Details

    • Complexity:
      Intermediate
    • Number of attachments :
      2

      Description

      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:

      1. copy/paste duplication
      2. 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.

        Issue Links

          Activity

          Hide
          Paul Benedict added a comment - - edited

          Use "import" scope; that's how you can define a POM for particular types of projects (see issue description) and then add those dependencies to your project. I would say the "import" scope is the Mixin you want.

          http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

          Show
          Paul Benedict added a comment - - edited Use "import" scope; that's how you can define a POM for particular types of projects (see issue description) and then add those dependencies to your project. I would say the "import" scope is the Mixin you want. http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
          Hide
          Maurizio Pillitu added a comment -

          @Tony

          • Yes, I still use it sometimes, but being a customisation on the Maven distro (and not a plugin) it is really hard to distribute and build collaboration around it
          • No improvements have been made so far
          • As above, no changes were made, but probably the biggest issue right now is find a way to implement it as a Maven plugin
          • I'm in, will create a github project in the weekend

          @Paul, the Mixin feature aims to inherit <build> behaviours, not (only) dependencies. Read more here http://stackoverflow.com/questions/2456375/how-to-use-maven-3-mixins

          Show
          Maurizio Pillitu added a comment - @Tony Yes, I still use it sometimes, but being a customisation on the Maven distro (and not a plugin) it is really hard to distribute and build collaboration around it No improvements have been made so far As above, no changes were made, but probably the biggest issue right now is find a way to implement it as a Maven plugin I'm in, will create a github project in the weekend @Paul, the Mixin feature aims to inherit <build> behaviours, not (only) dependencies. Read more here http://stackoverflow.com/questions/2456375/how-to-use-maven-3-mixins
          Hide
          Tony Lampada added a comment -

          Dunno.
          IMO, import scope was a very important step for maven as it is a move towards the "favor composition over inheritance" design principle for poms.
          However that limits using composition for project dependencies.

          There's nothing that import scopes can do for me if I want to make a reusable piece of build behaviour, like for example, using the maven-dependency-plugin to unpack a few dependencies during the proccess-resources phase.

          Please see

          Show
          Tony Lampada added a comment - Dunno. IMO, import scope was a very important step for maven as it is a move towards the "favor composition over inheritance" design principle for poms. However that limits using composition for project dependencies. There's nothing that import scopes can do for me if I want to make a reusable piece of build behaviour , like for example, using the maven-dependency-plugin to unpack a few dependencies during the proccess-resources phase. Please see MNG-5127 http://stackoverflow.com/questions/11749375/import-maven-plugin-configuration-by-composition-rather-than-inheritance-can-it http://stackoverflow.com/questions/10245621/how-to-inherit-from-a-multimodule-maven-project-with-all-its-goodies
          Hide
          Tony Lampada added a comment -

          Now that maven-tiles has been successfully packed as an open source project,
          I made a small project that demonstrates how, using maven-tiles, one can get the desired mixin behaviour.

          See attached daddy3.zip

          Thanks Maurizio!

          Show
          Tony Lampada added a comment - Now that maven-tiles has been successfully packed as an open source project , I made a small project that demonstrates how, using maven-tiles, one can get the desired mixin behaviour. See attached daddy3.zip Thanks Maurizio!
          Hide
          Roman Arkadijovych Muntyanu added a comment -

          If I'm not mistaken, dependencies mix-ins are implemented as "Grouping Dependencies" ( see http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-pom-best-practice.html ).
          Is it possible to extend "pom" packaging behaviour beyond dependencies-only? (so that properties, plugin and dependency management sections also became part of the pom depending on mix-in)

          Show
          Roman Arkadijovych Muntyanu added a comment - If I'm not mistaken, dependencies mix-ins are implemented as "Grouping Dependencies" ( see http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-pom-best-practice.html ). Is it possible to extend "pom" packaging behaviour beyond dependencies-only? (so that properties, plugin and dependency management sections also became part of the pom depending on mix-in)

            People

            • Assignee:
              Unassigned
              Reporter:
              Anthony Whitford
            • Votes:
              50 Vote for this issue
              Watchers:
              44 Start watching this issue

              Dates

              • Created:
                Updated: