Hi All,
What's the situation of this ?
Can we safely build / test / develop xwiki with ganymede ? :)
On Thu, Aug 14, 2008 at 5:46 PM, Pascal Voitot
<pascal.voitot.dev(a)gmail.com>wrote;wrote:
> On Thu, Aug 14, 2008 at 12:13 PM, Thomas Mortagne <
> thomas.mortagne(a)xwiki.com
>> wrote:
>
>> On Thu, Aug 14, 2008 at 10:35 AM, Pascal Voitot
>> <pascal.voitot.dev(a)gmail.com> wrote:
>>> Hello,
>>> I've tried building platform and XE from trunk under Eclipse
>> 3.4(Ganymede)
>>> with last M2Eclipse (Maven embedded 2.1.0 with m2eclipse 0.9.5)
>>> which
>> brings
>>> lots of new features but also some new problems...
>>>
>>> I've checked out full platform trunk and tried to use the "nested
> modules
>>> management" of m2eclipse in order to have something clean... so
>>> check
> out
>>> using Subclipse and then activated Maven dependency management,
> Workspace
>>> resolution and Nested Modules...
>>>
>>> Due to some new features of both maven and m2eclipse and due to new
>> nested
>>> modules, there are some problems building everything from
>>> scratch...
>>> Here are my short remarks (I'm only maven and eclipse user so
>>> this is
>> what I
>>> can seem with an external point of view):
>>> - the famous out-of-memory still exists when building aspects so
>>> still
>> needs
>>> to creates a specific Run target with the now famous
> "-XmxLOTS_OF_MEMORY"
>>> - now in Maven, compiled classes are separated: main classes goes
>>> in
>>> target/classes and test classes goes in target/test-classes
>>> (which is
> not
>> so
>>> bad)
>>> - In XWiki platform, we have now up to 3 levels of nested modules
>>> and
>>> apparently the maven inheritance is not well managed by
>>> m2eclipse. By
>>> default, maven tests are not run using parent compiled classes
>>> and I
> had
>> to
>>> explicitely trigger "resolve Workspace artifact" in my specific
>>> Maven
> Run
>>> target not to have "no class def found exception
>>> for ...XWikiContext"
>> when
>>> running maven:test.
>>> - the "resolve Workspace artifact" is sometimes not good: for
>> web/standard,
>>> it tries to copy the file xwiki-core/target/classes but as it is a
>>> directory, it fails to copy it :)...
>>> - Moreover, m2eclipse seems to run maven tests using target/classes
> from
>>> parent or locally dependent maven modules but not target/test-
>>> classes.
>> And
>>> in XWiki, xwiki-rendering/xwiki-rendering-tests, for example, uses
>> classes
>>> from xwiki-core tests classes. I haven't found a clever solution
>>> for
>> this.
>>> - I can also see some code errors in Eclipse in web/gwt because
>>> Eclipse
>> trie
>>> to resolve some deprecated functions from xwiki-core trunk... not a
>> problem
>>> when compiling with maven
>>
>> Do you have AJDT installed ? AJDT automatically build xwiki-core
>> aspects. The problem is that AJDT version that works correctly on
>> Eclipse 3.4 (the ones based on aspectJ 1.6) don't work with XWiki
>> aspect files it seems. I'm back to 3.3 cause of this.
>>
>
> No I don't have it...
> I think this is only a question of dependency management... lots of
> things
> have changed in the last version and the intensive usage of nested
> modules
> in XWiki is apparently not well managed!
> Moreover, this morning, I compiled XE and it worked and I
> discovered the
> XWiki-Core JAR was simply empty: no class inside :)
>
> I'm going to try extracting module per module and see if I can
> compile...
> and finally if I can't, I will install 3.3 or a standalone maven...
>
> Last week I have spent several days trying to compile with Java64
> under
> Eclipse64 but there was too many bugs that I came back to Java32
> under
> Eclipse32 and now Maven is ennoying me :)...
>
>
>
>>
>>>
>>> One other question about something I remark:
>>> when compiling, I see this tens of times:
>>> url =
http://maven.xwiki.org/externals
>>> Downloading:
>>>
>>
>
http://maven.xwiki.org/externals/groovy/groovy-all-1.0-jsr/06/groovy-all-1.…
>>> url =
http://maven.xwiki.org/releases
>>> Downloading:
>>>
>>
>
http://maven.xwiki.org/releases/groovy/groovy-all-1.0-jsr/06/groovy-all-1.0…
>>> url =
http://repo1.maven.org/maven2
>>> Downloading:
>>>
>>
>
http://repo1.maven.org/maven2/groovy/groovy-all-1.0-jsr/06/groovy-all-1.0-j…
>>>
>>> Apparently, it doesn't see it has already downloaded it... Do you
>>> know
>> why?
>>
>> It's because it did not already downloaded it :) The problem is that
>> this groovy version is wrongly packaged and does not have any
>> pom.xml
>> (look at
http://repo1.maven.org/maven2/groovy/groovy-all-1.0-jsr/06/)
>> .
>>
>
>
> Ok I see... sometime there is the error, sometimes not :)
>
>
>
>>
>>>
>>> So finally, compiling module per module triggering some options
>>> is OK
> but
>>> compiling from scratch implies skipping tests...
>>>
>>> Pascal