[
https://issues.apache.org/jira/browse/UIMA-2970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor updated UIMA-2970:
---------------------------------
Description:
Take advantage of the existence of the Apache dist.apache.org SVN site used for
releases to reduce the release work for new versions of existing update
subsites.
A subsite is typically a collection of features and plugins, at various
"versions", plus metadata that catalogs these items in two files: contents.jar
and artifacts.jar. The subsite also has pack.gz versions of the plugin Jars,
and checksums and signatures for the Jars and pack.gz things.
With each new version, the old versions of the features and plugins do not
change; just new versions are added and the metadata files are updated; all new
and changed files get new checksums/signatures.
Change the build process to:
a) checkout the existing subsite
b) build just the new versions
c) compute the new metadata and use the "append" facility to add to the
existing metadata
d) allow "committing" just the new/changed files to the dist repo after the
vote passes.
Since the update site build process no longer has any need of information about
previous versions, change the update-site organization and POM to have less
special updates needed (previously, it needed lists of previous versions, etc),
and make it align with the conventional way other projects are built, where
possible.
Make the category.xml a filtered file - substituting the "version" from the POM
instead of hard-coding it.
was:
Take advantage of the existence of the Apache dist.apache.org SVN site used for
releases to reduce the release work for new versions of existing update
subsites.
A subsite is typically a collection of features and plugins, at various
"versions", plus metadata that catalogs these items in two files: contents.jar
and artifacts.jar. The subsite also has pack.gz versions of the plugin Jars,
and checksums and signatures for the Jars and pack.gz things.
With each new version, the old versions of the features and plugins do not
change; just new versions are added and the metadata files are updated; all new
and changed files get new checksums/signatures.
Change the build process to:
a) checkout the existing subsite
b) build just the new versions
c) compute the new metadata and use the "append" facility to add to the
existing metadata
d) allow "committing" just the new/changed files to the dist repo after the
vote passes.
Since the update site build process no longer has any need of information about
previous versions, change the update-site organization and POM to have less
special updates needed (previously, it needed lists of previous versions, etc),
and make it align with the conventional way other projects are built, where
possible.
> Improve release of Eclipse Update sub-sites
> -------------------------------------------
>
> Key: UIMA-2970
> URL: https://issues.apache.org/jira/browse/UIMA-2970
> Project: UIMA
> Issue Type: Improvement
> Reporter: Marshall Schor
> Assignee: Marshall Schor
> Priority: Minor
>
> Take advantage of the existence of the Apache dist.apache.org SVN site used
> for releases to reduce the release work for new versions of existing update
> subsites.
> A subsite is typically a collection of features and plugins, at various
> "versions", plus metadata that catalogs these items in two files:
> contents.jar and artifacts.jar. The subsite also has pack.gz versions of the
> plugin Jars, and checksums and signatures for the Jars and pack.gz things.
> With each new version, the old versions of the features and plugins do not
> change; just new versions are added and the metadata files are updated; all
> new and changed files get new checksums/signatures.
> Change the build process to:
> a) checkout the existing subsite
> b) build just the new versions
> c) compute the new metadata and use the "append" facility to add to the
> existing metadata
> d) allow "committing" just the new/changed files to the dist repo after the
> vote passes.
> Since the update site build process no longer has any need of information
> about previous versions, change the update-site organization and POM to have
> less special updates needed (previously, it needed lists of previous
> versions, etc), and make it align with the conventional way other projects
> are built, where possible.
> Make the category.xml a filtered file - substituting the "version" from the
> POM instead of hard-coding it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
