Why not simply have a "release" profile that activates each module of the build? That is usually what Maven projects do when there are modules they don't want built during dev, such as docs, etc. Ken On Mon, Mar 26, 2012 at 11:03 AM, Julien Viet <julien(a)julienviet.com&gt; wrote: Hi, we are currently working on the build after the GIT migration, one of the current issue is profile selection. The most important issue we are solving is that performing a release is error prone and often fails to perform the release properly: often POM are not versionned by the release plugin, du to the fact that it uses incorrect profile activation. Of course it is always possible to have it working by selecting the good profiles in the release plugin and on the command line, however it is error prone and it is hard to figure out by looking at the build what should be used. We are going to change how the build work with profiles, not because we don't use profiles the right way, but because Maven profile activation is not good enough. (activeByDefault is broken, you cannot have flexible activation, etc...) We still need to use profiles and actually we don't change the current profiles, what we do change is how their activation is done with a simple and important change: "Everything is built by default" It means that the command "mvn install" builds everything (all server packaging, docs, examples, etc...). This guarantees that release plugin will release properly the project. Obviously we need to address developer productivity and we do provide a way to perform a build that saves the most time we can when it is activated in a simple manner. To achieve it we use profile activation based on properties: the gatein.dev property is introduced to do it. When this property is not present, the build behaves as said before : it builds everthing. When it is selected with any value, it means that the build is done for development purpose and it skips some parts of the build (examples, docs, most of packaging). When it is selected with a server value, it build that server only : for instance "mvn install -Dgatein.dev=jetty" . The possible values are - tomcat - jbossas5 - jbossas6 - jbossas - tomcat6 - tomcat7 - jetty Another issue to fix is the selected database for running the unit tests, but I believe it affects you less because most of you are using hsqldb tests. To perform tests with MySQL, the profile -Pmysql5 can be used. Several things to note: - The README file of GateIn has been updated with the information - AS7 build is not yet finished and is cut of the build (which means that doing a release would not version the AS7 poms) Let me know if you have any issue with the build. Julien _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

Julien, I think what you're describing is different to what I meant. I don't mean doing some profile as part of the release plugin, I mean creating a new release profile that has nothing but the modules to build, no plugins or anything else defined within it. Then as part of the release you only need to add -Prelease to build every module Might be missing something, but to me it's different. Ken On Mon, Mar 26, 2012 at 11:25 AM, Julien Viet <julien(a)julienviet.com&gt; wrote: Hi Ken, The additional profile added in the release plugin will not be run in the project until the release plugin fork itself (i.e the release plugin runs another maven during the release). To perform a correct and reproducible release all profiles should be executed from the beginning with all the profiles that will update the pom. We had issues in the past with some releases (with gatein and portlet container, I don't know for others) where the release was not done correctly (the main issue is that poms were not versioned during the release which makes a broken release and also breaks the trunk/master because there are pom using the previous release SNAPSHOT version). Those releases had to be redone or worse the SVN tag was "amended" (which is not possible anymore with git) to "fix" the release. The main motivation is to ensure that the release will be easy to do, will be correct and that the build after the release is correct. On Mar 26, 2012, at 5:08 PM, Ken Finnigan wrote: > Why not simply have a "release" profile that activates each module of the build? > > That is usually what Maven projects do when there are modules they don't want built during dev, such as docs, etc. > > Ken > > On Mon, Mar 26, 2012 at 11:03 AM, Julien Viet <julien(a)julienviet.com&gt; wrote: > Hi, > > we are currently working on the build after the GIT migration, one of the current issue is profile selection. > > The most important issue we are solving is that performing a release is error prone and often fails to perform the release properly: often POM are not versionned by the release plugin, du to the fact that it uses incorrect profile activation. Of course it is always possible to have it working by selecting the good profiles in the release plugin and on the command line, however it is error prone and it is hard to figure out by looking at the build what should be used. > > We are going to change how the build work with profiles, not because we don't use profiles the right way, but because Maven profile activation is not good enough. (activeByDefault is broken, you cannot have flexible activation, etc...) > > We still need to use profiles and actually we don't change the current profiles, what we do change is how their activation is done with a simple and important change: "Everything is built by default" > > It means that the command "mvn install" builds everything (all server packaging, docs, examples, etc...). This guarantees that release plugin will release properly the project. Obviously we need to address developer productivity and we do provide a way to perform a build that saves the most time we can when it is activated in a simple manner. > > To achieve it we use profile activation based on properties: the gatein.dev property is introduced to do it. > > When this property is not present, the build behaves as said before : it builds everthing. > > When it is selected with any value, it means that the build is done for development purpose and it skips some parts of the build (examples, docs, most of packaging). > > When it is selected with a server value, it build that server only : for instance "mvn install -Dgatein.dev=jetty" . The possible values are > > - tomcat > - jbossas5 > - jbossas6 > - jbossas > - tomcat6 > - tomcat7 > - jetty > > Another issue to fix is the selected database for running the unit tests, but I believe it affects you less because most of you are using hsqldb tests. To perform tests with MySQL, the profile -Pmysql5 can be used. > > Several things to note: > > - The README file of GateIn has been updated with the information > - AS7 build is not yet finished and is cut of the build (which means that doing a release would not version the AS7 poms) > > Let me know if you have any issue with the build. > > Julien > > > _______________________________________________ > gatein-dev mailing list > gatein-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/gatein-dev > > _______________________________________________ > gatein-dev mailing list > gatein-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/gatein-dev

