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 java-libpst (as library to do .pst import), links and versions are 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
