we are now able to build the Tomcat package with a build 100% based on Maven (and a bit of Ant) with the following benefits: - packaging is slightly faster (15s instead of 25s on my machine) - the build can be executed fully by Maven 3 (although it warns a bit on some stuff that he does not like) - a more lightweight build (67m instead of 74m according to Arnaud). This is based on the initial work provided by Martin Podolski, some ideas borrowed from Dimitri, useful help from Arnaud. The list of dependencies is now fully declared in a pom (which takes version from the parent pom and add some version for runtime specific libraries, we will see how to properly address that later with Thomas). Initially I used the assembly plugin as done initially by Martin but this has no-go flaws: - major drain to productivity: 2 minutes to assemble the Tomcat version. (exobuild was 25s) - no real control over the libraries we want in /libs - plugin version quirks 2.1 / 2.2beta / 2.2 have differences So I went for an Ant solution that is better, it uses several trick to assemble the /libs and /webapps. First of all it uses XSLT to transform the initial pom.xml into an Ant script (code generation basically), for instance: <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> </dependency> becomes <copy todir="target/tomcat/lib"> <fileset refid="org.slf4j:slf4j-api:jar"/> </copy> which means that we copy exactly what we want. The second trick is to use XSLT processing instructions to define metadata for the Ant script, in our case for now the main usage is the renaming of the war file so a dependency like: <dependency> <?rename portal.war?> <groupId>org.exoplatform.portal</groupId> <artifactId>exo.portal.web.portal</artifactId> <type>war</type> </dependency> becomes <copy tofile="target/tomcat/webapps/portal.war"> <fileset refid="org.exoplatform.portal:exo.portal.web.portal:war"/> </copy> The activation is exactly the same as before, the -Ppkg-tomcat is used and replace the previous one. However I understand it may cause unexpected issues so there will be a transition where you can still use the previous packaging with -Ppkg-tomcat-legacy. The new packaging now is in the folder packaging/tomcat and the generated tomcat is in packaging/tomcat/pkg/target/tomcat . cheers Julien

we are now able to build the Tomcat package with a build 100% based on Maven (and a bit of Ant) with the following benefits: - packaging is slightly faster (15s instead of 25s on my machine) - the build can be executed fully by Maven 3 (although it warns a bit on some stuff that he does not like) - a more lightweight build (67m instead of 74m according to Arnaud). This is based on the initial work provided by Martin Podolski, some ideas borrowed from Dimitri, useful help from Arnaud. The list of dependencies is now fully declared in a pom (which takes version from the parent pom and add some version for runtime specific libraries, we will see how to properly address that later with Thomas). Initially I used the assembly plugin as done initially by Martin but this has no-go flaws: - major drain to productivity: 2 minutes to assemble the Tomcat version. (exobuild was 25s) - no real control over the libraries we want in /libs - plugin version quirks 2.1 / 2.2beta / 2.2 have differences So I went for an Ant solution that is better, it uses several trick to assemble the /libs and /webapps. First of all it uses XSLT to transform the initial pom.xml into an Ant script (code generation basically), for instance: <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> </dependency> becomes <copy todir="target/tomcat/lib"> <fileset refid="org.slf4j:slf4j-api:jar"/> </copy> which means that we copy exactly what we want. The second trick is to use XSLT processing instructions to define metadata for the Ant script, in our case for now the main usage is the renaming of the war file so a dependency like: <dependency> <?rename portal.war?> <groupId>org.exoplatform.portal</groupId> <artifactId>exo.portal.web.portal</artifactId> <type>war</type> </dependency> becomes <copy tofile="target/tomcat/webapps/portal.war"> <fileset refid="org.exoplatform.portal:exo.portal.web.portal:war"/> </copy> The activation is exactly the same as before, the -Ppkg-tomcat is used and replace the previous one. However I understand it may cause unexpected issues so there will be a transition where you can still use the previous packaging with -Ppkg-tomcat-legacy. The new packaging now is in the folder packaging/tomcat and the generated tomcat is in packaging/tomcat/pkg/target/tomcat . cheers Julien _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

I think it depends if you want to use ear plugin or not. We need to know if ear plugin provides full control over the dependencies it aggregates or do something transitive. If it does something transitive it would be preferable to package an ear the same way I did for tomcat. In addition you would have to maintain the EAR descriptor file (or maybe generate it from the POM with a processing instruction allowing to include or exclude a jar). If EAR plugin is good then I think you are not far from solution but I have not tried Martin's ear. If you go with more handcrafted ear as described, you could reuse large part of the work but perform additional filtering of jar files as likely some of them are included in JBoss AS. In both case I don't think it is too much work. I think also that using only ANT would be good for consistence of the solution and it is at the end a straightforward solution although it bypass Maven's habits. On Oct 26, 2010, at 11:07 AM, Thomas Heute wrote: > You're insane ;) > > How much work for the jbossas packaging ? > > On 10/26/2010 05:34 AM, Julien Viet wrote: > >> we are now able to build the Tomcat package with a build 100% based on Maven (and a bit of Ant) with the following benefits: >> >> - packaging is slightly faster (15s instead of 25s on my machine) >> - the build can be executed fully by Maven 3 (although it warns a bit on some stuff that he does not like) >> - a more lightweight build (67m instead of 74m according to Arnaud). >> >> This is based on the initial work provided by Martin Podolski, some ideas borrowed from Dimitri, useful help from Arnaud. >> >> The list of dependencies is now fully declared in a pom (which takes version from the parent pom and add some version for runtime specific libraries, we will see how to properly address that later with Thomas). >> >> Initially I used the assembly plugin as done initially by Martin but this has no-go flaws: >> >> - major drain to productivity: 2 minutes to assemble the Tomcat version. (exobuild was 25s) >> - no real control over the libraries we want in /libs >> - plugin version quirks 2.1 / 2.2beta / 2.2 have differences >> >> So I went for an Ant solution that is better, it uses several trick to assemble the /libs and /webapps. >> >> First of all it uses XSLT to transform the initial pom.xml into an Ant script (code generation basically), for instance: >> >> <dependency> >> <groupId>org.slf4j</groupId> >> <artifactId>slf4j-api</artifactId> >> </dependency> >> >> becomes >> >> <copy todir="target/tomcat/lib"> >> <fileset refid="org.slf4j:slf4j-api:jar"/> >> </copy> >> >> which means that we copy exactly what we want. >> >> The second trick is to use XSLT processing instructions to define metadata for the Ant script, in our case for now the main usage is the renaming of the war file so a dependency like: >> >> <dependency> >> <?rename portal.war?> >> <groupId>org.exoplatform.portal</groupId> >> <artifactId>exo.portal.web.portal</artifactId> >> <type>war</type> >> </dependency> >> >> becomes >> >> <copy tofile="target/tomcat/webapps/portal.war"> >> <fileset refid="org.exoplatform.portal:exo.portal.web.portal:war"/> >> </copy> >> >> The activation is exactly the same as before, the -Ppkg-tomcat is used and replace the previous one. However I understand it may cause unexpected issues so there will be a transition where you can still use the previous packaging with -Ppkg-tomcat-legacy. >> >> The new packaging now is in the folder packaging/tomcat and the generated tomcat is in packaging/tomcat/pkg/target/tomcat . >> >> cheers >> >> Julien >> _______________________________________________ >> gatein-dev mailing list >> gatein-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/gatein-dev >> >> >

I think that for that we want at least to have no library version that are commonly used in a either poms, so it would be in a special pom (perhaps the parent or a parent of the parent that would only do that but have the same lifecycle than gatein, not released apart, or maybe that). Then I think each packaging has to explicitely declare what it uses because inheritance will surely not work in that case.

Comparison then would be done between poms.

Version update would happen at the common place.

On Oct 26, 2010, at 11:19 AM, Thomas Heute wrote: > Problem is to keep both (Tomcat and JBossAS) in sync, we need a similar solution so we can easily compare both. > > On 10/26/2010 11:17 AM, Julien Viet wrote: > >> I think it depends if you want to use ear plugin or not. >> >> We need to know if ear plugin provides full control over the dependencies it aggregates or do something transitive. If it does something transitive it would be preferable to package an ear the same way I did for tomcat. In addition you would have to maintain the EAR descriptor file (or maybe generate it from the POM with a processing instruction allowing to include or exclude a jar). >> >> If EAR plugin is good then I think you are not far from solution but I have not tried Martin's ear. >> If you go with more handcrafted ear as described, you could reuse large part of the work but perform additional filtering of jar files as likely some of them are included in JBoss AS. >> >> In both case I don't think it is too much work. >> >> I think also that using only ANT would be good for consistence of the solution and it is at the end a straightforward solution although it bypass Maven's habits. >> >> On Oct 26, 2010, at 11:07 AM, Thomas Heute wrote: >> >> >> >>> You're insane ;) >>> >>> How much work for the jbossas packaging ? >>> >>> On 10/26/2010 05:34 AM, Julien Viet wrote: >>> >>> >>>> we are now able to build the Tomcat package with a build 100% based on Maven (and a bit of Ant) with the following benefits: >>>> >>>> - packaging is slightly faster (15s instead of 25s on my machine) >>>> - the build can be executed fully by Maven 3 (although it warns a bit on some stuff that he does not like) >>>> - a more lightweight build (67m instead of 74m according to Arnaud). >>>> >>>> This is based on the initial work provided by Martin Podolski, some ideas borrowed from Dimitri, useful help from Arnaud. >>>> >>>> The list of dependencies is now fully declared in a pom (which takes version from the parent pom and add some version for runtime specific libraries, we will see how to properly address that later with Thomas). >>>> >>>> Initially I used the assembly plugin as done initially by Martin but this has no-go flaws: >>>> >>>> - major drain to productivity: 2 minutes to assemble the Tomcat version. (exobuild was 25s) >>>> - no real control over the libraries we want in /libs >>>> - plugin version quirks 2.1 / 2.2beta / 2.2 have differences >>>> >>>> So I went for an Ant solution that is better, it uses several trick to assemble the /libs and /webapps. >>>> >>>> First of all it uses XSLT to transform the initial pom.xml into an Ant script (code generation basically), for instance: >>>> >>>> <dependency> >>>> <groupId>org.slf4j</groupId> >>>> <artifactId>slf4j-api</artifactId> >>>> </dependency> >>>> >>>> becomes >>>> >>>> <copy todir="target/tomcat/lib"> >>>> <fileset refid="org.slf4j:slf4j-api:jar"/> >>>> </copy> >>>> >>>> which means that we copy exactly what we want. >>>> >>>> The second trick is to use XSLT processing instructions to define metadata for the Ant script, in our case for now the main usage is the renaming of the war file so a dependency like: >>>> >>>> <dependency> >>>> <?rename portal.war?> >>>> <groupId>org.exoplatform.portal</groupId> >>>> <artifactId>exo.portal.web.portal</artifactId> >>>> <type>war</type> >>>> </dependency> >>>> >>>> becomes >>>> >>>> <copy tofile="target/tomcat/webapps/portal.war"> >>>> <fileset refid="org.exoplatform.portal:exo.portal.web.portal:war"/> >>>> </copy> >>>> >>>> The activation is exactly the same as before, the -Ppkg-tomcat is used and replace the previous one. However I understand it may cause unexpected issues so there will be a transition where you can still use the previous packaging with -Ppkg-tomcat-legacy. >>>> >>>> The new packaging now is in the folder packaging/tomcat and the generated tomcat is in packaging/tomcat/pkg/target/tomcat . >>>> >>>> cheers >>>> >>>> Julien >>>> _______________________________________________ >>>> gatein-dev mailing list >>>> gatein-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>> >>>> >>>> >>> >>> >> >> >

not every libraries.

by fear to break things, I added them only in the pom.xml of tomcat packaging for now. http://anonsvn.jboss.org/repos/gatein/portal/trunk/packaging/tomcat/pkg/p...

