Fowarding to the dev alias.
We need to decide how to resolve this issue. Presently our version
numbers cannot be compared correctly as we are using a numerical value
in the "qualifier" section which is compared via a String comparison.
We should not do this. We should either use "-<build>" or we
should use the "version" part of this string to represent the version.
For documentation on how this should work:
http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
In other words, we should change bundles like glassfish-api to be:
10.0.0-7 or 10.0.0-15, etc.
Or:
10.0.7 or 10.0.15
Ken
Anissa Lam wrote:
Should we bring this discussion to the dev alias so everyone can
benefit ? Is Admin Console the only one that depends on glassfish-api
version ?
As Sahoo said,
glassfish API should use something like
rev-08
or rev-008 instead of rev-8 to work around the lexicographic string
comparison done by OSGi.
This should really be send to the dev alias, and the problem we are
facing is , it has been set to 10.0.0-rev7, 10.0.0-rev8, and now
at 10.0.0-rev9. Is it possible to go back and fix that and by whom
? otherwise, if i understand it correctly, this is like a time bomb
waiting to explode sometime down the road.
thanks
Anissa.
Sahoo wrote:
If you do
want to rely on bundle-version instead of package-version, then
glassfish API should use something like rev-08 or rev-008 instead of
rev-8 to work around the lexicographic string comparison done by OSGi.
How many zeros should appear after "rev" depends on how many revisions
we expect during a release.
What if you just depend on [10.0.0, 11.0)? I understand that this means
admingui will be resolved in an environment which has lower versions of
glassfish-api, but is that really a problem for you?
Thanks,
Sahoo
Ken Paulsen wrote:
Sahoo, our requirement is to have asynchronous releases of the admin
console. This means we will have a version of the admin console that
will work with any version of GlassFish AFTER a specific version #.
Say in Release v3.8 of GlassFish (hypothetical), that it depends on
glassfish-api version "10.0.0-rev87" -- we will have multiple versions
of the admin console that may be compatible with this. For example:
* In the first release of v3.0, we have a limited functionality
admin console which is still compatible... it depends on glassfish-api
version: 10.0.0-rev9
* Later we release an admin console which adds new functionality and
depends on features added to glassfish-api version 10.0.0-rev59
* And after that for version v3.9.2 we create another version of the
admin console which requires functionality in glassfish-api
10.0.0-rev124.
For those 3 different admin-console apps, the first 2 should work with
v3.8 w/ gf-api rev87. The first one fails! The second one works as
expected. The 3rd one should fail.... but doesn't fail (untill and
invalid api is attempted):
10.0.0-rev9 > 10.0.0-rev87 (oops!)
10.0.0-rev59 < 10.0.0-rev87 (good!)
10.0.0-rev124 < 10.0.0-rev87 (oops!)
Since we're not doing numerical comparisons, we run into these
problems. How do you suggest we solve this?
Thanks,
Ken
Sahoo wrote:
Ken Paulsen wrote:
Sahoo wrote:
Anissa,
Anissa Lam wrote:
Hi ,
Ken Paulsen wrote:
Attached is my pom.xml. Sorry
for
all the questions... I'm just going in circles trying to figure this
out! :) I really appreciate your help.
Thanks Ken for working over the weekend on trying to resolve all the
build issues we are facing, and Sahoo for the help so far.
Also, Ken has updated issue # 5293, and without an answer to that, we
will be facing another versioning problem again when glassfish-api
version goes to 10.0.0-rev10, which is coming up very soon since it is
at rev9 already.
I can't see why this should admingui from working.
Because we depend on 10.0.0-rev8 or higher. 10.0.0-rev10 is LOWER.
You can always specify a different version constraint while generating
the OSGi meta data.
Appreciate Sahoo for helping us
with
all the problem we are facing. I hope that we can address this for
the MS1 built, our user hasn't been able to bring up admin console
for almost 3 weeks now.
I made some changes last Monday. Why did it stop working 2 weeks before
that?
Because the admin gui that got downloaded had been built against an
earlier version of the GF api and until your changes we needed that
specific earlier version.
Same here. If the plugin is generating too restrictive metadata,
override it by specifying your own manifest headers. Please refer to
OSGi R4 spec for the kind of metatada you need.
Thanks,
Sahoo