Re: One version for specs
For the record, I just want the specs issue resolved... be it my way or not... I just want it fixed. * * * I apologize to those who think I was ignoring them... this issue was getting me way to worked up and I had to basically delete the thread to clear my head. --jason
Re: One version for specs
On Oct 3, 2006, at 11:47 AM, Jason Dillon wrote: On Oct 3, 2006, at 11:39 AM, David Blevins wrote: Ok, now it's me whose not reading emails :) You mentioned the site changes. Is that it? Are we really talking about re- releasing completely stable specs because of website changes? This was a reason why the spec module might change, not why (or why not) it should be released. Sure, but the proposal is that it would get released with just it's website changes whenever some other spec needs to be released because of code changes. I'm not so concerned about website stuff for the core specs that don't change. If that's the reason for wanting to keep updating the poms and re-releasing specs which are essentially "done", is there any other way we can meet the website goals you have? -David --jason
Re: One version for specs
On Oct 3, 2006, at 11:39 AM, David Blevins wrote: Ok, now it's me whose not reading emails :) You mentioned the site changes. Is that it? Are we really talking about re-releasing completely stable specs because of website changes? This was a reason why the spec module might change, not why (or why not) it should be released. --jason
Re: One version for specs
On Oct 3, 2006, at 11:25 AM, David Blevins wrote: On Oct 3, 2006, at 11:12 AM, Jason Dillon wrote: On Oct 3, 2006, at 11:03 AM, David Blevins wrote: Dude, you never read my emails. I read it... but the mail you just sent said they have not changed: Can you give some examples on what kind of pom changes that would happen to these that would merit another release? Ok, now it's me whose not reading emails :) You mentioned the site changes. Is that it? Are we really talking about re-releasing completely stable specs because of website changes? -David
Re: One version for specs
For the two classes of users that I mentioned earlier, the work will not be significant. I'm not certain that the post-it note spectre applies to this narrow domain. Regards, Alan On Oct 3, 2006, at 11:14 AM, Jason Dillon wrote: It does not matter how often it happens. The fact that they can be changed, and most *will* have some change made to them, increases the work to manage them significantly. --jason On Oct 3, 2006, at 11:09 AM, Alan D. Cabrera wrote: These don't change all that often, IIRC. Regards, Alan On Oct 2, 2006, at 2:56 PM, Jason Dillon wrote: About 1/3 of the specs depend on other specs (not including the uber 1.4 spec): ejb 2.1 -> jta 1.0.1b ejb3 -> jta 1.1, interceptor, annotation conector 1.5 -> jta 1.0.1b jacc -> servlet 2.4 j2ee mgmt -> ejb 2.1 javamail 1.3.1 -> activation javamail 1.4 -> activation jaxr -> activation jaxrpc -> saaj, qname, servlet 2.4 jsp -> servlet 2.4 saaj -> activation --jason On Oct 2, 2006, at 1:38 PM, Aaron Mulder wrote: I hear you, but underlying your case is the assumption that a lot of specs depend on each other. I'm not convinced that's true. Certainly, no J2EE 1.4 specs should rely on any J2EE 1.5 or non- J2EE specs. I guess underlying the compromise proposal is the assumtion that at this point J2EE 1.4 is fairly unlikely to need any changes, so a backward dependency from 1.5 to 1.4 is unlikely to need much maintainance. I'm not sure how many unaligned specs would have other spec dependencies, but I can't think of any. The only dependencies I can really think of are mail on activation, web services on mail and activation, and JSP on servlet I'm sure there are a few more, but I don't think it's anything like the inter-module dependencies of, say, Geronimo itself. Thanks, Aaron On 10/2/06, Jason Dillon <[EMAIL PROTECTED]> wrote: IMO there is no "best" way to handle this problem. There is only good and bad for each solution, but there is no smoking gun to solve everyones issues. I already sent out that itty bitty note about the release being jar + pom(s) but I wanted to clarify that even more... If you take the current specs build... all of the versions of the specs are defined in the top-level pom, which means that whenever any module need to change, that its parent will also need to change, and that change to its parent may cause other specs to need to be changed (if they depend on the spec that has been versioned). Those dependent modules really should be released in the same process too, but there is no easy mechanism to automate that in the multi- versioned build. Which leaves that task up to process... and as I have mentioned before, will almost certainly result in problems due to lack of insight into maven and how the multi-version spec build functions. If we have each spec in its own tree, that means that nothing is shared and all referenced version numbers are hardcoded, which means that when a dependency module is released that it is up to the process again to make sure that each dependent module gets updated and then released... which is even more problematic for keeping things in-sync and now users need to have even more insight into how the specs related to each other and will almost certainly end up in disaster, especially as more specs are added and more so when developers come and go. Both multi-version schemes seem to end up going down the same path towards a maintenance nightmare. But, if you compare this with the one version... if a dependency module changes, then all dependent modules will automatically get configured with the right version, will be included in the tag, will be included in the docs (site stuff), will be published and all of this can be done in a few simple steps... all of which are standard m2-isms so anyone who knows m2 should be able to easily understand what is going on. I agree with you on some levels... and in a perfect world maven would be able to make this happen for us as easily as it can with a single- version scheme... but right now this is not the case. Maybe in 6mo or a year maven will have a solution for us, but today it does not. * * * It is still my recommendation that it is best for the project in the short to medium term that one version be used to manage specs... and to commit to revisit later when there is better support for multi- versioned build automation. --jason On Oct 2, 2006, at 6:51 AM, Alan D. Cabrera wrote: > I don't think that this is a good idea. Versions should reflect > the contents of the jar not the fact that an unrelated spec was > released/patched/updated. > > > Regards, > Alan > > On Oct 1, 2006, at 4:07 PM, Jason Dillon wrote: > >> Hi, me again... and the specs topic again too. >> >> I have been thinking about this for quite a while and I believe >> that it would be in the best interest of the project to treat our >> specs as a project and use one version
Re: One version for specs
On Oct 3, 2006, at 11:12 AM, Jason Dillon wrote: On Oct 3, 2006, at 11:03 AM, David Blevins wrote: Dude, you never read my emails. I read it... but the mail you just sent said they have not changed: Can you give some examples on what kind of pom changes that would happen to these that would merit another release? -David
Re: One version for specs
It does not matter how often it happens. The fact that they can be changed, and most *will* have some change made to them, increases the work to manage them significantly. --jason On Oct 3, 2006, at 11:09 AM, Alan D. Cabrera wrote: These don't change all that often, IIRC. Regards, Alan On Oct 2, 2006, at 2:56 PM, Jason Dillon wrote: About 1/3 of the specs depend on other specs (not including the uber 1.4 spec): ejb 2.1 -> jta 1.0.1b ejb3 -> jta 1.1, interceptor, annotation conector 1.5 -> jta 1.0.1b jacc -> servlet 2.4 j2ee mgmt -> ejb 2.1 javamail 1.3.1 -> activation javamail 1.4 -> activation jaxr -> activation jaxrpc -> saaj, qname, servlet 2.4 jsp -> servlet 2.4 saaj -> activation --jason On Oct 2, 2006, at 1:38 PM, Aaron Mulder wrote: I hear you, but underlying your case is the assumption that a lot of specs depend on each other. I'm not convinced that's true. Certainly, no J2EE 1.4 specs should rely on any J2EE 1.5 or non-J2EE specs. I guess underlying the compromise proposal is the assumtion that at this point J2EE 1.4 is fairly unlikely to need any changes, so a backward dependency from 1.5 to 1.4 is unlikely to need much maintainance. I'm not sure how many unaligned specs would have other spec dependencies, but I can't think of any. The only dependencies I can really think of are mail on activation, web services on mail and activation, and JSP on servlet I'm sure there are a few more, but I don't think it's anything like the inter-module dependencies of, say, Geronimo itself. Thanks, Aaron On 10/2/06, Jason Dillon <[EMAIL PROTECTED]> wrote: IMO there is no "best" way to handle this problem. There is only good and bad for each solution, but there is no smoking gun to solve everyones issues. I already sent out that itty bitty note about the release being jar + pom(s) but I wanted to clarify that even more... If you take the current specs build... all of the versions of the specs are defined in the top-level pom, which means that whenever any module need to change, that its parent will also need to change, and that change to its parent may cause other specs to need to be changed (if they depend on the spec that has been versioned). Those dependent modules really should be released in the same process too, but there is no easy mechanism to automate that in the multi- versioned build. Which leaves that task up to process... and as I have mentioned before, will almost certainly result in problems due to lack of insight into maven and how the multi-version spec build functions. If we have each spec in its own tree, that means that nothing is shared and all referenced version numbers are hardcoded, which means that when a dependency module is released that it is up to the process again to make sure that each dependent module gets updated and then released... which is even more problematic for keeping things in-sync and now users need to have even more insight into how the specs related to each other and will almost certainly end up in disaster, especially as more specs are added and more so when developers come and go. Both multi-version schemes seem to end up going down the same path towards a maintenance nightmare. But, if you compare this with the one version... if a dependency module changes, then all dependent modules will automatically get configured with the right version, will be included in the tag, will be included in the docs (site stuff), will be published and all of this can be done in a few simple steps... all of which are standard m2-isms so anyone who knows m2 should be able to easily understand what is going on. I agree with you on some levels... and in a perfect world maven would be able to make this happen for us as easily as it can with a single- version scheme... but right now this is not the case. Maybe in 6mo or a year maven will have a solution for us, but today it does not. * * * It is still my recommendation that it is best for the project in the short to medium term that one version be used to manage specs... and to commit to revisit later when there is better support for multi- versioned build automation. --jason On Oct 2, 2006, at 6:51 AM, Alan D. Cabrera wrote: > I don't think that this is a good idea. Versions should reflect > the contents of the jar not the fact that an unrelated spec was > released/patched/updated. > > > Regards, > Alan > > On Oct 1, 2006, at 4:07 PM, Jason Dillon wrote: > >> Hi, me again... and the specs topic again too. >> >> I have been thinking about this for quite a while and I believe >> that it would be in the best interest of the project to treat our >> specs as a project and use one version to release the spec modules >> under. >> >> Doing so will greatly reduce the complexity to maintain the specs >> tree and to make new releases. It also reduces the need for a >> bunch of config in the root pom.xml for specs... all properties >> can be
Re: One version for specs
On Oct 3, 2006, at 11:03 AM, David Blevins wrote: Dude, you never read my emails. I read it... but the mail you just sent said they have not changed: On Oct 3, 2006, at 10:15 AM, David Blevins wrote: Yank these from trunk as they haven't changed in 2+ years? --jason
Re: One version for specs
These don't change all that often, IIRC. Regards, Alan On Oct 2, 2006, at 2:56 PM, Jason Dillon wrote: About 1/3 of the specs depend on other specs (not including the uber 1.4 spec): ejb 2.1 -> jta 1.0.1b ejb3 -> jta 1.1, interceptor, annotation conector 1.5 -> jta 1.0.1b jacc -> servlet 2.4 j2ee mgmt -> ejb 2.1 javamail 1.3.1 -> activation javamail 1.4 -> activation jaxr -> activation jaxrpc -> saaj, qname, servlet 2.4 jsp -> servlet 2.4 saaj -> activation --jason On Oct 2, 2006, at 1:38 PM, Aaron Mulder wrote: I hear you, but underlying your case is the assumption that a lot of specs depend on each other. I'm not convinced that's true. Certainly, no J2EE 1.4 specs should rely on any J2EE 1.5 or non-J2EE specs. I guess underlying the compromise proposal is the assumtion that at this point J2EE 1.4 is fairly unlikely to need any changes, so a backward dependency from 1.5 to 1.4 is unlikely to need much maintainance. I'm not sure how many unaligned specs would have other spec dependencies, but I can't think of any. The only dependencies I can really think of are mail on activation, web services on mail and activation, and JSP on servlet I'm sure there are a few more, but I don't think it's anything like the inter-module dependencies of, say, Geronimo itself. Thanks, Aaron On 10/2/06, Jason Dillon <[EMAIL PROTECTED]> wrote: IMO there is no "best" way to handle this problem. There is only good and bad for each solution, but there is no smoking gun to solve everyones issues. I already sent out that itty bitty note about the release being jar + pom(s) but I wanted to clarify that even more... If you take the current specs build... all of the versions of the specs are defined in the top-level pom, which means that whenever any module need to change, that its parent will also need to change, and that change to its parent may cause other specs to need to be changed (if they depend on the spec that has been versioned). Those dependent modules really should be released in the same process too, but there is no easy mechanism to automate that in the multi- versioned build. Which leaves that task up to process... and as I have mentioned before, will almost certainly result in problems due to lack of insight into maven and how the multi-version spec build functions. If we have each spec in its own tree, that means that nothing is shared and all referenced version numbers are hardcoded, which means that when a dependency module is released that it is up to the process again to make sure that each dependent module gets updated and then released... which is even more problematic for keeping things in-sync and now users need to have even more insight into how the specs related to each other and will almost certainly end up in disaster, especially as more specs are added and more so when developers come and go. Both multi-version schemes seem to end up going down the same path towards a maintenance nightmare. But, if you compare this with the one version... if a dependency module changes, then all dependent modules will automatically get configured with the right version, will be included in the tag, will be included in the docs (site stuff), will be published and all of this can be done in a few simple steps... all of which are standard m2-isms so anyone who knows m2 should be able to easily understand what is going on. I agree with you on some levels... and in a perfect world maven would be able to make this happen for us as easily as it can with a single- version scheme... but right now this is not the case. Maybe in 6mo or a year maven will have a solution for us, but today it does not. * * * It is still my recommendation that it is best for the project in the short to medium term that one version be used to manage specs... and to commit to revisit later when there is better support for multi- versioned build automation. --jason On Oct 2, 2006, at 6:51 AM, Alan D. Cabrera wrote: > I don't think that this is a good idea. Versions should reflect > the contents of the jar not the fact that an unrelated spec was > released/patched/updated. > > > Regards, > Alan > > On Oct 1, 2006, at 4:07 PM, Jason Dillon wrote: > >> Hi, me again... and the specs topic again too. >> >> I have been thinking about this for quite a while and I believe >> that it would be in the best interest of the project to treat our >> specs as a project and use one version to release the spec modules >> under. >> >> Doing so will greatly reduce the complexity to maintain the specs >> tree and to make new releases. It also reduces the need for a >> bunch of config in the root pom.xml for specs... all properties >> can be removed and most of the dependencyManagement can be removed >> as well. >> >> Releases can be done using the release plugin with out any twists >> of configuration, which should be straight forward. The >> alternative is that the configuration becomes more
Re: One version for specs
On Oct 2, 2006, at 12:38 PM, Jason Dillon wrote: IMO there is no "best" way to handle this problem. There is only good and bad for each solution, but there is no smoking gun to solve everyones issues. I already sent out that itty bitty note about the release being jar + pom(s) but I wanted to clarify that even more... If you take the current specs build... all of the versions of the specs are defined in the top-level pom, which means that whenever any module need to change, that its parent will also need to change, and that change to its parent may cause other specs to need to be changed (if they depend on the spec that has been versioned). Those dependent modules really should be released in the same process too, but there is no easy mechanism to automate that in the multi-versioned build. Which leaves that task up to process... and as I have mentioned before, will almost certainly result in problems due to lack of insight into maven and how the multi-version spec build functions. If we have each spec in its own tree, that means that nothing is shared and all referenced version numbers are hardcoded, which means that when a dependency module is released that it is up to the process again to make sure that each dependent module gets updated and then released... which is even more problematic for keeping things in-sync and now users need to have even more insight into how the specs related to each other and will almost certainly end up in disaster, especially as more specs are added and more so when developers come and go. What are the interdependencies between spec jars? I don't think there are many. GIven this fact, I'm not sure that there needs to be a root POM, _in specs_, that binds all the versions together. Regards, Alan
Re: One version for specs
On Oct 3, 2006, at 10:50 AM, Jason Dillon wrote: On Oct 3, 2006, at 10:15 AM, David Blevins wrote: Thoughts? Yank these from trunk as they haven't changed in 2+ years? ejb servlet jms transaction connector qname Not true... remember the pom. Once all of this is settled we need to update the site deployments too. So it is not safe to assume these will not change. Dude, you never read my emails. On Oct 2, 2006, at 1:35 PM, David Blevins wrote: And just so you don't think I'm ignoring pom changes, the poms for the modules I listed are stable to (no deps on anything that's changed). Waiting for another reply -David
Re: One version for specs
On Oct 2, 2006, at 10:35 AM, Aaron Mulder wrote: As a user, it is a convenience to be able to have a single version number to track across all the spec releases. So there's only one variable to track. There are two classes of specs users. One is Geroninmo users and they will just use what ever we have configured; they will not need to track anything since we'll provide everything nicely configured. The second is someone outside of Geronimo who wants to use a spec jar. This person will want to *not* want a single version tracking across all the spec releases. Regards, Alan
Re: One version for specs
On Oct 2, 2006, at 11:55 AM, Dain Sundstrom wrote: How about we split them into j2ee 1.4, j2ee 1.5 and independent modules for the non j2ee specs? This will prevent the flux from the 1.5 development from causing lots of new versions for the 1.4 specs. Just another middle ground idea. Thoughts? I have yet to hear about what the problem is that we're trying to solve by aggregating jars. Regards, Alan
Re: One version for specs
I take it that you are arguing that since the POM changes then the release jar has actually changed. This argument already assumes that you're using a single version for specs. Do I understand correctly? Regards, Alan On Oct 2, 2006, at 11:11 AM, [EMAIL PROTECTED] wrote: Remeber now A release is jar + pom configuration. --jason -Original Message- From: "Alan D. Cabrera" <[EMAIL PROTECTED]> Date: Mon, 2 Oct 2006 06:51:20 To:[email protected] Subject: Re: One version for specs I don't think that this is a good idea. Versions should reflect the contents of the jar not the fact that an unrelated spec was released/ patched/updated. Regards, Alan On Oct 1, 2006, at 4:07 PM, Jason Dillon wrote: Hi, me again... and the specs topic again too. I have been thinking about this for quite a while and I believe that it would be in the best interest of the project to treat our specs as a project and use one version to release the spec modules under. Doing so will greatly reduce the complexity to maintain the specs tree and to make new releases. It also reduces the need for a bunch of config in the root pom.xml for specs... all properties can be removed and most of the dependencyManagement can be removed as well. Releases can be done using the release plugin with out any twists of configuration, which should be straight forward. The alternative is that the configuration becomes more compkicated and that in order to make a release users will have to have much more knowledge of how Maven works and how we have configured it... which I am betting will only lead to something being missed which will only lead to problems down the road. One thing to remember for those of you who are gonna say that some spec module has not changed in x-years... is that the release is code + pom configuration... and even if the code has not changed, the configuration has, and thus it warrants a new release to be made. Specs do not get released that often anyways, so I don't really see any huge problem with re-releasing specs under a new version when something is added (or fixed). 1 version number for us (and our users) is IMO much, much simperer than 30+ versions. For example, if I am a developer and want to use the latest versions of all of the specs that I use, I would much rather know that there is just one version to track, instead of needing to hunt down what the latest version of each spec is... after all I don't care what the version is... I just want the latest version. Also remember that some spec modules depend on other spec modules, so ideally when a dependency module is released, the dependent modules should be released to pickup the latest versions. Doing this is automatic with the one-version scheme, but becomes much more work with independent versions... which will almost certainly result in dependent modules not getting updated as they should. * * * We have also been waiting for some resolution on this to simplify the main server build. It will take all of 10 minutes for me to fix the specs build to use one version and make a release than can be used by the server build (and allow the bootstrap of specs to be removed). So, my recommendation is to: 1) change the specs project to use one version, 2.0-SNAPSHOT, and publish the snaps 2) update the server build to use 2.0-SNAPSHOT for all specs 3) remove the specs build from bootstrap I believe this is the best option for the project and community at this point. I would like to implement this ASAP to simplify the server build. If after some time folks do not feel that is working well, then we can revisit and consider either splitting up into a multi-trunk build or using independent version numbers. But, I do believe that most will find that the advantages of using one version far out-weight the disadvantages. NOTE: For those unaware, Dain did an experiment with version ranges... but it looks like this will not work well right now as there is not general support for use of ranges in most plugins that we depend on. Also several members of the m2 team have suggested that ranges are buggy. This was my general impression that I brought up to Dain weeks ago when we talked about using ranges (and when he said he would try it out). So, for now at least I think that ranges will not work for us. --jason
Re: One version for specs
On Oct 3, 2006, at 10:15 AM, David Blevins wrote: Thoughts? Yank these from trunk as they haven't changed in 2+ years? ejb servlet jms transaction connector qname Not true... remember the pom. Once all of this is settled we need to update the site deployments too. So it is not safe to assume these will not change. --jason
Re: One version for specs
Can we think carefully about complexity for a second and agree that the two models under discussion are trunk/ branches// tags// and /[trunk, branches/, tags/] (in the 2nd choice each spec must be built and released individually by itself, there is no "build all the specs" pom) and that any other choices are going to make releasing anything correctly 120% impossible? We already have a system that doesn't work, thinking up more and more complicated choices is not going to result in ever releasing anything correctly. I'll repeat that philosophically I prefer the second solution but I don't think we have the attention span as a project to make it work so I'm voting for the first choice. I know if I was in charge of releasing the specs I would mess up the second choice for sure but I might be able to make the first choice work. If only half the specs are in trunk I wouldn't even try to build the specs myself locally. thanks david jencks On Oct 3, 2006, at 10:15 AM, David Blevins wrote: On Oct 2, 2006, at 1:35 PM, David Blevins wrote: On Oct 2, 2006, at 1:07 PM, Jason Dillon wrote: The main problem with compromise in this case... (not that I am unwilling to do so), is that it appears that _any_ compromise results in the same problem which I am trying to lead us away from. That problem being a complicated build and release process due to needing deep insight into the dependencies of each spec (or in your example, the groups of specs). No, I wasn't advocating groups of specs. Was more saying "let's just delete these specs from trunk" or otherwise get rid of them and leave only the specs that change and do the one version number thing. The code is tagged, so it's safe. Perhaps the issue is that we don't need these unchanging modules in trunk in the first place. And just so you don't think I'm ignoring pom changes, the poms for the modules I listed are stable to (no deps on anything that's changed). Thoughts? Thoughts? Yank these from trunk as they haven't changed in 2+ years? ejb servlet jms transaction connector qname -David -David --jason On Oct 2, 2006, at 11:16 AM, David Blevins wrote: On Oct 1, 2006, at 4:31 PM, David Jencks wrote: In any case PLEASE think about this and make your opinion known soon. If we could at least make a compromise that'd be very great, all or nothing is not the only way. Maybe we could just remove these core specs from trunk or something (we have several tags): ejb servlet jsp jms transaction connector qname If all the rest became "one version number" specs released at the pace of the most changing spec, that'd still be less desirable but be at least better. Maybe not the best idea, just trying to find some middle ground. Thoughts? -David
Re: One version for specs
On Oct 2, 2006, at 1:35 PM, David Blevins wrote: On Oct 2, 2006, at 1:07 PM, Jason Dillon wrote: The main problem with compromise in this case... (not that I am unwilling to do so), is that it appears that _any_ compromise results in the same problem which I am trying to lead us away from. That problem being a complicated build and release process due to needing deep insight into the dependencies of each spec (or in your example, the groups of specs). No, I wasn't advocating groups of specs. Was more saying "let's just delete these specs from trunk" or otherwise get rid of them and leave only the specs that change and do the one version number thing. The code is tagged, so it's safe. Perhaps the issue is that we don't need these unchanging modules in trunk in the first place. And just so you don't think I'm ignoring pom changes, the poms for the modules I listed are stable to (no deps on anything that's changed). Thoughts? Thoughts? Yank these from trunk as they haven't changed in 2+ years? ejb servlet jms transaction connector qname -David -David --jason On Oct 2, 2006, at 11:16 AM, David Blevins wrote: On Oct 1, 2006, at 4:31 PM, David Jencks wrote: In any case PLEASE think about this and make your opinion known soon. If we could at least make a compromise that'd be very great, all or nothing is not the only way. Maybe we could just remove these core specs from trunk or something (we have several tags): ejb servlet jsp jms transaction connector qname If all the rest became "one version number" specs released at the pace of the most changing spec, that'd still be less desirable but be at least better. Maybe not the best idea, just trying to find some middle ground. Thoughts? -David
Re: One version for specs
The maintenance simplicity problem does not differentiate between less changing specs or not... as soon as something changes, you will see the increased burden of knowledge and tasks to make a complete release. My point is that we do not need to spend time worry about this with one version. I can easily imagine with multi-version that a release might be made, and then something is noticed late in the vote, causing several rc cycles to fix a problem because someone missed updating a dependent spec. This will not happen with one version. --jason On Oct 3, 2006, at 9:21 AM, Dain Sundstrom wrote: This is good info. Out of this list of dependencies activation is the only one that changes often; the rest of the jars are just interfaces (or annotations which are just interfaces). That leaves us with the following problematic specifications: javamail 1.3.1 -> activation javamail 1.4 -> activation jaxr -> activation jaxrpc -> saaj, qname, servlet 2.4 saaj -> activation -dain On Oct 2, 2006, at 2:56 PM, Jason Dillon wrote: About 1/3 of the specs depend on other specs (not including the uber 1.4 spec): ejb 2.1 -> jta 1.0.1b ejb3 -> jta 1.1, interceptor, annotation conector 1.5 -> jta 1.0.1b jacc -> servlet 2.4 j2ee mgmt -> ejb 2.1 javamail 1.3.1 -> activation javamail 1.4 -> activation jaxr -> activation jaxrpc -> saaj, qname, servlet 2.4 jsp -> servlet 2.4 saaj -> activation --jason On Oct 2, 2006, at 1:38 PM, Aaron Mulder wrote: I hear you, but underlying your case is the assumption that a lot of specs depend on each other. I'm not convinced that's true. Certainly, no J2EE 1.4 specs should rely on any J2EE 1.5 or non-J2EE specs. I guess underlying the compromise proposal is the assumtion that at this point J2EE 1.4 is fairly unlikely to need any changes, so a backward dependency from 1.5 to 1.4 is unlikely to need much maintainance. I'm not sure how many unaligned specs would have other spec dependencies, but I can't think of any. The only dependencies I can really think of are mail on activation, web services on mail and activation, and JSP on servlet I'm sure there are a few more, but I don't think it's anything like the inter-module dependencies of, say, Geronimo itself. Thanks, Aaron On 10/2/06, Jason Dillon <[EMAIL PROTECTED]> wrote: IMO there is no "best" way to handle this problem. There is only good and bad for each solution, but there is no smoking gun to solve everyones issues. I already sent out that itty bitty note about the release being jar + pom(s) but I wanted to clarify that even more... If you take the current specs build... all of the versions of the specs are defined in the top-level pom, which means that whenever any module need to change, that its parent will also need to change, and that change to its parent may cause other specs to need to be changed (if they depend on the spec that has been versioned). Those dependent modules really should be released in the same process too, but there is no easy mechanism to automate that in the multi- versioned build. Which leaves that task up to process... and as I have mentioned before, will almost certainly result in problems due to lack of insight into maven and how the multi-version spec build functions. If we have each spec in its own tree, that means that nothing is shared and all referenced version numbers are hardcoded, which means that when a dependency module is released that it is up to the process again to make sure that each dependent module gets updated and then released... which is even more problematic for keeping things in-sync and now users need to have even more insight into how the specs related to each other and will almost certainly end up in disaster, especially as more specs are added and more so when developers come and go. Both multi-version schemes seem to end up going down the same path towards a maintenance nightmare. But, if you compare this with the one version... if a dependency module changes, then all dependent modules will automatically get configured with the right version, will be included in the tag, will be included in the docs (site stuff), will be published and all of this can be done in a few simple steps... all of which are standard m2-isms so anyone who knows m2 should be able to easily understand what is going on. I agree with you on some levels... and in a perfect world maven would be able to make this happen for us as easily as it can with a single- version scheme... but right now this is not the case. Maybe in 6mo or a year maven will have a solution for us, but today it does not. * * * It is still my recommendation that it is best for the project in the short to medium term that one version be used to manage specs... and to commit to revisit later when there is better support for multi- versioned build automation. --jason On Oct 2, 2006, at 6:51 AM, Alan D. Cabrera wrote: > I don't think
Re: One version for specs
This is good info. Out of this list of dependencies activation is the only one that changes often; the rest of the jars are just interfaces (or annotations which are just interfaces). That leaves us with the following problematic specifications: javamail 1.3.1 -> activation javamail 1.4 -> activation jaxr -> activation jaxrpc -> saaj, qname, servlet 2.4 saaj -> activation -dain On Oct 2, 2006, at 2:56 PM, Jason Dillon wrote: About 1/3 of the specs depend on other specs (not including the uber 1.4 spec): ejb 2.1 -> jta 1.0.1b ejb3 -> jta 1.1, interceptor, annotation conector 1.5 -> jta 1.0.1b jacc -> servlet 2.4 j2ee mgmt -> ejb 2.1 javamail 1.3.1 -> activation javamail 1.4 -> activation jaxr -> activation jaxrpc -> saaj, qname, servlet 2.4 jsp -> servlet 2.4 saaj -> activation --jason On Oct 2, 2006, at 1:38 PM, Aaron Mulder wrote: I hear you, but underlying your case is the assumption that a lot of specs depend on each other. I'm not convinced that's true. Certainly, no J2EE 1.4 specs should rely on any J2EE 1.5 or non-J2EE specs. I guess underlying the compromise proposal is the assumtion that at this point J2EE 1.4 is fairly unlikely to need any changes, so a backward dependency from 1.5 to 1.4 is unlikely to need much maintainance. I'm not sure how many unaligned specs would have other spec dependencies, but I can't think of any. The only dependencies I can really think of are mail on activation, web services on mail and activation, and JSP on servlet I'm sure there are a few more, but I don't think it's anything like the inter-module dependencies of, say, Geronimo itself. Thanks, Aaron On 10/2/06, Jason Dillon <[EMAIL PROTECTED]> wrote: IMO there is no "best" way to handle this problem. There is only good and bad for each solution, but there is no smoking gun to solve everyones issues. I already sent out that itty bitty note about the release being jar + pom(s) but I wanted to clarify that even more... If you take the current specs build... all of the versions of the specs are defined in the top-level pom, which means that whenever any module need to change, that its parent will also need to change, and that change to its parent may cause other specs to need to be changed (if they depend on the spec that has been versioned). Those dependent modules really should be released in the same process too, but there is no easy mechanism to automate that in the multi- versioned build. Which leaves that task up to process... and as I have mentioned before, will almost certainly result in problems due to lack of insight into maven and how the multi-version spec build functions. If we have each spec in its own tree, that means that nothing is shared and all referenced version numbers are hardcoded, which means that when a dependency module is released that it is up to the process again to make sure that each dependent module gets updated and then released... which is even more problematic for keeping things in-sync and now users need to have even more insight into how the specs related to each other and will almost certainly end up in disaster, especially as more specs are added and more so when developers come and go. Both multi-version schemes seem to end up going down the same path towards a maintenance nightmare. But, if you compare this with the one version... if a dependency module changes, then all dependent modules will automatically get configured with the right version, will be included in the tag, will be included in the docs (site stuff), will be published and all of this can be done in a few simple steps... all of which are standard m2-isms so anyone who knows m2 should be able to easily understand what is going on. I agree with you on some levels... and in a perfect world maven would be able to make this happen for us as easily as it can with a single- version scheme... but right now this is not the case. Maybe in 6mo or a year maven will have a solution for us, but today it does not. * * * It is still my recommendation that it is best for the project in the short to medium term that one version be used to manage specs... and to commit to revisit later when there is better support for multi- versioned build automation. --jason On Oct 2, 2006, at 6:51 AM, Alan D. Cabrera wrote: > I don't think that this is a good idea. Versions should reflect > the contents of the jar not the fact that an unrelated spec was > released/patched/updated. > > > Regards, > Alan > > On Oct 1, 2006, at 4:07 PM, Jason Dillon wrote: > >> Hi, me again... and the specs topic again too. >> >> I have been thinking about this for quite a while and I believe >> that it would be in the best interest of the project to treat our >> specs as a project and use one version to release the spec modules >> under. >> >> Doing so will greatly reduce the complexity to maintain the specs >> tree and to make new releases. It also reduces the need for a >> bunch of
Re: One version for specs
About 1/3 of the specs depend on other specs (not including the uber 1.4 spec): ejb 2.1 -> jta 1.0.1b ejb3 -> jta 1.1, interceptor, annotation conector 1.5 -> jta 1.0.1b jacc -> servlet 2.4 j2ee mgmt -> ejb 2.1 javamail 1.3.1 -> activation javamail 1.4 -> activation jaxr -> activation jaxrpc -> saaj, qname, servlet 2.4 jsp -> servlet 2.4 saaj -> activation --jason On Oct 2, 2006, at 1:38 PM, Aaron Mulder wrote: I hear you, but underlying your case is the assumption that a lot of specs depend on each other. I'm not convinced that's true. Certainly, no J2EE 1.4 specs should rely on any J2EE 1.5 or non-J2EE specs. I guess underlying the compromise proposal is the assumtion that at this point J2EE 1.4 is fairly unlikely to need any changes, so a backward dependency from 1.5 to 1.4 is unlikely to need much maintainance. I'm not sure how many unaligned specs would have other spec dependencies, but I can't think of any. The only dependencies I can really think of are mail on activation, web services on mail and activation, and JSP on servlet I'm sure there are a few more, but I don't think it's anything like the inter-module dependencies of, say, Geronimo itself. Thanks, Aaron On 10/2/06, Jason Dillon <[EMAIL PROTECTED]> wrote: IMO there is no "best" way to handle this problem. There is only good and bad for each solution, but there is no smoking gun to solve everyones issues. I already sent out that itty bitty note about the release being jar + pom(s) but I wanted to clarify that even more... If you take the current specs build... all of the versions of the specs are defined in the top-level pom, which means that whenever any module need to change, that its parent will also need to change, and that change to its parent may cause other specs to need to be changed (if they depend on the spec that has been versioned). Those dependent modules really should be released in the same process too, but there is no easy mechanism to automate that in the multi- versioned build. Which leaves that task up to process... and as I have mentioned before, will almost certainly result in problems due to lack of insight into maven and how the multi-version spec build functions. If we have each spec in its own tree, that means that nothing is shared and all referenced version numbers are hardcoded, which means that when a dependency module is released that it is up to the process again to make sure that each dependent module gets updated and then released... which is even more problematic for keeping things in-sync and now users need to have even more insight into how the specs related to each other and will almost certainly end up in disaster, especially as more specs are added and more so when developers come and go. Both multi-version schemes seem to end up going down the same path towards a maintenance nightmare. But, if you compare this with the one version... if a dependency module changes, then all dependent modules will automatically get configured with the right version, will be included in the tag, will be included in the docs (site stuff), will be published and all of this can be done in a few simple steps... all of which are standard m2-isms so anyone who knows m2 should be able to easily understand what is going on. I agree with you on some levels... and in a perfect world maven would be able to make this happen for us as easily as it can with a single- version scheme... but right now this is not the case. Maybe in 6mo or a year maven will have a solution for us, but today it does not. * * * It is still my recommendation that it is best for the project in the short to medium term that one version be used to manage specs... and to commit to revisit later when there is better support for multi- versioned build automation. --jason On Oct 2, 2006, at 6:51 AM, Alan D. Cabrera wrote: > I don't think that this is a good idea. Versions should reflect > the contents of the jar not the fact that an unrelated spec was > released/patched/updated. > > > Regards, > Alan > > On Oct 1, 2006, at 4:07 PM, Jason Dillon wrote: > >> Hi, me again... and the specs topic again too. >> >> I have been thinking about this for quite a while and I believe >> that it would be in the best interest of the project to treat our >> specs as a project and use one version to release the spec modules >> under. >> >> Doing so will greatly reduce the complexity to maintain the specs >> tree and to make new releases. It also reduces the need for a >> bunch of config in the root pom.xml for specs... all properties >> can be removed and most of the dependencyManagement can be removed >> as well. >> >> Releases can be done using the release plugin with out any twists >> of configuration, which should be straight forward. The >> alternative is that the configuration becomes more compkicated and >> that in order to make a release users will have to have much more >> knowledge of how Maven works and how we have
Re: One version for specs
You may be right... but I still believe one version is going to be easier for us. And I am willing to make the changes to get one version working as it is simple and easy (with a decent network connection it can all be done in under an hour). Almost anything else is going to take much longer and I believe the comparison of the work to rectify the state of the specs build is indicative of the effort it is going to take to maintain more and more of em. But... we need to fix this. Right now we can not even publish new specs for development as half of them will end up published to the snapshot repo and another half to the sync repo. This is due to the versions in trunk not being reset to SNAPSHOT versions after a release... which is also some more evidence that the multi-version method is problematic as non of the versions in trunk should have been set to a non-SNAPSHOT for more than a brief moment when a release was being made. With one version and the release plugin this problem goes away, and any dependencies are automatically updated to the correct version... which means that everything will be insync... all the time... at the slight cost of re-publishing new artifacts for modules which have had no code change... a minor cost worth the price of easy maintainable automation. --jason On Oct 2, 2006, at 1:38 PM, Aaron Mulder wrote: I hear you, but underlying your case is the assumption that a lot of specs depend on each other. I'm not convinced that's true. Certainly, no J2EE 1.4 specs should rely on any J2EE 1.5 or non-J2EE specs. I guess underlying the compromise proposal is the assumtion that at this point J2EE 1.4 is fairly unlikely to need any changes, so a backward dependency from 1.5 to 1.4 is unlikely to need much maintainance. I'm not sure how many unaligned specs would have other spec dependencies, but I can't think of any. The only dependencies I can really think of are mail on activation, web services on mail and activation, and JSP on servlet I'm sure there are a few more, but I don't think it's anything like the inter-module dependencies of, say, Geronimo itself. Thanks, Aaron On 10/2/06, Jason Dillon <[EMAIL PROTECTED]> wrote: IMO there is no "best" way to handle this problem. There is only good and bad for each solution, but there is no smoking gun to solve everyones issues. I already sent out that itty bitty note about the release being jar + pom(s) but I wanted to clarify that even more... If you take the current specs build... all of the versions of the specs are defined in the top-level pom, which means that whenever any module need to change, that its parent will also need to change, and that change to its parent may cause other specs to need to be changed (if they depend on the spec that has been versioned). Those dependent modules really should be released in the same process too, but there is no easy mechanism to automate that in the multi- versioned build. Which leaves that task up to process... and as I have mentioned before, will almost certainly result in problems due to lack of insight into maven and how the multi-version spec build functions. If we have each spec in its own tree, that means that nothing is shared and all referenced version numbers are hardcoded, which means that when a dependency module is released that it is up to the process again to make sure that each dependent module gets updated and then released... which is even more problematic for keeping things in-sync and now users need to have even more insight into how the specs related to each other and will almost certainly end up in disaster, especially as more specs are added and more so when developers come and go. Both multi-version schemes seem to end up going down the same path towards a maintenance nightmare. But, if you compare this with the one version... if a dependency module changes, then all dependent modules will automatically get configured with the right version, will be included in the tag, will be included in the docs (site stuff), will be published and all of this can be done in a few simple steps... all of which are standard m2-isms so anyone who knows m2 should be able to easily understand what is going on. I agree with you on some levels... and in a perfect world maven would be able to make this happen for us as easily as it can with a single- version scheme... but right now this is not the case. Maybe in 6mo or a year maven will have a solution for us, but today it does not. * * * It is still my recommendation that it is best for the project in the short to medium term that one version be used to manage specs... and to commit to revisit later when there is better support for multi- versioned build automation. --jason On Oct 2, 2006, at 6:51 AM, Alan D. Cabrera wrote: > I don't think that this is a good idea. Versions should reflect > the contents of the jar not the fact that an unrelated spec was >
Re: One version for specs
I hear you, but underlying your case is the assumption that a lot of specs depend on each other. I'm not convinced that's true. Certainly, no J2EE 1.4 specs should rely on any J2EE 1.5 or non-J2EE specs. I guess underlying the compromise proposal is the assumtion that at this point J2EE 1.4 is fairly unlikely to need any changes, so a backward dependency from 1.5 to 1.4 is unlikely to need much maintainance. I'm not sure how many unaligned specs would have other spec dependencies, but I can't think of any. The only dependencies I can really think of are mail on activation, web services on mail and activation, and JSP on servlet I'm sure there are a few more, but I don't think it's anything like the inter-module dependencies of, say, Geronimo itself. Thanks, Aaron On 10/2/06, Jason Dillon <[EMAIL PROTECTED]> wrote: IMO there is no "best" way to handle this problem. There is only good and bad for each solution, but there is no smoking gun to solve everyones issues. I already sent out that itty bitty note about the release being jar + pom(s) but I wanted to clarify that even more... If you take the current specs build... all of the versions of the specs are defined in the top-level pom, which means that whenever any module need to change, that its parent will also need to change, and that change to its parent may cause other specs to need to be changed (if they depend on the spec that has been versioned). Those dependent modules really should be released in the same process too, but there is no easy mechanism to automate that in the multi- versioned build. Which leaves that task up to process... and as I have mentioned before, will almost certainly result in problems due to lack of insight into maven and how the multi-version spec build functions. If we have each spec in its own tree, that means that nothing is shared and all referenced version numbers are hardcoded, which means that when a dependency module is released that it is up to the process again to make sure that each dependent module gets updated and then released... which is even more problematic for keeping things in-sync and now users need to have even more insight into how the specs related to each other and will almost certainly end up in disaster, especially as more specs are added and more so when developers come and go. Both multi-version schemes seem to end up going down the same path towards a maintenance nightmare. But, if you compare this with the one version... if a dependency module changes, then all dependent modules will automatically get configured with the right version, will be included in the tag, will be included in the docs (site stuff), will be published and all of this can be done in a few simple steps... all of which are standard m2-isms so anyone who knows m2 should be able to easily understand what is going on. I agree with you on some levels... and in a perfect world maven would be able to make this happen for us as easily as it can with a single- version scheme... but right now this is not the case. Maybe in 6mo or a year maven will have a solution for us, but today it does not. * * * It is still my recommendation that it is best for the project in the short to medium term that one version be used to manage specs... and to commit to revisit later when there is better support for multi- versioned build automation. --jason On Oct 2, 2006, at 6:51 AM, Alan D. Cabrera wrote: > I don't think that this is a good idea. Versions should reflect > the contents of the jar not the fact that an unrelated spec was > released/patched/updated. > > > Regards, > Alan > > On Oct 1, 2006, at 4:07 PM, Jason Dillon wrote: > >> Hi, me again... and the specs topic again too. >> >> I have been thinking about this for quite a while and I believe >> that it would be in the best interest of the project to treat our >> specs as a project and use one version to release the spec modules >> under. >> >> Doing so will greatly reduce the complexity to maintain the specs >> tree and to make new releases. It also reduces the need for a >> bunch of config in the root pom.xml for specs... all properties >> can be removed and most of the dependencyManagement can be removed >> as well. >> >> Releases can be done using the release plugin with out any twists >> of configuration, which should be straight forward. The >> alternative is that the configuration becomes more compkicated and >> that in order to make a release users will have to have much more >> knowledge of how Maven works and how we have configured it... >> which I am betting will only lead to something being missed which >> will only lead to problems down the road. >> >> One thing to remember for those of you who are gonna say that some >> spec module has not changed in x-years... is that the release is >> code + pom configuration... and even if the code has not changed, >> the configuration has, and thus it warrants a new release to be made. >> >> Specs do not
Re: One version for specs
On Oct 2, 2006, at 1:07 PM, Jason Dillon wrote: The main problem with compromise in this case... (not that I am unwilling to do so), is that it appears that _any_ compromise results in the same problem which I am trying to lead us away from. That problem being a complicated build and release process due to needing deep insight into the dependencies of each spec (or in your example, the groups of specs). No, I wasn't advocating groups of specs. Was more saying "let's just delete these specs from trunk" or otherwise get rid of them and leave only the specs that change and do the one version number thing. The code is tagged, so it's safe. Perhaps the issue is that we don't need these unchanging modules in trunk in the first place. And just so you don't think I'm ignoring pom changes, the poms for the modules I listed are stable to (no deps on anything that's changed). Thoughts? -David --jason On Oct 2, 2006, at 11:16 AM, David Blevins wrote: On Oct 1, 2006, at 4:31 PM, David Jencks wrote: In any case PLEASE think about this and make your opinion known soon. If we could at least make a compromise that'd be very great, all or nothing is not the only way. Maybe we could just remove these core specs from trunk or something (we have several tags): ejb servlet jsp jms transaction connector qname If all the rest became "one version number" specs released at the pace of the most changing spec, that'd still be less desirable but be at least better. Maybe not the best idea, just trying to find some middle ground. Thoughts? -David
Re: One version for specs
The main problem with compromise in this case... (not that I am unwilling to do so), is that it appears that _any_ compromise results in the same problem which I am trying to lead us away from. That problem being a complicated build and release process due to needing deep insight into the dependencies of each spec (or in your example, the groups of specs). IMO, splitting up into a smaller subset of groups for specs is no better than having a separate tree for each. I do not believe that multi-versioned spec maintenance will scale well... and in some ways I think it has already kinda proven that. 3 small groups for 1.4, 1.5 and other is already on the verge of becoming more work than it should be due to the overlap and dependencies. I will even go as far as saying that for most large project multi- versioning will not scale. Consider how much work it would be to keep G in sync if each and every module (config, code, app deployable, app deployable component, assembly and plugin) were individual versioned to live up to the code to version purity fallacy. Well, I can tell you that is a massive nightmare in the works... I've been there already in fact, a few times, most recently at my last gig. When I got there I saw developers with little stickys on their cubes listing versions and compatibility of like 60 different modules... where it took developers hours to make releases for each module, which ended up causing more problems if something was missed or a mistake was made that cascaded down to other dependent modules which ended up causing the entire thing to be re-released. It took me almost 5 months to un*uck that mess (of which a lot of time was spent sending mails kinda like this one)... and in the end I left them in a state where they could automate *every* build and every release at the click of a button on a browser. What used to take hours and caused a bunch of problems due to an overly complicated process to make a simple code release, could now be done in a few minutes and was highly reliable, repeatable and simple. --jason On Oct 2, 2006, at 11:16 AM, David Blevins wrote: On Oct 1, 2006, at 4:31 PM, David Jencks wrote: In any case PLEASE think about this and make your opinion known soon. If we could at least make a compromise that'd be very great, all or nothing is not the only way. Maybe we could just remove these core specs from trunk or something (we have several tags): ejb servlet jsp jms transaction connector qname If all the rest became "one version number" specs released at the pace of the most changing spec, that'd still be less desirable but be at least better. Maybe not the best idea, just trying to find some middle ground. Thoughts? -David
Re: One version for specs
On Oct 2, 2006, at 10:35 AM, Aaron Mulder wrote: However, I still don't think this is a very good approach. Our specs tree will continue to expand with new JSRs and J2EE releases, especially if we go with the earlier intent of making it a home for all Apache Java spec packages. I don't like the idea that I'll have 10 versions of EJB 2.0 in my local repository, all with the same code, and with different projects potentially using different revs depending on how aggressive they are about needing new unrelated specs. Growing spec modules is actually a case to simplify and use one version rather than the opposite... especially for cases when new specs depend on other specs. I think in the end, I'd rather have separate builds for separate specs and an auto-generated or frequently updated web page with a table listing all the specs with their JSR reference and the latest released and snapshot versions of each. If I had to check that page for the right numbers for each spec when building a new POM, that would be a pretty close second to just having all of them use the same number (which I'd still have to look up each time anyway). And it would mean copy and paste dependencies on old specs like EJB 2 would be more likely to be up to date. IMO the one-version for users, which is the point I am getting most of of this reply, is a side-effect of a simple process for developers (us) to manage a growing codebase of specs. Separate builds for specs does not really solve any of the problems related to maintenance which I have been trying to explain in more detail. The only problem which separate builds solves is that it reduces (not eliminates) re-releases of spec modules hat have had no _code_ change (could be a header change, or a config change, or a documentation change though). The amount of effort required to maintain a system like this far outweighs the advantages of _purity_ (or semi-purity when you consider the non-code changes described above). --jason
Re: One version for specs
IMO there is no "best" way to handle this problem. There is only good and bad for each solution, but there is no smoking gun to solve everyones issues. I already sent out that itty bitty note about the release being jar + pom(s) but I wanted to clarify that even more... If you take the current specs build... all of the versions of the specs are defined in the top-level pom, which means that whenever any module need to change, that its parent will also need to change, and that change to its parent may cause other specs to need to be changed (if they depend on the spec that has been versioned). Those dependent modules really should be released in the same process too, but there is no easy mechanism to automate that in the multi- versioned build. Which leaves that task up to process... and as I have mentioned before, will almost certainly result in problems due to lack of insight into maven and how the multi-version spec build functions. If we have each spec in its own tree, that means that nothing is shared and all referenced version numbers are hardcoded, which means that when a dependency module is released that it is up to the process again to make sure that each dependent module gets updated and then released... which is even more problematic for keeping things in-sync and now users need to have even more insight into how the specs related to each other and will almost certainly end up in disaster, especially as more specs are added and more so when developers come and go. Both multi-version schemes seem to end up going down the same path towards a maintenance nightmare. But, if you compare this with the one version... if a dependency module changes, then all dependent modules will automatically get configured with the right version, will be included in the tag, will be included in the docs (site stuff), will be published and all of this can be done in a few simple steps... all of which are standard m2-isms so anyone who knows m2 should be able to easily understand what is going on. I agree with you on some levels... and in a perfect world maven would be able to make this happen for us as easily as it can with a single- version scheme... but right now this is not the case. Maybe in 6mo or a year maven will have a solution for us, but today it does not. * * * It is still my recommendation that it is best for the project in the short to medium term that one version be used to manage specs... and to commit to revisit later when there is better support for multi- versioned build automation. --jason On Oct 2, 2006, at 6:51 AM, Alan D. Cabrera wrote: I don't think that this is a good idea. Versions should reflect the contents of the jar not the fact that an unrelated spec was released/patched/updated. Regards, Alan On Oct 1, 2006, at 4:07 PM, Jason Dillon wrote: Hi, me again... and the specs topic again too. I have been thinking about this for quite a while and I believe that it would be in the best interest of the project to treat our specs as a project and use one version to release the spec modules under. Doing so will greatly reduce the complexity to maintain the specs tree and to make new releases. It also reduces the need for a bunch of config in the root pom.xml for specs... all properties can be removed and most of the dependencyManagement can be removed as well. Releases can be done using the release plugin with out any twists of configuration, which should be straight forward. The alternative is that the configuration becomes more compkicated and that in order to make a release users will have to have much more knowledge of how Maven works and how we have configured it... which I am betting will only lead to something being missed which will only lead to problems down the road. One thing to remember for those of you who are gonna say that some spec module has not changed in x-years... is that the release is code + pom configuration... and even if the code has not changed, the configuration has, and thus it warrants a new release to be made. Specs do not get released that often anyways, so I don't really see any huge problem with re-releasing specs under a new version when something is added (or fixed). 1 version number for us (and our users) is IMO much, much simperer than 30+ versions. For example, if I am a developer and want to use the latest versions of all of the specs that I use, I would much rather know that there is just one version to track, instead of needing to hunt down what the latest version of each spec is... after all I don't care what the version is... I just want the latest version. Also remember that some spec modules depend on other spec modules, so ideally when a dependency module is released, the dependent modules should be released to pickup the latest versions. Doing this is automatic with the one-version
Re: One version for specs
On Oct 2, 2006, at 11:55 AM, Dain Sundstrom wrote: How about we split them into j2ee 1.4, j2ee 1.5 and independent modules for the non j2ee specs? This will prevent the flux from the 1.5 development from causing lots of new versions for the 1.4 specs. Just another middle ground idea. Thoughts? There are a few specs that overlap and are used in both j2ee 1.4 and jee 5 such as jms and connector. There might be more. -David -dain On Oct 2, 2006, at 11:16 AM, David Blevins wrote: On Oct 1, 2006, at 4:31 PM, David Jencks wrote: In any case PLEASE think about this and make your opinion known soon. If we could at least make a compromise that'd be very great, all or nothing is not the only way. Maybe we could just remove these core specs from trunk or something (we have several tags): ejb servlet jsp jms transaction connector qname If all the rest became "one version number" specs released at the pace of the most changing spec, that'd still be less desirable but be at least better. Maybe not the best idea, just trying to find some middle ground. Thoughts? -David
Re: One version for specs
I don't think that 1.5 development will result in new releases... those will all be SNAPSHOT artifacts anyways. Just some questions about this strategy... Which modules go where? Will each of these trees have a single version? How will the overlap between J2EE 1.5 and 1.4 fit? Where will common config go? --jason On Oct 2, 2006, at 11:55 AM, Dain Sundstrom wrote: How about we split them into j2ee 1.4, j2ee 1.5 and independent modules for the non j2ee specs? This will prevent the flux from the 1.5 development from causing lots of new versions for the 1.4 specs. Just another middle ground idea. Thoughts? -dain On Oct 2, 2006, at 11:16 AM, David Blevins wrote: On Oct 1, 2006, at 4:31 PM, David Jencks wrote: In any case PLEASE think about this and make your opinion known soon. If we could at least make a compromise that'd be very great, all or nothing is not the only way. Maybe we could just remove these core specs from trunk or something (we have several tags): ejb servlet jsp jms transaction connector qname If all the rest became "one version number" specs released at the pace of the most changing spec, that'd still be less desirable but be at least better. Maybe not the best idea, just trying to find some middle ground. Thoughts? -David
Re: One version for specs
A good compromise. Also, good for a start. Let's do this. Cheers Prasad On 10/2/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: How about we split them into j2ee 1.4, j2ee 1.5 and independent modules for the non j2ee specs? This will prevent the flux from the 1.5 development from causing lots of new versions for the 1.4 specs. Just another middle ground idea. Thoughts? -dain On Oct 2, 2006, at 11:16 AM, David Blevins wrote: > > On Oct 1, 2006, at 4:31 PM, David Jencks wrote: > >> In any case PLEASE think about this and make your opinion known soon. > > If we could at least make a compromise that'd be very great, all or > nothing is not the only way. > > Maybe we could just remove these core specs from trunk or something > (we have several tags): > > ejb > servlet > jsp > jms > transaction > connector > qname > > If all the rest became "one version number" specs released at the > pace of the most changing spec, that'd still be less desirable but > be at least better. > > Maybe not the best idea, just trying to find some middle ground. > Thoughts? > > -David > >
Re: One version for specs
On 10/2/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: How about we split them into j2ee 1.4, j2ee 1.5 and independent modules for the non j2ee specs? This will prevent the flux from the 1.5 development from causing lots of new versions for the 1.4 specs. Sounds promising to me... Thanks, Aaron On Oct 2, 2006, at 11:16 AM, David Blevins wrote: > > On Oct 1, 2006, at 4:31 PM, David Jencks wrote: > >> In any case PLEASE think about this and make your opinion known soon. > > If we could at least make a compromise that'd be very great, all or > nothing is not the only way. > > Maybe we could just remove these core specs from trunk or something > (we have several tags): > > ejb > servlet > jsp > jms > transaction > connector > qname > > If all the rest became "one version number" specs released at the > pace of the most changing spec, that'd still be less desirable but > be at least better. > > Maybe not the best idea, just trying to find some middle ground. > Thoughts? > > -David > >
Re: One version for specs
How about we split them into j2ee 1.4, j2ee 1.5 and independent modules for the non j2ee specs? This will prevent the flux from the 1.5 development from causing lots of new versions for the 1.4 specs. Just another middle ground idea. Thoughts? -dain On Oct 2, 2006, at 11:16 AM, David Blevins wrote: On Oct 1, 2006, at 4:31 PM, David Jencks wrote: In any case PLEASE think about this and make your opinion known soon. If we could at least make a compromise that'd be very great, all or nothing is not the only way. Maybe we could just remove these core specs from trunk or something (we have several tags): ejb servlet jsp jms transaction connector qname If all the rest became "one version number" specs released at the pace of the most changing spec, that'd still be less desirable but be at least better. Maybe not the best idea, just trying to find some middle ground. Thoughts? -David
Re: One version for specs
On Oct 1, 2006, at 4:31 PM, David Jencks wrote: In any case PLEASE think about this and make your opinion known soon. If we could at least make a compromise that'd be very great, all or nothing is not the only way. Maybe we could just remove these core specs from trunk or something (we have several tags): ejb servlet jsp jms transaction connector qname If all the rest became "one version number" specs released at the pace of the most changing spec, that'd still be less desirable but be at least better. Maybe not the best idea, just trying to find some middle ground. Thoughts? -David
Re: One version for specs
Remeber now A release is jar + pom configuration. --jason -Original Message- From: "Alan D. Cabrera" <[EMAIL PROTECTED]> Date: Mon, 2 Oct 2006 06:51:20 To:[email protected] Subject: Re: One version for specs I don't think that this is a good idea. Versions should reflect the contents of the jar not the fact that an unrelated spec was released/ patched/updated. Regards, Alan On Oct 1, 2006, at 4:07 PM, Jason Dillon wrote: > Hi, me again... and the specs topic again too. > > I have been thinking about this for quite a while and I believe > that it would be in the best interest of the project to treat our > specs as a project and use one version to release the spec modules > under. > > Doing so will greatly reduce the complexity to maintain the specs > tree and to make new releases. It also reduces the need for a > bunch of config in the root pom.xml for specs... all properties can > be removed and most of the dependencyManagement can be removed as > well. > > Releases can be done using the release plugin with out any twists > of configuration, which should be straight forward. The > alternative is that the configuration becomes more compkicated and > that in order to make a release users will have to have much more > knowledge of how Maven works and how we have configured it... which > I am betting will only lead to something being missed which will > only lead to problems down the road. > > One thing to remember for those of you who are gonna say that some > spec module has not changed in x-years... is that the release is > code + pom configuration... and even if the code has not changed, > the configuration has, and thus it warrants a new release to be made. > > Specs do not get released that often anyways, so I don't really see > any huge problem with re-releasing specs under a new version when > something is added (or fixed). > > 1 version number for us (and our users) is IMO much, much simperer > than 30+ versions. For example, if I am a developer and want to > use the latest versions of all of the specs that I use, I would > much rather know that there is just one version to track, instead > of needing to hunt down what the latest version of each spec is... > after all I don't care what the version is... I just want the > latest version. > > Also remember that some spec modules depend on other spec modules, > so ideally when a dependency module is released, the dependent > modules should be released to pickup the latest versions. Doing > this is automatic with the one-version scheme, but becomes much > more work with independent versions... which will almost certainly > result in dependent modules not getting updated as they should. > > * * * > > We have also been waiting for some resolution on this to simplify > the main server build. It will take all of 10 minutes for me to > fix the specs build to use one version and make a release than can > be used by the server build (and allow the bootstrap of specs to be > removed). > > So, my recommendation is to: > > 1) change the specs project to use one version, 2.0-SNAPSHOT, and > publish the snaps > 2) update the server build to use 2.0-SNAPSHOT for all specs > 3) remove the specs build from bootstrap > > I believe this is the best option for the project and community at > this point. I would like to implement this ASAP to simplify the > server build. If after some time folks do not feel that is working > well, then we can revisit and consider either splitting up into a > multi-trunk build or using independent version numbers. But, I do > believe that most will find that the advantages of using one > version far out-weight the disadvantages. > > NOTE: > > For those unaware, Dain did an experiment with version ranges... > but it looks like this will not work well right now as there is not > general support for use of ranges in most plugins that we depend > on. Also several members of the m2 team have suggested that ranges > are buggy. This was my general impression that I brought up to > Dain weeks ago when we talked about using ranges (and when he said > he would try it out). So, for now at least I think that ranges > will not work for us. > > --jason > >
Re: One version for specs
As a user, it is a convenience to be able to have a single version number to track across all the spec releases. So there's only one variable to track. However, I still don't think this is a very good approach. Our specs tree will continue to expand with new JSRs and J2EE releases, especially if we go with the earlier intent of making it a home for all Apache Java spec packages. I don't like the idea that I'll have 10 versions of EJB 2.0 in my local repository, all with the same code, and with different projects potentially using different revs depending on how aggressive they are about needing new unrelated specs. I think in the end, I'd rather have separate builds for separate specs and an auto-generated or frequently updated web page with a table listing all the specs with their JSR reference and the latest released and snapshot versions of each. If I had to check that page for the right numbers for each spec when building a new POM, that would be a pretty close second to just having all of them use the same number (which I'd still have to look up each time anyway). And it would mean copy and paste dependencies on old specs like EJB 2 would be more likely to be up to date. But in the end, I don't feel super-strongly about it. Thanks, Aaron On 10/1/06, Jason Dillon <[EMAIL PROTECTED]> wrote: Hi, me again... and the specs topic again too. I have been thinking about this for quite a while and I believe that it would be in the best interest of the project to treat our specs as a project and use one version to release the spec modules under. Doing so will greatly reduce the complexity to maintain the specs tree and to make new releases. It also reduces the need for a bunch of config in the root pom.xml for specs... all properties can be removed and most of the dependencyManagement can be removed as well. Releases can be done using the release plugin with out any twists of configuration, which should be straight forward. The alternative is that the configuration becomes more compkicated and that in order to make a release users will have to have much more knowledge of how Maven works and how we have configured it... which I am betting will only lead to something being missed which will only lead to problems down the road. One thing to remember for those of you who are gonna say that some spec module has not changed in x-years... is that the release is code + pom configuration... and even if the code has not changed, the configuration has, and thus it warrants a new release to be made. Specs do not get released that often anyways, so I don't really see any huge problem with re-releasing specs under a new version when something is added (or fixed). 1 version number for us (and our users) is IMO much, much simperer than 30+ versions. For example, if I am a developer and want to use the latest versions of all of the specs that I use, I would much rather know that there is just one version to track, instead of needing to hunt down what the latest version of each spec is... after all I don't care what the version is... I just want the latest version. Also remember that some spec modules depend on other spec modules, so ideally when a dependency module is released, the dependent modules should be released to pickup the latest versions. Doing this is automatic with the one-version scheme, but becomes much more work with independent versions... which will almost certainly result in dependent modules not getting updated as they should. * * * We have also been waiting for some resolution on this to simplify the main server build. It will take all of 10 minutes for me to fix the specs build to use one version and make a release than can be used by the server build (and allow the bootstrap of specs to be removed). So, my recommendation is to: 1) change the specs project to use one version, 2.0-SNAPSHOT, and publish the snaps 2) update the server build to use 2.0-SNAPSHOT for all specs 3) remove the specs build from bootstrap I believe this is the best option for the project and community at this point. I would like to implement this ASAP to simplify the server build. If after some time folks do not feel that is working well, then we can revisit and consider either splitting up into a multi-trunk build or using independent version numbers. But, I do believe that most will find that the advantages of using one version far out-weight the disadvantages. NOTE: For those unaware, Dain did an experiment with version ranges... but it looks like this will not work well right now as there is not general support for use of ranges in most plugins that we depend on. Also several members of the m2 team have suggested that ranges are buggy. This was my general impression that I brought up to Dain weeks ago when we talked about using ranges (and when he said he would try it out). So, for now at least I think that ranges will not work for us. --jason
Re: One version for specs
On Oct 1, 2006, at 4:31 PM, David Jencks wrote: I now think we should at least try the one-version approach. What we've been doing has resulted IMO in total confusion and many many problems releasing specs. We did try that, seven times. M1 -> 1.0.1 had all specs released all at the same time with the same version number. -David
Re: One version for specs
On Oct 1, 2006, at 4:31 PM, David Jencks wrote: After a long time thinking that separately versioned specs were better I started thinking about how much work it would be if I was trying to release separately versioned specs. I now think we should at least try the one-version approach. What we've been doing has resulted IMO in total confusion and many many problems releasing specs. Can you elaborate what those problems were? Regards, Alan
Re: One version for specs
I don't think that this is a good idea. Versions should reflect the contents of the jar not the fact that an unrelated spec was released/ patched/updated. Regards, Alan On Oct 1, 2006, at 4:07 PM, Jason Dillon wrote: Hi, me again... and the specs topic again too. I have been thinking about this for quite a while and I believe that it would be in the best interest of the project to treat our specs as a project and use one version to release the spec modules under. Doing so will greatly reduce the complexity to maintain the specs tree and to make new releases. It also reduces the need for a bunch of config in the root pom.xml for specs... all properties can be removed and most of the dependencyManagement can be removed as well. Releases can be done using the release plugin with out any twists of configuration, which should be straight forward. The alternative is that the configuration becomes more compkicated and that in order to make a release users will have to have much more knowledge of how Maven works and how we have configured it... which I am betting will only lead to something being missed which will only lead to problems down the road. One thing to remember for those of you who are gonna say that some spec module has not changed in x-years... is that the release is code + pom configuration... and even if the code has not changed, the configuration has, and thus it warrants a new release to be made. Specs do not get released that often anyways, so I don't really see any huge problem with re-releasing specs under a new version when something is added (or fixed). 1 version number for us (and our users) is IMO much, much simperer than 30+ versions. For example, if I am a developer and want to use the latest versions of all of the specs that I use, I would much rather know that there is just one version to track, instead of needing to hunt down what the latest version of each spec is... after all I don't care what the version is... I just want the latest version. Also remember that some spec modules depend on other spec modules, so ideally when a dependency module is released, the dependent modules should be released to pickup the latest versions. Doing this is automatic with the one-version scheme, but becomes much more work with independent versions... which will almost certainly result in dependent modules not getting updated as they should. * * * We have also been waiting for some resolution on this to simplify the main server build. It will take all of 10 minutes for me to fix the specs build to use one version and make a release than can be used by the server build (and allow the bootstrap of specs to be removed). So, my recommendation is to: 1) change the specs project to use one version, 2.0-SNAPSHOT, and publish the snaps 2) update the server build to use 2.0-SNAPSHOT for all specs 3) remove the specs build from bootstrap I believe this is the best option for the project and community at this point. I would like to implement this ASAP to simplify the server build. If after some time folks do not feel that is working well, then we can revisit and consider either splitting up into a multi-trunk build or using independent version numbers. But, I do believe that most will find that the advantages of using one version far out-weight the disadvantages. NOTE: For those unaware, Dain did an experiment with version ranges... but it looks like this will not work well right now as there is not general support for use of ranges in most plugins that we depend on. Also several members of the m2 team have suggested that ranges are buggy. This was my general impression that I brought up to Dain weeks ago when we talked about using ranges (and when he said he would try it out). So, for now at least I think that ranges will not work for us. --jason
Re: One version for specs
On Oct 1, 2006, at 7:31 PM, David Jencks wrote: After a long time thinking that separately versioned specs were better I started thinking about how much work it would be if I was trying to release separately versioned specs. I now think we should at least try the one-version approach. What we've been doing has resulted IMO in total confusion and many many problems releasing specs. In any case PLEASE think about this and make your opinion known soon. My only caveat is that I would prefer to use 1.2-SNAPSHOT releasing to 1.2 rather than 2.0. I tend to regard this as finally straightening out what we are doing with specs, and lining up the versioning and release with the directory structure, rather than a major policy change. (now we have a policy rather than confusion :-) I totally agree that 1 consisten spec version is the way to go. I'd also prefer a 1.2, rather than a 2.0 release. However, I doubt that I would devote too many keystrokes arguing the point... --kevan
Re: One version for specs
After a long time thinking that separately versioned specs were better I started thinking about how much work it would be if I was trying to release separately versioned specs. I now think we should at least try the one-version approach. What we've been doing has resulted IMO in total confusion and many many problems releasing specs. In any case PLEASE think about this and make your opinion known soon. My only caveat is that I would prefer to use 1.2-SNAPSHOT releasing to 1.2 rather than 2.0. I tend to regard this as finally straightening out what we are doing with specs, and lining up the versioning and release with the directory structure, rather than a major policy change. (now we have a policy rather than confusion :-) In addition I'd like to thank Jason for pushing on this issue. thanks david jencks On Oct 1, 2006, at 4:07 PM, Jason Dillon wrote: Hi, me again... and the specs topic again too. I have been thinking about this for quite a while and I believe that it would be in the best interest of the project to treat our specs as a project and use one version to release the spec modules under. Doing so will greatly reduce the complexity to maintain the specs tree and to make new releases. It also reduces the need for a bunch of config in the root pom.xml for specs... all properties can be removed and most of the dependencyManagement can be removed as well. Releases can be done using the release plugin with out any twists of configuration, which should be straight forward. The alternative is that the configuration becomes more compkicated and that in order to make a release users will have to have much more knowledge of how Maven works and how we have configured it... which I am betting will only lead to something being missed which will only lead to problems down the road. One thing to remember for those of you who are gonna say that some spec module has not changed in x-years... is that the release is code + pom configuration... and even if the code has not changed, the configuration has, and thus it warrants a new release to be made. Specs do not get released that often anyways, so I don't really see any huge problem with re-releasing specs under a new version when something is added (or fixed). 1 version number for us (and our users) is IMO much, much simperer than 30+ versions. For example, if I am a developer and want to use the latest versions of all of the specs that I use, I would much rather know that there is just one version to track, instead of needing to hunt down what the latest version of each spec is... after all I don't care what the version is... I just want the latest version. Also remember that some spec modules depend on other spec modules, so ideally when a dependency module is released, the dependent modules should be released to pickup the latest versions. Doing this is automatic with the one-version scheme, but becomes much more work with independent versions... which will almost certainly result in dependent modules not getting updated as they should. * * * We have also been waiting for some resolution on this to simplify the main server build. It will take all of 10 minutes for me to fix the specs build to use one version and make a release than can be used by the server build (and allow the bootstrap of specs to be removed). So, my recommendation is to: 1) change the specs project to use one version, 2.0-SNAPSHOT, and publish the snaps 2) update the server build to use 2.0-SNAPSHOT for all specs 3) remove the specs build from bootstrap I believe this is the best option for the project and community at this point. I would like to implement this ASAP to simplify the server build. If after some time folks do not feel that is working well, then we can revisit and consider either splitting up into a multi-trunk build or using independent version numbers. But, I do believe that most will find that the advantages of using one version far out-weight the disadvantages. NOTE: For those unaware, Dain did an experiment with version ranges... but it looks like this will not work well right now as there is not general support for use of ranges in most plugins that we depend on. Also several members of the m2 team have suggested that ranges are buggy. This was my general impression that I brought up to Dain weeks ago when we talked about using ranges (and when he said he would try it out). So, for now at least I think that ranges will not work for us. --jason
