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 21:17:29 GMT
Hi,

Am 08.01.2013 21:39, schrieb Marshall Schor:
> On 1/8/2013 8:29 AM, Peter Klügl wrote:
>> 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
>>
> This post looks like he was on the right track, but didn't realize that the
> target/eclipse-update-site in the project uimaj-eclipse-update-site isn't the
> update site, but rather a partial update site which has to "merged" with the
> full update site.
>

Well, we can try to apply the FeaturesAndBundlesPublisher on the 
complete update site and verify if Tycho is able to resolve the 
dependencies. I will investigate this tomorrow.

>>> 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 was referring to the name in the composite site which was the folder name of
> the new p2 version - it is called uima-2.4.0
see below

>> 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)
> I guess this could be a bit "cleaner", although people may need to learn more
> about Eclipse packaging (that is, how composite update sites work).
>
> If we have composite update sites for some subprojects, it seems we ought to
> have better names for the sub-sites, than uima-2.4.0, though.  I expect that
> each subsite will be for a separately developed set of plugins (like textmarker)
> - so you would have a subsite folder "textmarker", perhaps (no version number),
> and then, within that update subsite, there would reside all the various
> versions of the text marker releases, does that sound right?

Nope, that would be the worst case I think. I was rather referring to a 
layout where each release gets its own folder like uima-2.4.0, 
uima-2.4.1, textmarker-2.0.0, textmarker-2.0.1, ... The advantage is 
that we build the update site for the release and just archive it in the 
composite repository.

Peter

>> 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