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
