This is my response a comment on TSS about the structure in Maven projects. We recommend a structure we don't dictate one ...

The directory structure used by a Maven project has never been fixed. There are defaults, yes, but they can all be overridden. I have had many clients over the years that have had existing structures that needed to be preserved for various policy reasons, or projects that had lives spanning many branches into the past where changing the directory structure would have made merging a nightmare. The defaults are easy to change at a project, or organizational level. That the structure is fixed in Maven is a myth.

Many organizations choose to start new projects using the standard structure and/or migrate to the standard where possible as standard Maven documentation, training, and idioms then apply. Maven's defaults were chosen to allow for growth but are, in fact, as arbitrary as the defaults in any other system. The advantage is that our defaults are used by a few hundred thousand people and there are undeniable benefits in a collective understanding of a project structure. I'm not trying to say this alone mitigates any of the implementation defects in Maven (of which no one is more acutely aware then myself) or that a default structure alone is a good reason to use Maven. But it lends itself toward building a level of social capital (a measure of how well groups can work together) because there is some common structure from which to work from and communicate. Maven does not dictate a structure, contrary to popular opinion, but we definitely promote one.

You have used your same Ant build files since 2002 which works for you. If you deliver using this tool set who can argue with that. But I have seen the argument many times over and it goes something like "my structure is pretty simple because I stick to the basics and it does what I need." This is perfectly fine in isolated cases but try to onboard new developers, find resources for your build and release team, attract developers to your open source project, reach a standard in your department, or your organization, integrate with disparate parts of your organization, incorporate third party libraries, integrate open source and you will rapidly find N pivot points against which you must learn something different to make the overall system work. This is simply an untenable proposition for a community of people trying to together efficiently.

Maven has many flaws, but it is very usable by a large number of groups. Maven is also not static. Not many people know that .NET and C toolchains have been created for Maven, or that with a few new implementations of internal components that Maven can build OSGi components directly from manifest information (look Mom, no POM!), or that you can write Maven plugins in Groovy, Ruby, or Ant script. Many of these things are unknown because the Maven project has admittedly been terrible at documenting these attributes and features. This is a failure at the Maven community level that we are trying address.

Ultimately it's your decision as a user. If Maven doesn't work for you don't use it. But Maven was not meant to cater to personal biases, it was meant to work for groups and as such compromises need to be made in order to use Maven effectively. Maven is not for anyone in particular, it was intended for a large number of users who have made a conscious decision to work in more or less in the same way to achieve results in what they are making, not in how they make it.

Eugene and I have been watching with amazement how vocal MyEclipse users have been about their great disappointment with Genuitec's attempt at Maven integration, which amounts to complete mutilation of m2eclipse and the way Maven itself works. Genuitec decided to work in their standard fashion, which is unfortunately not a very collaborative mode of operation, and it's apparent that MyEclipse customers are not happy.

MyEclipse Breaks Maven

Maven has a very opinionated way of doing things, there is a very strong structure that is encouraged and users have come to like the convention over configuration approach. I warned Wayne Parrot from Genuitec that changing the way Maven worked by default, or at least the attempt to, would result in unhappy Maven users. None of our documentation would apply, users could not use conventional modes of support like the Maven users lists, or the m2eclipse users lists, and they couldn't benefit from standard books, or the Maven website. I really wasn't very pleased with some of the initial reactions but it was this quote that drove me to write something about the unequivocally abysmal Maven4MyEclipse integration:

I was using maven4myeclipse because I was following a book on maven. Until I reached a chapter on multi-module maven projects, after countless hours and then days trying to get the example chapter to work in maven4myeclipse I went online seeing if anyone else encountered similar problems. Well I've saw on google that someone in the myeclipse forums actually "removed maven4myeclipse" (http://www.myeclipseide.com/PNphpBB2-viewtopic-t-21172-highlight-m2eclipse.html) and instead installed m2eclipse. Curious I followed those same steps and managed to install m2eclipse without any obvious problems.

I was surprised to see that not only did m2eclipse have everything that maven4eclipse had but it seemed much, much, much more capable of doing big multi-module enterprise applications minus the frustration that maven4eclipse gave. Also m2eclipse truly followed the "convention over configuration" philosophy as I could literally drag and drop ANY pom files from any location into a m2eclipse project and have it working immediately. As opposed to maven4myeclipses non-standard propietary project meta information which is very myeclipse centric and non-portable for maven projects.

