Almost. Slight snag... we have the two bytecode impls in core. Are you happy with isis-core-bytecode-cglib and isis-core-bytecode-javassist?
On 12 December 2012 00:37, Robert Matthews <rmatth...@nakedobjects.org>wrote: > Absolutely. > > I think that should do for tonight. > > Rob > > > > On 12/12/12 00:33, Dan Haywood wrote: > >> 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. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >
