You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by Dan Haywood <da...@haywood-associates.co.uk> on 2012/12/01 14:40:30 UTC
Re: [DISCUSSION] Making releases easier and more frequent
On 30 November 2012 19:41, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
> Just to add my 2c
>
> +1 to the general idea
>
> If I understand correctly, it supports the idea of each module having its
> own version?
yes, that's the main idea.
> So if I (for example) take my time with the sql
> objectstore, its version number will remain low. So version number is a
> true indication of the (major) improvements behind each component?
>
We haven't talked about version numbering, that's perhaps for a different
thread. But, top of my head, I would suggest that if the core goes up as
0.4.0, 0.5.0, 0.6.0 etc, then I'd expect the other components to track
them, eg 0.3.0, 0.4.0, 0.5.0. If a component author wants to push out a
new feature that doesn't require a bumping of core, they could then go with
0.6.1, 0.6.2 etc.
But, as I say, don't want to get side-tracked by that point.... there's
probably lots of equally valid ways to deal with this.
> And not (like at present) each component / package / module has the
> same version, increasing with each release?
>
> As for the html-viewer.. I have one deployed application out there that
> is still using it.. so I would like to see it migrated into the new,
> renamed, format.
> Having said this - this application is also probably locked into the
> previous version of Isis (it has a custom objectstore that I can't migrate
> into the new format since the Oid changes were made), so maybe it
> doesn't matter if the html viewer is retired.
>
OK.
Thx
Dan
>
> Regards,
> Kevin
>
> On 30 Nov 2012 at 17:18, Dan Haywood wrote:
>
> > Yup, understood. I have now updated the wiki page [1], and the
> artifactIds
> > are pretty much identical to those you suggested in your mail of
> yesterday.
> > Check it out and let me know your thoughts...
> >
> > Dan
> > [1]
> >
> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
> >
> > On 30 November 2012 17:17, Robert Matthews <rmatthews@nakedobjects.org
> >wrote:
> >
> > > It's not about building the classpath - who'd want to do that - it's
> when
> > > you have to look at what's been added to the classpath. Only yesterday
> I
> > > was looking at the references for a project in Eclipse and, as Rafael
> says,
> > > it would have been easier if they were prefixed and hence grouped and I
> > > would have been able to see what I was looking for immediately.
> > >
> > > Rob
> > >
> > >
> > >
> > > On 11/30/12 16:31, Dan Haywood wrote:
> > >
> > >> Yeah, I understand. But does anyone today - especially for a
> framework
> > >> such as Isis that provides Maven archetypes - build up their
> classpath by
> > >> manually assembling jars in some sort of lib/ directory?
> > >>
> > >> I'm prepared to stand corrected, but it doesn't strike me as a
> > >> particularly
> > >> common use case. Maven, of course, builds the classpath by referring
> > >> directory to the jars in the local ~/.m2 repo.
> > >>
> > >> Dan
> > >>
> > >>
> > >> On 30 November 2012 16:23, Rafael Chaves <ra...@alphasimple.com>
> wrote:
> > >>
> > >> Dan,
> > >>>
> > >>> That is true for a repository - but I was referring to jars used in
> an
> > >>> *application*.
> > >>>
> > >>> Spring, Hibernate, Apache Commons, Restlet, Jackson, Camel, virtually
> > >>> every
> > >>> multi-artifact framework I use follows this approach. When I am
> looking
> > >>> at
> > >>> a directory with a hundred Jars trying to hunt down a specific jar
> from
> > >>> one
> > >>> of those libraries, I really appreciate they did so.
> > >>>
> > >>> Yeah, the example you mentioned takes the idea too far.
> > >>>
> > >>> Cheers,
> > >>>
> > >>> Rafael
> > >>>
> > >>> On Fri, Nov 30, 2012 at 8:14 AM, Dan Haywood
> > >>> <da...@haywood-associates.co.uk>**wrote:
> > >>>
> > >>> Hi Rafael,
> > >>>> hmm, not sure that's a very good motivation... the identity of a
> Maven
> > >>>>
> > >>> jar
> > >>>
> > >>>> is also the directory, ie the full path under ~/.m2/repository.
> > >>>>
> > >>>> Funnily enough, I was teaching a Maven course last week at a
> corporation
> > >>>> that shall remain nameless, and the developers there had Maven
> modules
> > >>>>
> > >>> with
> > >>>
> > >>>> a groupId of com.verybigcorp.foo.bar and an artifactId also of
> > >>>> com.verybigcorp.foo.bar. We decided that whoever chose that
> artifactId
> > >>>> hadn't understood that the identity of the artifact is the
> combination
> > >>>> of
> > >>>> the both (plus version, plus classifier), and had chosen artifactIds
> > >>>>
> > >>> based
> > >>>
> > >>>> on its use as the JAR name.
> > >>>>
> > >>>> Dan
> > >>>> ~~~~
> > >>>>
> > >>>> On 30 November 2012 16:06, Rafael Chaves <ra...@alphasimple.com>
> > >>>> wrote:
> > >>>>
> > >>>> The artifact id ends up by default being the jar name, right? If
> that
> > >>>>>
> > >>>> is
> > >>>
> > >>>> true, I'd go with an artifact name with a common prefix across
> > >>>>> all Isis artifacts (i.e. isis-dflt). Two benefits: people using
> Isis
> > >>>>>
> > >>>> have
> > >>>
> > >>>> an easy way of identifying the Isis jars among all the other Jars
> their
> > >>>>> application uses, and easily avoids collisions with other people's
> jar
> > >>>>> names.
> > >>>>>
> > >>>>> Cheers,
> > >>>>>
> > >>>>> Rafael
> > >>>>>
> > >>>>> On Fri, Nov 30, 2012 at 5:38 AM, Dan Haywood
> > >>>>> <da...@haywood-associates.co.uk>**wrote:
> > >>>>>
> > >>>>> OK, I've tried to pull together various opinions and updated the
> wiki
> > >>>>>>
> > >>>>> page
> > >>>>>
> > >>>>>> [1]
> > >>>>>>
> > >>>>>> - yes, to idea of independent, more granular releases
> > >>>>>> - yes, flatten the modules at least as an interim step
> > >>>>>> - also, rename the groupId/artifactId's
> > >>>>>> - break linkage so that separate modules so don't share common
> > >>>>>>
> > >>>>> parent
> > >>>>
> > >>>>> (ie are separate artifacts)
> > >>>>>> - perhaps... move the separate modules into their own git
> repos
> > >>>>>>
> > >>>>>> With respect to groupId/artifactId's, for those components (eg
> > >>>>>>
> > >>>>> objectstore,
> > >>>>>
> > >>>>>> security) where there are implementations both core and
> alternate, we
> > >>>>>>
> > >>>>> need
> > >>>>>
> > >>>>>> to decide between (eg):
> > >>>>>>
> > >>>>>> o.a.isis.core:objectstore-dflt
> > >>>>>> vs
> > >>>>>> o.a.isis.objectstore:dflt
> > >>>>>>
> > >>>>>> The former has the benefit that all the modules that come with
> core
> > >>>>>>
> > >>>>> have
> > >>>>
> > >>>>> a
> > >>>>>
> > >>>>>> common groupId; the latter has the benefit that all
> implementations,
> > >>>>>> irrespective of whether they are core or not, have the same
> groupId.
> > >>>>>>
> > >>>>> In
> > >>>>
> > >>>>> other words, does groupId represent a packaging, or does it
> represent
> > >>>>>> common functionality?
> > >>>>>>
> > >>>>>> In the wiki page shows, I've gone with the former. But I'm 50:50
> on
> > >>>>>>
> > >>>>> this
> > >>>>
> > >>>>> myself.
> > >>>>>>
> > >>>>>> ~~~
> > >>>>>> Buried on the wiki page are some further questions: whether to
> retire
> > >>>>>>
> > >>>>> the
> > >>>>
> > >>>>> html-viewer, the profilestore-xml, and the monitoring component.
> My
> > >>>>>> rationale for retiring html-viewer is that the wicket viewer is
> > >>>>>>
> > >>>>> similar
> > >>>
> > >>>> but
> > >>>>>
> > >>>>>> superior; I don't think profilestore-xml makes sense for webapp
> > >>>>>>
> > >>>>> viewers
> > >>>
> > >>>> (it
> > >>>>>
> > >>>>>> might have made sense for dnd viewer in client/server, but we've
> > >>>>>>
> > >>>>> already
> > >>>>
> > >>>>> removed remoting) ; and monitoring I think is a vestige of the
> > >>>>>>
> > >>>>> remoting
> > >>>
> > >>>> should also be removed. But we don't necessarily need to come to an
> > >>>>>> agreement on these points (though opinions would be good).
> > >>>>>>
> > >>>>>> Thanks, all
> > >>>>>> Dan
> > >>>>>>
> > >>>>>> [1]
> > >>>>>>
> > >>>>>>
> > >>>>>> https://cwiki.apache.org/**confluence/display/ISIS/Make+**
> > >>> releases+easier+and+more+**frequent<
> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
> >
> > >>>
> > >>
> > >
> >
>
>
> --
> Kevin Meyer, PhD, Pr.Sci.Nat
> KMZ P.O. Box 9822, Sharon Park, South Africa.
> Tel: +27 11 363 2001 Cell: +27 83 346 3045
>
>
>
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Errmmm... not sure why in my previous mail I said "the wiki page is now
gone"... it isn't.
What I meant to say is "the wiki page is updated ... again".
Sorry for the confusion.
Dan
On 3 December 2012 07:47, Dan Haywood <da...@haywood-associates.co.uk> wrote:
>
>
> On 2 December 2012 22:07, Robert Matthews <rm...@nakedobjects.org>wrote:
>
>> Some questions on the updated wiki page:-
>>
>
>
>
>
>>
>> 1) in the directory, why is 'unreleased' part of core - these are all
>> components.
>>
>
>
>
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Errmmm... not sure why in my previous mail I said "the wiki page is now
gone"... it isn't.
What I meant to say is "the wiki page is updated ... again".
Sorry for the confusion.
Dan
On 3 December 2012 07:47, Dan Haywood <da...@haywood-associates.co.uk> wrote:
>
>
> On 2 December 2012 22:07, Robert Matthews <rm...@nakedobjects.org>wrote:
>
>> Some questions on the updated wiki page:-
>>
>
>
>
>
>>
>> 1) in the directory, why is 'unreleased' part of core - these are all
>> components.
>>
>
>
>
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 2 December 2012 22:07, Robert Matthews <rm...@nakedobjects.org>wrote:
> Some questions on the updated wiki page:-
>
>
> 1) in the directory, why is 'unreleased' part of core - these are all
> components.
>
When you wrote this, the wiki page was out of date with latest discussions.
I've just updated it once more.
As you'll see, the wiki page is now gone; as you say, we simply have a list
of components, some of which will be released pretty quickly, some of which
may never be.
> 2) wouldn't all the top level poms (those for the components) be parented
> by something core in Isis (refering to "As noted above, all of the
> pom.xml's in these top-level directories are separately releaseable (have
> org.apache:apache as their parent).").
>
OK, that might be doable. Probably just need to be careful with its
naming: although this parent pom would be released as part of core, then
intention is that it can be used as the parent for any of the other
components.
I suggest something like "org.apache.isis:isis-parent".
> 3) is isis-sql-objectstore-tests-**common for different sql object stores
> or for different object stores generally. If not, could it refactored to
> cover both cases?
>
>
These are Kev's tests. I'd rather we develop the "tck" idea and have a set
of common tests for all component types (objectstores, security,
profilestores etc)
> Separately, I'll review the monitoring module. I created it at some point
> and need to see if it is still relevant, needs modernising or is now
> completely redundant.
>
> OK
> I'm still pondering the suggested structure, so I give my thoughts later.
>
Updated once more, as I say ... see the wiki page.
Dan
>
> Rob
>
>
>
> On 12/01/12 13:44, Dan Haywood wrote:
>
>> OK, so I've replied briefly to each of the most recent posts that Rob and
>> Kevin made, and I've now gone round the loop again with the wiki page.
>>
>> This time I've listed out each and every of the current modules, and
>> proposed how they could be moved around and in many cases amalgamated in
>> order to simplify and aid grokkability.
>>
>> I've also changed the artifactIds to go with (what seems generally
>> preferred) names such as isis-jdo-objectstore.
>>
>> Please check out the updated version of that wiki page [1] and let me know
>> your thoughts. It's important that we get this right (I don't want to
>> have
>> to do it all over in 3 months time!!!)
>>
>> Dan
>>
>> [1]
>> https://cwiki.apache.org/**confluence/display/ISIS/Make+**
>> releases+easier+and+more+**frequent<https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent>
>>
>>
>> ~~~~~~~
>>
>> On 1 December 2012 13:40, Dan Haywood <da...@haywood-associates.co.uk>
>> wrote:
>>
>>
>>> On 30 November 2012 19:41, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
>>>
>>> Just to add my 2c
>>>>
>>>> +1 to the general idea
>>>>
>>>> If I understand correctly, it supports the idea of each module having
>>>> its
>>>> own version?
>>>>
>>>
>>> yes, that's the main idea.
>>>
>>>
>>>
>>> So if I (for example) take my time with the sql
>>>> objectstore, its version number will remain low. So version number is a
>>>> true indication of the (major) improvements behind each component?
>>>>
>>>> We haven't talked about version numbering, that's perhaps for a
>>> different
>>> thread. But, top of my head, I would suggest that if the core goes up as
>>> 0.4.0, 0.5.0, 0.6.0 etc, then I'd expect the other components to track
>>> them, eg 0.3.0, 0.4.0, 0.5.0. If a component author wants to push out a
>>> new feature that doesn't require a bumping of core, they could then go
>>> with
>>> 0.6.1, 0.6.2 etc.
>>>
>>> But, as I say, don't want to get side-tracked by that point.... there's
>>> probably lots of equally valid ways to deal with this.
>>>
>>>
>>>
>>> And not (like at present) each component / package / module has the
>>>> same version, increasing with each release?
>>>>
>>>> As for the html-viewer.. I have one deployed application out there that
>>>> is still using it.. so I would like to see it migrated into the new,
>>>> renamed, format.
>>>> Having said this - this application is also probably locked into the
>>>> previous version of Isis (it has a custom objectstore that I can't
>>>> migrate
>>>> into the new format since the Oid changes were made), so maybe it
>>>> doesn't matter if the html viewer is retired.
>>>>
>>>> OK.
>>>
>>> Thx
>>> Dan
>>>
>>>
>>> Regards,
>>>> Kevin
>>>>
>>>> On 30 Nov 2012 at 17:18, Dan Haywood wrote:
>>>>
>>>> Yup, understood. I have now updated the wiki page [1], and the
>>>>>
>>>> artifactIds
>>>>
>>>>> are pretty much identical to those you suggested in your mail of
>>>>>
>>>> yesterday.
>>>>
>>>>> Check it out and let me know your thoughts...
>>>>>
>>>>> Dan
>>>>> [1]
>>>>>
>>>>> https://cwiki.apache.org/**confluence/display/ISIS/Make+**
>>>> releases+easier+and+more+**frequent<https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent>
>>>>
>>>>> On 30 November 2012 17:17, Robert Matthews <rmatthews@nakedobjects.org
>>>>> wrote:
>>>>>
>>>>> It's not about building the classpath - who'd want to do that - it's
>>>>>>
>>>>> when
>>>>
>>>>> you have to look at what's been added to the classpath. Only
>>>>>>
>>>>> yesterday I
>>>>
>>>>> was looking at the references for a project in Eclipse and, as Rafael
>>>>>>
>>>>> says,
>>>>
>>>>> it would have been easier if they were prefixed and hence grouped and
>>>>>>
>>>>> I
>>>>
>>>>> would have been able to see what I was looking for immediately.
>>>>>>
>>>>>> Rob
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 11/30/12 16:31, Dan Haywood wrote:
>>>>>>
>>>>>> Yeah, I understand. But does anyone today - especially for a
>>>>>>>
>>>>>> framework
>>>>
>>>>> such as Isis that provides Maven archetypes - build up their
>>>>>>>
>>>>>> classpath by
>>>>
>>>>> manually assembling jars in some sort of lib/ directory?
>>>>>>>
>>>>>>> I'm prepared to stand corrected, but it doesn't strike me as a
>>>>>>> particularly
>>>>>>> common use case. Maven, of course, builds the classpath by referring
>>>>>>> directory to the jars in the local ~/.m2 repo.
>>>>>>>
>>>>>>> Dan
>>>>>>>
>>>>>>>
>>>>>>> On 30 November 2012 16:23, Rafael Chaves <ra...@alphasimple.com>
>>>>>>>
>>>>>> wrote:
>>>>
>>>>> Dan,
>>>>>>>
>>>>>>>> That is true for a repository - but I was referring to jars used in
>>>>>>>>
>>>>>>> an
>>>>
>>>>> *application*.
>>>>>>>>
>>>>>>>> Spring, Hibernate, Apache Commons, Restlet, Jackson, Camel,
>>>>>>>>
>>>>>>> virtually
>>>>
>>>>> every
>>>>>>>> multi-artifact framework I use follows this approach. When I am
>>>>>>>>
>>>>>>> looking
>>>>
>>>>> at
>>>>>>>> a directory with a hundred Jars trying to hunt down a specific jar
>>>>>>>>
>>>>>>> from
>>>>
>>>>> one
>>>>>>>> of those libraries, I really appreciate they did so.
>>>>>>>>
>>>>>>>> Yeah, the example you mentioned takes the idea too far.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Rafael
>>>>>>>>
>>>>>>>> On Fri, Nov 30, 2012 at 8:14 AM, Dan Haywood
>>>>>>>> <da...@haywood-associates.co.uk>****wrote:
>>>>>>>>
>>>>>>>> Hi Rafael,
>>>>>>>>
>>>>>>>>> hmm, not sure that's a very good motivation... the identity of a
>>>>>>>>>
>>>>>>>> Maven
>>>>
>>>>> jar
>>>>>>>>
>>>>>>>> is also the directory, ie the full path under ~/.m2/repository.
>>>>>>>>>
>>>>>>>>> Funnily enough, I was teaching a Maven course last week at a
>>>>>>>>>
>>>>>>>> corporation
>>>>
>>>>> that shall remain nameless, and the developers there had Maven
>>>>>>>>>
>>>>>>>> modules
>>>>
>>>>> with
>>>>>>>>
>>>>>>>> a groupId of com.verybigcorp.foo.bar and an artifactId also of
>>>>>>>>> com.verybigcorp.foo.bar. We decided that whoever chose that
>>>>>>>>>
>>>>>>>> artifactId
>>>>
>>>>> hadn't understood that the identity of the artifact is the
>>>>>>>>>
>>>>>>>> combination
>>>>
>>>>> of
>>>>>>>>> the both (plus version, plus classifier), and had chosen
>>>>>>>>>
>>>>>>>> artifactIds
>>>>
>>>>> based
>>>>>>>>
>>>>>>>> on its use as the JAR name.
>>>>>>>>>
>>>>>>>>> Dan
>>>>>>>>> ~~~~
>>>>>>>>>
>>>>>>>>> On 30 November 2012 16:06, Rafael Chaves <ra...@alphasimple.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> The artifact id ends up by default being the jar name, right? If
>>>>>>>>>
>>>>>>>> that
>>>>
>>>>> is
>>>>>>>>> true, I'd go with an artifact name with a common prefix across
>>>>>>>>>
>>>>>>>>>> all Isis artifacts (i.e. isis-dflt). Two benefits: people using
>>>>>>>>>>
>>>>>>>>> Isis
>>>>
>>>>> have
>>>>>>>>> an easy way of identifying the Isis jars among all the other Jars
>>>>>>>>>
>>>>>>>> their
>>>>
>>>>> application uses, and easily avoids collisions with other
>>>>>>>>>>
>>>>>>>>> people's jar
>>>>
>>>>> names.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>>
>>>>>>>>>> Rafael
>>>>>>>>>>
>>>>>>>>>> On Fri, Nov 30, 2012 at 5:38 AM, Dan Haywood
>>>>>>>>>> <da...@haywood-associates.co.uk>****wrote:
>>>>>>>>>>
>>>>>>>>>> OK, I've tried to pull together various opinions and updated the
>>>>>>>>>>
>>>>>>>>> wiki
>>>>
>>>>> page
>>>>>>>>>>
>>>>>>>>>> [1]
>>>>>>>>>>>
>>>>>>>>>>> - yes, to idea of independent, more granular releases
>>>>>>>>>>> - yes, flatten the modules at least as an interim step
>>>>>>>>>>> - also, rename the groupId/artifactId's
>>>>>>>>>>> - break linkage so that separate modules so don't share
>>>>>>>>>>>
>>>>>>>>>> common
>>>>
>>>>> parent
>>>>>>>>>> (ie are separate artifacts)
>>>>>>>>>>
>>>>>>>>>>> - perhaps... move the separate modules into their own git
>>>>>>>>>>>
>>>>>>>>>> repos
>>>>
>>>>> With respect to groupId/artifactId's, for those components (eg
>>>>>>>>>>>
>>>>>>>>>>> objectstore,
>>>>>>>>>>
>>>>>>>>>> security) where there are implementations both core and
>>>>>>>>>>>
>>>>>>>>>> alternate, we
>>>>
>>>>> need
>>>>>>>>>>
>>>>>>>>>> to decide between (eg):
>>>>>>>>>>>
>>>>>>>>>>> o.a.isis.core:objectstore-dflt
>>>>>>>>>>> vs
>>>>>>>>>>> o.a.isis.objectstore:dflt
>>>>>>>>>>>
>>>>>>>>>>> The former has the benefit that all the modules that come with
>>>>>>>>>>>
>>>>>>>>>> core
>>>>
>>>>> have
>>>>>>>>>> a
>>>>>>>>>>
>>>>>>>>>> common groupId; the latter has the benefit that all
>>>>>>>>>>>
>>>>>>>>>> implementations,
>>>>
>>>>> irrespective of whether they are core or not, have the same
>>>>>>>>>>>
>>>>>>>>>> groupId.
>>>>
>>>>> In
>>>>>>>>>> other words, does groupId represent a packaging, or does it
>>>>>>>>>>
>>>>>>>>> represent
>>>>
>>>>> common functionality?
>>>>>>>>>>>
>>>>>>>>>>> In the wiki page shows, I've gone with the former. But I'm
>>>>>>>>>>>
>>>>>>>>>> 50:50 on
>>>>
>>>>> this
>>>>>>>>>> myself.
>>>>>>>>>>
>>>>>>>>>>> ~~~
>>>>>>>>>>> Buried on the wiki page are some further questions: whether to
>>>>>>>>>>>
>>>>>>>>>> retire
>>>>
>>>>> the
>>>>>>>>>> html-viewer, the profilestore-xml, and the monitoring component.
>>>>>>>>>>
>>>>>>>>> My
>>>>
>>>>> rationale for retiring html-viewer is that the wicket viewer is
>>>>>>>>>>>
>>>>>>>>>>> similar
>>>>>>>>>>
>>>>>>>>> but
>>>>>>>>>
>>>>>>>>>> superior; I don't think profilestore-xml makes sense for webapp
>>>>>>>>>>>
>>>>>>>>>>> viewers
>>>>>>>>>>
>>>>>>>>> (it
>>>>>>>>>
>>>>>>>>>> might have made sense for dnd viewer in client/server, but we've
>>>>>>>>>>>
>>>>>>>>>>> already
>>>>>>>>>> removed remoting) ; and monitoring I think is a vestige of the
>>>>>>>>>> remoting
>>>>>>>>>>
>>>>>>>>> should also be removed. But we don't necessarily need to come to
>>>>>>>>>
>>>>>>>> an
>>>>
>>>>> agreement on these points (though opinions would be good).
>>>>>>>>>>>
>>>>>>>>>>> Thanks, all
>>>>>>>>>>> Dan
>>>>>>>>>>>
>>>>>>>>>>> [1]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> https://cwiki.apache.org/****confluence/display/ISIS/Make+****<https://cwiki.apache.org/**confluence/display/ISIS/Make+**>
>>>>>>>>>>>
>>>>>>>>>> releases+easier+and+more+****frequent<
>>>>>>>>
>>>>>>> https://cwiki.apache.org/**confluence/display/ISIS/Make+**
>>>> releases+easier+and+more+**frequent<https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent>
>>>>
>>>> --
>>>> Kevin Meyer, PhD, Pr.Sci.Nat
>>>> KMZ P.O. Box 9822, Sharon Park, South Africa.
>>>> Tel: +27 11 363 2001 Cell: +27 83 346 3045
>>>>
>>>>
>>>>
>>>>
>
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 2 December 2012 22:07, Robert Matthews <rm...@nakedobjects.org>wrote:
> Some questions on the updated wiki page:-
>
>
> 1) in the directory, why is 'unreleased' part of core - these are all
> components.
>
When you wrote this, the wiki page was out of date with latest discussions.
I've just updated it once more.
As you'll see, the wiki page is now gone; as you say, we simply have a list
of components, some of which will be released pretty quickly, some of which
may never be.
> 2) wouldn't all the top level poms (those for the components) be parented
> by something core in Isis (refering to "As noted above, all of the
> pom.xml's in these top-level directories are separately releaseable (have
> org.apache:apache as their parent).").
>
OK, that might be doable. Probably just need to be careful with its
naming: although this parent pom would be released as part of core, then
intention is that it can be used as the parent for any of the other
components.
I suggest something like "org.apache.isis:isis-parent".
> 3) is isis-sql-objectstore-tests-**common for different sql object stores
> or for different object stores generally. If not, could it refactored to
> cover both cases?
>
>
These are Kev's tests. I'd rather we develop the "tck" idea and have a set
of common tests for all component types (objectstores, security,
profilestores etc)
> Separately, I'll review the monitoring module. I created it at some point
> and need to see if it is still relevant, needs modernising or is now
> completely redundant.
>
> OK
> I'm still pondering the suggested structure, so I give my thoughts later.
>
Updated once more, as I say ... see the wiki page.
Dan
>
> Rob
>
>
>
> On 12/01/12 13:44, Dan Haywood wrote:
>
>> OK, so I've replied briefly to each of the most recent posts that Rob and
>> Kevin made, and I've now gone round the loop again with the wiki page.
>>
>> This time I've listed out each and every of the current modules, and
>> proposed how they could be moved around and in many cases amalgamated in
>> order to simplify and aid grokkability.
>>
>> I've also changed the artifactIds to go with (what seems generally
>> preferred) names such as isis-jdo-objectstore.
>>
>> Please check out the updated version of that wiki page [1] and let me know
>> your thoughts. It's important that we get this right (I don't want to
>> have
>> to do it all over in 3 months time!!!)
>>
>> Dan
>>
>> [1]
>> https://cwiki.apache.org/**confluence/display/ISIS/Make+**
>> releases+easier+and+more+**frequent<https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent>
>>
>>
>> ~~~~~~~
>>
>> On 1 December 2012 13:40, Dan Haywood <da...@haywood-associates.co.uk>
>> wrote:
>>
>>
>>> On 30 November 2012 19:41, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
>>>
>>> Just to add my 2c
>>>>
>>>> +1 to the general idea
>>>>
>>>> If I understand correctly, it supports the idea of each module having
>>>> its
>>>> own version?
>>>>
>>>
>>> yes, that's the main idea.
>>>
>>>
>>>
>>> So if I (for example) take my time with the sql
>>>> objectstore, its version number will remain low. So version number is a
>>>> true indication of the (major) improvements behind each component?
>>>>
>>>> We haven't talked about version numbering, that's perhaps for a
>>> different
>>> thread. But, top of my head, I would suggest that if the core goes up as
>>> 0.4.0, 0.5.0, 0.6.0 etc, then I'd expect the other components to track
>>> them, eg 0.3.0, 0.4.0, 0.5.0. If a component author wants to push out a
>>> new feature that doesn't require a bumping of core, they could then go
>>> with
>>> 0.6.1, 0.6.2 etc.
>>>
>>> But, as I say, don't want to get side-tracked by that point.... there's
>>> probably lots of equally valid ways to deal with this.
>>>
>>>
>>>
>>> And not (like at present) each component / package / module has the
>>>> same version, increasing with each release?
>>>>
>>>> As for the html-viewer.. I have one deployed application out there that
>>>> is still using it.. so I would like to see it migrated into the new,
>>>> renamed, format.
>>>> Having said this - this application is also probably locked into the
>>>> previous version of Isis (it has a custom objectstore that I can't
>>>> migrate
>>>> into the new format since the Oid changes were made), so maybe it
>>>> doesn't matter if the html viewer is retired.
>>>>
>>>> OK.
>>>
>>> Thx
>>> Dan
>>>
>>>
>>> Regards,
>>>> Kevin
>>>>
>>>> On 30 Nov 2012 at 17:18, Dan Haywood wrote:
>>>>
>>>> Yup, understood. I have now updated the wiki page [1], and the
>>>>>
>>>> artifactIds
>>>>
>>>>> are pretty much identical to those you suggested in your mail of
>>>>>
>>>> yesterday.
>>>>
>>>>> Check it out and let me know your thoughts...
>>>>>
>>>>> Dan
>>>>> [1]
>>>>>
>>>>> https://cwiki.apache.org/**confluence/display/ISIS/Make+**
>>>> releases+easier+and+more+**frequent<https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent>
>>>>
>>>>> On 30 November 2012 17:17, Robert Matthews <rmatthews@nakedobjects.org
>>>>> wrote:
>>>>>
>>>>> It's not about building the classpath - who'd want to do that - it's
>>>>>>
>>>>> when
>>>>
>>>>> you have to look at what's been added to the classpath. Only
>>>>>>
>>>>> yesterday I
>>>>
>>>>> was looking at the references for a project in Eclipse and, as Rafael
>>>>>>
>>>>> says,
>>>>
>>>>> it would have been easier if they were prefixed and hence grouped and
>>>>>>
>>>>> I
>>>>
>>>>> would have been able to see what I was looking for immediately.
>>>>>>
>>>>>> Rob
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 11/30/12 16:31, Dan Haywood wrote:
>>>>>>
>>>>>> Yeah, I understand. But does anyone today - especially for a
>>>>>>>
>>>>>> framework
>>>>
>>>>> such as Isis that provides Maven archetypes - build up their
>>>>>>>
>>>>>> classpath by
>>>>
>>>>> manually assembling jars in some sort of lib/ directory?
>>>>>>>
>>>>>>> I'm prepared to stand corrected, but it doesn't strike me as a
>>>>>>> particularly
>>>>>>> common use case. Maven, of course, builds the classpath by referring
>>>>>>> directory to the jars in the local ~/.m2 repo.
>>>>>>>
>>>>>>> Dan
>>>>>>>
>>>>>>>
>>>>>>> On 30 November 2012 16:23, Rafael Chaves <ra...@alphasimple.com>
>>>>>>>
>>>>>> wrote:
>>>>
>>>>> Dan,
>>>>>>>
>>>>>>>> That is true for a repository - but I was referring to jars used in
>>>>>>>>
>>>>>>> an
>>>>
>>>>> *application*.
>>>>>>>>
>>>>>>>> Spring, Hibernate, Apache Commons, Restlet, Jackson, Camel,
>>>>>>>>
>>>>>>> virtually
>>>>
>>>>> every
>>>>>>>> multi-artifact framework I use follows this approach. When I am
>>>>>>>>
>>>>>>> looking
>>>>
>>>>> at
>>>>>>>> a directory with a hundred Jars trying to hunt down a specific jar
>>>>>>>>
>>>>>>> from
>>>>
>>>>> one
>>>>>>>> of those libraries, I really appreciate they did so.
>>>>>>>>
>>>>>>>> Yeah, the example you mentioned takes the idea too far.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Rafael
>>>>>>>>
>>>>>>>> On Fri, Nov 30, 2012 at 8:14 AM, Dan Haywood
>>>>>>>> <da...@haywood-associates.co.uk>****wrote:
>>>>>>>>
>>>>>>>> Hi Rafael,
>>>>>>>>
>>>>>>>>> hmm, not sure that's a very good motivation... the identity of a
>>>>>>>>>
>>>>>>>> Maven
>>>>
>>>>> jar
>>>>>>>>
>>>>>>>> is also the directory, ie the full path under ~/.m2/repository.
>>>>>>>>>
>>>>>>>>> Funnily enough, I was teaching a Maven course last week at a
>>>>>>>>>
>>>>>>>> corporation
>>>>
>>>>> that shall remain nameless, and the developers there had Maven
>>>>>>>>>
>>>>>>>> modules
>>>>
>>>>> with
>>>>>>>>
>>>>>>>> a groupId of com.verybigcorp.foo.bar and an artifactId also of
>>>>>>>>> com.verybigcorp.foo.bar. We decided that whoever chose that
>>>>>>>>>
>>>>>>>> artifactId
>>>>
>>>>> hadn't understood that the identity of the artifact is the
>>>>>>>>>
>>>>>>>> combination
>>>>
>>>>> of
>>>>>>>>> the both (plus version, plus classifier), and had chosen
>>>>>>>>>
>>>>>>>> artifactIds
>>>>
>>>>> based
>>>>>>>>
>>>>>>>> on its use as the JAR name.
>>>>>>>>>
>>>>>>>>> Dan
>>>>>>>>> ~~~~
>>>>>>>>>
>>>>>>>>> On 30 November 2012 16:06, Rafael Chaves <ra...@alphasimple.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> The artifact id ends up by default being the jar name, right? If
>>>>>>>>>
>>>>>>>> that
>>>>
>>>>> is
>>>>>>>>> true, I'd go with an artifact name with a common prefix across
>>>>>>>>>
>>>>>>>>>> all Isis artifacts (i.e. isis-dflt). Two benefits: people using
>>>>>>>>>>
>>>>>>>>> Isis
>>>>
>>>>> have
>>>>>>>>> an easy way of identifying the Isis jars among all the other Jars
>>>>>>>>>
>>>>>>>> their
>>>>
>>>>> application uses, and easily avoids collisions with other
>>>>>>>>>>
>>>>>>>>> people's jar
>>>>
>>>>> names.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>>
>>>>>>>>>> Rafael
>>>>>>>>>>
>>>>>>>>>> On Fri, Nov 30, 2012 at 5:38 AM, Dan Haywood
>>>>>>>>>> <da...@haywood-associates.co.uk>****wrote:
>>>>>>>>>>
>>>>>>>>>> OK, I've tried to pull together various opinions and updated the
>>>>>>>>>>
>>>>>>>>> wiki
>>>>
>>>>> page
>>>>>>>>>>
>>>>>>>>>> [1]
>>>>>>>>>>>
>>>>>>>>>>> - yes, to idea of independent, more granular releases
>>>>>>>>>>> - yes, flatten the modules at least as an interim step
>>>>>>>>>>> - also, rename the groupId/artifactId's
>>>>>>>>>>> - break linkage so that separate modules so don't share
>>>>>>>>>>>
>>>>>>>>>> common
>>>>
>>>>> parent
>>>>>>>>>> (ie are separate artifacts)
>>>>>>>>>>
>>>>>>>>>>> - perhaps... move the separate modules into their own git
>>>>>>>>>>>
>>>>>>>>>> repos
>>>>
>>>>> With respect to groupId/artifactId's, for those components (eg
>>>>>>>>>>>
>>>>>>>>>>> objectstore,
>>>>>>>>>>
>>>>>>>>>> security) where there are implementations both core and
>>>>>>>>>>>
>>>>>>>>>> alternate, we
>>>>
>>>>> need
>>>>>>>>>>
>>>>>>>>>> to decide between (eg):
>>>>>>>>>>>
>>>>>>>>>>> o.a.isis.core:objectstore-dflt
>>>>>>>>>>> vs
>>>>>>>>>>> o.a.isis.objectstore:dflt
>>>>>>>>>>>
>>>>>>>>>>> The former has the benefit that all the modules that come with
>>>>>>>>>>>
>>>>>>>>>> core
>>>>
>>>>> have
>>>>>>>>>> a
>>>>>>>>>>
>>>>>>>>>> common groupId; the latter has the benefit that all
>>>>>>>>>>>
>>>>>>>>>> implementations,
>>>>
>>>>> irrespective of whether they are core or not, have the same
>>>>>>>>>>>
>>>>>>>>>> groupId.
>>>>
>>>>> In
>>>>>>>>>> other words, does groupId represent a packaging, or does it
>>>>>>>>>>
>>>>>>>>> represent
>>>>
>>>>> common functionality?
>>>>>>>>>>>
>>>>>>>>>>> In the wiki page shows, I've gone with the former. But I'm
>>>>>>>>>>>
>>>>>>>>>> 50:50 on
>>>>
>>>>> this
>>>>>>>>>> myself.
>>>>>>>>>>
>>>>>>>>>>> ~~~
>>>>>>>>>>> Buried on the wiki page are some further questions: whether to
>>>>>>>>>>>
>>>>>>>>>> retire
>>>>
>>>>> the
>>>>>>>>>> html-viewer, the profilestore-xml, and the monitoring component.
>>>>>>>>>>
>>>>>>>>> My
>>>>
>>>>> rationale for retiring html-viewer is that the wicket viewer is
>>>>>>>>>>>
>>>>>>>>>>> similar
>>>>>>>>>>
>>>>>>>>> but
>>>>>>>>>
>>>>>>>>>> superior; I don't think profilestore-xml makes sense for webapp
>>>>>>>>>>>
>>>>>>>>>>> viewers
>>>>>>>>>>
>>>>>>>>> (it
>>>>>>>>>
>>>>>>>>>> might have made sense for dnd viewer in client/server, but we've
>>>>>>>>>>>
>>>>>>>>>>> already
>>>>>>>>>> removed remoting) ; and monitoring I think is a vestige of the
>>>>>>>>>> remoting
>>>>>>>>>>
>>>>>>>>> should also be removed. But we don't necessarily need to come to
>>>>>>>>>
>>>>>>>> an
>>>>
>>>>> agreement on these points (though opinions would be good).
>>>>>>>>>>>
>>>>>>>>>>> Thanks, all
>>>>>>>>>>> Dan
>>>>>>>>>>>
>>>>>>>>>>> [1]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> https://cwiki.apache.org/****confluence/display/ISIS/Make+****<https://cwiki.apache.org/**confluence/display/ISIS/Make+**>
>>>>>>>>>>>
>>>>>>>>>> releases+easier+and+more+****frequent<
>>>>>>>>
>>>>>>> https://cwiki.apache.org/**confluence/display/ISIS/Make+**
>>>> releases+easier+and+more+**frequent<https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent>
>>>>
>>>> --
>>>> Kevin Meyer, PhD, Pr.Sci.Nat
>>>> KMZ P.O. Box 9822, Sharon Park, South Africa.
>>>> Tel: +27 11 363 2001 Cell: +27 83 346 3045
>>>>
>>>>
>>>>
>>>>
>
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Robert Matthews <rm...@nakedobjects.org>.
Some questions on the updated wiki page:-
1) in the directory, why is 'unreleased' part of core - these are all
components.
2) wouldn't all the top level poms (those for the components) be
parented by something core in Isis (refering to "As noted above, all of
the pom.xml's in these top-level directories are separately releaseable
(have org.apache:apache as their parent).").
3) is isis-sql-objectstore-tests-common for different sql object stores
or for different object stores generally. If not, could it refactored to
cover both cases?
Separately, I'll review the monitoring module. I created it at some
point and need to see if it is still relevant, needs modernising or is
now completely redundant.
I'm still pondering the suggested structure, so I give my thoughts later.
Rob
On 12/01/12 13:44, Dan Haywood wrote:
> OK, so I've replied briefly to each of the most recent posts that Rob and
> Kevin made, and I've now gone round the loop again with the wiki page.
>
> This time I've listed out each and every of the current modules, and
> proposed how they could be moved around and in many cases amalgamated in
> order to simplify and aid grokkability.
>
> I've also changed the artifactIds to go with (what seems generally
> preferred) names such as isis-jdo-objectstore.
>
> Please check out the updated version of that wiki page [1] and let me know
> your thoughts. It's important that we get this right (I don't want to have
> to do it all over in 3 months time!!!)
>
> Dan
>
> [1]
> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
>
>
> ~~~~~~~
>
> On 1 December 2012 13:40, Dan Haywood <da...@haywood-associates.co.uk> wrote:
>
>>
>> On 30 November 2012 19:41, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
>>
>>> Just to add my 2c
>>>
>>> +1 to the general idea
>>>
>>> If I understand correctly, it supports the idea of each module having its
>>> own version?
>>
>> yes, that's the main idea.
>>
>>
>>
>>> So if I (for example) take my time with the sql
>>> objectstore, its version number will remain low. So version number is a
>>> true indication of the (major) improvements behind each component?
>>>
>> We haven't talked about version numbering, that's perhaps for a different
>> thread. But, top of my head, I would suggest that if the core goes up as
>> 0.4.0, 0.5.0, 0.6.0 etc, then I'd expect the other components to track
>> them, eg 0.3.0, 0.4.0, 0.5.0. If a component author wants to push out a
>> new feature that doesn't require a bumping of core, they could then go with
>> 0.6.1, 0.6.2 etc.
>>
>> But, as I say, don't want to get side-tracked by that point.... there's
>> probably lots of equally valid ways to deal with this.
>>
>>
>>
>>> And not (like at present) each component / package / module has the
>>> same version, increasing with each release?
>>>
>>> As for the html-viewer.. I have one deployed application out there that
>>> is still using it.. so I would like to see it migrated into the new,
>>> renamed, format.
>>> Having said this - this application is also probably locked into the
>>> previous version of Isis (it has a custom objectstore that I can't migrate
>>> into the new format since the Oid changes were made), so maybe it
>>> doesn't matter if the html viewer is retired.
>>>
>> OK.
>>
>> Thx
>> Dan
>>
>>
>>> Regards,
>>> Kevin
>>>
>>> On 30 Nov 2012 at 17:18, Dan Haywood wrote:
>>>
>>>> Yup, understood. I have now updated the wiki page [1], and the
>>> artifactIds
>>>> are pretty much identical to those you suggested in your mail of
>>> yesterday.
>>>> Check it out and let me know your thoughts...
>>>>
>>>> Dan
>>>> [1]
>>>>
>>> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
>>>> On 30 November 2012 17:17, Robert Matthews <rmatthews@nakedobjects.org
>>>> wrote:
>>>>
>>>>> It's not about building the classpath - who'd want to do that - it's
>>> when
>>>>> you have to look at what's been added to the classpath. Only
>>> yesterday I
>>>>> was looking at the references for a project in Eclipse and, as Rafael
>>> says,
>>>>> it would have been easier if they were prefixed and hence grouped and
>>> I
>>>>> would have been able to see what I was looking for immediately.
>>>>>
>>>>> Rob
>>>>>
>>>>>
>>>>>
>>>>> On 11/30/12 16:31, Dan Haywood wrote:
>>>>>
>>>>>> Yeah, I understand. But does anyone today - especially for a
>>> framework
>>>>>> such as Isis that provides Maven archetypes - build up their
>>> classpath by
>>>>>> manually assembling jars in some sort of lib/ directory?
>>>>>>
>>>>>> I'm prepared to stand corrected, but it doesn't strike me as a
>>>>>> particularly
>>>>>> common use case. Maven, of course, builds the classpath by referring
>>>>>> directory to the jars in the local ~/.m2 repo.
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>> On 30 November 2012 16:23, Rafael Chaves <ra...@alphasimple.com>
>>> wrote:
>>>>>> Dan,
>>>>>>> That is true for a repository - but I was referring to jars used in
>>> an
>>>>>>> *application*.
>>>>>>>
>>>>>>> Spring, Hibernate, Apache Commons, Restlet, Jackson, Camel,
>>> virtually
>>>>>>> every
>>>>>>> multi-artifact framework I use follows this approach. When I am
>>> looking
>>>>>>> at
>>>>>>> a directory with a hundred Jars trying to hunt down a specific jar
>>> from
>>>>>>> one
>>>>>>> of those libraries, I really appreciate they did so.
>>>>>>>
>>>>>>> Yeah, the example you mentioned takes the idea too far.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Rafael
>>>>>>>
>>>>>>> On Fri, Nov 30, 2012 at 8:14 AM, Dan Haywood
>>>>>>> <da...@haywood-associates.co.uk>**wrote:
>>>>>>>
>>>>>>> Hi Rafael,
>>>>>>>> hmm, not sure that's a very good motivation... the identity of a
>>> Maven
>>>>>>> jar
>>>>>>>
>>>>>>>> is also the directory, ie the full path under ~/.m2/repository.
>>>>>>>>
>>>>>>>> Funnily enough, I was teaching a Maven course last week at a
>>> corporation
>>>>>>>> that shall remain nameless, and the developers there had Maven
>>> modules
>>>>>>> with
>>>>>>>
>>>>>>>> a groupId of com.verybigcorp.foo.bar and an artifactId also of
>>>>>>>> com.verybigcorp.foo.bar. We decided that whoever chose that
>>> artifactId
>>>>>>>> hadn't understood that the identity of the artifact is the
>>> combination
>>>>>>>> of
>>>>>>>> the both (plus version, plus classifier), and had chosen
>>> artifactIds
>>>>>>> based
>>>>>>>
>>>>>>>> on its use as the JAR name.
>>>>>>>>
>>>>>>>> Dan
>>>>>>>> ~~~~
>>>>>>>>
>>>>>>>> On 30 November 2012 16:06, Rafael Chaves <ra...@alphasimple.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> The artifact id ends up by default being the jar name, right? If
>>> that
>>>>>>>> is
>>>>>>>> true, I'd go with an artifact name with a common prefix across
>>>>>>>>> all Isis artifacts (i.e. isis-dflt). Two benefits: people using
>>> Isis
>>>>>>>> have
>>>>>>>> an easy way of identifying the Isis jars among all the other Jars
>>> their
>>>>>>>>> application uses, and easily avoids collisions with other
>>> people's jar
>>>>>>>>> names.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>>
>>>>>>>>> Rafael
>>>>>>>>>
>>>>>>>>> On Fri, Nov 30, 2012 at 5:38 AM, Dan Haywood
>>>>>>>>> <da...@haywood-associates.co.uk>**wrote:
>>>>>>>>>
>>>>>>>>> OK, I've tried to pull together various opinions and updated the
>>> wiki
>>>>>>>>> page
>>>>>>>>>
>>>>>>>>>> [1]
>>>>>>>>>>
>>>>>>>>>> - yes, to idea of independent, more granular releases
>>>>>>>>>> - yes, flatten the modules at least as an interim step
>>>>>>>>>> - also, rename the groupId/artifactId's
>>>>>>>>>> - break linkage so that separate modules so don't share
>>> common
>>>>>>>>> parent
>>>>>>>>> (ie are separate artifacts)
>>>>>>>>>> - perhaps... move the separate modules into their own git
>>> repos
>>>>>>>>>> With respect to groupId/artifactId's, for those components (eg
>>>>>>>>>>
>>>>>>>>> objectstore,
>>>>>>>>>
>>>>>>>>>> security) where there are implementations both core and
>>> alternate, we
>>>>>>>>> need
>>>>>>>>>
>>>>>>>>>> to decide between (eg):
>>>>>>>>>>
>>>>>>>>>> o.a.isis.core:objectstore-dflt
>>>>>>>>>> vs
>>>>>>>>>> o.a.isis.objectstore:dflt
>>>>>>>>>>
>>>>>>>>>> The former has the benefit that all the modules that come with
>>> core
>>>>>>>>> have
>>>>>>>>> a
>>>>>>>>>
>>>>>>>>>> common groupId; the latter has the benefit that all
>>> implementations,
>>>>>>>>>> irrespective of whether they are core or not, have the same
>>> groupId.
>>>>>>>>> In
>>>>>>>>> other words, does groupId represent a packaging, or does it
>>> represent
>>>>>>>>>> common functionality?
>>>>>>>>>>
>>>>>>>>>> In the wiki page shows, I've gone with the former. But I'm
>>> 50:50 on
>>>>>>>>> this
>>>>>>>>> myself.
>>>>>>>>>> ~~~
>>>>>>>>>> Buried on the wiki page are some further questions: whether to
>>> retire
>>>>>>>>> the
>>>>>>>>> html-viewer, the profilestore-xml, and the monitoring component.
>>> My
>>>>>>>>>> rationale for retiring html-viewer is that the wicket viewer is
>>>>>>>>>>
>>>>>>>>> similar
>>>>>>>> but
>>>>>>>>>> superior; I don't think profilestore-xml makes sense for webapp
>>>>>>>>>>
>>>>>>>>> viewers
>>>>>>>> (it
>>>>>>>>>> might have made sense for dnd viewer in client/server, but we've
>>>>>>>>>>
>>>>>>>>> already
>>>>>>>>> removed remoting) ; and monitoring I think is a vestige of the
>>>>>>>>> remoting
>>>>>>>> should also be removed. But we don't necessarily need to come to
>>> an
>>>>>>>>>> agreement on these points (though opinions would be good).
>>>>>>>>>>
>>>>>>>>>> Thanks, all
>>>>>>>>>> Dan
>>>>>>>>>>
>>>>>>>>>> [1]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://cwiki.apache.org/**confluence/display/ISIS/Make+**
>>>>>>> releases+easier+and+more+**frequent<
>>> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
>>>
>>> --
>>> Kevin Meyer, PhD, Pr.Sci.Nat
>>> KMZ P.O. Box 9822, Sharon Park, South Africa.
>>> Tel: +27 11 363 2001 Cell: +27 83 346 3045
>>>
>>>
>>>
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Minto van der Sluis <mi...@xup.nl>.
+1
Sounds also very easy for a novice. Core is the engine and describes the
interfaces for components. The rest is components.
Regards,
Minto
Op 2-12-2012 16:44, Dan Haywood schreef:
> Hmm... I'm not sure myself on this point.
>
> If we expect that the typical route into the framework is via our
> archetypes, then we probably can keep the component implementations out of
> core. This isn't just the objectstore, also the profilestore and the two
> security components (authentication and authorization). After all, the
> whole point of archetypes is to preassemble selected components.
>
> On the other hand, if users don't use archetypes, then it's a lot of stuff
> to explain and have them assemble. It also means that we'd be routinely
> doing votes for the release of the in-memory object store or the no-op
> authentication manager (just to keep these simple components in sync with
> the releases of the core).
>
> On balance, I'm probably with you Kevin: keep all module implementations
> out of core and rely solely on archetypes as the entry point into the
> framework. This would mean that the directory structure you suggest works.
>
>
> Still interested in more opinions on this thread. For example, does anyone
> have an objection to my amalgamating the various core submodules together,
> ditto the runtime submodules?
>
>
> On 2 December 2012 10:50, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
>
>> Just a quick response:
>>
>> It's really inconsistent, but perhaps inmemory * could be included in
>> core? As a "special case"..
>>
>> *shrug*
>>
>> Regards,
>> Kevin
>>
>>
>> On 2 Dec 2012 at 10:24, Dan Haywood wrote:
>>
>>> On 2 December 2012 10:13, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
>>>
>>>> To express my preferences:
>>>>
>>>> *) Have subdirectories for function, and help in grouping:
>>>> e.g.:
>>>> core/
>>>> security/
>>>> viewer/
>>>> objectstore/
>>>> inmemory
>>>> jdo
>>>> nosql
>>>> sql
>>>> ...
>>>>
>>>> likewise for viewers, security, etc...
>>>>
>>>> (I think it a little inconsistent to have "viewer-wicket" at the same
>>>> directory level as "core". I think "viewer" should be at the same
>> level as
>>>> "core", but there may be consequences that I am not aware of).
>>>>
>>>>
>>> The directory groupings aren't that significant for those components that
>>> are separately released (And, of course, if they move to their own git
>>> repos, then the issue is moot).
>>>
>>> However, putting inmemory-objectstore in this directory structure IS an
>>> issue, assuming that we want to have it as part of core. The reason is
>>> that I don't think that the <modules> tag in the parent pom can have an
>>> entry such as:
>>>
>>> <modules>
>>> <module>core</module>
>>> <module>runtime</module>
>>> <module>../objectstore/inmemory</module> <== not sure if this is
>> doable.
>>> ...
>>> </modules>
>>>
>>>
>>>
>>>> *) Have groupIds grouped by function (as proposed in the wiki
>>>> 2012/12/02 10h00 GMT):
>>>> o.a.i.viewer,*
>>>> o.a.i.objectstore.*
>>>>
>>>> ok, good
>>>
>>>
>>>> *) Have artifactIds gouped by technology (as proposed in the wiki
>>>> 2012/12/02 10h00 GMT (as proposed in the wiki 2012/12/02 10h00
>>>> GMT):
>>>> isis-jdo-*
>>>> isis-sql-*
>>>> isis-nosql-*
>>>>
>>>>
>>> ok, good ... a consensus is starting to emerge on this one
>>>
>>>
>>>> *) If I understand that git does not let you pull subdirectories, then
>> I
>>>> think I would prefer if git repositories were grouped by technology
>> (e.g.
>>>> "sql, jdo",etc for datastores (which would contain the security, etc
>>>> packages). Viewers, etc, are probably not affected, are they?
>>>> Progmodel - maybe, yes (groovy vs default (java)?).
>>>> This will let me ignore (e.g. jdo) for as long as I don't need it.
>> Please
>>>> also consider those who may still have to pay per MB, like I used to!
>> ;)
>>>>
>>> I thought about doing this, but I think a better solution if we are
>> worried
>>> about such things is to use separate git repos. Then people can just
>> pull
>>> down the repos that they want to work on. So, can we park this proposal
>>> for now?
>>>
>>> Thx for the input
>>> Dan
>>>
>>>
>>>
>>>
>>>
>>>> If some of my preferences have inconsistent consequences: e.g.
>>>> directory structure with separate git repositories, please point this
>> out
>>>> and I'll reconsider!!
>>>>
>>>> Regards,
>>>> Kevin
>>>>
>>
>>
>>
--
ir. ing. Minto van der Sluis
Software innovator / renovator
Xup BV
Mobiel: +31 (0) 626 014541
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 7 December 2012 08:54, Dan Haywood <da...@haywood-associates.co.uk> wrote:
>
>
> There was one issue that came up during this work, to do with
> oai.core:isis-integtestsupport module's dependencies. I'll comment on that
> in a separate post.
>
>
>
... so, let me comment on this here.
To back up a bit... the idea of integtestsupport is to allow the developer
to run up an instance of Isis within a unit test, with a minimum of effort.
This would use default components and allow alternative components - eg
security, objectstore, profilestore etc - to be substituted in.
For example, Jeroen is using this actively right now in testing Estatio
app. He runs the integration tests with the JDO objectstore, and then
exercises the domain application using the JDO repositories. It works
really well.
Anyway, back to the issue. The oai.core:isis-integtestsupport module
currently has dependencies on the inmemory objectstore, inmemory
profilestore and the noop security components: in order to be able to
instantiate Isis with aforesaid minimum of effort. As things stand, I've
moved these components back into core.
One thought I had was that we should actually move these default
implementations into the integtestsupport module itself? In other words,
other that for testing purposes I don't know that anyone would actually use
these components in a production system. I'm not 100% convinced myself
it's the right thing to do, but thought it worthy of mention.
There are two other alternatives: move integtestsupport out of core, or
alternatively, to require the developer to explicitly specify the
components it should use. Neither of these particularly appeals to me.
As a first pass, I'm going to keep these modules in core. None of this is
irreversible, so I'd rather just do the change and then we can evaluate
whether we like it or not.
Dan
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 7 December 2012 08:54, Dan Haywood <da...@haywood-associates.co.uk> wrote:
>
>
> There was one issue that came up during this work, to do with
> oai.core:isis-integtestsupport module's dependencies. I'll comment on that
> in a separate post.
>
>
>
... so, let me comment on this here.
To back up a bit... the idea of integtestsupport is to allow the developer
to run up an instance of Isis within a unit test, with a minimum of effort.
This would use default components and allow alternative components - eg
security, objectstore, profilestore etc - to be substituted in.
For example, Jeroen is using this actively right now in testing Estatio
app. He runs the integration tests with the JDO objectstore, and then
exercises the domain application using the JDO repositories. It works
really well.
Anyway, back to the issue. The oai.core:isis-integtestsupport module
currently has dependencies on the inmemory objectstore, inmemory
profilestore and the noop security components: in order to be able to
instantiate Isis with aforesaid minimum of effort. As things stand, I've
moved these components back into core.
One thought I had was that we should actually move these default
implementations into the integtestsupport module itself? In other words,
other that for testing purposes I don't know that anyone would actually use
these components in a production system. I'm not 100% convinced myself
it's the right thing to do, but thought it worthy of mention.
There are two other alternatives: move integtestsupport out of core, or
alternatively, to require the developer to explicitly specify the
components it should use. Neither of these particularly appeals to me.
As a first pass, I'm going to keep these modules in core. None of this is
irreversible, so I'd rather just do the change and then we can evaluate
whether we like it or not.
Dan
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 6 December 2012 19:00, Robert Matthews <rm...@nakedobjects.org>wrote:
> How do you propose we collaboratively work on this? I'm going to set some
> time aside for this, but I'm not sure how proceed safely.
>
>
Jeroen was over in the UK yesterday and again today, so he and I are
actually working through on this ... as you'll see from the commits I've
been pushing through.
The position as of this morning (Fri 7th Dec) is that we've moved all the
modules around into their correct directories (at least as defined in the
current wiki page), and we're about to start renaming the
groupId/artifactIds.
There was one issue that came up during this work, to do with
oai.core:isis-integtestsupport module's dependencies. I'll comment on that
in a separate post.
~~~
To your original question, the most valuable thing to do when you have time
is to check out the codebase and go through the actions of putting out a
release of - say - the scimpi and nosql components, (though without
actually doing so). The whole point of this exercise is to enable releases
easier to do, so that's the criteria to determine if we've got it right.
For example, I suspect that we'll need to configure the
supplemental-models.xml for each of the components, and the RAT tool, and
to make sure the release management profile stuff from org.apache:apache is
inherited correctly. I intend to do this for core and for the jdo, wicket
and restfulobjects components, so that'll be something to work from. But
I'm aware that I'm the only person who's had to grok all this stuff to date
- for example, there's the release key that you need to create [1] - so
there'll be a bit of a learning curve to go up.
Another thing we need to discuss is versioning strategy, eg whether to use
semantic versioning [2]. But that's probably a post for a different thread.
Dan
[1] http://isis.apache.org/contributors/key-generation.html
[2] http://semver.org
> Rob
>
>
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Robert Matthews <rm...@nakedobjects.org>.
How do you propose we collaboratively work on this? I'm going to set
some time aside for this, but I'm not sure how proceed safely.
Rob
On 12/05/12 08:09, Dan Haywood wrote:
> As we are, I think, getting close to consensus, and since there's a lot of
> refactoring to do, I've made a start on stuff where there's been no
> disagreement:
>
> * the core:common, core:metamodel, core:runtime, core:progmodel and
> progmodels:dflt artifacts have been merged into core:isis-metamodel
>
> * the runtimes.dflt:webapp has been merged into runtimes.dflt:runtime
>
> * the runtimes.dflt:webserver has been renamed runtimes.dflt:isis-webserver
>
> So, when you next do an git pull from the origin repo, please remove these
> projects. I recommend you also delete any isis artifacts under
> ~/.m2/repository/org/apache just to check all is building ok.
>
> Thx
> Dan
>
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
As we are, I think, getting close to consensus, and since there's a lot of
refactoring to do, I've made a start on stuff where there's been no
disagreement:
* the core:common, core:metamodel, core:runtime, core:progmodel and
progmodels:dflt artifacts have been merged into core:isis-metamodel
* the runtimes.dflt:webapp has been merged into runtimes.dflt:runtime
* the runtimes.dflt:webserver has been renamed runtimes.dflt:isis-webserver
So, when you next do an git pull from the origin repo, please remove these
projects. I recommend you also delete any isis artifacts under
~/.m2/repository/org/apache just to check all is building ok.
Thx
Dan
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
As we are, I think, getting close to consensus, and since there's a lot of
refactoring to do, I've made a start on stuff where there's been no
disagreement:
* the core:common, core:metamodel, core:runtime, core:progmodel and
progmodels:dflt artifacts have been merged into core:isis-metamodel
* the runtimes.dflt:webapp has been merged into runtimes.dflt:runtime
* the runtimes.dflt:webserver has been renamed runtimes.dflt:isis-webserver
So, when you next do an git pull from the origin repo, please remove these
projects. I recommend you also delete any isis artifacts under
~/.m2/repository/org/apache just to check all is building ok.
Thx
Dan
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 3 December 2012 23:00, Robert Matthews <rm...@nakedobjects.org>wrote:
> It's all looking clearer now. A few more points though:-
>
> slowly getting there...
> 1. I know Jeroen doesn't want to be petty, but I think we should be
> consistent with our grammatical numbering. I concur with Jeroen that they
> should all be singular (which fits with the group and artifact ids).
>
Updated wiki page, now singular.
>
> 2. The webserver module is not just for testing, it's generally applicable
> for containerless deployment. Many web apps make use of this allowing you
> run an app in an embedded Jetty instance, for example Jenkins allow this.
> Therefore it should be part of deployment, but as it depends on Jetty is
> should stay as a separate module.
>
Moved.
>
> 2. You state, Dan, "As the table indicates, I am now proposing that we
> move the unreleased artifacts into their own subdirectory. This will make
> them easier to exclude via a Maven profile." I'm not quite sure which
> modules you are referring to. If they are potential core modules then the
> profile statement makes sense, if they are components then I feel I am
> missing something about the build process. Which is it?
>
> That statement on the wiki page (referring to an 'unreleased'
subdirectory) was out of date.
Instead, I think what we're saying is simply: we have a bunch of
components; each of these is potentially separately releasable; we'll
document their release status/date clearly (indeed, I've already started
on this, see [1]).
I've updated the wiki page to this effect.
3. Has anybody used the version element of the dependency element
> sufficiently to have a concrete vision of how we might effectively use
> dependency version ranges to minimise component releases. Specifically, how
> will we ensure that a small change to the core modules will not require new
> versions of all the components.
>
My understanding is that version ranges are no longer encouraged in Maven,
even though they aren't officially deprecated. I can tell you that
DataNucleus (for JDO) does use version ranges, and it causes us a few
difficulties in places [2]
I'd rather we didn't use version ranges... if we did then it would require
us to lock down the core and maintain strict backward compatibility at all
times. This isn't a constraint I particularly want to impose on myself
just yet.
Rather, I see the process similar to the way I originally described it: one
of the committers wants to put out a new "edition" with the latest and
greatest of their components (Scimpi/NoSQL, say). This might have required
a few changes to core to support it.
The committer prepares several releases to be voted on: one for core, and
one for each of their components. The components refer to the exact
version of the core that they are compatible with.
If another committer wants to push out a release of their components for
this version of core, they can either co-ordinate with the first committer
or they can simply push out a release of their components at any time
thereafter the core release has gone through.
I'd like to suggest we at least start with the above process, and only
refine it if it doesn't work well enough for us?
>
> 4. Didn't Kevin say he was still using the HTML viewer? You still have it
> down for retirement.
>
>
I had thought the opposite, but I'm happy to keep it in for now. We can
assess all of the components in 18 months or so, say, to see which have
actually been released, and do a tidy up then if either Wicket or Scimpi
has fully replaced it.
To avoid confusion, I've updated the wiki page, removing this statement
about retiring this module.
> 5. Why are the basic implementations like isis-file-security and
> isis-inmemory-objectstore part of the org.apache.isis.core group, yet are
> placed outside the core directory. Surely these are just implementations
> and are not central to the framework. While they might typically be used
> initially it is up to the archetypes to declare that.
>
Again, this related to an earlier version when I was proposing these
components were bundled as part of core.
This is now fixed... as you say, their groupId should and does now relate
to the component type.
~~~
As I was updating the wiki, a few other things occurred to me that I want
to highlight:
* just to flag it: there are two exceptions to this idea that components
are released separately from core: (a) the default progmodel, and (b) the
identity bytecode. I don't have a problem with this, but yell if you do.
* I'd like to rename oai.core:isis-core to oai.core:isis-metamodel. Two
reasons: first, I always think of this stuff as mostly being about the
metamodel, and second, it'll disambiguate the word "core" to mean a set of
artifacts with "core" as their groupId, (rather than one particular
artifact within that groupId)
* I think the way in which we handle release process is to split the
current parent oai:isis pom into two:
- oai:isis-parent will be the *ultimate *parent of all modules, hence
will define release management confirmation, but will not be an
aggregagator (will have no <modules> element)
- oai.core:isis will be the aggregator for all the groupId=core
artifacts, ie it WILL have the <modules> element. Its parent will be
oai:isis-parent
* similarly, the other components will have their own analogous top-level
pom. For example, oai.viewer:isis-scimpi-viewer will be an aggregator that
will reference the isis-scimpi-viewer-dispatcher and
isis-scimpi-viewer-servlet artifacts via its <modules>, and will have
parented by oai:isis-parent.
Dan
> Regards
>
> Rob
>
>
[1] http://isis.apache.org/documentation.html
[2] http://isis.apache.org/components/objectstores/jdo/hints-and-tips.html
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 3 December 2012 23:00, Robert Matthews <rm...@nakedobjects.org>wrote:
> It's all looking clearer now. A few more points though:-
>
> slowly getting there...
> 1. I know Jeroen doesn't want to be petty, but I think we should be
> consistent with our grammatical numbering. I concur with Jeroen that they
> should all be singular (which fits with the group and artifact ids).
>
Updated wiki page, now singular.
>
> 2. The webserver module is not just for testing, it's generally applicable
> for containerless deployment. Many web apps make use of this allowing you
> run an app in an embedded Jetty instance, for example Jenkins allow this.
> Therefore it should be part of deployment, but as it depends on Jetty is
> should stay as a separate module.
>
Moved.
>
> 2. You state, Dan, "As the table indicates, I am now proposing that we
> move the unreleased artifacts into their own subdirectory. This will make
> them easier to exclude via a Maven profile." I'm not quite sure which
> modules you are referring to. If they are potential core modules then the
> profile statement makes sense, if they are components then I feel I am
> missing something about the build process. Which is it?
>
> That statement on the wiki page (referring to an 'unreleased'
subdirectory) was out of date.
Instead, I think what we're saying is simply: we have a bunch of
components; each of these is potentially separately releasable; we'll
document their release status/date clearly (indeed, I've already started
on this, see [1]).
I've updated the wiki page to this effect.
3. Has anybody used the version element of the dependency element
> sufficiently to have a concrete vision of how we might effectively use
> dependency version ranges to minimise component releases. Specifically, how
> will we ensure that a small change to the core modules will not require new
> versions of all the components.
>
My understanding is that version ranges are no longer encouraged in Maven,
even though they aren't officially deprecated. I can tell you that
DataNucleus (for JDO) does use version ranges, and it causes us a few
difficulties in places [2]
I'd rather we didn't use version ranges... if we did then it would require
us to lock down the core and maintain strict backward compatibility at all
times. This isn't a constraint I particularly want to impose on myself
just yet.
Rather, I see the process similar to the way I originally described it: one
of the committers wants to put out a new "edition" with the latest and
greatest of their components (Scimpi/NoSQL, say). This might have required
a few changes to core to support it.
The committer prepares several releases to be voted on: one for core, and
one for each of their components. The components refer to the exact
version of the core that they are compatible with.
If another committer wants to push out a release of their components for
this version of core, they can either co-ordinate with the first committer
or they can simply push out a release of their components at any time
thereafter the core release has gone through.
I'd like to suggest we at least start with the above process, and only
refine it if it doesn't work well enough for us?
>
> 4. Didn't Kevin say he was still using the HTML viewer? You still have it
> down for retirement.
>
>
I had thought the opposite, but I'm happy to keep it in for now. We can
assess all of the components in 18 months or so, say, to see which have
actually been released, and do a tidy up then if either Wicket or Scimpi
has fully replaced it.
To avoid confusion, I've updated the wiki page, removing this statement
about retiring this module.
> 5. Why are the basic implementations like isis-file-security and
> isis-inmemory-objectstore part of the org.apache.isis.core group, yet are
> placed outside the core directory. Surely these are just implementations
> and are not central to the framework. While they might typically be used
> initially it is up to the archetypes to declare that.
>
Again, this related to an earlier version when I was proposing these
components were bundled as part of core.
This is now fixed... as you say, their groupId should and does now relate
to the component type.
~~~
As I was updating the wiki, a few other things occurred to me that I want
to highlight:
* just to flag it: there are two exceptions to this idea that components
are released separately from core: (a) the default progmodel, and (b) the
identity bytecode. I don't have a problem with this, but yell if you do.
* I'd like to rename oai.core:isis-core to oai.core:isis-metamodel. Two
reasons: first, I always think of this stuff as mostly being about the
metamodel, and second, it'll disambiguate the word "core" to mean a set of
artifacts with "core" as their groupId, (rather than one particular
artifact within that groupId)
* I think the way in which we handle release process is to split the
current parent oai:isis pom into two:
- oai:isis-parent will be the *ultimate *parent of all modules, hence
will define release management confirmation, but will not be an
aggregagator (will have no <modules> element)
- oai.core:isis will be the aggregator for all the groupId=core
artifacts, ie it WILL have the <modules> element. Its parent will be
oai:isis-parent
* similarly, the other components will have their own analogous top-level
pom. For example, oai.viewer:isis-scimpi-viewer will be an aggregator that
will reference the isis-scimpi-viewer-dispatcher and
isis-scimpi-viewer-servlet artifacts via its <modules>, and will have
parented by oai:isis-parent.
Dan
> Regards
>
> Rob
>
>
[1] http://isis.apache.org/documentation.html
[2] http://isis.apache.org/components/objectstores/jdo/hints-and-tips.html
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Robert Matthews <rm...@nakedobjects.org>.
It's all looking clearer now. A few more points though:-
1. I know Jeroen doesn't want to be petty, but I think we should be
consistent with our grammatical numbering. I concur with Jeroen that
they should all be singular (which fits with the group and artifact ids).
2. The webserver module is not just for testing, it's generally
applicable for containerless deployment. Many web apps make use of this
allowing you run an app in an embedded Jetty instance, for example
Jenkins allow this. Therefore it should be part of deployment, but as it
depends on Jetty is should stay as a separate module.
2. You state, Dan, "As the table indicates, I am now proposing that we
move the unreleased artifacts into their own subdirectory. This will
make them easier to exclude via a Maven profile." I'm not quite sure
which modules you are referring to. If they are potential core modules
then the profile statement makes sense, if they are components then I
feel I am missing something about the build process. Which is it?
3. Has anybody used the version element of the dependency element
sufficiently to have a concrete vision of how we might effectively use
dependency version ranges to minimise component releases. Specifically,
how will we ensure that a small change to the core modules will not
require new versions of all the components.
4. Didn't Kevin say he was still using the HTML viewer? You still have
it down for retirement.
5. Why are the basic implementations like isis-file-security and
isis-inmemory-objectstore part of the org.apache.isis.core group, yet
are placed outside the core directory. Surely these are just
implementations and are not central to the framework. While they might
typically be used initially it is up to the archetypes to declare that.
Regards
Rob
On 12/02/12 21:06, Jeroen van der Wal wrote:
> Thanks Dan, I'm in.
>
> I could argue about the fact that I prefer to drop the extra folder level
> you added (core, components) and like singular over plural but that would
> make me a pettifogger ;-)
>
> -Jeroen
>
> There are still some parts of the source we haven't touched:
> - structure101
> - examples
> - domain-libs
> Should we catch that right away?
>
>
> On Sun, Dec 2, 2012 at 9:18 PM, Dan Haywood <da...@haywood-associates.co.uk>wrote:
>
>> On 2 December 2012 20:02, Robert Matthews <rmatthews@nakedobjects.org
>>> wrote:
>>> Dan,
>>>
>>> Can you be more explicit about the core and runtime submodules. There was
>>> an idea in there that there could be another way of building the core;
>>> would that be affected?
>>>
>> Not sure I follow, but let me try to summarize the proposals as concisely
>> as I can.
>>
>> The core consists of:
>>
>> oai.core:isis-core # the metamodel, plus
>> defining the main runtime APIs
>> oai.core:isis-cglib-bytecode # first of the two impls of
>> bytecode API, for use by objectstores
>> oai.core:isis-javassist-bytecode # second of the two impls of
>> bytecode API, for use by objectstores
>> oai.core:isis-runtime # the default runtime
>> impl
>> oai.core:isis-unittestsupport # used by other core modules,
>> with scope=test
>> oai.core:isis-integtestsupport # for use by tck and end-users,
>> with scope=test
>> oai.core:isis-webserver # for use by end-users in a
>> dev env
>>
>> (As Jeroen identified them), the runtime components are : isis-core,
>> isis-runtime, isis-xxx-bytecode, the remainder are for use in the
>> development environment.
>>
>> The above assumes that we don't bundle any default components for the
>> objectstore, security or viewer APIs.
>>
>> For the components outside the core are separately releasable (their parent
>> is org.apache:apache). In most cases these components will have
>> submodules. The components are:
>>
>> oia.viewer:isis-dnd-viewer
>> oia.viewer:isis-restfulobjects-viewer
>> oia.viewer:isis-scimpi-viewer
>> oia.viewer:isis-wicket-viewer
>>
>> oia.objectstore:isis-inmemory-objectstore
>> oia.objectstore:isis-jdo-objectstore
>> oia.objectstore:isis-nosql-objectstore
>> oia.objectstore:isis-sql-objectstore
>> oia.objectstore:isis-xml-objectstore
>>
>> oia.objectstore:isis-inmemory-profilestore
>> oia.objectstore:isis-xml-profilestore # not released in the
>> first event
>> oia.objectstore:isis-sql-profilestore # not released in the
>> first event
>>
>> oia.security:isis-noop-security # previously called 'dflt'
>> oia.security:isis-file-security
>> oia.security:isis-sql-security # not released in the first
>> event
>> oia.security:isis-ldap-security # not released in the first
>> event
>>
>> To be retired:
>> * oia.viewer:isis-html-viewer
>> * oia.core:isis-monitoring
>>
>> Finally, there will be archetypes:
>>
>> oai.archetypes:dnd-inmemory
>> oai.archetypes:scimpi-nosql
>> oai.archetypes:wicket-restful-jdo
>>
>> According to the reseach that Jeroen did, it seems feasible that we can
>> arrange the above into pretty much any directory structure we want. For
>> example:
>>
>> core/deployment/ # subdirs for: core, runtime, xxx-bytecode
>> core/development # subdirs for: xxxtestsupport, webserver
>>
>> components/viewers/ # subdirs for dnd, restful, scimpi, wicket,
>> components/objectstores/ # subdirs for inmemory, jdo, nosql, sql, xml
>> components/profilestores/ # subdirs for inmemory, xml, sql
>> components/security/ # subdirs for noop, ldap, sql
>>
>> archetypes/ # subdirs for each
>>
>>
>> Hope that helps pull everything together
>> Dan
>>
>>
>>
>>> Rob
>>>
>>>
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Jeroen van der Wal <je...@stromboli.it>.
Thanks Dan, I'm in.
I could argue about the fact that I prefer to drop the extra folder level
you added (core, components) and like singular over plural but that would
make me a pettifogger ;-)
-Jeroen
There are still some parts of the source we haven't touched:
- structure101
- examples
- domain-libs
Should we catch that right away?
On Sun, Dec 2, 2012 at 9:18 PM, Dan Haywood <da...@haywood-associates.co.uk>wrote:
> On 2 December 2012 20:02, Robert Matthews <rmatthews@nakedobjects.org
> >wrote:
>
> > Dan,
> >
> > Can you be more explicit about the core and runtime submodules. There was
> > an idea in there that there could be another way of building the core;
> > would that be affected?
> >
>
> Not sure I follow, but let me try to summarize the proposals as concisely
> as I can.
>
> The core consists of:
>
> oai.core:isis-core # the metamodel, plus
> defining the main runtime APIs
> oai.core:isis-cglib-bytecode # first of the two impls of
> bytecode API, for use by objectstores
> oai.core:isis-javassist-bytecode # second of the two impls of
> bytecode API, for use by objectstores
> oai.core:isis-runtime # the default runtime
> impl
> oai.core:isis-unittestsupport # used by other core modules,
> with scope=test
> oai.core:isis-integtestsupport # for use by tck and end-users,
> with scope=test
> oai.core:isis-webserver # for use by end-users in a
> dev env
>
> (As Jeroen identified them), the runtime components are : isis-core,
> isis-runtime, isis-xxx-bytecode, the remainder are for use in the
> development environment.
>
> The above assumes that we don't bundle any default components for the
> objectstore, security or viewer APIs.
>
> For the components outside the core are separately releasable (their parent
> is org.apache:apache). In most cases these components will have
> submodules. The components are:
>
> oia.viewer:isis-dnd-viewer
> oia.viewer:isis-restfulobjects-viewer
> oia.viewer:isis-scimpi-viewer
> oia.viewer:isis-wicket-viewer
>
> oia.objectstore:isis-inmemory-objectstore
> oia.objectstore:isis-jdo-objectstore
> oia.objectstore:isis-nosql-objectstore
> oia.objectstore:isis-sql-objectstore
> oia.objectstore:isis-xml-objectstore
>
> oia.objectstore:isis-inmemory-profilestore
> oia.objectstore:isis-xml-profilestore # not released in the
> first event
> oia.objectstore:isis-sql-profilestore # not released in the
> first event
>
> oia.security:isis-noop-security # previously called 'dflt'
> oia.security:isis-file-security
> oia.security:isis-sql-security # not released in the first
> event
> oia.security:isis-ldap-security # not released in the first
> event
>
> To be retired:
> * oia.viewer:isis-html-viewer
> * oia.core:isis-monitoring
>
> Finally, there will be archetypes:
>
> oai.archetypes:dnd-inmemory
> oai.archetypes:scimpi-nosql
> oai.archetypes:wicket-restful-jdo
>
> According to the reseach that Jeroen did, it seems feasible that we can
> arrange the above into pretty much any directory structure we want. For
> example:
>
> core/deployment/ # subdirs for: core, runtime, xxx-bytecode
> core/development # subdirs for: xxxtestsupport, webserver
>
> components/viewers/ # subdirs for dnd, restful, scimpi, wicket,
> components/objectstores/ # subdirs for inmemory, jdo, nosql, sql, xml
> components/profilestores/ # subdirs for inmemory, xml, sql
> components/security/ # subdirs for noop, ldap, sql
>
> archetypes/ # subdirs for each
>
>
> Hope that helps pull everything together
> Dan
>
>
>
> >
> > Rob
> >
> >
>
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 2 December 2012 20:02, Robert Matthews <rm...@nakedobjects.org>wrote:
> Dan,
>
> Can you be more explicit about the core and runtime submodules. There was
> an idea in there that there could be another way of building the core;
> would that be affected?
>
Not sure I follow, but let me try to summarize the proposals as concisely
as I can.
The core consists of:
oai.core:isis-core # the metamodel, plus
defining the main runtime APIs
oai.core:isis-cglib-bytecode # first of the two impls of
bytecode API, for use by objectstores
oai.core:isis-javassist-bytecode # second of the two impls of
bytecode API, for use by objectstores
oai.core:isis-runtime # the default runtime impl
oai.core:isis-unittestsupport # used by other core modules,
with scope=test
oai.core:isis-integtestsupport # for use by tck and end-users,
with scope=test
oai.core:isis-webserver # for use by end-users in a
dev env
(As Jeroen identified them), the runtime components are : isis-core,
isis-runtime, isis-xxx-bytecode, the remainder are for use in the
development environment.
The above assumes that we don't bundle any default components for the
objectstore, security or viewer APIs.
For the components outside the core are separately releasable (their parent
is org.apache:apache). In most cases these components will have
submodules. The components are:
oia.viewer:isis-dnd-viewer
oia.viewer:isis-restfulobjects-viewer
oia.viewer:isis-scimpi-viewer
oia.viewer:isis-wicket-viewer
oia.objectstore:isis-inmemory-objectstore
oia.objectstore:isis-jdo-objectstore
oia.objectstore:isis-nosql-objectstore
oia.objectstore:isis-sql-objectstore
oia.objectstore:isis-xml-objectstore
oia.objectstore:isis-inmemory-profilestore
oia.objectstore:isis-xml-profilestore # not released in the
first event
oia.objectstore:isis-sql-profilestore # not released in the
first event
oia.security:isis-noop-security # previously called 'dflt'
oia.security:isis-file-security
oia.security:isis-sql-security # not released in the first
event
oia.security:isis-ldap-security # not released in the first
event
To be retired:
* oia.viewer:isis-html-viewer
* oia.core:isis-monitoring
Finally, there will be archetypes:
oai.archetypes:dnd-inmemory
oai.archetypes:scimpi-nosql
oai.archetypes:wicket-restful-jdo
According to the reseach that Jeroen did, it seems feasible that we can
arrange the above into pretty much any directory structure we want. For
example:
core/deployment/ # subdirs for: core, runtime, xxx-bytecode
core/development # subdirs for: xxxtestsupport, webserver
components/viewers/ # subdirs for dnd, restful, scimpi, wicket,
components/objectstores/ # subdirs for inmemory, jdo, nosql, sql, xml
components/profilestores/ # subdirs for inmemory, xml, sql
components/security/ # subdirs for noop, ldap, sql
archetypes/ # subdirs for each
Hope that helps pull everything together
Dan
>
> Rob
>
>
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Robert Matthews <rm...@nakedobjects.org>.
Dan,
Can you be more explicit about the core and runtime submodules. There
was an idea in there that there could be another way of building the
core; would that be affected?
Rob
On 12/02/12 15:44, Dan Haywood wrote:
> Hmm... I'm not sure myself on this point.
>
> If we expect that the typical route into the framework is via our
> archetypes, then we probably can keep the component implementations out of
> core. This isn't just the objectstore, also the profilestore and the two
> security components (authentication and authorization). After all, the
> whole point of archetypes is to preassemble selected components.
>
> On the other hand, if users don't use archetypes, then it's a lot of stuff
> to explain and have them assemble. It also means that we'd be routinely
> doing votes for the release of the in-memory object store or the no-op
> authentication manager (just to keep these simple components in sync with
> the releases of the core).
>
> On balance, I'm probably with you Kevin: keep all module implementations
> out of core and rely solely on archetypes as the entry point into the
> framework. This would mean that the directory structure you suggest works.
>
>
> Still interested in more opinions on this thread. For example, does anyone
> have an objection to my amalgamating the various core submodules together,
> ditto the runtime submodules?
>
>
> On 2 December 2012 10:50, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
>
>> Just a quick response:
>>
>> It's really inconsistent, but perhaps inmemory * could be included in
>> core? As a "special case"..
>>
>> *shrug*
>>
>> Regards,
>> Kevin
>>
>>
>> On 2 Dec 2012 at 10:24, Dan Haywood wrote:
>>
>>> On 2 December 2012 10:13, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
>>>
>>>> To express my preferences:
>>>>
>>>> *) Have subdirectories for function, and help in grouping:
>>>> e.g.:
>>>> core/
>>>> security/
>>>> viewer/
>>>> objectstore/
>>>> inmemory
>>>> jdo
>>>> nosql
>>>> sql
>>>> ...
>>>>
>>>> likewise for viewers, security, etc...
>>>>
>>>> (I think it a little inconsistent to have "viewer-wicket" at the same
>>>> directory level as "core". I think "viewer" should be at the same
>> level as
>>>> "core", but there may be consequences that I am not aware of).
>>>>
>>>>
>>> The directory groupings aren't that significant for those components that
>>> are separately released (And, of course, if they move to their own git
>>> repos, then the issue is moot).
>>>
>>> However, putting inmemory-objectstore in this directory structure IS an
>>> issue, assuming that we want to have it as part of core. The reason is
>>> that I don't think that the <modules> tag in the parent pom can have an
>>> entry such as:
>>>
>>> <modules>
>>> <module>core</module>
>>> <module>runtime</module>
>>> <module>../objectstore/inmemory</module> <== not sure if this is
>> doable.
>>> ...
>>> </modules>
>>>
>>>
>>>
>>>> *) Have groupIds grouped by function (as proposed in the wiki
>>>> 2012/12/02 10h00 GMT):
>>>> o.a.i.viewer,*
>>>> o.a.i.objectstore.*
>>>>
>>>> ok, good
>>>
>>>
>>>> *) Have artifactIds gouped by technology (as proposed in the wiki
>>>> 2012/12/02 10h00 GMT (as proposed in the wiki 2012/12/02 10h00
>>>> GMT):
>>>> isis-jdo-*
>>>> isis-sql-*
>>>> isis-nosql-*
>>>>
>>>>
>>> ok, good ... a consensus is starting to emerge on this one
>>>
>>>
>>>> *) If I understand that git does not let you pull subdirectories, then
>> I
>>>> think I would prefer if git repositories were grouped by technology
>> (e.g.
>>>> "sql, jdo",etc for datastores (which would contain the security, etc
>>>> packages). Viewers, etc, are probably not affected, are they?
>>>> Progmodel - maybe, yes (groovy vs default (java)?).
>>>> This will let me ignore (e.g. jdo) for as long as I don't need it.
>> Please
>>>> also consider those who may still have to pay per MB, like I used to!
>> ;)
>>>>
>>> I thought about doing this, but I think a better solution if we are
>> worried
>>> about such things is to use separate git repos. Then people can just
>> pull
>>> down the repos that they want to work on. So, can we park this proposal
>>> for now?
>>>
>>> Thx for the input
>>> Dan
>>>
>>>
>>>
>>>
>>>
>>>> If some of my preferences have inconsistent consequences: e.g.
>>>> directory structure with separate git repositories, please point this
>> out
>>>> and I'll reconsider!!
>>>>
>>>> Regards,
>>>> Kevin
>>>>
>>
>>
>>
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Hmm... I'm not sure myself on this point.
If we expect that the typical route into the framework is via our
archetypes, then we probably can keep the component implementations out of
core. This isn't just the objectstore, also the profilestore and the two
security components (authentication and authorization). After all, the
whole point of archetypes is to preassemble selected components.
On the other hand, if users don't use archetypes, then it's a lot of stuff
to explain and have them assemble. It also means that we'd be routinely
doing votes for the release of the in-memory object store or the no-op
authentication manager (just to keep these simple components in sync with
the releases of the core).
On balance, I'm probably with you Kevin: keep all module implementations
out of core and rely solely on archetypes as the entry point into the
framework. This would mean that the directory structure you suggest works.
Still interested in more opinions on this thread. For example, does anyone
have an objection to my amalgamating the various core submodules together,
ditto the runtime submodules?
On 2 December 2012 10:50, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
> Just a quick response:
>
> It's really inconsistent, but perhaps inmemory * could be included in
> core? As a "special case"..
>
> *shrug*
>
> Regards,
> Kevin
>
>
> On 2 Dec 2012 at 10:24, Dan Haywood wrote:
>
> > On 2 December 2012 10:13, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
> >
> > > To express my preferences:
> > >
> > > *) Have subdirectories for function, and help in grouping:
> > > e.g.:
> > > core/
> > > security/
> > > viewer/
> > > objectstore/
> > > inmemory
> > > jdo
> > > nosql
> > > sql
> > > ...
> > >
> > > likewise for viewers, security, etc...
> > >
> > > (I think it a little inconsistent to have "viewer-wicket" at the same
> > > directory level as "core". I think "viewer" should be at the same
> level as
> > > "core", but there may be consequences that I am not aware of).
> > >
> > >
> > The directory groupings aren't that significant for those components that
> > are separately released (And, of course, if they move to their own git
> > repos, then the issue is moot).
> >
> > However, putting inmemory-objectstore in this directory structure IS an
> > issue, assuming that we want to have it as part of core. The reason is
> > that I don't think that the <modules> tag in the parent pom can have an
> > entry such as:
> >
> > <modules>
> > <module>core</module>
> > <module>runtime</module>
> > <module>../objectstore/inmemory</module> <== not sure if this is
> doable.
> > ...
> > </modules>
> >
> >
> >
> > > *) Have groupIds grouped by function (as proposed in the wiki
> > > 2012/12/02 10h00 GMT):
> > > o.a.i.viewer,*
> > > o.a.i.objectstore.*
> > >
> > > ok, good
> >
> >
> >
> > > *) Have artifactIds gouped by technology (as proposed in the wiki
> > > 2012/12/02 10h00 GMT (as proposed in the wiki 2012/12/02 10h00
> > > GMT):
> > > isis-jdo-*
> > > isis-sql-*
> > > isis-nosql-*
> > >
> > >
> > ok, good ... a consensus is starting to emerge on this one
> >
> >
> > > *) If I understand that git does not let you pull subdirectories, then
> I
> > > think I would prefer if git repositories were grouped by technology
> (e.g.
> > > "sql, jdo",etc for datastores (which would contain the security, etc
> > > packages). Viewers, etc, are probably not affected, are they?
> > > Progmodel - maybe, yes (groovy vs default (java)?).
> > > This will let me ignore (e.g. jdo) for as long as I don't need it.
> Please
> > > also consider those who may still have to pay per MB, like I used to!
> ;)
> > >
> > >
> > I thought about doing this, but I think a better solution if we are
> worried
> > about such things is to use separate git repos. Then people can just
> pull
> > down the repos that they want to work on. So, can we park this proposal
> > for now?
> >
> > Thx for the input
> > Dan
> >
> >
> >
> >
> >
> > > If some of my preferences have inconsistent consequences: e.g.
> > > directory structure with separate git repositories, please point this
> out
> > > and I'll reconsider!!
> > >
> > > Regards,
> > > Kevin
> > >
>
>
>
>
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Hmm... I'm not sure myself on this point.
If we expect that the typical route into the framework is via our
archetypes, then we probably can keep the component implementations out of
core. This isn't just the objectstore, also the profilestore and the two
security components (authentication and authorization). After all, the
whole point of archetypes is to preassemble selected components.
On the other hand, if users don't use archetypes, then it's a lot of stuff
to explain and have them assemble. It also means that we'd be routinely
doing votes for the release of the in-memory object store or the no-op
authentication manager (just to keep these simple components in sync with
the releases of the core).
On balance, I'm probably with you Kevin: keep all module implementations
out of core and rely solely on archetypes as the entry point into the
framework. This would mean that the directory structure you suggest works.
Still interested in more opinions on this thread. For example, does anyone
have an objection to my amalgamating the various core submodules together,
ditto the runtime submodules?
On 2 December 2012 10:50, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
> Just a quick response:
>
> It's really inconsistent, but perhaps inmemory * could be included in
> core? As a "special case"..
>
> *shrug*
>
> Regards,
> Kevin
>
>
> On 2 Dec 2012 at 10:24, Dan Haywood wrote:
>
> > On 2 December 2012 10:13, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
> >
> > > To express my preferences:
> > >
> > > *) Have subdirectories for function, and help in grouping:
> > > e.g.:
> > > core/
> > > security/
> > > viewer/
> > > objectstore/
> > > inmemory
> > > jdo
> > > nosql
> > > sql
> > > ...
> > >
> > > likewise for viewers, security, etc...
> > >
> > > (I think it a little inconsistent to have "viewer-wicket" at the same
> > > directory level as "core". I think "viewer" should be at the same
> level as
> > > "core", but there may be consequences that I am not aware of).
> > >
> > >
> > The directory groupings aren't that significant for those components that
> > are separately released (And, of course, if they move to their own git
> > repos, then the issue is moot).
> >
> > However, putting inmemory-objectstore in this directory structure IS an
> > issue, assuming that we want to have it as part of core. The reason is
> > that I don't think that the <modules> tag in the parent pom can have an
> > entry such as:
> >
> > <modules>
> > <module>core</module>
> > <module>runtime</module>
> > <module>../objectstore/inmemory</module> <== not sure if this is
> doable.
> > ...
> > </modules>
> >
> >
> >
> > > *) Have groupIds grouped by function (as proposed in the wiki
> > > 2012/12/02 10h00 GMT):
> > > o.a.i.viewer,*
> > > o.a.i.objectstore.*
> > >
> > > ok, good
> >
> >
> >
> > > *) Have artifactIds gouped by technology (as proposed in the wiki
> > > 2012/12/02 10h00 GMT (as proposed in the wiki 2012/12/02 10h00
> > > GMT):
> > > isis-jdo-*
> > > isis-sql-*
> > > isis-nosql-*
> > >
> > >
> > ok, good ... a consensus is starting to emerge on this one
> >
> >
> > > *) If I understand that git does not let you pull subdirectories, then
> I
> > > think I would prefer if git repositories were grouped by technology
> (e.g.
> > > "sql, jdo",etc for datastores (which would contain the security, etc
> > > packages). Viewers, etc, are probably not affected, are they?
> > > Progmodel - maybe, yes (groovy vs default (java)?).
> > > This will let me ignore (e.g. jdo) for as long as I don't need it.
> Please
> > > also consider those who may still have to pay per MB, like I used to!
> ;)
> > >
> > >
> > I thought about doing this, but I think a better solution if we are
> worried
> > about such things is to use separate git repos. Then people can just
> pull
> > down the repos that they want to work on. So, can we park this proposal
> > for now?
> >
> > Thx for the input
> > Dan
> >
> >
> >
> >
> >
> > > If some of my preferences have inconsistent consequences: e.g.
> > > directory structure with separate git repositories, please point this
> out
> > > and I'll reconsider!!
> > >
> > > Regards,
> > > Kevin
> > >
>
>
>
>
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Kevin Meyer - KMZ <ke...@kmz.co.za>.
Just a quick response:
It's really inconsistent, but perhaps inmemory * could be included in
core? As a "special case"..
*shrug*
Regards,
Kevin
On 2 Dec 2012 at 10:24, Dan Haywood wrote:
> On 2 December 2012 10:13, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
>
> > To express my preferences:
> >
> > *) Have subdirectories for function, and help in grouping:
> > e.g.:
> > core/
> > security/
> > viewer/
> > objectstore/
> > inmemory
> > jdo
> > nosql
> > sql
> > ...
> >
> > likewise for viewers, security, etc...
> >
> > (I think it a little inconsistent to have "viewer-wicket" at the same
> > directory level as "core". I think "viewer" should be at the same level as
> > "core", but there may be consequences that I am not aware of).
> >
> >
> The directory groupings aren't that significant for those components that
> are separately released (And, of course, if they move to their own git
> repos, then the issue is moot).
>
> However, putting inmemory-objectstore in this directory structure IS an
> issue, assuming that we want to have it as part of core. The reason is
> that I don't think that the <modules> tag in the parent pom can have an
> entry such as:
>
> <modules>
> <module>core</module>
> <module>runtime</module>
> <module>../objectstore/inmemory</module> <== not sure if this is doable.
> ...
> </modules>
>
>
>
> > *) Have groupIds grouped by function (as proposed in the wiki
> > 2012/12/02 10h00 GMT):
> > o.a.i.viewer,*
> > o.a.i.objectstore.*
> >
> > ok, good
>
>
>
> > *) Have artifactIds gouped by technology (as proposed in the wiki
> > 2012/12/02 10h00 GMT (as proposed in the wiki 2012/12/02 10h00
> > GMT):
> > isis-jdo-*
> > isis-sql-*
> > isis-nosql-*
> >
> >
> ok, good ... a consensus is starting to emerge on this one
>
>
> > *) If I understand that git does not let you pull subdirectories, then I
> > think I would prefer if git repositories were grouped by technology (e.g.
> > "sql, jdo",etc for datastores (which would contain the security, etc
> > packages). Viewers, etc, are probably not affected, are they?
> > Progmodel - maybe, yes (groovy vs default (java)?).
> > This will let me ignore (e.g. jdo) for as long as I don't need it. Please
> > also consider those who may still have to pay per MB, like I used to! ;)
> >
> >
> I thought about doing this, but I think a better solution if we are worried
> about such things is to use separate git repos. Then people can just pull
> down the repos that they want to work on. So, can we park this proposal
> for now?
>
> Thx for the input
> Dan
>
>
>
>
>
> > If some of my preferences have inconsistent consequences: e.g.
> > directory structure with separate git repositories, please point this out
> > and I'll reconsider!!
> >
> > Regards,
> > Kevin
> >
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 2 December 2012 10:13, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
> To express my preferences:
>
> *) Have subdirectories for function, and help in grouping:
> e.g.:
> core/
> security/
> viewer/
> objectstore/
> inmemory
> jdo
> nosql
> sql
> ...
>
> likewise for viewers, security, etc...
>
> (I think it a little inconsistent to have "viewer-wicket" at the same
> directory level as "core". I think "viewer" should be at the same level as
> "core", but there may be consequences that I am not aware of).
>
>
The directory groupings aren't that significant for those components that
are separately released (And, of course, if they move to their own git
repos, then the issue is moot).
However, putting inmemory-objectstore in this directory structure IS an
issue, assuming that we want to have it as part of core. The reason is
that I don't think that the <modules> tag in the parent pom can have an
entry such as:
<modules>
<module>core</module>
<module>runtime</module>
<module>../objectstore/inmemory</module> <== not sure if this is doable.
...
</modules>
> *) Have groupIds grouped by function (as proposed in the wiki
> 2012/12/02 10h00 GMT):
> o.a.i.viewer,*
> o.a.i.objectstore.*
>
> ok, good
> *) Have artifactIds gouped by technology (as proposed in the wiki
> 2012/12/02 10h00 GMT (as proposed in the wiki 2012/12/02 10h00
> GMT):
> isis-jdo-*
> isis-sql-*
> isis-nosql-*
>
>
ok, good ... a consensus is starting to emerge on this one
> *) If I understand that git does not let you pull subdirectories, then I
> think I would prefer if git repositories were grouped by technology (e.g.
> "sql, jdo",etc for datastores (which would contain the security, etc
> packages). Viewers, etc, are probably not affected, are they?
> Progmodel - maybe, yes (groovy vs default (java)?).
> This will let me ignore (e.g. jdo) for as long as I don't need it. Please
> also consider those who may still have to pay per MB, like I used to! ;)
>
>
I thought about doing this, but I think a better solution if we are worried
about such things is to use separate git repos. Then people can just pull
down the repos that they want to work on. So, can we park this proposal
for now?
Thx for the input
Dan
> If some of my preferences have inconsistent consequences: e.g.
> directory structure with separate git repositories, please point this out
> and I'll reconsider!!
>
> Regards,
> Kevin
>
> On 2 Dec 2012 at 1:18, Giovanni Júnior wrote:
>
> > +1, except that for question a) I prefer "isis-jdo-objectstore".
> >
> >
> > 2012/12/1 Jeroen van der Wal <je...@stromboli.it>
> >
> > > Wow, what a useful thread this is, thanks for all the contributions in
> > > unraveling Isis (at least for me)!
> > >
> > > I would go for option a.
> > >
> > > I even like to take it a step further and move out every component in
> core
> > > (released or not) into it's respective folder. For the JDO objectstore
> the
> > > groupId would org.apache.isis.objectstore and the artifactId isis-
> > > objectstore-jdo
> > >
> > > It's still hard for met to get why things are under core or not and
> what's
> > > used in every deployment (imho equals core) and what is used in
> > > development. Given that thought my ideal top-level folder layout would
> be
> > > something like this:
> > > core/
> > > applib
> > > bytecode-cglib
> > > bytecode-javassist
> > > core
> > > runtime
> > > development/
> > > tck
> > > unittestsupport
> > > integtestsupport
> > > webserver
> > > objectstore/
> > > inmemory
> > > jdo
> > > nosql
> > > sql
> > > xml
> > > profilestore/
> > > inmemory
> > > sql
> > > xml
> > > progmodel/
> > > java
> > > groovy
> > > wrapper
> > > security/
> > > ldap
> > > sql
> > > noop
> > > file
> > > viewer/
> > > bdd
> > > junit
> > > html
> > > dnd
> > > restfulobjects
> > > scimpi
> > > wicket
> > > archetype/
> > > dnd-xml
> > > scimpi-nosql
> > > wicket-restful-jdo
> > > retired/
> > > core/
> > > monitoring
> > >
> > > Still not sure if we need the retired folder though, releasing is all
> about
> > > picking the right combination of modules right?
> > >
> > > Cheers,
> > >
> > > Jeroen
> > >
>
> > > >
> > >
> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
>
>
>
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Kevin Meyer - KMZ <ke...@kmz.co.za>.
To express my preferences:
*) Have subdirectories for function, and help in grouping:
e.g.:
core/
security/
viewer/
objectstore/
inmemory
jdo
nosql
sql
...
likewise for viewers, security, etc...
(I think it a little inconsistent to have "viewer-wicket" at the same
directory level as "core". I think "viewer" should be at the same level as
"core", but there may be consequences that I am not aware of).
*) Have groupIds grouped by function (as proposed in the wiki
2012/12/02 10h00 GMT):
o.a.i.viewer,*
o.a.i.objectstore.*
*) Have artifactIds gouped by technology (as proposed in the wiki
2012/12/02 10h00 GMT (as proposed in the wiki 2012/12/02 10h00
GMT):
isis-jdo-*
isis-sql-*
isis-nosql-*
*) If I understand that git does not let you pull subdirectories, then I
think I would prefer if git repositories were grouped by technology (e.g.
"sql, jdo",etc for datastores (which would contain the security, etc
packages). Viewers, etc, are probably not affected, are they?
Progmodel - maybe, yes (groovy vs default (java)?).
This will let me ignore (e.g. jdo) for as long as I don't need it. Please
also consider those who may still have to pay per MB, like I used to! ;)
If some of my preferences have inconsistent consequences: e.g.
directory structure with separate git repositories, please point this out
and I'll reconsider!!
Regards,
Kevin
On 2 Dec 2012 at 1:18, Giovanni Júnior wrote:
> +1, except that for question a) I prefer "isis-jdo-objectstore".
>
>
> 2012/12/1 Jeroen van der Wal <je...@stromboli.it>
>
> > Wow, what a useful thread this is, thanks for all the contributions in
> > unraveling Isis (at least for me)!
> >
> > I would go for option a.
> >
> > I even like to take it a step further and move out every component in core
> > (released or not) into it's respective folder. For the JDO objectstore the
> > groupId would org.apache.isis.objectstore and the artifactId isis-
> > objectstore-jdo
> >
> > It's still hard for met to get why things are under core or not and what's
> > used in every deployment (imho equals core) and what is used in
> > development. Given that thought my ideal top-level folder layout would be
> > something like this:
> > core/
> > applib
> > bytecode-cglib
> > bytecode-javassist
> > core
> > runtime
> > development/
> > tck
> > unittestsupport
> > integtestsupport
> > webserver
> > objectstore/
> > inmemory
> > jdo
> > nosql
> > sql
> > xml
> > profilestore/
> > inmemory
> > sql
> > xml
> > progmodel/
> > java
> > groovy
> > wrapper
> > security/
> > ldap
> > sql
> > noop
> > file
> > viewer/
> > bdd
> > junit
> > html
> > dnd
> > restfulobjects
> > scimpi
> > wicket
> > archetype/
> > dnd-xml
> > scimpi-nosql
> > wicket-restful-jdo
> > retired/
> > core/
> > monitoring
> >
> > Still not sure if we need the retired folder though, releasing is all about
> > picking the right combination of modules right?
> >
> > Cheers,
> >
> > Jeroen
> >
> > >
> > https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Kevin Meyer - KMZ <ke...@kmz.co.za>.
To express my preferences:
*) Have subdirectories for function, and help in grouping:
e.g.:
core/
security/
viewer/
objectstore/
inmemory
jdo
nosql
sql
...
likewise for viewers, security, etc...
(I think it a little inconsistent to have "viewer-wicket" at the same
directory level as "core". I think "viewer" should be at the same level as
"core", but there may be consequences that I am not aware of).
*) Have groupIds grouped by function (as proposed in the wiki
2012/12/02 10h00 GMT):
o.a.i.viewer,*
o.a.i.objectstore.*
*) Have artifactIds gouped by technology (as proposed in the wiki
2012/12/02 10h00 GMT (as proposed in the wiki 2012/12/02 10h00
GMT):
isis-jdo-*
isis-sql-*
isis-nosql-*
*) If I understand that git does not let you pull subdirectories, then I
think I would prefer if git repositories were grouped by technology (e.g.
"sql, jdo",etc for datastores (which would contain the security, etc
packages). Viewers, etc, are probably not affected, are they?
Progmodel - maybe, yes (groovy vs default (java)?).
This will let me ignore (e.g. jdo) for as long as I don't need it. Please
also consider those who may still have to pay per MB, like I used to! ;)
If some of my preferences have inconsistent consequences: e.g.
directory structure with separate git repositories, please point this out
and I'll reconsider!!
Regards,
Kevin
On 2 Dec 2012 at 1:18, Giovanni Júnior wrote:
> +1, except that for question a) I prefer "isis-jdo-objectstore".
>
>
> 2012/12/1 Jeroen van der Wal <je...@stromboli.it>
>
> > Wow, what a useful thread this is, thanks for all the contributions in
> > unraveling Isis (at least for me)!
> >
> > I would go for option a.
> >
> > I even like to take it a step further and move out every component in core
> > (released or not) into it's respective folder. For the JDO objectstore the
> > groupId would org.apache.isis.objectstore and the artifactId isis-
> > objectstore-jdo
> >
> > It's still hard for met to get why things are under core or not and what's
> > used in every deployment (imho equals core) and what is used in
> > development. Given that thought my ideal top-level folder layout would be
> > something like this:
> > core/
> > applib
> > bytecode-cglib
> > bytecode-javassist
> > core
> > runtime
> > development/
> > tck
> > unittestsupport
> > integtestsupport
> > webserver
> > objectstore/
> > inmemory
> > jdo
> > nosql
> > sql
> > xml
> > profilestore/
> > inmemory
> > sql
> > xml
> > progmodel/
> > java
> > groovy
> > wrapper
> > security/
> > ldap
> > sql
> > noop
> > file
> > viewer/
> > bdd
> > junit
> > html
> > dnd
> > restfulobjects
> > scimpi
> > wicket
> > archetype/
> > dnd-xml
> > scimpi-nosql
> > wicket-restful-jdo
> > retired/
> > core/
> > monitoring
> >
> > Still not sure if we need the retired folder though, releasing is all about
> > picking the right combination of modules right?
> >
> > Cheers,
> >
> > Jeroen
> >
> > >
> > https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Giovanni Júnior <gi...@gmail.com>.
+1, except that for question a) I prefer "isis-jdo-objectstore".
2012/12/1 Jeroen van der Wal <je...@stromboli.it>
> Wow, what a useful thread this is, thanks for all the contributions in
> unraveling Isis (at least for me)!
>
> I would go for option a.
>
> I even like to take it a step further and move out every component in core
> (released or not) into it's respective folder. For the JDO objectstore the
> groupId would org.apache.isis.objectstore and the artifactId isis-
> objectstore-jdo
>
> It's still hard for met to get why things are under core or not and what's
> used in every deployment (imho equals core) and what is used in
> development. Given that thought my ideal top-level folder layout would be
> something like this:
> core/
> applib
> bytecode-cglib
> bytecode-javassist
> core
> runtime
> development/
> tck
> unittestsupport
> integtestsupport
> webserver
> objectstore/
> inmemory
> jdo
> nosql
> sql
> xml
> profilestore/
> inmemory
> sql
> xml
> progmodel/
> java
> groovy
> wrapper
> security/
> ldap
> sql
> noop
> file
> viewer/
> bdd
> junit
> html
> dnd
> restfulobjects
> scimpi
> wicket
> archetype/
> dnd-xml
> scimpi-nosql
> wicket-restful-jdo
> retired/
> core/
> monitoring
>
> Still not sure if we need the retired folder though, releasing is all about
> picking the right combination of modules right?
>
> Cheers,
>
> Jeroen
>
>
> On Sat, Dec 1, 2012 at 4:36 PM, Dan Haywood <dan@haywood-associates.co.uk
> >wrote:
>
> > On 1 December 2012 14:23, Minto van der Sluis <mi...@xup.nl> wrote:
> >
> > > >Hmm, I get confused by the artifactIds. I see both for formats
> > > (isis-viewer-bdd and isis-wicket-viewer).
> >
> >
> > ah, that was a typo. the intention for artifactIds was: isis-xxx-viewer,
> > isis-yyy-objectstore etc.
> >
> >
> > > I also see artifactIds with 4
> > > sections, for instance: isis-jdo-objectstore-metamodel. This confuses
> > > me. Is it an objectstore or a metamodel?
> >
> >
> > ok, well... some modules (in fact, most) have more than one component.
> And
> > I don't think we should insist that all modules have only one component.
> >
> > In this particular example, isis-jdo-objectstore-metamodel would be the
> > additional facet factories that are added to the metamodel that interpret
> > JDO-specific annotations. That is to distinguish from, say,
> > isis-jdo-objectstore-datanucleus, which is the stuff that calls the
> > DataNucleus' specific stuff.
> >
> > But there is similar layering in isis-scimpi-viewer,
> > isis-restfulobjects-viewer, isis-wicket-viewer, isis-sql-objectstore.
> >
> >
> > (isis-metamodel-jdo) Also is
> > > there really a difference between model and metamodel?
> > > (isis-jdo-objectstore-metamodel vs isis-wicket-viewer-model).
> > >
> >
> > Yes... there is (though even if there weren't, I'm not sure it matters
> too
> > much ... I'd rather give the authors of individual components/modules
> some
> > latitude in how they name the individual submodules. For example, scimpi
> > has isis-scimpi-dispatcher and isis-scimpi-servlet. Anyone who wants to
> > get involved in enhancing scimpi would grok these particular names and
> why
> > they were chosen easily enough)
> >
> > To answer your question, though... jdo's metamodel submodule is as
> > described above, its contributions to the Isis metamodel, whereas
> wicket's
> > model is Isis' implementation of Wicket's IModel interface.
> >
> >
> >
> > > By the way my preference here is isis-objectstore-jdo. For the same
> > > reason as for the proposed location (easy component grouping when
> > > viewing directory). In my own projects I usually have my directory
> > > location match my artifactIds.
> > >
> >
> > ok, so we now we have a couple of distinct and different preferences in
> > the community.
> >
> > Anyone else have an explicit preferences:
> > a) for the artifactId: isis-jdo-objectstore vs isis-objectstore-jdo
> > b) for whether artifactId = directory name
> >
> >
> > >
> > > Also, isis-scimpi-viewer needs some more attention.
> > >
> >
> > the artifactIds weren't correct ... now fixed
> >
> >
> > Thanks
> >
> > Dan
> >
> >
> >
> > > >
> > > > Please check out the updated version of that wiki page [1] and let me
> > > know
> > > > your thoughts. It's important that we get this right (I don't want
> to
> > > have
> > > > to do it all over in 3 months time!!!)
> > > >
> > > > Dan
> > > >
> > > > [1]
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
> > > >
> > > >
> > >
> > >
> >
>
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Jeroen van der Wal <je...@stromboli.it>.
It is possible in Maven to have parent and sub-modules on the same
directory level [1][2].
I agree that we could document better what modules are development only but
I'd rather invest some time in making our source code speak for it's self
instead of having to read a manual.
Cheers,
Jeroen
[1]
http://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Example_4
[2]
http://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Example_2
On Sun, Dec 2, 2012 at 4:53 PM, Dan Haywood <da...@haywood-associates.co.uk>wrote:
> Hi Jeroen,
> Just realized I did comment on your points here.
>
> With respect to the directory structure, it looks like you're saying
> similar things to Kevin who commented today (Sunday).
>
> You did make the point about distinguishing the development modules.
> There's the same potential issue as I made with Kevin's suggestion; I'm
> not sure that Maven modules can be in a different tree. In the parent pom
> it would need to say something like:
>
> <modules>
> <module>applib</module>
> <module>core</module>
> ...
> <module>../development/unittestsupport</module> <== not sure that this
> is allowed
> ..
> </modules>
>
> That said, I think you have correctly listed which modules are intended for
> development use only... maybe we just need to document this on our website
> more clearly?
>
> Dan
>
>
> On 1 December 2012 16:46, Jeroen van der Wal <je...@stromboli.it> wrote:
>
> > Wow, what a useful thread this is, thanks for all the contributions in
> > unraveling Isis (at least for me)!
> >
> > I would go for option a.
> >
> > I even like to take it a step further and move out every component in
> core
> > (released or not) into it's respective folder. For the JDO objectstore
> the
> > groupId would org.apache.isis.objectstore and the artifactId isis-
> > objectstore-jdo
> >
> > It's still hard for met to get why things are under core or not and
> what's
> > used in every deployment (imho equals core) and what is used in
> > development. Given that thought my ideal top-level folder layout would be
> > something like this:
> > core/
> > applib
> > bytecode-cglib
> > bytecode-javassist
> > core
> > runtime
> > development/
> > tck
> > unittestsupport
> > integtestsupport
> > webserver
> > objectstore/
> > inmemory
> > jdo
> > nosql
> > sql
> > xml
> > profilestore/
> > inmemory
> > sql
> > xml
> > progmodel/
> > java
> > groovy
> > wrapper
> > security/
> > ldap
> > sql
> > noop
> > file
> > viewer/
> > bdd
> > junit
> > html
> > dnd
> > restfulobjects
> > scimpi
> > wicket
> > archetype/
> > dnd-xml
> > scimpi-nosql
> > wicket-restful-jdo
> > retired/
> > core/
> > monitoring
> >
> > Still not sure if we need the retired folder though, releasing is all
> about
> > picking the right combination of modules right?
> >
> > Cheers,
> >
> > Jeroen
> >
> >
> > On Sat, Dec 1, 2012 at 4:36 PM, Dan Haywood <
> dan@haywood-associates.co.uk
> > >wrote:
> >
> > > On 1 December 2012 14:23, Minto van der Sluis <mi...@xup.nl> wrote:
> > >
> > > > >Hmm, I get confused by the artifactIds. I see both for formats
> > > > (isis-viewer-bdd and isis-wicket-viewer).
> > >
> > >
> > > ah, that was a typo. the intention for artifactIds was:
> isis-xxx-viewer,
> > > isis-yyy-objectstore etc.
> > >
> > >
> > > > I also see artifactIds with 4
> > > > sections, for instance: isis-jdo-objectstore-metamodel. This confuses
> > > > me. Is it an objectstore or a metamodel?
> > >
> > >
> > > ok, well... some modules (in fact, most) have more than one component.
> > And
> > > I don't think we should insist that all modules have only one
> component.
> > >
> > > In this particular example, isis-jdo-objectstore-metamodel would be the
> > > additional facet factories that are added to the metamodel that
> interpret
> > > JDO-specific annotations. That is to distinguish from, say,
> > > isis-jdo-objectstore-datanucleus, which is the stuff that calls the
> > > DataNucleus' specific stuff.
> > >
> > > But there is similar layering in isis-scimpi-viewer,
> > > isis-restfulobjects-viewer, isis-wicket-viewer, isis-sql-objectstore.
> > >
> > >
> > > (isis-metamodel-jdo) Also is
> > > > there really a difference between model and metamodel?
> > > > (isis-jdo-objectstore-metamodel vs isis-wicket-viewer-model).
> > > >
> > >
> > > Yes... there is (though even if there weren't, I'm not sure it matters
> > too
> > > much ... I'd rather give the authors of individual components/modules
> > some
> > > latitude in how they name the individual submodules. For example,
> scimpi
> > > has isis-scimpi-dispatcher and isis-scimpi-servlet. Anyone who wants
> to
> > > get involved in enhancing scimpi would grok these particular names and
> > why
> > > they were chosen easily enough)
> > >
> > > To answer your question, though... jdo's metamodel submodule is as
> > > described above, its contributions to the Isis metamodel, whereas
> > wicket's
> > > model is Isis' implementation of Wicket's IModel interface.
> > >
> > >
> > >
> > > > By the way my preference here is isis-objectstore-jdo. For the same
> > > > reason as for the proposed location (easy component grouping when
> > > > viewing directory). In my own projects I usually have my directory
> > > > location match my artifactIds.
> > > >
> > >
> > > ok, so we now we have a couple of distinct and different preferences
> in
> > > the community.
> > >
> > > Anyone else have an explicit preferences:
> > > a) for the artifactId: isis-jdo-objectstore vs isis-objectstore-jdo
> > > b) for whether artifactId = directory name
> > >
> > >
> > > >
> > > > Also, isis-scimpi-viewer needs some more attention.
> > > >
> > >
> > > the artifactIds weren't correct ... now fixed
> > >
> > >
> > > Thanks
> > >
> > > Dan
> > >
> > >
> > >
> > > > >
> > > > > Please check out the updated version of that wiki page [1] and let
> me
> > > > know
> > > > > your thoughts. It's important that we get this right (I don't want
> > to
> > > > have
> > > > > to do it all over in 3 months time!!!)
> > > > >
> > > > > Dan
> > > > >
> > > > > [1]
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
>
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Hi Jeroen,
Just realized I did comment on your points here.
With respect to the directory structure, it looks like you're saying
similar things to Kevin who commented today (Sunday).
You did make the point about distinguishing the development modules.
There's the same potential issue as I made with Kevin's suggestion; I'm
not sure that Maven modules can be in a different tree. In the parent pom
it would need to say something like:
<modules>
<module>applib</module>
<module>core</module>
...
<module>../development/unittestsupport</module> <== not sure that this
is allowed
..
</modules>
That said, I think you have correctly listed which modules are intended for
development use only... maybe we just need to document this on our website
more clearly?
Dan
On 1 December 2012 16:46, Jeroen van der Wal <je...@stromboli.it> wrote:
> Wow, what a useful thread this is, thanks for all the contributions in
> unraveling Isis (at least for me)!
>
> I would go for option a.
>
> I even like to take it a step further and move out every component in core
> (released or not) into it's respective folder. For the JDO objectstore the
> groupId would org.apache.isis.objectstore and the artifactId isis-
> objectstore-jdo
>
> It's still hard for met to get why things are under core or not and what's
> used in every deployment (imho equals core) and what is used in
> development. Given that thought my ideal top-level folder layout would be
> something like this:
> core/
> applib
> bytecode-cglib
> bytecode-javassist
> core
> runtime
> development/
> tck
> unittestsupport
> integtestsupport
> webserver
> objectstore/
> inmemory
> jdo
> nosql
> sql
> xml
> profilestore/
> inmemory
> sql
> xml
> progmodel/
> java
> groovy
> wrapper
> security/
> ldap
> sql
> noop
> file
> viewer/
> bdd
> junit
> html
> dnd
> restfulobjects
> scimpi
> wicket
> archetype/
> dnd-xml
> scimpi-nosql
> wicket-restful-jdo
> retired/
> core/
> monitoring
>
> Still not sure if we need the retired folder though, releasing is all about
> picking the right combination of modules right?
>
> Cheers,
>
> Jeroen
>
>
> On Sat, Dec 1, 2012 at 4:36 PM, Dan Haywood <dan@haywood-associates.co.uk
> >wrote:
>
> > On 1 December 2012 14:23, Minto van der Sluis <mi...@xup.nl> wrote:
> >
> > > >Hmm, I get confused by the artifactIds. I see both for formats
> > > (isis-viewer-bdd and isis-wicket-viewer).
> >
> >
> > ah, that was a typo. the intention for artifactIds was: isis-xxx-viewer,
> > isis-yyy-objectstore etc.
> >
> >
> > > I also see artifactIds with 4
> > > sections, for instance: isis-jdo-objectstore-metamodel. This confuses
> > > me. Is it an objectstore or a metamodel?
> >
> >
> > ok, well... some modules (in fact, most) have more than one component.
> And
> > I don't think we should insist that all modules have only one component.
> >
> > In this particular example, isis-jdo-objectstore-metamodel would be the
> > additional facet factories that are added to the metamodel that interpret
> > JDO-specific annotations. That is to distinguish from, say,
> > isis-jdo-objectstore-datanucleus, which is the stuff that calls the
> > DataNucleus' specific stuff.
> >
> > But there is similar layering in isis-scimpi-viewer,
> > isis-restfulobjects-viewer, isis-wicket-viewer, isis-sql-objectstore.
> >
> >
> > (isis-metamodel-jdo) Also is
> > > there really a difference between model and metamodel?
> > > (isis-jdo-objectstore-metamodel vs isis-wicket-viewer-model).
> > >
> >
> > Yes... there is (though even if there weren't, I'm not sure it matters
> too
> > much ... I'd rather give the authors of individual components/modules
> some
> > latitude in how they name the individual submodules. For example, scimpi
> > has isis-scimpi-dispatcher and isis-scimpi-servlet. Anyone who wants to
> > get involved in enhancing scimpi would grok these particular names and
> why
> > they were chosen easily enough)
> >
> > To answer your question, though... jdo's metamodel submodule is as
> > described above, its contributions to the Isis metamodel, whereas
> wicket's
> > model is Isis' implementation of Wicket's IModel interface.
> >
> >
> >
> > > By the way my preference here is isis-objectstore-jdo. For the same
> > > reason as for the proposed location (easy component grouping when
> > > viewing directory). In my own projects I usually have my directory
> > > location match my artifactIds.
> > >
> >
> > ok, so we now we have a couple of distinct and different preferences in
> > the community.
> >
> > Anyone else have an explicit preferences:
> > a) for the artifactId: isis-jdo-objectstore vs isis-objectstore-jdo
> > b) for whether artifactId = directory name
> >
> >
> > >
> > > Also, isis-scimpi-viewer needs some more attention.
> > >
> >
> > the artifactIds weren't correct ... now fixed
> >
> >
> > Thanks
> >
> > Dan
> >
> >
> >
> > > >
> > > > Please check out the updated version of that wiki page [1] and let me
> > > know
> > > > your thoughts. It's important that we get this right (I don't want
> to
> > > have
> > > > to do it all over in 3 months time!!!)
> > > >
> > > > Dan
> > > >
> > > > [1]
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
> > > >
> > > >
> > >
> > >
> >
>
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Giovanni Júnior <gi...@gmail.com>.
+1, except that for question a) I prefer "isis-jdo-objectstore".
2012/12/1 Jeroen van der Wal <je...@stromboli.it>
> Wow, what a useful thread this is, thanks for all the contributions in
> unraveling Isis (at least for me)!
>
> I would go for option a.
>
> I even like to take it a step further and move out every component in core
> (released or not) into it's respective folder. For the JDO objectstore the
> groupId would org.apache.isis.objectstore and the artifactId isis-
> objectstore-jdo
>
> It's still hard for met to get why things are under core or not and what's
> used in every deployment (imho equals core) and what is used in
> development. Given that thought my ideal top-level folder layout would be
> something like this:
> core/
> applib
> bytecode-cglib
> bytecode-javassist
> core
> runtime
> development/
> tck
> unittestsupport
> integtestsupport
> webserver
> objectstore/
> inmemory
> jdo
> nosql
> sql
> xml
> profilestore/
> inmemory
> sql
> xml
> progmodel/
> java
> groovy
> wrapper
> security/
> ldap
> sql
> noop
> file
> viewer/
> bdd
> junit
> html
> dnd
> restfulobjects
> scimpi
> wicket
> archetype/
> dnd-xml
> scimpi-nosql
> wicket-restful-jdo
> retired/
> core/
> monitoring
>
> Still not sure if we need the retired folder though, releasing is all about
> picking the right combination of modules right?
>
> Cheers,
>
> Jeroen
>
>
> On Sat, Dec 1, 2012 at 4:36 PM, Dan Haywood <dan@haywood-associates.co.uk
> >wrote:
>
> > On 1 December 2012 14:23, Minto van der Sluis <mi...@xup.nl> wrote:
> >
> > > >Hmm, I get confused by the artifactIds. I see both for formats
> > > (isis-viewer-bdd and isis-wicket-viewer).
> >
> >
> > ah, that was a typo. the intention for artifactIds was: isis-xxx-viewer,
> > isis-yyy-objectstore etc.
> >
> >
> > > I also see artifactIds with 4
> > > sections, for instance: isis-jdo-objectstore-metamodel. This confuses
> > > me. Is it an objectstore or a metamodel?
> >
> >
> > ok, well... some modules (in fact, most) have more than one component.
> And
> > I don't think we should insist that all modules have only one component.
> >
> > In this particular example, isis-jdo-objectstore-metamodel would be the
> > additional facet factories that are added to the metamodel that interpret
> > JDO-specific annotations. That is to distinguish from, say,
> > isis-jdo-objectstore-datanucleus, which is the stuff that calls the
> > DataNucleus' specific stuff.
> >
> > But there is similar layering in isis-scimpi-viewer,
> > isis-restfulobjects-viewer, isis-wicket-viewer, isis-sql-objectstore.
> >
> >
> > (isis-metamodel-jdo) Also is
> > > there really a difference between model and metamodel?
> > > (isis-jdo-objectstore-metamodel vs isis-wicket-viewer-model).
> > >
> >
> > Yes... there is (though even if there weren't, I'm not sure it matters
> too
> > much ... I'd rather give the authors of individual components/modules
> some
> > latitude in how they name the individual submodules. For example, scimpi
> > has isis-scimpi-dispatcher and isis-scimpi-servlet. Anyone who wants to
> > get involved in enhancing scimpi would grok these particular names and
> why
> > they were chosen easily enough)
> >
> > To answer your question, though... jdo's metamodel submodule is as
> > described above, its contributions to the Isis metamodel, whereas
> wicket's
> > model is Isis' implementation of Wicket's IModel interface.
> >
> >
> >
> > > By the way my preference here is isis-objectstore-jdo. For the same
> > > reason as for the proposed location (easy component grouping when
> > > viewing directory). In my own projects I usually have my directory
> > > location match my artifactIds.
> > >
> >
> > ok, so we now we have a couple of distinct and different preferences in
> > the community.
> >
> > Anyone else have an explicit preferences:
> > a) for the artifactId: isis-jdo-objectstore vs isis-objectstore-jdo
> > b) for whether artifactId = directory name
> >
> >
> > >
> > > Also, isis-scimpi-viewer needs some more attention.
> > >
> >
> > the artifactIds weren't correct ... now fixed
> >
> >
> > Thanks
> >
> > Dan
> >
> >
> >
> > > >
> > > > Please check out the updated version of that wiki page [1] and let me
> > > know
> > > > your thoughts. It's important that we get this right (I don't want
> to
> > > have
> > > > to do it all over in 3 months time!!!)
> > > >
> > > > Dan
> > > >
> > > > [1]
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
> > > >
> > > >
> > >
> > >
> >
>
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Hi Jeroen,
Just realized I did comment on your points here.
With respect to the directory structure, it looks like you're saying
similar things to Kevin who commented today (Sunday).
You did make the point about distinguishing the development modules.
There's the same potential issue as I made with Kevin's suggestion; I'm
not sure that Maven modules can be in a different tree. In the parent pom
it would need to say something like:
<modules>
<module>applib</module>
<module>core</module>
...
<module>../development/unittestsupport</module> <== not sure that this
is allowed
..
</modules>
That said, I think you have correctly listed which modules are intended for
development use only... maybe we just need to document this on our website
more clearly?
Dan
On 1 December 2012 16:46, Jeroen van der Wal <je...@stromboli.it> wrote:
> Wow, what a useful thread this is, thanks for all the contributions in
> unraveling Isis (at least for me)!
>
> I would go for option a.
>
> I even like to take it a step further and move out every component in core
> (released or not) into it's respective folder. For the JDO objectstore the
> groupId would org.apache.isis.objectstore and the artifactId isis-
> objectstore-jdo
>
> It's still hard for met to get why things are under core or not and what's
> used in every deployment (imho equals core) and what is used in
> development. Given that thought my ideal top-level folder layout would be
> something like this:
> core/
> applib
> bytecode-cglib
> bytecode-javassist
> core
> runtime
> development/
> tck
> unittestsupport
> integtestsupport
> webserver
> objectstore/
> inmemory
> jdo
> nosql
> sql
> xml
> profilestore/
> inmemory
> sql
> xml
> progmodel/
> java
> groovy
> wrapper
> security/
> ldap
> sql
> noop
> file
> viewer/
> bdd
> junit
> html
> dnd
> restfulobjects
> scimpi
> wicket
> archetype/
> dnd-xml
> scimpi-nosql
> wicket-restful-jdo
> retired/
> core/
> monitoring
>
> Still not sure if we need the retired folder though, releasing is all about
> picking the right combination of modules right?
>
> Cheers,
>
> Jeroen
>
>
> On Sat, Dec 1, 2012 at 4:36 PM, Dan Haywood <dan@haywood-associates.co.uk
> >wrote:
>
> > On 1 December 2012 14:23, Minto van der Sluis <mi...@xup.nl> wrote:
> >
> > > >Hmm, I get confused by the artifactIds. I see both for formats
> > > (isis-viewer-bdd and isis-wicket-viewer).
> >
> >
> > ah, that was a typo. the intention for artifactIds was: isis-xxx-viewer,
> > isis-yyy-objectstore etc.
> >
> >
> > > I also see artifactIds with 4
> > > sections, for instance: isis-jdo-objectstore-metamodel. This confuses
> > > me. Is it an objectstore or a metamodel?
> >
> >
> > ok, well... some modules (in fact, most) have more than one component.
> And
> > I don't think we should insist that all modules have only one component.
> >
> > In this particular example, isis-jdo-objectstore-metamodel would be the
> > additional facet factories that are added to the metamodel that interpret
> > JDO-specific annotations. That is to distinguish from, say,
> > isis-jdo-objectstore-datanucleus, which is the stuff that calls the
> > DataNucleus' specific stuff.
> >
> > But there is similar layering in isis-scimpi-viewer,
> > isis-restfulobjects-viewer, isis-wicket-viewer, isis-sql-objectstore.
> >
> >
> > (isis-metamodel-jdo) Also is
> > > there really a difference between model and metamodel?
> > > (isis-jdo-objectstore-metamodel vs isis-wicket-viewer-model).
> > >
> >
> > Yes... there is (though even if there weren't, I'm not sure it matters
> too
> > much ... I'd rather give the authors of individual components/modules
> some
> > latitude in how they name the individual submodules. For example, scimpi
> > has isis-scimpi-dispatcher and isis-scimpi-servlet. Anyone who wants to
> > get involved in enhancing scimpi would grok these particular names and
> why
> > they were chosen easily enough)
> >
> > To answer your question, though... jdo's metamodel submodule is as
> > described above, its contributions to the Isis metamodel, whereas
> wicket's
> > model is Isis' implementation of Wicket's IModel interface.
> >
> >
> >
> > > By the way my preference here is isis-objectstore-jdo. For the same
> > > reason as for the proposed location (easy component grouping when
> > > viewing directory). In my own projects I usually have my directory
> > > location match my artifactIds.
> > >
> >
> > ok, so we now we have a couple of distinct and different preferences in
> > the community.
> >
> > Anyone else have an explicit preferences:
> > a) for the artifactId: isis-jdo-objectstore vs isis-objectstore-jdo
> > b) for whether artifactId = directory name
> >
> >
> > >
> > > Also, isis-scimpi-viewer needs some more attention.
> > >
> >
> > the artifactIds weren't correct ... now fixed
> >
> >
> > Thanks
> >
> > Dan
> >
> >
> >
> > > >
> > > > Please check out the updated version of that wiki page [1] and let me
> > > know
> > > > your thoughts. It's important that we get this right (I don't want
> to
> > > have
> > > > to do it all over in 3 months time!!!)
> > > >
> > > > Dan
> > > >
> > > > [1]
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
> > > >
> > > >
> > >
> > >
> >
>
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Jeroen van der Wal <je...@stromboli.it>.
Wow, what a useful thread this is, thanks for all the contributions in
unraveling Isis (at least for me)!
I would go for option a.
I even like to take it a step further and move out every component in core
(released or not) into it's respective folder. For the JDO objectstore the
groupId would org.apache.isis.objectstore and the artifactId isis-
objectstore-jdo
It's still hard for met to get why things are under core or not and what's
used in every deployment (imho equals core) and what is used in
development. Given that thought my ideal top-level folder layout would be
something like this:
core/
applib
bytecode-cglib
bytecode-javassist
core
runtime
development/
tck
unittestsupport
integtestsupport
webserver
objectstore/
inmemory
jdo
nosql
sql
xml
profilestore/
inmemory
sql
xml
progmodel/
java
groovy
wrapper
security/
ldap
sql
noop
file
viewer/
bdd
junit
html
dnd
restfulobjects
scimpi
wicket
archetype/
dnd-xml
scimpi-nosql
wicket-restful-jdo
retired/
core/
monitoring
Still not sure if we need the retired folder though, releasing is all about
picking the right combination of modules right?
Cheers,
Jeroen
On Sat, Dec 1, 2012 at 4:36 PM, Dan Haywood <da...@haywood-associates.co.uk>wrote:
> On 1 December 2012 14:23, Minto van der Sluis <mi...@xup.nl> wrote:
>
> > >Hmm, I get confused by the artifactIds. I see both for formats
> > (isis-viewer-bdd and isis-wicket-viewer).
>
>
> ah, that was a typo. the intention for artifactIds was: isis-xxx-viewer,
> isis-yyy-objectstore etc.
>
>
> > I also see artifactIds with 4
> > sections, for instance: isis-jdo-objectstore-metamodel. This confuses
> > me. Is it an objectstore or a metamodel?
>
>
> ok, well... some modules (in fact, most) have more than one component. And
> I don't think we should insist that all modules have only one component.
>
> In this particular example, isis-jdo-objectstore-metamodel would be the
> additional facet factories that are added to the metamodel that interpret
> JDO-specific annotations. That is to distinguish from, say,
> isis-jdo-objectstore-datanucleus, which is the stuff that calls the
> DataNucleus' specific stuff.
>
> But there is similar layering in isis-scimpi-viewer,
> isis-restfulobjects-viewer, isis-wicket-viewer, isis-sql-objectstore.
>
>
> (isis-metamodel-jdo) Also is
> > there really a difference between model and metamodel?
> > (isis-jdo-objectstore-metamodel vs isis-wicket-viewer-model).
> >
>
> Yes... there is (though even if there weren't, I'm not sure it matters too
> much ... I'd rather give the authors of individual components/modules some
> latitude in how they name the individual submodules. For example, scimpi
> has isis-scimpi-dispatcher and isis-scimpi-servlet. Anyone who wants to
> get involved in enhancing scimpi would grok these particular names and why
> they were chosen easily enough)
>
> To answer your question, though... jdo's metamodel submodule is as
> described above, its contributions to the Isis metamodel, whereas wicket's
> model is Isis' implementation of Wicket's IModel interface.
>
>
>
> > By the way my preference here is isis-objectstore-jdo. For the same
> > reason as for the proposed location (easy component grouping when
> > viewing directory). In my own projects I usually have my directory
> > location match my artifactIds.
> >
>
> ok, so we now we have a couple of distinct and different preferences in
> the community.
>
> Anyone else have an explicit preferences:
> a) for the artifactId: isis-jdo-objectstore vs isis-objectstore-jdo
> b) for whether artifactId = directory name
>
>
> >
> > Also, isis-scimpi-viewer needs some more attention.
> >
>
> the artifactIds weren't correct ... now fixed
>
>
> Thanks
>
> Dan
>
>
>
> > >
> > > Please check out the updated version of that wiki page [1] and let me
> > know
> > > your thoughts. It's important that we get this right (I don't want to
> > have
> > > to do it all over in 3 months time!!!)
> > >
> > > Dan
> > >
> > > [1]
> > >
> >
> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
> > >
> > >
> >
> >
>
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Jeroen van der Wal <je...@stromboli.it>.
Thanks Rob, this makes sense. And I agree.
-Jeroen
On Sun, Dec 2, 2012 at 9:35 PM, Robert Matthews
<rm...@nakedobjects.org>wrote:
> Hi Jeroen
>
> Having continued reading I think I'm saying the same kind of thing as Dan.
> But an example should help.
>
> At the moment we have listed the component like the SQL OS, Scimpi viewer
> and Wicket viewer as a set of components, so specifically the Scimpi viewer
> is down as o.a.i.viewer:scimpi, o.a.i.viewer:scimpi-servlet and
> o.a.i.viewer:scimpi-**dispacther. Those submodules are just part of the
> Scimpi viewer and not themselves components. So the list of relevant
> components (as far as the outside world is concerned) would be be like this:
>
> isis-viewer-restful
> isis-viewer-scimpi
> isis-viewer-wicket
> isis-viewer-html
>
> instead of this:
>
> isis-viewer-restful
> isis-viewer-restful-applib
> isis-viewer-restful-viewer
> isis-viewer-restful-tck
> isis-viewer-scimpi
> isis-viewer-scimpi-servlet
> isis-viewer-scimpi-dispatcher
> isis-viewer-wicket
> isis-viewer-wicket-model
> isis-viewer-wicket-ui
> isis-viewer-wicket-viewer
> isis-viewer-wicket-tck
> isis-viewer-html
>
> Hence a component is portrayed as single entity even though internally it
> may be complicated and made up of many things.
>
> Another way of putting it, is that the list we are discussing is more
> complicated than it needs to be because many of modules are effectively not
> important from main view.
>
> I hope that helps.
>
> Rob
>
>
>
>
> On 12/02/12 18:51, Jeroen van der Wal wrote:
>
>> Hi Rob
>>
>> Sorry but I don't get what you're trying to tell. Perhaps you could
>> elaborate or give a sample?
>>
>> Cheers,
>>
>> Jeroen
>>
>>
>> On Sun, Dec 2, 2012 at 7:51 PM, Robert Matthews
>> <rm...@nakedobjects.org>**wrote:
>>
>> I think the multiple modules aspect is what is adding confusion. What our
>>> list needs to show is what top level parts there are. So there is the
>>> core
>>> and a number of components that work with the core. Now as far as the
>>> components are concerned whether they simply consist of the module that
>>> is
>>> named or a number of modules is concerned is immaterial. What is
>>> important
>>> is that each component is known by one name; any submodules are not
>>> relevant and are to be seen only within the module. The core follows
>>> this
>>> idea to a lesser degree I think.
>>>
>>> This means that the list being discussed probably should be shorter, and
>>> the sub modules left out.
>>>
>>> Does this make sense?
>>>
>>> Rob
>>>
>>>
>>>
>>> On 12/01/12 15:36, Dan Haywood wrote:
>>>
>>> On 1 December 2012 14:23, Minto van der Sluis <mi...@xup.nl> wrote:
>>>>
>>>> Hmm, I get confused by the artifactIds. I see both for formats
>>>>
>>>>> (isis-viewer-bdd and isis-wicket-viewer).
>>>>>
>>>>> ah, that was a typo. the intention for artifactIds was:
>>>> isis-xxx-viewer,
>>>> isis-yyy-objectstore etc.
>>>>
>>>>
>>>> I also see artifactIds with 4
>>>>
>>>>> sections, for instance: isis-jdo-objectstore-****metamodel. This
>>>>> confuses
>>>>>
>>>>> me. Is it an objectstore or a metamodel?
>>>>>
>>>>> ok, well... some modules (in fact, most) have more than one component.
>>>> And
>>>> I don't think we should insist that all modules have only one component.
>>>>
>>>> In this particular example, isis-jdo-objectstore-metamodel would be the
>>>> additional facet factories that are added to the metamodel that
>>>> interpret
>>>> JDO-specific annotations. That is to distinguish from, say,
>>>> isis-jdo-objectstore-****datanucleus, which is the stuff that calls the
>>>>
>>>> DataNucleus' specific stuff.
>>>>
>>>> But there is similar layering in isis-scimpi-viewer,
>>>> isis-restfulobjects-viewer, isis-wicket-viewer, isis-sql-objectstore.
>>>>
>>>>
>>>> (isis-metamodel-jdo) Also is
>>>>
>>>> there really a difference between model and metamodel?
>>>>> (isis-jdo-objectstore-****metamodel vs isis-wicket-viewer-model).
>>>>>
>>>>>
>>>>> Yes... there is (though even if there weren't, I'm not sure it
>>>>> matters
>>>>>
>>>> too
>>>> much ... I'd rather give the authors of individual components/modules
>>>> some
>>>> latitude in how they name the individual submodules. For example,
>>>> scimpi
>>>> has isis-scimpi-dispatcher and isis-scimpi-servlet. Anyone who wants to
>>>> get involved in enhancing scimpi would grok these particular names and
>>>> why
>>>> they were chosen easily enough)
>>>>
>>>> To answer your question, though... jdo's metamodel submodule is as
>>>> described above, its contributions to the Isis metamodel, whereas
>>>> wicket's
>>>> model is Isis' implementation of Wicket's IModel interface.
>>>>
>>>>
>>>>
>>>> By the way my preference here is isis-objectstore-jdo. For the same
>>>>
>>>>> reason as for the proposed location (easy component grouping when
>>>>> viewing directory). In my own projects I usually have my directory
>>>>> location match my artifactIds.
>>>>>
>>>>> ok, so we now we have a couple of distinct and different
>>>>> preferences in
>>>>>
>>>> the community.
>>>>
>>>> Anyone else have an explicit preferences:
>>>> a) for the artifactId: isis-jdo-objectstore vs isis-objectstore-jdo
>>>> b) for whether artifactId = directory name
>>>>
>>>>
>>>> Also, isis-scimpi-viewer needs some more attention.
>>>>
>>>>> the artifactIds weren't correct ... now fixed
>>>>>
>>>>
>>>> Thanks
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>>> Please check out the updated version of that wiki page [1] and let me
>>>>
>>>>> know
>>>>>
>>>>> your thoughts. It's important that we get this right (I don't want to
>>>>>>
>>>>>> have
>>>>>
>>>>> to do it all over in 3 months time!!!)
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>> [1]
>>>>>>
>>>>>> https://cwiki.apache.org/****confluence/display/ISIS/Make+****<https://cwiki.apache.org/**confluence/display/ISIS/Make+**>
>>>>>>
>>>>> releases+easier+and+more+****frequent<https://cwiki.apache.**
>>>>> org/confluence/display/ISIS/**Make+releases+easier+and+more+**frequent<https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent>
>>>>> >
>>>>>
>>>>>
>>>>>>
>
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Robert Matthews <rm...@nakedobjects.org>.
Hi Jeroen
Having continued reading I think I'm saying the same kind of thing as
Dan. But an example should help.
At the moment we have listed the component like the SQL OS, Scimpi
viewer and Wicket viewer as a set of components, so specifically the
Scimpi viewer is down as o.a.i.viewer:scimpi,
o.a.i.viewer:scimpi-servlet and o.a.i.viewer:scimpi-dispacther. Those
submodules are just part of the Scimpi viewer and not themselves
components. So the list of relevant components (as far as the outside
world is concerned) would be be like this:
isis-viewer-restful
isis-viewer-scimpi
isis-viewer-wicket
isis-viewer-html
instead of this:
isis-viewer-restful
isis-viewer-restful-applib
isis-viewer-restful-viewer
isis-viewer-restful-tck
isis-viewer-scimpi
isis-viewer-scimpi-servlet
isis-viewer-scimpi-dispatcher
isis-viewer-wicket
isis-viewer-wicket-model
isis-viewer-wicket-ui
isis-viewer-wicket-viewer
isis-viewer-wicket-tck
isis-viewer-html
Hence a component is portrayed as single entity even though internally
it may be complicated and made up of many things.
Another way of putting it, is that the list we are discussing is more
complicated than it needs to be because many of modules are effectively
not important from main view.
I hope that helps.
Rob
On 12/02/12 18:51, Jeroen van der Wal wrote:
> Hi Rob
>
> Sorry but I don't get what you're trying to tell. Perhaps you could
> elaborate or give a sample?
>
> Cheers,
>
> Jeroen
>
>
> On Sun, Dec 2, 2012 at 7:51 PM, Robert Matthews
> <rm...@nakedobjects.org>wrote:
>
>> I think the multiple modules aspect is what is adding confusion. What our
>> list needs to show is what top level parts there are. So there is the core
>> and a number of components that work with the core. Now as far as the
>> components are concerned whether they simply consist of the module that is
>> named or a number of modules is concerned is immaterial. What is important
>> is that each component is known by one name; any submodules are not
>> relevant and are to be seen only within the module. The core follows this
>> idea to a lesser degree I think.
>>
>> This means that the list being discussed probably should be shorter, and
>> the sub modules left out.
>>
>> Does this make sense?
>>
>> Rob
>>
>>
>>
>> On 12/01/12 15:36, Dan Haywood wrote:
>>
>>> On 1 December 2012 14:23, Minto van der Sluis <mi...@xup.nl> wrote:
>>>
>>> Hmm, I get confused by the artifactIds. I see both for formats
>>>> (isis-viewer-bdd and isis-wicket-viewer).
>>>>
>>> ah, that was a typo. the intention for artifactIds was: isis-xxx-viewer,
>>> isis-yyy-objectstore etc.
>>>
>>>
>>> I also see artifactIds with 4
>>>> sections, for instance: isis-jdo-objectstore-**metamodel. This confuses
>>>> me. Is it an objectstore or a metamodel?
>>>>
>>> ok, well... some modules (in fact, most) have more than one component.
>>> And
>>> I don't think we should insist that all modules have only one component.
>>>
>>> In this particular example, isis-jdo-objectstore-metamodel would be the
>>> additional facet factories that are added to the metamodel that interpret
>>> JDO-specific annotations. That is to distinguish from, say,
>>> isis-jdo-objectstore-**datanucleus, which is the stuff that calls the
>>> DataNucleus' specific stuff.
>>>
>>> But there is similar layering in isis-scimpi-viewer,
>>> isis-restfulobjects-viewer, isis-wicket-viewer, isis-sql-objectstore.
>>>
>>>
>>> (isis-metamodel-jdo) Also is
>>>
>>>> there really a difference between model and metamodel?
>>>> (isis-jdo-objectstore-**metamodel vs isis-wicket-viewer-model).
>>>>
>>>> Yes... there is (though even if there weren't, I'm not sure it matters
>>> too
>>> much ... I'd rather give the authors of individual components/modules some
>>> latitude in how they name the individual submodules. For example, scimpi
>>> has isis-scimpi-dispatcher and isis-scimpi-servlet. Anyone who wants to
>>> get involved in enhancing scimpi would grok these particular names and why
>>> they were chosen easily enough)
>>>
>>> To answer your question, though... jdo's metamodel submodule is as
>>> described above, its contributions to the Isis metamodel, whereas wicket's
>>> model is Isis' implementation of Wicket's IModel interface.
>>>
>>>
>>>
>>> By the way my preference here is isis-objectstore-jdo. For the same
>>>> reason as for the proposed location (easy component grouping when
>>>> viewing directory). In my own projects I usually have my directory
>>>> location match my artifactIds.
>>>>
>>>> ok, so we now we have a couple of distinct and different preferences in
>>> the community.
>>>
>>> Anyone else have an explicit preferences:
>>> a) for the artifactId: isis-jdo-objectstore vs isis-objectstore-jdo
>>> b) for whether artifactId = directory name
>>>
>>>
>>> Also, isis-scimpi-viewer needs some more attention.
>>>> the artifactIds weren't correct ... now fixed
>>>
>>> Thanks
>>>
>>> Dan
>>>
>>>
>>>
>>> Please check out the updated version of that wiki page [1] and let me
>>>> know
>>>>
>>>>> your thoughts. It's important that we get this right (I don't want to
>>>>>
>>>> have
>>>>
>>>>> to do it all over in 3 months time!!!)
>>>>>
>>>>> Dan
>>>>>
>>>>> [1]
>>>>>
>>>>> https://cwiki.apache.org/**confluence/display/ISIS/Make+**
>>>> releases+easier+and+more+**frequent<https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent>
>>>>
>>>>>
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Jeroen van der Wal <je...@stromboli.it>.
Hi Rob
Sorry but I don't get what you're trying to tell. Perhaps you could
elaborate or give a sample?
Cheers,
Jeroen
On Sun, Dec 2, 2012 at 7:51 PM, Robert Matthews
<rm...@nakedobjects.org>wrote:
> I think the multiple modules aspect is what is adding confusion. What our
> list needs to show is what top level parts there are. So there is the core
> and a number of components that work with the core. Now as far as the
> components are concerned whether they simply consist of the module that is
> named or a number of modules is concerned is immaterial. What is important
> is that each component is known by one name; any submodules are not
> relevant and are to be seen only within the module. The core follows this
> idea to a lesser degree I think.
>
> This means that the list being discussed probably should be shorter, and
> the sub modules left out.
>
> Does this make sense?
>
> Rob
>
>
>
> On 12/01/12 15:36, Dan Haywood wrote:
>
>> On 1 December 2012 14:23, Minto van der Sluis <mi...@xup.nl> wrote:
>>
>> Hmm, I get confused by the artifactIds. I see both for formats
>>>>
>>> (isis-viewer-bdd and isis-wicket-viewer).
>>>
>>
>> ah, that was a typo. the intention for artifactIds was: isis-xxx-viewer,
>> isis-yyy-objectstore etc.
>>
>>
>> I also see artifactIds with 4
>>> sections, for instance: isis-jdo-objectstore-**metamodel. This confuses
>>> me. Is it an objectstore or a metamodel?
>>>
>>
>> ok, well... some modules (in fact, most) have more than one component.
>> And
>> I don't think we should insist that all modules have only one component.
>>
>> In this particular example, isis-jdo-objectstore-metamodel would be the
>> additional facet factories that are added to the metamodel that interpret
>> JDO-specific annotations. That is to distinguish from, say,
>> isis-jdo-objectstore-**datanucleus, which is the stuff that calls the
>> DataNucleus' specific stuff.
>>
>> But there is similar layering in isis-scimpi-viewer,
>> isis-restfulobjects-viewer, isis-wicket-viewer, isis-sql-objectstore.
>>
>>
>> (isis-metamodel-jdo) Also is
>>
>>> there really a difference between model and metamodel?
>>> (isis-jdo-objectstore-**metamodel vs isis-wicket-viewer-model).
>>>
>>> Yes... there is (though even if there weren't, I'm not sure it matters
>> too
>> much ... I'd rather give the authors of individual components/modules some
>> latitude in how they name the individual submodules. For example, scimpi
>> has isis-scimpi-dispatcher and isis-scimpi-servlet. Anyone who wants to
>> get involved in enhancing scimpi would grok these particular names and why
>> they were chosen easily enough)
>>
>> To answer your question, though... jdo's metamodel submodule is as
>> described above, its contributions to the Isis metamodel, whereas wicket's
>> model is Isis' implementation of Wicket's IModel interface.
>>
>>
>>
>> By the way my preference here is isis-objectstore-jdo. For the same
>>> reason as for the proposed location (easy component grouping when
>>> viewing directory). In my own projects I usually have my directory
>>> location match my artifactIds.
>>>
>>> ok, so we now we have a couple of distinct and different preferences in
>> the community.
>>
>> Anyone else have an explicit preferences:
>> a) for the artifactId: isis-jdo-objectstore vs isis-objectstore-jdo
>> b) for whether artifactId = directory name
>>
>>
>> Also, isis-scimpi-viewer needs some more attention.
>>>
>>> the artifactIds weren't correct ... now fixed
>>
>>
>> Thanks
>>
>> Dan
>>
>>
>>
>> Please check out the updated version of that wiki page [1] and let me
>>>>
>>> know
>>>
>>>> your thoughts. It's important that we get this right (I don't want to
>>>>
>>> have
>>>
>>>> to do it all over in 3 months time!!!)
>>>>
>>>> Dan
>>>>
>>>> [1]
>>>>
>>>> https://cwiki.apache.org/**confluence/display/ISIS/Make+**
>>> releases+easier+and+more+**frequent<https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent>
>>>
>>>>
>>>>
>>>
>
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Robert Matthews <rm...@nakedobjects.org>.
I think the multiple modules aspect is what is adding confusion. What
our list needs to show is what top level parts there are. So there is
the core and a number of components that work with the core. Now as far
as the components are concerned whether they simply consist of the
module that is named or a number of modules is concerned is immaterial.
What is important is that each component is known by one name; any
submodules are not relevant and are to be seen only within the module.
The core follows this idea to a lesser degree I think.
This means that the list being discussed probably should be shorter, and
the sub modules left out.
Does this make sense?
Rob
On 12/01/12 15:36, Dan Haywood wrote:
> On 1 December 2012 14:23, Minto van der Sluis <mi...@xup.nl> wrote:
>
>>> Hmm, I get confused by the artifactIds. I see both for formats
>> (isis-viewer-bdd and isis-wicket-viewer).
>
> ah, that was a typo. the intention for artifactIds was: isis-xxx-viewer,
> isis-yyy-objectstore etc.
>
>
>> I also see artifactIds with 4
>> sections, for instance: isis-jdo-objectstore-metamodel. This confuses
>> me. Is it an objectstore or a metamodel?
>
> ok, well... some modules (in fact, most) have more than one component. And
> I don't think we should insist that all modules have only one component.
>
> In this particular example, isis-jdo-objectstore-metamodel would be the
> additional facet factories that are added to the metamodel that interpret
> JDO-specific annotations. That is to distinguish from, say,
> isis-jdo-objectstore-datanucleus, which is the stuff that calls the
> DataNucleus' specific stuff.
>
> But there is similar layering in isis-scimpi-viewer,
> isis-restfulobjects-viewer, isis-wicket-viewer, isis-sql-objectstore.
>
>
> (isis-metamodel-jdo) Also is
>> there really a difference between model and metamodel?
>> (isis-jdo-objectstore-metamodel vs isis-wicket-viewer-model).
>>
> Yes... there is (though even if there weren't, I'm not sure it matters too
> much ... I'd rather give the authors of individual components/modules some
> latitude in how they name the individual submodules. For example, scimpi
> has isis-scimpi-dispatcher and isis-scimpi-servlet. Anyone who wants to
> get involved in enhancing scimpi would grok these particular names and why
> they were chosen easily enough)
>
> To answer your question, though... jdo's metamodel submodule is as
> described above, its contributions to the Isis metamodel, whereas wicket's
> model is Isis' implementation of Wicket's IModel interface.
>
>
>
>> By the way my preference here is isis-objectstore-jdo. For the same
>> reason as for the proposed location (easy component grouping when
>> viewing directory). In my own projects I usually have my directory
>> location match my artifactIds.
>>
> ok, so we now we have a couple of distinct and different preferences in
> the community.
>
> Anyone else have an explicit preferences:
> a) for the artifactId: isis-jdo-objectstore vs isis-objectstore-jdo
> b) for whether artifactId = directory name
>
>
>> Also, isis-scimpi-viewer needs some more attention.
>>
> the artifactIds weren't correct ... now fixed
>
>
> Thanks
>
> Dan
>
>
>
>>> Please check out the updated version of that wiki page [1] and let me
>> know
>>> your thoughts. It's important that we get this right (I don't want to
>> have
>>> to do it all over in 3 months time!!!)
>>>
>>> Dan
>>>
>>> [1]
>>>
>> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
>>>
>>
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 1 December 2012 14:23, Minto van der Sluis <mi...@xup.nl> wrote:
> >Hmm, I get confused by the artifactIds. I see both for formats
> (isis-viewer-bdd and isis-wicket-viewer).
ah, that was a typo. the intention for artifactIds was: isis-xxx-viewer,
isis-yyy-objectstore etc.
> I also see artifactIds with 4
> sections, for instance: isis-jdo-objectstore-metamodel. This confuses
> me. Is it an objectstore or a metamodel?
ok, well... some modules (in fact, most) have more than one component. And
I don't think we should insist that all modules have only one component.
In this particular example, isis-jdo-objectstore-metamodel would be the
additional facet factories that are added to the metamodel that interpret
JDO-specific annotations. That is to distinguish from, say,
isis-jdo-objectstore-datanucleus, which is the stuff that calls the
DataNucleus' specific stuff.
But there is similar layering in isis-scimpi-viewer,
isis-restfulobjects-viewer, isis-wicket-viewer, isis-sql-objectstore.
(isis-metamodel-jdo) Also is
> there really a difference between model and metamodel?
> (isis-jdo-objectstore-metamodel vs isis-wicket-viewer-model).
>
Yes... there is (though even if there weren't, I'm not sure it matters too
much ... I'd rather give the authors of individual components/modules some
latitude in how they name the individual submodules. For example, scimpi
has isis-scimpi-dispatcher and isis-scimpi-servlet. Anyone who wants to
get involved in enhancing scimpi would grok these particular names and why
they were chosen easily enough)
To answer your question, though... jdo's metamodel submodule is as
described above, its contributions to the Isis metamodel, whereas wicket's
model is Isis' implementation of Wicket's IModel interface.
> By the way my preference here is isis-objectstore-jdo. For the same
> reason as for the proposed location (easy component grouping when
> viewing directory). In my own projects I usually have my directory
> location match my artifactIds.
>
ok, so we now we have a couple of distinct and different preferences in
the community.
Anyone else have an explicit preferences:
a) for the artifactId: isis-jdo-objectstore vs isis-objectstore-jdo
b) for whether artifactId = directory name
>
> Also, isis-scimpi-viewer needs some more attention.
>
the artifactIds weren't correct ... now fixed
Thanks
Dan
> >
> > Please check out the updated version of that wiki page [1] and let me
> know
> > your thoughts. It's important that we get this right (I don't want to
> have
> > to do it all over in 3 months time!!!)
> >
> > Dan
> >
> > [1]
> >
> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
> >
> >
>
>
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 1 December 2012 14:23, Minto van der Sluis <mi...@xup.nl> wrote:
> >Hmm, I get confused by the artifactIds. I see both for formats
> (isis-viewer-bdd and isis-wicket-viewer).
ah, that was a typo. the intention for artifactIds was: isis-xxx-viewer,
isis-yyy-objectstore etc.
> I also see artifactIds with 4
> sections, for instance: isis-jdo-objectstore-metamodel. This confuses
> me. Is it an objectstore or a metamodel?
ok, well... some modules (in fact, most) have more than one component. And
I don't think we should insist that all modules have only one component.
In this particular example, isis-jdo-objectstore-metamodel would be the
additional facet factories that are added to the metamodel that interpret
JDO-specific annotations. That is to distinguish from, say,
isis-jdo-objectstore-datanucleus, which is the stuff that calls the
DataNucleus' specific stuff.
But there is similar layering in isis-scimpi-viewer,
isis-restfulobjects-viewer, isis-wicket-viewer, isis-sql-objectstore.
(isis-metamodel-jdo) Also is
> there really a difference between model and metamodel?
> (isis-jdo-objectstore-metamodel vs isis-wicket-viewer-model).
>
Yes... there is (though even if there weren't, I'm not sure it matters too
much ... I'd rather give the authors of individual components/modules some
latitude in how they name the individual submodules. For example, scimpi
has isis-scimpi-dispatcher and isis-scimpi-servlet. Anyone who wants to
get involved in enhancing scimpi would grok these particular names and why
they were chosen easily enough)
To answer your question, though... jdo's metamodel submodule is as
described above, its contributions to the Isis metamodel, whereas wicket's
model is Isis' implementation of Wicket's IModel interface.
> By the way my preference here is isis-objectstore-jdo. For the same
> reason as for the proposed location (easy component grouping when
> viewing directory). In my own projects I usually have my directory
> location match my artifactIds.
>
ok, so we now we have a couple of distinct and different preferences in
the community.
Anyone else have an explicit preferences:
a) for the artifactId: isis-jdo-objectstore vs isis-objectstore-jdo
b) for whether artifactId = directory name
>
> Also, isis-scimpi-viewer needs some more attention.
>
the artifactIds weren't correct ... now fixed
Thanks
Dan
> >
> > Please check out the updated version of that wiki page [1] and let me
> know
> > your thoughts. It's important that we get this right (I don't want to
> have
> > to do it all over in 3 months time!!!)
> >
> > Dan
> >
> > [1]
> >
> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
> >
> >
>
>
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Minto van der Sluis <mi...@xup.nl>.
Hi Dan,
See my remarks below.
Regards,
Minto
Op 1-12-2012 14:44, Dan Haywood schreef:
> OK, so I've replied briefly to each of the most recent posts that Rob and
> Kevin made, and I've now gone round the loop again with the wiki page.
>
> This time I've listed out each and every of the current modules, and
> proposed how they could be moved around and in many cases amalgamated in
> order to simplify and aid grokkability.
>
> I've also changed the artifactIds to go with (what seems generally
> preferred) names such as isis-jdo-objectstore.
Hmm, I get confused by the artifactIds. I see both for formats
(isis-viewer-bdd and isis-wicket-viewer). I also see artifactIds with 4
sections, for instance: isis-jdo-objectstore-metamodel. This confuses
me. Is it an objectstore or a metamodel? (isis-metamodel-jdo) Also is
there really a difference between model and metamodel?
(isis-jdo-objectstore-metamodel vs isis-wicket-viewer-model).
By the way my preference here is isis-objectstore-jdo. For the same
reason as for the proposed location (easy component grouping when
viewing directory). In my own projects I usually have my directory
location match my artifactIds.
Also, isis-scimpi-viewer needs some more attention.
>
> Please check out the updated version of that wiki page [1] and let me know
> your thoughts. It's important that we get this right (I don't want to have
> to do it all over in 3 months time!!!)
>
> Dan
>
> [1]
> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
>
>
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
OK, so I've replied briefly to each of the most recent posts that Rob and
Kevin made, and I've now gone round the loop again with the wiki page.
This time I've listed out each and every of the current modules, and
proposed how they could be moved around and in many cases amalgamated in
order to simplify and aid grokkability.
I've also changed the artifactIds to go with (what seems generally
preferred) names such as isis-jdo-objectstore.
Please check out the updated version of that wiki page [1] and let me know
your thoughts. It's important that we get this right (I don't want to have
to do it all over in 3 months time!!!)
Dan
[1]
https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
~~~~~~~
On 1 December 2012 13:40, Dan Haywood <da...@haywood-associates.co.uk> wrote:
>
>
> On 30 November 2012 19:41, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
>
>> Just to add my 2c
>>
>> +1 to the general idea
>>
>> If I understand correctly, it supports the idea of each module having its
>> own version?
>
>
> yes, that's the main idea.
>
>
>
>> So if I (for example) take my time with the sql
>> objectstore, its version number will remain low. So version number is a
>> true indication of the (major) improvements behind each component?
>>
>
> We haven't talked about version numbering, that's perhaps for a different
> thread. But, top of my head, I would suggest that if the core goes up as
> 0.4.0, 0.5.0, 0.6.0 etc, then I'd expect the other components to track
> them, eg 0.3.0, 0.4.0, 0.5.0. If a component author wants to push out a
> new feature that doesn't require a bumping of core, they could then go with
> 0.6.1, 0.6.2 etc.
>
> But, as I say, don't want to get side-tracked by that point.... there's
> probably lots of equally valid ways to deal with this.
>
>
>
>> And not (like at present) each component / package / module has the
>> same version, increasing with each release?
>>
>> As for the html-viewer.. I have one deployed application out there that
>> is still using it.. so I would like to see it migrated into the new,
>> renamed, format.
>> Having said this - this application is also probably locked into the
>> previous version of Isis (it has a custom objectstore that I can't migrate
>> into the new format since the Oid changes were made), so maybe it
>> doesn't matter if the html viewer is retired.
>>
>
> OK.
>
> Thx
> Dan
>
>
>>
>> Regards,
>> Kevin
>>
>> On 30 Nov 2012 at 17:18, Dan Haywood wrote:
>>
>> > Yup, understood. I have now updated the wiki page [1], and the
>> artifactIds
>> > are pretty much identical to those you suggested in your mail of
>> yesterday.
>> > Check it out and let me know your thoughts...
>> >
>> > Dan
>> > [1]
>> >
>> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
>> >
>> > On 30 November 2012 17:17, Robert Matthews <rmatthews@nakedobjects.org
>> >wrote:
>> >
>> > > It's not about building the classpath - who'd want to do that - it's
>> when
>> > > you have to look at what's been added to the classpath. Only
>> yesterday I
>> > > was looking at the references for a project in Eclipse and, as Rafael
>> says,
>> > > it would have been easier if they were prefixed and hence grouped and
>> I
>> > > would have been able to see what I was looking for immediately.
>> > >
>> > > Rob
>> > >
>> > >
>> > >
>> > > On 11/30/12 16:31, Dan Haywood wrote:
>> > >
>> > >> Yeah, I understand. But does anyone today - especially for a
>> framework
>> > >> such as Isis that provides Maven archetypes - build up their
>> classpath by
>> > >> manually assembling jars in some sort of lib/ directory?
>> > >>
>> > >> I'm prepared to stand corrected, but it doesn't strike me as a
>> > >> particularly
>> > >> common use case. Maven, of course, builds the classpath by referring
>> > >> directory to the jars in the local ~/.m2 repo.
>> > >>
>> > >> Dan
>> > >>
>> > >>
>> > >> On 30 November 2012 16:23, Rafael Chaves <ra...@alphasimple.com>
>> wrote:
>> > >>
>> > >> Dan,
>> > >>>
>> > >>> That is true for a repository - but I was referring to jars used in
>> an
>> > >>> *application*.
>> > >>>
>> > >>> Spring, Hibernate, Apache Commons, Restlet, Jackson, Camel,
>> virtually
>> > >>> every
>> > >>> multi-artifact framework I use follows this approach. When I am
>> looking
>> > >>> at
>> > >>> a directory with a hundred Jars trying to hunt down a specific jar
>> from
>> > >>> one
>> > >>> of those libraries, I really appreciate they did so.
>> > >>>
>> > >>> Yeah, the example you mentioned takes the idea too far.
>> > >>>
>> > >>> Cheers,
>> > >>>
>> > >>> Rafael
>> > >>>
>> > >>> On Fri, Nov 30, 2012 at 8:14 AM, Dan Haywood
>> > >>> <da...@haywood-associates.co.uk>**wrote:
>> > >>>
>> > >>> Hi Rafael,
>> > >>>> hmm, not sure that's a very good motivation... the identity of a
>> Maven
>> > >>>>
>> > >>> jar
>> > >>>
>> > >>>> is also the directory, ie the full path under ~/.m2/repository.
>> > >>>>
>> > >>>> Funnily enough, I was teaching a Maven course last week at a
>> corporation
>> > >>>> that shall remain nameless, and the developers there had Maven
>> modules
>> > >>>>
>> > >>> with
>> > >>>
>> > >>>> a groupId of com.verybigcorp.foo.bar and an artifactId also of
>> > >>>> com.verybigcorp.foo.bar. We decided that whoever chose that
>> artifactId
>> > >>>> hadn't understood that the identity of the artifact is the
>> combination
>> > >>>> of
>> > >>>> the both (plus version, plus classifier), and had chosen
>> artifactIds
>> > >>>>
>> > >>> based
>> > >>>
>> > >>>> on its use as the JAR name.
>> > >>>>
>> > >>>> Dan
>> > >>>> ~~~~
>> > >>>>
>> > >>>> On 30 November 2012 16:06, Rafael Chaves <ra...@alphasimple.com>
>> > >>>> wrote:
>> > >>>>
>> > >>>> The artifact id ends up by default being the jar name, right? If
>> that
>> > >>>>>
>> > >>>> is
>> > >>>
>> > >>>> true, I'd go with an artifact name with a common prefix across
>> > >>>>> all Isis artifacts (i.e. isis-dflt). Two benefits: people using
>> Isis
>> > >>>>>
>> > >>>> have
>> > >>>
>> > >>>> an easy way of identifying the Isis jars among all the other Jars
>> their
>> > >>>>> application uses, and easily avoids collisions with other
>> people's jar
>> > >>>>> names.
>> > >>>>>
>> > >>>>> Cheers,
>> > >>>>>
>> > >>>>> Rafael
>> > >>>>>
>> > >>>>> On Fri, Nov 30, 2012 at 5:38 AM, Dan Haywood
>> > >>>>> <da...@haywood-associates.co.uk>**wrote:
>> > >>>>>
>> > >>>>> OK, I've tried to pull together various opinions and updated the
>> wiki
>> > >>>>>>
>> > >>>>> page
>> > >>>>>
>> > >>>>>> [1]
>> > >>>>>>
>> > >>>>>> - yes, to idea of independent, more granular releases
>> > >>>>>> - yes, flatten the modules at least as an interim step
>> > >>>>>> - also, rename the groupId/artifactId's
>> > >>>>>> - break linkage so that separate modules so don't share
>> common
>> > >>>>>>
>> > >>>>> parent
>> > >>>>
>> > >>>>> (ie are separate artifacts)
>> > >>>>>> - perhaps... move the separate modules into their own git
>> repos
>> > >>>>>>
>> > >>>>>> With respect to groupId/artifactId's, for those components (eg
>> > >>>>>>
>> > >>>>> objectstore,
>> > >>>>>
>> > >>>>>> security) where there are implementations both core and
>> alternate, we
>> > >>>>>>
>> > >>>>> need
>> > >>>>>
>> > >>>>>> to decide between (eg):
>> > >>>>>>
>> > >>>>>> o.a.isis.core:objectstore-dflt
>> > >>>>>> vs
>> > >>>>>> o.a.isis.objectstore:dflt
>> > >>>>>>
>> > >>>>>> The former has the benefit that all the modules that come with
>> core
>> > >>>>>>
>> > >>>>> have
>> > >>>>
>> > >>>>> a
>> > >>>>>
>> > >>>>>> common groupId; the latter has the benefit that all
>> implementations,
>> > >>>>>> irrespective of whether they are core or not, have the same
>> groupId.
>> > >>>>>>
>> > >>>>> In
>> > >>>>
>> > >>>>> other words, does groupId represent a packaging, or does it
>> represent
>> > >>>>>> common functionality?
>> > >>>>>>
>> > >>>>>> In the wiki page shows, I've gone with the former. But I'm
>> 50:50 on
>> > >>>>>>
>> > >>>>> this
>> > >>>>
>> > >>>>> myself.
>> > >>>>>>
>> > >>>>>> ~~~
>> > >>>>>> Buried on the wiki page are some further questions: whether to
>> retire
>> > >>>>>>
>> > >>>>> the
>> > >>>>
>> > >>>>> html-viewer, the profilestore-xml, and the monitoring component.
>> My
>> > >>>>>> rationale for retiring html-viewer is that the wicket viewer is
>> > >>>>>>
>> > >>>>> similar
>> > >>>
>> > >>>> but
>> > >>>>>
>> > >>>>>> superior; I don't think profilestore-xml makes sense for webapp
>> > >>>>>>
>> > >>>>> viewers
>> > >>>
>> > >>>> (it
>> > >>>>>
>> > >>>>>> might have made sense for dnd viewer in client/server, but we've
>> > >>>>>>
>> > >>>>> already
>> > >>>>
>> > >>>>> removed remoting) ; and monitoring I think is a vestige of the
>> > >>>>>>
>> > >>>>> remoting
>> > >>>
>> > >>>> should also be removed. But we don't necessarily need to come to
>> an
>> > >>>>>> agreement on these points (though opinions would be good).
>> > >>>>>>
>> > >>>>>> Thanks, all
>> > >>>>>> Dan
>> > >>>>>>
>> > >>>>>> [1]
>> > >>>>>>
>> > >>>>>>
>> > >>>>>> https://cwiki.apache.org/**confluence/display/ISIS/Make+**
>> > >>> releases+easier+and+more+**frequent<
>> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
>> >
>> > >>>
>> > >>
>> > >
>> >
>>
>>
>> --
>> Kevin Meyer, PhD, Pr.Sci.Nat
>> KMZ P.O. Box 9822, Sharon Park, South Africa.
>> Tel: +27 11 363 2001 Cell: +27 83 346 3045
>>
>>
>>
>
Re: [DISCUSSION] Making releases easier and more frequent
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
OK, so I've replied briefly to each of the most recent posts that Rob and
Kevin made, and I've now gone round the loop again with the wiki page.
This time I've listed out each and every of the current modules, and
proposed how they could be moved around and in many cases amalgamated in
order to simplify and aid grokkability.
I've also changed the artifactIds to go with (what seems generally
preferred) names such as isis-jdo-objectstore.
Please check out the updated version of that wiki page [1] and let me know
your thoughts. It's important that we get this right (I don't want to have
to do it all over in 3 months time!!!)
Dan
[1]
https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
~~~~~~~
On 1 December 2012 13:40, Dan Haywood <da...@haywood-associates.co.uk> wrote:
>
>
> On 30 November 2012 19:41, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
>
>> Just to add my 2c
>>
>> +1 to the general idea
>>
>> If I understand correctly, it supports the idea of each module having its
>> own version?
>
>
> yes, that's the main idea.
>
>
>
>> So if I (for example) take my time with the sql
>> objectstore, its version number will remain low. So version number is a
>> true indication of the (major) improvements behind each component?
>>
>
> We haven't talked about version numbering, that's perhaps for a different
> thread. But, top of my head, I would suggest that if the core goes up as
> 0.4.0, 0.5.0, 0.6.0 etc, then I'd expect the other components to track
> them, eg 0.3.0, 0.4.0, 0.5.0. If a component author wants to push out a
> new feature that doesn't require a bumping of core, they could then go with
> 0.6.1, 0.6.2 etc.
>
> But, as I say, don't want to get side-tracked by that point.... there's
> probably lots of equally valid ways to deal with this.
>
>
>
>> And not (like at present) each component / package / module has the
>> same version, increasing with each release?
>>
>> As for the html-viewer.. I have one deployed application out there that
>> is still using it.. so I would like to see it migrated into the new,
>> renamed, format.
>> Having said this - this application is also probably locked into the
>> previous version of Isis (it has a custom objectstore that I can't migrate
>> into the new format since the Oid changes were made), so maybe it
>> doesn't matter if the html viewer is retired.
>>
>
> OK.
>
> Thx
> Dan
>
>
>>
>> Regards,
>> Kevin
>>
>> On 30 Nov 2012 at 17:18, Dan Haywood wrote:
>>
>> > Yup, understood. I have now updated the wiki page [1], and the
>> artifactIds
>> > are pretty much identical to those you suggested in your mail of
>> yesterday.
>> > Check it out and let me know your thoughts...
>> >
>> > Dan
>> > [1]
>> >
>> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
>> >
>> > On 30 November 2012 17:17, Robert Matthews <rmatthews@nakedobjects.org
>> >wrote:
>> >
>> > > It's not about building the classpath - who'd want to do that - it's
>> when
>> > > you have to look at what's been added to the classpath. Only
>> yesterday I
>> > > was looking at the references for a project in Eclipse and, as Rafael
>> says,
>> > > it would have been easier if they were prefixed and hence grouped and
>> I
>> > > would have been able to see what I was looking for immediately.
>> > >
>> > > Rob
>> > >
>> > >
>> > >
>> > > On 11/30/12 16:31, Dan Haywood wrote:
>> > >
>> > >> Yeah, I understand. But does anyone today - especially for a
>> framework
>> > >> such as Isis that provides Maven archetypes - build up their
>> classpath by
>> > >> manually assembling jars in some sort of lib/ directory?
>> > >>
>> > >> I'm prepared to stand corrected, but it doesn't strike me as a
>> > >> particularly
>> > >> common use case. Maven, of course, builds the classpath by referring
>> > >> directory to the jars in the local ~/.m2 repo.
>> > >>
>> > >> Dan
>> > >>
>> > >>
>> > >> On 30 November 2012 16:23, Rafael Chaves <ra...@alphasimple.com>
>> wrote:
>> > >>
>> > >> Dan,
>> > >>>
>> > >>> That is true for a repository - but I was referring to jars used in
>> an
>> > >>> *application*.
>> > >>>
>> > >>> Spring, Hibernate, Apache Commons, Restlet, Jackson, Camel,
>> virtually
>> > >>> every
>> > >>> multi-artifact framework I use follows this approach. When I am
>> looking
>> > >>> at
>> > >>> a directory with a hundred Jars trying to hunt down a specific jar
>> from
>> > >>> one
>> > >>> of those libraries, I really appreciate they did so.
>> > >>>
>> > >>> Yeah, the example you mentioned takes the idea too far.
>> > >>>
>> > >>> Cheers,
>> > >>>
>> > >>> Rafael
>> > >>>
>> > >>> On Fri, Nov 30, 2012 at 8:14 AM, Dan Haywood
>> > >>> <da...@haywood-associates.co.uk>**wrote:
>> > >>>
>> > >>> Hi Rafael,
>> > >>>> hmm, not sure that's a very good motivation... the identity of a
>> Maven
>> > >>>>
>> > >>> jar
>> > >>>
>> > >>>> is also the directory, ie the full path under ~/.m2/repository.
>> > >>>>
>> > >>>> Funnily enough, I was teaching a Maven course last week at a
>> corporation
>> > >>>> that shall remain nameless, and the developers there had Maven
>> modules
>> > >>>>
>> > >>> with
>> > >>>
>> > >>>> a groupId of com.verybigcorp.foo.bar and an artifactId also of
>> > >>>> com.verybigcorp.foo.bar. We decided that whoever chose that
>> artifactId
>> > >>>> hadn't understood that the identity of the artifact is the
>> combination
>> > >>>> of
>> > >>>> the both (plus version, plus classifier), and had chosen
>> artifactIds
>> > >>>>
>> > >>> based
>> > >>>
>> > >>>> on its use as the JAR name.
>> > >>>>
>> > >>>> Dan
>> > >>>> ~~~~
>> > >>>>
>> > >>>> On 30 November 2012 16:06, Rafael Chaves <ra...@alphasimple.com>
>> > >>>> wrote:
>> > >>>>
>> > >>>> The artifact id ends up by default being the jar name, right? If
>> that
>> > >>>>>
>> > >>>> is
>> > >>>
>> > >>>> true, I'd go with an artifact name with a common prefix across
>> > >>>>> all Isis artifacts (i.e. isis-dflt). Two benefits: people using
>> Isis
>> > >>>>>
>> > >>>> have
>> > >>>
>> > >>>> an easy way of identifying the Isis jars among all the other Jars
>> their
>> > >>>>> application uses, and easily avoids collisions with other
>> people's jar
>> > >>>>> names.
>> > >>>>>
>> > >>>>> Cheers,
>> > >>>>>
>> > >>>>> Rafael
>> > >>>>>
>> > >>>>> On Fri, Nov 30, 2012 at 5:38 AM, Dan Haywood
>> > >>>>> <da...@haywood-associates.co.uk>**wrote:
>> > >>>>>
>> > >>>>> OK, I've tried to pull together various opinions and updated the
>> wiki
>> > >>>>>>
>> > >>>>> page
>> > >>>>>
>> > >>>>>> [1]
>> > >>>>>>
>> > >>>>>> - yes, to idea of independent, more granular releases
>> > >>>>>> - yes, flatten the modules at least as an interim step
>> > >>>>>> - also, rename the groupId/artifactId's
>> > >>>>>> - break linkage so that separate modules so don't share
>> common
>> > >>>>>>
>> > >>>>> parent
>> > >>>>
>> > >>>>> (ie are separate artifacts)
>> > >>>>>> - perhaps... move the separate modules into their own git
>> repos
>> > >>>>>>
>> > >>>>>> With respect to groupId/artifactId's, for those components (eg
>> > >>>>>>
>> > >>>>> objectstore,
>> > >>>>>
>> > >>>>>> security) where there are implementations both core and
>> alternate, we
>> > >>>>>>
>> > >>>>> need
>> > >>>>>
>> > >>>>>> to decide between (eg):
>> > >>>>>>
>> > >>>>>> o.a.isis.core:objectstore-dflt
>> > >>>>>> vs
>> > >>>>>> o.a.isis.objectstore:dflt
>> > >>>>>>
>> > >>>>>> The former has the benefit that all the modules that come with
>> core
>> > >>>>>>
>> > >>>>> have
>> > >>>>
>> > >>>>> a
>> > >>>>>
>> > >>>>>> common groupId; the latter has the benefit that all
>> implementations,
>> > >>>>>> irrespective of whether they are core or not, have the same
>> groupId.
>> > >>>>>>
>> > >>>>> In
>> > >>>>
>> > >>>>> other words, does groupId represent a packaging, or does it
>> represent
>> > >>>>>> common functionality?
>> > >>>>>>
>> > >>>>>> In the wiki page shows, I've gone with the former. But I'm
>> 50:50 on
>> > >>>>>>
>> > >>>>> this
>> > >>>>
>> > >>>>> myself.
>> > >>>>>>
>> > >>>>>> ~~~
>> > >>>>>> Buried on the wiki page are some further questions: whether to
>> retire
>> > >>>>>>
>> > >>>>> the
>> > >>>>
>> > >>>>> html-viewer, the profilestore-xml, and the monitoring component.
>> My
>> > >>>>>> rationale for retiring html-viewer is that the wicket viewer is
>> > >>>>>>
>> > >>>>> similar
>> > >>>
>> > >>>> but
>> > >>>>>
>> > >>>>>> superior; I don't think profilestore-xml makes sense for webapp
>> > >>>>>>
>> > >>>>> viewers
>> > >>>
>> > >>>> (it
>> > >>>>>
>> > >>>>>> might have made sense for dnd viewer in client/server, but we've
>> > >>>>>>
>> > >>>>> already
>> > >>>>
>> > >>>>> removed remoting) ; and monitoring I think is a vestige of the
>> > >>>>>>
>> > >>>>> remoting
>> > >>>
>> > >>>> should also be removed. But we don't necessarily need to come to
>> an
>> > >>>>>> agreement on these points (though opinions would be good).
>> > >>>>>>
>> > >>>>>> Thanks, all
>> > >>>>>> Dan
>> > >>>>>>
>> > >>>>>> [1]
>> > >>>>>>
>> > >>>>>>
>> > >>>>>> https://cwiki.apache.org/**confluence/display/ISIS/Make+**
>> > >>> releases+easier+and+more+**frequent<
>> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
>> >
>> > >>>
>> > >>
>> > >
>> >
>>
>>
>> --
>> Kevin Meyer, PhD, Pr.Sci.Nat
>> KMZ P.O. Box 9822, Sharon Park, South Africa.
>> Tel: +27 11 363 2001 Cell: +27 83 346 3045
>>
>>
>>
>