ok, but isn't that what documentation is for, to document the release process with whatever parameters are needed? I'd hardly consider -Prelease to be extremely onerous on a releaser. I guess from a different perspective, it's not a very pleasant experience for a community member to attempt to build GateIn and end up waiting forever for it to complete because, like everyone else, they didn't read the readme before trying to build a project. In my opinion, if someone needs to read a readme before they even attempt to build a Maven project, something is very wrong. Yes it means they don't have a packaged GateIn with a server environment built, but at least the codebase built and is available in their Maven repo. Ken On Mon, Mar 26, 2012 at 11:53 AM, Julien Viet <julien(a)julienviet.com&gt; wrote: the issue we had in the past was about forgetting profile or not knowing exactly which profiles should be activated when doing release. On Mar 26, 2012, at 5:47 PM, Ken Finnigan wrote: > Julien, > > I think what you're describing is different to what I meant. > > I don't mean doing some profile as part of the release plugin, I mean creating a new release profile that has nothing but the modules to build, no plugins or anything else defined within it. Then as part of the release you only need to add -Prelease to build every module > > Might be missing something, but to me it's different. > > Ken > > On Mon, Mar 26, 2012 at 11:25 AM, Julien Viet <julien(a)julienviet.com&gt; wrote: > Hi Ken, > > The additional profile added in the release plugin will not be run in the project until the release plugin fork itself (i.e the release plugin runs another maven during the release). > > To perform a correct and reproducible release all profiles should be executed from the beginning with all the profiles that will update the pom. > > We had issues in the past with some releases (with gatein and portlet container, I don't know for others) where the release was not done correctly (the main issue is that poms were not versioned during the release which makes a broken release and also breaks the trunk/master because there are pom using the previous release SNAPSHOT version). Those releases had to be redone or worse the SVN tag was "amended" (which is not possible anymore with git) to "fix" the release. > > The main motivation is to ensure that the release will be easy to do, will be correct and that the build after the release is correct. > > On Mar 26, 2012, at 5:08 PM, Ken Finnigan wrote: > >> Why not simply have a "release" profile that activates each module of the build? >> >> That is usually what Maven projects do when there are modules they don't want built during dev, such as docs, etc. >> >> Ken >> >> On Mon, Mar 26, 2012 at 11:03 AM, Julien Viet <julien(a)julienviet.com&gt; wrote: >> Hi, >> >> we are currently working on the build after the GIT migration, one of the current issue is profile selection. >> >> The most important issue we are solving is that performing a release is error prone and often fails to perform the release properly: often POM are not versionned by the release plugin, du to the fact that it uses incorrect profile activation. Of course it is always possible to have it working by selecting the good profiles in the release plugin and on the command line, however it is error prone and it is hard to figure out by looking at the build what should be used. >> >> We are going to change how the build work with profiles, not because we don't use profiles the right way, but because Maven profile activation is not good enough. (activeByDefault is broken, you cannot have flexible activation, etc...) >> >> We still need to use profiles and actually we don't change the current profiles, what we do change is how their activation is done with a simple and important change: "Everything is built by default" >> >> It means that the command "mvn install" builds everything (all server packaging, docs, examples, etc...). This guarantees that release plugin will release properly the project. Obviously we need to address developer productivity and we do provide a way to perform a build that saves the most time we can when it is activated in a simple manner. >> >> To achieve it we use profile activation based on properties: the gatein.dev property is introduced to do it. >> >> When this property is not present, the build behaves as said before : it builds everthing. >> >> When it is selected with any value, it means that the build is done for development purpose and it skips some parts of the build (examples, docs, most of packaging). >> >> When it is selected with a server value, it build that server only : for instance "mvn install -Dgatein.dev=jetty" . The possible values are >> >> - tomcat >> - jbossas5 >> - jbossas6 >> - jbossas >> - tomcat6 >> - tomcat7 >> - jetty >> >> Another issue to fix is the selected database for running the unit tests, but I believe it affects you less because most of you are using hsqldb tests. To perform tests with MySQL, the profile -Pmysql5 can be used. >> >> Several things to note: >> >> - The README file of GateIn has been updated with the information >> - AS7 build is not yet finished and is cut of the build (which means that doing a release would not version the AS7 poms) >> >> Let me know if you have any issue with the build. >> >> Julien >> >> >> _______________________________________________ >> gatein-dev mailing list >> gatein-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/gatein-dev >> >> _______________________________________________ >> gatein-dev mailing list >> gatein-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/gatein-dev > >

Hmm. I may be mistaken, but when would making a mistake not potentially, or likely, break things? To me this is solving a problem that can be solved with documentation. Are you saying that you don't build the GateIn packaging modules at all? You only download the released artifacts from a Maven repo? Ken On Mon, Mar 26, 2012 at 12:24 PM, Julien Viet <julien(a)julienviet.com&gt; wrote: as I said the issue is that doing a mistake breaks things, not that it is hard or complex to add an argument on the command line. That being said my opinion is that if I need a jar in my repo then I add a dependency in my pom to get those jars and maven will fetch them from me. It will be faster than having to wait 20 minutes to build the same jars. On Mar 26, 2012, at 6:02 PM, Ken Finnigan wrote: > ok, but isn't that what documentation is for, to document the release process with whatever parameters are needed? > > I'd hardly consider -Prelease to be extremely onerous on a releaser. > > I guess from a different perspective, it's not a very pleasant experience for a community member to attempt to build GateIn and end up waiting forever for it to complete because, like everyone else, they didn't read the readme before trying to build a project. > > In my opinion, if someone needs to read a readme before they even attempt to build a Maven project, something is very wrong. Yes it means they don't have a packaged GateIn with a server environment built, but at least the codebase built and is available in their Maven repo. > > Ken > > On Mon, Mar 26, 2012 at 11:53 AM, Julien Viet <julien(a)julienviet.com&gt; wrote: > the issue we had in the past was about forgetting profile or not knowing exactly which profiles should be activated when doing release. > > On Mar 26, 2012, at 5:47 PM, Ken Finnigan wrote: > >> Julien, >> >> I think what you're describing is different to what I meant. >> >> I don't mean doing some profile as part of the release plugin, I mean creating a new release profile that has nothing but the modules to build, no plugins or anything else defined within it. Then as part of the release you only need to add -Prelease to build every module >> >> Might be missing something, but to me it's different. >> >> Ken >> >> On Mon, Mar 26, 2012 at 11:25 AM, Julien Viet <julien(a)julienviet.com&gt; wrote: >> Hi Ken, >> >> The additional profile added in the release plugin will not be run in the project until the release plugin fork itself (i.e the release plugin runs another maven during the release). >> >> To perform a correct and reproducible release all profiles should be executed from the beginning with all the profiles that will update the pom. >> >> We had issues in the past with some releases (with gatein and portlet container, I don't know for others) where the release was not done correctly (the main issue is that poms were not versioned during the release which makes a broken release and also breaks the trunk/master because there are pom using the previous release SNAPSHOT version). Those releases had to be redone or worse the SVN tag was "amended" (which is not possible anymore with git) to "fix" the release. >> >> The main motivation is to ensure that the release will be easy to do, will be correct and that the build after the release is correct. >> >> On Mar 26, 2012, at 5:08 PM, Ken Finnigan wrote: >> >>> Why not simply have a "release" profile that activates each module of the build? >>> >>> That is usually what Maven projects do when there are modules they don't want built during dev, such as docs, etc. >>> >>> Ken >>> >>> On Mon, Mar 26, 2012 at 11:03 AM, Julien Viet <julien(a)julienviet.com&gt; wrote: >>> Hi, >>> >>> we are currently working on the build after the GIT migration, one of the current issue is profile selection. >>> >>> The most important issue we are solving is that performing a release is error prone and often fails to perform the release properly: often POM are not versionned by the release plugin, du to the fact that it uses incorrect profile activation. Of course it is always possible to have it working by selecting the good profiles in the release plugin and on the command line, however it is error prone and it is hard to figure out by looking at the build what should be used. >>> >>> We are going to change how the build work with profiles, not because we don't use profiles the right way, but because Maven profile activation is not good enough. (activeByDefault is broken, you cannot have flexible activation, etc...) >>> >>> We still need to use profiles and actually we don't change the current profiles, what we do change is how their activation is done with a simple and important change: "Everything is built by default" >>> >>> It means that the command "mvn install" builds everything (all server packaging, docs, examples, etc...). This guarantees that release plugin will release properly the project. Obviously we need to address developer productivity and we do provide a way to perform a build that saves the most time we can when it is activated in a simple manner. >>> >>> To achieve it we use profile activation based on properties: the gatein.dev property is introduced to do it. >>> >>> When this property is not present, the build behaves as said before : it builds everthing. >>> >>> When it is selected with any value, it means that the build is done for development purpose and it skips some parts of the build (examples, docs, most of packaging). >>> >>> When it is selected with a server value, it build that server only : for instance "mvn install -Dgatein.dev=jetty" . The possible values are >>> >>> - tomcat >>> - jbossas5 >>> - jbossas6 >>> - jbossas >>> - tomcat6 >>> - tomcat7 >>> - jetty >>> >>> Another issue to fix is the selected database for running the unit tests, but I believe it affects you less because most of you are using hsqldb tests. To perform tests with MySQL, the profile -Pmysql5 can be used. >>> >>> Several things to note: >>> >>> - The README file of GateIn has been updated with the information >>> - AS7 build is not yet finished and is cut of the build (which means that doing a release would not version the AS7 poms) >>> >>> Let me know if you have any issue with the build. >>> >>> Julien >>> >>> >>> _______________________________________________ >>> gatein-dev mailing list >>> gatein-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>> >>> _______________________________________________ >>> gatein-dev mailing list >>> gatein-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/gatein-dev >> >> > >

