[gatein-dev] Build update
Thomas Heute
theute at redhat.com
Wed Mar 28 09:52:30 EDT 2012
On 03/28/2012 03:43 PM, Boleslaw Dawidowicz wrote:
> We are not really dev friendly anyway because you first need to read
> README to setup settings.xml... Something I personally don't really
> get either but anyway :)
AFAIK you actually don't need to except for components (and to download
AS). In GateIn I think we have the repositories written down (which we
would have to remove if/when we want to be on central repo AFAIK but
then we wouldn't need to setup additional repos) (PS: there is probably
more to do to be on central repo)
Thomas
>
> Our main problem with -Prelease profile so far is that it was
> constantly behind. Thing is that we were using this approach so far
> and each time I forgot to grep version after "mvn release:prepare" I
> pushed somehow messed up tag. In most cases when people do changes in
> the build they simply forget to update release profile. If we keep
> like this then doing release is repeating painful process as first you
> spend whole day putting the build back into a decent state...
>
> Ken I agree with you that in theory -Prelease should be a better
> approach. In practice it just didn't work in our case.
>
> Bolek
>
> On Mar 26, 2012, at 6:59 PM, Ken Finnigan wrote:
>
>> When I stated it, I was thinking along the lines of them wanting to
>> develop on GateIn, but also use that which they developed, which
>> would require local changes to be in their Maven repo.
>>
>> if someone has downloaded the GateIn bundle, played with it, and
>> decided that they want to take a look at the code. That first time
>> they want to download and build source, they don't necessarily want
>> or care about it being packaged into a server. They just want to
>> make sure it builds and pulls in dependencies so that looking at the
>> code in an IDE makes sense and doesn't have red marks everywhere with
>> thousands of errors.
>>
>> If it's desired to build a server env along with source, I would
>> suggest building a single server by default, such as AS7, and then
>> allowing the developer to choose to build a different server if they
>> want.
>>
>> Ken
>>
>> On Mon, Mar 26, 2012 at 12:50 PM, Julien Viet <julien at julienviet.com
>> <mailto:julien at julienviet.com>> 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 at julienviet.com <mailto:julien at 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 at julienviet.com <mailto: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 <mailto: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
>>>>>> <mailto: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
>>>>>> <mailto:gatein-dev at lists.jboss.org>
>>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> gatein-dev mailing list
>>>>>> gatein-dev at lists.jboss.org
>>>>>> <mailto:gatein-dev at lists.jboss.org>
>>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> gatein-dev mailing list
>> gatein-dev at lists.jboss.org <mailto: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/20120328/8d462154/attachment-0001.html
More information about the gatein-dev
mailing list