Re: We may need to rethink unversioned dependencies among server plans...
I agree with Jencks that dates are too unpredictable. If there are patches as you described below (1.1.1-patch-aaron-5 or 1.1.1-2345-fix-by-dain) those are not welformed so the results are undefined. Aaron Mulder wrote: My problem with the "version with well-explained scheme" is that it basically means there can only be one source of updates. I mean, it's probably OK if you figure you won't be able to apply a WAS CE patch to Geronimo or vice versa. Are we sure we're not going to want to have test patches and stuff that we want people to install and try out before the official patch release? Maybe they just need to have proper version numbers and the "official patch releases" will tend to skip numbers. I guess that's worked well enoguh for the RPM distros. Dain, any thoughts on this? I think you're the one working on the dependency resolving during upgrades at the moment. Thanks, Aaron On 4/20/06, David Jencks <[EMAIL PROTECTED]> wrote: On Apr 20, 2006, at 4:25 AM, Aaron Mulder wrote: First, can you rev the version of the plugin so we can eliminate that as a possible source of the problem? will do Second, what happens when we go to upgrade j2ee-server from 1.1(.0) to 1.1.1 at runtime? During that redeploy operation, both 1.1.0 and 1.1.1 will be present in the config store, and the configuration manager has to re-resolve all the dependencies, and I don't think it's workable to have an explicit version file at runtime (when who knows which patches will be applied in which order). I plan for the runtime server to not have an explicit versions file. I think it should only be used to build a server in the maven repo. I think we need to adopt a strategy of either favoring the newest entry in the config store by date or favoring the highest version number. I think I'd prefer to give the newest entry precedence. It does mean that if you have 1.1.2 and later install 1.1.1 it will downgrade, but that seems better to me than try to decide whether 1.1.1-patch-aaron-5 or 1.1.1-2345-fix-by-dain has a higher version number. I prefer version numbers with a well-explained scheme. Date is too unpredictable IMO. thanks david jencks Thanks, Aaron On 4/20/06, David Jencks <[EMAIL PROTECTED]> wrote: On Apr 19, 2006, at 6:27 PM, Aaron Mulder wrote: So I'm having a build problem. The root cause appears to be that my local Maven repo has both 1.1-SNAPSHOT and 1.2-SNAPSHOT artifacts. One of the server artifacts (say, j2ee-system) has a dependency on another (say, rmi-naming), and that dependency has no version. So when the packaging plugin packages j2ee-system, it asks the repository for a matching rmi-naming, and gets rmi-naming/1.2- SNAPSHOT instead of rmi-naming/1.1-SNAPSHOT I'm not sure what we can do about this. I'll think about it a bit. hmm, this appears to be working ok on my machine, maybe I don't have enough 1.2 artifacts on it. The way it's supposed to work is that the artifact resolver has a map of explicit versions to use for unversioned artifacts. This is currently etc/explicit_versions.properties for the packaging and assembly plugins. You can have entries of the form groupid/ artifactid//type=version or groupid///=version; the former are checked first. Since on my machine nothing was working when this file was missing/ incorrect, and adding entries (such as for xmlparserapis) has fixed problems, I'm inclined to think it's working properly. I did forget to bump the version number on the plugins, perhaps your problems are from an out of date plugin??? thanks david jencks Thanks, Aaron
Re: We may need to rethink unversioned dependencies among server plans...
My problem with the "version with well-explained scheme" is that it basically means there can only be one source of updates. I mean, it's probably OK if you figure you won't be able to apply a WAS CE patch to Geronimo or vice versa. Are we sure we're not going to want to have test patches and stuff that we want people to install and try out before the official patch release? Maybe they just need to have proper version numbers and the "official patch releases" will tend to skip numbers. I guess that's worked well enoguh for the RPM distros. Dain, any thoughts on this? I think you're the one working on the dependency resolving during upgrades at the moment. Thanks, Aaron On 4/20/06, David Jencks <[EMAIL PROTECTED]> wrote: > > On Apr 20, 2006, at 4:25 AM, Aaron Mulder wrote: > > > First, can you rev the version of the plugin so we can eliminate that > > as a possible source of the problem? > > will do > > > > Second, what happens when we go to upgrade j2ee-server from 1.1(.0) to > > 1.1.1 at runtime? During that redeploy operation, both 1.1.0 and > > 1.1.1 will be present in the config store, and the configuration > > manager has to re-resolve all the dependencies, and I don't think it's > > workable to have an explicit version file at runtime (when who knows > > which patches will be applied in which order). > > I plan for the runtime server to not have an explicit versions file. > I think it should only be used to build a server in the maven repo. > > > > I think we need to adopt a strategy of either favoring the newest > > entry in the config store by date or favoring the highest version > > number. I think I'd prefer to give the newest entry precedence. It > > does mean that if you have 1.1.2 and later install 1.1.1 it will > > downgrade, but that seems better to me than try to decide whether > > 1.1.1-patch-aaron-5 or 1.1.1-2345-fix-by-dain has a higher version > > number. > > I prefer version numbers with a well-explained scheme. Date is too > unpredictable IMO. > > thanks > david jencks > > > > > Thanks, > > Aaron > > > > On 4/20/06, David Jencks <[EMAIL PROTECTED]> wrote: > >> > >> On Apr 19, 2006, at 6:27 PM, Aaron Mulder wrote: > >> > >>> So I'm having a build problem. > >>> > >>> The root cause appears to be that my local Maven repo has both > >>> 1.1-SNAPSHOT and 1.2-SNAPSHOT artifacts. One of the server > >>> artifacts > >>> (say, j2ee-system) has a dependency on another (say, rmi-naming), > >>> and > >>> that dependency has no version. > >>> > >>> So when the packaging plugin packages j2ee-system, it asks the > >>> repository for a matching rmi-naming, and gets rmi-naming/1.2- > >>> SNAPSHOT > >>> instead of rmi-naming/1.1-SNAPSHOT > >>> > >>> I'm not sure what we can do about this. I'll think about it a bit. > >> > >> hmm, this appears to be working ok on my machine, maybe I don't have > >> enough 1.2 artifacts on it. > >> > >> The way it's supposed to work is that the artifact resolver has a map > >> of explicit versions to use for unversioned artifacts. This is > >> currently etc/explicit_versions.properties for the packaging and > >> assembly plugins. You can have entries of the form groupid/ > >> artifactid//type=version or groupid///=version; the former are > >> checked first. > >> > >> Since on my machine nothing was working when this file was missing/ > >> incorrect, and adding entries (such as for xmlparserapis) has fixed > >> problems, I'm inclined to think it's working properly. I did forget > >> to bump the version number on the plugins, perhaps your problems are > >> from an out of date plugin??? > >> > >> thanks > >> david jencks > >> > >>> > >>> Thanks, > >>> Aaron > >> > >> > >
Re: We may need to rethink unversioned dependencies among server plans...
On Apr 20, 2006, at 4:25 AM, Aaron Mulder wrote: First, can you rev the version of the plugin so we can eliminate that as a possible source of the problem? will do Second, what happens when we go to upgrade j2ee-server from 1.1(.0) to 1.1.1 at runtime? During that redeploy operation, both 1.1.0 and 1.1.1 will be present in the config store, and the configuration manager has to re-resolve all the dependencies, and I don't think it's workable to have an explicit version file at runtime (when who knows which patches will be applied in which order). I plan for the runtime server to not have an explicit versions file. I think it should only be used to build a server in the maven repo. I think we need to adopt a strategy of either favoring the newest entry in the config store by date or favoring the highest version number. I think I'd prefer to give the newest entry precedence. It does mean that if you have 1.1.2 and later install 1.1.1 it will downgrade, but that seems better to me than try to decide whether 1.1.1-patch-aaron-5 or 1.1.1-2345-fix-by-dain has a higher version number. I prefer version numbers with a well-explained scheme. Date is too unpredictable IMO. thanks david jencks Thanks, Aaron On 4/20/06, David Jencks <[EMAIL PROTECTED]> wrote: On Apr 19, 2006, at 6:27 PM, Aaron Mulder wrote: So I'm having a build problem. The root cause appears to be that my local Maven repo has both 1.1-SNAPSHOT and 1.2-SNAPSHOT artifacts. One of the server artifacts (say, j2ee-system) has a dependency on another (say, rmi-naming), and that dependency has no version. So when the packaging plugin packages j2ee-system, it asks the repository for a matching rmi-naming, and gets rmi-naming/1.2- SNAPSHOT instead of rmi-naming/1.1-SNAPSHOT I'm not sure what we can do about this. I'll think about it a bit. hmm, this appears to be working ok on my machine, maybe I don't have enough 1.2 artifacts on it. The way it's supposed to work is that the artifact resolver has a map of explicit versions to use for unversioned artifacts. This is currently etc/explicit_versions.properties for the packaging and assembly plugins. You can have entries of the form groupid/ artifactid//type=version or groupid///=version; the former are checked first. Since on my machine nothing was working when this file was missing/ incorrect, and adding entries (such as for xmlparserapis) has fixed problems, I'm inclined to think it's working properly. I did forget to bump the version number on the plugins, perhaps your problems are from an out of date plugin??? thanks david jencks Thanks, Aaron
Re: We may need to rethink unversioned dependencies among server plans...
First, can you rev the version of the plugin so we can eliminate that as a possible source of the problem? Second, what happens when we go to upgrade j2ee-server from 1.1(.0) to 1.1.1 at runtime? During that redeploy operation, both 1.1.0 and 1.1.1 will be present in the config store, and the configuration manager has to re-resolve all the dependencies, and I don't think it's workable to have an explicit version file at runtime (when who knows which patches will be applied in which order). I think we need to adopt a strategy of either favoring the newest entry in the config store by date or favoring the highest version number. I think I'd prefer to give the newest entry precedence. It does mean that if you have 1.1.2 and later install 1.1.1 it will downgrade, but that seems better to me than try to decide whether 1.1.1-patch-aaron-5 or 1.1.1-2345-fix-by-dain has a higher version number. Thanks, Aaron On 4/20/06, David Jencks <[EMAIL PROTECTED]> wrote: > > On Apr 19, 2006, at 6:27 PM, Aaron Mulder wrote: > > > So I'm having a build problem. > > > > The root cause appears to be that my local Maven repo has both > > 1.1-SNAPSHOT and 1.2-SNAPSHOT artifacts. One of the server artifacts > > (say, j2ee-system) has a dependency on another (say, rmi-naming), and > > that dependency has no version. > > > > So when the packaging plugin packages j2ee-system, it asks the > > repository for a matching rmi-naming, and gets rmi-naming/1.2-SNAPSHOT > > instead of rmi-naming/1.1-SNAPSHOT > > > > I'm not sure what we can do about this. I'll think about it a bit. > > hmm, this appears to be working ok on my machine, maybe I don't have > enough 1.2 artifacts on it. > > The way it's supposed to work is that the artifact resolver has a map > of explicit versions to use for unversioned artifacts. This is > currently etc/explicit_versions.properties for the packaging and > assembly plugins. You can have entries of the form groupid/ > artifactid//type=version or groupid///=version; the former are > checked first. > > Since on my machine nothing was working when this file was missing/ > incorrect, and adding entries (such as for xmlparserapis) has fixed > problems, I'm inclined to think it's working properly. I did forget > to bump the version number on the plugins, perhaps your problems are > from an out of date plugin??? > > thanks > david jencks > > > > > Thanks, > > Aaron > >
Re: We may need to rethink unversioned dependencies among server plans...
On Apr 19, 2006, at 6:27 PM, Aaron Mulder wrote: So I'm having a build problem. The root cause appears to be that my local Maven repo has both 1.1-SNAPSHOT and 1.2-SNAPSHOT artifacts. One of the server artifacts (say, j2ee-system) has a dependency on another (say, rmi-naming), and that dependency has no version. So when the packaging plugin packages j2ee-system, it asks the repository for a matching rmi-naming, and gets rmi-naming/1.2-SNAPSHOT instead of rmi-naming/1.1-SNAPSHOT I'm not sure what we can do about this. I'll think about it a bit. hmm, this appears to be working ok on my machine, maybe I don't have enough 1.2 artifacts on it. The way it's supposed to work is that the artifact resolver has a map of explicit versions to use for unversioned artifacts. This is currently etc/explicit_versions.properties for the packaging and assembly plugins. You can have entries of the form groupid/ artifactid//type=version or groupid///=version; the former are checked first. Since on my machine nothing was working when this file was missing/ incorrect, and adding entries (such as for xmlparserapis) has fixed problems, I'm inclined to think it's working properly. I did forget to bump the version number on the plugins, perhaps your problems are from an out of date plugin??? thanks david jencks Thanks, Aaron
Re: We may need to rethink unversioned dependencies among server plans...
This is behaving as designed isn't it? I would expect the highest level version to be selected in the absence of a restriction (another dependency indicated that it required 1.1-SNAPSHOT) or a specific dependency (some dependency indicated it needed naming-1.1-SNAPSHOT). Does this sound right? Aaron Mulder wrote: So I'm having a build problem. The root cause appears to be that my local Maven repo has both 1.1-SNAPSHOT and 1.2-SNAPSHOT artifacts. One of the server artifacts (say, j2ee-system) has a dependency on another (say, rmi-naming), and that dependency has no version. So when the packaging plugin packages j2ee-system, it asks the repository for a matching rmi-naming, and gets rmi-naming/1.2-SNAPSHOT instead of rmi-naming/1.1-SNAPSHOT I'm not sure what we can do about this. I'll think about it a bit. Thanks, Aaron
