5:25 p.m.
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> 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