I'm very disappointed in the maven4myeclipse plugin and I'll recommend to anyone reading this post that if they want a excellent maven plugin for their projects, I would strongly recommend that they uninstall maven4myeclipse and instead install m2eclipse, I'm sure that it'll be compatible with your existing maven projects with a minimum amount of disruption.

So how did did Genuitec get their Maven integration so wrong? I really think it is a lack of foresight in cooperating with a project that has a very strong community and doing pretty poor product planning. They obviously didn't talk to many of their customers about Maven integration as you can see from litany I've collected below. I think the integration of Maven in MyEclipse can be considered a complete flop by MyEclipse users. Hopefully the next time around Genuitec will make an attempt to communicate more with the Open Source community which they are trying to leverage and do a better job of listening to their customers or they are going to be listening a continuation of the litany below.

So what can Maven4MyEclipse users do? Well, I don't have an ideal solution because that's up to Genuitec. As a stop gap for MyEclipse users who want to harness the full power of m2eclipse, they can use the following update site that will disable Maven4MyEclipse and replace it with stock m2eclipse.

http://m2eclipse.sonatype.org/update-maven4youreclipse/

After all, it's your Eclipse and you can have Maven the way you expect and want it. Glad we could help. The rest is a keen lesson in learning to treat your customers like an intelligent community of users who prefer to not have their time wasted.

The Genuitec Maven Integration Litany from MyEclipse Customers

We've assembled some of the feedback from Genuitec's own customers who are frustrated with the problems they are having with Maven4MyEclipse:

Maven projects are not arbitrary. They have a consistent and predictable layout. You have effectively made m2eclipse useless with your M4ME implementation. Because of this I'll most likely not move to newer versions of MyEclipse past 6.0. (source)

I have several hundred maven projects that work just fine with m2eclipse but are useless with Maven4MyEclipse. Hopefully future versions will become compatible but until then i will not upgrade. (source)

Why do we need a custom implementation of m2eclipse? Why do we need custom implementations of anything? I don't mind new features being added to MyEclipse, but if each new version is going to break my existing setup, it begins to become tedius. Especially if there is no easy way to disable a conflicting feature from within the Manage Your Configuration. Creating a new project and copying things into it is simply not an option. (source)

Okay, I have now been able to disable Maven4MyEclipse and have the original m2eclipse working again (on MyEclipse 6.5). (he also provides instructions how to remove Maven support from MyEclipse) (source)

The crux of the issue here is that m2Eclipse is very powerful, very flexible and works with existing projects or new ones. I can take any maven-based project and just use it. Maven4Myecilpse appears only to work for Newbies at the expense of those of us who already have Maven-based projects. So, for people like me, M4ME offers none of the value that M2E does. And as a result I'll probably do what's been recommended above and pry your component out in favor of putting M2E in. (source)

If you read this thread you'll see that's exactly the problem. One of the other posters mentioned 400 maven-based projects. Without being able to add maven support from ME to the project, he can't function within ME 6.5. I think if you can't fix M4ME at least make it so those of use who want to use M2E can turn off M4E. (source)

Like many others here, I find Maven4MyEclipse to be a major step BACKWARDS in functionality from the plain-old m2eclipse plugin.What in the world were you thinking to actually REMOVE from m2eclipse the standard maven project structure? Simply defies all belief! (source)

I am migrating from M2Eclipse to Mave4Eclipse my project works fine with M2Eclipse when i try build using the Mave4Eclipse i am getting this error. (source)

We currently have the Standard edition, so we cannot use maven4myeclipse, and are unable to run m2eclipse after it is installed. This is very disappointing and doesn't seem to be in line with the pluggable / open architecture of eclipse. (source)

I appreciate all the hard work which has been put into the myeclipse maven integration but It is not yet a complete maven solution and has several features which are missing (many of which are already implemented in the m2eclipse plugin). As a paying customer I'd like to get the some of the new features of 6.5 but i cannot because I am forced to stay at 6.0.1 until the myeclipse maven integration catches up to m2eclipse. This doesn't seem like a viable solution. (source)

I'm no great fan of Maven after it biting me severely along the way but it would at least vaguely work with the M2Eclipse plugin. Rolling back from 6.5.1, a fantastic release otherwise where a lot of bugs I was running into were fixed, and having no option to run the freely available working Maven plugin and pay for it just hurtful. (source)

We've bought six Standard edition licenses, but we can't use them while MyEclipse won't work with our existing Maven projects. Is there a download of version 6.01 for OSX available until you have removed Maven4MyEclipse from the Standard edition? (source)

