RE: release-plugin enhancement
Ok, that might cover the first part. I still think the second part could be improved to make the interactive mojos easier to use. -Original Message- From: dan tran [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 10, 2006 8:24 PM To: Maven Developers List Subject: Re: release-plugin enhancement There is a JIRA to create release:release mojo to do just that to support full release automation On 5/10/06, Brian E. Fox [EMAIL PROTECTED] wrote: All, I'd like to add the ability to specify the release version, next development iteration and tag base as parameters to the release plugin so that no interactivity is needed. 1st any objections? 2nd: For multimodule builds, release prompts for the versions for each module. Is this really needed? It seems like if someone is releasing a multimodule build as a single unit, shouldn't all the modules share the version number? If no, then I propose 1 of 2 solutions: if the version IS the same as the parent to begin with, then don't bother prompting. AND/OR if multiple modules are detected, prompt if we can use the same number. I don't mind doing the work here, just wondering what everyone else thinks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Subscription: Outstanding Repository Maintenance: Evangelism
Issue Subscription Filter: Outstanding Repository Maintenance: Evangelism (29 issues) Subscriber: mavendevlist Key Summary MEV-389 org.openwfe:openwfe 1.7.0 broken pom http://jira.codehaus.org/browse/MEV-389 MEV-334 Stax POM points to an invalid XMLBeans dependency http://jira.codehaus.org/browse/MEV-334 MEV-384 velocity 1.4 dependencies are wrong http://jira.codehaus.org/browse/MEV-384 MEV-375 Relocate xpp to xpp3 http://jira.codehaus.org/browse/MEV-375 MEV-374 activeio 3.0 not deployed http://jira.codehaus.org/browse/MEV-374 MEV-373 activemq 4.0-M3 pom invalid http://jira.codehaus.org/browse/MEV-373 MEV-372 activemq 4.0rc2 is not deployed to ibiblio http://jira.codehaus.org/browse/MEV-372 MEV-364 Fix dependencies of common-lang 1.0 (add test scope for junit) http://jira.codehaus.org/browse/MEV-364 MEV-360 nanocontainer has invalid xpp3 dependency http://jira.codehaus.org/browse/MEV-360 MEV-361 picocontainer has invalid xpp3 dependency http://jira.codehaus.org/browse/MEV-361 MEV-352 Relocate cvslib in netbeans groupId to cvsclient in org.netbeans.lib http://jira.codehaus.org/browse/MEV-352 MEV-356 Missing dep on jboss-common in jbossmq-client jnp-client 4.0.2 http://jira.codehaus.org/browse/MEV-356 MEV-351 xmlc-xerces-2.2.7.1.jar is unnecessary and xmlc-apis.jar is required. http://jira.codehaus.org/browse/MEV-351 MEV-296 Activemq-core (and other activemq projects) 3.2.1 have unexpanded variables http://jira.codehaus.org/browse/MEV-296 MEV-326 Spring 2.0 M2 is missing a POM http://jira.codehaus.org/browse/MEV-326 MEV-337 OJB 1.0.4 has a number of dependencies that should be optional http://jira.codehaus.org/browse/MEV-337 MEV-330 WebWork 2.2.1 POM should list FreeMarker as a dependency since it's required for plain ol' JSPs http://jira.codehaus.org/browse/MEV-330 MEV-325 Description of jaxb-api 1.0.1 is wrong http://jira.codehaus.org/browse/MEV-325 MEV-313 publish seperate spring POM's for seperate dependencies http://jira.codehaus.org/browse/MEV-313 MEV-277 More Spring Dependencies Should be Optional http://jira.codehaus.org/browse/MEV-277 MEV-320 Hibernate 3.1.x POMs pull in Sun jars http://jira.codehaus.org/browse/MEV-320 MEV-201 should have dependency on org.relaxngdatatype.relaxngDatatype http://jira.codehaus.org/browse/MEV-201 MEV-173 xmlpull JARs exist in two different places on ibiblio http://jira.codehaus.org/browse/MEV-173 MEV-48 openejb poms http://jira.codehaus.org/browse/MEV-48 MEV-45 Full list of poms that doesn't respect the m2 format http://jira.codehaus.org/browse/MEV-45 MEV-36 Exo POM(s) missing dependency versions http://jira.codehaus.org/browse/MEV-36 MEV-33 XOM POM references xercesImpl v.2.2.1 which does not exist in repo http://jira.codehaus.org/browse/MEV-33 MEV-31 XOM POM references xmlParserAPIs v2.6.1 which is not in the repo http://jira.codehaus.org/browse/MEV-31 MEV-20 clean up bad IDs in the repository http://jira.codehaus.org/browse/MEV-20 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: release-plugin enhancement
+1, for the next version. On the second one, I suggest allowing a choice of use for all and use for all that had the same original version in addition to the current user for this one only. - Brett Brian E. Fox wrote: All, I'd like to add the ability to specify the release version, next development iteration and tag base as parameters to the release plugin so that no interactivity is needed. 1st any objections? 2nd: For multimodule builds, release prompts for the versions for each module. Is this really needed? It seems like if someone is releasing a multimodule build as a single unit, shouldn't all the modules share the version number? If no, then I propose 1 of 2 solutions: if the version IS the same as the parent to begin with, then don't bother prompting. AND/OR if multiple modules are detected, prompt if we can use the same number. I don't mind doing the work here, just wondering what everyone else thinks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
