9 Sep
2016
9 Sep
'16
12:07 p.m.
I'm really not a fan of this idea:
* there is way too much maintaining work both for the extension and
for platform and contrib parent and the possible mistakes which go
with it
* it does not make sense to build the extension on latest versions of
platform because that's not what your are going to release and it
makes impossible to use APIs that have been moved to legacy in latest
version of XE
* in practice what we really want to verify most of the time when we
test with latest version is if we broke something on platform so what
would really be useful IMO is not to test the extension on latest
stable but on latest SNAPSHOT
So my preference actually goes to the opposite. What I would like us
to end up with eventually is some system where you indicate
* the id(s) of your extension(s) to install
* the id of the jar containing the integration tests (that the
extension should deploy), it also means that we need to not break
anything in the integration test framework (we really not been very
careful about that for now)
* the version of XWiki on which you want to tests it (usually the last
SNAPHOT or stable probably since the tests on the version the
extension depends on will still be executed in the extension build
itself)
then this platform get the platform or enterprise jetty/hsqldb
package, install the last SNAPSHOT of your extension on it and run the
tests located in the test jar provide by the extension
In the meantime here is a possible quick hack that should be doable I
guess: at the root of platform add a new module xwiki-platform-tests
containing a submodule for each extension we want to use to do retro
compatibility. Each module will get platform jetty/hsqldb and we
implement a new org.junit.runners.Suite which call EM URLs to install
the latest version of the extension and execute the tests located in
the jar containing the integration tests (the extension need to deploy
this jar during its build). Each extension is free to propose a pull
request to add itself to the build. Then we can either have a single
Jenkins job for the whole xwiki-platform-tests or create a new job for
each submodule.
On Fri, Sep 9, 2016 at 11:14 AM, Vincent Massol <vincent(a)massol.net> wrote:
--
Thomas Mortagne
On 09 Sep 2016, at 10:51, Vincent Massol
<vincent(a)massol.net> wrote:
Hi devs,
Context
=======
I’d like to propose a new best practice for extensions and especially recommended ones.
We already have the following on
http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPra…:
"In your POM always try to depend on the oldest version of
commons/rendering/platform dependencies for which your code works. At least, ensure that
your Applications works on the latest LTS version of XWiki. This will allow the largest
number of users to use your application.”
In addition on the definition of a Recommended Extension at
http://extensions.xwiki.org/xwiki/bin/view/ExtensionCode/RecommendedExtensi…
we say:
“Works at least with the latest stable XWiki versions and with the LTS version”
This proposal is about ensuring that an extension works with the latest stable XWiki
version.
Proposal
========
1) Always create a LATEST branch for recommended extensions
2) On this branch depend on LATEST for parent pom. For example:
<parent>
<groupId>org.xwiki.commons</groupId>
<artifactId>xwiki-commons-pom</artifactId>
<version>LATEST</version>
</parent>
Note 1: For extensions using https://github.com/xwiki-contrib/parent we also need to
release latest version of those poms as part of the XWiki
commons/rendering/platform/enterprise release process.
Note 2: The advantage of using LATEST is that it doesn’t require maintenance from the
extensions whenever new versions of XWiki commons/rendering/platform/enterprise are
released. It does require to update the contrib parent poms though.
Actually I’ve just realized that this is not true… When you make changes to master you
need to backport them to the LATEST release branch too so it could be quite tedious
actually.
Any idea to salvage this proposal to have something that can be applied today?
The other solution (but it’s much more work and not for today) would be to find ways to
modify the PackageMojo code to support running XWiki under various versions.
Thanks
-Vincent
3) On ci.xwiki.org, make sure that the job is
defined to build 2 branches. You can also leave the branch name empty and Jenkins will
then build all available branches as I’ve done for IRC Bot app:
http://ci.xwiki.org/job/Contrib%20-%20IRC%20Bot%20Application/configure (check the “Source
Code Management” section).
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs