you won't be able to do it because you cannot know which revision you'll
have in your tag. If someone else commit just before you it wont work ?
Cheers,
Arnaud
# Arnaud Héritier
# Software Factory Manager
# eXo Platform
#
On Sun, Oct 11, 2009 at 12:39 AM, Dimitri BAELI <dbaeli(a)gmail.com> wrote:
I was simply suggesting to create a tag with the revision number
of the
source, and in the version.
Dimitri BAELI - eXo Platform SAS
On Sun, Oct 11, 2009 at 12:36 AM, Arnaud HERITIER <aheritier(a)gmail.com>wrote:
> It is impossible to deploy a version with the SCM revision (for several
> bugs/reasons in Maven)
>
> You have to use timestamped versions instead of SNAPSHOTs version to avoid
> this problemYou can use mvn versions:lock-snapshots to resolve them
>
http://mojo.codehaus.org/versions-maven-plugin/lock-snapshots-mojo.html
> Actually at eXo we don't keep all SNAPSHOTs but they don't cleanup them at
> JBoss
>
> Cheers,
>
> Arnaud
>
> # Arnaud Héritier
> # Software Factory Manager
> # eXo Platform
> #
http://www.exoplatform.com
> #
http://blog.aheritier.net
>
>
> On Sun, Oct 11, 2009 at 12:22 AM, Dimitri BAELI <dbaeli(a)gmail.com> wrote:
>
>> Note:
>> +1 to not use any SNAPSHOT in dependencies because it can block to
>> reproduce the build of past revisions.
>> Trying to build a previous revision can fail because the last version
>> of dependencies snapshots will be used, not the one this revision was using.
>> Instead of using snapshots, we can simply deploy versions of those
>> dependencies with revision number instead of the SNAPSHOT name (like
>> 2.1.0-r326).
>> Dimitri BAELI - eXo Platform SAS
>>
>>
>> On Sun, Oct 11, 2009 at 12:12 AM, Arnaud HERITIER
<aheritier(a)gmail.com>wrote:
>>
>>> I suppose that avoiding to build it on windows isn't a reply ??:-)
>>> Another solution can be a change in a plugin because I updated several
>>> things in poms.
>>> But the only one I'm sure I didn't change is the compiler plugin
where
>>> the problem seems to be.
>>>
>>> Cheers,
>>>
>>> Arnaud
>>>
>>> # Arnaud Héritier
>>> # Software Factory Manager
>>> # eXo Platform
>>> #
http://www.exoplatform.com
>>> #
http://blog.aheritier.net
>>>
>>>
>>> On Sat, Oct 10, 2009 at 10:59 PM, Dimitri BAELI
<dbaeli(a)gmail.com>wrote:
>>>
>>>> Hello,
>>>> I already see your smile but we've got a big problem on
compiling
>>>> GateIn on windows.
>>>> The issue is reported and detailled here :
>>>>
https://jira.jboss.org/jira/browse/GTNPORTAL-27
>>>> The build takes 40min where it should take 5min.
>>>>
>>>> I've investigated a bit:
>>>> * It seems that the javac is spending all his time in scaning
>>>> directories in the classpath.
>>>> * Then I compared the dependencies of current a previous versions of
>>>> webui\eXo module (one of the slow modules), and it turns that nearly
only
>>>> some versions changed in the dependencies.
>>>> ** There is tools.jar (12Mo !) from htmlparser from JCR (see
>>>> EXOJCR-179 <
https://jira.jboss.org/jira/browse/EXOJCR-179>) but
>>>> removing it from the compilation classpath is not sufficient.
>>>> ** Other dependencies changes are mainly versions changes.
>>>>
>>>> Current conclusion:
>>>> * It is probably a change in the classpath, but not sure yet.
>>>> * No clue of responsible commit for the moment.
>>>>
>>>> What's next:
>>>> * update the gatein source code to past revision and rebuild until the
>>>> commit that introduced the regression is found.
>>>>
>>>> I'm starting to study that and let you know. Unless someone has
another
>>>> idea.
>>>>
>>>> Dimitri BAELI - eXo Platform SAS
>>>>
>>>> _______________________________________________
>>>> gatein-dev mailing list
>>>> gatein-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/gatein-dev
>>>>
>>>>
>>>
>>
>