uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Klügl <pklu...@uni-wuerzburg.de>
Subject Re: [VOTE] Replace update site with composite repository
Date Tue, 08 Jan 2013 13:29:34 GMT
Hi,

On 08.01.2013 00:34, Marshall Schor wrote:
> I have a basic question about the approach, which is using composite update
> sites, and whether or not we need composites.
>
> It looks like the current build in uimaj-eclipse-update-site builds the update
> site with p2 additional metadata (the files artifacts.xml and content.xml).  If
> these were added to the existing eclipse-update-site, would that be sufficient?
>
> And, is there a way to have the build process for the content / artifacts
> include the older versions of the plugins & features?

I don't know and I haven't tried it yet. However, Steven has indicated 
that this will probably won't work:
https://issues.apache.org/jira/browse/UIMA-2475?focusedCommentId=13484857&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13484857

> I think that ought to be possible, and if so, we could have a simpler process,
> with just one update site, instead of composites.  This would also avoid the
> version naming issue I raised earlier re: naming and versioning the (multiple)
> composite sites.

Do we have to increment the version at all? ... since nothing is 
replaced, but only extended.

I cannot provide a good/clean solution for the versioning problem, but I 
personally prefer a solution based on a composite repository. I have the 
feeling that adding new update site, for example for the TextMarker 
release, would be easier and cleaner because we do not have to touch the 
other update sites. We would just add another folder if a new release is 
done (which is also true if we create a separate update site for uima-as)

Without providing any arguments, I also think that switching the build 
process for the update sites to Tycho might be a good idea.

Anyways, that is just my opinion and I will not argue against a solution 
based on only one update site.


> Of course, it's quite possible that I'm missing something in my (limited)
> understanding of everything :-)
>

(same here)

Best,

Peter


> -Marshall
>
>
> On 1/7/2013 11:26 AM, Marshall Schor wrote:
>> ok - I'll take a run at doing the things I mentioned :-)
>>
>> -Marshall
>> On 1/7/2013 8:54 AM, Peter Klügl wrote:
>>> Hi,
>>>
>>> I want to push this issue a bit.
>>>
>>> What do we need to change for a new vote?
>>>
>>> Marshall, do you want to restructure the update sites in SVN?
>>>
>>> Best,
>>>
>>> Peter
>>>
>>>
>>> On 19.12.2012 14:17, Peter Klügl wrote:
>>>> Hi,
>>>>
>>>> On 19.12.2012 06:27, Marshall Schor wrote:
>>>>> hi,
>>>>>
>>>>> I'm just now having a chance to look at this (sorry for the delay).
>>>>>
>>>>> Some initial questions:
>>>>>
>>>>> As part of this update, the UIMA SVN has a new top-level folder, parallel
with
>>>>> uimaj, uima-as, etc., called eclipse-packagings.
>>>>>
>>>>> I noticed this folder is missing the normal trunk/tags/branches subfolders.
 It
>>>>> would seem to me that we should have those, and when a new packaging
is
>>>>> done, it
>>>>> would have a version, and be "tagged", like a release.
>>>>>
>>>>> I realize it may not be considered a release (because it's just a re-packaging
>>>>> of the already released Jars) but it still seems to me that we should
have a
>>>>> trunk and a tags for this, and tag what we promote out.
>>>>>
>>>>> Another question:  There's a pom at the top level of the folder
>>>>> eclipse-packagings.  It says its for artifact "eclipse-packagings", and
has a
>>>>> version number of "4".
>>>>>
>>>>> I would think it would have a version number of "1", since it's the first
>>>>> version being released.
>>>> I agree on all points. One thing I want to mention: We need some strategy
for
>>>> the version number as this packaging will probably contain releases with
>>>> different version numbers, e.g., uima-2.4.0 and hopefully uima-textmarker-2.0.0
>>>> Therefore the number will be increased with asynchronous releases.
>>>>
>>>>
>>>> Peter
>>>>
>>>>
>>>>
>>>>> More later...
>>>>>
>>>>> -Marshall
>>>>>
>>>>> On 11/29/2012 11:31 AM, Peter Klügl wrote:
>>>>>> Hi,
>>>>>>
>>>>>> this vote is about replacing the current update site with a composite
>>>>>> repository, which essentially contains the same artifacts as before.
>>>>>>
>>>>>> We discussed in UIMA-2475 (https://issues.apache.org/jira/browse/UIMA-2475)
>>>>>> that the update site of Apache UIMA is not compatible with p2 repositories.
>>>>>> This complicates, for example, the development of bundles built with
Tycho.
>>>>>> The result of the discussion is right now a composite repository,
which refers
>>>>>> to two update sites. The first one is exactly the currently published
update
>>>>>> site (legacy) and the second one is a p2 repository (uima-2.4.0)
containing
>>>>>> the eclipse bundles of the 2.4.0 release. Note that these artifacts
are
>>>>>> provided twice.
>>>>>>
>>>>>> The new update site (composite repository) is here:
>>>>>> https://svn.apache.org/repos/asf/uima/eclipse-packagings/eclipse-update-site
>>>>>>
>>>>>> Please vote to approve this release:
>>>>>>
>>>>>> [ ] +1 Approve the release
>>>>>> [ ] -1 Veto the release (please provide specific comments)
>>>>>> [ ] 0   Don't care
>>>>>>
>>>>>> PS: As this is essentially not a new release, I skipped most/all
parts
>>>>>> mentioned in http://uima.apache.org/release.html
>>>>>>
>>>>>>


Mime
View raw message