On 11 December 2012 23:49, Robert Matthews <rmatth...@nakedobjects.org>wrote:
> 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. > > ok, good... perhaps I had misunderstood what you were saying earlier, but at any rate sounds like we're in agreement the same page now. So... for example, I'll rename: * isis-jdo-objectstore -> isis-objectstore-jdo. * isis-sql-objectstore -> isis-objectstore-sql. Dan > Rob > > > > On 12/11/12 23:36, Dan Haywood wrote: > >> On 11 December 2012 23:26, Robert Matthews <rmatth...@nakedobjects.org>** >> wrote: >> >> 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 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. >>>> >>>> >>>> >
