very happy to go with that suggestion. And ditto for the profilestore and security, presumably.
On 12 December 2012 00:30, Robert Matthews <rmatth...@nakedobjects.org>wrote: > I was thinking about that too and thought that they are object stores etc > so that is fine (ie isis-objectstore-inmemory). But what about: > > isis-inmemory-objectstore -> isis-core-objectstore > > and so on as they are all basic/simple implementations. > > Rob > > > > On 12/12/12 00:23, Dan Haywood wrote: > >> On 12 December 2012 00:16, Robert Matthews <rmatth...@nakedobjects.org>** >> wrote: >> >> Do we want to achieve the same thing with the core modules? eg: >>> >>> isis-metamodel -> isis-core-metamodel >>> isis-runtime -> isis-core-runtime >>> >>> >>> Yeah, I had the same thought. Happy to do that. >> >> Per previous mails, core DOES after all need to include the inmemory >> objectstore, the inmemory profilestore and noop security, BECAUSE these >> are >> all referenced by the integtestsupport module. >> >> I don't have a problem with this. >> >> The question that arises is, what name to give these artifacts? >> >> isis-inmemory-objectstore -> isis-objectstore-inmemory (meaning it >> will group with the non-core objectstore components) >> OR >> isis-inmemory-objectstore -> isis-core-objectstore-inmemory (meaning >> it will group with other core components). >> >> I think I prefer the latter. But I could be persuaded either way. >> >> >> >> >> >> Rob >>> >>> >>> >>> On 12/11/12 23:55, Dan Haywood wrote: >>> >>> 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. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >
