:-( Implementation-Version is (or maybe 'was' now) being set
dynamically. I don;t expect the impl version to be the same as the spec
version.
See the build-jar target in each module's build.xml that sets it to the
${svn.info}.
The Specification-Version: can be a property too.
Regards,
Tim
Alexey Petrenko wrote:
We also need to keep Import-Package section up to date...
For sure, and (just to be clear to all) these are not just for Eclipse's
benefit, they are for our benefit as they are the definition of our
class library modularity. When you add a new Import or Export you are
Tim,
I got your point and mostly agree with you.
But in this case we really need some dependency checking routine
because now nobody checks them.
SY, Alexey
2006/10/5, Tim Ellison [EMAIL PROTECTED]:
Alexey Petrenko wrote:
We also need to keep Import-Package section up to date...
For sure,
Alexey Petrenko wrote:
Tim,
I got your point and mostly agree with you.
Which bit do you disagree with g ?
But in this case we really need some dependency checking routine
because now nobody checks them.
Well the Eclipse-based people will be checking them (since we get
compiler errors for
Tim Ellison wrote:
Alexey Petrenko wrote:
We also need to keep Import-Package section up to date...
For sure, and (just to be clear to all) these are not just for Eclipse's
benefit, they are for our benefit as they are the definition of our
class library modularity. When you add a new
Stepan Mishura wrote:
On 10/5/06, Tim Ellison wrote:
Alexey Petrenko wrote:
We also need to keep Import-Package section up to date...
For sure, and (just to be clear to all) these are not just for Eclipse's
benefit, they are for our benefit as they are the definition of our
class library
Can we consider making the final manifest that goes into our jars to be
created/updated dynamically?
I just went through all manifests and added Specification-Version,
Implementation-Version, etc and they will change, at least the last one.
I know the Eclipse people depend on them, so maybe
