geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: Poll: Resolve configId Versions for 1.0.1
Date Thu, 26 Jan 2006 21:06:54 GMT
On 1/26/06, Dain Sundstrom <dain@iq80.com> wrote:
> 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.

Except, we currently allow you to specify abitrary configIds.  So you
can declare a configId of "foo" or "foo/bar", and then it's not clear
what an import would look like if you tried to use the split-up syntax
to refer to that configId.

Also, parentId is currently an attribute which we can't decompose as
easily.  Granted we could just eliminate parentId in favor of <import>
(which as far as I can tell does the same thing), but we still have to
figure out what to do about the above.  I'm not super-thrilled with
telling people that they must write every plan using the
configId="group/artifact/version/type" syntax.

Can we say "there are configIds with 3 slashes and there are all other
configIds" and "if you don't have 3 slashes then you only use
artifactId to refer to it, otherwise you must use at least groupId and
artifactId and may use version and type"?

I'm not sure about making "car" the default since we also use these
same elements for dependencies, which are most naturally of type
"jar".  Though I guess there's no reason we can't have different
defaults for "import" than for "dependency" and "include".

Thanks,
    Aaron

> 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 <dain@iq80.com> 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
> >>
> >>
>
>

Mime
View raw message