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 <[email protected]> wrote: > >> On 09 Sep 2016, at 10:51, Vincent Massol <[email protected]> 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/ApplicationDevelopmentBestPractices: >> "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/RecommendedExtensions/RecommendedDefinition/ >> 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 > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
