maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mirko Friedenhagen <>
Subject Re: Releasing clean "company" parent Poms
Date Sat, 01 Mar 2014 12:11:02 GMT
Hello Bernd,

you could think about having a multi-module pom project with an
aggregation-pom, having life cycle/configuration jar module and your
company pom. Testing would be defined in the aggregation pom. Only ugly
thing that you have to duplicate some plugin versions in the aggregate and
company pom.

Regards from Karlsruhe
Sent from my mobile
On Mar 1, 2014 2:26 AM, "Bernd Eckenfels" <> wrote:

> Hello,
> I am currently wondering what the best way would be to deploy a
> "company wide" parent POM (with maven release plugin) but have only the
> information in the parent POM which is actually about the object model
> of the clients (and not the definitions for deploying and testing the
> parent).
> I have seen that the ASF and Maven parents have moved some release
> related code to a second site-pom. So you dont have the site-specific
> definitions cluttering up the parent pom.
> However there is still SCM information and plugins in the parent pom.
> So, basically there are multiple ways, one would be to use deploy-file,
> another would be to attach a source file as a deployed artifact. I
> wonder if there is a prefered way to do this. Or is there a reason not
> to do it.
> My main question is, how the coordinates of the build project and the
> build artifacts would overlap?
> So, I was thinking to have a repository like:
> poms/pom.xml modules=company,... (com.pany.poms:aggregator:1.0)
>      company/pom.xml             (com.pany.poms:company-build:1.0)
>      company/src/pom/pom.xml     (com.pany.parent:pom:1.0)
> When releasing poms/pom.xml the result would be a released company wide
> parent pom which does by itself only contain project/company metadata
> and not plugins for itself.
> (I guess the easiest would be to manually deploy a static file, but in
> that case I could not automate that with some testing and site
> creation).
> I guess this topic is somewhat more relevant since there have been some
> discussions about seperating the public visible models from (its own)
> build instructions in later POM schema versions.
> Gruss
> Bernd
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message