I installed m2eclipse not realizing that MyEclipse 6.5 had a maven plugin. I seem to have had a conflict (both m2eclispe or Maven4MyEclipse preferences pages are getting exceptions) so I disabled the m2eclipse plugin. Even though m2eclipse is disabled, I am still getting a java.lang.NoClassDefFound error from Maven4MyEclipse preference page. I am unsure how to recover at this point -- do I have to reinstall MyEclipse 6.5 and start over? Also, is there a way to disable Maven4MyEclipse? (source)

This is, quite frankly, ridiculous, but you've already heard that over in other threads. (But it's sort of unfathomable how you guys didn't anticipate that this would be a problem -- integrating m2eclipse into MyEclipse in such a way that you removed functionality AND prevented users from restoring that functionality with their own local installs of m2eclipse. Did this really, really never cross the drawing board?!?) (source)

...why stomp on the namespace of the existing m2eclipse plugin? Why didn't you create your functionality in an entirely different namespace, and make it so that users could choose whether to use it at all, and if they chose not to use it they wouldn't have any problem installing m2eclipse right atop MyEclipse 6.5? (source)

this new feature prevents us from using 6.5 with our existing maven projects... which we would like to be able to do as used to. Downgrade ahead of us. (source)

I created a Maven project from scratch at work and checked it in to Subversion. I'm also lucky enough to be able to work from home and have access to that svn repository, and I'm flabergasted that I can't check out that same project and work on it at a different location and have all the same functionality available to me. I can't add Maven support to the project. I can't figure out how to add AspectJ support. It's a total nightmare trying to get this project working on another machine. (source)

If the magnitude of the problem isn't completely clear from this forum thread, just for the benefit of the developer folks, I use Maven 2 for all Java projects developed for my company and others I consult for. When I discovered that the initial Maven 2 support in MyEclipseIDE prevented using existing Maven 2 projects, I had to completely uninstall MyEclipseIDE and am unable to use it at all now. So I'm a version behind, and am stuck there until this Maven support issue is resolved. So if this support issue has been resolved, then please let me know, so I can upgrade. If not, then please understand the magnitude of the problem: I cannot use MyEclipseIDE at all until this is resolved. (source)

For the last few nights we have had some particularly bad Maven citizens averaging almost 3000 connections in a 10 minute period. This particular abuser emanates from the Netherlands and this is the first time I have completely blocked an IP permanently from the central repository (I'm sure they will just use another one but it's a start). I've started trying to track down who exactly the IP (82.94.207.11) belongs to. I have a pretty good suspicion who it is.

We're happy to work with groups who want to mirror the repository using rsync provided you are using that mirror to service other Maven users. Trying to scape Maven central cripples the primary feeder to all the mirrors and the synchronization with other open source organizations we work with. By opening 3000 connections to central and scraping it you screw every other Maven user on the planet you idiots. Anyone who knows me knows how rabidly tenacious I am and I will track down every IP you have and create blacklist that every Maven mirror and Maven repository manager will just drop connections to. If you make the life of Maven users more difficult then necessary I will find a way to do the same to you.

On the m2eclipse mailing list Alexandre Sauvé asked about the future of Eclipse RCP-based application development with Maven and so Igor Fedorenko, who leads our development on Tycho, responded with a short summary of what we're planning and what's been accomplished so far with Tycho.

Here's what Igor had to say:

First of all, I have to apologize for keeping Tycho development plans and progress to myself. I would like to thank you for bringing this up and will try to both explain our grand vision and what we already have or will have implemented in the near future.

The big picture. Ultimately, we want tycho to be one-stop solution for doing Eclipse and OSGi development with Maven 2 (actually, 3, more on this later). We believe there are two distinct development workflows, when developer explicitly creates and maintains OSGi manifest and other Eclipse/OSGi metadata (we call it "manifest-first") and when OSGi metadata is generated by the build based on information available from pom.xml ("pom-first", naturally). We plan to support both development workflows.

In manifest-first mode, tycho will use Eclipse/OSGi metadata and OSGi rules to calculate project dependencies dynamically, at build time. It will support all attributes supported by Eclipse OSGi resolver (Require-Bundle, Import-Package, Eclipse-GenericRequire, etc). It will use proper classpath access rules during compilation. It will support all projects supported by PDE and will use PDE/JDT project metadata where applicable. One important design goal is to make sure there is no duplication of metadata between pom.xml files and Eclipse/OSGi config files. In fact, tycho will support "pom-less" projects, where all required build metadata is derived from Eclipse/OSGi config files.

In pom-first mode current plan is to provide similar set of features as in felix/bnd plugin, although I do not know if we'll be able to share any of the code. Additionally, Tycho will support Eclipse-friendlier Require-Bundle and will provide better support for developing multiple related OSGi bundles (I have not checked recently, so felix/bnd may already support these).

In both modes tycho will support remote repositories both as source and sink for artifacts. We plan to support maven repositories, p2 and update sites, although level of support will likely vary. There will also be integration between m2e, tycho and pde to make the three work nicely together.

So these are the plans... Disclaimer: plans do change! ;-)

Now to what tycho is already able to do. Our first goal was to enable m2e continues build, so we started with manifest-first mode and I believe covered most of manifest-first features described above. Tycho already uses Eclipse/OSGi metadata to resolve project dependencies by OSGi rules and injects these dependencies into maven project model dynamically, at build time. It supports bundle, fragment, feature and update site projects (shame on me, but no RCP application yet). It knows how to run junit test plugins using OSGi runtime. Two big features that are still missing, are support for pom-less projects and work with artifact repositories, although there is prototype of target platform materialization from p2 repository already. There is also some rudimentary implementation of pom-first mode, but its usability outside of m2e build context is probably limited. Many smaller features are still missing and I am certain there are quite a few bugs too, but I think overall tycho code is in reasonably good shape already.

Few words about relationship between maven and tycho. Tycho is not morphing into maven, but it provides maven extensions and plugins that enable maven to work with Eclipse/OSGi projects. Some of tycho functionality, especially OSGi dependency injection, relies on maven features only available in maven 3.0 which was very recently renamed from 2.1. Since there is no maven 3.0 release yet, current tycho distribution includes complete copy of maven 3.0-SNAPSHOT.

As for contributing to the project... well, this would be really awesome . I think the best way to start is to try tycho and see what is missing to support your projects and development workflow. Then we can work together to implement missing features, fix bugs, etc. I have simple demo that shows how to use tycho to build set of simple projects and some user-level documentation. I will try to make this available later today. I will also provide tycho dev env setup steps, so you can start looking at the code if you want to. And tycho distribution is already available from the Sonatype Maven repository (looks for the latest .zip file)

I hope it answers your questions, but feel free to ask more, especially if something is not clear or does not make sense. You can subscribe to the m2e mailing list if you want to learn more.

Sonatype just released Nexus 1.0-beta-5 where the most significant change was the addition of the RBAC and authentication system based on JSecurity. It's pretty amazing how fast the Nexus team integrated JSecurity. In 4 days we got the first integration done that was working. Yes, 4 days. At the end of our iteration, a week after we started, it was pretty much fully working. After two weeks we were completely done integration and testing JSecurity.

JSecurity is currently in the Apache Incubator but that should in no way deter you from using it. The architecture allowed us to override everywhere we found it necessary, and the JSecurity team turned around fixes on almost a daily basis which is also pretty amazing. We will definitely be integrating JSecurity in the rest of the Sonatype products. I highly recommend JSecurity for your application if you require a complete security solution. Thanks to Les Hazlewood of JSecurity for giving us advice, though it's so good we probably didn't need your advice :-)

The time has finally come to twit. Not that anyone would be particularly interested in my brain farts but here you go.

http://twitter.com/jvanzyl

Ben over at Codehaus has created a Nexus repository index for Codehaus that you can use from inside m2eclipse. If you are interested you can learn how to create a Nexus index for your project and join the group of projects that are already providing indices. Why is a Nexus index useful to your users? It means they have immediate access to all your artifacts without having to leave the IDE!

Nexus is getting a lot of traction lately as we see several open source organizations indexing their repositories with Nexus (or the stand-alone Nexus Indexer) and official adoption by all IDEs.

Read more...

http://www.eclipse.org/newsportal/thread.php?group=eclipse.technology.m2e

Read more...

Read more...

Maven Day at Intuit

Read more...

Sonatype is also talking with a few of our clients about basic requirements in NMaven, and so we figured we might host an open event here in the Valley, where folks interested in Maven and .NET can chat about future direction and things they would like to see. Drop me a line if you're interested.

Welcome aboard Shane!

Read more...

Tamás has been with for Sonatype for a few months now, quietly working away on our second generation repository manager. Proximity served Maven users well and Tamás has gone even further to provide some very advanced proxying features. I've helped out with the REST APIs and Eugene Kuleshov helped with the indexing and searching capabilities. The most important features are as follows:

• Ability to read Proximity configurations
• Repository proxying and hosting
• Full indexing and searching (including central repository index downloads for remote searching)
• No external resource requirements (i.e. points of failure like databases, ORMs, or content repository stores)
• Stand-alone security model with LDAP support
• AJAX Interface
• Fully compliant WebDAV support (no other repository manager does: run Litmus to verify that)
• Complete REST APIs
• Repository RSS feeds
• On-the-fly repository metadata cleaning/correction
• Enhanced logical routing and aggregation of repositories
• Ability to publish and proxy M2 repositories to M1 clients
• Ability to optimize repository request resolution by group and artifact IDs
• Snapshot cleanup
• Runs out-of-the-box. Just drop it, unzip it and go!

We are starting beta testing with four of our largest clients with a total of eight thousand developers so when Nexus works for them it will most certainly work for everyone else. If you are interested in beta testing we are looking for large scale environments with hundreds of developers right now, but we are also looking for existing Proximity users who can help test the transition from Proximity to Nexus. The source code will be released under the Apache Software License and will be available from a Subversion/GIT repository when we are done beta testing. A special thanks to Tamás who has worked very hard, and been very patient as he's wanted to tell every Proximity user about Nexus for a month now. If you're interested in beta testing we will open this up to the general public this coming Monday.

Read more...

Tamás has been with for Sonatype for a few months now, quietly working away on our second generation repository manager. Proximity served Maven users well and Tamás has gone even further to provide some very advanced proxying features. I've helped out with the REST APIs and Eugene Kuleshov helped with the indexing and searching capabilities. The most important features are as follows:

• Ability to read Proximity configurations
• Repository proxying and hosting
• Full indexing and searching (including central repository index downloads for remote searching)
• No external resource requirements (i.e. points of failure like databases, ORMs, or content repository stores)
• Stand-alone security model with LDAP support
• AJAX Interface
• Fully compliant WebDAV support (no other repository manager does: run Litmus to verify that)
• Complete REST APIs
• Repository RSS feeds
• On-the-fly repository metadata cleaning/correction
• Enhanced logical routing and aggregation of repositories
• Ability to publish and proxy M2 repositories to M1 clients
• Ability to optimize repository request resolution by group and artifact IDs
• Snapshot cleanup
• Runs out-of-the-box. Just drop it, unzip it and go!

We are starting beta testing with four of our largest clients with a total of eight thousand developers so when Nexus works for them it will most certainly work for everyone else. If you are interested in beta testing we are looking for large scale environments with hundreds of developers right now, but we are also looking for existing Proximity users who can help test the transition from Proximity to Nexus. The source code will be released under the Apache Software License and will be available from a Subversion/GIT repository when we are done beta testing. A special thanks to Tamás who has worked very hard, and been very patient as he's wanted to tell every Proximity user about Nexus for a month now. If you're interested in beta testing we will open this up to the general public this coming Monday.

Read more...

I been spending a lot of time in TextMate, and so I found BlogMate along with the standard Blogging Bundle. They make blogging from TextMate way too easy. I have found recently when I’ve wanted to blog don’t want to use a browser and I just find Ecto tedious and overly complicated. I have a way of working with text and doing things differently inside Ecto was just annoying. Working inside TextMate, using Markdown, and firing off an entry with a hotkey is very nice indeed.

The standard Blogging Bundle is great for regular posts, but BlogMate is a nice complement as you can just fire messages off to Twitter from inside TextMate.

We realize that many users are frustrated by not having their patches incorporated into Maven so this is our first organized attempt to remedy the situation. We definitely don't want to turn people away from contributing to the project because we don't make time to incorporate external work.

Maven Patch Day will take place on Tuesday August 21st and we pretty much have all TZs covered. If you have a patch you are encouraged to submit it on the Maven Patch Day page and be available via email, or preferably join our IRC chat room (irc.codehaus.org:6667 #maven).

The presentation will be held on Thursday, August 16th from 6-8pm at the in the Auditorium room at the Convention Point. There will be some drinks and hors d'oeuvres provided after the presentation. The full address is below and here's the Google map to help you find your way. See you next Thursday and many thanks to SWX for sponsoring the event !

SWX Swiss Exchange
ConventionPoint
Selnaustrasse 30
P.O. Box
CH-8021 Zurich
+41(0)58 854 23 10/11
www.conventionpoint.ch
info@conventionpoint.ch

For integrating Maven features into Ant builds the Maven Ant Tasks are the way to go. We've recently had a flurry of activity from Herve Boutemy who has helped us great improve the Ant support.

You can find the binaries from our download centre and our Roadmap is also available.