[gatein-dev] Compilation hell on Windows

Dimitri BAELI dbaeli at gmail.com
Sat Oct 10 18:22:50 EDT 2009


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 at 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 at 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 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/20091011/9fe79f0d/attachment.html 


More information about the gatein-dev mailing list