Maven 2.0 Technology Preview Available

Discussions

News: Maven 2.0 Technology Preview Available

  1. Maven 2.0 Technology Preview Available (27 messages)

    The Maven team is pleased to announce our Technology Preview for the eagerly-awaited Maven 2.0 release. This release offers users both an advance look at the enhancements in Maven 2.0 and a headstart in helping to shape the final Maven release (currently slated for early August).

    All new Maven 2.0 includes:

    Lifecycle Mechanism: Maven 2.0's central process replaces the use of goals with a standard lifecycle; plugins are now attached to a particular phase in the lifecycle, eliminating the need for pre/post goals.

    Transitive Dependencies: project dependencies at closure are now calculated to include scoping for compile-time, test-time, and run-time dependencies, as well conflict resolution.

    Improved Dependency Management: all dependency management, including dependency versioning across projects, is now controlled from the POM, elminating the need to use properties or entities to control dependency versioning.

    Integrated Reactor: Maven 2.0 is inherently multi-project aware. When Maven is executed from the top-level of a group of projects the reactor will automagically be invoked.

    Archetypes: Maven 2.0's new project template mechanism, archetypes, enables developers to get up and running quickly; the archetype provides developers with a prototype of a project that includes a set of velocity templates that can be parameterized to suit the environment.

    Improved Snapshot Mechanism: the snapshot mechanism is now configurable, allowing users to easily disable it entirely, enable it manually with a command line option, or have it checked at given intervals for snapshots.

    Scalable Repository Layout: the revamped repository layout is now more scalable, easier to manage, and simpler to navigate directly.
     
    Please note, as a Technology Preview, this release is not intended for production use.

    We plan to have 2-3 alphas and 1-2 betas prior to posting the release candidates, which will be followed by the final release. We welcome any and all feedback and look forward to your comments!

    Threaded Messages (27)

  2. First of all - congratz!

    "Eagerly awaited" is definitly the term!

    We've just started integrating Maven (1.x) here through our projects. Almost all of the questions and issues that were raised by our developers are given an answer in the 2.x feature list.

    We are currently working on an IntelliJ plugin which integrates Maven into IDEA. It is intended to be more than the simple plugin that exists today for IntelliJ (which simply lists the goals and allows execution) and really work with the Maven API and associate maven goals with different modules, as well as integrate into the build system. The issues we face seem to be answered in 2.x, so we definitly look forward for it.

    Even now, though, I intend to publish the plugin (perhaps via java.net) so existing 1.x users might benefit from it as well.

    If you guys need someone to develop the 2.x intellij plugin - I'm on the front line ;-)

    Keep up the great work!
  3. repository layout[ Go to top ]

    Improved repository layout - Maven 2.0 supports both the existing layout, and an improved repository layout that has deeper, partitioned structure making it easier to browse.

    I am not agee with this, the layout used for maven 1.0 is easy to browse. If I have some project under maven 1.0 and some under Maven 2.0 ... I need to build two repository and theses two repository are not compatible, are they ?
  4. Layout reasoning[ Go to top ]

    The new layout is meant to be used with a groupId that incorportates a project's FQDN. We use the groupId to create the path to the artifact in the repository. So for a project with a groupId of "org.apache.maven.wagon", we would place the artifact for that project in ${repo}/org/apache/maven/wagon.

    We honestly felt that when viewing a repository with a browser that drilling down to find a particular artifact would be easier.
  5. Layout reasoning[ Go to top ]

    the problem with deep structures is that they are hard to browse on slower connections. One has to click and wait repeatedly which can become frustrating.
    Another application where deep structures is contraproductive is automatic searching. I've tried to write a tool that would search the maven remote repo purely from the client side by calling the http server. It's way too slow since it has to perform many connections while drilling down the structure.

    However I guess this kind of searching cannot be performed from client side in an effective manner and needs a server counterpart. Are there plans to have the searching ability included in the maven distribution? In a way that would allow easy setup for any custom maven repository?
    That would be very cool for IDE integrations for example where one could have the whole remote repository right at the fingertips.
  6. Repository Management[ Go to top ]

    Milos, we plan to implement a full-blown application to manage, validate, and search Maven repositories. We already have tools for validating the integrity of a Maven repository but the general manageability and searching capabilities will come in the following months leading up the the final release of Maven 2.0. We will be blogging more about the repository manager but if you want to see what we are intending you should take a look at CodeZoo.net.
  7. Custom repository layouts[ Go to top ]

    A nice feature would be "Custom/Pluggable Repositories", where a maven client (plugins or maven core) accesses something of a service locator - so the repository can be a remote web site, ssh remote server, an EJB container, etc.

    This would allow "embedding" existing repositories (if some organization has a repository for other means and would like to reuse it) which maven does not recognize. All that would have to be defined is some sort of a repository proxy interface.

    Are there any plans to create something like that?

    (this sounds more like something to the mailing list actually ;-))
  8. Custom repository layouts[ Go to top ]

    All the things you're wondering about we already support! We have a general transport layer called Maven Wagon so right now we support support http, ftp, and scp. You just have to implement the Wagon interface for the transport you wish to support.

    For general artifact handling we have Maven Arifact which is decoupled from Maven proper. Maven Artifact supports arbitrary layouts though we will only be supporting one in Maven itself. Using Maven Artifact, artifacts are requested by providing a groupId, artifactId and version: we no longer use paths to retrieve artifacts so Maven Artifact is layout agnostic. In fact, using Maven Wagon and Maven Artifact you can theoretically store/retrieve artifacts from any source.

    Many of the features in Maven 2.0 like transitive dependencies and dependency mediation come from Maven Artifact. So, at some point we are planning on creating simple wrappers for Maven Artifact so that anyone can use these facilities. One of our first attempts at this will be to make Ant tasks so that Ant users can take advantage of all Maven's artifact handling capabilities without have to use Maven itself.
  9. Custom repository layouts[ Go to top ]

    Sounds great!!

    I can definitly envision rdbms repositories, or scp repositories.
  10. Love Maven ! Hate Jelly!![ Go to top ]

    Do plugins still have to be written in Jelly ? Can we use Groovy instead ?

    Why force deveopers to use a dying obscure language like Jelly to develop plugins ?
  11. Love Maven ! Hate Jelly!![ Go to top ]

    Hi,

    Actually, in Maven2 plugins are written as standard Java classes, or Marmalade (a Jelly successor I believe).

    However, I believe the Maven team has plans to deliver several adapters that would know to execute different kinds of plugins - for example, you could write a GroovyPluginAdaptor which would read your plugin's groovy scripts and execute them (it would ofcourse have to copy/link the Maven context info into a GroovyContext.

    Cheers.
  12. Love Maven ! Hate Jelly!![ Go to top ]

    Hi,Actually, in Maven2 plugins are written as standard Java classes, or Marmalade (a Jelly successor I believe). However, I believe the Maven team has plans to deliver several adapters that would know to execute different kinds of plugins - for example, you could write a GroovyPluginAdaptor which would read your plugin's groovy scripts and execute them (it would ofcourse have to copy/link the Maven context info into a GroovyContext.Cheers.

    That would be cool. I like Maven (after an initial period of hating it), but still can't bring myself to like Jelly.
  13. Mojos and Plugins in Maven 2.x[ Go to top ]

    Just a little background information first which might be helpful in explaining what we are planning for Maven 2.x. In Maven 2.x a plugin consists of one or more mojos where a mojo is akin to an Ant task. The main difference being mojos can written in Java or be scripted. The scriptability of mojos comes from the fact that Plexus, our IOC container, supports scripted components and mojos are Plexus components under the covers.

    Right now we support Java and Marmalade. Marmalade is a replacement for Jelly and we made a replacement for Jelly to be able to reliably support XML scripting which our current users are accustom to. XML scripting may be passe to some, but there are lots of Maven1 and Ant users for whom it is a mainstay so we will be supporting XML scripting. We are, in fact, doing our best to try and get a Jelly compat mode working in Marmalade to ease the transition for maven1 users.

    That said, Plexus currently supports Jython, Beanshell and Groovy components. By the time of the final release in August we will most likely have all these working in side Maven 2.x but we will definitely promote one option and it is looking like it will be Beanshell. It is small, Java-like and reliable. Groovy won't even be considered an option until a final release appears. Maven 2.x will not be a Groovy testbed. We will not be repeating history insofar as incorporating experimental languages into the core. It's just not something we can afford to do again.
  14. Mojos and Plugins in Maven 2.x[ Go to top ]

    Why Plexus? With the many IoC containers out there, why would you choose one that doesn't make the first page in terms of mindshare? Is Plexus going to be Maven2's answer to Maven1's Jelly (in terms of adopting a library no-one else uses and which is eventually stranded).

    It's always seemed to me that Maven has some good ideas functionally but has just made some horrificly tragic technology decisions.
    Just a little background information first which might be helpful in explaining what we are planning for Maven 2.x. In Maven 2.x a plugin consists of one or more mojos where a mojo is akin to an Ant task. The main difference being mojos can written in Java or be scripted. The scriptability of mojos comes from the fact that Plexus, our IOC container, supports scripted components and mojos are Plexus components under the covers.Right now we support Java and Marmalade. Marmalade is a replacement for Jelly and we made a replacement for Jelly to be able to reliably support XML scripting which our current users are accustom to. XML scripting may be passe to some, but there are lots of Maven1 and Ant users for whom it is a mainstay so we will be supporting XML scripting. We are, in fact, doing our best to try and get a Jelly compat mode working in Marmalade to ease the transition for maven1 users.That said, Plexus currently supports Jython, Beanshell and Groovy components. By the time of the final release in August we will most likely have all these working in side Maven 2.x but we will definitely promote one option and it is looking like it will be Beanshell. It is small, Java-like and reliable. Groovy won't even be considered an option until a final release appears. Maven 2.x will not be a Groovy testbed. We will not be repeating history insofar as incorporating experimental languages into the core. It's just not something we can afford to do again.
  15. Why Plexus?[ Go to top ]

    There are many options for containers now, but Plexus predates all of them except for the Avalon containers which is what Plexus originally was. My options when starting m2 were limited to Excalibur and Fortress as they were the only embeddable solutions at the time. Excalibur was clunky and I couldn't get Fortress to work. Phoenix (which by the way is probably still technically the best container I've ever seen -- it is now Loom @ Codehaus) was not embeddable.

    Some things I wanted which weren't available were scriptable components, dynamic component addition/updating, pluggable component lifecycles, discoverable components, pluggable component instantiation strategies, and client definable component personalities i.e. Plexus can run an Avalon component along with a Plexus component along with a Pico component if these component personalities are enabled. Plexus now has all these features.

    All mojos present inside m2 will be discovered, if the requested mojo is not present it is transparently downloaded from a Maven repository and drawn into Plexus where it is adapted to be run as a Plexus component. None of these things are magic but they took time to implement and most containers I know of don't do many of these things even today.

    So, it certainly wasn't the case that I decided to just jump in and make a container 6 months ago. Maven2 has been in the works for a long time and I'm not only interested in dependency injection. There are a whole gamut of other problems to be resolved by component containers but people tend to focus on terms like IoC and miss entirely many of the other critical issues outlined by people like Clemens Szyperski, methods like Catalysis and voluminous amount of literature on components in general.

    This is getting long and probably better suited for a blog entry on why we create Plexus and use it.
  16. Why Plexus?[ Go to top ]

    There are many options for containers now, but Plexus predates all of them except for the Avalon containers which is what Plexus originally was.
    Actually, it doesn't really matter *why* Plexus is a good choice for Maven 2.

    You are missing Jason's point and repeating the Jelly mistake by using frameworks that nobody uses.

    Mindshare is important, especially for tools that heavily rely on the community participation and plug-ins to spread. In these cases, it's worth the extra effort to adopt a popular tool, even if you need to run through a few extra hoops to make it work.

    Besides, we're talking IoC, not application servers, I can't believe it would be that hard to switch a container for the other...

    --
    Cedric
  17. Why Plexus?[ Go to top ]

    Actually, I was under the impression that the "Jelly mistake" had more to do with core-developer abandonment than with the vibrancy of its community...perhaps a trivial, but definitely important, difference.

    Plexus does offer many advantages over Spring, for example. There are other postings on this thread enumerating some of them. For the plugin-separation, it's one the only good choices that I've seen. Whatever else you can say, the most popular IoC containers can't fit the bill here. At least, not without major revision which would probably compromise/dilute their main reason for existence.

    So, buzzwords aside, why use a hammer when we need a drill? This isn't a popularity contest, but a search for the best tool for the job. If the tool really is good, then the community will grow around it. If it's not good, then we can still say that this container has some fairly generic attributes...if we can duplicate them elsewhere, then we can simply rewrite the deployment descriptors, and escape lock-in. I mean, that is the promise of IoC, right? ;)

    One final thought: how did Spring gain it's community? It certainly wasn't by adopting someone else's container, and modifying it suit its own purposes...even good projects spend some time in obscurity.
  18. Why Plexus?[ Go to top ]

    How does a project gain mindshare? I agree with you that it is important to be using tools that people are familiar with and accustom to but new projects do appear and they can gain mindshare.

    To posit that the only good tools are popular ones is not an argument I buy and obviously one you don't buy either. JUnit doesn't do what you feel it should, has some features not present you would like, and generally lacking and so you wrote TestNG. By your own argument you should have jumped through a few extra hoops to collaborate with the JUnit guys so you could use a popular tool. But you didn't. You made your own tool and you plan to gain mindshare don't you? I plan on doing the same with Plexus.

    Plexus is a project without much notoriety at the moment, but as Maven 2.0 is released, Plexus will hopefully not be a framework that no one uses. We plan to document it well and promote it as best we can to gain mindshare. The choice of tools is never going to be a static list of options and you can't blame a guy for trying to bring a new choice into the market place. Right? :-)
  19. Why Plexus?[ Go to top ]

     The choice of tools is never going to be a static list of options and you can't blame a guy for trying to bring a new choice into the market place. Right? :-)
    Touche' :-)

    I would argue that the situation is not quite comparable, though. IoC is only a small constituent in your overall project, while TestNG's goals were directly at odds with the way JUnit is designed and implemented.

    Anyway, point taken, history will decide if you made the right decision.

    --
    Cedric
  20. Mojos and Plugins in Maven 2.x[ Go to top ]

    Why Plexus? With the many IoC containers out there, why would you choose one that doesn't make the first page in terms of mindshare? Is Plexus going to be Maven2's answer to Maven1's Jelly (in terms of adopting a library no-one else uses and which is eventually stranded). It's always seemed to me that Maven has some good ideas functionally but has just made some horrificly tragic technology decisions.

    Just curious can you name at least one of the popular IoC
    container which has feature set which matches plexus (which is imo the strongest point of m2)?

    Note that for example for maven you need to have a container which has:
    - component/plugin class loader isolation (plugins and their dependencies should be loaded into separate realms so they don't clash)
    - components which define their dependencies in terms of jars and other components
    - support for multiple versions of the same plugin/component
    - support for complex lifecycles (do not confuse it with lifestyles)

    There is couple of great open source IoC containers, which can do that (Jason Van Zyl named one of the them) but afaik non of them is really popular. The ones which are popular are just to simple to support needs of new maven.

    Michal
  21. By the time of the final release in August we will most likely have all these working in side Maven 2.x but we will definitely promote one option and it is looking like it will be Beanshell. It is small, Java-like and reliable. Groovy won't even be considered an option until a final release appears.

    What about Pnuts?
  22. There's only so much time in the day. I originally tried Beanshell and Jython because I have experience with both of them and I made the obligatory attempt with Groovy but I've not heard much about Pnuts so I'll definitely check it out. Thanks for the reference!
  23. Mojos and Plugins in Maven 2.x[ Go to top ]

    Maven always was a bitter-sweet experience to me. As an earlier poster stated, you start out intensely hating it, then it sort of grows on you in what is undoubtedly part becoming accustomed and part Stockholm syndrome. To this day I remain unconvinced that I am better off with Maven than with the Ant snippets its stated goal is to eliminate, but the resident build system nuts insist on using it so I have to cope. But I digress.

    I know it's an asinine point to make but one thing that I always found amusing and annoying at the same time is the names: "Reactor". Huh? Guess "Engine" fell out of favour as an impressive-sounding metaphor for this trivial piece of code or the other. Now "Mojos"? What's wrong with calling what it is, "plug-in"? "Wagon"... "Wagon" for crying out loud... Stop trying to look cool and name things so it gives us poor bastards who have to use it an idea what it is.

    Anyway, If the build guys don't stumble upon some other tinkertoy in the mean time, I'll probably find myself jousting this beast sometime in the future, so good luck with it.
  24. Migration from Maven 1.0 to 2.0[ Go to top ]

    I have been using maven-1.0 since some time now & wondering if the migration would be seamless.A feedback to the maven development team, my project has a typical requirement to embedd reports 'site:deploy' in the webapp so that the developers would be able to view the latest reports.I know this may sound little wierd, but thats the way it is.Some build details..

    Three modes to execute build.
    1. Build without report embedding.
    2. Build with report injection (site:deploy)
    3. Build with report injection and AspectJ weaving.

    When executing in mode '3', maven dies reporting AspectJ runtime causing 'OutOfMemory' error.The memory usage at this stage is 112/123mb.I am running 6 maven reactors in the build. (core,shared,bizserver,client,web)+ embedd:report.Do you guys recommend migrating to 1.0.2 or any other wise idea.

    Peace,
    Vijay KHANNA
  25. suggestions and rant[ Go to top ]

    I’d really like to see M2 succeed. Here are a few suggestions:

    Unless you plan to ship M2 with a bablefish I suggest only one scripting language be allowed in the distro. Having multiple scripting languages will just fragment and burden information overloaded developers. Build environments should be boringly uniform and predictable.

    Just looking at ‘generate-source’ makes my tendons tighten up, at least provide shorter aliases like ‘gen’ for long target names.

    One thing that’s sorely lacking in build environments is a flexible uniform way to deploy to J2EE application servers. M2 should define a standard deployment lifecyle and set of mandatory and optional targets that cover:
    1) packaged deploy and undeply (mandatory)
    2) in-place deployment (optional)
    3) expanded deployment (optional)
    4) server status (running or not)
    5) start/stop/restart server or leave alone if already running
    There should also be a documented way (preferably in the POM) to deploy to any number of differently configured target servers.

    Slightly off topic but Sun is doing an incredible disservice to Java community by not allowing the activation and javamail libs to be freely distributed. Maven’s repository is probably the most effective means yet of making Java ubiquitous and Sun’s management is sabotaging it by allowing the lawyers to call the shots. Simple solution: hand these libraries over to the Apache Group.
  26. suggestions and rant[ Go to top ]

    Unless you plan to ship M2 with a bablefish I suggest only one scripting language be allowed in the distro. Having multiple scripting languages will just fragment and burden information overloaded developers.

    We agree, which is why there is an intent to focus on (and probably distribute) just the following: pure Java API (most powerful), Marmalade (to help those trying to move from Maven 1.0 or script with Ant), one other which looks like being Beanshell.

    That said, I believe we'll allow other implementations to be added, or provided by the languages themselves, to avoid the holy wars if nothing else. Some shops might be using another language internally and choose to right a set of their own plugins in that particular language.
    Build environments should be boringly uniform and predictable.

    Sounds like a good justification for Maven :)
    Just looking at ‘generate-source’ makes my tendons tighten up, at least provide shorter aliases like ‘gen’ for long target names.

    I'd rarely use this - more likely I'd use "compile" and have it do both. It's a fair point though - perhaps aliases are a better alternative though so we can retain the descriptive names.
    One thing that’s sorely lacking in build environments is a flexible uniform way to deploy to J2EE application servers.

    I couldn't agree more - we certainly hope to be able to provide good support for this as a set of plugins.
    Slightly off topic but Sun is doing an incredible disservice to Java community by not allowing the activation and javamail libs to be freely distributed. Maven’s repository is probably the most effective means yet of making Java ubiquitous and Sun’s management is sabotaging it by allowing the lawyers to call the shots. Simple solution: hand these libraries over to the Apache Group.

    This has certainly troubled a lot of Maven users - it's easily one of the most frequently asked questions.

    We've looked at other alternatives - click through licenses (not sure we can even do those), or stubs to help locate and install the JARs locally. This would only make it a little easier on a new user though. Depending on how the situation pans out, we should definitely include something in the final Maven2 release.
  27. Maven and SUN[ Go to top ]

    Trying to get the JavaMail and the Activation libraries into the Maven repository is something I tried to get done about two years ago and SUN was, to be honest, not very helpful at all. It is a shame because it is a real disservice to the Java community and though it would require some legal wrangling on SUN's part this is not an intractable problem.

    I believe the only way to rectify this is by publicly presurring SUN to help us. It is common knowledge that using SUN JARs with Maven will stop your build dead in its tracks and this is not only extremely annoying but entirely unecessary.

    We're all ears on how this situation can be remedied.
  28. suggestions and rant[ Go to top ]

    One thing that’s sorely lacking in build environments is a flexible uniform way to deploy to J2EE application servers. M2 should define a standard deployment lifecyle and set of mandatory and optional targets that cover:1) packaged deploy and undeply (mandatory)2) in-place deployment (optional)3) expanded deployment (optional)4) server status (running or not)5) start/stop/restart server or leave alone if already runningThere should also be a documented way (preferably in the POM) to deploy to any number of differently configured target servers.

    It would really help if there were some standardization of features on this topic. Even de factor standards would be of immense help. Unfortunately, the simple fact is that management of J2EE servers is an extremely rich and diverse discussion to have, and a very sticky problem to try to address.

    The only solution I can imagine (and maybe someone else can help me out with a little inspiration here), is to somehow provide an adaptor layer which would conceal the complexity of this process from the user. What makes this extremely difficult is that you have to (a) boil down the abstraction layer to the common denominator, which means excluding a lot of the nicer features that users and companies pay for when buying a container; and (b) maintaining an incredibly complex collection of parallel implementations of a very small set of interfaces, complete with consistent error handling and user feedback. The latter issue involves interpreting responses from each proprietary API and trying to make sense of it for the user, sort of similar to what Spring attempts with its JDBC layer (except JDBC is in fact a standard interface).

    I'd like very much to have something like this to help an enterprise development process. However, at the risk of sounding overly pessimistic, I fear that until the powers that be in the commercial world get their act together and move toward some standard (even de facto), we're very limited on how far we can go with this.