You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2018/01/12 16:50:02 UTC
managing multiple version streams
Thoughts, discussion needed:
When we started this project, we imagined we were creating some artifacts, each
of which would have multiple versions marching forward in time, but each version
superseding the previous.
We set up svn to have a top level name for each sub-big-project (e.g. uimaj,
uima-cpp, ducc, uimaFIT, Ruta, etc.), and under that
-trunk
-tags
-branches
following normal conventions. Our build tools are based around this convention.
--------------------------
Now, we are beginning to see the need for multiple versions where some of these
will continue to be maintained.
- For example, uimaj now has version 2.10.2 and (soon) version 3.0.0.
- And uima-as may soon have also a version 2.x and (soon) a restructured
(maybe slightly incompatible) version 3.x (not related to uimaj 3.x).
- other projects may also have multiple maintained versions that work with
uimaj-v3 and uima-v2
--------------------------
One choice might be to have new names for maintained versions, that reflect
something identifyable about them. For instance, we might have:
- uimaj-v3 (old name, version starts at 3.0.0 ) -> uimaj-j (version starts at
1.0.0, or 3.0.0)
- <the new as yet unnamed refactored version of uima-as> -> uima-as-r (version
starts at 1.0.0 or ??)
(Please excuse the poor names, they're just for an example)
--------------------------
If we went this route, these new big-projects would live in the svn hierarchy
along side the other projects. So for example we might have
uima (top level svn)
uimaj
uimaFIT
ducc
ruta
uima-as
uimaj-j
uima-as-r
and under each of these, there would be a "release" process, making shared use
of our uima-wide superpom which in turn makes use of conventions of having under
these directories a "trunk" and a "tag", etc.
---------------------------
If uimaFIT wanted two versions maintained, one being one that worked with uimaj
and the other that worked with uimaj-j, it would perhaps have two top level
projects:
uimaFIT
uimaFIT-j (sorry for the name... just adopting the single letter suffix from
uimaj -> uimaj-j)
and, the same would apply to uima-as and uima-as-r:
uima-as-j
uima-as-j-r
Some of these projects could be tiny. For example the version of uima-as that
works with uimaj-j has only POM changes versus the uima-as project (plus some
small code change I think that could probably be parameterized somehow).
It might be possible to have just one project for uima-as for the uimaj/uima-j
combo, if we could figure out how to build two different (named) artifacts when
doing builds for releasing the binary form.
-------------------------
The current svn organization collects the xxx-j style projects (those that
depend on uimaj-v3) underneath an "extra" top level node in the svn directory:
uv3/. And it names those projects with the suffix -v3.
-------------------------
I think the suffix "-v3" is potentially confusing (going forward) because of the
need for other projects to claim a v3 for a completely unrelated purpose.
Example, the reworking of uima-as, changing things so that semantic versioning
says it needs to increment the 1st digit - will have a version 3.0.0 (completely
unrelated to uimaj-v3).
So, I think (as a minimum) we should rename the uv3 moniker to something not
version specific, like uimaj-j.
-------------------------
Please consider these issues, and make improvements / suggestions :-)
-Marshall
Re: managing multiple version streams
Posted by Marshall Schor <ms...@schor.com>.
sounds good to me :-)
-Marshall
On 1/17/2018 7:30 AM, Richard Eckart de Castilho wrote:
> My understanding is that you suggested to change the artifact names from e.g. "uimaj-core" to "uimaj-core-j".
>
> If that is done, then Maven can no longer figure out that uimaj-core:2.10.2 and uimaj-core-j:1.0.0 are mutually exclusive because - because the contain the same Java packages.
>
> So if the artifact ID is changed, then the package names should be changed. Apache Commons projects do this from time to time.
> E.g.
>
> - commons-lang:2.x has the package name "org.apache.commons.lang"
> - commons-lang3:3.x has the package name "org.apache.commons.lang3"
>
> Having the same package in different artifacts defies Mavens dependency resolution process. It may be necessary to add explicit "excludes" to POMs to avoid dragging in incompatible UIMAv2 dependencies just because they have a different artifact ID.
>
> I believe we already had the discussion of v2 and v3 co-existing at runtime (as e.g. commons-lang and commons-lang3 do) and it was decided that it would be too much effort. So the logical path to follow seems to me to continue with the existing group/artifactIds at version 3.
>
> We can continue doing releases of version 2.x and version 3.x artifacts from different branches in the repo.
>
> The only thing you need to observe is that if you want to import the v2 and the v3 branch simultaneously into the same Eclipse workspace, you need to change the project naming pattern in the "Import existing Maven projects" dialog, so that e.g. v2 modules are imported as "{artifactId}-v2" and v3 modules as "{artifactId}-v3".
>
> -- Richard
>
>> On 16.01.2018, at 19:34, Marshall Schor <ms...@schor.com> wrote:
>>
>> or perhaps you might mean changing the artifact name
>>
>> org.apache.uima : uimaj-core : 3.0.0
>> org.apache.uima : uimaj-core-j : 1.0.0
>>
>> In this example, following a (weak) convention of suffixing "-j" to indicate the uima-v3 redesign version, and noting it could start with version 1.0.0...
>>
>> -Marshall
>>
>>
>> On 1/16/2018 1:26 PM, Marshall Schor wrote:
>>> By changing the "package names" - do you mean Java package names?
>>> e.g., we have org.apache.uima.UIMAFramework (class);
>>> what might be an alternative package name?
>>>
>>> Or do you mean a different maven coordinate "group" name?
>>>
>>> org.apache.uima : uimaj-core : 3.0.0
>>> (group) : (artifact-id) : version
>>>
>>> -Marshall
>
Re: managing multiple version streams
Posted by Richard Eckart de Castilho <re...@apache.org>.
My understanding is that you suggested to change the artifact names from e.g. "uimaj-core" to "uimaj-core-j".
If that is done, then Maven can no longer figure out that uimaj-core:2.10.2 and uimaj-core-j:1.0.0 are mutually exclusive because - because the contain the same Java packages.
So if the artifact ID is changed, then the package names should be changed. Apache Commons projects do this from time to time.
E.g.
- commons-lang:2.x has the package name "org.apache.commons.lang"
- commons-lang3:3.x has the package name "org.apache.commons.lang3"
Having the same package in different artifacts defies Mavens dependency resolution process. It may be necessary to add explicit "excludes" to POMs to avoid dragging in incompatible UIMAv2 dependencies just because they have a different artifact ID.
I believe we already had the discussion of v2 and v3 co-existing at runtime (as e.g. commons-lang and commons-lang3 do) and it was decided that it would be too much effort. So the logical path to follow seems to me to continue with the existing group/artifactIds at version 3.
We can continue doing releases of version 2.x and version 3.x artifacts from different branches in the repo.
The only thing you need to observe is that if you want to import the v2 and the v3 branch simultaneously into the same Eclipse workspace, you need to change the project naming pattern in the "Import existing Maven projects" dialog, so that e.g. v2 modules are imported as "{artifactId}-v2" and v3 modules as "{artifactId}-v3".
-- Richard
> On 16.01.2018, at 19:34, Marshall Schor <ms...@schor.com> wrote:
>
> or perhaps you might mean changing the artifact name
>
> org.apache.uima : uimaj-core : 3.0.0
> org.apache.uima : uimaj-core-j : 1.0.0
>
> In this example, following a (weak) convention of suffixing "-j" to indicate the uima-v3 redesign version, and noting it could start with version 1.0.0...
>
> -Marshall
>
>
> On 1/16/2018 1:26 PM, Marshall Schor wrote:
>> By changing the "package names" - do you mean Java package names?
>> e.g., we have org.apache.uima.UIMAFramework (class);
>> what might be an alternative package name?
>>
>> Or do you mean a different maven coordinate "group" name?
>>
>> org.apache.uima : uimaj-core : 3.0.0
>> (group) : (artifact-id) : version
>>
>> -Marshall
Re: managing multiple version streams
Posted by Marshall Schor <ms...@schor.com>.
or perhaps you might mean changing the artifact name
org.apache.uima : uimaj-core : 3.0.0
org.apache.uima : uimaj-core-j : 1.0.0
In this example, following a (weak) convention of suffixing "-j" to indicate the uima-v3 redesign version, and noting it could start with version 1.0.0...
-Marshall
On 1/16/2018 1:26 PM, Marshall Schor wrote:
> By changing the "package names" - do you mean Java package names?
> e.g., we have org.apache.uima.UIMAFramework (class);
> what might be an alternative package name?
>
> Or do you mean a different maven coordinate "group" name?
>
> org.apache.uima : uimaj-core : 3.0.0
> (group) : (artifact-id) : version
>
> -Marshall
>
>
> On 1/12/2018 5:06 PM, Richard Eckart de Castilho wrote:
>> If we change the artifact IDs, then IMHO we should also change the package names. That would allow multiple versions to co-exist. If we just change the artifactIds and not the packages, then Maven could end up adding multiple artifacts with overlapping and incompatible packages to the classpath.
>>
>> DKPro Core and WebAnno are both maintaining multiple versions in parallel. We're using GIT here, but I assume the general strategy we use could also be applied to SVN:
>>
>> - there is a "master" branch (i.e. svn trunk) which contains the very latest version. In terms of
>> UIMA that would be v3.
>> - there is one or more "maintenance" branches (e.g. 1.8.x, 1.9.x, etc. i.e. in svn branches/1.8.x,
>> branches/1.9.x) where older versions are maintained
>> - when there are bug-fixes to older versions, these branches are usually merged into the master
>> branch as well
>> - new features are usually added to the master branch, but minor features may also be added into
>> the maintenance branches and be merge from there into the master branch
>> - changes to the master branch do usually not get merged back into the maintenance versions
>>
>> We have then multiple Jenkins builds set up that monitor the different branches and build them.
>>
>> Release are done from the respective branches when convenient.
>>
>> Personally, I'd tend go down that road for uimaFIT since it worked out well for me on other projects.
>>
>> I haven't done a lot of merging with SVN for a while - with git it works great.
>>
>> Cheers,
>>
>> -- Richard
>
Re: managing multiple version streams
Posted by Marshall Schor <ms...@schor.com>.
By changing the "package names" - do you mean Java package names?
e.g., we have org.apache.uima.UIMAFramework (class);
what might be an alternative package name?
Or do you mean a different maven coordinate "group" name?
org.apache.uima : uimaj-core : 3.0.0
(group) : (artifact-id) : version
-Marshall
On 1/12/2018 5:06 PM, Richard Eckart de Castilho wrote:
> If we change the artifact IDs, then IMHO we should also change the package names. That would allow multiple versions to co-exist. If we just change the artifactIds and not the packages, then Maven could end up adding multiple artifacts with overlapping and incompatible packages to the classpath.
>
> DKPro Core and WebAnno are both maintaining multiple versions in parallel. We're using GIT here, but I assume the general strategy we use could also be applied to SVN:
>
> - there is a "master" branch (i.e. svn trunk) which contains the very latest version. In terms of
> UIMA that would be v3.
> - there is one or more "maintenance" branches (e.g. 1.8.x, 1.9.x, etc. i.e. in svn branches/1.8.x,
> branches/1.9.x) where older versions are maintained
> - when there are bug-fixes to older versions, these branches are usually merged into the master
> branch as well
> - new features are usually added to the master branch, but minor features may also be added into
> the maintenance branches and be merge from there into the master branch
> - changes to the master branch do usually not get merged back into the maintenance versions
>
> We have then multiple Jenkins builds set up that monitor the different branches and build them.
>
> Release are done from the respective branches when convenient.
>
> Personally, I'd tend go down that road for uimaFIT since it worked out well for me on other projects.
>
> I haven't done a lot of merging with SVN for a while - with git it works great.
>
> Cheers,
>
> -- Richard
Re: managing multiple version streams
Posted by Richard Eckart de Castilho <re...@apache.org>.
If we change the artifact IDs, then IMHO we should also change the package names. That would allow multiple versions to co-exist. If we just change the artifactIds and not the packages, then Maven could end up adding multiple artifacts with overlapping and incompatible packages to the classpath.
DKPro Core and WebAnno are both maintaining multiple versions in parallel. We're using GIT here, but I assume the general strategy we use could also be applied to SVN:
- there is a "master" branch (i.e. svn trunk) which contains the very latest version. In terms of
UIMA that would be v3.
- there is one or more "maintenance" branches (e.g. 1.8.x, 1.9.x, etc. i.e. in svn branches/1.8.x,
branches/1.9.x) where older versions are maintained
- when there are bug-fixes to older versions, these branches are usually merged into the master
branch as well
- new features are usually added to the master branch, but minor features may also be added into
the maintenance branches and be merge from there into the master branch
- changes to the master branch do usually not get merged back into the maintenance versions
We have then multiple Jenkins builds set up that monitor the different branches and build them.
Release are done from the respective branches when convenient.
Personally, I'd tend go down that road for uimaFIT since it worked out well for me on other projects.
I haven't done a lot of merging with SVN for a while - with git it works great.
Cheers,
-- Richard