[jira] Created: (MRELEASE-203) support more than one release pattern via new goal release:branch
support more than one release pattern via new goal release:branch - Key: MRELEASE-203 URL: http://jira.codehaus.org/browse/MRELEASE-203 Project: Maven 2.x Release Plugin Issue Type: Improvement Affects Versions: 2.0-beta-4, 2.0-beta-3, 2.0-beta-5, 2.0 Environment: irrelevant Reporter: Joerg Buchberger - CURRENT BEHAVIOUR: maven currently seems to support only this one release pattern well: *_feature branches_* develop towards release in trunk; prepare it by tagging, then release from that tag; continue for next iteration in trunk (+pom version tags are nicely updated+), while some or most features are done in branches - DESIRABLE IMPROVEMENT: alternative patterns or customizations such as *_release branches_* should be available: develop features in trunk and rarely use feature branches; begin release phase by branching, then work towards release in branch, while continuing for next iteration in trunk (+currently pom version tag hell, when doing this manually+); prepare by tagging from branch, then release from tag this could be achieved by offering a new goal release:branch, that creates a branch from trunk, updates *the trunk* poms for next iteration and stores some properties in the branch, so that upon release:prepare from *the branch*, the user can opt out preparations for next iteration on the branch - loosely related to following issues: -- [branch instead of tag|http://jira.codehaus.org/browse/MRELEASE-179] -- [branch during prepare|http://jira.codehaus.org/browse/MRELEASE-170] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1209) need copy-projects additionally to add-project
need copy-projects additionally to add-project -- Key: CONTINUUM-1209 URL: http://jira.codehaus.org/browse/CONTINUUM-1209 Project: Continuum Issue Type: Improvement Affects Versions: 1.0.3, 1.1-alpha-1, 1.1-alpha-2, 1.1-alpha-#, Future Environment: irrelevant Reporter: Joerg Buchberger once all projects from some scm-trunk are setup, it's later on desirable to have a bulk operation to copy some of the existing projects in one go; this could be done by prompting the user for two options: a *prefix*, that is prepended to the names of the copied projects - and *scm*, that can change the scm-urls of the copied projects from trunk to specified branch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-203) support more than one release pattern via new goal release:branch
[ http://jira.codehaus.org/browse/MRELEASE-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90245 ] Joerg Buchberger commented on MRELEASE-203: --- - WORKAROUND: specify version only in root POM to avoid version tag adaption hell, because only one version tag needs to be incremented to prepare for next iteration > support more than one release pattern via new goal release:branch > - > > Key: MRELEASE-203 > URL: http://jira.codehaus.org/browse/MRELEASE-203 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-3, 2.0-beta-4, 2.0-beta-5, 2.0 > Environment: irrelevant >Reporter: Joerg Buchberger > > - CURRENT BEHAVIOUR: > maven currently seems to support only this one release pattern well: > *_feature branches_* > develop towards release in trunk; prepare it by tagging, then release from > that tag; continue for next iteration in trunk (+pom version tags are nicely > updated+), while some or most features are done in branches > - DESIRABLE IMPROVEMENT: > alternative patterns or customizations such as *_release branches_* should be > available: > develop features in trunk and rarely use feature branches; begin release > phase by branching, then work towards release in branch, while continuing for > next iteration in trunk (+currently pom version tag hell, when doing this > manually+); prepare by tagging from branch, then release from tag > this could be achieved by offering a new goal release:branch, that creates a > branch from trunk, updates *the trunk* poms for next iteration and stores > some properties in the branch, so that upon release:prepare from *the > branch*, the user can opt out preparations for next iteration on the branch > - loosely related to following issues: > -- [branch instead of tag|http://jira.codehaus.org/browse/MRELEASE-179] > -- [branch during prepare|http://jira.codehaus.org/browse/MRELEASE-170] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-152) Write .classpath with ordered dependencies [incl. Patch]
[ http://jira.codehaus.org/browse/MECLIPSE-152?page=comments#action_85342 ] Joerg Buchberger commented on MECLIPSE-152: --- As for the convenience of finding particular dependencies in eclipse build path more quickly, I'd suggest the following SORT OPTIONS: - by artifactId - by groupId However, I consider it more important to have the option to control CLASSPATH ORDER by sorting classpath entries according to the order of dependencies as written in the POM. At least for runtime dependencies. This would make it unnecessary to manually adjust classpath order in eclipse and reduce time for supporting developers who are unexperienced or new to the project... > Write .classpath with ordered dependencies [incl. Patch] > > > Key: MECLIPSE-152 > URL: http://jira.codehaus.org/browse/MECLIPSE-152 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement >Affects Versions: 2.2 > Environment: Windowz XP, eclipse 3.2 >Reporter: Holger Hoffstätte > Assigned To: Kenney Westerhof > Fix For: 2.4 > > Attachments: orderDependencies.patch, orderDependencies.patch > > > Related to my comment in MNG-1412 - I decided to take a quick stab at the > eclipse plugin and voilá! Ordered dependencies in the written .classpath. > This is only a prototype (my first attempt at maven development) and could > serve as basis for other orderings like groupId, transitive nearness etc. > Initially I wanted to make IdeDependency comparable (similar to MECLIPSE-150 > which added proper equals) but having multiple Comparators seemed better for > extensibility. > It worked right away, does exactly what I want (ordering by artifactId) and > has minimal impact. I am not familiar with the maven codebase so I hope this > is the right place to do the actual ordering before writing; obviously it > should observe a property like -DorderDependencies=artifactId or something > similar. The patch is against svn r425750 (2006-08-30). Currently no testcase > but if someone tells me how to add/read an orderDependencies property I might > add one. > Comments welcome. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
