Re: [gatein-dev] Compilation hell on Windows

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&gt; 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&gt;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&gt;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 >>> >>> >> >