we should also analyse potential conflicts with transitive dependencies, but I think here some maven plugin could help to detect conflict. On Oct 26, 2010, at 11:27 AM, Thomas Heute wrote: > On 10/26/2010 11:24 AM, Julien Viet wrote: > >> I think that for that we want at least to have no library version that are commonly used in a either poms, so it would be in a special pom (perhaps the parent or a parent of the parent that would only do that but have the same lifecycle than gatein, not released apart, or maybe that). >> >> Then I think each packaging has to explicitely declare what it uses because inheritance will surely not work in that case. >> >> > Yes, we'll have to be explicit. > >> Comparison then would be done between poms. >> >> > That would work (I feared that we would have a pom and an Ant) > >> Version update would happen at the common place. >> >> > Versions are already defined in the root pom for most libraries right ? > > >> On Oct 26, 2010, at 11:19 AM, Thomas Heute wrote: >> >> >> >>> Problem is to keep both (Tomcat and JBossAS) in sync, we need a similar solution so we can easily compare both. >>> >>> On 10/26/2010 11:17 AM, Julien Viet wrote: >>> >>> >>>> I think it depends if you want to use ear plugin or not. >>>> >>>> We need to know if ear plugin provides full control over the dependencies it aggregates or do something transitive. If it does something transitive it would be preferable to package an ear the same way I did for tomcat. In addition you would have to maintain the EAR descriptor file (or maybe generate it from the POM with a processing instruction allowing to include or exclude a jar). >>>> >>>> If EAR plugin is good then I think you are not far from solution but I have not tried Martin's ear. >>>> If you go with more handcrafted ear as described, you could reuse large part of the work but perform additional filtering of jar files as likely some of them are included in JBoss AS. >>>> >>>> In both case I don't think it is too much work. >>>> >>>> I think also that using only ANT would be good for consistence of the solution and it is at the end a straightforward solution although it bypass Maven's habits. >>>> >>>> On Oct 26, 2010, at 11:07 AM, Thomas Heute wrote: >>>> >>>> >>>> >>>> >>>>> You're insane ;) >>>>> >>>>> How much work for the jbossas packaging ? >>>>> >>>>> On 10/26/2010 05:34 AM, Julien Viet wrote: >>>>> >>>>> >>>>> >>>>>> we are now able to build the Tomcat package with a build 100% based on Maven (and a bit of Ant) with the following benefits: >>>>>> >>>>>> - packaging is slightly faster (15s instead of 25s on my machine) >>>>>> - the build can be executed fully by Maven 3 (although it warns a bit on some stuff that he does not like) >>>>>> - a more lightweight build (67m instead of 74m according to Arnaud). >>>>>> >>>>>> This is based on the initial work provided by Martin Podolski, some ideas borrowed from Dimitri, useful help from Arnaud. >>>>>> >>>>>> The list of dependencies is now fully declared in a pom (which takes version from the parent pom and add some version for runtime specific libraries, we will see how to properly address that later with Thomas). >>>>>> >>>>>> Initially I used the assembly plugin as done initially by Martin but this has no-go flaws: >>>>>> >>>>>> - major drain to productivity: 2 minutes to assemble the Tomcat version. (exobuild was 25s) >>>>>> - no real control over the libraries we want in /libs >>>>>> - plugin version quirks 2.1 / 2.2beta / 2.2 have differences >>>>>> >>>>>> So I went for an Ant solution that is better, it uses several trick to assemble the /libs and /webapps. >>>>>> >>>>>> First of all it uses XSLT to transform the initial pom.xml into an Ant script (code generation basically), for instance: >>>>>> >>>>>> <dependency> >>>>>> <groupId>org.slf4j</groupId> >>>>>> <artifactId>slf4j-api</artifactId> >>>>>> </dependency> >>>>>> >>>>>> becomes >>>>>> >>>>>> <copy todir="target/tomcat/lib"> >>>>>> <fileset refid="org.slf4j:slf4j-api:jar"/> >>>>>> </copy> >>>>>> >>>>>> which means that we copy exactly what we want. >>>>>> >>>>>> The second trick is to use XSLT processing instructions to define metadata for the Ant script, in our case for now the main usage is the renaming of the war file so a dependency like: >>>>>> >>>>>> <dependency> >>>>>> <?rename portal.war?> >>>>>> <groupId>org.exoplatform.portal</groupId> >>>>>> <artifactId>exo.portal.web.portal</artifactId> >>>>>> <type>war</type> >>>>>> </dependency> >>>>>> >>>>>> becomes >>>>>> >>>>>> <copy tofile="target/tomcat/webapps/portal.war"> >>>>>> <fileset refid="org.exoplatform.portal:exo.portal.web.portal:war"/> >>>>>> </copy> >>>>>> >>>>>> The activation is exactly the same as before, the -Ppkg-tomcat is used and replace the previous one. However I understand it may cause unexpected issues so there will be a transition where you can still use the previous packaging with -Ppkg-tomcat-legacy. >>>>>> >>>>>> The new packaging now is in the folder packaging/tomcat and the generated tomcat is in packaging/tomcat/pkg/target/tomcat . >>>>>> >>>>>> cheers >>>>>> >>>>>> Julien >>>>>> _______________________________________________ >>>>>> gatein-dev mailing list >>>>>> gatein-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> >