[jira] Commented: (MNG-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146373#action_146373 ] Eric Brown commented on MNG-624: Hi Ralph, Thanks for the feedback. I'm glad it was looked at and progress is being made. And it would be great if it could be done cleaner than I did it. Being the most watched and voted on issue in jira, I'd encourage the maven team to find a solution sooner than later even if it means a less than perfectly elegant solution. > automatic parent versioning > --- > > Key: MNG-624 > URL: http://jira.codehaus.org/browse/MNG-624 > Project: Maven 2 > Issue Type: Improvement > Components: Inheritance and Interpolation >Reporter: Brett Porter >Assignee: Ralph Goers >Priority: Blocker > Fix For: 3.0 > > Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see > MNG-521) > currently, you have to specify the parent version when extending which makes > a project stand alone very easily, but has the drawback of being a > maintainance problem when you start development on a new version. Tools can > help, but it would be nice not to have to rely on them. > One alternative is to allow the parent version to be omitted, and when it is > it is assumed you want the latest. The parent is used from the reactor or the > universal source directory. IT may also be read from a LATEST in the > repository though this is contentious - it may be better to simply fail in > that environment and require builds be in a known checkout structure for > building individual projects. > This also introduces the need for tool support to populate the version on > release and deployment for reproducibility. -- 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: (MNG-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146365#action_146365 ] Eric Brown commented on MNG-624: I recognize that the patch I submitted is now out of date - it was against 2.0. And it has 16 integration tests! I was assured both here and on the mailing list that if there were sufficient integration tests, the patch would be taken, but it never has been. This was (still is?) the most watched & voted maven issue in jira. Honestly, I've lost interest in maven, but I thought I'd point out what might have been missed in all the comments since I submitted a patch to fix this issue. > automatic parent versioning > --- > > Key: MNG-624 > URL: http://jira.codehaus.org/browse/MNG-624 > Project: Maven 2 > Issue Type: Improvement > Components: Inheritance and Interpolation >Reporter: Brett Porter >Assignee: Ralph Goers >Priority: Blocker > Fix For: 3.0 > > Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see > MNG-521) > currently, you have to specify the parent version when extending which makes > a project stand alone very easily, but has the drawback of being a > maintainance problem when you start development on a new version. Tools can > help, but it would be nice not to have to rely on them. > One alternative is to allow the parent version to be omitted, and when it is > it is assumed you want the latest. The parent is used from the reactor or the > universal source directory. IT may also be read from a LATEST in the > repository though this is contentious - it may be better to simply fail in > that environment and require builds be in a known checkout structure for > building individual projects. > This also introduces the need for tool support to populate the version on > release and deployment for reproducibility. -- 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: (MNG-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88281 ] Eric Brown commented on MNG-624: Yes, all the integration tests run. Both the ones still attached to the maven-2.0.x branch and the ones in core-integration-tests. trunk wasn't working for me at the time I started this, so I did it against 2.0.x. I should have dug a bit further I suppose. If you want to open a new issue for this for 2.1, I can look at it when I get a chance, but it'd be great to get this in 2.0.6. > automatic parent versioning > --- > > Key: MNG-624 > URL: http://jira.codehaus.org/browse/MNG-624 > Project: Maven 2 > Issue Type: Improvement > Components: Inheritance and Interpolation >Reporter: Brett Porter > Assigned To: Brett Porter >Priority: Blocker > Fix For: 2.1.x > > Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see > MNG-521) > currently, you have to specify the parent version when extending which makes > a project stand alone very easily, but has the drawback of being a > maintainance problem when you start development on a new version. Tools can > help, but it would be nice not to have to rely on them. > One alternative is to allow the parent version to be omitted, and when it is > it is assumed you want the latest. The parent is used from the reactor or the > universal source directory. IT may also be read from a LATEST in the > repository though this is contentious - it may be better to simply fail in > that environment and require builds be in a known checkout structure for > building individual projects. > This also introduces the need for tool support to populate the version on > release and deployment for reproducibility. -- 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] Updated: (MNG-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Brown updated MNG-624: --- Attachment: MNG-624-tests.tar.gz MNG-624-maven-2.0.x-r507648.patch The attached patch and 16 integration tests fixes this issue by allowing the following: * Variable expansion works in the section of pom-s for version, groupId and artifactId * The same elements are all optional. At the extreme, this means most times will work. There is a rule for this to work, however. You must have enough of your development tree on disk that maven can walk the directories ( still works) to resolve variables and/or find inferred elements that are missing. Implementation Notes: * All existing and 16 new integration tests are passing. The code-path and what's going on really doesn't change for existing projects that have explicit sections. * It passes my complex 202-module project. * Most of what is going on is that maven now guesses and does re-interpolation later to verify (and/or) continue its inferencing. I call it "expansion" in a few places because it is more than just interpolation, profiles also have to be expanded - but the code was all there, I just refactored slightly. * When pom-s are installed and deployed, if any part of their specification was inferred or re-expanded, it is no longer possible to simply copy the source pom.xml unmodified to the local and/or remote repository. Doing so would make it impossible to build from somewhere other than "trunk" as when building from the middle of a tree, artifacts that are elsewhere in sibling or cousin nodes of the tree are actually fetched from the repository and their parents in-turn from the repository as well. But the parents couldn't be found in the repository because the parent section was missing! So maven now detects that the parent section was missing or needed expansion due to the presence of variables and makes sure the parent section is present before writing a pom to a repository. I'm not fantastically pleased with this implementation for a couple reasons: (though it works and my vote would be to accept it as is - I doubt it is the worst ugliness in the code) ** The pom in the repository looses all comments and formatting from the original. ** The way I hooked it into the artifact and suck it back out again when installing and deploying pom-s just felt hackish. Though I really don't see any other way to pass the needed information around as this information obviously was not intended to be passed between the maven-project and maven-artifact modules in the architecture. BTW, The reason I spent so much time on this is because I have 202 modules and release twice / month. My svn logs are littered with crap from changing version information in my 202 pom-s and I find it very annoying. Maven is a great tool, but I've never worked with or built a build system where I had to keep version information in so many places. I know there are tools to manage it, but it is still uglier than the patch I've submitted here IMO. YMMV :) > automatic parent versioning > --- > > Key: MNG-624 > URL: http://jira.codehaus.org/browse/MNG-624 > Project: Maven 2 > Issue Type: Improvement > Components: Inheritance and Interpolation >Reporter: Brett Porter > Assigned To: Brett Porter >Priority: Blocker > Fix For: 2.1.x > > Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see > MNG-521) > currently, you have to specify the parent version when extending which makes > a project stand alone very easily, but has the drawback of being a > maintainance problem when you start development on a new version. Tools can > help, but it would be nice not to have to rely on them. > One alternative is to allow the parent version to be omitted, and when it is > it is assumed you want the latest. The parent is used from the reactor or the > universal source directory. IT may also be read from a LATEST in the > repository though this is contentious - it may be better to simply fail in > that environment and require builds be in a known checkout structure for > building individual projects. > This also introduces the need for tool support to populate the version on > release and deployment for reproducibility. -- 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] Updated: (MNG-1412) dependency sorting in classpath
[ http://jira.codehaus.org/browse/MNG-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Brown updated MNG-1412: Attachment: MNG-1412-maven-2.0.x-r507746.patch Note that r430569 (committed into 2.0.5) does fix some of the related issues here. In fact, I'm not even completely clear on all the changes proposed in Marten's patches other than that they can't break things (just using Linked versions of HashMap and HashSet) and common-sense dictates they make sense in several places. My strong vote would be to commit this patch as I don't see anyway it could break anything. Tests would be nice, but given the random nature of items returned from non-Linked HashSet and HashMap collections, it is hard to validate that the tests would fail without these changes. Tests would be nice in the future to ensure things don't break again. This is an update of the patches Marten submitted against the maven-2.0.x post 2.0.5. I've removed a few changes where maps and sets were never converted collections or passed outside their local scope. Plus r430569 shrinks it a bit too. Hopefully that makes it smaller and easier to code review. Thanks to Marten for the initial work on these patches. > dependency sorting in classpath > --- > > Key: MNG-1412 > URL: http://jira.codehaus.org/browse/MNG-1412 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Mark Hobson > Assigned To: fabrizio giustina > Fix For: 2.1.x > > Attachments: artifact-order_maven-artifact-manager.txt, > artifact-order_maven-artifact.txt, artifact-order_maven-project.txt, > MNG-1412-maven-2.0.x-r507746.patch > > > The .classpath file entries should be ordered by nearest transitiveness (if > that's a word). > For example, I have project A that depends on B that depends on C. The > classpath for A is generated in the order C, B. Ideally the classpath should > be in order of how near they are to the project, i.e. B, C. -- 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: (MNG-1994) Execution order of child plugins is arbitrary if inheritance is involved
[ http://jira.codehaus.org/browse/MNG-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_87644 ] Eric Brown commented on MNG-1994: - This bug was inadvertently fixed by jdcasey in r425921 when fixing MNG-1891. Thus, it is fixed in 2.0.5. The attached patch is no longer relevant as several changes between 2.0.4 and 2.0.5 were merges from trunk and significantly altered the structure of the code. I code reviewed the 2.0.5 implementation and believe it fixes this problem. Given the nature of the bug -- arbitrary -- I don't think there is a reasonable way to write unit or integration tests. Suggest closing this bug as fixed. > Execution order of child plugins is arbitrary if inheritance is involved > > > Key: MNG-1994 > URL: http://jira.codehaus.org/browse/MNG-1994 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.1 >Reporter: John Didion >Priority: Critical > Fix For: 2.1.x > > Attachments: mergePluginLists.txt > > > This is related to MNG-1499, but different, and, in my opinion, equally > important. It makes sense that the order of plugin execution should be the > same as it appears in the POM. For example, I have two plugins: one that > generates a batch file and one that executes it. These plugins must run in > order or the build will fail. However, the current implementation of > ModelUtils.mergePluginLists does not respect the order of child plugins. > There is also a seperate bug in that the assembledPlugins map is being > checked for the presence of child plugins before adding them to the > mergedPlugins list, but nothing is ever added to assembledPlugins. So if a > plugin exists in a parent and a child, it will end up appearing twice in the > child's plugin list. > I have re-written this method to fix both these problems. See attached. -- 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: (MNG-1468) best practices: version management in multi project builds
[ http://jira.codehaus.org/browse/MNG-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_87525 ] Eric Brown commented on MNG-1468: - For 2.0.x, this is defined by MNG-521. For 2.1, this is still being defined in MNG-624. > best practices: version management in multi project builds > -- > > Key: MNG-1468 > URL: http://jira.codehaus.org/browse/MNG-1468 > Project: Maven 2 > Issue Type: Bug > Components: Design, Patterns & Best Practices >Reporter: Jason van Zyl >Priority: Trivial > Fix For: 2.0.x > > > How to manage versions from a single place in a multi project build. > The reference in the wiki can be found here: > http://docs.codehaus.org/display/MAVEN/Maven+Best+Practices -- 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: (MJAVADOC-72) Aggregating javadocs doesn't work
[ http://jira.codehaus.org/browse/MJAVADOC-72?page=comments#action_68957 ] Eric Brown commented on MJAVADOC-72: I'm experiencing this issue as well. I'm not sure how to upgrade to 2.0-final. I tried adding 2.0-final inside , but it still fails. I get: GroupId: org.apache.maven.plugins ArtifactId: maven-javadoc-pluginVersion: 2.0-final Reason: Unable to download the artifact from any repository org.apache.maven.plugins:maven-javadoc-plugin:pom:2.0-final Doesn't sound like the solution anyway. > Aggregating javadocs doesn't work > - > > Key: MJAVADOC-72 > URL: http://jira.codehaus.org/browse/MJAVADOC-72 > Project: Maven 2.x Javadoc Plugin > Type: Bug > Versions: 2.0 > Environment: WinXP SP2 > cygwin 1.5.19 > maven 2.0.4 > jdk 1.5.0_06 > javadoc-plugin 2.0 final > latest released plugins > Reporter: Bugittaa Pahasti > > > When I define true to javadoc plugin configuration in > parent pom, javadoc generation doesn't work from the parent (all other > configuration options are default). If run under individual components, > javadoc is generated without problems. It seems that the child dependencies > aren't resolved: > Embedded error: Exit code: 1 - > c:/code/apps/project/common/src/main/java/com/company/AbstractLogEnabled.java:3: > package org.apache.log4j does not exist > import org.apache.log4j.Logger; > c:/code/apps/component/common-test/src/main/java/com/company/unittest/AbstractDatasourceEnabledTestCase.java:11: > package org.apache.commons.dbcp does not exist > import org.apache.commons.dbcp.BasicDataSource; > And lot more similar errors. > Additionally, there are a huge number of ClassCastExceptions from javadoc. > java.lang.ClassCastException: com.sun.tools.javadoc.ClassDocImpl > at > com.sun.tools.javadoc.AnnotationDescImpl.annotationType(AnnotationDescImpl.java:46) > at > com.sun.tools.doclets.internal.toolkit.util.Util.isDeprecated(Util.java:804) > at > com.sun.tools.doclets.formats.html.TagletWriterImpl.deprecatedTagOutput(TagletWriterImpl.java:85) > at > com.sun.tools.doclets.internal.toolkit.taglets.DeprecatedTaglet.getTagletOutput(DeprecatedTaglet.java:40) > at > com.sun.tools.doclets.formats.html.MethodWriterImpl.writeDeprecated(MethodWriterImpl.java:166) > at > com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.buildDeprecationInfo(MethodBuilder.java:183) > at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.invokeMethod(MethodBuilder.java:109) > at > com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:90) > at > com.sun.tools.doclets.internal.toolkit.builders.AbstractMemberBuilder.build(AbstractMemberBuilder.java:56) > at > com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.buildMethodDoc(MethodBuilder.java:150) > at sun.reflect.GeneratedMethodAccessor36.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.invokeMethod(MethodBuilder.java:109) > at > com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:90) > at > com.sun.tools.doclets.internal.toolkit.builders.AbstractMemberBuilder.build(AbstractMemberBuilder.java:56) > at > com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.buildMethodDetails(ClassBuilder.java:322) > at sun.reflect.GeneratedMethodAccessor33.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.invokeMethod(ClassBuilder.java:101) > at > com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:90) > at > com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.buildClassDoc(ClassBuilder.java:124) > at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.invokeMethod(ClassBuilder.java:101) > at > com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:90) > at > com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.build(ClassBuilder.java:108) > at > com.sun.tools.doclets.formats.html.HtmlDoclet.generateClassFiles(HtmlDoclet.java:155) > at