BTW I'm trying to build gatein with an empty repository (doing mv .m2 m2 before) which is the initial experience a user has when he build gatein. and I get [INFO] ------------------------------------------------------------------------ [INFO] Building GateIn Portal Component Portal Data [INFO] task-segment: [dependency:tree] [INFO] ------------------------------------------------------------------------ Downloading: http://repo1.maven.org/maven2/org/gatein/gatein-dep/1.0.3-Beta01/gatein-d... [INFO] Unable to find resource 'org.gatein:gatein-dep:pom:1.0.3-Beta01' in repository central (http://repo1.maven.org/maven2) [INFO] ------------------------------------------------------------------------ [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] Error building POM (may not be this project's POM). Project ID: org.gatein:gatein-dep Reason: POM 'org.gatein:gatein-dep' not found in repository: Unable to download the artifact from any repository org.gatein:gatein-dep:pom:1.0.3-Beta01 from the specified remote repositories: central (http://repo1.maven.org/maven2) for project org.gatein:gatein-dep I don't understand where this issue is coming from, if someone else can double check and help, it would be cool. On Mar 26, 2012, at 6:50 PM, Julien Viet wrote: > you said "but at least the codebase built and is available in their > Maven repo" > > if I need a jar in my repo, it's because I'm using it. If I need > log4j for instance, I don't build it, I add a dependency, it's simpler. > > what is the point of building only jars and not server ? > > > > > On Mar 26, 2012, at 6:41 PM, Ken Finnigan wrote: > >> Hmm. I may be mistaken, but when would making a mistake not >> potentially, or likely, break things? To me this is solving a >> problem that can be solved with documentation. >> >> Are you saying that you don't build the GateIn packaging modules at >> all? You only download the released artifacts from a Maven repo? >> >> Ken >> >> On Mon, Mar 26, 2012 at 12:24 PM, Julien Viet <julien(a)julienviet.com >> <mailto:julien@julienviet.com>> wrote: >> >> as I said the issue is that doing a mistake breaks things, not >> that it is hard or complex to add an argument on the command line. >> >> That being said my opinion is that if I need a jar in my repo >> then I add a dependency in my pom to get those jars and maven >> will fetch them from me. It will be faster than having to wait >> 20 minutes to build the same jars. >> >> On Mar 26, 2012, at 6:02 PM, Ken Finnigan wrote: >> >>> ok, but isn't that what documentation is for, to document the >>> release process with whatever parameters are needed? >>> >>> I'd hardly consider -Prelease to be extremely onerous on a >>> releaser. >>> >>> I guess from a different perspective, it's not a very pleasant >>> experience for a community member to attempt to build GateIn >>> and end up waiting forever for it to complete because, like >>> everyone else, they didn't read the readme before trying to >>> build a project. >>> >>> In my opinion, if someone needs to read a readme before they >>> even attempt to build a Maven project, something is very wrong. >>> Yes it means they don't have a packaged GateIn with a server >>> environment built, but at least the codebase built and is >>> available in their Maven repo. >>> >>> Ken >>> >>> On Mon, Mar 26, 2012 at 11:53 AM, Julien Viet >>> <julien(a)julienviet.com <mailto:julien@julienviet.com>> wrote: >>> >>> the issue we had in the past was about forgetting profile >>> or not knowing exactly which profiles should be activated >>> when doing release. >>> >>> On Mar 26, 2012, at 5:47 PM, Ken Finnigan wrote: >>> >>>> Julien, >>>> >>>> I think what you're describing is different to what I meant. >>>> >>>> I don't mean doing some profile as part of the release >>>> plugin, I mean creating a new release profile that has >>>> nothing but the modules to build, no plugins or anything >>>> else defined within it. Then as part of the release you >>>> only need to add -Prelease to build every module >>>> >>>> Might be missing something, but to me it's different. >>>> >>>> Ken >>>> >>>> On Mon, Mar 26, 2012 at 11:25 AM, Julien Viet >>>> <julien(a)julienviet.com <mailto:julien@julienviet.com>> wrote: >>>> >>>> Hi Ken, >>>> >>>> The additional profile added in the release plugin >>>> will not be run in the project until the release >>>> plugin fork itself (i.e the release plugin runs >>>> another maven during the release). >>>> >>>> To perform a correct and reproducible release all >>>> profiles should be executed from the beginning with >>>> all the profiles that will update the pom. >>>> >>>> We had issues in the past with some releases (with >>>> gatein and portlet container, I don't know for others) >>>> where the release was not done correctly (the main >>>> issue is that poms were not versioned during the >>>> release which makes a broken release and also breaks >>>> the trunk/master because there are pom using the >>>> previous release SNAPSHOT version). Those releases had >>>> to be redone or worse the SVN tag was "amended" (which >>>> is not possible anymore with git) to "fix" the release. >>>> >>>> The main motivation is to ensure that the release will >>>> be easy to do, will be correct and that the build >>>> after the release is correct. >>>> >>>> On Mar 26, 2012, at 5:08 PM, Ken Finnigan wrote: >>>> >>>>> Why not simply have a "release" profile that >>>>> activates each module of the build? >>>>> >>>>> That is usually what Maven projects do when there are >>>>> modules they don't want built during dev, such as >>>>> docs, etc. >>>>> >>>>> Ken >>>>> >>>>> On Mon, Mar 26, 2012 at 11:03 AM, Julien Viet >>>>> <julien(a)julienviet.com >>>>> <mailto:julien@julienviet.com>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> we are currently working on the build after the >>>>> GIT migration, one of the current issue is >>>>> profile selection. >>>>> >>>>> The most important issue we are solving is that >>>>> performing a release is error prone and often >>>>> fails to perform the release properly: often POM >>>>> are not versionned by the release plugin, du to >>>>> the fact that it uses incorrect profile >>>>> activation. Of course it is always possible to >>>>> have it working by selecting the good profiles in >>>>> the release plugin and on the command line, >>>>> however it is error prone and it is hard to >>>>> figure out by looking at the build what should be >>>>> used. >>>>> >>>>> We are going to change how the build work with >>>>> profiles, not because we don't use profiles the >>>>> right way, but because Maven profile activation >>>>> is not good enough. (activeByDefault is broken, >>>>> you cannot have flexible activation, etc...) >>>>> >>>>> We still need to use profiles and actually we >>>>> don't change the current profiles, what we do >>>>> change is how their activation is done with a >>>>> simple and important change: "Everything is built >>>>> by default" >>>>> >>>>> It means that the command "mvn install" builds >>>>> everything (all server packaging, docs, examples, >>>>> etc...). This guarantees that release plugin will >>>>> release properly the project. Obviously we need >>>>> to address developer productivity and we do >>>>> provide a way to perform a build that saves the >>>>> most time we can when it is activated in a simple >>>>> manner. >>>>> >>>>> To achieve it we use profile activation based on >>>>> properties: the gatein.dev property is introduced >>>>> to do it. >>>>> >>>>> When this property is not present, the build >>>>> behaves as said before : it builds everthing. >>>>> >>>>> When it is selected with any value, it means that >>>>> the build is done for development purpose and it >>>>> skips some parts of the build (examples, docs, >>>>> most of packaging). >>>>> >>>>> When it is selected with a server value, it build >>>>> that server only : for instance "mvn install >>>>> -Dgatein.dev=jetty" . The possible values are >>>>> >>>>> - tomcat >>>>> - jbossas5 >>>>> - jbossas6 >>>>> - jbossas >>>>> - tomcat6 >>>>> - tomcat7 >>>>> - jetty >>>>> >>>>> Another issue to fix is the selected database for >>>>> running the unit tests, but I believe it affects >>>>> you less because most of you are using hsqldb >>>>> tests. To perform tests with MySQL, the profile >>>>> -Pmysql5 can be used. >>>>> >>>>> Several things to note: >>>>> >>>>> - The README file of GateIn has been updated with >>>>> the information >>>>> - AS7 build is not yet finished and is cut of the >>>>> build (which means that doing a release would not >>>>> version the AS7 poms) >>>>> >>>>> Let me know if you have any issue with the build. >>>>> >>>>> Julien >>>>> >>>>> >>>>> _______________________________________________ >>>>> gatein-dev mailing list >>>>> gatein-dev(a)lists.jboss.org >>>>> <mailto:gatein-dev@lists.jboss.org> >>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> gatein-dev mailing list >>>>> gatein-dev(a)lists.jboss.org >>>>> <mailto:gatein-dev@lists.jboss.org> >>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>> >>>> >>> >>> >> >> > _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

It says it's only checking central for artifacts. Users should setup jboss-public-repository in their settings.xml, right? On Mon, Mar 26, 2012 at 7:02 PM, Nick Scavelli <nscavell(a)redhat.com&gt; wrote: I think this is a maven 2 issue. I think we require maven 3 now because of this bug. On 03/26/2012 12:58 PM, Julien Viet wrote: > > BTW I'm trying to build gatein with an empty repository (doing mv .m2 m2 before) which is the initial experience a user has when he build gatein. > > and I get > > [INFO] ------------------------------------------------------------------------ > [INFO] Building GateIn Portal Component Portal Data > [INFO] task-segment: [dependency:tree] > [INFO] ------------------------------------------------------------------------ > Downloading: http://repo1.maven.org/maven2/org/gatein/gatein-dep/1.0.3-Beta01/gatein-d... > [INFO] Unable to find resource 'org.gatein:gatein-dep:pom:1.0.3-Beta01' in repository central (http://repo1.maven.org/maven2) > [INFO] ------------------------------------------------------------------------ > [ERROR] BUILD ERROR > [INFO] ------------------------------------------------------------------------ > [INFO] Error building POM (may not be this project's POM). > > > Project ID: org.gatein:gatein-dep > > Reason: POM 'org.gatein:gatein-dep' not found in repository: Unable to download the artifact from any repository > > org.gatein:gatein-dep:pom:1.0.3-Beta01 > > from the specified remote repositories: > central (http://repo1.maven.org/maven2) > > for project org.gatein:gatein-dep > > > I don't understand where this issue is coming from, if someone else can double check and help, it would be cool. > > On Mar 26, 2012, at 6:50 PM, Julien Viet wrote: > >> you said "but at least the codebase built and is available in their Maven repo" >> >> if I need a jar in my repo, it's because I'm using it. If I need log4j for instance, I don't build it, I add a dependency, it's simpler. >> >> what is the point of building only jars and not server ? >> >> >> >> >> On Mar 26, 2012, at 6:41 PM, Ken Finnigan wrote: >> >>> Hmm. I may be mistaken, but when would making a mistake not potentially, or likely, break things? To me this is solving a problem that can be solved with documentation. >>> >>> Are you saying that you don't build the GateIn packaging modules at all? You only download the released artifacts from a Maven repo? >>> >>> Ken >>> >>> On Mon, Mar 26, 2012 at 12:24 PM, Julien Viet <julien(a)julienviet.com&gt; wrote: >>> as I said the issue is that doing a mistake breaks things, not that it is hard or complex to add an argument on the command line. >>> >>> That being said my opinion is that if I need a jar in my repo then I add a dependency in my pom to get those jars and maven will fetch them from me. It will be faster than having to wait 20 minutes to build the same jars. >>> >>> On Mar 26, 2012, at 6:02 PM, Ken Finnigan wrote: >>> >>>> ok, but isn't that what documentation is for, to document the release process with whatever parameters are needed? >>>> >>>> I'd hardly consider -Prelease to be extremely onerous on a releaser. >>>> >>>> I guess from a different perspective, it's not a very pleasant experience for a community member to attempt to build GateIn and end up waiting forever for it to complete because, like everyone else, they didn't read the readme before trying to build a project. >>>> >>>> In my opinion, if someone needs to read a readme before they even attempt to build a Maven project, something is very wrong. Yes it means they don't have a packaged GateIn with a server environment built, but at least the codebase built and is available in their Maven repo. >>>> >>>> Ken >>>> >>>> On Mon, Mar 26, 2012 at 11:53 AM, Julien Viet <julien(a)julienviet.com&gt; wrote: >>>> the issue we had in the past was about forgetting profile or not knowing exactly which profiles should be activated when doing release. >>>> >>>> On Mar 26, 2012, at 5:47 PM, Ken Finnigan wrote: >>>> >>>>> Julien, >>>>> >>>>> I think what you're describing is different to what I meant. >>>>> >>>>> I don't mean doing some profile as part of the release plugin, I mean creating a new release profile that has nothing but the modules to build, no plugins or anything else defined within it. Then as part of the release you only need to add -Prelease to build every module >>>>> >>>>> Might be missing something, but to me it's different. >>>>> >>>>> Ken >>>>> >>>>> On Mon, Mar 26, 2012 at 11:25 AM, Julien Viet <julien(a)julienviet.com&gt; wrote: >>>>> Hi Ken, >>>>> >>>>> The additional profile added in the release plugin will not be run in the project until the release plugin fork itself (i.e the release plugin runs another maven during the release). >>>>> >>>>> To perform a correct and reproducible release all profiles should be executed from the beginning with all the profiles that will update the pom. >>>>> >>>>> We had issues in the past with some releases (with gatein and portlet container, I don't know for others) where the release was not done correctly (the main issue is that poms were not versioned during the release which makes a broken release and also breaks the trunk/master because there are pom using the previous release SNAPSHOT version). Those releases had to be redone or worse the SVN tag was "amended" (which is not possible anymore with git) to "fix" the release. >>>>> >>>>> The main motivation is to ensure that the release will be easy to do, will be correct and that the build after the release is correct. >>>>> >>>>> On Mar 26, 2012, at 5:08 PM, Ken Finnigan wrote: >>>>> >>>>>> Why not simply have a "release" profile that activates each module of the build? >>>>>> >>>>>> That is usually what Maven projects do when there are modules they don't want built during dev, such as docs, etc. >>>>>> >>>>>> Ken >>>>>> >>>>>> On Mon, Mar 26, 2012 at 11:03 AM, Julien Viet <julien(a)julienviet.com&gt; wrote: >>>>>> Hi, >>>>>> >>>>>> we are currently working on the build after the GIT migration, one of the current issue is profile selection. >>>>>> >>>>>> The most important issue we are solving is that performing a release is error prone and often fails to perform the release properly: often POM are not versionned by the release plugin, du to the fact that it uses incorrect profile activation. Of course it is always possible to have it working by selecting the good profiles in the release plugin and on the command line, however it is error prone and it is hard to figure out by looking at the build what should be used. >>>>>> >>>>>> We are going to change how the build work with profiles, not because we don't use profiles the right way, but because Maven profile activation is not good enough. (activeByDefault is broken, you cannot have flexible activation, etc...) >>>>>> >>>>>> We still need to use profiles and actually we don't change the current profiles, what we do change is how their activation is done with a simple and important change: "Everything is built by default" >>>>>> >>>>>> It means that the command "mvn install" builds everything (all server packaging, docs, examples, etc...). This guarantees that release plugin will release properly the project. Obviously we need to address developer productivity and we do provide a way to perform a build that saves the most time we can when it is activated in a simple manner. >>>>>> >>>>>> To achieve it we use profile activation based on properties: the gatein.dev property is introduced to do it. >>>>>> >>>>>> When this property is not present, the build behaves as said before : it builds everthing. >>>>>> >>>>>> When it is selected with any value, it means that the build is done for development purpose and it skips some parts of the build (examples, docs, most of packaging). >>>>>> >>>>>> When it is selected with a server value, it build that server only : for instance "mvn install -Dgatein.dev=jetty" . The possible values are >>>>>> >>>>>> - tomcat >>>>>> - jbossas5 >>>>>> - jbossas6 >>>>>> - jbossas >>>>>> - tomcat6 >>>>>> - tomcat7 >>>>>> - jetty >>>>>> >>>>>> Another issue to fix is the selected database for running the unit tests, but I believe it affects you less because most of you are using hsqldb tests. To perform tests with MySQL, the profile -Pmysql5 can be used. >>>>>> >>>>>> Several things to note: >>>>>> >>>>>> - The README file of GateIn has been updated with the information >>>>>> - AS7 build is not yet finished and is cut of the build (which means that doing a release would not version the AS7 poms) >>>>>> >>>>>> Let me know if you have any issue with the build. >>>>>> >>>>>> Julien >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> gatein-dev mailing list >>>>>> gatein-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>>>> >>>>>> _______________________________________________ >>>>>> gatein-dev mailing list >>>>>> gatein-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>>> >>>>> >>>> >>>> >>> >>> >> > > > > _______________________________________________ > gatein-dev mailing list > gatein-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/gatein-dev _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

it looks like a corner casen thanks for investigating it, I find it very odd. what is very strange is that it claims "org.gatein:gatein-dep:pom:1.0.3-Beta01" and this dependency must be transitively specified somewhere and I can't figure out from where. On Mar 26, 2012, at 7:02 PM, Nick Scavelli wrote: > I think this is a maven 2 issue. I think we require maven 3 now because of this bug. > > On 03/26/2012 12:58 PM, Julien Viet wrote: >> >> BTW I'm trying to build gatein with an empty repository (doing mv .m2 m2 before) which is the initial experience a user has when he build gatein. >> >> and I get >> >> [INFO] ------------------------------------------------------------------------ >> [INFO] Building GateIn Portal Component Portal Data >> [INFO] task-segment: [dependency:tree] >> [INFO] ------------------------------------------------------------------------ >> Downloading: http://repo1.maven.org/maven2/org/gatein/gatein-dep/1.0.3-Beta01/gatein-d... >> [INFO] Unable to find resource 'org.gatein:gatein-dep:pom:1.0.3-Beta01' in repository central (http://repo1.maven.org/maven2) >> [INFO] ------------------------------------------------------------------------ >> [ERROR] BUILD ERROR >> [INFO] ------------------------------------------------------------------------ >> [INFO] Error building POM (may not be this project's POM). >> >> >> Project ID: org.gatein:gatein-dep >> >> Reason: POM 'org.gatein:gatein-dep' not found in repository: Unable to download the artifact from any repository >> >> org.gatein:gatein-dep:pom:1.0.3-Beta01 >> >> from the specified remote repositories: >> central (http://repo1.maven.org/maven2) >> >> for project org.gatein:gatein-dep >> >> >> I don't understand where this issue is coming from, if someone else can double check and help, it would be cool. >> >> On Mar 26, 2012, at 6:50 PM, Julien Viet wrote: >> >>> you said "but at least the codebase built and is available in their Maven repo" >>> >>> if I need a jar in my repo, it's because I'm using it. If I need log4j for instance, I don't build it, I add a dependency, it's simpler. >>> >>> what is the point of building only jars and not server ? >>> >>> >>> >>> >>> On Mar 26, 2012, at 6:41 PM, Ken Finnigan wrote: >>> >>>> Hmm. I may be mistaken, but when would making a mistake not potentially, or likely, break things? To me this is solving a problem that can be solved with documentation. >>>> >>>> Are you saying that you don't build the GateIn packaging modules at all? You only download the released artifacts from a Maven repo? >>>> >>>> Ken >>>> >>>> On Mon, Mar 26, 2012 at 12:24 PM, Julien Viet <julien(a)julienviet.com&gt; wrote: >>>> as I said the issue is that doing a mistake breaks things, not that it is hard or complex to add an argument on the command line. >>>> >>>> That being said my opinion is that if I need a jar in my repo then I add a dependency in my pom to get those jars and maven will fetch them from me. It will be faster than having to wait 20 minutes to build the same jars. >>>> >>>> On Mar 26, 2012, at 6:02 PM, Ken Finnigan wrote: >>>> >>>>> ok, but isn't that what documentation is for, to document the release process with whatever parameters are needed? >>>>> >>>>> I'd hardly consider -Prelease to be extremely onerous on a releaser. >>>>> >>>>> I guess from a different perspective, it's not a very pleasant experience for a community member to attempt to build GateIn and end up waiting forever for it to complete because, like everyone else, they didn't read the readme before trying to build a project. >>>>> >>>>> In my opinion, if someone needs to read a readme before they even attempt to build a Maven project, something is very wrong. Yes it means they don't have a packaged GateIn with a server environment built, but at least the codebase built and is available in their Maven repo. >>>>> >>>>> Ken >>>>> >>>>> On Mon, Mar 26, 2012 at 11:53 AM, Julien Viet <julien(a)julienviet.com&gt; wrote: >>>>> the issue we had in the past was about forgetting profile or not knowing exactly which profiles should be activated when doing release. >>>>> >>>>> On Mar 26, 2012, at 5:47 PM, Ken Finnigan wrote: >>>>> >>>>>> Julien, >>>>>> >>>>>> I think what you're describing is different to what I meant. >>>>>> >>>>>> I don't mean doing some profile as part of the release plugin, I mean creating a new release profile that has nothing but the modules to build, no plugins or anything else defined within it. Then as part of the release you only need to add -Prelease to build every module >>>>>> >>>>>> Might be missing something, but to me it's different. >>>>>> >>>>>> Ken >>>>>> >>>>>> On Mon, Mar 26, 2012 at 11:25 AM, Julien Viet <julien(a)julienviet.com&gt; wrote: >>>>>> Hi Ken, >>>>>> >>>>>> The additional profile added in the release plugin will not be run in the project until the release plugin fork itself (i.e the release plugin runs another maven during the release). >>>>>> >>>>>> To perform a correct and reproducible release all profiles should be executed from the beginning with all the profiles that will update the pom. >>>>>> >>>>>> We had issues in the past with some releases (with gatein and portlet container, I don't know for others) where the release was not done correctly (the main issue is that poms were not versioned during the release which makes a broken release and also breaks the trunk/master because there are pom using the previous release SNAPSHOT version). Those releases had to be redone or worse the SVN tag was "amended" (which is not possible anymore with git) to "fix" the release. >>>>>> >>>>>> The main motivation is to ensure that the release will be easy to do, will be correct and that the build after the release is correct. >>>>>> >>>>>> On Mar 26, 2012, at 5:08 PM, Ken Finnigan wrote: >>>>>> >>>>>>> Why not simply have a "release" profile that activates each module of the build? >>>>>>> >>>>>>> That is usually what Maven projects do when there are modules they don't want built during dev, such as docs, etc. >>>>>>> >>>>>>> Ken >>>>>>> >>>>>>> On Mon, Mar 26, 2012 at 11:03 AM, Julien Viet <julien(a)julienviet.com&gt; wrote: >>>>>>> Hi, >>>>>>> >>>>>>> we are currently working on the build after the GIT migration, one of the current issue is profile selection. >>>>>>> >>>>>>> The most important issue we are solving is that performing a release is error prone and often fails to perform the release properly: often POM are not versionned by the release plugin, du to the fact that it uses incorrect profile activation. Of course it is always possible to have it working by selecting the good profiles in the release plugin and on the command line, however it is error prone and it is hard to figure out by looking at the build what should be used. >>>>>>> >>>>>>> We are going to change how the build work with profiles, not because we don't use profiles the right way, but because Maven profile activation is not good enough. (activeByDefault is broken, you cannot have flexible activation, etc...) >>>>>>> >>>>>>> We still need to use profiles and actually we don't change the current profiles, what we do change is how their activation is done with a simple and important change: "Everything is built by default" >>>>>>> >>>>>>> It means that the command "mvn install" builds everything (all server packaging, docs, examples, etc...). This guarantees that release plugin will release properly the project. Obviously we need to address developer productivity and we do provide a way to perform a build that saves the most time we can when it is activated in a simple manner. >>>>>>> >>>>>>> To achieve it we use profile activation based on properties: the gatein.dev property is introduced to do it. >>>>>>> >>>>>>> When this property is not present, the build behaves as said before : it builds everthing. >>>>>>> >>>>>>> When it is selected with any value, it means that the build is done for development purpose and it skips some parts of the build (examples, docs, most of packaging). >>>>>>> >>>>>>> When it is selected with a server value, it build that server only : for instance "mvn install -Dgatein.dev=jetty" . The possible values are >>>>>>> >>>>>>> - tomcat >>>>>>> - jbossas5 >>>>>>> - jbossas6 >>>>>>> - jbossas >>>>>>> - tomcat6 >>>>>>> - tomcat7 >>>>>>> - jetty >>>>>>> >>>>>>> Another issue to fix is the selected database for running the unit tests, but I believe it affects you less because most of you are using hsqldb tests. To perform tests with MySQL, the profile -Pmysql5 can be used. >>>>>>> >>>>>>> Several things to note: >>>>>>> >>>>>>> - The README file of GateIn has been updated with the information >>>>>>> - AS7 build is not yet finished and is cut of the build (which means that doing a release would not version the AS7 poms) >>>>>>> >>>>>>> Let me know if you have any issue with the build. >>>>>>> >>>>>>> Julien >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> gatein-dev mailing list >>>>>>> gatein-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>>>>> >>>>>>> _______________________________________________ >>>>>>> gatein-dev mailing list >>>>>>> gatein-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >> >> >> >> _______________________________________________ >> gatein-dev mailing list >> gatein-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/gatein-dev _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

you said "but at least the codebase built and is available in their Maven repo" if I need a jar in my repo, it's because I'm using it. If I need log4j for instance, I don't build it, I add a dependency, it's simpler. what is the point of building only jars and not server ? On Mar 26, 2012, at 6:41 PM, Ken Finnigan wrote: Hmm. I may be mistaken, but when would making a mistake not potentially, or likely, break things? To me this is solving a problem that can be solved with documentation. Are you saying that you don't build the GateIn packaging modules at all? You only download the released artifacts from a Maven repo? Ken On Mon, Mar 26, 2012 at 12:24 PM, Julien Viet <julien(a)julienviet.com&gt;wrote: > as I said the issue is that doing a mistake breaks things, not that it is > hard or complex to add an argument on the command line. > > That being said my opinion is that if I need a jar in my repo then I add > a dependency in my pom to get those jars and maven will fetch them from me. > It will be faster than having to wait 20 minutes to build the same jars. > > On Mar 26, 2012, at 6:02 PM, Ken Finnigan wrote: > > ok, but isn't that what documentation is for, to document the release > process with whatever parameters are needed? > > I'd hardly consider -Prelease to be extremely onerous on a releaser. > > I guess from a different perspective, it's not a very pleasant experience > for a community member to attempt to build GateIn and end up waiting > forever for it to complete because, like everyone else, they didn't read > the readme before trying to build a project. > > In my opinion, if someone needs to read a readme before they even attempt > to build a Maven project, something is very wrong. Yes it means they don't > have a packaged GateIn with a server environment built, but at least the > codebase built and is available in their Maven repo. > > Ken > > On Mon, Mar 26, 2012 at 11:53 AM, Julien Viet <julien(a)julienviet.com&gt;wrote: > >> the issue we had in the past was about forgetting profile or not knowing >> exactly which profiles should be activated when doing release. >> >> On Mar 26, 2012, at 5:47 PM, Ken Finnigan wrote: >> >> Julien, >> >> I think what you're describing is different to what I meant. >> >> I don't mean doing some profile as part of the release plugin, I mean >> creating a new release profile that has nothing but the modules to build, >> no plugins or anything else defined within it. Then as part of the release >> you only need to add -Prelease to build every module >> >> Might be missing something, but to me it's different. >> >> Ken >> >> On Mon, Mar 26, 2012 at 11:25 AM, Julien Viet <julien(a)julienviet.com&gt;wrote: >> >>> Hi Ken, >>> >>> The additional profile added in the release plugin will not be run in >>> the project until the release plugin fork itself (i.e the release plugin >>> runs another maven during the release). >>> >>> To perform a correct and reproducible release all profiles should be >>> executed from the beginning with all the profiles that will update the pom. >>> >>> We had issues in the past with some releases (with gatein and portlet >>> container, I don't know for others) where the release was not done >>> correctly (the main issue is that poms were not versioned during the >>> release which makes a broken release and also breaks the trunk/master >>> because there are pom using the previous release SNAPSHOT version). Those >>> releases had to be redone or worse the SVN tag was "amended" (which is not >>> possible anymore with git) to "fix" the release. >>> >>> The main motivation is to ensure that the release will be easy to do, >>> will be correct and that the build after the release is correct. >>> >>> On Mar 26, 2012, at 5:08 PM, Ken Finnigan wrote: >>> >>> Why not simply have a "release" profile that activates each module of >>> the build? >>> >>> That is usually what Maven projects do when there are modules they >>> don't want built during dev, such as docs, etc. >>> >>> Ken >>> >>> On Mon, Mar 26, 2012 at 11:03 AM, Julien Viet <julien(a)julienviet.com&gt;wrote: >>> >>>> Hi, >>>> >>>> we are currently working on the build after the GIT migration, one of >>>> the current issue is profile selection. >>>> >>>> The most important issue we are solving is that performing a release >>>> is error prone and often fails to perform the release properly: often POM >>>> are not versionned by the release plugin, du to the fact that it uses >>>> incorrect profile activation. Of course it is always possible to have it >>>> working by selecting the good profiles in the release plugin and on the >>>> command line, however it is error prone and it is hard to figure out by >>>> looking at the build what should be used. >>>> >>>> We are going to change how the build work with profiles, not because >>>> we don't use profiles the right way, but because Maven profile activation >>>> is not good enough. (activeByDefault is broken, you cannot have flexible >>>> activation, etc...) >>>> >>>> We still need to use profiles and actually we don't change the current >>>> profiles, what we do change is how their activation is done with a simple >>>> and important change: "Everything is built by default" >>>> >>>> It means that the command "mvn install" builds everything (all server >>>> packaging, docs, examples, etc...). This guarantees that release plugin >>>> will release properly the project. Obviously we need to address developer >>>> productivity and we do provide a way to perform a build that saves the most >>>> time we can when it is activated in a simple manner. >>>> >>>> To achieve it we use profile activation based on properties: the >>>> gatein.dev property is introduced to do it. >>>> >>>> When this property is not present, the build behaves as said before : >>>> it builds everthing. >>>> >>>> When it is selected with any value, it means that the build is done >>>> for development purpose and it skips some parts of the build (examples, >>>> docs, most of packaging). >>>> >>>> When it is selected with a server value, it build that server only : >>>> for instance "mvn install -Dgatein.dev=jetty" . The possible values are >>>> >>>> - tomcat >>>> - jbossas5 >>>> - jbossas6 >>>> - jbossas >>>> - tomcat6 >>>> - tomcat7 >>>> - jetty >>>> >>>> Another issue to fix is the selected database for running the unit >>>> tests, but I believe it affects you less because most of you are using >>>> hsqldb tests. To perform tests with MySQL, the profile -Pmysql5 can be used. >>>> >>>> Several things to note: >>>> >>>> - The README file of GateIn has been updated with the information >>>> - AS7 build is not yet finished and is cut of the build (which means >>>> that doing a release would not version the AS7 poms) >>>> >>>> Let me know if you have any issue with the build. >>>> >>>> Julien >>>> >>>> >>>> _______________________________________________ >>>> gatein-dev mailing list >>>> gatein-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>> >>> >>> _______________________________________________ >>> gatein-dev mailing list >>> gatein-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>> >>> >>> >> >> > >

We are not really dev friendly anyway because you first need to read README to setup settings.xml... Something I personally don't really get either but anyway :)

Our main problem with -Prelease profile so far is that it was constantly behind. Thing is that we were using this approach so far and each time I forgot to grep version after "mvn release:prepare" I pushed somehow messed up tag. In most cases when people do changes in the build they simply forget to update release profile. If we keep like this then doing release is repeating painful process as first you spend whole day putting the build back into a decent state... Ken I agree with you that in theory -Prelease should be a better approach. In practice it just didn't work in our case. Bolek On Mar 26, 2012, at 6:59 PM, Ken Finnigan wrote: > When I stated it, I was thinking along the lines of them wanting to > develop on GateIn, but also use that which they developed, which > would require local changes to be in their Maven repo. > > if someone has downloaded the GateIn bundle, played with it, and > decided that they want to take a look at the code. That first time > they want to download and build source, they don't necessarily want > or care about it being packaged into a server. They just want to > make sure it builds and pulls in dependencies so that looking at the > code in an IDE makes sense and doesn't have red marks everywhere with > thousands of errors. > > If it's desired to build a server env along with source, I would > suggest building a single server by default, such as AS7, and then > allowing the developer to choose to build a different server if they > want. > > Ken > > On Mon, Mar 26, 2012 at 12:50 PM, Julien Viet <julien(a)julienviet.com > <mailto:julien@julienviet.com>> wrote: > > you said "but at least the codebase built and is available in > their Maven repo" > > if I need a jar in my repo, it's because I'm using it. If I need > log4j for instance, I don't build it, I add a dependency, it's > simpler. > > what is the point of building only jars and not server ? > > > > > > On Mar 26, 2012, at 6:41 PM, Ken Finnigan wrote: > >> Hmm. I may be mistaken, but when would making a mistake not >> potentially, or likely, break things? To me this is solving a >> problem that can be solved with documentation. >> >> Are you saying that you don't build the GateIn packaging modules >> at all? You only download the released artifacts from a Maven repo? >> >> Ken >> >> On Mon, Mar 26, 2012 at 12:24 PM, Julien Viet >> <julien(a)julienviet.com <mailto:julien@julienviet.com>> wrote: >> >> as I said the issue is that doing a mistake breaks things, >> not that it is hard or complex to add an argument on the >> command line. >> >> That being said my opinion is that if I need a jar in my >> repo then I add a dependency in my pom to get those jars and >> maven will fetch them from me. It will be faster than having >> to wait 20 minutes to build the same jars. >> >> On Mar 26, 2012, at 6:02 PM, Ken Finnigan wrote: >> >>> ok, but isn't that what documentation is for, to document >>> the release process with whatever parameters are needed? >>> >>> I'd hardly consider -Prelease to be extremely onerous on a >>> releaser. >>> >>> I guess from a different perspective, it's not a very >>> pleasant experience for a community member to attempt to >>> build GateIn and end up waiting forever for it to complete >>> because, like everyone else, they didn't read the readme >>> before trying to build a project. >>> >>> In my opinion, if someone needs to read a readme before >>> they even attempt to build a Maven project, something is >>> very wrong. Yes it means they don't have a packaged GateIn >>> with a server environment built, but at least the codebase >>> built and is available in their Maven repo. >>> >>> Ken >>> >>> On Mon, Mar 26, 2012 at 11:53 AM, Julien Viet >>> <julien(a)julienviet.com <mailto:julien@julienviet.com>> wrote: >>> >>> the issue we had in the past was about forgetting >>> profile or not knowing exactly which profiles should be >>> activated when doing release. >>> >>> On Mar 26, 2012, at 5:47 PM, Ken Finnigan wrote: >>> >>>> Julien, >>>> >>>> I think what you're describing is different to what I >>>> meant. >>>> >>>> I don't mean doing some profile as part of the release >>>> plugin, I mean creating a new release profile that has >>>> nothing but the modules to build, no plugins or >>>> anything else defined within it. Then as part of the >>>> release you only need to add -Prelease to build every >>>> module >>>> >>>> Might be missing something, but to me it's different. >>>> >>>> Ken >>>> >>>> On Mon, Mar 26, 2012 at 11:25 AM, Julien Viet >>>> <julien(a)julienviet.com <mailto:julien@julienviet.com>> >>>> wrote: >>>> >>>> Hi Ken, >>>> >>>> The additional profile added in the release plugin >>>> will not be run in the project until the release >>>> plugin fork itself (i.e the release plugin runs >>>> another maven during the release). >>>> >>>> To perform a correct and reproducible release all >>>> profiles should be executed from the beginning >>>> with all the profiles that will update the pom. >>>> >>>> We had issues in the past with some releases (with >>>> gatein and portlet container, I don't know for >>>> others) where the release was not done correctly >>>> (the main issue is that poms were not versioned >>>> during the release which makes a broken release >>>> and also breaks the trunk/master because there are >>>> pom using the previous release SNAPSHOT >>>> version). Those releases had to be redone or >>>> worse the SVN tag was "amended" (which is not >>>> possible anymore with git) to "fix" the release. >>>> >>>> The main motivation is to ensure that the release >>>> will be easy to do, will be correct and that the >>>> build after the release is correct. >>>> >>>> On Mar 26, 2012, at 5:08 PM, Ken Finnigan wrote: >>>> >>>>> Why not simply have a "release" profile that >>>>> activates each module of the build? >>>>> >>>>> That is usually what Maven projects do when there >>>>> are modules they don't want built during dev, >>>>> such as docs, etc. >>>>> >>>>> Ken >>>>> >>>>> On Mon, Mar 26, 2012 at 11:03 AM, Julien Viet >>>>> <julien(a)julienviet.com >>>>> <mailto:julien@julienviet.com>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> we are currently working on the build after >>>>> the GIT migration, one of the current issue >>>>> is profile selection. >>>>> >>>>> The most important issue we are solving is >>>>> that performing a release is error prone and >>>>> often fails to perform the release properly: >>>>> often POM are not versionned by the release >>>>> plugin, du to the fact that it uses incorrect >>>>> profile activation. Of course it is always >>>>> possible to have it working by selecting the >>>>> good profiles in the release plugin and on >>>>> the command line, however it is error prone >>>>> and it is hard to figure out by looking at >>>>> the build what should be used. >>>>> >>>>> We are going to change how the build work >>>>> with profiles, not because we don't use >>>>> profiles the right way, but because Maven >>>>> profile activation is not good enough. >>>>> (activeByDefault is broken, you cannot have >>>>> flexible activation, etc...) >>>>> >>>>> We still need to use profiles and actually we >>>>> don't change the current profiles, what we do >>>>> change is how their activation is done with a >>>>> simple and important change: "Everything is >>>>> built by default" >>>>> >>>>> It means that the command "mvn install" >>>>> builds everything (all server packaging, >>>>> docs, examples, etc...). This guarantees that >>>>> release plugin will release properly the >>>>> project. Obviously we need to address >>>>> developer productivity and we do provide a >>>>> way to perform a build that saves the most >>>>> time we can when it is activated in a simple >>>>> manner. >>>>> >>>>> To achieve it we use profile activation based >>>>> on properties: the gatein.dev property is >>>>> introduced to do it. >>>>> >>>>> When this property is not present, the build >>>>> behaves as said before : it builds everthing. >>>>> >>>>> When it is selected with any value, it means >>>>> that the build is done for development >>>>> purpose and it skips some parts of the build >>>>> (examples, docs, most of packaging). >>>>> >>>>> When it is selected with a server value, it >>>>> build that server only : for instance "mvn >>>>> install -Dgatein.dev=jetty" . The possible >>>>> values are >>>>> >>>>> - tomcat >>>>> - jbossas5 >>>>> - jbossas6 >>>>> - jbossas >>>>> - tomcat6 >>>>> - tomcat7 >>>>> - jetty >>>>> >>>>> Another issue to fix is the selected database >>>>> for running the unit tests, but I believe it >>>>> affects you less because most of you are >>>>> using hsqldb tests. To perform tests with >>>>> MySQL, the profile -Pmysql5 can be used. >>>>> >>>>> Several things to note: >>>>> >>>>> - The README file of GateIn has been updated >>>>> with the information >>>>> - AS7 build is not yet finished and is cut of >>>>> the build (which means that doing a release >>>>> would not version the AS7 poms) >>>>> >>>>> Let me know if you have any issue with the build. >>>>> >>>>> Julien >>>>> >>>>> >>>>> _______________________________________________ >>>>> gatein-dev mailing list >>>>> gatein-dev(a)lists.jboss.org >>>>> <mailto:gatein-dev@lists.jboss.org> >>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> gatein-dev mailing list >>>>> gatein-dev(a)lists.jboss.org >>>>> <mailto:gatein-dev@lists.jboss.org> >>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>> >>>> >>> >>> >> >> > > > _______________________________________________ > gatein-dev mailing list > gatein-dev(a)lists.jboss.org <mailto:gatein-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/gatein-dev _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

