You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Aaron Digulla <di...@hepe.com> on 2007/01/30 14:44:38 UTC
Extending the notion of "parent pom"
Hello,
My POMs have two parents: The one in the parent directory and the one
which supplies them with the build defaults.
Out of necessity, they can't be the same POM. The ../pom.xml just
specifies the build order. The POM specified with the <parent> element
supplies the build config (for example for webapps or for code
libraries).
Usually, a web project in our company contains a code and a web part,
so I need two <parent> POMs (one for libraries and one for webapps)
and I need a POM which says "build the library, then build the webapp".
This means, I'm fighting with the limitations of Maven's parent POM
model. Some plugins like the site plugin are confused how to build the
aggregated site structure.
I see three ways to improve the situation:
- Support <xi:include>.
Pro: It's a W3C standard (some will say that's a drawback :-)
Con: It doesn't really fit into the XML inheritance model of Maven.
When will variables be resolved? Before or after the includes? Or
somewhere inbetween? How can we debug this?
- Allow multiple <parent> elements
Pro: People are already used to the parent element
Con: Humans have more than one parent (father and mother) and we all
know how confusing it is when they can't agree about something. So
this would call for a smart conflict resolution strategy which a
developer can understand without help.
The current element will probably have to be extended with new attributes.
- A new <mixin> element
The element refers to a POM artifact like the <parent> element but I
would also like it to be able to select deeper in XML tree of a POM:
* "I'd like to copy the configuration for the maven-deploy-plugin but
overwrite the version element"
* "Copy the report config and merge it with the definitions in the
current POM"
* "Copy the config for the cobertura plugin except for the include
element in the configuration"
Pro: New element allows new semantic
Con: This will be a pretty complex element, especially if it can copy
conditionally. The syntax should be simple enough so people don't
swamp the Maven lists with questions but powerful enough to actually
solve the limitations of the current inheritance system.
We might be tempted to support a copy operator based on XPath. I think
this is a bad idea because the XPath syntax is really very complex and
can be quite confusing.
- Allow to include "macro POMs". A macro POM defines common building
blocks which can be extended as we're used to or configured via
paramaters:
<macros>
<include>
<groupId>...</groupId>
<artefactId>...</artefactId>
<version>...</version>
</include>
<include>
<file>....</file>
</include>
<macro>
<id>compile</id>
<parameter><name>version</name><default>2.0.2</default></parameter>
<parameter><name>source</name><default>1.4</default></parameter>
<parameter><name>target</name><default>@{source}</default></parameter>
<body>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>@{version}</version>
<configuration>
<source>@{source}</source>
<target>@{target}</target>
</configuration>
</plugin>
</body>
</macro>
</macros>
<build>
<plugins>
<macro-ref>
<id>compile</id>
<parameter><name>version</name><value>2.1</value></parameter>
<body>
<plugin>
<configuration>
<clean />
<source>1.5</source>
</configuration>
</plugin>
</body>
</macro-ref>
</plugins>
</build>
Some comments:
- The "<clean />" element deletes anything inherited below the current
parent element. In the example, there is no target element in the
effective POM anymore.
- Includes overwrite in the order in which they are specified. So the
macros defined in the artefact are overwritten by those in the file
and any "compile" macro will be overwritten with the local definition.
Maybe inheritance merge should be supported here, too.
Comments?
--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.philmann-dark.de/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Extending the notion of "parent pom"
Posted by Aaron Digulla <di...@hepe.com>.
Quoting John Casey <ca...@gmail.com>:
> Do you have even more plugin configuration in this third parent POM? If not,
> why is it critical that the webapp/library projects can declare themselves
> to be children of this POM (in addition to the type-specific POMs)? If you
> do have more plugin configuration in this coordinating parent POM, why is it
> not maintained in the type-specific POMs, or even further up the chain in a
> common parent of those two parent POMs?
That's what I currently do and it confuses the site plugin. The site
plugin has to determine which projects are "children" or another. Here
is the directory tree:
root
+--parent-pom
+--library-pom
+--webapp-pom
+--lib1
+--p2
+--lib2
+--webapp2
POM inheritance:
parent-pom
+--library-pom
| +--lib1
| +--lib2
+--webapp-pom
| +--webapp2
+--p2
So when the site plugin builds "p2" does it have children or not? How
should it link to lib2 and webapp2? From the parent POM or the pom.xml
in the parent directory?
I think that other plugins are also affected because I see that Maven
is printing some messages when I have ../pom.xml and <parent> in a
project.
That sparked the idea of having mixins. With mixins, I could separate
the two trees cleanly.
Regards,
--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.philmann-dark.de/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Extending the notion of "parent pom"
Posted by Aaron Digulla <di...@hepe.com>.
John Casey wrote:
> That sparked the idea of having mixins. With mixins, I could separate
> the two trees cleanly.
>
> I'm still a little unclear on how mixins would be "cleaner" than two
> levels of inheritance. If multiple levels of inheritance confuses the
> site plugin, then that plugin needs to be fixed in some way. However, I
> don't think it's appropriate to address a problem that could be fixed
> via rearrangement of directory structures by instead introducing a
> massively complex new feature to Maven. It'd be a lot like replacing the
> engine in your car just so you can get a little more torque to turn a
> flat tire, rather than just fixing the tire.
I don't say that my problem can't be fixed by fixing the site plugin. I
say that it got me thinking if there is a bigger problem hiding
somewhere below all that.
Single parent inheritance is limited. It leads to a long line of parent
POMs because every time you find you need a feature in more than one
project, you have to inject a new level if you don't want to "pollute"
unrelated projects or if you can't (for example when you have to
configure a build plugin).
With mixins, I could have a single mixin file which configures all
plugins and all aspects of Maven I can think of in one place. In the
POMs, I could then use these superblocks as I see fit.
It's probably the extension of the Maven idea: Create powerful, smart
building blocks from which you can build your projects.
Regards,
--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Extending the notion of "parent pom"
Posted by John Casey <ca...@gmail.com>.
Hi Aaron,
While I can't say you're the first person I've heard mention mixins in
connection with Maven, I'd really like to hear more about the environment
you've put together.
For starters, you seem to have two "type-specific" POMs - one for webapps,
one for libraries - that presumably setup the plugin configurations for
each. But then, you also have another "coordinator" parent POM that I'm
assuming has the webapp- and library-project subdirectories listed as
modules.
Do you have even more plugin configuration in this third parent POM? If not,
why is it critical that the webapp/library projects can declare themselves
to be children of this POM (in addition to the type-specific POMs)? If you
do have more plugin configuration in this coordinating parent POM, why is it
not maintained in the type-specific POMs, or even further up the chain in a
common parent of those two parent POMs?
I definitely think there is a place for an externalizable standardized
plugin configuration that can be referenced in a chunk. However, knowing how
much of a mess profiles themselves can make when introduced into the build
(in terms of trying to intuit the effective project POM), I have severe
reservations about complicating this process even more. In particular, I'm
not convinced that your situation calls for something so drastic. Can you
shed some more light on it for me?
-john
On 1/30/07, Aaron Digulla <di...@hepe.com> wrote:
>
> Hello,
>
> My POMs have two parents: The one in the parent directory and the one
> which supplies them with the build defaults.
>
> Out of necessity, they can't be the same POM. The ../pom.xml just
> specifies the build order. The POM specified with the <parent> element
> supplies the build config (for example for webapps or for code
> libraries).
>
> Usually, a web project in our company contains a code and a web part,
> so I need two <parent> POMs (one for libraries and one for webapps)
> and I need a POM which says "build the library, then build the webapp".
>
> This means, I'm fighting with the limitations of Maven's parent POM
> model. Some plugins like the site plugin are confused how to build the
> aggregated site structure.
>
> I see three ways to improve the situation:
>
> - Support <xi:include>.
>
> Pro: It's a W3C standard (some will say that's a drawback :-)
>
> Con: It doesn't really fit into the XML inheritance model of Maven.
> When will variables be resolved? Before or after the includes? Or
> somewhere inbetween? How can we debug this?
>
> - Allow multiple <parent> elements
>
> Pro: People are already used to the parent element
>
> Con: Humans have more than one parent (father and mother) and we all
> know how confusing it is when they can't agree about something. So
> this would call for a smart conflict resolution strategy which a
> developer can understand without help.
>
> The current element will probably have to be extended with new attributes.
>
> - A new <mixin> element
>
> The element refers to a POM artifact like the <parent> element but I
> would also like it to be able to select deeper in XML tree of a POM:
>
> * "I'd like to copy the configuration for the maven-deploy-plugin but
> overwrite the version element"
>
> * "Copy the report config and merge it with the definitions in the
> current POM"
>
> * "Copy the config for the cobertura plugin except for the include
> element in the configuration"
>
> Pro: New element allows new semantic
>
> Con: This will be a pretty complex element, especially if it can copy
> conditionally. The syntax should be simple enough so people don't
> swamp the Maven lists with questions but powerful enough to actually
> solve the limitations of the current inheritance system.
>
> We might be tempted to support a copy operator based on XPath. I think
> this is a bad idea because the XPath syntax is really very complex and
> can be quite confusing.
>
> - Allow to include "macro POMs". A macro POM defines common building
> blocks which can be extended as we're used to or configured via
> paramaters:
>
> <macros>
> <include>
> <groupId>...</groupId>
> <artefactId>...</artefactId>
> <version>...</version>
> </include>
> <include>
> <file>....</file>
> </include>
> <macro>
> <id>compile</id>
> <parameter><name>version</name><default>2.0.2
> </default></parameter>
> <parameter><name>source</name><default>1.4</default></parameter>
>
> <parameter><name>target</name><default>@{source}</default></parameter>
> <body>
> <plugin>
> <artifactId>maven-compiler-plugin</artifactId>
> <version>@{version}</version>
> <configuration>
> <source>@{source}</source>
> <target>@{target}</target>
> </configuration>
> </plugin>
> </body>
> </macro>
> </macros>
>
> <build>
> <plugins>
> <macro-ref>
> <id>compile</id>
> <parameter><name>version</name><value>2.1</value></parameter>
> <body>
> <plugin>
> <configuration>
> <clean />
> <source>1.5</source>
> </configuration>
> </plugin>
> </body>
> </macro-ref>
> </plugins>
> </build>
>
> Some comments:
>
> - The "<clean />" element deletes anything inherited below the current
> parent element. In the example, there is no target element in the
> effective POM anymore.
>
> - Includes overwrite in the order in which they are specified. So the
> macros defined in the artefact are overwritten by those in the file
> and any "compile" macro will be overwritten with the local definition.
>
> Maybe inheritance merge should be supported here, too.
>
> Comments?
>
> --
> Aaron "Optimizer" Digulla a.k.a. Philmann Dark
> "It's not the universe that's limited, it's our imagination.
> Follow me and I'll show you something beyond the limits."
> http://www.philmann-dark.de/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>