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