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
