Marshall Schor wrote:
Marshall Schor wrote:
In this release, we're hoping to include some things from the
sandbox. Some of these are eclipse plugins (the uima-as Eclipse
plugins).
We have a choice: have another Eclipse update site for these, or have
just one update Eclipse update site, with multiple "features" the user
can pick/install.
The 2nd approach seems much better to me. This would make the update
site more like the distribution site for Apache, or the maven
repositories - just another "packaging" that's convenient for
downloading Eclipse plugins related to the Apache UIMA project.
If we were to go to this approach, we would need the process which
computes the update site to do it for all the "features". This
process creates artifacts - 1 for each feature, and one for the
overall update site (listing all the features, at all the versions).
The running of the update site build would then be something done when
either the main UIMA was release, or when a sandbox project that had
artifacts on thie update site, was released.
Does this seem like the right approach, or is there another approach
to take?
-Marshall
More thoughts about "versions". If we keep the versions of the sandbox
releases == main UIMA releases, no problem. If not, then the Eclipse
update site will have:
1) a version for the overall eclipse update site
2) versions for the features and plugins that go with those features
The versions for (2) would match the version of those releases. Number
(1) would be an independent version, I guess.
Not wanting to deal with these complications, I think, for now, we'll
presume (for this release, at least) that everything is at the same
version level.
Comments/other views?
-Marshall
Can we assume that for 2.2.2, we'll have a synchronized release for
the core and the sandbox? Do we want to hold up the core release if
there are problems with the sandbox one? Or just wait with the eclipse
update site update until we have both releases?
--Thilo
