About branch for 3.5.1, I wonder if there is a way to properly manage that with extensions manager ? Is it possible to provide a specific extension artifact for users running xwiki 3.5.1 and another one for 4.x ? Or is it just too painful and useless, at once, to not just provide the extension for last xwiki version ?
2012/10/7 Jeremie BOUSQUET <[email protected]>: > Hi again, > > - I pushed last updated code to git, so that version should be better > ... But I'm still having issues building it, so you should add > "-Dmaven.test.failure.ignore=true" to maven cli. It's a problem I > still couldn't solve: the junits for MailUtils component (in -api) > fail because of xwiki not finding roles for this component, while when > the app is deployed to a running xwiki, MailUtils component is > instanciated without any issue. > Time for an additional question : there are some specific things to do > to unit test a component that depends on old core, but are there any > for a component that depends on a component that depends on old core ? > - About moving to more recent xwiki version I agree, I'll create a > branch for 3.5.1. Will also be a motivation to finish migrating my > wiki to recent version :) > - I added MailArchiveCode.UIExtension for application panel, doesn't > it work ? Did not test in a 4.x myself so I'm not sure. > - added dependency on Tabs Macro from Mail Archive App extension, but > it's not listed in the page... I must have done something wrong. > - added dependency on -api from -ui > > Br, > Jeremie > > > 2012/10/7 Jeremie BOUSQUET <[email protected]>: >> Answers below, >> >> >> 2012/10/7 Vincent Massol <[email protected]>: >>> Some more feedback: >>> >>> * You should put all your technical code in the MailArchiveCode space. I >>> see you're putting pages in existing spaces which is not that good: >>> Scheduler, Extension, XApp. >> For Scheduler and xApp I agree, though it's the default behaviour of >> scheduler and application manager apps to put their descriptors in >> their space. >> For Extension it was of our decision to put documentation in Extension >> space on xwiki.org. I wanted to have the pages in the same relative >> location but anyway as I can't import those pages in xwiki.org it's >> useless, so I'll set them back in MailArchive space (they are not >> technical pages but documentation pages). >> >>> * You should mark all the technical pages as hidden docs. >> I don't think it existed in 3.5.1, that's why I didn't set them ;-) >> >>> * You should have a package.xml file since it's generated automatically :) >> I understand that I "shouldn't have" a package.xml file, am I right ? >> >>> * I see a java-libpst jar in some lib/ dir. This lib should be in maven if >>> it's required.* >> It's supposed to be used by experimental feature in specific branch, >> so I should remove it completely from master. >> >>> * MailArchive UI module is missing dependencies; it should depend on >>> xwiki-contrib-mailarchive-api for ex at least >> I'll fix that. >> >> I really appreciate your feedbacks ! >> For git I'll send a mail when fixed, because I don't exactly remember >> how far I went, I'll have to test that before committing. >> Thanks, >> Jeremie >> >>> >>> Thanks >>> -Vincent >>> >>> On Oct 7, 2012, at 2:34 PM, Vincent Massol <[email protected]> wrote: >>> >>>> Hi Jeremie, >>>> >>>> I've tried using version 0.1 this week end and I've found that it doesn't >>>> work and is missing things. For example, it requires the tab macro which >>>> isn't specified as a dependency. And some pages have velocity macro >>>> failures. >>>> >>>> I've then tried to build the mailarchive app from git in the hope that >>>> some more recent commits fixed the issues but I couldn't built it. The >>>> build fails with: >>>> >>>> "Results : >>>> >>>> Failed tests: >>>> decodeMailContentForHtmlAndNoBodyAndCut(org.xwiki.contrib.mailarchive.internal.MailUtilsTest): >>>> To be implemented >>>> >>>> Tests in error: >>>> >>>> extractTypesWithLimitValues(org.xwiki.contrib.mailarchive.internal.DefaultMailArchiveTest): >>>> Failed to lookup component >>>> [org.xwiki.contrib.mailarchive.internal.DefaultMailArchive] for role >>>> [org.xwiki.contrib.mailarchive.IMailArchive] and hint [default] >>>> >>>> extractTypesForNominalCases_OtherType(org.xwiki.contrib.mailarchive.internal.DefaultMailArchiveTest): >>>> Failed to lookup component >>>> [org.xwiki.contrib.mailarchive.internal.DefaultMailArchive] for role >>>> [org.xwiki.contrib.mailarchive.IMailArchive] and hint [default] >>>> >>>> extractTypesForMultiplePatternsAndTypes(org.xwiki.contrib.mailarchive.internal.DefaultMailArchiveTest): >>>> Failed to lookup component >>>> [org.xwiki.contrib.mailarchive.internal.DefaultMailArchive] for role >>>> [org.xwiki.contrib.mailarchive.IMailArchive] and hint [default] >>>> >>>> Tests run: 10, Failures: 1, Errors: 3, Skipped: 0 >>>> " >>>> >>>> I've also noticed that on master the core dep is 3.5.1 which is pretty >>>> old. I'd like to update this to 4.3-SNAPSHOT and when you perform a >>>> release you resolve the snapshot to whatever version is the latest >>>> released (ATM that would be 4.2 and later on that would be 4.3-milestone-1 >>>> for ex). >>>> >>>> If you still need to depend on 3.5.1, it should be done on a branch of the >>>> mail archive app IMO. >>>> >>>> It would be nice for ex to be able to use the Application panel extension >>>> point. >>>> >>>> WDYT? >>>> >>>> I'm now going to try building with -DskipTests and pray it's going to run >>>> ;-) >>>> >>>> Thanks >>>> -Vincent >>>> >>>> PS: I'm still very eager to see it in action! >>> _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
