On Thu, Aug 14, 2008 at 12:13 PM, Thomas Mortagne <[EMAIL PROTECTED] > wrote:
> On Thu, Aug 14, 2008 at 10:35 AM, Pascal Voitot > <[EMAIL PROTECTED]> 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.0-jsr-06.pom > > url = http://maven.xwiki.org/releases > > Downloading: > > > http://maven.xwiki.org/releases/groovy/groovy-all-1.0-jsr/06/groovy-all-1.0-jsr-06.pom > > url = http://repo1.maven.org/maven2 > > Downloading: > > > http://repo1.maven.org/maven2/groovy/groovy-all-1.0-jsr/06/groovy-all-1.0-jsr-06.pom > > > > 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 > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > -- > Thomas Mortagne > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
