Re: Possible problems with maven-style configIds WAS: Warning of change in configId format
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 > > > > yourGroup/yourArtifact/yourVersion/jar > > > > rather than > > > > yourGroup/jars/yourArtifact-yourVersion.jar > > > > 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. > > , , -- 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 >
Re: Possible problems with maven-style configIds WAS: Warning of change in configId format
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 > > yourGroup/yourArtifact/yourVersion/jar > > rather than > > yourGroup/jars/yourArtifact-yourVersion.jar > > 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. , , -- 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
Re: Possible problems with maven-style configIds WAS: Warning of change in configId format
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 yourGroup/yourArtifact/yourVersion/jar rather than yourGroup/jars/yourArtifact-yourVersion.jar 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 org.apache.geronimo kernel 1.0 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
Re: Possible problems with maven-style configIds WAS: Warning of change in configId format
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. 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), 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. 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. Aaron > > org.apache.geronimo > kernel > 1.0 > > > > 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 > >
Re: Possible problems with maven-style configIds WAS: Warning of change in configId format
On Nov 23, 2005, at 4:14 PM, David Jencks wrote: On Nov 23, 2005, at 2:02 PM, Dain Sundstrom wrote: On Nov 23, 2005, at 3:27 PM, David Jencks wrote: Should we change our dependency URIs to the same format? I'm inclined to think we should. I would prefer to include the type (car|jar) for completeness and to distinguish dependencies from configIds. 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: org.apache.geronimo kernel 1.0 Look in the configs/assemblies builds. All dependency elements are generated by the plugins, and are in this format. Very nice. Do we can deprecate the one liner format now, or wait for another release? 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. I'm mostly wondering about jsr-77 object names. But, we already have both meaningless configId uris and, in ear module names, path uris for relative position in the ear. So I'm not sure this would introduce any more confusion. I think the name will be a bit tighter, but will still be pretty unreadable for users anyway. At least we aren't making it worse :) 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. Well, I'd recommend if we decide to change to this uri format that the Repository implementations accept them rather than the current path based uris they are accepting. +1 ConfigIds in plans should all change. Plans we supply are all (in configs build) using (generated) dependencies and imports of the long format already. IMO you should be specifiying all the parents using import tags anyway in the long format (this is done in configs build as well (as soon as I commit the next cleanup :-)). +1 I'm starting to think this is doable by 1.0. It would be nice to hear other opinions... +1 -dain
Re: Possible problems with maven-style configIds WAS: Warning of change in configId format
On Nov 23, 2005, at 2:02 PM, Dain Sundstrom wrote: On Nov 23, 2005, at 3:27 PM, David Jencks wrote: On Nov 23, 2005, at 1:12 PM, Dain Sundstrom wrote: On Nov 23, 2005, at 1:58 PM, David Jencks wrote: I've investigated this a little bit and think it might be too big a lurch in a new direction for 1.0. Here are a few of the things that would have to change or appear to be problems: 1. constructing the configId from groupId + artifactId + version + type. This is pretty easy. 2. finding stuff in a repo and/or config store from the configId. This is fairly easy 3. Constructing the ObjectNames that include the configId in J2EEApplication and/or J2EEModule. This requires quoting the configId which is a big pain and is apt to cause difficulties everywhere. 4. We have been using URI for the configIds internally. I think if we use this new format this should change. The : character appears to have a specific meaning in URIs and it is decidedly different from what we are meaning by it. We could perhaps introduce a scheme and write configid:groupId:artifactId:version:type. I could not tell from a bit of research on URIs whether this is consistent with their intended semantics. Does it make sense to have URIs of this form? Should we just change our configId type to something else? At this point I think we need more discussion before we proceed along this route. I have some of it implemented please speak up. My opinion, is we don't make incompatible changes between major releases, so if we decide not to do this now, it will be harder to do it later. Anyway, I see your point, so lets talk about what changes you want to implement pre-1.0? If you are changing the configuration ids, I'd like to make sure the format is something we can easily parse into groupId, artifactId and version. For example, we could go with: org.apache.geronimo/j2ee-server/1.0 Should we change our dependency URIs to the same format? I'm inclined to think we should. I would prefer to include the type (car|jar) for completeness and to distinguish dependencies from configIds. 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: org.apache.geronimo kernel 1.0 Look in the configs/assemblies builds. All dependency elements are generated by the plugins, and are in this format. 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. I'm mostly wondering about jsr-77 object names. But, we already have both meaningless configId uris and, in ear module names, path uris for relative position in the ear. So I'm not sure this would introduce any more confusion. 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. Well, I'd recommend if we decide to change to this uri format that the Repository implementations accept them rather than the current path based uris they are accepting. ConfigIds in plans should all change. Plans we supply are all (in configs build) using (generated) dependencies and imports of the long format already. IMO you should be specifiying all the parents using import tags anyway in the long format (this is done in configs build as well (as soon as I commit the next cleanup :-)). I'm starting to think this is doable by 1.0. It would be nice to hear other opinions... thanks david jencks -dain
Re: Possible problems with maven-style configIds WAS: Warning of change in configId format
On Nov 23, 2005, at 3:27 PM, David Jencks wrote: On Nov 23, 2005, at 1:12 PM, Dain Sundstrom wrote: On Nov 23, 2005, at 1:58 PM, David Jencks wrote: I've investigated this a little bit and think it might be too big a lurch in a new direction for 1.0. Here are a few of the things that would have to change or appear to be problems: 1. constructing the configId from groupId + artifactId + version + type. This is pretty easy. 2. finding stuff in a repo and/or config store from the configId. This is fairly easy 3. Constructing the ObjectNames that include the configId in J2EEApplication and/or J2EEModule. This requires quoting the configId which is a big pain and is apt to cause difficulties everywhere. 4. We have been using URI for the configIds internally. I think if we use this new format this should change. The : character appears to have a specific meaning in URIs and it is decidedly different from what we are meaning by it. We could perhaps introduce a scheme and write configid:groupId:artifactId:version:type. I could not tell from a bit of research on URIs whether this is consistent with their intended semantics. Does it make sense to have URIs of this form? Should we just change our configId type to something else? At this point I think we need more discussion before we proceed along this route. I have some of it implemented please speak up. My opinion, is we don't make incompatible changes between major releases, so if we decide not to do this now, it will be harder to do it later. Anyway, I see your point, so lets talk about what changes you want to implement pre-1.0? If you are changing the configuration ids, I'd like to make sure the format is something we can easily parse into groupId, artifactId and version. For example, we could go with: org.apache.geronimo/j2ee-server/1.0 Should we change our dependency URIs to the same format? I'm inclined to think we should. I would prefer to include the type (car|jar) for completeness and to distinguish dependencies from configIds. 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: org.apache.geronimo kernel 1.0 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
Re: Possible problems with maven-style configIds WAS: Warning of change in configId format
On Nov 23, 2005, at 1:12 PM, Dain Sundstrom wrote: On Nov 23, 2005, at 1:58 PM, David Jencks wrote: I've investigated this a little bit and think it might be too big a lurch in a new direction for 1.0. Here are a few of the things that would have to change or appear to be problems: 1. constructing the configId from groupId + artifactId + version + type. This is pretty easy. 2. finding stuff in a repo and/or config store from the configId. This is fairly easy 3. Constructing the ObjectNames that include the configId in J2EEApplication and/or J2EEModule. This requires quoting the configId which is a big pain and is apt to cause difficulties everywhere. 4. We have been using URI for the configIds internally. I think if we use this new format this should change. The : character appears to have a specific meaning in URIs and it is decidedly different from what we are meaning by it. We could perhaps introduce a scheme and write configid:groupId:artifactId:version:type. I could not tell from a bit of research on URIs whether this is consistent with their intended semantics. Does it make sense to have URIs of this form? Should we just change our configId type to something else? At this point I think we need more discussion before we proceed along this route. I have some of it implemented please speak up. My opinion, is we don't make incompatible changes between major releases, so if we decide not to do this now, it will be harder to do it later. Anyway, I see your point, so lets talk about what changes you want to implement pre-1.0? If you are changing the configuration ids, I'd like to make sure the format is something we can easily parse into groupId, artifactId and version. For example, we could go with: org.apache.geronimo/j2ee-server/1.0 Should we change our dependency URIs to the same format? I'm inclined to think we should. I would prefer to include the type (car|jar) for completeness and to distinguish dependencies from configIds. 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. 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. thanks david jencks -dain
Re: Possible problems with maven-style configIds WAS: Warning of change in configId format
On Nov 23, 2005, at 1:58 PM, David Jencks wrote: I've investigated this a little bit and think it might be too big a lurch in a new direction for 1.0. Here are a few of the things that would have to change or appear to be problems: 1. constructing the configId from groupId + artifactId + version + type. This is pretty easy. 2. finding stuff in a repo and/or config store from the configId. This is fairly easy 3. Constructing the ObjectNames that include the configId in J2EEApplication and/or J2EEModule. This requires quoting the configId which is a big pain and is apt to cause difficulties everywhere. 4. We have been using URI for the configIds internally. I think if we use this new format this should change. The : character appears to have a specific meaning in URIs and it is decidedly different from what we are meaning by it. We could perhaps introduce a scheme and write configid:groupId:artifactId:version:type. I could not tell from a bit of research on URIs whether this is consistent with their intended semantics. Does it make sense to have URIs of this form? Should we just change our configId type to something else? At this point I think we need more discussion before we proceed along this route. I have some of it implemented please speak up. My opinion, is we don't make incompatible changes between major releases, so if we decide not to do this now, it will be harder to do it later. Anyway, I see your point, so lets talk about what changes you want to implement pre-1.0? If you are changing the configuration ids, I'd like to make sure the format is something we can easily parse into groupId, artifactId and version. For example, we could go with: org.apache.geronimo/j2ee-server/1.0 Are there any other changes of note? -dain
