Re: [eclipse-dev] Eclipse Committers: we now have a specific "target fil

[Andreas Sewe <andreas.sewe@xxxxxxxxxxxxxx>]

Hi Krzysztof,

>> I am not entirely sure what this means for a project like ours (Eclipse
>> Code Recommenders). In particular, I am unsure how to handle the
>> following two issues:
>>
>> 1.) We have a fair number of dependencies from Orbit (e.g.,
>> javax.inject, org.apache.lucene.core) which are part of both our target
>> file [1] and of eclipse-sdk-prereqs.target.
>>
>> - Do I need to manually ensure that the versions of these dependencies
>> match?
> 
> Yes, but that was always the case. The point is that Eclipse platform
> will now include a specified version of a dependency, and adding a new
> version of a lib to orbit will not cause platform to use it. For a
> platform to pick up latest version of any library, a commiter action
> will be required. So the change removes unwanted platform modifications.
> 
> If you don't follow what is happening in the platform, you will get:
> a. duplicated instances for non-singleton
> b. installation conflicts for singletons.

OK, we'll keep an eye on eclipse-sdk-prereqs.target then.

>> 2.) We have a couple of dependencies from Orbit (e.g.,
>> com.google.inject, org.apache.commons.io, etc.) in our target file which
>> are *not* part of eclipse-sdk-prereqs.target. Our target file has the
>> versions of the respective Orbit bundles tied down and they are then
>> published to our update site [2] from which they are then picked when
>> the EPP packages we participate in are build (Java/RCP/DSL developers).
>>
>> - Do they need to be added to the eclipse-sdk-prereqs.target (or a
>> similar file used by the EPP packages in question)?
> 
> It would be awesome to have centrally managed dependency set - all
> projects in a train to use a common target. But I'm afraid that was not
> the intention.
> 
>> I am sorry if these questions were answered before, but I couldn't find
>> these questions answered in the wiki.
> 
> The only effect for other projects is that they should be aware that
> platform may not always provide latest version of dependencies. As a
> releng recommendation I'd use multiple target files
> (eclipse-sdk-prereqs.target and project specific one), and ensured they
> have no common bundles (I think this is how multiple target files work -
> they are merged at build time, but Jan or Tobias will know better).

Your releng recommendation seems perfectly sensible to me (and, AFAIK,
perfectly doable with Tycho). Unfortunately, you can only set a single
target platform in the IDE, which either means you have to work against
an incompletion target definition in the IDE ore to manually maintain a
merged target file for IDE purposes. :-(

Anyways, the current situation is not so bad: Once in a while checking
whether we are still in-sync with eclipse-sdk-prereqs.target.

Thanks for the advice.

Andreas

-- 
Codetrails UG (haftungsbeschränkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940