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
