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
