geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Will 1.0.1 & 1.1 be incompatible with 1.0?
Date Fri, 20 Jan 2006 02:06:57 GMT
It seems like if we move ahead as planned for 1.0.1 and 1.1, we're
going to ship a product with configIds like
geronimo/j2ee-server/1.0.1/car, which means that many deployment plans
written for 1.0 will not be able to be deployed unmodified on 1.0 --
and it will instantly turn a huge number of published articles and
examples into errors (think of it -- any example including a Geronimo
configId will be wrong).  Furthermore, there's no way to write a plan
that will work on more than one specific major/minor/patch release of
Geronimo, if you have a dependency on a server plan other that the
default (such as depending on ActiveMQ or CORBA or whatever) or a
reference to a GBean in a Geronimo configuration other than your own
(such that the module's configId must appear in the reference, like,
say, ServerInfo).  I don't know why this hasn't bothered me up until
now, but I think it's a pretty serious problem.

I think we have a few options:

1) Ship 1.0.1 with all the configIds saying "1.0" so there is no issue
for at least that release

2) Remove version numbers from configIds from 1.0.1 onward, so at
least we can have backward compatibility from 1.0.1 forward

3) Put in some logic to treat all version numbers in configIds as wildcards

4) Support explicit wildcards or version ranges in configIds

My opinions on these are:

I think it would be workable to make all the configIds in 1.0.1 say
1.0, though it would surely be painful to change substitution
variables in ALL the plans accordingly.  Though, this is a pretty
short-sighted fix because eventually we'll have to stop calling
everything 1.0.

I'd be pretty happy removing the version numbers from the configIds,
because I think there has to be a better way to declare and express
version-ness than to bury it in a String that's used for other things.
 I'd rather have a plan say "configId='geronimo/j2ee-server/car'
version='1.0.1' " and a reference say "name='geronimo/j2ee-server/car'
version='1.*' " where the version number is optional for the referrer
(to be used if you really care about locking it down and to be omitted
if you want to maximize portability to other Geronimo versions).  If
we went this way, I guess we would also make the version a separate
property of the ObjectName.

I think supporting wildcards or ranges in the version numbers in
configIds as they are today, and/or treating all version numbers as
wildcards, would be pretty hard to implement.  I also don't think
version ranges or wildcards will work that well.  I expect there won't
be much reason why an application developed and deployed on Geronimo
1.0 wouldn't be able to be redeployed on Geronimo 2.0.  Sure some
things will change, but I hope it will be rare that you might actually
*need* to rewrite an old deployment plan if you just want to redeploy
the same old app and don't care about taking full advantage of
whatever new stuff 2.0 offers.  So if we recommend everyone write 1.x
plans to say "1.*" or "[1.0,2.0)" or whatever, that just means we're
artificially making it impossible to deploy in a future release of
Geronimo without mangling your plans -- and also making configIds a
lot less pleasant to write to begin with

So I think overall I prefer pulling the version out of the configId,
and making it a separate property of the configuration, which you can
use in a reference or not as you please.  Accordingly, I'd also
suggest removing the parentId so any parents have to be declared in a
<import>, where we can make the version number a separate element or
attribute, and I guess we'd need to handle it in GBean references too.

Anyway, bottom line, I'm not real comfortable shipping 1.0.1 without
addressing this in some way.  Maybe we should ship 1.0.1 with all the
configId versions saying 1.0 and then plan to address this ASAP for
1.1 (and maybe even plan to call it 2.0 since it would then be
incompatible with 1.0.x).



View raw message