Hi, we are currently working on the build after the GIT migration, one of the current issue is profile selection. The most important issue we are solving is that performing a release is error prone and often fails to perform the release properly: often POM are not versionned by the release plugin, du to the fact that it uses incorrect profile activation. Of course it is always possible to have it working by selecting the good profiles in the release plugin and on the command line, however it is error prone and it is hard to figure out by looking at the build what should be used. We are going to change how the build work with profiles, not because we don't use profiles the right way, but because Maven profile activation is not good enough. (activeByDefault is broken, you cannot have flexible activation, etc...) We still need to use profiles and actually we don't change the current profiles, what we do change is how their activation is done with a simple and important change: "Everything is built by default" It means that the command "mvn install" builds everything (all server packaging, docs, examples, etc...). This guarantees that release plugin will release properly the project. Obviously we need to address developer productivity and we do provide a way to perform a build that saves the most time we can when it is activated in a simple manner. To achieve it we use profile activation based on properties: the gatein.dev property is introduced to do it. When this property is not present, the build behaves as said before : it builds everthing. When it is selected with any value, it means that the build is done for development purpose and it skips some parts of the build (examples, docs, most of packaging). When it is selected with a server value, it build that server only : for instance "mvn install -Dgatein.dev=jetty" . The possible values are - tomcat - jbossas5 - jbossas6 - jbossas - tomcat6 - tomcat7 - jetty Another issue to fix is the selected database for running the unit tests, but I believe it affects you less because most of you are using hsqldb tests. To perform tests with MySQL, the profile -Pmysql5 can be used. Several things to note: - The README file of GateIn has been updated with the information - AS7 build is not yet finished and is cut of the build (which means that doing a release would not version the AS7 poms) Let me know if you have any issue with the build. Julien _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

