Re: [gatein-dev] Build update

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