Hi All, What's the situation of this ? Can we safely build / test / develop xwiki with ganymede ? :) Thanks. - Asiri On Thu, Aug 14, 2008 at 5:46 PM, Pascal Voitot <pascal.voitot.dev@gmail.com>wrote:
On Thu, Aug 14, 2008 at 12:13 PM, Thomas Mortagne < thomas.mortagne@xwiki.com
wrote:
On Thu, Aug 14, 2008 at 10:35 AM, Pascal Voitot <pascal.voitot.dev@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.0...
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-js...
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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs