[p2-dev] Dynamic or "Latest" Metadata Requires Version?

["Mark Melvin" <Mark.Melvin@xxxxxxxxxx>]

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.