Also, we need to think about the meaning of "version". You might deploy a lot of times between designated versions of an application. I'd prefer that we not require that the version be SNAPSHOT if you're going to do that (because then they really are indistinguishable). It would be nice if you could be working on App-1.2.1 and deploy 10 times and Geronimo internally kept track of 1.2.1 deploy #1 vs 1.2.1 deploy #2, etc. I'm not sure how to accomodate that in the vendor/app/type/version scheme that Maven uses for released builds.
Aaron On 11/23/05, Aaron Mulder <[EMAIL PROTECTED]> wrote: > 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 >
