[gatein-dev] Build update

Marko Strukelj marko.strukelj at gmail.com
Mon Mar 26 18:08:39 EDT 2012 

It says it's only checking central for artifacts.

Users should setup jboss-public-repository in their settings.xml, right?



On Mon, Mar 26, 2012 at 7:02 PM, Nick Scavelli <nscavell at redhat.com> wrote:

>  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>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>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
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>
>
> _______________________________________________
> gatein-dev mailing listgatein-dev at lists.jboss.orghttps://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/20120327/1e569df2/attachment-0001.html

More information about the gatein-dev mailing list