Re: [DISCUSSION] Release process - fine tuning
On 11 December 2012 23:26, Robert Matthews rmatth...@nakedobjects.orgwrote: Dan 1. A quick look at Eclipse and I'm struggling to see any seemingly random placing. All my components are together and so on. What I do have though is very long names as the group ids are also showing. This is set up in the Eclipse plug-in settings. That said I'd rather have shorter project names, and after making the change to shorter name everything is all over the place. I'm happy with the proposed naming convention as I prefer the benefit of the ordering. That said, the core modules will still appear randomly. Yeah, if you import with the advanced template of [groupId]:[artifactId], then everything is indeed ordered logically. However, when Jeroen and I tried this on Monday, we decided not to use this template, and just went with the default template, which is just the artifactId. Try it... you'll see it's quite a mess. I was just playing around with Idea 12, and (I think) it also does the equivalent, of naming its projects based on the artifact. 2 3. My previous expectations were that the core would be released at a particular point and the components would then be released independently to work against the core, and would probably be re-released again against the same core as they get improved. So the components would evolve more quickly than the core and the core would be improved in the background. (Although isolated fixes to the core would be made without causing the components any concern.) Yes, no change... that's my expectation as well. WRT the parenting, are we expecting the core modules to stay in step - all released each time - or will specific modules be release as they needed? All the core modules would be released together, yes. An alternative strategy to the two options you suggested would be for the parent pom to be released as part of the core, that way it would always be ready for the components. Generally, though, I'm still trying to get my head around how this could/would/should work. Maybe a skype call, were share our thoughts, might be worth while at this stage. I think this is basically the same as having everything parented by core's pom. Indeed, the more I think about it, the more I am happy to go this way. I'm trying it out in a branch locally to see how it flies (ie testing to see if I release core and then if I can release one of the components). 3. Such numbering makes a lot of sense. And as you say a large number is just a large number. Ok, that's three of us in agreement. It might be worthwhile doing a formal vote on this one; perhaps in a day or two. Regards Rob On 12/10/12 20:17, Dan Haywood wrote: All, Following on from the previous discussion thread relating to renaming of artifacts etc, I've been doing some further work on the release process, up to and including have now pushed our isis-core up to the Nexus staging repo. Won't be calling a vote, just wanted to see if it all worked using git (which it does, after a few modifications). Anyway, we have a few alternatives in some of the detail; if you have an opinion on any of this, please respond... 1. artifactId names: eg isis-jdo-objectstore vs isis-objectstore-jdo This point came up in the previous thread, and at the time I was ambivalent as to which way we went on it. Now, though, I think we should use the reverse polish notation, ie isis-objectstore-jdo. The reason is mostly this: if a developer imports the entire project from the root aggregator pom (oai:isis-all) into Eclipse, then the project name will (by default at least) be based on the artifactId. This means that artifacts appear pretty randomly in the Eclipse workspace. Of course, the same argument applies if listing a directory, eg ls WEB-INF/lib. Opinions? 2. Should our releasable modules (core and each of the 20-ish components) have a separate org.apache.isis:isis-parent as their parent (which defines the maven-release-plugin configuration etc), or should they all use org.apache.isis.core:isis as their parent. The benefit of the former (and the code is mostly organized this way) is that, well, it seems to follow what many other maven projects do. But the downside is that we would need to release this isis-parent artifact first, and we might tend to forget about it and not update it. The benefit of the latter is we will always re-release it whenever there is a new release of core, and - as a bonus - all the child modules will inherit version definitions by way of dependencyManagement. Put another way: do we think that the lifecycle of our release process itself be decoupled from the lifecycle of releases of Isis core? If yes, we should have a separate org.apache.isis:isis-parent. If no, we should just use org.apache.isis.core:isis as the parent of all releasable modules. Opinions? 3. What should our version numbers be? This is quite a
Re: [DISCUSSION] Release process - fine tuning
Just tom confirm, I did try it and it is messy, that's why I would like to make the project names shorter (not show the group id, just the artifact id) and have them ordered nicely from a developers perspective - go for the RPN. Rob On 12/11/12 23:36, Dan Haywood wrote: On 11 December 2012 23:26, Robert Matthews rmatth...@nakedobjects.orgwrote: Dan 1. A quick look at Eclipse and I'm struggling to see any seemingly random placing. All my components are together and so on. What I do have though is very long names as the group ids are also showing. This is set up in the Eclipse plug-in settings. That said I'd rather have shorter project names, and after making the change to shorter name everything is all over the place. I'm happy with the proposed naming convention as I prefer the benefit of the ordering. That said, the core modules will still appear randomly. Yeah, if you import with the advanced template of [groupId]:[artifactId], then everything is indeed ordered logically. However, when Jeroen and I tried this on Monday, we decided not to use this template, and just went with the default template, which is just the artifactId. Try it... you'll see it's quite a mess. I was just playing around with Idea 12, and (I think) it also does the equivalent, of naming its projects based on the artifact. 2 3. My previous expectations were that the core would be released at a particular point and the components would then be released independently to work against the core, and would probably be re-released again against the same core as they get improved. So the components would evolve more quickly than the core and the core would be improved in the background. (Although isolated fixes to the core would be made without causing the components any concern.) Yes, no change... that's my expectation as well. WRT the parenting, are we expecting the core modules to stay in step - all released each time - or will specific modules be release as they needed? All the core modules would be released together, yes. An alternative strategy to the two options you suggested would be for the parent pom to be released as part of the core, that way it would always be ready for the components. Generally, though, I'm still trying to get my head around how this could/would/should work. Maybe a skype call, were share our thoughts, might be worth while at this stage. I think this is basically the same as having everything parented by core's pom. Indeed, the more I think about it, the more I am happy to go this way. I'm trying it out in a branch locally to see how it flies (ie testing to see if I release core and then if I can release one of the components). 3. Such numbering makes a lot of sense. And as you say a large number is just a large number. Ok, that's three of us in agreement. It might be worthwhile doing a formal vote on this one; perhaps in a day or two. Regards Rob On 12/10/12 20:17, Dan Haywood wrote: All, Following on from the previous discussion thread relating to renaming of artifacts etc, I've been doing some further work on the release process, up to and including have now pushed our isis-core up to the Nexus staging repo. Won't be calling a vote, just wanted to see if it all worked using git (which it does, after a few modifications). Anyway, we have a few alternatives in some of the detail; if you have an opinion on any of this, please respond... 1. artifactId names: eg isis-jdo-objectstore vs isis-objectstore-jdo This point came up in the previous thread, and at the time I was ambivalent as to which way we went on it. Now, though, I think we should use the reverse polish notation, ie isis-objectstore-jdo. The reason is mostly this: if a developer imports the entire project from the root aggregator pom (oai:isis-all) into Eclipse, then the project name will (by default at least) be based on the artifactId. This means that artifacts appear pretty randomly in the Eclipse workspace. Of course, the same argument applies if listing a directory, eg ls WEB-INF/lib. Opinions? 2. Should our releasable modules (core and each of the 20-ish components) have a separate org.apache.isis:isis-parent as their parent (which defines the maven-release-plugin configuration etc), or should they all use org.apache.isis.core:isis as their parent. The benefit of the former (and the code is mostly organized this way) is that, well, it seems to follow what many other maven projects do. But the downside is that we would need to release this isis-parent artifact first, and we might tend to forget about it and not update it. The benefit of the latter is we will always re-release it whenever there is a new release of core, and - as a bonus - all the child modules will inherit version definitions by way of dependencyManagement. Put another way: do we think that the lifecycle of our release process itself be decoupled from the lifecycle of releases of Isis core? If yes, we
Re: [DISCUSSION] Release process - fine tuning
1. After having imported the new source into our project I find too that artifacts are now not logically ordered and prefer an analogy with the project hierarchy (org.apache.isis.viewer.wicket - isis-viewer-wicket). For people working on an specific area (like sql) and would like to have all related projects side by side it might be an idea to use working sets in Eclipse (hence the name). 2. I don't have a strong opinion on this because I can't really tell what's the most practical one. My gut feeling says using isis:core as a parent but I'm open to adopt other project's best practices. 3. Having read the semantic versioning article I strongly feel this is the way to go. Let's hit those numbers! -Jeroen On Mon, Dec 10, 2012 at 9:17 PM, Dan Haywood d...@haywood-associates.co.ukwrote: All, Following on from the previous discussion thread relating to renaming of artifacts etc, I've been doing some further work on the release process, up to and including have now pushed our isis-core up to the Nexus staging repo. Won't be calling a vote, just wanted to see if it all worked using git (which it does, after a few modifications). Anyway, we have a few alternatives in some of the detail; if you have an opinion on any of this, please respond... 1. artifactId names: eg isis-jdo-objectstore vs isis-objectstore-jdo This point came up in the previous thread, and at the time I was ambivalent as to which way we went on it. Now, though, I think we should use the reverse polish notation, ie isis-objectstore-jdo. The reason is mostly this: if a developer imports the entire project from the root aggregator pom (oai:isis-all) into Eclipse, then the project name will (by default at least) be based on the artifactId. This means that artifacts appear pretty randomly in the Eclipse workspace. Of course, the same argument applies if listing a directory, eg ls WEB-INF/lib. Opinions? 2. Should our releasable modules (core and each of the 20-ish components) have a separate org.apache.isis:isis-parent as their parent (which defines the maven-release-plugin configuration etc), or should they all use org.apache.isis.core:isis as their parent. The benefit of the former (and the code is mostly organized this way) is that, well, it seems to follow what many other maven projects do. But the downside is that we would need to release this isis-parent artifact first, and we might tend to forget about it and not update it. The benefit of the latter is we will always re-release it whenever there is a new release of core, and - as a bonus - all the child modules will inherit version definitions by way of dependencyManagement. Put another way: do we think that the lifecycle of our release process itself be decoupled from the lifecycle of releases of Isis core? If yes, we should have a separate org.apache.isis:isis-parent. If no, we should just use org.apache.isis.core:isis as the parent of all releasable modules. Opinions? 3. What should our version numbers be? This is quite a big one, possibly worth its own thread, but I was wondering if we should adopt semantic versioning [1]. Thus, this first release will be v1.0.0 of the core; any bug fixes would be 1.0.1, 1.0.2, any backwardly compatible enhancements (to the APIs) would be 1.1.0, 1.2.0, any breaking changes to the APIs would be 2.0.0, 3.0.0, etc. There's an argument that things aren't quite stable enough in core to do this; the counter argument is that they are just numbers; if we end up with isis-core v 12.0.0 in two years time because of a succession of breaking API changes, so what? Opinions? Thanks Dan PS: fyi, I'm hoping to be in a position to put a release out of isis core for voting by the end of this week or beginning of next, latest. [1] http://semver.org.
