Re: [gatein-dev] Build update

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 listgatein-dev@lists.jboss.orghttps://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