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