Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [gef-dev] Possible upcoming change on JavaFX-Equinox-Integration

Hi,

No hurry. We are contributing the 1.2.0 to M6 and 2.0.0 (with the
changes) to M7! I'll give you a heads up once I'm done and our nightly
builds holds the necessary bits!

Tom

On 20.03.15 11:31, Alexander Nyßen wrote:
> Hi Tom,
> 
> thanks for pointing this out. As we will have to release M6+1 on Monday,
> and a respective e(fx)clipse update would break us if we do not adjust
> our code base, the only chance of not breaking GEF4 would be:
> 
> a) not releasing the e(fx)clipse update with M6, or
> b) releasing the e(fx)clipse update with M6, with the following constraints:
> 1) adjusting and testing GEF4 code base today (we would need to consume
> the change in order to run tests against it)
> 2) releasing the e(fx)clipse update already on Monday before the GEF4
> release, so the updated GEF4 version will behave properly
> 
> As you probably target at b), I would offer that we will run respective
> tests today (and adjust our code base accordingly), if you can point us
> to an e(fx)clipse build that provides the described update, which could
> be used for testing. If we identify blockers (and cannot react to them
> today), I would propose to postpone the e(fx)clipse update, at least up
> to M7 (so that would give us enough time to adapt GEF4. If not, we could
> proceed as outlined in 2).
> 
> Cheers
> Alexander 
> 
>> Am 20.03.2015 um 09:37 schrieb Tom Schindl
>> <tom.schindl@xxxxxxxxxxxxxxx <mailto:tom.schindl@xxxxxxxxxxxxxxx>>:
>>
>> Hi,
>>
>> I know you guys are using our Equinox integration so I'd like to draw
>> your attention to a possible upcoming change you'd be affected if
>> implemented.
>>
>> The nice thing is that you could remove all the javafx* imports in your
>> MANIFEST.MF because those will be found by default. The Adaptor-Hook
>> will stay as is but instead of createing a classloader for a specific
>> module it will act as a last resort loader e.g. to find the
>> SWT-JavaFX-Bridge.
>>
>> I case you think this change is too distruptive and too late in the dev
>> cycle I could push that back to the next release but because we are
>> doing a 2.0.0 release in Mars this would be the perfect timeing and I
>> think the same is true for GEF4.
>>
>> The bug to track is https://bugs.eclipse.org/bugs/show_bug.cgi?id=462634
>>
>> Thanks for your attention
>>
>> Tom
>>
>> -- 
>> Thomas Schindl, CTO
>> BestSolution.at <http://BestSolution.at> EDV Systemhaus GmbH
>> Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
>> http://www.bestsolution.at/
>> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>> _______________________________________________
>> gef-dev mailing list
>> gef-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or
>> unsubscribe from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/gef-dev
> 
> --
> Dr. Alexander Nyßen
> Dipl.-Inform.
> Principal Engineer
> 
> Telefon: +49 (0) 231 / 98 60-202
> Telefax: +49 (0) 231 / 98 60-211
> Mobil: +49 (0) 151 /  17396743
> 
> http://www.itemis.de 
> alexander.nyssen@xxxxxxxxx <mailto:alexander.nyssen@xxxxxxxxx> 
> 
> itemis AG
> Am Brambusch 15-24
> 44536 Lünen
> 
> Rechtlicher Hinweis:
> 
> Amtsgericht Dortmund, HRB 20621
> 
> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg
> Pietrek, Jens Trompeter, Sebastian Neus
> 
> Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus,
> Jennifer Fiorentino
> 
> 
> 
> 
> 
> _______________________________________________
> gef-dev mailing list
> gef-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/gef-dev
> 


-- 
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck


Back to the top