On Thu, Mar 19, 2015 at 11:54 AM, [email protected] <[email protected]> wrote: > Hi Jean, > > On 19 Mar 2015 at 10:46:22, Jean SIMARD > ([email protected](mailto:[email protected])) wrote: > >> OK, but if we don't keep track of the relocation of groupId/artifactId, >> I wonder how you will be able to manage the upgrade (since it seems it >> is a topic you and Vincent are interested in). Am I missing something? >> Should I put this information in another way somewhere in the root POM >> or in another file? > > Yes I wasn’t talking about Maven Relocation but about XWiki’s EM relocation > (aka alias or extension features). > > This is how to indicate a relocation in our pom.xml: > > <properties> > <xwiki.extension.features> > <!-- Old names of this module used for retro compatibility when > resolving dependencies of old extensions --> > org.xwiki.platform:xwiki-platform-workspace-template-features > </xwiki.extension.features> > </properties> > > Thanks > -Vincent >
> PS: Side note: I’ve never understood why Thomas decided to use the “features” > terminology for relocation. Maybe you can explain what you had in mind > Thomas? :) It's not used just for relocation. We use it whenever we want to specify that an extension X bundles another extension Y, or that X provides the features of extension Y, or simply put: X features Y. From https://www.google.com/?#q=define:feature "the hotel features a large lounge, a sauna, and a coin-operated solarium". Thanks, Marius > >> Sincerely, >> >> On 19/03/2015 10:41, Thomas Mortagne wrote: >> > Vincent was not really talking about Maven relocation specifically but >> > simply how to EM can find the new version of an extension that changed >> > its id. >> > >> > On Thu, Mar 19, 2015 at 10:39 AM, Jean SIMARD wrote: >> >> Hi Vincent, >> >> >> >> I'd like to have more precision on the "relocation" you're talking about. >> >> >> >> For example, we have this at the moment >> >> >> >> + application-forum >> >> | + pom.xml >> >> ->org.xwiki.contrib.forum:application-forum [xar] >> >> >> >> We'd like to transform the hierarchy of Maven modules/submodules into >> >> the following structure >> >> >> >> + application-forum >> >> | + pom.xml -> [pom] >> >> | + application-forum-ui/ >> >> | | + pom.xml -> [xar] >> >> | + application-forum-test/ >> >> | | + pom.xml -> [pom] >> >> | | + application-forum-test-pageobjects/ >> >> | | | + pom.xml -> [jar] >> >> | | | + src/ >> >> | | + application-forum-test-tests/ >> >> | | | + pom.xml -> [jar] >> >> | | | + src/ >> >> >> >> But now, I'm looking at relocation guide on Maven >> >> >> >> https://maven.apache.org/guides/mini/guide-relocation.html#How_to_relocate_a_Maven_2_artifact_to_a_different_groupId >> >> >> >> and I'm not sure of what I need to do. From the link, I understand that >> >> I should do another pom.xml for each old release. Let say I will take >> >> care only of the last release at the moment (1.9.3 for Forum App). Then >> >> I should add a submodule to the root that looks like the following? >> >> >> >> + application-forum >> >> | + pom.xml -> [pom] >> >> | ... >> >> | + application-forum-1.9.3 >> >> | | + pom.xml -> [xar?] (see below for the content) >> >> >> >> pom.xml >> >> ----- >> >> >> >> 4.0.0 >> >> org.xwiki.contrib.forum >> >> application-forum >> >> 1.9.3 >> >> >> >> >> >> application-forum-ui >> >> >> >> >> >> >> >> ----- >> >> >> >> Thanks, >> >> >> >> On 19/03/2015 09:08, [email protected] wrote: >> >>> Hi Caty, >> >>> >> >>> See below. >> >>> >> >>> On 18 Mar 2015 at 19:29:17, Ecaterina Moraru (Valica) >> >>> ([email protected](mailto:[email protected])) wrote: >> >>> >> >>>> Hi, >> >>>> >> >>>> I want to write automated tests for some contrib applications, but I >> >>>> need >> >>>> you help on some questions. >> >>>> >> >>>> == Prb 1. Folder Structure + Changing IDs == >> >>>> >> >>>> Currently the majority of applications don't have modules. >> >>> >> >>> You mean submodules I guess since they’re a module (maven module) >> >>> themselves. >> >>> >> >>>> Also some applications have IDs that don't correspond with the contrib >> >>>> standard: sometimes wrong groupId like 'org.xwiki.contrib.forum', >> >>>> sometimes >> >>>> random artifactId. >> >>> >> >>> Why would ‘org.xwiki.contrib.forum’ be a wrong group id? >> >>> >> >>> The rule is defined here >> >>> http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome#HHostingtools and a >> >>> module can have org.xwiki.contrib or org.xwiki.contrib.. >> >>> >> >>>> When wanting to change the groupId for 'org.xwiki.contrib.forum' I was >> >>>> told >> >>>> that we should change it only if we have a very good reason, otherwise >> >>>> changing the ID will resolve in upgrading problems within the Extension >> >>>> Manager. Unfortunately I don't remember exactly the problem with the >> >>>> changing of the ID, I just know I don't need to do it :) (//sorry >> >>>> Thomas) >> >>> >> >>> We support relocation so the extension id (groupId+artifactId) can >> >>> change. The only negative effect is that XWiki will not propose an >> >>> upgrade automatically when the new version comes out with a new >> >>> extensionId. (I’d love to brainstorm about finding ways to handle this >> >>> with Thomas though). >> >>> >> >>>> Example: https://github.com/xwiki-contrib/application-forum >> >>>> Theoretically, wanting to add tests I would need to create two modules: >> >>>> - application-forum-test >> >>>> - application-forum-ui, and move the current sources here. >> >>>> Unfortunately this means a change in the ID. >> >>>> >> >>>> Are 'adding tests' a good reason to change the ID? >> >>>> Should I not change the ID, and just add a test module? >> >>>> - application-forum-test >> >>>> - src/main/resources >> >>> >> >>> I’m in favor of changing the extension id and add relocation (it was >> >>> done for this purpose). This is what we did in xwiki-platform for a lot >> >>> of modules. >> >>> >> >>>> == Prb 2. Naming standards == >> >>>> >> >>>> We have some conventions on contrib.xwiki.org about name of the project. >> >>>> We should add maybe some more examples on groupId and artifactId. >> >>>> >> >>>> Also when looking at the test modules names, some applications have: >> >>>> - {{full-repository-name}}-tests >> >>>> - {{full-repository-name}}-test >> >>>> - {{partial-repository-name}}-test >> >>>> - {{random-repository-name}}-test >> >>>> - test >> >>> >> >>> Where? AFAIK I’ve been the one doing most of the tests relocation in >> >>> xwiki-platform and our naming rule has always been the same. For example: >> >>> >> >>> xwiki-platform-faq-test/ >> >>> |_ xwiki-platform-faq-test-tests/ >> >>> |_ … >> >>> >> >>>> Maybe we should agree also on this and document it. >> >>>> I guess the correct name would be: >> >>>> - {{full-repository-name}}-test >> >>>> -- {{full-repository-name}}-test-pageobjects >> >>>> -- {{full-repository-name}}-test-tests >> >>>> - {{full-repository-name}}-ui >> >>> >> >>> Yes. Some conventions are already documented here: >> >>> http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HBuildBestPractices >> >>> >> >>>> Also if we are 'discovering' some applications that don't correspond to >> >>>> the >> >>>> standard, do we change them or do we let them be? Since changing means a >> >>>> change in the ID :P >> >>> >> >>> I’d say we change them. >> >>> >> >>>> Since in theory we should have automated tests for all our applications, >> >>>> should we add a convention to always create a >> >>>> - {{full-repository-name}}-ui ? >> >>> >> >>> Yes. This is what I do when I create a new "top level" module. >> >>> >> >>>> Additional question: Also when we will transfer from platform to >> >>>> contrib, >> >>>> are we going to rename the modules? >> >>> >> >>> I think we discussed this and we said we would change the id but not >> >>> change the package names for now to not break backward compat. Would >> >>> need to read again the mail thread. In any case we still have some >> >>> decisions to make on that. I’ve been wanting to do this move but first I >> >>> wanted to implement the cleanup/removal of xwiki-enterprise to make way >> >>> for flavors. >> >>> >> >>> Thanks >> >>> -Vincent >> >>> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
