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