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
