Glad it helped :) It's a bit tricky to write tests when you have oldcore in your dependencies.
On Mon, Jun 11, 2012 at 3:55 PM, Jeremie BOUSQUET <[email protected]> wrote: > Hi Thomas, > > Thanks, this is great and I don't think I would have found the solution alone > :) > > I've merged it into master and started implementation of some tests, > that all pass now. > (Git is a mysterious tool, it puzzles me but does the job I want anyway :D) > > Thanks, > Jeremie > > 2012/6/8 Thomas Mortagne <[email protected]>: >> Hi Jeremie, >> >> I did a but of build cleanup based on mastert branch and pushed it in >> mavencleanup branch. I also worked on your test setup, should be >> better now, theyr are still failing but the remaining issue seems to >> be purely on your side (use in the test a variable that has not been >> initialized yet, etc.) ;) >> >> Will let you review and fix my mistakes before merging. >> >> On Fri, Jun 8, 2012 at 10:46 AM, Jeremie BOUSQUET >> <[email protected]> wrote: >>> Hello, >>> >>> I eventually managed to publish the project to contrib ... :) Git >>> wasn't very nice with me when I had to remove some files from the >>> whole history (to remove my password) :D >>> If you want to have a look, don't forget it's highly unstable for now >>> and many things remain to do (so long ...). I didn't even perform >>> basic tests on this version and it seems that it does not compile for >>> any reason. >>> If someone wants to try make one of the unit test at least pass the >>> component initialize() I would be greatful, as I'm still stuck on that >>> and it must be something really stupid though. UTs are really missing >>> ... >>> >>> I also want to push the .pst import to a dedicated branch for now, and >>> remove it from master, until the lib problem is solved. >>> >>> Thanks, >>> Jeremie >>> >>> >>> >>> 2012/5/30 Jeremie BOUSQUET <[email protected]>: >>>> Ok I'll do that - thanks for the link, anyway I won't use it right >>>> away. I'm not even sure .pst import is a feature that would interest >>>> people or not. Will give some time to have feedbacks from the author >>>> of the lib and/or sonatype :) >>>> Sorry for mstor, I thought I had searched central for it :/ >>>> >>>> 2012/5/30 Thomas Mortagne <[email protected]>: >>>>> On Wed, May 30, 2012 at 9:40 AM, Jeremie BOUSQUET >>>>> <[email protected]> wrote: >>>>>> Something different : I have 2 "system" scoped dependencies in maven >>>>>> poms. >>>>>> In fact I have 2 dependencies (for now) that do not exist in Xwiki >>>>>> nexus repository. So before submitting this to your opinion, I've set >>>>>> them as system and used them locally, ugly but temporary. >>>>>> The dependencies are mstor 0.9.13 (a Store provider for Javamail) and >>>>> >>>>> http://search.maven.org/#search|ga|1|mstor >>>>> >>>>>> java-libpst (as library to do .pst import), links and versions are >>>>> >>>>> Can't find this one. If there is really no alternative I can add it to >>>>> http://maven.xwiki.org/externals/ I guess but the best would be to add >>>>> it to maven central or suggest them to do it if they are still a bit >>>>> alive. See >>>>> https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+Maven+Central. >>>>> >>>>>> available on the Design page. >>>>>> >>>>>> Would you mind adding those libs to the xwiki nexus repository ? I >>>>>> don't think they exist in any maven repository for now (and they are a >>>>>> bit old and inactive or seems so) ? >>>>>> Or should I make those features optional, and if the user want them, >>>>>> ask him to populate his wiki instance with the dedicated .jar files ? >>>>>> The PST import is more a nice-to-have feature that could be optional. >>>>>> The Store feature is more important. >>>>>> >>>>>> Additionally mstor needs 2 other dependencies to "work" (at least ... >>>>>> the bundle comes with many deps but I needed only 2 to make it work) : >>>>>> ehcache 1.4.1 and backport-util-concurrent 3.1. >>>>>> I don't really like >>>>>> adding new libraries in WEB-INF/lib without really knowing the impact >>>>>> or possible conflicts with existing libs, but I did not find a better >>>>>> solution for now ... And mstor is the best and easiest I found so far >>>>>> to achieve my use-case ... (backup/restore loaded emails, reload after >>>>>> structural migration, ...). JavamailDir creates a file per email >>>>>> stored, that can be an issue on Linux systems as you can easily reach >>>>>> inodes nb limitations. >>>>>> >>>>>> Thanks, >>>>>> Jeremie >>>>>> >>>>>> 2012/5/29 Jeremie BOUSQUET <[email protected]>: >>>>>>> Ok it's clearer now thanks :) >>>>>>> >>>>>>> 2012/5/29 Vincent Massol <[email protected]>: >>>>>>>> >>>>>>>> On May 29, 2012, at 5:46 PM, Sergiu Dumitriu wrote: >>>>>>>> >>>>>>>>> On Tuesday, May 29, 2012, Jeremie BOUSQUET >>>>>>>>> <[email protected]> >>>>>>>>> wrote: >>>>>>>>>> Well, I have no problem to use "org.xwiki.contrib" for groupId >>>>>>>>>> (though >>>>>>>>>> I personnally don't like to put unrelated projects at same level in >>>>>>>>>> repositories), >>>>>>>> >>>>>>>> Yes and thanks Sergiu for correcting me. I wasn't thinking straight >>>>>>>> when I first replied to Jeremie. >>>>>>>> >>>>>>>>>> but I don't really understand the motivation to use >>>>>>>>>> org.xwiki.contrib.mailarchive for the java package ... >>>>>>>>>> Well I understand it, but as I started this as a component, I used >>>>>>>>>> the >>>>>>>>>> usual packages for components, ie "org.xwiki.component.mailarchive". >>>>>>>>>> Should I really refactor my code to use "contrib" instead of >>>>>>>>>> "component" ? >>>>>>>> >>>>>>>> Yes. >>>>>>>> >>>>>>>> org.xwiki.* is reserved for the XWiki Dev team except for >>>>>>>> org.xwiki.contrib.* which is reserved for contrib projects. >>>>>>>> >>>>>>>> Also your code is not related to the component module >>>>>>>> (org.xwiki.component is reserved for the Component module) so it >>>>>>>> wouldn't make much sense to use org.xwiki.component. >>>>>>>> >>>>>>>>>> Do you mean that if a component makes it way from >>>>>>>>>> contrib to xwiki core, you change the java package naming ? >>>>>>>> >>>>>>>> Yes, that's the current strategy. With modern IDEs, renaming is quite >>>>>>>> fast. >>>>>>>> >>>>>>>> Note that the target package (if moved in platform) would be >>>>>>>> org.xwiki.mailarchive (if we agree about the "mailarchive" module >>>>>>>> name). >>>>>>>> >>>>>>>>>> I'm a bit >>>>>>>>>> surprised but I'll do as you defined of course. >>>>>>>>> >>>>>>>>> Hmm... Vincent, WDYT? >>>>>>>> >>>>>>>> Thanks >>>>>>>> -Vincent >>>>>>>> >>>>>>>>>> 2012/5/29 Sergiu Dumitriu <[email protected]>: >>>>>>>>>>> On 05/29/2012 04:07 AM, Jeremie BOUSQUET wrote: >>>>>>>>>>>> >>>>>>>>>>>> Dear community, >>>>>>>>>>>> >>>>>>>>>>>> I would like to request for a new contrib project to store the Mail >>>>>>>>>>>> Archive application I'm currently writing. >>>>>>>>>>>> >>>>>>>>>>>> Name: xwiki-application-mailarchive >>>>>>>>>>>> Description: A mailing-list archive application. >>>>>>>>>>>> >>>>>>>>>>>> - For now a GitHub project to store sources should be fine. My >>>>>>>>>>>> username on GitHub is "jbousque". >>>>>>>>>>>> - For Jira it might be useful to have a project once the >>>>>>>>>>>> application >>>>>>>>>>>> is released "officially", that is still not the case. Meanwhile the >>>>>>>>>>>> generic project is ok for me. >>>>>>>>>>>> - There is a specific page in Design space on xwiki.org : >>>>>>>>>>>> http://dev.xwiki.org/xwiki/bin/view/Design/MailArchiveApplication , >>>>>>>>>>>> but for now no extension has been added. I would like if possible >>>>>>>>>>>> to >>>>>>>>>>>> test my extension (automatic install with dependencies) before >>>>>>>>>>>> publishing it >>>>>>>>>>>> >>>>>>>>>>>> The Design page also gives some info about the current state and >>>>>>>>>>>> progress, and some screenshots. There is many remaining work, but >>>>>>>>>>>> it >>>>>>>>>>>> begins to look like something usable. The bad side is the lack of >>>>>>>>>>>> unit >>>>>>>>>>>> tests most of all ... >>>>>>>>>>>> >>>>>>>>>>>> A question : the groupId "org.xwiki.contrib" is to be used, do I >>>>>>>>>>>> have >>>>>>>>>>>> to use this exact groupId or can there be sublevels if needed ? >>>>>>>>>>>> If so I would use org.xwiki.contrib.mailarchive as groupId. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The groupId should be org.xwiki.contrib, but "groupId" means the >>>>>>>>>>> groupId >>>>>>>>>>> part of the maven artifact identity. >>>>>>>>>>> >>>>>>>>>>> However, the java package name *should* be >>>>>>>>>>> org.xwiki.contrib.mailarchive >>>>>>>>>>> -- >>>>>>>>>>> Sergiu Dumitriu >>>>>>>>>>> http://purl.org/net/sergiu/ >>>>>>>> _______________________________________________ >>>>>>>> devs mailing list >>>>>>>> [email protected] >>>>>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>>>> _______________________________________________ >>>>>> 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 >> >> >> >> -- >> 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 -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
