Hi
I seem to be able to sign while using a branch so the
qvto-photon-master job actually uses ewillink/525759 for now. The
build looks promising but parameterization, promotion and a final
alias remain to do.
The only real change that I'm aware of is wrt sources plugins. In
the past low level lightweight features were sources free and high
level features included sources. All a bit magic. Tycho has a much
simpler default. Every plugin and feature has an auto-generated
sources counterpart with corresponding include hierarchy. What
actually gets packaged is driven by category.xml. So we now have
twice as many category items, the original ones, no longer
including sources, and the new ones with sources. For users there
is a clearer choice. Only real problem is third party distros that
expect org.eclipse.qvt.oml.sdk to include sources. Tough. If they
want the sources they must also import
org.eclipse.qvt.oml.sdk.source. I suspect that a high proportion
didn't actually want the sources anyway.
The increased Tycho automation detected that a couple of features
were inconsistently named ".feature.feature". Easy fixed.
Unfortunately the doc.feature was in the doc folder giving two
same-named artefacts. A no-no for Maven. doc.feature therefore
moved to the features folder. No need to move the examples.feature
(its plugin is "samples").
Gratuiously increasing all versions to 3.8 falls foul of API
tooling so Photon WIP versions are 3.8.0/3.7.100/3.6.200/3.5.300,
2.8.0/2.7.100 (debug), 1.4.0/1.3.100/1.2.200 (tools). I've added
the API nature to tools, cleaned up UTF-8/Unix NL, deleted
.cvsignore's and moved dead plugins to archive.
These changes can all be reviewed now on ewillink/525759 where
each commit is a complete solution to a distinct problem/clean-up.
Beware; after GIT commit changes that 'create'/'delete' plugins
you may need to re-Import Projects... New plugins are
releng/org.eclipse.qvto.releng.tycho,
releng/org.eclipse.qvto.releng.targetdefinition,
releng/org.eclipse.qvto.releng.build-site. Interim results are in
the target folder of each plugin. Magic folder-level pom.xml files
are not visible in the Package Explorer. You need to open e.g.
plugins/pom.xml from the GIT repo Working Tree to see the
enumeration of plugins to build. (You could check out the GIT root
as a separate project, but then searches and launches see
everything twice!)
Install m2e from SimRel, update your workspace from QVTo GIT,
then launch m2e->Build QVTo Distribution to see it all happen
(in the Console View).
A signed installable build may be found at
https://hudson.eclipse.org/qvt-oml/job/qvto-photon-master/lastSuccessfulBuild/artifact/releng/org.eclipse.qvto.releng.build-site/target/org.eclipse.qvto.releng.build-site-3.8.0-SNAPSHOT.zip
Internally I think it is ok, just needs a proper name and promotion
to updates/downloads.
Please review in the next week. I'll sort out OCL, QVTd before
pushing QVTo to master.
Regards
Ed Willink
On 10/10/2017 16:45, Ed Willink wrote:
Hi
I've chosen to do QVTo first since it's probably easiest.
(Maybe but custom Ant tasks are always painful.)
For the most part Tycho is much nicer than Buckminster. It
actually succeeds in providing something that executes in your
normal workspace. (Just install m2e from SimRel, update your
workspace and run the m2e->Build QVTo launch.) I have
packaging and tests working but strangely the source plugins are
omitted. The tests use the packaged results rather than the
build workspace so they are a better test, but they are two JVM
invocations away from a debugger.
Now I have to sort out signing and promoting, which can only be
done on a master build. I'll therefore be making use of a new
qvto-photon-master job.
I'll bump all feature versions to 3.8.0. Only one cosmetic
plugin signature no-change was need to fix an error while I
accidentally used Java 1.8.
Do not trust any 3.8.0 promotions until I'm done.
Regards
Ed Willink
On 25/08/2017 10:18, Sergey Boyko
wrote:
Hi Ed,
Yes, you're right. Seems that moving to Tycho is the
only option for our build infrastructure. Hope this can
guarantee stable releases for next few years until next "new
technology" will appear :)
Certainly the main difficulties is to move OCL to Tycho.
Once it's done then duplicating it for QVT* projects won't
be so complicated.
Of course I'll be very grateful if you will try to move
QVTo to Tycho. Or once OCL will be bready I can try to
"copy-paste" the solution myself.
Best Regards,
Sergey.
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvto-dev