3 Feb
2013
3 Feb
'13
6:30 p.m.
I just tested installation from EM from xwiki.org repository, and it seems
to install correctly :)
I'll try my best not to wait so long for next version ... That one is far
from perfect but should be far more usable than 0.1 thanksfully.
2013/2/3 Jeremie BOUSQUET <jeremie.bousquet(a)gmail.com>
Thanks Vincent !
Maybe I'm wrong, but I didn't want to use the original groupId of this
mstor artifact, because its dependencies are slightly modified compared to
the original. I think it would introduce the false impression of relying on
the original artifact, while it's not really the case.
If someone depends on it, thinking it's the original, in a standalone
environment, it might not work as expected. While "my" version with
different transitive dependencies, is the only one that works without
conflicting with XE.
For these complex cases, might be nice that EM manages maven exclusions,
though maybe it's a big work for not so frequent use-case.
Nexus config can be somewhat tricky ;-) I know it a little but not pro
features as staging and promotion.
Thanks again,
Jeremie
2013/2/3 Vincent Massol <vincent(a)massol.net>
On Feb 3, 2013, at 5:05 PM, Jeremie BOUSQUET <jeremie.bousquet(a)gmail.com>
wrote:
:)
http://xwiki.markmail.org/search/?q=mstor#query:mstor+page:1+mid:owjykurnlz…
Hi Vincent,
2013/2/3 Vincent Massol <vincent(a)massol.net>
> Hi Jeremie,
>
> On Feb 3, 2013, at 4:15 PM, Jeremie BOUSQUET <
jeremie.bousquet(a)gmail.com>
wrote:
> Hello devs,
>
> Please could you promote release 0.2 of mail archive app in your nexus
> repository ?
Cool :)
Seen that you had some issues to release it? Anything we can help with?
Nothing, except by me some better brains, so I don't forget my GPG
passphrase next time ;-) >> groupId:
>> org.xwiki.contrib.mailarchive
>> artifactIds:
>> xwiki-contrib-mail
>> xwiki-contrib-mailarchive-api
>> xwiki-contrib-mailarchive-ui
>> mstor
>
> I was about to do it when I noticed mstor. What is this? If this is a
3rd
party lib
why publish it with the org.xwiki.contrib.mailarchive groupid
instead of using its own groupid as we do for other 3rd paty libs?
See discussion
Basically, I need mstor library to create a
Javamail store (to
backup/reload emails), but this library comes with extra transitive
dependencies, that conflict with XE.
I solved that by publishing that lib along my project, without the
conflicting (and useless) transitive deps.
I've read the discussion again and still didn't understand why you needed
to publish that artifact under your own groupid vs publishing it with a
proper groupid.
Anyway I've promoted and released your artifacts. The nexus config looks
very complex now and I don't master it (I had to close, promote and release
which sounds like a lot of steps!)… We also need to give you direct
permissions to do that IMO but I don't know the config well enough to do
that now. Maybe Sergiu knows since I think he configured that?
Thanks
-Vincent
> Thanks
> -Vincent
>
>> Thanks !
>>
>> BR,
>> Jeremie
>>
>>
>> 2012/12/13 Jeremie BOUSQUET <jeremie.bousquet(a)gmail.com>
>>
>>> Ok I removed them.
>>> Thought about something, is that main problem is if someone wants to
>>> install it manually, ie without the Extension Manager, he would have
to
>>> retrieve the transitive dependencies
"by hand".
>>> But as my target is XE 4.X, I'm wondering if it's useful anyway to
allow
>>> users installing such extension
manually, as it's faaar more easy
using
> EM.
>>>
>>>
>>> 2012/12/7 Thomas Mortagne <thomas.mortagne(a)xwiki.com>
>>>
>>>> On Fri, Dec 7, 2012 at 2:52 PM, Jeremie BOUSQUET <
>>>> jeremie.bousquet(a)gmail.com
>>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>>
>>>>> 2012/9/14 Vincent Massol <vincent(a)massol.net>
>>>>>
>>>>>>
>>>>>> On Sep 14, 2012, at 9:13 AM, Jeremie BOUSQUET <
>>>>> jeremie.bousquet(a)gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I guess I have to create an extension page for each artifact
?
(mail
>>>>>>> extension,
mailarchive api extension, mail archive ui extension)
>>>>>>> Didn't had time to test within extension repository
manager
locally,
>>>>>>> so I hope it'll
work ! :)
>>>>>>
>>>>>> No don't create one per artifact. To start with I'd
suggest just
one
>>>> for
>>>>>> the UI module. The other artifacts are already in an extension
>>>> repository
>>>>>> since they're in maven.xwiki.org ;)
>>>>>>
>>>>>> Thanks
>>>>>> -Vincent
>>>>>>
>>>>>>
>>>>> Back to this, since I didn't see that recommendation, at that
time
I
>>>>> created 3 extension pages for
the 3 modules (and not only for UI):
>>>>> (UI)
>>>>>
>>>>>
>>>>
>
http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Application
>>>>> (mail api)
>>>>>
>>>>>
>>>>
>
http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Mail+Module
>>>>> (mail archive api)
>>>>>
>
http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Module
>>>>>
>>>>> As the last 2 do not really need to be materialized in
>>>>> extensions.xwiki.org,
>>>>> and lead to more maintenance from my side, and more confusion on
users
>>>>> side, I would like to remove
these 2 pages from
extensions.xwiki.org,
>>>> and
>>>>> move some of their content to the Design page related to the
> MailArchive
>>>>> Application.
>>>>>
>>>>> Since those 2 were already published, from users point of view it
> means
>>>> 2
>>>>> extensions will "disappear" from the catalog.
>>>>> So I wanted to check with you if it's not a bad practice to do
that,
>>>> and if
>>>>> I can safely remove those 2 extensions (according to the fact,
also,
>>>> that
>>>>> the whole thing is tagged as "BETA").
>>>>>
>>>>
>>>> There is no official practice on this yet. IMO you can do this is
you
>>>> think
>>>> it's the cleaner like this.
>>>>
>>>> It's not going to break anything for users unless there is other
>>>> extensions
>>>> depending of these extensions in which case they won't be able to
> install
>>>> them of course.
>>>>
>>>>
>>>>> Thanks,
>>>>> Jeremie
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs