On Nov 23, 2005, at 3:46 PM, Aaron Mulder wrote:
On 11/23/05, Dain Sundstrom <[EMAIL PROTECTED]> 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
