I agree this is an issue.
I can see 2 paths forward. One makes multiple eclipse-update-sites.
The other moves the generation of the update site to a "deploy" step
taken after the release is approved.
I would like to consider this latter way. It seems to me that the
update site is very similar to maven artifact deployment. In both
cases, the artifacts being deployed are being packaged with additional
meta-information about their versions, etc.. And, in both cases, there
is a kind of "merging" that is done. In the Maven case, there is a file
which is updated which contains all the versions of the artifact - this
is similar to the manual update of the site.xml, for the Eclipse update
site.
In the Maven case, the deployment takes place after the release is voted
on. If we could do something similar, then we could remove the "build"
of the Eclipse update site and do it after the release had been voted on.
Unless there are objections, I'll update the xxx-distr POMs to remove
the building of the Eclipse update site - that should fix our build for
the moment, I think.
-Marshall
Michael Baessler 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
How will this work with the distribution build? Currently it seems that
we can only build a UIMA core distribution if the plugins for UIMA AS
are also in place. I don't think this is what we want. I think we have
the same issue when doing a build from the source distribution since we
don't ship UIMA AS sources with UIMA core.
I opened an issue for that. UIMA-865
-- Michael
