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
