Migrating a legacy P2 Update Suite

[ewillink]

I'm trying to migrate a tree of traditional manual/ant/php maintained P2/ZIP sites to use JustJ rather than PHP.

I have successfuly tweaked releng/org.eclipse.nebula.site/promotion/pom.xml so that it appears that the regular nightly/milestone/release lifecycle could work.

However when I try to sequence the conversions to migrate many years of releases, I seem to have to fight the lifecycle. Even converting each release as nightly then milestone doesn't seem to work because the nightly wants to rewrite build dates, so I lose the version number for the release.

It seems I need a version number override command line argument.

Better still a migrate command line argument would take the root of the legacy suite and convert it all.

However surely migration was solved for the EMF Update Site so I don't want to re-invent the wheel?

Is there an easy solution?

[merks]

For other projects I literally just copied the/each old release site folder to a child folder of the new release folder. The next promoted nightly build finds that and incorporates it into the structure. Of course use a sensible version number for the release folder name.

Where can I look to see where you are doing this to give advice?

[ewillink]

I'm currently practising on QVTo, but nothing is committed to GIT yet.

I don't follow your comment. Take https://download.eclipse.org/modeling/emf/emf/builds/release/2.6/index.html as an example. This was clearly generated by something resembling JustJ; just copying a legacy would not do. So my question is perhaps just how to generate the 2.6 JustJ files from a pre-JustJ 2.6 P2 site.

(Trivial observation: https://eclipse.dev/justj/?page=tools comments

-remote - A remote source/destination specifification as used by rsync.🔗

<rsync-path> - A specication of the host and the path on that host. E.g.,
[email protected]:/home/data/httpd/download.eclipse.org/justj
localhost:C:/Users/Account/justj
If a compatible/standard rsync is available on the system PATH, one can test using localhost. Optional, i.e, when not specified, only the -root will be populated locally which is useful for testing.

On Windows at least -remote C:/Temp/qvto-sync works nicely for testing. )

[merks]

Note that the entire set of html index files for all update sites in the tree are completely regenerated for every build. So if you copy an update site into the release folder, an index will be generated for that and the composites will compose it. You could delete all *.html files and they will all be regenerated. This allows the potential to improve all pages in the future. Just try it.

[ewillink]

Thanks. Seems like a single careful copy command and I'm done.

[merks]

Yes that worked for GEF, Graphiti, and Nebula recently.