On 11/23/05, David Jencks <[EMAIL PROTECTED]> 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
