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

[David M Williams <david_williams@xxxxxxxxxx>]

> I am not entirely sure what this means for a project
like ours (Eclipse
> Code Recommenders). 

Ideally, it would not effect other project's at all.
But, a) there easily might 
be something I don't understand; b) there might be
some assumptions you 
(and others?) have been making about "parent
pom re-use" that is not completely 
valid. 

If this new, specific pre-req target causes "problems
for other projects", 
then I suspect that is an indication that their use
is a good thing, as it 
allows "conflicts" to be found earlier (at
build time) rather than months 
later at runtime. 

> 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?
> 
> - Or is the intention rather that a project like Code Recommenders
> simply re-uses eclipse-sdk-prereqs.target? Because then we run into
issue 2.
> 
> 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)?

I'll start at the bottom: They should definitely not
be added to our .target file,
if we don't need them for our build. 
Each project should have a relatively "independent"
build, and in cases where 
there is opportunity for re-use (either literally,
or by copy/paste) then 
it'd be up to the projects to negotiate any points
of conflicts. You can open 
a bug in our "Platform --> Releng" component
if you think we, the platform, 
should "move up" some prerequisite and it'd
be discussed/decided by the team, 
and others it might effect. (See bug 423084 for a
timely example). 
But otherwise it is likely best, in most cases, 
to match what is in the platform. The reason is there
are a number of ways to 
"assemble" products (in addition to EPP's
way of doing it) so either it does 
no harm if you have different versions of pre-reqs
(business as usual for complex 
"products" assembled from Eclipse projects)
or if there is harm or reason to match 
exactly, then us having a specific .target file should
help find such issues earlier
in the process than in the past, when we just had
"loose" requirements.   

The main point of using such .target files is for
us, and others, to have reproducible, 
predictable builds. 

Hope this helps. I appreciate your comments and if
I am "missing something", please ask again. 

Thanks,