Re: Releasing clean company parent Poms
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
Re: Releasing clean company parent Poms
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
Releasing clean company parent Poms
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
