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
>

Reply via email to