8 Oct
2012
8 Oct
'12
3:02 p.m.
Thanks for explainations ! :)
Well, I believe my target anyway will be 4.x (and only 4.x),
compatibility for 3.x is mainly for my own use-case of replacing the
old app in production with the new component. Once it's done (and my
own wiki migrated to 4.x) I don't think I will bother with 3.x
compatibility anymore ...
So of course if this timeframe is really short I might not even bother
with a 3.x at all, but it all depends on my ability to releasing a
real 1.0 soon ;-) ... (I feel I'm a bit far from that to be honest)
Thanks,
Jeremie
2012/10/8 Vincent Massol <vincent(a)massol.net>et>:
On Oct 8, 2012, at 1:12 PM, Jeremie BOUSQUET <jeremie.bousquet(a)gmail.com> wrote:
About branch for 3.5.1, I wonder if there is a
way to properly manage
that with extensions manager ?
Is it possible to provide a specific extension artifact for users
running xwiki 3.5.1 and another one for 4.x ?
You can have as many versions as you want of your module.
The EM can install any version. By default it'll pick the latest version compatible
with your install but you can ask it to use any specific version.
What you need to figure out (if you need 3.x compatibility) is how to name the version.
You basically have 2 solutions:
Solution 1: You use the xwiki version in the name of your module
========
Example:
* xwiki-contrib-mailarchive-ui-3x-0.2 based on XE 3x
* xwiki-contrib-mailarchive-ui-4x-0.2 based on XE 4x
And when you need to release a new version for XE 3.x you use for example:
* xwiki-contrib-mailarchive-ui-3x-0.3 based on XE 3x
Or instead of 3x and 4x you use the exact version of XE it requires:
* xwiki-contrib-mailarchive-ui-3.5.1-0.2 based on XE 3.5.1
* xwiki-contrib-mailarchive-ui-4.2-0.2 based on XE 4.2
(note to self: need to check with Thomas what version the EM think is the most recent in
this case - I don't know our algorithm - I guess it's alphetical so 4.2-0.2 will
be considered more recent than 3.5.1-0.3).
Solution 2: You just specify in the release notes what's the minimal version required
for a given version
========
Example:
* xwiki-contrib-mailarchive-ui-0.2 - Works with XE 3.x
* xwiki-contrib-mailarchive-ui-0.3 - Works with XE 4.x
And when you need to release a new version for XE 3.x you use for example:
xwiki-contrib-mailarchive-ui-0.2.1
It's not fully correct since it may not be a bugfix release so this second solution
works best when you follow the XE releases and only issue bugfix releases for past XE
versions.
The most correct solution is Solution 1 of course.
Hope it helps,
-Vincent
PS: It's always a pain to maintain several branches, so you really need to decide if
you want to do that or just maintain one branch… ;)
Or is it just too painful and useless, at once,
to not just provide
the extension for last xwiki version ?
2012/10/7 Jeremie BOUSQUET <jeremie.bousquet(a)gmail.com>om>:
> Hi again,
>
> - I pushed last updated code to git, so that version should be better
> ... But I'm still having issues building it, so you should add
> "-Dmaven.test.failure.ignore=true" to maven cli. It's a problem I
> still couldn't solve: the junits for MailUtils component (in -api)
> fail because of xwiki not finding roles for this component, while when
> the app is deployed to a running xwiki, MailUtils component is
> instanciated without any issue.
> Time for an additional question : there are some specific things to do
> to unit test a component that depends on old core, but are there any
> for a component that depends on a component that depends on old core ?
> - About moving to more recent xwiki version I agree, I'll create a
> branch for 3.5.1. Will also be a motivation to finish migrating my
> wiki to recent version :)
> - I added MailArchiveCode.UIExtension for application panel, doesn't
> it work ? Did not test in a 4.x myself so I'm not sure.
> - added dependency on Tabs Macro from Mail Archive App extension, but
> it's not listed in the page... I must have done something wrong.
> - added dependency on -api from -ui
>
> Br,
> Jeremie
>
>
> 2012/10/7 Jeremie BOUSQUET <jeremie.bousquet(a)gmail.com>om>:
>> Answers below,
>>
>>
>> 2012/10/7 Vincent Massol <vincent(a)massol.net>et>:
>>> Some more feedback:
>>>
>>> * You should put all your technical code in the MailArchiveCode space. I see
you're putting pages in existing spaces which is not that good: Scheduler, Extension,
XApp.
>> For Scheduler and xApp I agree, though it's the default behaviour of
>> scheduler and application manager apps to put their descriptors in
>> their space.
>> For Extension it was of our decision to put documentation in Extension
>> space on xwiki.org. I wanted to have the pages in the same relative
>> location but anyway as I can't import those pages in xwiki.org it's
>> useless, so I'll set them back in MailArchive space (they are not
>> technical pages but documentation pages).
>>
>>> * You should mark all the technical pages as hidden docs.
>> I don't think it existed in 3.5.1, that's why I didn't set them ;-)
>>
>>> * You should have a package.xml file since it's generated automatically
:)
>> I understand that I "shouldn't have" a package.xml file, am I right
?
>>
>>> * I see a java-libpst jar in some lib/ dir. This lib should be in maven if
it's required.*
>> It's supposed to be used by experimental feature in specific branch,
>> so I should remove it completely from master.
>>
>>> * MailArchive UI module is missing dependencies; it should depend on
xwiki-contrib-mailarchive-api for ex at least
>> I'll fix that.
>>
>> I really appreciate your feedbacks !
>> For git I'll send a mail when fixed, because I don't exactly remember
>> how far I went, I'll have to test that before committing.
>> Thanks,
>> Jeremie
>>
>>>
>>> Thanks
>>> -Vincent
>>>
>>> On Oct 7, 2012, at 2:34 PM, Vincent Massol <vincent(a)massol.net> wrote:
>>>
>>>> Hi Jeremie,
>>>>
>>>> I've tried using version 0.1 this week end and I've found that it
doesn't work and is missing things. For example, it requires the tab macro which
isn't specified as a dependency. And some pages have velocity macro failures.
>>>>
>>>> I've then tried to build the mailarchive app from git in the hope
that some more recent commits fixed the issues but I couldn't built it. The build
fails with:
>>>>
>>>> "Results :
>>>>
>>>> Failed tests:
decodeMailContentForHtmlAndNoBodyAndCut(org.xwiki.contrib.mailarchive.internal.MailUtilsTest):
To be implemented
>>>>
>>>> Tests in error:
>>>>
extractTypesWithLimitValues(org.xwiki.contrib.mailarchive.internal.DefaultMailArchiveTest):
Failed to lookup component [org.xwiki.contrib.mailarchive.internal.DefaultMailArchive] for
role [org.xwiki.contrib.mailarchive.IMailArchive] and hint [default]
>>>>
extractTypesForNominalCases_OtherType(org.xwiki.contrib.mailarchive.internal.DefaultMailArchiveTest):
Failed to lookup component [org.xwiki.contrib.mailarchive.internal.DefaultMailArchive] for
role [org.xwiki.contrib.mailarchive.IMailArchive] and hint [default]
>>>>
extractTypesForMultiplePatternsAndTypes(org.xwiki.contrib.mailarchive.internal.DefaultMailArchiveTest):
Failed to lookup component [org.xwiki.contrib.mailarchive.internal.DefaultMailArchive] for
role [org.xwiki.contrib.mailarchive.IMailArchive] and hint [default]
>>>>
>>>> Tests run: 10, Failures: 1, Errors: 3, Skipped: 0
>>>> "
>>>>
>>>> I've also noticed that on master the core dep is 3.5.1 which is
pretty old. I'd like to update this to 4.3-SNAPSHOT and when you perform a release you
resolve the snapshot to whatever version is the latest released (ATM that would be 4.2 and
later on that would be 4.3-milestone-1 for ex).
>>>>
>>>> If you still need to depend on 3.5.1, it should be done on a branch of
the mail archive app IMO.
>>>>
>>>> It would be nice for ex to be able to use the Application panel extension
point.
>>>>
>>>> WDYT?
>>>>
>>>> I'm now going to try building with -DskipTests and pray it's
going to run ;-)
>>>>
>>>> Thanks
>>>> -Vincent
>>>>
>>>> PS: I'm still very eager to see it in action!
>>>