That could be an option to keep in mind when/if we define a roadmap for 2.1 release.
If a 2.1 release can't be expected soon (i.e some mounth) we could rename it 2.2 and prepare a 2.1 release to be feature equivalent to 2.0.x but require java5. That beeing said, changing requirements for a "maintenance" release is not IMHO a blocker. Many 2.0.x upgrades required some fixes to existing projects, as detailled in release notes. I think the only reason for a minor version is when some features gets removed... just my 2cents. Nicolas 2008/5/4 Jason Dillon <[EMAIL PROTECTED]>: > Perhaps 2.1 needs to be changed to 2.2 and then 2.1 can be used for what > would be 2.0.10 + Java5 > > --jason > > > > On May 4, 2008, at 6:32 PM, Marat Radchenko wrote: > > +1 for 2.1, -1 for 2.0.10 > > On 5/4/08, nicolas de loof <[EMAIL PROTECTED]> wrote: > > > > > Hello, > > > > > > As you can read at http://java.sun.com/j2se/1.4.2/ > > > *" J2SE 1.4.2 is in its Java Technology End of Life (EOL) transition > > > period*. > > > The EOL transition period began Dec, 11 2006 and will complete October > > > 30th, > > > 2008" > > > > > > I don't think we have plan yet to release maven 2.1, so I think it > > > would be > > > a valid to require java 1.5 as minimal runtime. > > > > > > Main beneficts (IMHO) : > > > > > > - annotation can replace javadoc-style IoC an Maven plugin > > > declarations > > > (code allready available : > > > http://docs.codehaus.org/display/MAVEN/Java+5+Annotations+for+Plugins) > > > - jsr-250 annotations can replace some plexus interfaces ( LogEnabled > > > -> > > > @Resource('log') , Initializable --> @PostConstruct ...) and make > > > component > > > more "standard" and accessible to developpers without plexus > > > knowledge. > > > - generics can make the maven model more comprehensible. The current > > > "Collection project.getArtifacts()" is not really clear and the fiew > > > available javadoc don't help a lot. > > > > > > Other possible improvements : > > > > > > - plugin test tool could use jUnit 4 runners to create something > > > comparable > > > to spring-test-context : > > > annotate your plugin test class with @Runwith( "MavenPluginTestRunner" > > > ) > > > @Pom( "myTestPom.xml" ) > > > and the test will prepare the plugin set in the test pom and inject it > > > in > > > the test class. > > > - benefict from java.util.concurrent to do some tasks in parallel ? > > > Example > > > : dependencies downloading > > > - any other ? > > > > > > > > > WDYT ? > > > > > > > > > Nicolas. > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
