Sorry Bernd and everyone, I did not see that you just outlined the solution I proposed yourself.
Regards Mirko -- Sent from my mobile On Mar 1, 2014 1:11 PM, "Mirko Friedenhagen" <mfriedenha...@gmail.com> wrote: > 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 > Mirko > -- > Sent from my mobile > On Mar 1, 2014 2:26 AM, "Bernd Eckenfels" <e...@zusammenkunft.net> 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: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >>
