Re: [gatein-dev] Build update

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 >