Well not completely in fact: the main concert is about AJDT which seems to have lot's of problems with our aspect since aspectJ 1.6 and the last version based on aspectJ 1.5 does not work well with Eclipse 3.4. I guess the problem can be fixed by someone who knows aspectJ better than me simply by fixing our aspectJ files.
On Fri, Sep 12, 2008 at 9:35 PM, Vincent Massol <[EMAIL PROTECTED]> wrote: > > On Sep 12, 2008, at 9:14 PM, Asiri Rathnayake wrote: > >> Hi All, >> >> What's the situation of this ? >> >> Can we safely build / test / develop xwiki with ganymede ? :) > > Sure. > > -Vincent > >> On Thu, Aug 14, 2008 at 5:46 PM, Pascal Voitot >> <[EMAIL PROTECTED]>wrote: >> >>> 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
