With m2e and Eclipse 4, it is possible to have a development / test cycle that uses incremental Eclipse builds for changes to plugin projects, and uses the class files (without building into Jars) for the plugins during debug/testing. (This, of course, relies on not hitting "bugs" in the current levels of Eclipse 4).
Given this, I'm wondering if it would be a good idea to move the generation of pack.gz forms of the jars up one level. Currently pack.gz forms are generated when building plugins for the update-site. The update site build for plugins involves copying the jars from Maven repositories, and then running the "pack" operation on each of them. There can be a lot of Jars - one for each plugin * the number of versions for each plugin. For instance, right now we have for the uimaj project, 2 versions of each plugin - 2.4 0 and 2.3.1. Moving forward, we'll likely keep the older versions for quite a while, and add newer versions. It is possible to add the pack.gz creation step to the step that produces the Jars. This has the drawback that running the build for that takes longer. I think with the 4.2 support incremental builds in Eclipse, this may not matter as much. We might also do a process where the pack.gz isn't done until the update site is built, but when it's done there, it's only done for the current version; older versions are obtained from Maven repositories. In both these cases, the release of the plugin artifacts would be part of the release process, and the plugins (and their pack.gz forms) would be uploaded to Maven central. This contrasts with today's process, where pack.gz files are regenerated whenever update sites are built, and never "saved" for reuse. ----------- A major alternative to uploading artifacts like the pack.gz to Maven central (where they exist only to allow the maven-dependency-plugin to copy them into new update sites using "Maven coordinates" of group-id, artifact-id, and version): would be to instead pull the older version artifacts from the release-spot SVN. This is possible because of the new release process, where the Eclipse update site is now in the "release" svn (https://dist.apache.org/repos/dist/release/uima/eclipse-update-site. The build of update sites could split the work around current and previous versions of features and plugins; for the previous ones, it could copy artifacts from the dist svn site, including the pack.gz files, and for the new versions, it could get them from the Maven coordiates (.m2 and/or Maven Central) and generate the pack.gz on every build, rather than saving it alongside the jar in Maven repos. Any opinions on what the best practice would be here? My own slight preference is to set things up so that the update site fetches previous versions from the distribution release SVN, and rebuilds pack.gz's every time. -Marshall
