[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [p2-dev] Dynamic or "Latest" Metadata Requires Version?

Hello Again,

I never got an answer to this, or figured it out on my own.  I have come
back to this point now.  Aside from manually maintaining version numbers
in all of my p2.inf files, or using this construct:

requires.0.namespace=org.eclipse.equinox.p2.iu
requires.0.name=some.iu.id
requires.0.range=0.0.0

Which, as far as I can tell means to require/use the latest version of
something in a repository, is there any way I can get my build process
to substitute the latest version found (at build time) of a specific,
pre-built requirement that is already present in the build environment?
I understand this works if you build from a .product file, but is there
any way for me to accomplish the same thing without a .product file?

For example, I just built "my.cool.feature" version 2.0.1, and it is
grabbed and used in the build for "my.other.cool.feature", version
1.0.0.  Basically, I want to do something like this in my p2.inf for
"my.other.cool.feature":

requires.0.namespace=org.eclipse.equinox.p2.iu
requires.0.name=my.cool.feature
requires.0.range=$my.cool.feature.version$

(where $my.cool.feature.version$ evaluates to [2.0.1,2.0.1])

Is this possible?

Thanks,
Mark.
-------------------------------------------- 

> -----Original Message-----
> From: p2-dev-bounces@xxxxxxxxxxx 
> [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Mark Melvin
> Sent: May 12, 2009 11:13 AM
> To: P2 developer discussions
> Subject: [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.
> _______________________________________________
> p2-dev mailing list
> p2-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/p2-dev
>