Re: [recommenders-dev] Mangement of third party dependencies

[Andreas Sewe <andreas.sewe@xxxxxxxxxxxxxx>]

Hi Marcel,

great to see such a lengthy proposal but I fear I need to toy around
with this some more before I can you give a really solid answer. Sorry.

That being said, there us one thing I am really curious about (and where
I am surprised that it didn't bite us yet): Why do we build to
o.e.r.feature.3rd.orbit features (one 1.0.4 from the Eclipse build and
one 0.1.0 from build.codetrails.com)? This name clash seems dangerous to
me and I'd like to understand the existence of *two* Orbit 3rd party
dependency features a bit better.

> Andreas was asking whether we should use fixed version in our features.
> In general, I'd say yes but this will cause a lot of extra trouble. I
> don't know out of my head whether we have to specify the qualifier in
> the feature.xml too to make the build work. But when we we have to
> specify the qualifier, every change in a qualifier will break our build.
> This will get annoying pretty soon. I think we should test (or someone
> can already tell me?) whether the qualifier is required.

Fixing the version in the feature.xml was the solution (workaround,
really, as yesterday's fixing of the build was quite stressful) I came
up with yesterday.

In the longer run, however, I think that fixing the versions in the
target definitions makes more sense. Here's why:

- Fixing the version in the feature.xml while leaving the version
unconstrained in the *.target means that any update sites therein
(currently we have 3(!) target definitions) need to supply the exact
same version. This restricts us to the versions that where available for
the Juno release even when targeting Luna.

- Fixing the version in the *.target would allow us to selected
different versions of the same library in different build profiles. The
feature would, with a 0.0.0 "constraint" simply pick up the version from
the current target definition. This would make it possible to bundle
SLF4J 1.6.4 with our Juno-compatible builds and 1.7.2 with our
Kepler-compatible builds. Of course this requires that the libraries are
sufficiently compatible. If not, a *declared* version constraint in our
plugins' MANIFEST.MFs should fail the build.

Either way, fixing versions in *.target or feature.xml ensures that we
honor our IP log obligations, namely to only use approved versions of
our dependencies. Leaving them unconstrained everywhere just asks for
trouble.

> To summarize,
> the core changes over the current approach I propose ATM are  (i) the
> as-is p2 repository (marked orange in the illustration) and (ii) the
> publishing to particular download folders.
> 
> Andreas, what do you think?

I'll give the different *.target files approach a spin over the weekend,
building with all three profiles, and see how that goes and whether I
get get away without having to specify qualifiers (which is annoying, I
agree).

I'll report back on the list.

Andreas
-- 
Codetrails.com – The knowledge transfer company