30 May
2012
30 May
'12
11:57 a.m.
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 <thomas.mortagne(a)xwiki.com>om>:
On Wed, May 30, 2012 at 9:40 AM, Jeremie BOUSQUET
<jeremie.bousquet(a)gmail.com> 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+….
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 <jeremie.bousquet(a)gmail.com>om>:
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs Ok it's clearer now thanks :)
2012/5/29 Vincent Massol <vincent(a)massol.net>et>:
>
> On May 29, 2012, at 5:46 PM, Sergiu Dumitriu wrote:
>
>> On Tuesday, May 29, 2012, Jeremie BOUSQUET <jeremie.bousquet(a)gmail.com>
>> 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 <sergiu(a)xwiki.com>om>:
>>>> 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
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs