Re: [tycho-user] Building an RCP product against different Eclipse versi

["arcanefoam@xxxxxxxxx" <arcanefoam@xxxxxxxxx>]

I would keep using maven profiles but use different target platform definitions for changing the Eclipse VERSIONS. The maven profile would enable the corresponding target platform module (--projects). 

I have also found thst wrapping my maven builds on bash/powershell scripts avoids the "forgot to run x or y", issues. I add to my project a BuildLocal script that runs all the maven with the different profiles. This also allows me to skip integration tests for local builds if need be. My build script usually accepts flags that let me fine tune what I want to do, with the no parameter version running all I need. I also find that the build script is usually a good guide for then writing my CI configurations.

Cheers, 

On Tue, 8 Sep 2020, 13:58 Andreas Pakulat, <andreas@xxxxxxxxxxxxx> wrote:

On 2020-09-08 13:46, Christian Pontesegger wrote:
>> My current solution is manual, one has to specify a profile name on
>> the
>> commandline for the macOS build. That profile sets up a different
>> path for
>> the 'eclipse-mirror' repository and then building our product happens
>> with
>> Eclipse 4.12 instead of 4.7. I'm then doing two builds of the
>> product, once
>> without profile specified and once with the macOS profile.
>
> I am not aware of a method that can do this via one build step. It
> would mean that each component (plugin, feature, p2 site) would have to
> be built twice as its dependencies change. Also tests would have to be
> executed against multiple targets.

For us it's more a bundling-thing, than really compiling against both
versions. Our dependencies are met by even older versions of Eclipse than
4.7, the API's we use have not changed in a while - in particular not the
runtime-API's.

> The approach with different profiles seems to be quite fine. Why not
> use a batch/shell script to run both builds?

We use a script to do this for our normal package builds and it works there
quite well.

We also sometimes build packages locally (in particular with changes that
someone else is then supposed to try out) though and that's what I had in
mind here. Doing this only occassionally means easily forgetting to pick the
mac-profile for building when necessary. So I hoped for a way to avoid that
pitfall as it can result in back/forth between the receiver of the package
and the one building it. However if that is not available or ends up being
too cumbersome to maintain a separate profile will be sufficient for the time
being - eventually we'll update on all platforms anyway.

Andreas

--
Andreas Pakulat squish@xxxxxxxxxxxxx
froglogic GmbH - Automated UI and Web Testing
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/tycho-user