I think the real issue is that we are preforming releases on our own developer machines. This is not a very reproducible or auditable process (ie developer can specify profiles or options during the build, local maven repo may have some dirty jars, sources may not not be exactly what has been committed, ...).

Having a release system in place would solve a lot of these issue. We should really use something like hudson, and all that we need to do to release product or a component is to click a button and let the system take care of the rest. This would ensure that the maven repo is properly configured, that the correct profiles are specified, that the release version is properly specified, etc..

On Mon, 2012-03-26 at 12:56 -0400, Nick Scavelli wrote: > My main issue is that we're changing the default behavior to solve an > issue that is not a common scenario (building everything). > > On 03/26/2012 11:03 AM, Julien Viet wrote: >> Hi, >> >> we are currently working on the build after the GIT migration, one of the current issue is profile selection. >> >> The most important issue we are solving is that performing a release is error prone and often fails to perform the release properly: often POM are not versionned by the release plugin, du to the fact that it uses incorrect profile activation. Of course it is always possible to have it working by selecting the good profiles in the release plugin and on the command line, however it is error prone and it is hard to figure out by looking at the build what should be used. >> >> We are going to change how the build work with profiles, not because we don't use profiles the right way, but because Maven profile activation is not good enough. (activeByDefault is broken, you cannot have flexible activation, etc...) >> >> We still need to use profiles and actually we don't change the current profiles, what we do change is how their activation is done with a simple and important change: "Everything is built by default" >> >> It means that the command "mvn install" builds everything (all server packaging, docs, examples, etc...). This guarantees that release plugin will release properly the project. Obviously we need to address developer productivity and we do provide a way to perform a build that saves the most time we can when it is activated in a simple manner. >> >> To achieve it we use profile activation based on properties: the gatein.dev property is introduced to do it. >> >> When this property is not present, the build behaves as said before : it builds everthing. >> >> When it is selected with any value, it means that the build is done for development purpose and it skips some parts of the build (examples, docs, most of packaging). >> >> When it is selected with a server value, it build that server only : for instance "mvn install -Dgatein.dev=jetty" . The possible values are >> >> - tomcat >> - jbossas5 >> - jbossas6 >> - jbossas >> - tomcat6 >> - tomcat7 >> - jetty >> >> Another issue to fix is the selected database for running the unit tests, but I believe it affects you less because most of you are using hsqldb tests. To perform tests with MySQL, the profile -Pmysql5 can be used. >> >> Several things to note: >> >> - The README file of GateIn has been updated with the information >> - AS7 build is not yet finished and is cut of the build (which means that doing a release would not version the AS7 poms) >> >> Let me know if you have any issue with the build. >> >> Julien >> >> >> _______________________________________________ >> gatein-dev mailing list >> gatein-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/gatein-dev > _______________________________________________ > gatein-dev mailing list > gatein-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/gatein-dev

