Yes, I started to look into that, but the versions of the plugins in
eclipse don't follow maven convention, so for some of them I could
tweak the versions during artifact install, but for others I'm not
100% sure yet if the maven could handle the version comparisons. I'd
have to play around with it. But using version ranges I still have
to manually open up and look at what the versions of a distribution
are. Plugins jars only change versions if the content in them
changes. So an eclipse feature X version 3.0.0 could have X number
of plugins with versions 3.0.0 but one plugin could still be at
1.0.0. It stills introducing a maintainability issue when I move up
builds frequently. I like having the idea of restriction be defined
in the distribution URLs and not the content of the distribution.
But then again, I'm always changing my mind :) so let me start with
below just to get things building then we can see if it makes better
sense to use version ranges.
Sound good?
- sachin
On Mar 6, 2006, at 7:33 PM, Dain Sundstrom wrote:
Why not just use maven 2 version ranges?
-dain
On Mar 6, 2006, at 4:18 PM, Sachin Patel wrote:
So I've been banging my head over the weekend on how best to
handle eclipse plugin dependencies in M2. And I think I just
realized my answer on my way home. Whenever you're building a
eclipse plugin using PDE you're always building against a target
distribution and the plugin jars that are in that distribution. A
plugin developer wouldn't pick to build against version A of this
plugin, version B of another plugin, basically they wouldn't be
mixing and matching. Rather you build against a "target
workbench" and the plugins and the versions of those plugins that
come with a given build. So the question I was trying to figure
out was how to manage the versions of the plugins as every build
of eclipse, wtp, emf... etc have different versions of plugins due
to the introduction of qualifier builds. The answer I think is
that I shouldn't be looking at the individual versions of the jars
as this greatly complicates things especially from a
maintainability perspective, and I should only need to deal with
building against a given distribution. And from that perspective
the the answer is easy, and I can programatically set the versions
of the plugins during build time depending on what distribution
I'm pointing at.
So for any eclipse plugin dependencies declared in my pom's I'm
thinking I'll introduce a "DISTRO" keyword for the version
element. Then at build time, any eclipse dependency with a
version set to DISTRO will be set to the exact version of the
dependency inside the targeted distribution. This makes things
much much simpler. Anytime I want to move up to a different
build, only the build URL would need to change.
If anyone has any other ideas let me know.
- sachin
