geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: Possible problems with maven-style configIds WAS: Warning of change in configId format
Date Thu, 24 Nov 2005 02:07:07 GMT
On 11/23/05, David Jencks <> 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

> 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

> ...
> 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.


View raw message