uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: [VOTE] Replace update site with composite repository
Date Mon, 07 Jan 2013 23:34:36 GMT
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 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.

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


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
>>>> uimaj, uima-as, etc., called eclipse-packagings.
>>>> I noticed this folder is missing the normal trunk/tags/branches subfolders.
>>>> 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
>>>> 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
>>>> 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
>>>>> The result of the discussion is right now a composite repository, which
>>>>> to two update sites. The first one is exactly the currently published
>>>>> 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

View raw message