[gatein-dev] Build update

[Ken Finnigan]

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 at 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 at 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 at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/gatein-dev
>>>
>>
>> _______________________________________________
>> gatein-dev mailing list
>> gatein-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/gatein-dev
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/gatein-dev/attachments/20120326/54576a54/attachment.html