[gatein-dev] Build update
Nick Scavelli
nscavell at redhat.com
Mon Mar 26 13:02:29 EDT 2012
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-dep-1.0.3-Beta01.pom
> [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 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
> 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/cea8f3af/attachment-0001.html
More information about the gatein-dev
mailing list