Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [qvto-dev] Tycho build progress (was Buckminster RIP)

Hi Ed,

Really great progress!!   

I'll thoroughly verify commits in 'ewillink/525759' branch. Actually more for getting some information about new releng than to find any inaccuracies since I'm not familiar with Tycho.

Tnank You and Best Regards,
  Sergey.


On Thu, Oct 12, 2017 at 10:43 AM, Ed Willink <ed@xxxxxxxxxxxxx> wrote:

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.



On Tue, Aug 22, 2017 at 7:49 PM, Ed Willink <ed@xxxxxxxxxxxxx> wrote:
Hi Sergey

https://bugs.eclipse.org/bugs/show_bug.cgi?id=521263 announces the termination of the command line signer before Photon. It is therefore unlikely that OCL, QVTd or QVTo builds can survive unchanged until Photon.

Migrating OCL (and QVTd) to Tycho has been on my to-do list (https://bugs.eclipse.org/bugs/show_bug.cgi?id=499509) but so far I have managed to defer the pain.

Fudging a variant signer on the Buckminster build seems like a recipe for ongoing trouble. Might as well move. Once I've done OCL, doing QVTd and QVTo should be fairly easy.

Adolfo started on the migration attempting to clone perhaps EMF Compare, but somehow it didn't seem that easy, so there are problems still to solve.

Do you want me to try to do QVTo? I think that some of Adolfo's difficulties came from trying to replicate legacy build/test artefacts too precisely. If a little flexibility is acceptable it may be easier and more conventional.

    Regards

        Ed



Back to the top