You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2005/11/18 08:30:15 UTC
Warning of change in configId format
I have been working on assembling geronimo using the packaging and
assembly plugins. This gives us the ability to put together versions
of geronimo with different capabilities without duplication. For
instance, we now have a jetty-only and a tomcat-only version of
geronimo. To build these,
cd configs;maven -o multiproject:install; cd ..
cd assemblies/j2ee-jetty-server;maven -o;
cd ../j2ee-tomcat-server:maven -o
This relies on using the packaging plugin, which builds configurations
and puts them into the local maven repository. As such, it uses the
maven id as the configId: they typically look like
${groupId}/cars/${artifactId}-${pom.currentVersion}.car
I think this is a big improvement over the unsystematic hand-invented
ids we have been relying on up to now, but it is a backwards
incompatible change that will require changing any plan that mentions a
parentId (many plans do not need to: the builders include default
parents sufficient for the geronimo classes needed for the app to
load). It will also require changing the <module> element in gbean
references that include them.
I think we should just go ahead with the change, and announce it
loudly. We could provide "adapter plans" with no content of any kind
that have e.g. a configId of org/apache/geronimo/rmi-naming and a
parentId of geronimo/cars/geronimo-rmi-naming-1.0-SNAPSHOT.car. This
would allow plans that have only old-style parentIds to deploy
successfully, but would not help with the gbean references.
I beileve in a slightly related development we are planning to change
the groupId to org.apache.geronimo before v1. Doing these changes more
or less at once might reduce confusion.
Comments? Objections?
thanks
david jencks
Re: Warning of change in configId format
Posted by John Sisson <jr...@gmail.com>.
Dain Sundstrom wrote:
> On Nov 22, 2005, at 1:35 PM, David Jencks wrote:
>
>> To me the biggest problem here is still backwards compatibility and
>> if/how we can support it. Dain suggested (privately) that we might
>> have a conversion table for our configids so that an old plan would
>> still deploy. This is possible but really ugly. I will look into
>> just how ugly :-) I'd certainly appreciate any other opinions on
>> how serious a problem this is and what we can do about it.
>>
>> Now to more specific responses:
>> On Nov 18, 2005, at 6:59 AM, Aaron Mulder wrote:
>>
>>> I assume it will be the case that the configId declaration in the file
>>> will therefore control which repository location the CAR is installed
>>> in -- so if you change the configId, it changes the install location.
>>> Is that correct?
>>
>>
>> well, maybe. The packaging plugin is the only way currently to get
>> a car file into a maven-like repository, and it only uses the actual
>> maven repository at the moment. The identity of path inside the
>> maven repo and configId is currently a convention, but IMO a really
>> good one. I'd like to see if a packed-car repository config- store
>> works, but I doubt I'll have time to try it before 1.0.
>
>
> I think using the maven repo path for the configId is problematic.
> The layout of the repository will change over time, and is actually
> completely repository dependent. We have already seen a change
> between maven 1 and maven 2. I would prefer that the ID follow the
> maven single line notation for an artifact.
>
> groupId:artifactId:version:type[:classifier]
>
> In this case, we don't need a classifier and we can always assume
> type is "car", so we will end up with something like:
>
> org.apache.geronimo:j2ee-server:1.0
>
> which I think is a lot cleaner then the m1 and m2 paths, as doesn't
> repeat information:
>
> org.apache.geronimo./cars/geronimo-j2ee-server-1.0.car
> org/apache/geronimo/geronimo-j2ee-server/1.0/geronimo-j2ee-
> server-1.0.car
>
> Does that seem reasonable?
I like the maven single line notation proposed above. Having it follow
a more structured format like this could give us more flexibility in the
future than freeform names.
>
>>> Here are my issues:
>>> - It's a pretty significant change for the "last gasp before 1.0". I
>>> would *really* prefer to hold off on this so we have some time to
>>> think it through and work with it a bit longer before committing to it
>>> as the future, but I'm afraid that you won't deliver separate
>>> Jetty/Tomcat builds without it. What do you think?
>>
>>
>> Right, for me this is a requirement for separate jetty/tomcat builds.
>
>
> I think this is one of the things we address now, or defer until
> Geronimo 2.0, whenever that is.
If we think there might be issues migrating users from 1.0 to a later
release that has a different configId scheme then I think we need to
address this now.
>
>>> - I want to make sure that application configIds or configIds for
>>> services created by the user (e.g. database pools, security realms)
>>> can still be anything at all ("foo") and don't have to follow the
>>> Maven style naming. Further, I don't think that not using Maven- style
>>> configIds for your application should limit your capabilities in any
>>> way (no, "can't deploy to a cluster if you can't use the packaging
>>> plugin if you didn't use Maven-style configIds" or anything like that)
>>
>>
>> AFAIK we don't have clustering yet... there's nothing stopping you
>> from using whatever badly thought out :-) configIds you want, but I
>> think we should encourage people to use configIds with systematic
>> and useful info in them -- i.e. the maven style ones.
>
>
> Well if we want to use maven artifact to manage our repository, we
> are going to need a groupId, artifactId and a version. We could
> simply make groupId and vendorId equal what ever random string the
> user give us and make the version a time stamp. I think it would be
> better if the deployment tool prompted for the groupId and artifactId
> if there wasn't a geronimo plan in the archive, but it isn't necessary.
In regards to using a maven style repository for configurations:
I'm not sure if I have misunderstood whether you are proposing to change
the way configurations are stored...
How do you picture a configuration in the configuration store (maven
style) being placed there and accessed by geronimo instances in a
cluster when a configuration is deployed?
Will there be a central repository containing versioned configs that all
instances in the cluster will access? What happens if the machine
containing the central repository dies?
Or will each instance (could be on the same machine or remote machines)
have its own repository (seems to go against the maven repository concept)?
Currently the current config store stores web app files in an expanded
directory format. If we were to use a maven repo as the config store
then I am assuming that isn't possible and containers such as
Tomcat/Jetty would have to read files from the CAR? If so, does this
have any implications?
We would also have to think about maintaining the repository (enable old
configurations to be removed so we don't use up too much disk space) as
it would build up quickly, especially in a development environment where
new versions are deployed and tested often.
It seems (since you mentioned maven artifact above) you are suggesting
that a maven would need to be installed to properly manage geronimo
configurations in a repository. If this is the case I think this needs
to be made clear to everyone to get their buy in.
Regards,
John
>
> -dain
>
Re: Possible problems with maven-style configIds WAS: Warning of change in configId format
Posted by Dain Sundstrom <da...@iq80.com>.
On Nov 23, 2005, at 4:14 PM, David Jencks wrote:
> On Nov 23, 2005, at 2:02 PM, Dain Sundstrom wrote:
>
>> On Nov 23, 2005, at 3:27 PM, David Jencks wrote:
>>
>>> Should we change our dependency URIs to the same format? I'm
>>> inclined to think we should. I would prefer to include the type
>>> (car|jar) for completeness and to distinguish dependencies from
>>> configIds.
>>
>> I know it will make the files much longer, but I'd prefer we drop
>> or deprecate support for the single line dependency declaration,
>> which means we require the full format:
>>
>> <dependency>
>> <groupId>org.apache.geronimo</groupId>
>> <artifactId>kernel</artifactId>
>> <version>1.0</version>
>> </dependency>
>
> Look in the configs/assemblies builds. All dependency elements are
> generated by the plugins, and are in this format.
Very nice. Do we can deprecate the one liner format now, or wait for
another release?
>>> So I think this format proposal takes care of (3) and (4) and I
>>> already implemented (1) and (2) although with the : separator.
>>> I'm not sure if this format might cause confusion anywhere
>>> between a resolvable path URI and this more abstract configId
>>> format.
>>
>> It is possible. Who will actually see it? If it is just us
>> geronimo programmers, we should document it. If it is users, I
>> think we should think about mitigating the impact.
>
> I'm mostly wondering about jsr-77 object names. But, we already
> have both meaningless configId uris and, in ear module names, path
> uris for relative position in the ear. So I'm not sure this would
> introduce any more confusion.
I think the name will be a bit tighter, but will still be pretty
unreadable for users anyway. At least we aren't making it worse :)
>>>> Are there any other changes of note?
>>>
>>> Using the plugins rather than tons of jelly is a big change, but
>>> I'm not sure what else might be a change "of note". Also for a
>>> while now the plugin-based build has been extracting dependency
>>> info from project.xml rather than requiring you to duplicate it.
>>
>> Cool. I was really asking about changes to the internal stuff or
>> to the plans themselves.
>
> Well, I'd recommend if we decide to change to this uri format that
> the Repository implementations accept them rather than the current
> path based uris they are accepting.
+1
> ConfigIds in plans should all change. Plans we supply are all (in
> configs build) using (generated) dependencies and imports of the
> long format already. IMO you should be specifiying all the parents
> using import tags anyway in the long format (this is done in
> configs build as well (as soon as I commit the next cleanup :-)).
+1
> I'm starting to think this is doable by 1.0. It would be nice to
> hear other opinions...
+1
-dain
Re: Possible problems with maven-style configIds WAS: Warning of change in configId format
Posted by David Jencks <da...@yahoo.com>.
On Nov 23, 2005, at 2:02 PM, Dain Sundstrom wrote:
> On Nov 23, 2005, at 3:27 PM, David Jencks wrote:
>
>>
>> On Nov 23, 2005, at 1:12 PM, Dain Sundstrom wrote:
>>
>>> On Nov 23, 2005, at 1:58 PM, David Jencks wrote:
>>>
>>>> I've investigated this a little bit and think it might be too big
>>>> a lurch in a new direction for 1.0. Here are a few of the things
>>>> that would have to change or appear to be problems:
>>>>
>>>> 1. constructing the configId from groupId + artifactId + version +
>>>> type. This is pretty easy.
>>>> 2. finding stuff in a repo and/or config store from the configId.
>>>> This is fairly easy
>>>> 3. Constructing the ObjectNames that include the configId in
>>>> J2EEApplication and/or J2EEModule. This requires quoting the
>>>> configId which is a big pain and is apt to cause difficulties
>>>> everywhere.
>>>> 4. We have been using URI for the configIds internally. I think if
>>>> we use this new format this should change. The : character appears
>>>> to have a specific meaning in URIs and it is decidedly different
>>>> from what we are meaning by it. We could perhaps introduce a
>>>> scheme and write
>>>> configid:groupId:artifactId:version:type. I could not tell from a
>>>> bit of research on URIs whether this is consistent with their
>>>> intended semantics. Does it make sense to have URIs of this form?
>>>> Should we just change our configId type to something else?
>>>>
>>>> At this point I think we need more discussion before we proceed
>>>> along this route. I have some of it implemented.... please speak
>>>> up.
>>>
>>> My opinion, is we don't make incompatible changes between major
>>> releases, so if we decide not to do this now, it will be harder to
>>> do it later.
>>>
>>> Anyway, I see your point, so lets talk about what changes you want
>>> to implement pre-1.0?
>>>
>>> If you are changing the configuration ids, I'd like to make sure the
>>> format is something we can easily parse into groupId, artifactId and
>>> version. For example, we could go with:
>>>
>>> org.apache.geronimo/j2ee-server/1.0
>>
>> Should we change our dependency URIs to the same format? I'm
>> inclined to think we should. I would prefer to include the type
>> (car|jar) for completeness and to distinguish dependencies from
>> configIds.
>
> I know it will make the files much longer, but I'd prefer we drop or
> deprecate support for the single line dependency declaration, which
> means we require the full format:
>
> <dependency>
> <groupId>org.apache.geronimo</groupId>
> <artifactId>kernel</artifactId>
> <version>1.0</version>
> </dependency>
Look in the configs/assemblies builds. All dependency elements are
generated by the plugins, and are in this format.
>
>> So I think this format proposal takes care of (3) and (4) and I
>> already implemented (1) and (2) although with the : separator. I'm
>> not sure if this format might cause confusion anywhere between a
>> resolvable path URI and this more abstract configId format.
>
> It is possible. Who will actually see it? If it is just us geronimo
> programmers, we should document it. If it is users, I think we should
> think about mitigating the impact.
I'm mostly wondering about jsr-77 object names. But, we already have
both meaningless configId uris and, in ear module names, path uris for
relative position in the ear. So I'm not sure this would introduce any
more confusion.
>
>>> Are there any other changes of note?
>>
>> Using the plugins rather than tons of jelly is a big change, but I'm
>> not sure what else might be a change "of note". Also for a while now
>> the plugin-based build has been extracting dependency info from
>> project.xml rather than requiring you to duplicate it.
>
> Cool. I was really asking about changes to the internal stuff or to
> the plans themselves.
Well, I'd recommend if we decide to change to this uri format that the
Repository implementations accept them rather than the current path
based uris they are accepting.
ConfigIds in plans should all change. Plans we supply are all (in
configs build) using (generated) dependencies and imports of the long
format already. IMO you should be specifiying all the parents using
import tags anyway in the long format (this is done in configs build as
well (as soon as I commit the next cleanup :-)).
I'm starting to think this is doable by 1.0. It would be nice to hear
other opinions...
thanks
david jencks
>
> -dain
>
Re: Possible problems with maven-style configIds WAS: Warning of change in configId format
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Also, we need to think about the meaning of "version". You might
deploy a lot of times between designated versions of an application.
I'd prefer that we not require that the version be SNAPSHOT if you're
going to do that (because then they really are indistinguishable). It
would be nice if you could be working on App-1.2.1 and deploy 10 times
and Geronimo internally kept track of 1.2.1 deploy #1 vs 1.2.1 deploy
#2, etc. I'm not sure how to accomodate that in the
vendor/app/type/version scheme that Maven uses for released builds.
Aaron
On 11/23/05, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> On 11/23/05, David Jencks <da...@yahoo.com> wrote:
> > First, I think Dain is talking mostly about dependencies here. In this
> > case if we continue to support the short form you would write
> >
> > <uri>yourGroup/yourArtifact/yourVersion/jar</uri>
> >
> > rather than
> >
> > <uri>yourGroup/jars/yourArtifact-yourVersion.jar</uri>
> >
> > which to my untutored eyes looks shorter and simpler. However, I think
> > encouraging people to use the long form is clearer and leads to less
> > confusion and it can be installed by maven from your project.xml.
>
> But not shorter or simpler than "yourApp" (which I guess is the same
> as "yourArtifact" or maybe "yourArtifact yourVersion"). If you buy
> into the rigor that Maven enforces, then I think the proposal that you
> and Dain are working with is fine. But I don't want to see Geronimo
> require that rigor of its users, since many of them won't need/want
> it. At least not a first -- maybe once they discover the wonders
> they'll sign on, but I don't thing many of them are coming pre-sold on
> Maven.
>
> > All simple apps shouldn't need to specify any parentIds at all in any
> > way, one line or import-style multiline. The builders insert the
> > parentIds that are needed for that kind of j2ee module to run. Unless
> > you are doing something unusual like having applications depend on each
> > other this should work. If it doesn't we probably need to adjust the
> > default parentIds in the builders.
>
> Well, let's say you want your database pool to always be started
> before your application. What is the recommended way to make that
> happen?
>
> > ...
> > Could you be more explicit about what you are talking about here? So
> > far I have no idea.
>
> <import>, <include>, <dependency> -- they all are of XML type
> "dependencyType", meaning that they take either a single URI or a set
> of Maven chunks. Yet some of them poitn to repository locations and
> some of them refer to a configId, which may look like a repository
> location but may also not. I still think we should have two different
> XML types, one for the elements that are repository locations and one
> for the elements that are configIds. (That would also let us
> establish different rules for each, such as requiring the Maven format
> for things in the repository.)
>
> > If you are using a custom database pool in your app, why wouldn't you
> > include the pool configuration in your plan in one of the numerous
> > supported ways?
>
> Because no other app server really works that way, and all our users
> will be coming from other app servers. I think our adoption will be
> helped by working in the way that people expect us to work, even if
> it's less than coneceptually ideal. I support hot deploy and you
> don't for the same reasons. :)
>
> > Once you get to "sharing between multiple apps" situations, I think
> > these are sufficiently complicated that requiring users to pay
> > attention to who they are (groupId) and how far along their project
> > parts are relative to one another (version) will only help them.
>
> Again, why are you telling the users how to work? I don't like that
> direction in tools. Even if you think it would be smarter for the
> user to work in the way you are outlining, why not leave the door open
> to other ways? If your way is better, I'm sure users will migrate to
> it over time, but since none of them are coming from it, if you insist
> on it, it only makes a very large learning curve.
>
> > Well, once we have a defined and meaningful format for config Ids, we
> > have the possibility of supplying defaults somewhere in the system.
> > For instance, we might tell the deployer that if the groupid is
> > missing, it should default to your company groupId. Similarly for the
> > version. I'm not sure how plausible it is to push this into module
> > tags in references, but we might be able to come up with something. If
> > we continue on our current path of random and meaningless configIds no
> > such defaults are possible.
>
> OK, but again, you're talking about changing the way that people
> operate. Other servers don't ask that you tell them your company or
> organization so that they can decide how to name your deployments.
> Let's make the easy path easy, and then help guide people to the more
> advanced path later.
>
> Thanks,
> Aaron
>
Re: Possible problems with maven-style configIds WAS: Warning of change in configId format
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 11/23/05, David Jencks <da...@yahoo.com> wrote:
> First, I think Dain is talking mostly about dependencies here. In this
> case if we continue to support the short form you would write
>
> <uri>yourGroup/yourArtifact/yourVersion/jar</uri>
>
> rather than
>
> <uri>yourGroup/jars/yourArtifact-yourVersion.jar</uri>
>
> which to my untutored eyes looks shorter and simpler. However, I think
> encouraging people to use the long form is clearer and leads to less
> confusion and it can be installed by maven from your project.xml.
But not shorter or simpler than "yourApp" (which I guess is the same
as "yourArtifact" or maybe "yourArtifact yourVersion"). If you buy
into the rigor that Maven enforces, then I think the proposal that you
and Dain are working with is fine. But I don't want to see Geronimo
require that rigor of its users, since many of them won't need/want
it. At least not a first -- maybe once they discover the wonders
they'll sign on, but I don't thing many of them are coming pre-sold on
Maven.
> All simple apps shouldn't need to specify any parentIds at all in any
> way, one line or import-style multiline. The builders insert the
> parentIds that are needed for that kind of j2ee module to run. Unless
> you are doing something unusual like having applications depend on each
> other this should work. If it doesn't we probably need to adjust the
> default parentIds in the builders.
Well, let's say you want your database pool to always be started
before your application. What is the recommended way to make that
happen?
> ...
> Could you be more explicit about what you are talking about here? So
> far I have no idea.
<import>, <include>, <dependency> -- they all are of XML type
"dependencyType", meaning that they take either a single URI or a set
of Maven chunks. Yet some of them poitn to repository locations and
some of them refer to a configId, which may look like a repository
location but may also not. I still think we should have two different
XML types, one for the elements that are repository locations and one
for the elements that are configIds. (That would also let us
establish different rules for each, such as requiring the Maven format
for things in the repository.)
> If you are using a custom database pool in your app, why wouldn't you
> include the pool configuration in your plan in one of the numerous
> supported ways?
Because no other app server really works that way, and all our users
will be coming from other app servers. I think our adoption will be
helped by working in the way that people expect us to work, even if
it's less than coneceptually ideal. I support hot deploy and you
don't for the same reasons. :)
> Once you get to "sharing between multiple apps" situations, I think
> these are sufficiently complicated that requiring users to pay
> attention to who they are (groupId) and how far along their project
> parts are relative to one another (version) will only help them.
Again, why are you telling the users how to work? I don't like that
direction in tools. Even if you think it would be smarter for the
user to work in the way you are outlining, why not leave the door open
to other ways? If your way is better, I'm sure users will migrate to
it over time, but since none of them are coming from it, if you insist
on it, it only makes a very large learning curve.
> Well, once we have a defined and meaningful format for config Ids, we
> have the possibility of supplying defaults somewhere in the system.
> For instance, we might tell the deployer that if the groupid is
> missing, it should default to your company groupId. Similarly for the
> version. I'm not sure how plausible it is to push this into module
> tags in references, but we might be able to come up with something. If
> we continue on our current path of random and meaningless configIds no
> such defaults are possible.
OK, but again, you're talking about changing the way that people
operate. Other servers don't ask that you tell them your company or
organization so that they can decide how to name your deployments.
Let's make the easy path easy, and then help guide people to the more
advanced path later.
Thanks,
Aaron
Re: Possible problems with maven-style configIds WAS: Warning of change in configId format
Posted by David Jencks <da...@yahoo.com>.
On Nov 23, 2005, at 3:46 PM, Aaron Mulder wrote:
> On 11/23/05, Dain Sundstrom <da...@iq80.com> wrote:
>> I know it will make the files much longer, but I'd prefer we drop or
>> deprecate support for the single line dependency declaration, which
>> means we require the full format:
>
> I object to doing this. I really think most users are going to want
> to give their applications short and sweet config IDs like "AppName".
> OK, yes, that means you can't use the packaging plugin to install
> them, but I as a user am totally comfortable with that, and I don't
> see why I should have to do something like the huge block below for
> every little module I write. P.S. I also would be opposed to needing
> to specify the parentId using 4 attributes.
First, I think Dain is talking mostly about dependencies here. In this
case if we continue to support the short form you would write
<uri>yourGroup/yourArtifact/yourVersion/jar</uri>
rather than
<uri>yourGroup/jars/yourArtifact-yourVersion.jar</uri>
which to my untutored eyes looks shorter and simpler. However, I think
encouraging people to use the long form is clearer and leads to less
confusion and it can be installed by maven from your project.xml.
All simple apps shouldn't need to specify any parentIds at all in any
way, one line or import-style multiline. The builders insert the
parentIds that are needed for that kind of j2ee module to run. Unless
you are doing something unusual like having applications depend on each
other this should work. If it doesn't we probably need to adjust the
default parentIds in the builders.
Anyone who is doing something complicated enough to require explicitly
specifying parent ids will probably not mind the extra clarity and
structure the longer format provides.
>
> So I won't kick and scream too much if you change our server
> components to use stuff like that in their own plans, but I will be
> pretty grumpy if users are required to use that in order to write any
> basic Geronimo plan containing a configId and parentId. And since
> there's no distinguishing between the elements that point to a
> location in the repository and the elements that simply take an
> abstract URI (another mistake IMHO but David J continues to overrule
> me on this one)
Could you be more explicit about what you are talking about here? So
far I have no idea.
> , if you're going to be allowed to name your database
> pool "MyPool" and then create an app "MyApp" with "MyPool" as a parent
> or dependency, we can't insist that people use the Maven-style format.
If you are using a custom database pool in your app, why wouldn't you
include the pool configuration in your plan in one of the numerous
supported ways?
Once you get to "sharing between multiple apps" situations, I think
these are sufficiently complicated that requiring users to pay
attention to who they are (groupId) and how far along their project
parts are relative to one another (version) will only help them.
>
> I think this would all be a lot more palatable if we could think up a
> way for a user to use a short name like "MyApp" and we use more large
> and explicit naming under the covers but allow the user to do
> everything with only "MyApp", but I think that might be challenging.
Well, once we have a defined and meaningful format for config Ids, we
have the possibility of supplying defaults somewhere in the system.
For instance, we might tell the deployer that if the groupid is
missing, it should default to your company groupId. Similarly for the
version. I'm not sure how plausible it is to push this into module
tags in references, but we might be able to come up with something. If
we continue on our current path of random and meaningless configIds no
such defaults are possible.
thanks
david jencks
>
> Aaron
>
>> <dependency>
>> <groupId>org.apache.geronimo</groupId>
>> <artifactId>kernel</artifactId>
>> <version>1.0</version>
>> </dependency>
>>
>>> So I think this format proposal takes care of (3) and (4) and I
>>> already implemented (1) and (2) although with the : separator. I'm
>>> not sure if this format might cause confusion anywhere between a
>>> resolvable path URI and this more abstract configId format.
>>
>> It is possible. Who will actually see it? If it is just us geronimo
>> programmers, we should document it. If it is users, I think we
>> should think about mitigating the impact.
>>
>>>> Are there any other changes of note?
>>>
>>> Using the plugins rather than tons of jelly is a big change, but
>>> I'm not sure what else might be a change "of note". Also for a
>>> while now the plugin-based build has been extracting dependency
>>> info from project.xml rather than requiring you to duplicate it.
>>
>> Cool. I was really asking about changes to the internal stuff or to
>> the plans themselves.
>>
>> -dain
>>
>>
>
Re: Possible problems with maven-style configIds WAS: Warning of change in configId format
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 11/23/05, Dain Sundstrom <da...@iq80.com> wrote:
> I know it will make the files much longer, but I'd prefer we drop or
> deprecate support for the single line dependency declaration, which
> means we require the full format:
I object to doing this. I really think most users are going to want
to give their applications short and sweet config IDs like "AppName".
OK, yes, that means you can't use the packaging plugin to install
them, but I as a user am totally comfortable with that, and I don't
see why I should have to do something like the huge block below for
every little module I write. P.S. I also would be opposed to needing
to specify the parentId using 4 attributes.
So I won't kick and scream too much if you change our server
components to use stuff like that in their own plans, but I will be
pretty grumpy if users are required to use that in order to write any
basic Geronimo plan containing a configId and parentId. And since
there's no distinguishing between the elements that point to a
location in the repository and the elements that simply take an
abstract URI (another mistake IMHO but David J continues to overrule
me on this one), if you're going to be allowed to name your database
pool "MyPool" and then create an app "MyApp" with "MyPool" as a parent
or dependency, we can't insist that people use the Maven-style format.
I think this would all be a lot more palatable if we could think up a
way for a user to use a short name like "MyApp" and we use more large
and explicit naming under the covers but allow the user to do
everything with only "MyApp", but I think that might be challenging.
Aaron
> <dependency>
> <groupId>org.apache.geronimo</groupId>
> <artifactId>kernel</artifactId>
> <version>1.0</version>
> </dependency>
>
> > So I think this format proposal takes care of (3) and (4) and I
> > already implemented (1) and (2) although with the : separator. I'm
> > not sure if this format might cause confusion anywhere between a
> > resolvable path URI and this more abstract configId format.
>
> It is possible. Who will actually see it? If it is just us geronimo
> programmers, we should document it. If it is users, I think we
> should think about mitigating the impact.
>
> >> Are there any other changes of note?
> >
> > Using the plugins rather than tons of jelly is a big change, but
> > I'm not sure what else might be a change "of note". Also for a
> > while now the plugin-based build has been extracting dependency
> > info from project.xml rather than requiring you to duplicate it.
>
> Cool. I was really asking about changes to the internal stuff or to
> the plans themselves.
>
> -dain
>
>
Re: Possible problems with maven-style configIds WAS: Warning of change in configId format
Posted by Dain Sundstrom <da...@iq80.com>.
On Nov 23, 2005, at 3:27 PM, David Jencks wrote:
>
> On Nov 23, 2005, at 1:12 PM, Dain Sundstrom wrote:
>
>> On Nov 23, 2005, at 1:58 PM, David Jencks wrote:
>>
>>> I've investigated this a little bit and think it might be too
>>> big a lurch in a new direction for 1.0. Here are a few of the
>>> things that would have to change or appear to be problems:
>>>
>>> 1. constructing the configId from groupId + artifactId + version
>>> + type. This is pretty easy.
>>> 2. finding stuff in a repo and/or config store from the
>>> configId. This is fairly easy
>>> 3. Constructing the ObjectNames that include the configId in
>>> J2EEApplication and/or J2EEModule. This requires quoting the
>>> configId which is a big pain and is apt to cause difficulties
>>> everywhere.
>>> 4. We have been using URI for the configIds internally. I think
>>> if we use this new format this should change. The : character
>>> appears to have a specific meaning in URIs and it is decidedly
>>> different from what we are meaning by it. We could perhaps
>>> introduce a scheme and write
>>> configid:groupId:artifactId:version:type. I could not tell from
>>> a bit of research on URIs whether this is consistent with their
>>> intended semantics. Does it make sense to have URIs of this
>>> form? Should we just change our configId type to something else?
>>>
>>> At this point I think we need more discussion before we proceed
>>> along this route. I have some of it implemented.... please speak
>>> up.
>>
>> My opinion, is we don't make incompatible changes between major
>> releases, so if we decide not to do this now, it will be harder to
>> do it later.
>>
>> Anyway, I see your point, so lets talk about what changes you want
>> to implement pre-1.0?
>>
>> If you are changing the configuration ids, I'd like to make sure
>> the format is something we can easily parse into groupId,
>> artifactId and version. For example, we could go with:
>>
>> org.apache.geronimo/j2ee-server/1.0
>
> Should we change our dependency URIs to the same format? I'm
> inclined to think we should. I would prefer to include the type
> (car|jar) for completeness and to distinguish dependencies from
> configIds.
I know it will make the files much longer, but I'd prefer we drop or
deprecate support for the single line dependency declaration, which
means we require the full format:
<dependency>
<groupId>org.apache.geronimo</groupId>
<artifactId>kernel</artifactId>
<version>1.0</version>
</dependency>
> So I think this format proposal takes care of (3) and (4) and I
> already implemented (1) and (2) although with the : separator. I'm
> not sure if this format might cause confusion anywhere between a
> resolvable path URI and this more abstract configId format.
It is possible. Who will actually see it? If it is just us geronimo
programmers, we should document it. If it is users, I think we
should think about mitigating the impact.
>> Are there any other changes of note?
>
> Using the plugins rather than tons of jelly is a big change, but
> I'm not sure what else might be a change "of note". Also for a
> while now the plugin-based build has been extracting dependency
> info from project.xml rather than requiring you to duplicate it.
Cool. I was really asking about changes to the internal stuff or to
the plans themselves.
-dain
Re: Possible problems with maven-style configIds WAS: Warning of change in configId format
Posted by David Jencks <da...@yahoo.com>.
On Nov 23, 2005, at 1:12 PM, Dain Sundstrom wrote:
> On Nov 23, 2005, at 1:58 PM, David Jencks wrote:
>
>> I've investigated this a little bit and think it might be too big a
>> lurch in a new direction for 1.0. Here are a few of the things that
>> would have to change or appear to be problems:
>>
>> 1. constructing the configId from groupId + artifactId + version +
>> type. This is pretty easy.
>> 2. finding stuff in a repo and/or config store from the configId.
>> This is fairly easy
>> 3. Constructing the ObjectNames that include the configId in
>> J2EEApplication and/or J2EEModule. This requires quoting the
>> configId which is a big pain and is apt to cause difficulties
>> everywhere.
>> 4. We have been using URI for the configIds internally. I think if
>> we use this new format this should change. The : character appears
>> to have a specific meaning in URIs and it is decidedly different from
>> what we are meaning by it. We could perhaps introduce a scheme and
>> write
>> configid:groupId:artifactId:version:type. I could not tell from a
>> bit of research on URIs whether this is consistent with their
>> intended semantics. Does it make sense to have URIs of this form?
>> Should we just change our configId type to something else?
>>
>> At this point I think we need more discussion before we proceed along
>> this route. I have some of it implemented.... please speak up.
>
> My opinion, is we don't make incompatible changes between major
> releases, so if we decide not to do this now, it will be harder to do
> it later.
>
> Anyway, I see your point, so lets talk about what changes you want to
> implement pre-1.0?
>
> If you are changing the configuration ids, I'd like to make sure the
> format is something we can easily parse into groupId, artifactId and
> version. For example, we could go with:
>
> org.apache.geronimo/j2ee-server/1.0
Should we change our dependency URIs to the same format? I'm inclined
to think we should. I would prefer to include the type (car|jar) for
completeness and to distinguish dependencies from configIds.
So I think this format proposal takes care of (3) and (4) and I already
implemented (1) and (2) although with the : separator. I'm not sure if
this format might cause confusion anywhere between a resolvable path
URI and this more abstract configId format.
>
> Are there any other changes of note?
Using the plugins rather than tons of jelly is a big change, but I'm
not sure what else might be a change "of note". Also for a while now
the plugin-based build has been extracting dependency info from
project.xml rather than requiring you to duplicate it.
thanks
david jencks
>
> -dain
>
Re: Possible problems with maven-style configIds WAS: Warning of change in configId format
Posted by Dain Sundstrom <da...@iq80.com>.
On Nov 23, 2005, at 1:58 PM, David Jencks wrote:
> I've investigated this a little bit and think it might be too big
> a lurch in a new direction for 1.0. Here are a few of the things
> that would have to change or appear to be problems:
>
> 1. constructing the configId from groupId + artifactId + version +
> type. This is pretty easy.
> 2. finding stuff in a repo and/or config store from the configId.
> This is fairly easy
> 3. Constructing the ObjectNames that include the configId in
> J2EEApplication and/or J2EEModule. This requires quoting the
> configId which is a big pain and is apt to cause difficulties
> everywhere.
> 4. We have been using URI for the configIds internally. I think if
> we use this new format this should change. The : character appears
> to have a specific meaning in URIs and it is decidedly different
> from what we are meaning by it. We could perhaps introduce a
> scheme and write
> configid:groupId:artifactId:version:type. I could not tell from a
> bit of research on URIs whether this is consistent with their
> intended semantics. Does it make sense to have URIs of this form?
> Should we just change our configId type to something else?
>
> At this point I think we need more discussion before we proceed
> along this route. I have some of it implemented.... please speak up.
My opinion, is we don't make incompatible changes between major
releases, so if we decide not to do this now, it will be harder to do
it later.
Anyway, I see your point, so lets talk about what changes you want to
implement pre-1.0?
If you are changing the configuration ids, I'd like to make sure the
format is something we can easily parse into groupId, artifactId and
version. For example, we could go with:
org.apache.geronimo/j2ee-server/1.0
Are there any other changes of note?
-dain
Possible problems with maven-style configIds WAS: Warning of change in configId format
Posted by David Jencks <da...@yahoo.com>.
>>
<snip>
>> I think using the maven repo path for the configId is problematic.
>> The layout of the repository will change over time, and is actually
>> completely repository dependent. We have already seen a change
>> between maven 1 and maven 2. I would prefer that the ID follow the
>> maven single line notation for an artifact.
>>
>> groupId:artifactId:version:type[:classifier]
>>
>> In this case, we don't need a classifier and we can always assume
>> type is "car", so we will end up with something like:
>>
>> org.apache.geronimo:j2ee-server:1.0
>>
>> which I think is a lot cleaner then the m1 and m2 paths, as doesn't
>> repeat information:
>>
>> org.apache.geronimo./cars/geronimo-j2ee-server-1.0.car
>> org/apache/geronimo/geronimo-j2ee-server/1.0/geronimo-j2ee-server
>> -1.0.car
>>
>> Does that seem reasonable?
>
> I like that a lot. I have been wondering how to extract the pieces of
> the repo path back out of the configId.
>
I've investigated this a little bit and think it might be too big a
lurch in a new direction for 1.0. Here are a few of the things that
would have to change or appear to be problems:
1. constructing the configId from groupId + artifactId + version +
type. This is pretty easy.
2. finding stuff in a repo and/or config store from the configId. This
is fairly easy
3. Constructing the ObjectNames that include the configId in
J2EEApplication and/or J2EEModule. This requires quoting the configId
which is a big pain and is apt to cause difficulties everywhere.
4. We have been using URI for the configIds internally. I think if we
use this new format this should change. The : character appears to
have a specific meaning in URIs and it is decidedly different from what
we are meaning by it. We could perhaps introduce a scheme and write
configid:groupId:artifactId:version:type. I could not tell from a bit
of research on URIs whether this is consistent with their intended
semantics. Does it make sense to have URIs of this form? Should we
just change our configId type to something else?
At this point I think we need more discussion before we proceed along
this route. I have some of it implemented.... please speak up.
thanks
david jencks
Re: Warning of change in configId format
Posted by David Jencks <da...@yahoo.com>.
On Nov 22, 2005, at 2:51 PM, Dain Sundstrom wrote:
> On Nov 22, 2005, at 1:35 PM, David Jencks wrote:
>
>> To me the biggest problem here is still backwards compatibility and
>> if/how we can support it. Dain suggested (privately) that we might
>> have a conversion table for our configids so that an old plan would
>> still deploy. This is possible but really ugly. I will look into
>> just how ugly :-) I'd certainly appreciate any other opinions on how
>> serious a problem this is and what we can do about it.
>>
>> Now to more specific responses:
>> On Nov 18, 2005, at 6:59 AM, Aaron Mulder wrote:
>>
>>> I assume it will be the case that the configId declaration in the
>>> file
>>> will therefore control which repository location the CAR is installed
>>> in -- so if you change the configId, it changes the install location.
>>> Is that correct?
>>
>> well, maybe. The packaging plugin is the only way currently to get a
>> car file into a maven-like repository, and it only uses the actual
>> maven repository at the moment. The identity of path inside the
>> maven repo and configId is currently a convention, but IMO a really
>> good one. I'd like to see if a packed-car repository config-store
>> works, but I doubt I'll have time to try it before 1.0.
>
> I think using the maven repo path for the configId is problematic.
> The layout of the repository will change over time, and is actually
> completely repository dependent. We have already seen a change
> between maven 1 and maven 2. I would prefer that the ID follow the
> maven single line notation for an artifact.
>
> groupId:artifactId:version:type[:classifier]
>
> In this case, we don't need a classifier and we can always assume type
> is "car", so we will end up with something like:
>
> org.apache.geronimo:j2ee-server:1.0
>
> which I think is a lot cleaner then the m1 and m2 paths, as doesn't
> repeat information:
>
> org.apache.geronimo./cars/geronimo-j2ee-server-1.0.car
> org/apache/geronimo/geronimo-j2ee-server/1.0/geronimo-j2ee-server
> -1.0.car
>
> Does that seem reasonable?
I like that a lot. I have been wondering how to extract the pieces of
the repo path back out of the configId.
>
>>> Here are my issues:
>>> - It's a pretty significant change for the "last gasp before 1.0".
>>> I
>>> would *really* prefer to hold off on this so we have some time to
>>> think it through and work with it a bit longer before committing to
>>> it
>>> as the future, but I'm afraid that you won't deliver separate
>>> Jetty/Tomcat builds without it. What do you think?
>>
>> Right, for me this is a requirement for separate jetty/tomcat builds.
>
> I think this is one of the things we address now, or defer until
> Geronimo 2.0, whenever that is.
>
>>> - I want to make sure that application configIds or configIds for
>>> services created by the user (e.g. database pools, security realms)
>>> can still be anything at all ("foo") and don't have to follow the
>>> Maven style naming. Further, I don't think that not using
>>> Maven-style
>>> configIds for your application should limit your capabilities in any
>>> way (no, "can't deploy to a cluster if you can't use the packaging
>>> plugin if you didn't use Maven-style configIds" or anything like
>>> that)
>>
>> AFAIK we don't have clustering yet... there's nothing stopping you
>> from using whatever badly thought out :-) configIds you want, but I
>> think we should encourage people to use configIds with systematic and
>> useful info in them -- i.e. the maven style ones.
>
> Well if we want to use maven artifact to manage our repository, we are
> going to need a groupId, artifactId and a version. We could simply
> make groupId and vendorId equal what ever random string the user give
> us and make the version a time stamp. I think it would be better if
> the deployment tool prompted for the groupId and artifactId if there
> wasn't a geronimo plan in the archive, but it isn't necessary.
I like this too, especially if someone else implements it:-)
thanks
david jencks
>
> -dain
>
Re: Warning of change in configId format
Posted by Dain Sundstrom <da...@iq80.com>.
Aaron,
I think you have summed it up best when you used this example:
> My understanding of "packaged configurations" is "you take whatever's
> in config-store/22 and zip it" -- now you have a "packaged
> configuration" or "CAR" and the repository was never involved. If you
> want to move that to a different server, you pass the ZIP/CAR to the
> other server, it picks the next available config-store ID (say, 44)
> and unzips the thing into config-store/44. Again, no repository
> involved.
So think about this. If we were to stick that zip file into a global
maven repository, anyone would be able to download and install that
configuration into their server. All we need is for the
configuration to have a groupId, artifactId and version. This is
exactly what David has been working on, and what I ran into while
working on the idea of a plugin based server (using OSGi + Maven +
XBean). This is why David and I have been talking about the concept
of configurationIds == maven repository id.
There is another subtle question buried in your text. If the
configuration is kept in the repository, it should be static, so
where does the server specific configuration information go?
Currently, almost all of this information goes into the var/config/
config.xml (IMNOHO this file should be named server.xml) with the
very notable exception of gbeans added to a configuration by the
console. In the case of new GBeans, these get saved back to the
configuration in config-store/${config-num}/META-INF/config.sav
file. I plan on changing the save code to put the new gbeans into
the config.xml file for 1.0, so the the configuration directory is
static.
-dain
On Nov 22, 2005, at 5:16 PM, Aaron Mulder wrote:
> I don't understand why people are using "repository" and
> "config-store" interchangeably.
>
> My understanding of "repository" is that it's "where third-party
> libraries are stored". A URI into the repository works like maven by
> convention because that's how we've chosen to lay out our repository.
> But for our file system repository implementation, we could also just
> put stuff in "any old place" under the repository root, and then the
> URI's would have to look like not-Maven-style in order to work.
>
> My understanding of "config-store" is where all the code and config
> info for a particular deployed server configuration is stored. We
> specifically avoid any knowledge of how things are laid out within the
> config store by using abstract names to identify the entries there
> (though in practice, our current implementation stores entries in
> sequentially numbered directories).
>
> My understanding of "packaged configurations" is "you take whatever's
> in config-store/22 and zip it" -- now you have a "packaged
> configuration" or "CAR" and the repository was never involved. If you
> want to move that to a different server, you pass the ZIP/CAR to the
> other server, it picks the next available config-store ID (say, 44)
> and unzips the thing into config-store/44. Again, no repository
> involved.
>
> So my view of a configId is it's the abstract/human-readable name used
> to interact with the thing that the config-store knows of as
> "config-store/22" on server 1 and "config-store/44" on server 2. If
> we put a name or version or whatever in the configId that's OK, but it
> doesn't correspond to anything on the file system, it's just part of
> the chunk of text that identifies that entry in the config-store. In
> particular, tying the human names of entries in the config-store to
> the layout of files in the repository seems unnatural to me.
>
> Help!
>
> Thanks,
> Aaron
>
> On 11/22/05, Dain Sundstrom <da...@iq80.com> wrote:
>> On Nov 22, 2005, at 1:35 PM, David Jencks wrote:
>>
>>> To me the biggest problem here is still backwards compatibility and
>>> if/how we can support it. Dain suggested (privately) that we might
>>> have a conversion table for our configids so that an old plan would
>>> still deploy. This is possible but really ugly. I will look into
>>> just how ugly :-) I'd certainly appreciate any other opinions on
>>> how serious a problem this is and what we can do about it.
>>>
>>> Now to more specific responses:
>>> On Nov 18, 2005, at 6:59 AM, Aaron Mulder wrote:
>>>
>>>> I assume it will be the case that the configId declaration in the
>>>> file
>>>> will therefore control which repository location the CAR is
>>>> installed
>>>> in -- so if you change the configId, it changes the install
>>>> location.
>>>> Is that correct?
>>>
>>> well, maybe. The packaging plugin is the only way currently to get
>>> a car file into a maven-like repository, and it only uses the
>>> actual maven repository at the moment. The identity of path inside
>>> the maven repo and configId is currently a convention, but IMO a
>>> really good one. I'd like to see if a packed-car repository config-
>>> store works, but I doubt I'll have time to try it before 1.0.
>>
>> I think using the maven repo path for the configId is problematic.
>> The layout of the repository will change over time, and is actually
>> completely repository dependent. We have already seen a change
>> between maven 1 and maven 2. I would prefer that the ID follow the
>> maven single line notation for an artifact.
>>
>> groupId:artifactId:version:type[:classifier]
>>
>> In this case, we don't need a classifier and we can always assume
>> type is "car", so we will end up with something like:
>>
>> org.apache.geronimo:j2ee-server:1.0
>>
>> which I think is a lot cleaner then the m1 and m2 paths, as doesn't
>> repeat information:
>>
>> org.apache.geronimo./cars/geronimo-j2ee-server-1.0.car
>> org/apache/geronimo/geronimo-j2ee-server/1.0/geronimo-j2ee-
>> server-1.0.car
>>
>> Does that seem reasonable?
>>
>>>> Here are my issues:
>>>> - It's a pretty significant change for the "last gasp before
>>>> 1.0". I
>>>> would *really* prefer to hold off on this so we have some time to
>>>> think it through and work with it a bit longer before committing
>>>> to it
>>>> as the future, but I'm afraid that you won't deliver separate
>>>> Jetty/Tomcat builds without it. What do you think?
>>>
>>> Right, for me this is a requirement for separate jetty/tomcat
>>> builds.
>>
>> I think this is one of the things we address now, or defer until
>> Geronimo 2.0, whenever that is.
>>
>>>> - I want to make sure that application configIds or configIds for
>>>> services created by the user (e.g. database pools, security realms)
>>>> can still be anything at all ("foo") and don't have to follow the
>>>> Maven style naming. Further, I don't think that not using Maven-
>>>> style
>>>> configIds for your application should limit your capabilities in
>>>> any
>>>> way (no, "can't deploy to a cluster if you can't use the packaging
>>>> plugin if you didn't use Maven-style configIds" or anything like
>>>> that)
>>>
>>> AFAIK we don't have clustering yet... there's nothing stopping you
>>> from using whatever badly thought out :-) configIds you want, but I
>>> think we should encourage people to use configIds with systematic
>>> and useful info in them -- i.e. the maven style ones.
>>
>> Well if we want to use maven artifact to manage our repository, we
>> are going to need a groupId, artifactId and a version. We could
>> simply make groupId and vendorId equal what ever random string the
>> user give us and make the version a time stamp. I think it would be
>> better if the deployment tool prompted for the groupId and artifactId
>> if there wasn't a geronimo plan in the archive, but it isn't
>> necessary.
>>
>> -dain
>>
Re: Warning of change in configId format
Posted by David Jencks <da...@yahoo.com>.
On Nov 22, 2005, at 3:16 PM, Aaron Mulder wrote:
> I don't understand why people are using "repository" and
> "config-store" interchangeably.
Right now the config-store used in geronimo happens to not relate the
configId and the file location. I'm interested to see what happens if
I implement a config-store that stores the configs in a (geronimo)
repository. However, the geronimo classes certainly have different
methods and functions.
>
> My understanding of "repository" is that it's "where third-party
> libraries are stored". A URI into the repository works like maven by
> convention because that's how we've chosen to lay out our repository.
> But for our file system repository implementation, we could also just
> put stuff in "any old place" under the repository root, and then the
> URI's would have to look like not-Maven-style in order to work.
So, the URIs for our standard repository follow the maven convention,
although other choices are possible. We could equally well insist that
the configIds follow a maven convention, although other choices are
possible. Also, to perhaps nitpick, "third-party" is perhaps not quite
accurate, all of geronimo is there too :-).
>
> My understanding of "config-store" is where all the code and config
> info for a particular deployed server configuration is stored. We
> specifically avoid any knowledge of how things are laid out within the
> config store by using abstract names to identify the entries there
> (though in practice, our current implementation stores entries in
> sequentially numbered directories).
Yes, and we could, if we chose to, by convention, use maven style
configIds, put the configs in a maven repo structure. This is
certainly not the only choice, but I believe it offers many advantages.
One is that it provides some advice on how to construct a configId.
>
> My understanding of "packaged configurations" is "you take whatever's
> in config-store/22 and zip it" -- now you have a "packaged
> configuration" or "CAR" and the repository was never involved. If you
> want to move that to a different server, you pass the ZIP/CAR to the
> other server, it picks the next available config-store ID (say, 44)
> and unzips the thing into config-store/44. Again, no repository
> involved.
To me you are confusing one way of constructing a packaged
configuration with the concept itself. I think it's a jar file with a
serialized gbean data for a Configuration gbean in a particular
location inside. You are also dragging in many implementation
artifacts of our current LocalConfigStore which are irrelevant to its
purpose or interface-defined functioning. I think there are errors in
the current interface that obscure its functioning and tie it
unnecessarily to a file system implementation. Certainly the
directory-numbering is pretty irrelevant to its functioning.
>
> So my view of a configId is it's the abstract/human-readable name used
> to interact with the thing that the config-store knows of as
> "config-store/22" on server 1 and "config-store/44" on server 2. If
> we put a name or version or whatever in the configId that's OK, but it
> doesn't correspond to anything on the file system, it's just part of
> the chunk of text that identifies that entry in the config-store. In
> particular, tying the human names of entries in the config-store to
> the layout of files in the repository seems unnatural to me.
I think it is all what conventions we want to support and encourage. I
think maven style config ids have numerous advantages, most of which
are the same advantages of using them for your projects jar files
rather than the random names and missing versions so prevalent outside
maven-influenced projects. In particular, more or less forcing people
to include a version number in the configId can only be a good thing.
So, we could implement un-maven-like repositories and config-stores,
but why would we encourage such rampant disorganization?
I'm not sure I'm getting your point.... have you tried building
geronimo with the packaging and assembly plugins and looking at how it
works? I've been somewhat influenced by that, and I might not be
seeing the same things you are.
thanks
david jencks
>
> Help!
>
> Thanks,
> Aaron
>
> On 11/22/05, Dain Sundstrom <da...@iq80.com> wrote:
>> On Nov 22, 2005, at 1:35 PM, David Jencks wrote:
>>
>>> To me the biggest problem here is still backwards compatibility and
>>> if/how we can support it. Dain suggested (privately) that we might
>>> have a conversion table for our configids so that an old plan would
>>> still deploy. This is possible but really ugly. I will look into
>>> just how ugly :-) I'd certainly appreciate any other opinions on
>>> how serious a problem this is and what we can do about it.
>>>
>>> Now to more specific responses:
>>> On Nov 18, 2005, at 6:59 AM, Aaron Mulder wrote:
>>>
>>>> I assume it will be the case that the configId declaration in the
>>>> file
>>>> will therefore control which repository location the CAR is
>>>> installed
>>>> in -- so if you change the configId, it changes the install
>>>> location.
>>>> Is that correct?
>>>
>>> well, maybe. The packaging plugin is the only way currently to get
>>> a car file into a maven-like repository, and it only uses the
>>> actual maven repository at the moment. The identity of path inside
>>> the maven repo and configId is currently a convention, but IMO a
>>> really good one. I'd like to see if a packed-car repository config-
>>> store works, but I doubt I'll have time to try it before 1.0.
>>
>> I think using the maven repo path for the configId is problematic.
>> The layout of the repository will change over time, and is actually
>> completely repository dependent. We have already seen a change
>> between maven 1 and maven 2. I would prefer that the ID follow the
>> maven single line notation for an artifact.
>>
>> groupId:artifactId:version:type[:classifier]
>>
>> In this case, we don't need a classifier and we can always assume
>> type is "car", so we will end up with something like:
>>
>> org.apache.geronimo:j2ee-server:1.0
>>
>> which I think is a lot cleaner then the m1 and m2 paths, as doesn't
>> repeat information:
>>
>> org.apache.geronimo./cars/geronimo-j2ee-server-1.0.car
>> org/apache/geronimo/geronimo-j2ee-server/1.0/geronimo-j2ee-
>> server-1.0.car
>>
>> Does that seem reasonable?
>>
>>>> Here are my issues:
>>>> - It's a pretty significant change for the "last gasp before
>>>> 1.0". I
>>>> would *really* prefer to hold off on this so we have some time to
>>>> think it through and work with it a bit longer before committing
>>>> to it
>>>> as the future, but I'm afraid that you won't deliver separate
>>>> Jetty/Tomcat builds without it. What do you think?
>>>
>>> Right, for me this is a requirement for separate jetty/tomcat builds.
>>
>> I think this is one of the things we address now, or defer until
>> Geronimo 2.0, whenever that is.
>>
>>>> - I want to make sure that application configIds or configIds for
>>>> services created by the user (e.g. database pools, security realms)
>>>> can still be anything at all ("foo") and don't have to follow the
>>>> Maven style naming. Further, I don't think that not using Maven-
>>>> style
>>>> configIds for your application should limit your capabilities in any
>>>> way (no, "can't deploy to a cluster if you can't use the packaging
>>>> plugin if you didn't use Maven-style configIds" or anything like
>>>> that)
>>>
>>> AFAIK we don't have clustering yet... there's nothing stopping you
>>> from using whatever badly thought out :-) configIds you want, but I
>>> think we should encourage people to use configIds with systematic
>>> and useful info in them -- i.e. the maven style ones.
>>
>> Well if we want to use maven artifact to manage our repository, we
>> are going to need a groupId, artifactId and a version. We could
>> simply make groupId and vendorId equal what ever random string the
>> user give us and make the version a time stamp. I think it would be
>> better if the deployment tool prompted for the groupId and artifactId
>> if there wasn't a geronimo plan in the archive, but it isn't
>> necessary.
>>
>> -dain
>>
>
Re: Warning of change in configId format
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I don't understand why people are using "repository" and
"config-store" interchangeably.
My understanding of "repository" is that it's "where third-party
libraries are stored". A URI into the repository works like maven by
convention because that's how we've chosen to lay out our repository.
But for our file system repository implementation, we could also just
put stuff in "any old place" under the repository root, and then the
URI's would have to look like not-Maven-style in order to work.
My understanding of "config-store" is where all the code and config
info for a particular deployed server configuration is stored. We
specifically avoid any knowledge of how things are laid out within the
config store by using abstract names to identify the entries there
(though in practice, our current implementation stores entries in
sequentially numbered directories).
My understanding of "packaged configurations" is "you take whatever's
in config-store/22 and zip it" -- now you have a "packaged
configuration" or "CAR" and the repository was never involved. If you
want to move that to a different server, you pass the ZIP/CAR to the
other server, it picks the next available config-store ID (say, 44)
and unzips the thing into config-store/44. Again, no repository
involved.
So my view of a configId is it's the abstract/human-readable name used
to interact with the thing that the config-store knows of as
"config-store/22" on server 1 and "config-store/44" on server 2. If
we put a name or version or whatever in the configId that's OK, but it
doesn't correspond to anything on the file system, it's just part of
the chunk of text that identifies that entry in the config-store. In
particular, tying the human names of entries in the config-store to
the layout of files in the repository seems unnatural to me.
Help!
Thanks,
Aaron
On 11/22/05, Dain Sundstrom <da...@iq80.com> wrote:
> On Nov 22, 2005, at 1:35 PM, David Jencks wrote:
>
> > To me the biggest problem here is still backwards compatibility and
> > if/how we can support it. Dain suggested (privately) that we might
> > have a conversion table for our configids so that an old plan would
> > still deploy. This is possible but really ugly. I will look into
> > just how ugly :-) I'd certainly appreciate any other opinions on
> > how serious a problem this is and what we can do about it.
> >
> > Now to more specific responses:
> > On Nov 18, 2005, at 6:59 AM, Aaron Mulder wrote:
> >
> >> I assume it will be the case that the configId declaration in the
> >> file
> >> will therefore control which repository location the CAR is installed
> >> in -- so if you change the configId, it changes the install location.
> >> Is that correct?
> >
> > well, maybe. The packaging plugin is the only way currently to get
> > a car file into a maven-like repository, and it only uses the
> > actual maven repository at the moment. The identity of path inside
> > the maven repo and configId is currently a convention, but IMO a
> > really good one. I'd like to see if a packed-car repository config-
> > store works, but I doubt I'll have time to try it before 1.0.
>
> I think using the maven repo path for the configId is problematic.
> The layout of the repository will change over time, and is actually
> completely repository dependent. We have already seen a change
> between maven 1 and maven 2. I would prefer that the ID follow the
> maven single line notation for an artifact.
>
> groupId:artifactId:version:type[:classifier]
>
> In this case, we don't need a classifier and we can always assume
> type is "car", so we will end up with something like:
>
> org.apache.geronimo:j2ee-server:1.0
>
> which I think is a lot cleaner then the m1 and m2 paths, as doesn't
> repeat information:
>
> org.apache.geronimo./cars/geronimo-j2ee-server-1.0.car
> org/apache/geronimo/geronimo-j2ee-server/1.0/geronimo-j2ee-
> server-1.0.car
>
> Does that seem reasonable?
>
> >> Here are my issues:
> >> - It's a pretty significant change for the "last gasp before
> >> 1.0". I
> >> would *really* prefer to hold off on this so we have some time to
> >> think it through and work with it a bit longer before committing
> >> to it
> >> as the future, but I'm afraid that you won't deliver separate
> >> Jetty/Tomcat builds without it. What do you think?
> >
> > Right, for me this is a requirement for separate jetty/tomcat builds.
>
> I think this is one of the things we address now, or defer until
> Geronimo 2.0, whenever that is.
>
> >> - I want to make sure that application configIds or configIds for
> >> services created by the user (e.g. database pools, security realms)
> >> can still be anything at all ("foo") and don't have to follow the
> >> Maven style naming. Further, I don't think that not using Maven-
> >> style
> >> configIds for your application should limit your capabilities in any
> >> way (no, "can't deploy to a cluster if you can't use the packaging
> >> plugin if you didn't use Maven-style configIds" or anything like
> >> that)
> >
> > AFAIK we don't have clustering yet... there's nothing stopping you
> > from using whatever badly thought out :-) configIds you want, but I
> > think we should encourage people to use configIds with systematic
> > and useful info in them -- i.e. the maven style ones.
>
> Well if we want to use maven artifact to manage our repository, we
> are going to need a groupId, artifactId and a version. We could
> simply make groupId and vendorId equal what ever random string the
> user give us and make the version a time stamp. I think it would be
> better if the deployment tool prompted for the groupId and artifactId
> if there wasn't a geronimo plan in the archive, but it isn't necessary.
>
> -dain
>
Re: Warning of change in configId format
Posted by Dain Sundstrom <da...@iq80.com>.
On Nov 22, 2005, at 1:35 PM, David Jencks wrote:
> To me the biggest problem here is still backwards compatibility and
> if/how we can support it. Dain suggested (privately) that we might
> have a conversion table for our configids so that an old plan would
> still deploy. This is possible but really ugly. I will look into
> just how ugly :-) I'd certainly appreciate any other opinions on
> how serious a problem this is and what we can do about it.
>
> Now to more specific responses:
> On Nov 18, 2005, at 6:59 AM, Aaron Mulder wrote:
>
>> I assume it will be the case that the configId declaration in the
>> file
>> will therefore control which repository location the CAR is installed
>> in -- so if you change the configId, it changes the install location.
>> Is that correct?
>
> well, maybe. The packaging plugin is the only way currently to get
> a car file into a maven-like repository, and it only uses the
> actual maven repository at the moment. The identity of path inside
> the maven repo and configId is currently a convention, but IMO a
> really good one. I'd like to see if a packed-car repository config-
> store works, but I doubt I'll have time to try it before 1.0.
I think using the maven repo path for the configId is problematic.
The layout of the repository will change over time, and is actually
completely repository dependent. We have already seen a change
between maven 1 and maven 2. I would prefer that the ID follow the
maven single line notation for an artifact.
groupId:artifactId:version:type[:classifier]
In this case, we don't need a classifier and we can always assume
type is "car", so we will end up with something like:
org.apache.geronimo:j2ee-server:1.0
which I think is a lot cleaner then the m1 and m2 paths, as doesn't
repeat information:
org.apache.geronimo./cars/geronimo-j2ee-server-1.0.car
org/apache/geronimo/geronimo-j2ee-server/1.0/geronimo-j2ee-
server-1.0.car
Does that seem reasonable?
>> Here are my issues:
>> - It's a pretty significant change for the "last gasp before
>> 1.0". I
>> would *really* prefer to hold off on this so we have some time to
>> think it through and work with it a bit longer before committing
>> to it
>> as the future, but I'm afraid that you won't deliver separate
>> Jetty/Tomcat builds without it. What do you think?
>
> Right, for me this is a requirement for separate jetty/tomcat builds.
I think this is one of the things we address now, or defer until
Geronimo 2.0, whenever that is.
>> - I want to make sure that application configIds or configIds for
>> services created by the user (e.g. database pools, security realms)
>> can still be anything at all ("foo") and don't have to follow the
>> Maven style naming. Further, I don't think that not using Maven-
>> style
>> configIds for your application should limit your capabilities in any
>> way (no, "can't deploy to a cluster if you can't use the packaging
>> plugin if you didn't use Maven-style configIds" or anything like
>> that)
>
> AFAIK we don't have clustering yet... there's nothing stopping you
> from using whatever badly thought out :-) configIds you want, but I
> think we should encourage people to use configIds with systematic
> and useful info in them -- i.e. the maven style ones.
Well if we want to use maven artifact to manage our repository, we
are going to need a groupId, artifactId and a version. We could
simply make groupId and vendorId equal what ever random string the
user give us and make the version a time stamp. I think it would be
better if the deployment tool prompted for the groupId and artifactId
if there wasn't a geronimo plan in the archive, but it isn't necessary.
-dain
Re: Warning of change in configId format
Posted by David Jencks <da...@yahoo.com>.
To me the biggest problem here is still backwards compatibility and
if/how we can support it. Dain suggested (privately) that we might
have a conversion table for our configids so that an old plan would
still deploy. This is possible but really ugly. I will look into just
how ugly :-) I'd certainly appreciate any other opinions on how
serious a problem this is and what we can do about it.
Now to more specific responses:
On Nov 18, 2005, at 6:59 AM, Aaron Mulder wrote:
> I assume it will be the case that the configId declaration in the file
> will therefore control which repository location the CAR is installed
> in -- so if you change the configId, it changes the install location.
> Is that correct?
well, maybe. The packaging plugin is the only way currently to get a
car file into a maven-like repository, and it only uses the actual
maven repository at the moment. The identity of path inside the maven
repo and configId is currently a convention, but IMO a really good one.
I'd like to see if a packed-car repository config-store works, but I
doubt I'll have time to try it before 1.0.
>
> Here are my issues:
> - It's a pretty significant change for the "last gasp before 1.0". I
> would *really* prefer to hold off on this so we have some time to
> think it through and work with it a bit longer before committing to it
> as the future, but I'm afraid that you won't deliver separate
> Jetty/Tomcat builds without it. What do you think?
Right, for me this is a requirement for separate jetty/tomcat builds.
>
> - I want to make sure that application configIds or configIds for
> services created by the user (e.g. database pools, security realms)
> can still be anything at all ("foo") and don't have to follow the
> Maven style naming. Further, I don't think that not using Maven-style
> configIds for your application should limit your capabilities in any
> way (no, "can't deploy to a cluster if you can't use the packaging
> plugin if you didn't use Maven-style configIds" or anything like that)
AFAIK we don't have clustering yet... there's nothing stopping you
from using whatever badly thought out :-) configIds you want, but I
think we should encourage people to use configIds with systematic and
useful info in them -- i.e. the maven style ones.
>
> - Along those line, are you proposing that this is the only way to
> handle CAR import or export? That isn't my sense. I thought the
> original plan was to import/export content from the Config Store
> directly. I'm not really sure when the repository got involved, but
> I'd like to hear the case for it. I mean, if I deploy application
> foo, and it goes into directory 14 in the config store, can't we just
> have a tool that zips and exports directory 14 as "foo.car" and then
> another tool that imports "foo.car" as directory N+1 in the config
> store of the destination? I'm not saying that's right or you're
> wrong, it's just this kind of thing that makes me think I'd really
> prefer to work through this in detail at ApacheCon rather than putting
> in the change at the last second before 1.0.
The entire configId system works pretty much by convention: they are
just URI's internally. Our current config-store is sort of unusable
from the perspective of looking at it as a directory. IMO it would be
much better if we used the configId as the path in the config store.
However, I'm not proposing to experiment with this for 1.0. You can
write lots of tools to manipulate cars, but I don't really see the
point in having the name unrelated to the configId and leaving out
version information.
The maven repository got involved with the packaging plugin. As I
understand the original idea for configurations was that they would be
independently distributable packages, such as are produced by the
packaging plugin; since it's a maven plugin, it puts its output in the
maven repo. IMO the entire current modules/assembly way of building
geronimo is an unfortunate hack that has distorted our view of geronimo
capabilities and that got implemented only because we made a slight
mistake early on in development priorities. There's nothing stopping
anyone from writing more tools, but the only working ones I am aware of
is the packaging and assembly plugins.
>
> - On a parctical note, I'm afraid the config IDs will become too long
> for the deployer to fit on a single line, and it would make the
> list-modules view pretty terrible (any chance we can establish a
> policy of omitting the groupId if it happens to be org.apache.geronimo
> and leaving out the "type" since IIUC it will always be "car"?)
For the actual configId, I am really strongly in favor of consistency,
and consistency by convention with maven. For display, there are lots
of choices, and I have no preference. For instance, we could group
configIds by groupId.
>
> If you go ahead, do you have a sense for how long it would take to
> implement and test the change?
The jetty and tomcat servers now build and start and run the respective
copies of the console. Please try them out. I've done little except
try the console and welcome apps. For instance, I don't know if the
command line deployer works. I'd like to try the tck on them soon, but
there are backwards compatibility obstacles with the plans at the
moment.
After a few more people troubleshoot the manual build process I'd like
to add it to the standard build.
thanks
david jencks
>
> Thanks,
> Aaron
>
> On 11/18/05, David Jencks <da...@yahoo.com> wrote:
>> I have been working on assembling geronimo using the packaging and
>> assembly plugins. This gives us the ability to put together versions
>> of geronimo with different capabilities without duplication. For
>> instance, we now have a jetty-only and a tomcat-only version of
>> geronimo. To build these,
>>
>> cd configs;maven -o multiproject:install; cd ..
>> cd assemblies/j2ee-jetty-server;maven -o;
>> cd ../j2ee-tomcat-server:maven -o
>>
>> This relies on using the packaging plugin, which builds configurations
>> and puts them into the local maven repository. As such, it uses the
>> maven id as the configId: they typically look like
>>
>> ${groupId}/cars/${artifactId}-${pom.currentVersion}.car
>>
>> I think this is a big improvement over the unsystematic hand-invented
>> ids we have been relying on up to now, but it is a backwards
>> incompatible change that will require changing any plan that mentions
>> a
>> parentId (many plans do not need to: the builders include default
>> parents sufficient for the geronimo classes needed for the app to
>> load). It will also require changing the <module> element in gbean
>> references that include them.
>>
>> I think we should just go ahead with the change, and announce it
>> loudly. We could provide "adapter plans" with no content of any kind
>> that have e.g. a configId of org/apache/geronimo/rmi-naming and a
>> parentId of geronimo/cars/geronimo-rmi-naming-1.0-SNAPSHOT.car. This
>> would allow plans that have only old-style parentIds to deploy
>> successfully, but would not help with the gbean references.
>>
>> I beileve in a slightly related development we are planning to change
>> the groupId to org.apache.geronimo before v1. Doing these changes
>> more
>> or less at once might reduce confusion.
>>
>>
>> Comments? Objections?
>>
>> thanks
>> david jencks
>>
>>
>
Re: Warning of change in configId format
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I assume it will be the case that the configId declaration in the file
will therefore control which repository location the CAR is installed
in -- so if you change the configId, it changes the install location.
Is that correct?
Here are my issues:
- It's a pretty significant change for the "last gasp before 1.0". I
would *really* prefer to hold off on this so we have some time to
think it through and work with it a bit longer before committing to it
as the future, but I'm afraid that you won't deliver separate
Jetty/Tomcat builds without it. What do you think?
- I want to make sure that application configIds or configIds for
services created by the user (e.g. database pools, security realms)
can still be anything at all ("foo") and don't have to follow the
Maven style naming. Further, I don't think that not using Maven-style
configIds for your application should limit your capabilities in any
way (no, "can't deploy to a cluster if you can't use the packaging
plugin if you didn't use Maven-style configIds" or anything like that)
- Along those line, are you proposing that this is the only way to
handle CAR import or export? That isn't my sense. I thought the
original plan was to import/export content from the Config Store
directly. I'm not really sure when the repository got involved, but
I'd like to hear the case for it. I mean, if I deploy application
foo, and it goes into directory 14 in the config store, can't we just
have a tool that zips and exports directory 14 as "foo.car" and then
another tool that imports "foo.car" as directory N+1 in the config
store of the destination? I'm not saying that's right or you're
wrong, it's just this kind of thing that makes me think I'd really
prefer to work through this in detail at ApacheCon rather than putting
in the change at the last second before 1.0.
- On a parctical note, I'm afraid the config IDs will become too long
for the deployer to fit on a single line, and it would make the
list-modules view pretty terrible (any chance we can establish a
policy of omitting the groupId if it happens to be org.apache.geronimo
and leaving out the "type" since IIUC it will always be "car"?)
If you go ahead, do you have a sense for how long it would take to
implement and test the change?
Thanks,
Aaron
On 11/18/05, David Jencks <da...@yahoo.com> wrote:
> I have been working on assembling geronimo using the packaging and
> assembly plugins. This gives us the ability to put together versions
> of geronimo with different capabilities without duplication. For
> instance, we now have a jetty-only and a tomcat-only version of
> geronimo. To build these,
>
> cd configs;maven -o multiproject:install; cd ..
> cd assemblies/j2ee-jetty-server;maven -o;
> cd ../j2ee-tomcat-server:maven -o
>
> This relies on using the packaging plugin, which builds configurations
> and puts them into the local maven repository. As such, it uses the
> maven id as the configId: they typically look like
>
> ${groupId}/cars/${artifactId}-${pom.currentVersion}.car
>
> I think this is a big improvement over the unsystematic hand-invented
> ids we have been relying on up to now, but it is a backwards
> incompatible change that will require changing any plan that mentions a
> parentId (many plans do not need to: the builders include default
> parents sufficient for the geronimo classes needed for the app to
> load). It will also require changing the <module> element in gbean
> references that include them.
>
> I think we should just go ahead with the change, and announce it
> loudly. We could provide "adapter plans" with no content of any kind
> that have e.g. a configId of org/apache/geronimo/rmi-naming and a
> parentId of geronimo/cars/geronimo-rmi-naming-1.0-SNAPSHOT.car. This
> would allow plans that have only old-style parentIds to deploy
> successfully, but would not help with the gbean references.
>
> I beileve in a slightly related development we are planning to change
> the groupId to org.apache.geronimo before v1. Doing these changes more
> or less at once might reduce confusion.
>
>
> Comments? Objections?
>
> thanks
> david jencks
>
>
Re: Warning of change in configId format
Posted by David Jencks <da...@yahoo.com>.
On Nov 18, 2005, at 9:32 AM, Dain Sundstrom wrote:
>
> On Nov 17, 2005, at 11:30 PM, David Jencks wrote:
>
>> This relies on using the packaging plugin, which builds
>> configurations and puts them into the local maven repository. As
>> such, it uses the maven id as the configId: they typically look like
>>
>> ${groupId}/cars/${artifactId}-${pom.currentVersion}.car
>
> I'd prefer not to encode the maven 1 repository layout into Geronimo.
> I think we should either go with a m2 parent element at the top of our
> configuration:
>
> <parent>
> <groupId>org.apache.geronimo</groupId>
> <artifactId>geronimo</artifactId>
> <version>1.0-SNAPSHOT</version>
> <type>car<type>
> </parent>
>
We are currently using "import" rather than "parent". Do you want the
name to change?
from my original message:
I beileve in a slightly related development we are planning to change
the groupId to org.apache.geronimo before v1. Doing these changes more
or less at once might reduce confusion.
Despite the misspelling, is this what you are suggesting?
As I recall you indicated that you would be making this groupId change.
Do you have an estimate on when, or did I misunderstand?
david jencks
Re: Warning of change in configId format
Posted by Dain Sundstrom <da...@iq80.com>.
On Nov 17, 2005, at 11:30 PM, David Jencks wrote:
> This relies on using the packaging plugin, which builds
> configurations and puts them into the local maven repository. As
> such, it uses the maven id as the configId: they typically look like
>
> ${groupId}/cars/${artifactId}-${pom.currentVersion}.car
I'd prefer not to encode the maven 1 repository layout into
Geronimo. I think we should either go with a m2 parent element at
the top of our configuration:
<parent>
<groupId>org.apache.geronimo</groupId>
<artifactId>geronimo</artifactId>
<version>1.0-SNAPSHOT</version>
<type>car<type>
</parent>
-dain