Cool. Thanks.
To add more thoughts, the general thinking is that we need to support all the great effort going into the Eclipse platform. By building on the new features they add, we are bringing those great things to our downstream consumers. By not doing that, it’s
really an disservice to that great work they’re doing and to the downstream consumers who need those features.
Supporting old releases based on constraints in the ecosystem means we all pay based for the choices of the few. If you have problems with an old plug-in that won’t run, that really should be the problem for the producer of that plug-in, not the rest of
the community.
But in the end, with everything in git and using maven to build, it’s so easy to fork if you have special requirements so you do have that path to get your consumers what they need.
Doug.
Hello
These kind of changes are often tricky and sometimes cause disagreements. I understand points on both sides. With this email I'd like to express my take on it and how we try to handle it.
In the source code of Trace Compass we have been holding back to not use any 4.5 APIs of Eclipse (e.g. Update usage of IAdaptable#getAdapter). However, we were aware of the upcoming changes in o.e.remote because one bug fix was initiated by our group (Bug 454063)
and the fix actually boiled down to an API addition in o.e.core.runtime (e.g. Path.forPosix()). We decided, that if we were to support older Eclipse versions for Trace Compass internally at my company we would create special builds to by-pass the dependencies.
Even if this means additional overhead. I think it's quite common to have such workarounds temporarily to be able to use latest and greatest features, bugfixes and advance with the project faster.
Right now we don't have this requirement of supporting older Eclipse versions at my company. In most cases users use the Trace Compass standalone application (RCP) or are ok with upgrading to Mars.
Best Regards
Bernd
On 05/06/2015 09:45 PM, Doug Schaefer wrote:
Now that I'm on the list...
If you have a product that needs to run on 4.4, then you are free to fork o.e.remote and make it work for you.
For the rest of us, we'll get the benefit of the new feature that uses it.
Nope. o.e.remote 2.0 uses new APIs in Eclipse 4.5.
Doug.
___________________________________________________________ _____________
Adding Greg and Doug as the org.eclipse.remote 2.0 representatives:
I haven't checked the exact details, but I do think that org.eclipse.remote 2.0 should be able to run on Eclipse 4.4 or even older because it has minimal dependencies. And if it can't today, I think that would be desirable -- I like Eclipse 4.5 and I'm
convinced it's the best Eclipse ever, but we shouldn't break people unnecessarily if they feel like they have to stick to Luna SR2 (or older) for some reason.
For example, I've heard of some commercial products which won't update to Mars in quite some time (a ClearCase adapter was cited as one such example by our customers). It would be desirable to be able and install Trace Compass + org.eclipse.remote 2.0
into those products which have to stick to Luna or even Kepler as the base Platform.
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner - Development Tools, Wind River direct +43.662.457915.85 fax +43.662.457915.6
-----Original Message-----
Subject: [tracecompass-dev] Trace Compass now requires Eclipse 4.5
Hi all,
Just to let you know, due to a non-backwards compatible change in org.eclipse.remote.core, which we depend on, Trace Compass now depends on Eclipse 4.5. This applies to master, and will apply to the 1.0 release in June.
Cheers,
Alexandre
_______________________________________________
tracecompass-dev mailing list
_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tracecompass-dev
|