[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[p2-dev] Dynamic or "Latest" Metadata Requires Version?
|
Hi Everyone,
Andrew - in the equinox newsgroup I have a question about maintaining
dependencies in the metadata versus the feature.xml which you answered.
There was one small point left that I can't seem to solve. Here is the
blurb from my post, and your response:
>> It seems that I still will have a build-time dependency in the
>> metadata. I'll need to know what the latest version of the
>> configuration feature is to inject it into the p2.inf, or use a broad
>> range and manually update the version requirements in all of my
p2.inf
>> files. I guess it is no different than maintaining inter-feature
>> dependency versions...
> Our products say nothing about which version of rcp.configuration to
> include. Currently, when the publisher goes to include
rcp.configuration
> into the product, there is no advice telling it >which version to use,
> so it does a query on the build repo and uses the latest version IU
that
> it finds.
> This works because we introduced the dependency by including the
> rcp.configuration feature in the .product file, not by using a p2.inf
file.
My question is - can I accomplish the same thing without a product file?
I am building my features individually, and do not use product files at
all. Is there any way I can use a simple p2.inf or some Ant tasks to
have P2 figure out the latest version of a dependency and stick it into
the metadata? Currently my p2.inf for a particular feature looks like
this:
requires.0.namespace=org.eclipse.equinox.p2.iu
requires.0.name=com.signaklara.artifacts.my.feature1.group
requires.0.range=[1.0.0,2.0.0)
requires.0.greedy=true
requires.0.optional=false
requires.0.multiple=false
Ideally, I'd like to get rid of the "range" and and have it keyed to a
fixed version of the feature group that was present at build time. If I
bump the version of "com.signaklara.artifacts.my.feature1.group", I'll
also rebuild the features that require it, bumping their versions as
well.
The only other way I can see to accomplish this is to write a bunch of
build logic that replaces lines in my p2.inf file based on dependency
artifacts it found in the local build directory before I build my
feature.
Thanks,
Mark.