[jira] (MNG-5102) Mixin POM fragments
[ https://jira.codehaus.org/browse/MNG-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360887#comment-360887 ] Christoph Henrici commented on MNG-5102: Unfortunately does e2Eclipse not work with https://github.com/repaint-io/maven-tiles. It simply ignores it. Exactly http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-pom-best-practice.html is simply not enough. Dependency Management is almost more urgent. > Mixin POM fragments > --- > > Key: MNG-5102 > URL: https://jira.codehaus.org/browse/MNG-5102 > Project: Maven > Issue Type: Wish > Components: FDPFC, POM >Affects Versions: 2.2.1 >Reporter: Anthony Whitford > Fix For: Issues to be reviewed for 4.x > > Attachments: daddy3.zip, maven-tiles.zip > > > I am looking for a way to _mixin_ POM fragments into POMs. Note that this > idea is beyond parent pom inheritance because all projects inherit from a > corporate parent pom. The problem that I am running into is that the > corporate parent pom is turning into an _"everything but the kitchen sink"_ > POM and I'd like to dissect it into POM fragments relevant for individual > modules. > For example, I would like to have mixins for: > * Java projects (that include static code analysis plugins, javadoc, etc.) > * JPA projects (that include DDL generation) > * Flex projects (that include flexmojos, asdoc, etc.) > * Scala projects (that include the maven-scala-compiler plugin, scaladoc, > etc.) > * JavaScript projects (that include build plugins like > maven-yuicompressor-plugin with jslint and compress goals) > Hopefully, you get the idea. Without the ability to factor pom logic, we are > left with two symptoms: > # copy/paste duplication > # complex _"it does it all"_ parent poms (which slow down builds because more > plugins are loaded even though they might not do anything material) > Note that a project may include multiple mixins as I could have a project > that contains Java code, Scala code, and JavaScript. > Another idea is that the mixins could be parameterized, so that the ultimate > pom can be customized based on the parameters (like tokens). > I recall reading about Mixins coming in Maven 3.1, but could not find any > such issue to watch, so am creating one. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5102) Mixin POM fragments
[ https://jira.codehaus.org/browse/MNG-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354470#comment-354470 ] Christoph Henrici edited comment on MNG-5102 at 10/16/14 4:52 AM: -- great, https://github.com/repaint-io/maven-tiles certainly looks like what we need i ll try this ..great thx for sharing!! was (Author: chenrici): great, https://github.com/repaint-io/maven-tiles certainly looks like what we need i ll try this ..thx!! > Mixin POM fragments > --- > > Key: MNG-5102 > URL: https://jira.codehaus.org/browse/MNG-5102 > Project: Maven > Issue Type: Wish > Components: FDPFC, POM >Affects Versions: 2.2.1 >Reporter: Anthony Whitford > Fix For: Issues to be reviewed for 4.x > > Attachments: daddy3.zip, maven-tiles.zip > > > I am looking for a way to _mixin_ POM fragments into POMs. Note that this > idea is beyond parent pom inheritance because all projects inherit from a > corporate parent pom. The problem that I am running into is that the > corporate parent pom is turning into an _"everything but the kitchen sink"_ > POM and I'd like to dissect it into POM fragments relevant for individual > modules. > For example, I would like to have mixins for: > * Java projects (that include static code analysis plugins, javadoc, etc.) > * JPA projects (that include DDL generation) > * Flex projects (that include flexmojos, asdoc, etc.) > * Scala projects (that include the maven-scala-compiler plugin, scaladoc, > etc.) > * JavaScript projects (that include build plugins like > maven-yuicompressor-plugin with jslint and compress goals) > Hopefully, you get the idea. Without the ability to factor pom logic, we are > left with two symptoms: > # copy/paste duplication > # complex _"it does it all"_ parent poms (which slow down builds because more > plugins are loaded even though they might not do anything material) > Note that a project may include multiple mixins as I could have a project > that contains Java code, Scala code, and JavaScript. > Another idea is that the mixins could be parameterized, so that the ultimate > pom can be customized based on the parameters (like tokens). > I recall reading about Mixins coming in Maven 3.1, but could not find any > such issue to watch, so am creating one. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5102) Mixin POM fragments
[ https://jira.codehaus.org/browse/MNG-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354470#comment-354470 ] Christoph Henrici commented on MNG-5102: great, https://github.com/repaint-io/maven-tiles certainly looks like what we need i ll try this ..thx!! > Mixin POM fragments > --- > > Key: MNG-5102 > URL: https://jira.codehaus.org/browse/MNG-5102 > Project: Maven > Issue Type: Wish > Components: FDPFC, POM >Affects Versions: 2.2.1 >Reporter: Anthony Whitford > Fix For: Issues to be reviewed for 4.x > > Attachments: daddy3.zip, maven-tiles.zip > > > I am looking for a way to _mixin_ POM fragments into POMs. Note that this > idea is beyond parent pom inheritance because all projects inherit from a > corporate parent pom. The problem that I am running into is that the > corporate parent pom is turning into an _"everything but the kitchen sink"_ > POM and I'd like to dissect it into POM fragments relevant for individual > modules. > For example, I would like to have mixins for: > * Java projects (that include static code analysis plugins, javadoc, etc.) > * JPA projects (that include DDL generation) > * Flex projects (that include flexmojos, asdoc, etc.) > * Scala projects (that include the maven-scala-compiler plugin, scaladoc, > etc.) > * JavaScript projects (that include build plugins like > maven-yuicompressor-plugin with jslint and compress goals) > Hopefully, you get the idea. Without the ability to factor pom logic, we are > left with two symptoms: > # copy/paste duplication > # complex _"it does it all"_ parent poms (which slow down builds because more > plugins are loaded even though they might not do anything material) > Note that a project may include multiple mixins as I could have a project > that contains Java code, Scala code, and JavaScript. > Another idea is that the mixins could be parameterized, so that the ultimate > pom can be customized based on the parameters (like tokens). > I recall reading about Mixins coming in Maven 3.1, but could not find any > such issue to watch, so am creating one. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-529) Provide a way to exclude optional dependencies of a module from the assembly
[ https://jira.codehaus.org/browse/MASSEMBLY-529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342417#comment-342417 ] Christoph Henrici edited comment on MASSEMBLY-529 at 3/5/14 7:27 AM: - " I would even go as far as suggesting than optional dependencies should not get pulled in per default." 100% agreed. From my point of view it yields the plugin even useless at least in certain usage szenarios... optional means as i understand: a dependency which should NOT be included transitively by default, but only when explicitly included as Dependency. was (Author: chenrici): " I would even go as far as suggesting than optional dependencies should not get pulled in per default." 100% agreed. From my point of view it yields the plugin even useless... optional means as i understand: a dependency which should NOT be included transitively by default, but only when explicitly included as Dependency. > Provide a way to exclude optional dependencies of a module from the assembly > > > Key: MASSEMBLY-529 > URL: https://jira.codehaus.org/browse/MASSEMBLY-529 > Project: Maven Assembly Plugin > Issue Type: Improvement > Components: moduleSet >Affects Versions: 2.2-beta-5, 2.2 >Reporter: Oleg Kalnichevski > > Presently optional dependencies of modules in a module set always get pulled > in and there appears to be no way to exclude all optional dependencies other > than explicitly excluding them one by on -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-529) Provide a way to exclude optional dependencies of a module from the assembly
[ https://jira.codehaus.org/browse/MASSEMBLY-529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342417#comment-342417 ] Christoph Henrici commented on MASSEMBLY-529: - " I would even go as far as suggesting than optional dependencies should not get pulled in per default." 100% agreed. From my point of view it yields the plugin even useless... optional means as i understand: a dependency which should NOT be included transitively by default, but only when explicitly included as Dependency. > Provide a way to exclude optional dependencies of a module from the assembly > > > Key: MASSEMBLY-529 > URL: https://jira.codehaus.org/browse/MASSEMBLY-529 > Project: Maven Assembly Plugin > Issue Type: Improvement > Components: moduleSet >Affects Versions: 2.2-beta-5, 2.2 >Reporter: Oleg Kalnichevski > > Presently optional dependencies of modules in a module set always get pulled > in and there appears to be no way to exclude all optional dependencies other > than explicitly excluding them one by on -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-1977) Global dependency exclusions
[ https://jira.codehaus.org/browse/MNG-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=338250#comment-338250 ] Christoph Henrici edited comment on MNG-1977 at 1/8/14 9:19 AM: A real world problem needs a solution. Is there any real intention to adress this? was (Author: chenrici): A real world problem needs a solution. > Global dependency exclusions > > > Key: MNG-1977 > URL: https://jira.codehaus.org/browse/MNG-1977 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: POM >Reporter: Kees de Kooter > Fix For: Issues to be reviewed for 4.x > > Attachments: global_excls_it-test_v2.patch, > global_excls_it-test_v3.patch, global_excls_maven3_v2.patch, > global_excls_maven3_v3.patch > > > I depend on some libraries, which in turn depend on something > (which in turn depend on something) that I don't want, because I declare > some other artifact in my pom.xml. > A concrete example: I don't want that the artifact "xerces" is imported in > my project because I declare to depend on "xercesImpl" which ships newer > libraries but with the same namespaces. > I guess I would need an "exclude transitive dependency at all", either > globally or from this and that artifact. I saw the tag, but it > forces me to be very verbose and have exact control on what is required by a > dependency. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-1977) Global dependency exclusions
[ https://jira.codehaus.org/browse/MNG-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=338250#comment-338250 ] Christoph Henrici commented on MNG-1977: A real world problem needs a solution. > Global dependency exclusions > > > Key: MNG-1977 > URL: https://jira.codehaus.org/browse/MNG-1977 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: POM >Reporter: Kees de Kooter > Fix For: Issues to be reviewed for 4.x > > Attachments: global_excls_it-test_v2.patch, > global_excls_it-test_v3.patch, global_excls_maven3_v2.patch, > global_excls_maven3_v3.patch > > > I depend on some libraries, which in turn depend on something > (which in turn depend on something) that I don't want, because I declare > some other artifact in my pom.xml. > A concrete example: I don't want that the artifact "xerces" is imported in > my project because I declare to depend on "xercesImpl" which ships newer > libraries but with the same namespaces. > I guess I would need an "exclude transitive dependency at all", either > globally or from this and that artifact. I saw the tag, but it > forces me to be very verbose and have exact control on what is required by a > dependency. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
