uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marshall Schor (JIRA)" <...@uima.apache.org>
Subject [jira] [Updated] (UIMA-2970) Improve release of Eclipse Update sub-sites
Date Thu, 06 Jun 2013 19:56:22 GMT

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

Incorporate checksums and signings into the normal mvn build process, under the apache-release
profile (so other builders don't need to do this part).



  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.

Make the category.xml a filtered file - substituting the "version" from the POM instead of
hard-coding it.



    
> 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.
> Incorporate checksums and signings into the normal mvn build process, under the apache-release
profile (so other builders don't need to do this part).

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

Mime
View raw message