You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A Maven-based update site generator could produce db.xml.gz files for artifacts available from a remote Maven repository. So e.g. we can generate an update site for Fiji by running the generator against sc.fiji:fiji. It would scrape the maven-metadata.xml for all release and snapshot versions of Fiji, and declare them in the db.xml.gz. It would declare the dependencies to match the declared deps of that GAV (need to check whether the Updater is smart enough regarding transitive deps, though—I'm guessing it is).
For stable, use release versions only. For unstable, use the latest SNAPSHOT.
There might be a problem with old snapshots disappearing: rerunning the generator after a snapshot has disappeared would (naively) make that version no longer declared in the db.xml.gz. But we can get around this by supporting unioning of existing db.xml.gz metadata with newly generated content.
Because we have datestamps for all published Maven artifacts, we should be able to support downgrading in a future version of the Updater.
The text was updated successfully, but these errors were encountered:
A Maven-based update site generator could produce
db.xml.gz
files for artifacts available from a remote Maven repository. So e.g. we can generate an update site for Fiji by running the generator againstsc.fiji:fiji
. It would scrape themaven-metadata.xml
for all release and snapshot versions of Fiji, and declare them in thedb.xml.gz
. It would declare the dependencies to match the declared deps of that GAV (need to check whether the Updater is smart enough regarding transitive deps, though—I'm guessing it is).db.xml.gz
. But we can get around this by supporting unioning of existingdb.xml.gz
metadata with newly generated content.The text was updated successfully, but these errors were encountered: