In general, we have two forms of the configuration reference in
Geronimo:
parentId="geronimo/foo/1.0/car"
<import>
<groupId>geronimo</groupId>
<artifactId>foo</artifactId>
<version>1.0</version
<type>car</type>
</import>
I think the second form is the easiest to deal with. We can easily,
omit the version and when we introduce maven version ranges (this
should happen soon), you end up with something like this:
<import>
<groupId>geronimo</groupId>
<artifactId>foo</artifactId>
<version>[1.0,2.0)</version
<type>car</type>
</import>
*see http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and
+Conflict+Resolution
The first form is much more problematic. If we omit the version or
add version ranges, we end up with something uguly:
geronimo/foo//car
geronimo/foo/[1.0,2.0)/car
Also this string form is not the maven standard which uses colon ':'
instead of a slash '/'
How about we just eliminate the single string from? In most cases,
you shouldn't need the parentId anyway, and in the cases you do, you
simply use this:
<parent>
<groupId>geronimo</groupId>
<artifactId>foo</artifactId>
</parent >
-dain
P.S., I think we should make "car" the default type and allow it to
be optional.
On Jan 26, 2006, at 12:33 PM, Aaron Mulder wrote:
I believe the problem only affects Geronimo deployment plans written
by users. Either for their own J2EE applications, or for custom
Geronimo services. (And "users" includes "vendors writing Geronimo
extensions or Geronimo-based products"). So if a user writes a plan
with any "1.0" in it and then tries to deploy under 1.0.1 or 1.1 or
whatever, it won't work.
Within the plans, the main thing not in your list is GBean references.
If a custom GBean refers to a Geronimo GBean, it typically has to
include the target GBean's module name (= configId). I think
ServerInfo is the most likely to be used in this way, but any Geronimo
GBean you want to refer to would have the issue.
Other GBean references in the plans include:
References to a WorkManager from a connector plan. That is an
arbitrary GBean reference, and if you use the long form, you may need
to include the owning GBean's module name. Most likely you can avoid
it by either using <gbean-link> or referring to a custom deployed
WorkManager.
References to a TSS/CSS from a CORBA EJB or client, or a
ResourceAdapter from a MDB, or a JDBC pool from any component... I'm
sure I'm forgetting a few more. All are effectively GBean references.
All of these are probably referring to components you deployed so you
can probably choose not to use a version number in the name or at
least you won't be hit by Geronimo revving our version numbers.
I don't think individually the issues with the GBean references are
super-compelling, but all together they add up to something.
Thanks,
Aaron
P.S. The console also has some issues, like for an ActiveMQ JMS
deployment it generates a parent/import for
geronimo/activemq-broker/1.0/car, but that URI is in a config file
with variable substitution applied during the build, so it will only
cause trouble if you use the console to generate a plan and then save
that plan separately and later upgrade Geronimo, at which point it's
the same as the user-supplied plan problem. :)
On 1/26/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
I'm having a hard time following this discussion, because I'm not
sure of the scope of this problem. Is this a problem that only
impacts our xml configs, and does it only impact the following:
o parentId attribute
o import short form element
o import long form
If there are more places we need to address this problem, I'd like to
get them on the table now.
-dain
On Jan 24, 2006, at 11:52 AM, Aaron Mulder wrote:
All,
There was some IRC talk but not a lot of list response to the
configId
versioning issue. Right now, it's kind of holding up 1.0.1 IMHO
because I can't support releasing 1.0.1 until we resolve the
compatibility issue somehow, and there's going to be a fair bit of
work to get it going one way or another. Anyway, for the 1.0.1
release, please indicate your preference for:
[ ] Change all configIds to 1.0 even though it's the 1.0.1 release
[ ] Change all references to use no version and make that work
[ ] Something else (please explain)
For the second option, that means the configId for module would
still
be geronimo/foo/1.0.1/car but any parentId, import, or GBean
reference
would look like this:
parentId="geronimo/foo//car"
<import>geronimo/foo//car</import>
<import>
<groupId>geronimo</groupId>
<artifactId>foo</artifactId>
<type>car</type>
</import>
That is, the version would be omitted from the reference, and we'd
somehow interpret that to mean "whatever version is present" or "use
most current version". You still *could* use a specific version,
we'd
just emphasize the version-less option for maximum compatibility. I
think this alternative would require more work but might be a better
fit for a long-term strategy.
Thanks,
Aaron
