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. >>>>>> >>>>>> >>>>>> >>>>>> >
