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 <[EMAIL PROTECTED]> 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