The absolutely the most friendly user experience when building GateIn I think would be to have an interactive mode: mvn install -Dinteractive will start asking questions: >Do you also want to package GateIn with one or more of the supported servers? [Y/n] >Select server(s) you want to package with: > 1) JBoss AS7 > 2) Tomcat 7 > 3) Tomcat 6 > 4) JBoss AS6 > 5) JBoss AS5 > 6) Jetty > >Enter comma seperated list of numbers: 1,2 > >Enter a path to the directory where jboss-as-7.1.0.Final.zip can be found [/home/uname/containers/]: $HOME/devel/containers >Enter a path to the directory where apache-tomcat-6.0.20.zip can be found [$HOME/devel/containers]: ... ... >Arhive jboss-as-7.1.0.Final.zip was not found in $HOME/devel/containers. Do you want me to download it from Maven repository? [Y,n] I think that would be the nicest first experience. On Tue, Mar 27, 2012 at 5:06 PM, Julien Viet <julien(a)julienviet.com&gt; wrote: On Mar 27, 2012, at 4:56 PM, Matt Wringe wrote: > I think the real issue is that we are preforming releases on our own > developer machines. This is not a very reproducible or auditable process > (ie developer can specify profiles or options during the build, local > maven repo may have some dirty jars, sources may not not be exactly what > has been committed, ...). I agree with you on that point. Not talking about the bundled server too that may be tweaked or whatever. > > Having a release system in place would solve a lot of these issue. We > should really use something like hudson, and all that we need to do to > release product or a component is to click a button and let the system > take care of the rest. This would ensure that the maven repo is properly > configured, that the correct profiles are specified, that the release > version is properly specified, etc.. Yes it would be a good thing. > > On Mon, 2012-03-26 at 12:56 -0400, Nick Scavelli wrote: >> My main issue is that we're changing the default behavior to solve an >> issue that is not a common scenario (building everything). >> >> On 03/26/2012 11:03 AM, Julien Viet wrote: >>> Hi, >>> >>> we are currently working on the build after the GIT migration, one of the current issue is profile selection. >>> >>> The most important issue we are solving is that performing a release is error prone and often fails to perform the release properly: often POM are not versionned by the release plugin, du to the fact that it uses incorrect profile activation. Of course it is always possible to have it working by selecting the good profiles in the release plugin and on the command line, however it is error prone and it is hard to figure out by looking at the build what should be used. >>> >>> We are going to change how the build work with profiles, not because we don't use profiles the right way, but because Maven profile activation is not good enough. (activeByDefault is broken, you cannot have flexible activation, etc...) >>> >>> We still need to use profiles and actually we don't change the current profiles, what we do change is how their activation is done with a simple and important change: "Everything is built by default" >>> >>> It means that the command "mvn install" builds everything (all server packaging, docs, examples, etc...). This guarantees that release plugin will release properly the project. Obviously we need to address developer productivity and we do provide a way to perform a build that saves the most time we can when it is activated in a simple manner. >>> >>> To achieve it we use profile activation based on properties: the gatein.dev property is introduced to do it. >>> >>> When this property is not present, the build behaves as said before : it builds everthing. >>> >>> When it is selected with any value, it means that the build is done for development purpose and it skips some parts of the build (examples, docs, most of packaging). >>> >>> When it is selected with a server value, it build that server only : for instance "mvn install -Dgatein.dev=jetty" . The possible values are >>> >>> - tomcat >>> - jbossas5 >>> - jbossas6 >>> - jbossas >>> - tomcat6 >>> - tomcat7 >>> - jetty >>> >>> Another issue to fix is the selected database for running the unit tests, but I believe it affects you less because most of you are using hsqldb tests. To perform tests with MySQL, the profile -Pmysql5 can be used. >>> >>> Several things to note: >>> >>> - The README file of GateIn has been updated with the information >>> - AS7 build is not yet finished and is cut of the build (which means that doing a release would not version the AS7 poms) >>> >>> Let me know if you have any issue with the build. >>> >>> Julien >>> >>> >>> _______________________________________________ >>> gatein-dev mailing list >>> gatein-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/gatein-dev >> _______________________________________________ >> gatein-dev mailing list >> gatein-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/gatein-dev > > _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

I don't think it works inside a shell :) GUI level of 'user friendy' is not for people who build code. What I propose is for people who want to build gatein from code, but don't want to spend 2 hours to get it done for the first time. On Tue, Mar 27, 2012 at 5:28 PM, Julien Viet <julien(a)julienviet.com&gt; wrote: why don't you wrap maven with izpack :-) ? http://izpack.org/ On Mar 27, 2012, at 5:26 PM, Marko Strukelj wrote: > The absolutely the most friendly user experience when building GateIn I think would be to have an interactive mode: > > mvn install -Dinteractive > > will start asking questions: > > >Do you also want to package GateIn with one or more of the supported servers? [Y/n] > > >Select server(s) you want to package with: > > 1) JBoss AS7 > > 2) Tomcat 7 > > 3) Tomcat 6 > > 4) JBoss AS6 > > 5) JBoss AS5 > > 6) Jetty > > > >Enter comma seperated list of numbers: 1,2 > > > >Enter a path to the directory where jboss-as-7.1.0.Final.zip can be found [/home/uname/containers/]: $HOME/devel/containers > >Enter a path to the directory where apache-tomcat-6.0.20.zip can be found [$HOME/devel/containers]: > ... > ... > >Arhive jboss-as-7.1.0.Final.zip was not found in $HOME/devel/containers. Do you want me to download it from Maven repository? [Y,n] > > > I think that would be the nicest first experience. > > > > On Tue, Mar 27, 2012 at 5:06 PM, Julien Viet <julien(a)julienviet.com&gt; wrote: > > On Mar 27, 2012, at 4:56 PM, Matt Wringe wrote: > > > I think the real issue is that we are preforming releases on our own > > developer machines. This is not a very reproducible or auditable process > > (ie developer can specify profiles or options during the build, local > > maven repo may have some dirty jars, sources may not not be exactly what > > has been committed, ...). > > I agree with you on that point. Not talking about the bundled server too that may be tweaked or whatever. > > > > > Having a release system in place would solve a lot of these issue. We > > should really use something like hudson, and all that we need to do to > > release product or a component is to click a button and let the system > > take care of the rest. This would ensure that the maven repo is properly > > configured, that the correct profiles are specified, that the release > > version is properly specified, etc.. > > Yes it would be a good thing. > > > > > On Mon, 2012-03-26 at 12:56 -0400, Nick Scavelli wrote: > >> My main issue is that we're changing the default behavior to solve an > >> issue that is not a common scenario (building everything). > >> > >> On 03/26/2012 11:03 AM, Julien Viet wrote: > >>> Hi, > >>> > >>> we are currently working on the build after the GIT migration, one of the current issue is profile selection. > >>> > >>> The most important issue we are solving is that performing a release is error prone and often fails to perform the release properly: often POM are not versionned by the release plugin, du to the fact that it uses incorrect profile activation. Of course it is always possible to have it working by selecting the good profiles in the release plugin and on the command line, however it is error prone and it is hard to figure out by looking at the build what should be used. > >>> > >>> We are going to change how the build work with profiles, not because we don't use profiles the right way, but because Maven profile activation is not good enough. (activeByDefault is broken, you cannot have flexible activation, etc...) > >>> > >>> We still need to use profiles and actually we don't change the current profiles, what we do change is how their activation is done with a simple and important change: "Everything is built by default" > >>> > >>> It means that the command "mvn install" builds everything (all server packaging, docs, examples, etc...). This guarantees that release plugin will release properly the project. Obviously we need to address developer productivity and we do provide a way to perform a build that saves the most time we can when it is activated in a simple manner. > >>> > >>> To achieve it we use profile activation based on properties: the gatein.dev property is introduced to do it. > >>> > >>> When this property is not present, the build behaves as said before : it builds everthing. > >>> > >>> When it is selected with any value, it means that the build is done for development purpose and it skips some parts of the build (examples, docs, most of packaging). > >>> > >>> When it is selected with a server value, it build that server only : for instance "mvn install -Dgatein.dev=jetty" . The possible values are > >>> > >>> - tomcat > >>> - jbossas5 > >>> - jbossas6 > >>> - jbossas > >>> - tomcat6 > >>> - tomcat7 > >>> - jetty > >>> > >>> Another issue to fix is the selected database for running the unit tests, but I believe it affects you less because most of you are using hsqldb tests. To perform tests with MySQL, the profile -Pmysql5 can be used. > >>> > >>> Several things to note: > >>> > >>> - The README file of GateIn has been updated with the information > >>> - AS7 build is not yet finished and is cut of the build (which means that doing a release would not version the AS7 poms) > >>> > >>> Let me know if you have any issue with the build. > >>> > >>> Julien > >>> > >>> > >>> _______________________________________________ > >>> gatein-dev mailing list > >>> gatein-dev(a)lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/gatein-dev > >> _______________________________________________ > >> gatein-dev mailing list > >> gatein-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/gatein-dev > > > > > > > _______________________________________________ > gatein-dev mailing list > gatein-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/gatein-dev >