[DISCUSSION] Making releases easier and more frequent

[Dan Haywood <da...@haywood-associates.co.uk>]

This discussion post is mostly to the contributors, but cc:ing to user list
for opinions also...

~~~

At the moment it's a daunting task to fully verify all the components of
the framework are working correctly prior to pushing out a release. I
suppose that wouldn't be so much of a concern if we had better automated
tests, but, hey, that's how things are.

Moreover, frankly, some of the modules are best considered spikes and
probably don't constitute something that we would consider
production-ready. Or, at least, they haven't been used in a real-world
context, so it's not possible to say whether they are really
fit-for-purpose. I include here quite a lot of the stuff that I have worked
on over the last few years, eg the wrapper-progmodel, the groovy progmodel,
probably also the JUnit viewer and BDD viewer. Now that we are a top-level
project, I'd like it that the code we put out is thought of as production
ready.

In order to make the framework easier to release, I propose that we use
Maven profiles to be able to release subsets of modules, that a given
contributor can stand behind and say: "yes, those modules are working and
are fit for general consumption". Each release would consist of the certain
core modules, along with selected additional viewers and object stores.

For example, over time we might end up releasing:

* v0.3.1 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
 // a "wicket/jdo release" - eg tested and released by Dan

* v0.4.0 core + objectstore-nosql + viewer-scimpi     // a "scimpi/nosql
release" - eg tested and released by Rob

* v0.5.0 core + objectstore-dflt + objectstore-xml + viewer-dnd     // a
"dev env release" - eg tested and released by Rob

* v0.6.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
// another "wicket/jdo release"

* v0.7.0 core + objectstore-sql + viewer-html     // a "html/sql release" -
eg tested and released by Kevin

* v0.8.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
// another "wicket/jdo release"

Whenever a release goes out, we would update our website to indicate the
most recent version of the components.

Now, when I say "release", what I actually mean here is the deployment of
binary artifacts up to the Maven central repo. This, after all, is what
most users/would-be users in the community would use and consider a
release. However, Apache's own formal definition of "release" is actually
the source code release ... this is what the [VOTE] mechanism is for. I
don't see this changing... the vote basically says that the software
complies with all the legal license stuff etc. The whole codebase is tagged
with that release number, and the generated src.zip is a zip of this
release.

One benefit of this is that it allows the deployment of other modules to be
performed "after the fact". For example, suppose that I (Dan) puts out the
v0.3.1 release as above, and then Rob later on tests the scimpi viewer in
that tag and finds it works well. He can (I think) push the release of the
scimpi viewer up to Maven central repo.

As I see things there are several benefits to this scheme:

a) (as already noted) the user community will only see binary releases that
are known to be of production ready. This should mitigate the "is it safe
to use this component" worry
b) (as hinted at) it should be possible for individual contributors to put
out releases of their modules more rapidly
c) we get visibility of which modules aren't being released; for example,
we might say that if a module hasn't been released by anyone for 18 or 24
months, say, then it's probably time to remove it from the codebase.

~~~

In order to support the above scheme, I propose that we rearrange some of
the modules so that they can be more easily included within Maven
modules.  I've
created a page on our wiki [1] which shows my proposed rearrangement.  It
also repeats the above discussion text by way of context.


Opinions welcome!

Thx

Dan


[1]
https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent

Re: [DISCUSSION] Making releases easier and more frequent

[Giovanni Júnior <gi...@gmail.com>]

+1 for o.a.isis.objectstore:dflt


2012/11/30 Dan Haywood <da...@haywood-associates.co.uk>

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

Re: [DISCUSSION] Making releases easier and more frequent

[Giovanni Júnior <gi...@gmail.com>]

+1 for each and every point

2012/11/30 Robert Matthews <rm...@nakedobjects.org>

> I've been looking through the wiki page again at the naming.  As a
> comparison here are some of the Maven modules:-
>
> GroupId                        ArtifactId
>
> org.apache.maven.shared     file-maven
> org.apache.maven.shared     management-archiver
> org.apache.maven.shared     maven-artifact-resolver
> org.apache.maven.shared     maven-common-artifact-filters
> org.apache.maven.shared     maven-dependency-analyzer
> org.apache.maven.shared     maven-doxia-tools
> org.apache.maven.shared     maven-filtering
> org.apache.maven.shared     maven-invoker
> org.apache.maven.shared     maven-repository-builder
>
>
> org.apache.maven.plugins    maven-antrun-plugin
> org.apache.maven.plugins    maven-assembly-plugin
> org.apache.maven.plugins    maven-clean-plugin
> org.apache.maven.plugins    maven-compiler-plugin
> org.apache.maven.plugins    maven-dependency-plugin
> org.apache.maven.plugins    maven-deploy-plugin
> org.apache.maven.plugins    maven-docck-plugin
> org.apache.maven.plugins    maven-enforcer-plugin
> org.apache.maven.plugins    maven-failsafe-plugin
>
> When I look at this list, several things strike me:-
>
> 1) on the whole it's clean and consice, yet clear what each module is.
> 2) the artifact id tells me everything I want to know about that module:
> it tells me that it's part of Maven; whether it's a core part or a plugin;
> and what the module is for.  The group id actually adds nothing, it just
> indicates who's responsible for that module.
> 3) the artifact ids read easily, for example, the maven-compiler-plugin is
> the Maven compiler plugin (as we say in the UK it does what it says on the
> tin).
>
> After these observation I would like to suggest the following:-
>
> 1) we don't need a proliferation of group ids - is it part of the core or
> not.
> 2) the names we use should read clearly, the JDO module is an object
> store, so say that - ie., isis-jdo-objectstore, and not
> isis-objectstore-jdo. Also this groups the components that use the same
> technology, eg isis-sql-objectstore, isis-sql-security and
> isis-sql-profilestore all reflect my choice to use a SQL database (if I'm
> using SQL persistence then I probably want to use it for everything).
> 3) non-standard abbreviations should be avoided. Can we call default
> modules "default" rather than "dflt". I know you can't do the same thing
> for package names, but that's fine. An alternative is to use the term
> "fallback", "basic" or "simple".
>
> Not directly related, but I'm still not sure about the runtime modules.
> Actually I'm confused. What are they all about, what is a "runtime
> runtime"? When I look at the list of core Maven modules they seem to relate
> to my understanding of how Maven works. With Isis i just know I need
> everything to make it work.  Not a good advert for encouraging others to
> get involved in the core.
>
> Rob
>
> PS don't retire the XML store, I'm always making use of it.
>
>
>
>
> On 11/30/12 16:52, Dan Haywood wrote:
>
>> ... and, for the same reason, probably should add the component type there
>> also, as suggested by both Rob and Minto.  Else, "isis-sql" might be the
>> object store, or might be a security impl.
>>
>> I guess the artifactIds are a bit long as a result, but better that than
>> ambiguity and the possibility of clashes.
>>
>> On 30 November 2012 16:46, Dan Haywood <da...@haywood-associates.co.uk>
>> wrote:
>>
>> Ah, ok.  Yeah, that does make sense... I do indeed stand corrected.
>>>
>>> In that case, we probably should follow the convention of other
>>> frameworks.  Let me go update that wiki page now [1].
>>>
>>> Thx
>>> 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 16:43, Rafael Chaves <ra...@alphasimple.com> wrote:
>>>
>>> Dan, I never mentioned a manual process. In the process of packaging a
>>>> Java
>>>> app, the common scenario is that all dependencies are fetched and placed
>>>> in
>>>> a single directory (for instance, the WEB-INF/lib dir for JEE webapps).
>>>> Once a Java application is packaged, Maven groups disappear. No
>>>> surprise,
>>>> since Maven is a development/build time tool only. It is then that a
>>>> common
>>>> prefix makes a big difference.
>>>>
>>>> Hope it was clear now. Cheers,
>>>>
>>>> Rafael
>>>>
>>>> A J2EE webapp I know fetches As part of the build process all the
>>>> dependencies used by the application (be it a web app, are
>>>> (automatically)
>>>> fetched into
>>>>
>>>> On Fri, Nov 30, 2012 at 8:31 AM, Dan Haywood
>>>> <da...@haywood-associates.co.uk>**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>
>>>>
>>>
>>>
>

Re: [DISCUSSION] Making releases easier and more frequent

[Dan Haywood <da...@haywood-associates.co.uk>]

good points, Rob.  Within...

On 30 November 2012 19:24, Robert Matthews <rm...@nakedobjects.org>wrote:

> I've been looking through the wiki page again at the naming.  As a
> comparison here are some of the Maven modules:-
>
>
> When I look at this list, several things strike me:-
>
> 1) on the whole it's clean and consice, yet clear what each module is.
> 2) the artifact id tells me everything I want to know about that module:
> it tells me that it's part of Maven; whether it's a core part or a plugin;
> and what the module is for.  The group id actually adds nothing, it just
> indicates who's responsible for that module.
> 3) the artifact ids read easily, for example, the maven-compiler-plugin is
> the Maven compiler plugin (as we say in the UK it does what it says on the
> tin).
>
>
ok, I take all that on board.




> After these observation I would like to suggest the following:-
>
> 1) we don't need a proliferation of group ids - is it part of the core or
> not.
>

OK, but I do think we could be a little bit more descriptive.  I would like
to suggest it's either core, or its an objectstore, or its a viewer etc...
 (More on this in a subsequent post to this thread).



> 2) the names we use should read clearly, the JDO module is an object
> store, so say that - ie., isis-jdo-objectstore, and not
> isis-objectstore-jdo. Also this groups the components that use the same
> technology, eg isis-sql-objectstore, isis-sql-security and
> isis-sql-profilestore all reflect my choice to use a SQL database (if I'm
> using SQL persistence then I probably want to use it for everything).
>

OK, I take that on board.

However, in terms of directory names, I do have a preference for the
component-type format (eg objectstore-jdo).  That means that when I do an
"ls" or a "dir", that things are not a complete jumble.



> 3) non-standard abbreviations should be avoided. Can we call default
> modules "default" rather than "dflt". I know you can't do the same thing
> for package names, but that's fine. An alternative is to use the term
> "fallback", "basic" or "simple".
>

OK.  See subsequent post where I've updated the wiki page once more.  I
have now banished "dflt", in favour of choosing names that are more
descriptive.



>
> Not directly related, but I'm still not sure about the runtime modules.
> Actually I'm confused. What are they all about, what is a "runtime
> runtime"? When I look at the list of core Maven modules they seem to relate
> to my understanding of how Maven works. With Isis i just know I need
> everything to make it work.  Not a good advert for encouraging others to
> get involved in the core.
>

OK, and so this is a concern to me.  If you - who after all, wrote lots of
the original code - are confused by the code structure, then that's a major
impediment to others grokking it.

I must take some of the blame here - I do know I have a tendency to
overcomplicate on occasion.

So, see my next posting where I've tried to address this ... by
consolidating a number of the modules that are probably just too
fine-grained.


> Rob
>
> PS don't retire the XML store, I'm always making use of it.
>
> OK. I made a mistake in the wiki... intended to say should we retire just
the XML *profile* store.  Any component being actively used should of
course live on.



>
>
>
> On 11/30/12 16:52, Dan Haywood wrote:
>
>> ... and, for the same reason, probably should add the component type there
>> also, as suggested by both Rob and Minto.  Else, "isis-sql" might be the
>> object store, or might be a security impl.
>>
>> I guess the artifactIds are a bit long as a result, but better that than
>> ambiguity and the possibility of clashes.
>>
>> On 30 November 2012 16:46, Dan Haywood <da...@haywood-associates.co.uk>
>> wrote:
>>
>>  Ah, ok.  Yeah, that does make sense... I do indeed stand corrected.
>>>
>>> In that case, we probably should follow the convention of other
>>> frameworks.  Let me go update that wiki page now [1].
>>>
>>> Thx
>>> 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 16:43, Rafael Chaves <ra...@alphasimple.com> wrote:
>>>
>>>  Dan, I never mentioned a manual process. In the process of packaging a
>>>> Java
>>>> app, the common scenario is that all dependencies are fetched and placed
>>>> in
>>>> a single directory (for instance, the WEB-INF/lib dir for JEE webapps).
>>>> Once a Java application is packaged, Maven groups disappear. No
>>>> surprise,
>>>> since Maven is a development/build time tool only. It is then that a
>>>> common
>>>> prefix makes a big difference.
>>>>
>>>> Hope it was clear now. Cheers,
>>>>
>>>> Rafael
>>>>
>>>> A J2EE webapp I know fetches As part of the build process all the
>>>> dependencies used by the application (be it a web app, are
>>>> (automatically)
>>>> fetched into
>>>>
>>>> On Fri, Nov 30, 2012 at 8:31 AM, Dan Haywood
>>>> <da...@haywood-associates.co.uk>**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>
>>>>
>>>
>>>
>

Re: [DISCUSSION] Making releases easier and more frequent

[Robert Matthews <rm...@nakedobjects.org>]

I've been looking through the wiki page again at the naming.  As a 
comparison here are some of the Maven modules:-

GroupId                        ArtifactId

org.apache.maven.shared     file-maven
org.apache.maven.shared     management-archiver
org.apache.maven.shared     maven-artifact-resolver
org.apache.maven.shared     maven-common-artifact-filters
org.apache.maven.shared     maven-dependency-analyzer
org.apache.maven.shared     maven-doxia-tools
org.apache.maven.shared     maven-filtering
org.apache.maven.shared     maven-invoker
org.apache.maven.shared     maven-repository-builder


org.apache.maven.plugins    maven-antrun-plugin
org.apache.maven.plugins    maven-assembly-plugin
org.apache.maven.plugins    maven-clean-plugin
org.apache.maven.plugins    maven-compiler-plugin
org.apache.maven.plugins    maven-dependency-plugin
org.apache.maven.plugins    maven-deploy-plugin
org.apache.maven.plugins    maven-docck-plugin
org.apache.maven.plugins    maven-enforcer-plugin
org.apache.maven.plugins    maven-failsafe-plugin

When I look at this list, several things strike me:-

1) on the whole it's clean and consice, yet clear what each module is.
2) the artifact id tells me everything I want to know about that module: 
it tells me that it's part of Maven; whether it's a core part or a 
plugin; and what the module is for.  The group id actually adds nothing, 
it just indicates who's responsible for that module.
3) the artifact ids read easily, for example, the maven-compiler-plugin 
is the Maven compiler plugin (as we say in the UK it does what it says 
on the tin).

After these observation I would like to suggest the following:-

1) we don't need a proliferation of group ids - is it part of the core 
or not.
2) the names we use should read clearly, the JDO module is an object 
store, so say that - ie., isis-jdo-objectstore, and not 
isis-objectstore-jdo. Also this groups the components that use the same 
technology, eg isis-sql-objectstore, isis-sql-security and 
isis-sql-profilestore all reflect my choice to use a SQL database (if 
I'm using SQL persistence then I probably want to use it for everything).
3) non-standard abbreviations should be avoided. Can we call default 
modules "default" rather than "dflt". I know you can't do the same thing 
for package names, but that's fine. An alternative is to use the term 
"fallback", "basic" or "simple".

Not directly related, but I'm still not sure about the runtime modules. 
Actually I'm confused. What are they all about, what is a "runtime 
runtime"? When I look at the list of core Maven modules they seem to 
relate to my understanding of how Maven works. With Isis i just know I 
need everything to make it work.  Not a good advert for encouraging 
others to get involved in the core.

Rob

PS don't retire the XML store, I'm always making use of it.



On 11/30/12 16:52, Dan Haywood wrote:
> ... and, for the same reason, probably should add the component type there
> also, as suggested by both Rob and Minto.  Else, "isis-sql" might be the
> object store, or might be a security impl.
>
> I guess the artifactIds are a bit long as a result, but better that than
> ambiguity and the possibility of clashes.
>
> On 30 November 2012 16:46, Dan Haywood <da...@haywood-associates.co.uk> wrote:
>
>> Ah, ok.  Yeah, that does make sense... I do indeed stand corrected.
>>
>> In that case, we probably should follow the convention of other
>> frameworks.  Let me go update that wiki page now [1].
>>
>> Thx
>> Dan
>>
>> [1]
>> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
>>
>>
>>
>> On 30 November 2012 16:43, Rafael Chaves <ra...@alphasimple.com> wrote:
>>
>>> Dan, I never mentioned a manual process. In the process of packaging a
>>> Java
>>> app, the common scenario is that all dependencies are fetched and placed
>>> in
>>> a single directory (for instance, the WEB-INF/lib dir for JEE webapps).
>>> Once a Java application is packaged, Maven groups disappear. No surprise,
>>> since Maven is a development/build time tool only. It is then that a
>>> common
>>> prefix makes a big difference.
>>>
>>> Hope it was clear now. Cheers,
>>>
>>> Rafael
>>>
>>> A J2EE webapp I know fetches As part of the build process all the
>>> dependencies used by the application (be it a web app, are (automatically)
>>> fetched into
>>>
>>> On Fri, Nov 30, 2012 at 8:31 AM, Dan Haywood
>>> <da...@haywood-associates.co.uk>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
>>

Re: [DISCUSSION] Making releases easier and more frequent

[Dan Haywood <da...@haywood-associates.co.uk>]

... and, for the same reason, probably should add the component type there
also, as suggested by both Rob and Minto.  Else, "isis-sql" might be the
object store, or might be a security impl.

I guess the artifactIds are a bit long as a result, but better that than
ambiguity and the possibility of clashes.

On 30 November 2012 16:46, Dan Haywood <da...@haywood-associates.co.uk> wrote:

> Ah, ok.  Yeah, that does make sense... I do indeed stand corrected.
>
> In that case, we probably should follow the convention of other
> frameworks.  Let me go update that wiki page now [1].
>
> Thx
> Dan
>
> [1]
> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
>
>
>
> On 30 November 2012 16:43, Rafael Chaves <ra...@alphasimple.com> wrote:
>
>> Dan, I never mentioned a manual process. In the process of packaging a
>> Java
>> app, the common scenario is that all dependencies are fetched and placed
>> in
>> a single directory (for instance, the WEB-INF/lib dir for JEE webapps).
>> Once a Java application is packaged, Maven groups disappear. No surprise,
>> since Maven is a development/build time tool only. It is then that a
>> common
>> prefix makes a big difference.
>>
>> Hope it was clear now. Cheers,
>>
>> Rafael
>>
>> A J2EE webapp I know fetches As part of the build process all the
>> dependencies used by the application (be it a web app, are (automatically)
>> fetched into
>>
>> On Fri, Nov 30, 2012 at 8:31 AM, Dan Haywood
>> <da...@haywood-associates.co.uk>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
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>

Re: [DISCUSSION] Making releases easier and more frequent

[Dan Haywood <da...@haywood-associates.co.uk>]

... and, for the same reason, probably should add the component type there
also, as suggested by both Rob and Minto.  Else, "isis-sql" might be the
object store, or might be a security impl.

I guess the artifactIds are a bit long as a result, but better that than
ambiguity and the possibility of clashes.

On 30 November 2012 16:46, Dan Haywood <da...@haywood-associates.co.uk> wrote:

> Ah, ok.  Yeah, that does make sense... I do indeed stand corrected.
>
> In that case, we probably should follow the convention of other
> frameworks.  Let me go update that wiki page now [1].
>
> Thx
> Dan
>
> [1]
> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
>
>
>
> On 30 November 2012 16:43, Rafael Chaves <ra...@alphasimple.com> wrote:
>
>> Dan, I never mentioned a manual process. In the process of packaging a
>> Java
>> app, the common scenario is that all dependencies are fetched and placed
>> in
>> a single directory (for instance, the WEB-INF/lib dir for JEE webapps).
>> Once a Java application is packaged, Maven groups disappear. No surprise,
>> since Maven is a development/build time tool only. It is then that a
>> common
>> prefix makes a big difference.
>>
>> Hope it was clear now. Cheers,
>>
>> Rafael
>>
>> A J2EE webapp I know fetches As part of the build process all the
>> dependencies used by the application (be it a web app, are (automatically)
>> fetched into
>>
>> On Fri, Nov 30, 2012 at 8:31 AM, Dan Haywood
>> <da...@haywood-associates.co.uk>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
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>

Re: [DISCUSSION] Making releases easier and more frequent

[Dan Haywood <da...@haywood-associates.co.uk>]

Ah, ok.  Yeah, that does make sense... I do indeed stand corrected.

In that case, we probably should follow the convention of other frameworks.
 Let me go update that wiki page now [1].

Thx
Dan

[1]
https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent


On 30 November 2012 16:43, Rafael Chaves <ra...@alphasimple.com> wrote:

> Dan, I never mentioned a manual process. In the process of packaging a Java
> app, the common scenario is that all dependencies are fetched and placed in
> a single directory (for instance, the WEB-INF/lib dir for JEE webapps).
> Once a Java application is packaged, Maven groups disappear. No surprise,
> since Maven is a development/build time tool only. It is then that a common
> prefix makes a big difference.
>
> Hope it was clear now. Cheers,
>
> Rafael
>
> A J2EE webapp I know fetches As part of the build process all the
> dependencies used by the application (be it a web app, are (automatically)
> fetched into
>
> On Fri, Nov 30, 2012 at 8:31 AM, Dan Haywood
> <da...@haywood-associates.co.uk>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
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSSION] Making releases easier and more frequent

[Dan Haywood <da...@haywood-associates.co.uk>]

Ah, ok.  Yeah, that does make sense... I do indeed stand corrected.

In that case, we probably should follow the convention of other frameworks.
 Let me go update that wiki page now [1].

Thx
Dan

[1]
https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent


On 30 November 2012 16:43, Rafael Chaves <ra...@alphasimple.com> wrote:

> Dan, I never mentioned a manual process. In the process of packaging a Java
> app, the common scenario is that all dependencies are fetched and placed in
> a single directory (for instance, the WEB-INF/lib dir for JEE webapps).
> Once a Java application is packaged, Maven groups disappear. No surprise,
> since Maven is a development/build time tool only. It is then that a common
> prefix makes a big difference.
>
> Hope it was clear now. Cheers,
>
> Rafael
>
> A J2EE webapp I know fetches As part of the build process all the
> dependencies used by the application (be it a web app, are (automatically)
> fetched into
>
> On Fri, Nov 30, 2012 at 8:31 AM, Dan Haywood
> <da...@haywood-associates.co.uk>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
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSSION] Making releases easier and more frequent

[Rafael Chaves <ra...@alphasimple.com>]

Dan, I never mentioned a manual process. In the process of packaging a Java
app, the common scenario is that all dependencies are fetched and placed in
a single directory (for instance, the WEB-INF/lib dir for JEE webapps).
Once a Java application is packaged, Maven groups disappear. No surprise,
since Maven is a development/build time tool only. It is then that a common
prefix makes a big difference.

Hope it was clear now. Cheers,

Rafael

A J2EE webapp I know fetches As part of the build process all the
dependencies used by the application (be it a web app, are (automatically)
fetched into

On Fri, Nov 30, 2012 at 8:31 AM, Dan Haywood
<da...@haywood-associates.co.uk>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
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSSION] Making releases easier and more frequent

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[Dan Haywood <da...@haywood-associates.co.uk>]

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

[Dan Haywood <da...@haywood-associates.co.uk>]

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

[Kevin Meyer - KMZ <ke...@kmz.co.za>]

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

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

[Kevin Meyer - KMZ <ke...@kmz.co.za>]

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

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

[Dan Haywood <da...@haywood-associates.co.uk>]

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

Re: [DISCUSSION] Making releases easier and more frequent

[Dan Haywood <da...@haywood-associates.co.uk>]

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

Re: [DISCUSSION] Making releases easier and more frequent

[Robert Matthews <rm...@nakedobjects.org>]

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

Re: [DISCUSSION] Making releases easier and more frequent

[Dan Haywood <da...@haywood-associates.co.uk>]

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

Re: [DISCUSSION] Making releases easier and more frequent

[Dan Haywood <da...@haywood-associates.co.uk>]

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

Re: [DISCUSSION] Making releases easier and more frequent

[Rafael Chaves <ra...@alphasimple.com>]

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

Re: [DISCUSSION] Making releases easier and more frequent

[Rafael Chaves <ra...@alphasimple.com>]

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

Re: [DISCUSSION] Making releases easier and more frequent

[Dan Haywood <da...@haywood-associates.co.uk>]

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

Re: [DISCUSSION] Making releases easier and more frequent

[Dan Haywood <da...@haywood-associates.co.uk>]

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

Re: [DISCUSSION] Making releases easier and more frequent

[Rafael Chaves <ra...@alphasimple.com>]

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
>

Re: [DISCUSSION] Making releases easier and more frequent

[Giovanni Júnior <gi...@gmail.com>]

+1 for o.a.isis.objectstore:dflt


2012/11/30 Dan Haywood <da...@haywood-associates.co.uk>

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

Re: [DISCUSSION] Making releases easier and more frequent

[Dan Haywood <da...@haywood-associates.co.uk>]

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

Re: [DISCUSSION] Making releases easier and more frequent

[Dan Haywood <da...@haywood-associates.co.uk>]

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

Re: [DISCUSSION] Making releases easier and more frequent

[Dan Haywood <da...@haywood-associates.co.uk>]

On 30 November 2012 08:19, Minto van der Sluis <mi...@xup.nl> wrote:

>
> Wouldn't is be better to separate components in objstores en viewers?
> Like this:
>
> org.apache.isis.objstores          isis-objstore-sql
> org.apache.isis.objstores          isis-objstore-jdo
> org.apache.isis.objstores          isis-objstore-nosql
> org.apache.isis.objstores          isis-objstore-xxxxxx
> org.apache.isis.viewers             isis-viewer-wicket
> org.apache.isis.viewers             isis-viewer-restful
> org.apache.isis.viewers             isis-viewer-html
> org.apache.isis.viewers             isis-viewer-dnd
> org.apache.isis.viewers             isis-viewer-scimpi
> org.apache.isis.viewers             isis-viewer-xxxxxx
>
>
Yes, I was thinking that too.  Unlike Maven, that really only has one sort
of plugin type, Isis has several (objectstores, viewer being the most
significant).




> Also is security really part of the core? Or could it be like:
>

Well, it is, yes.  In that there mus always be an authenticaiton manager
and authorization manager; the 'dflt' impls are basically no-ops, allowing
everything through.



>
> org.apache.isis.security                isis-security-default
> org.apache.isis.security                isis-security-file
> org.apache.isis.security                isis-security-xxxxxx
>
>
I think we should have security as a separate component type, analogous to
viewer and objectstore.

It sounds like there's an appetite to change these module names.  I didn't
really want to do that, because to do it properly also requires us changing
the package names, which is a big and tedious job.  But perhaps as a first
pass we can alter the groupIds and artifactIds.

Let me go back to the wiki page and collate these ideas, then go round the
loop again.

Dan



> Regards,
>
> MInto
>
> Op 29-11-2012 23:38, Robert Matthews schreef:
> > +1 for me. We'd also need a repo for the DnD.
> >
> > +1 for what Jeroen suggested also.
> >
> > While we are doing this it would be good to improve the module
> > naming/identification.  I have just had a look at the Maven project
> > (see http://maven.apache.org/shared/index.html and
> > http://maven.apache.org/plugin-management.html) and if we followed
> > there lead our modules would look something like this:-
> >
> > GroupId                                ArtifactId
> > -------                             ----------
> >
> > org.apache.isis.core                isis-applib
> >
> > org.apache.isis.core                isis-core
> > org.apache.isis.core                isis-bytecode
> > org.apache.isis.core                isis-runtime
> > org.apache.isis.core                isis-testsupport
> > org.apache.isis.core                isis-webapp
> > org.apache.isis.core                isis-webserver
> > org.apache.isis.core                isis-progmodel
> > org.apache.isis.core                isis-default-progmodel
> > org.apache.isis.core                isis-default-security
> > org.apache.isis.core                isis-file-security
> > org.apache.isis.core                isis-compatibility (was tck)
> > org.apache.isis.core                isis-xxxxxx
> >
> >
> > org.apache.isis.components          isis-sql-objectstore
> > org.apache.isis.components          isis-jdo-objectstore
> > org.apache.isis.components          isis-nosql-objectstore
> > org.apache.isis.components          isis-xxxxxx-objectstore
> > org.apache.isis.components          isis-wicket-viewer
> > org.apache.isis.components          isis-restful-viewer
> > org.apache.isis.components          isis-html-viewer
> > org.apache.isis.components          isis-dnd-viewer
> > org.apache.isis.components          isis-scimpi-viewer
> > org.apache.isis.components          isis-xxxxxx-viewer
> >
> >
> > org.apache.isis.editions            isis-quickstart-edition
> > org.apache.isis.editions            isis-modeller-edition
> > org.apache.isis.editions            isis-webapp-edition
> > org.apache.isis.editions            isis-xxxxxx-edition
> >
> > How does that look?
> >
> > Rob
> >
> >
> > On 11/29/12 20:20, Dan Haywood wrote:
> >> Hi Rob,
> >>
> >> Thanks for these thoughts... sounds like we are somewhat in the same
> >> boat
> >> in that we want to push out new releases, but don't know enough about
> >> the
> >> (state of the) other modules to know whether it is safe to do so.
> >>
> >> And so, yes, breaking up the codebase into separate submodules is the
> >> obvious next step, and something that you and I have discussed several
> >> times in the past off-list.  I don't have any issue with doing it
> >> myself,
> >> it's an obvious evolution from my proposal.
> >>
> >> The concept of an edition, then, I think equates to an archetype: it's a
> >> project template to get a would-be used up-and-running quickly with a
> >> precanned set of modules.
> >>
> >> What I therefore suggest is that we:
> >>
> >> 1. wait for Infra to move our code from svn to git (soon, I hope...)
> >> 2. flatten out the modules as I outlined in the wiki page
> >> 3. raise another ticket for infra to create new repos for each of the
> >> modules that we want to release separately... seems to me that these
> >> could
> >> start out as clones of the original
> >> 4. when those new submodule repos exist, we can zap remove all the
> >> foreign
> >> stuff; conversely, in the original repo, we zap the code for which there
> >> are now submodule repos
> >>
> >> The new repos that I see us needing are:
> >> - viewer-wicket
> >> - viewer-scimpi
> >> - viewer-restful
> >> - viewer-html
> >> - objectstore-jdo
> >> - objectstore-nosql
> >> - objectstore-sql
> >> - editions                   // for the various archetypes we might
> >> want to
> >> create.
> >>
> >> For the other modules that are not core (eg progmodel-groovy, or
> >> viewer-junit), I'd rather leave them in the "default" repo, but not
> >> release
> >> them until there is a need.  For these we can use a Maven profile to
> >> exclude them from the release process.
> >>
> >> Although overall this introduces a little bit more formality into the
> >> proceedings, I do think that the time is now right to do this.  And, I
> >> think it properly answers all the objections that Giovanni raised
> >> earlier
> >> in this thread.
> >>
> >> What say we all?
> >>
> >> Dan
> >>
> >>
> >> On 29 November 2012 20:00, Robert Matthews
> >> <rm...@nakedobjects.org>wrote:
> >>
> >>> First and foremost, I think we should release things more granularly so
> >>> individual components (most of our Maven modules) can be worked on more
> >>> independently. I would find it great to be able to work on improving
> >>> the
> >>> NOSQL store or the Scimpi viewer without having to consider that every
> >>> other module has to be got into a releasable state just so one ready
> >>> module
> >>> can be released.  Most of the modules, outside of the core,  are fairly
> >>> independent, typically relying only on the core and will work other
> >>> versions of other components, eg a viewer is not typically dependent
> >>> on an
> >>> object store. Basically, we have the core modules, which need to be
> >>> maintained and released together, then we have a whole pile of major
> >>> component, mostly that can be developed independently.
> >>>
> >>> The "editions", as I think someone referred to them, are a
> >>> combination of
> >>> the components that are useful together, but are just that. They are
> >>> lightweight, just specifying how to pull those components together and
> >>> providing supporting resources like examples, configurations and extra
> >>> documentation.  Think of these like Linux distributions, they pull
> >>> together
> >>> a host of programs together to create a, sometimes unique, set up.  The
> >>> distribution is just a collation of all the programs along with the
> >>> installer, some specific graphics and preconfigured settings. The
> >>> programs
> >>> themselves are developed, and also available,  separately.
> >>>
> >>> Instead of keeping it all monolithic and using profiles to control
> >>> what is
> >>> released (and what isn't) I think we should break it up into:-
> >>>
> >>>      A "Core"
> >>>      Individual "Components" (viewer, object stores etc)
> >>>      Specially targetted "Editions" (SOA, Web Framework, Modeller's
> >>> toolbox
> >>> etc)
> >>>
> >>> This would obviously affect both the organisation of the code and be
> >>> reflected in the site as a series of subprojects (like a number of
> >>> Apache
> >>> project do, like James, Maven, Velocity and Xerces).
> >>>
> >>> (Doesn't Eclipse actually something just like this - they have a core,
> >>> there are are series of components that work with it and they provide
> >>> different "editions" that target different types of user.)
> >>>
> >>> Another benefit of working this way is that a (new) developer can
> >>> concentrate on a single component, i.e., check out a small amount of
> >>> code,
> >>> use Maven to sort of the dependencies to other framework classes, which
> >>> will download the jars and then focus on just that one module.
> >>>
> >>> Just a few thoughts.
> >>>
> >>> Regards
> >>>
> >>> Rob
> >>>
> >>>
> >>>
> >>>
> >>> On 11/29/12 14:36, Dan Haywood wrote:
> >>>
> >>>> This discussion post is mostly to the contributors, but cc:ing to user
> >>>> list
> >>>> for opinions also...
> >>>>
> >>>> ~~~
> >>>>
> >>>> At the moment it's a daunting task to fully verify all the
> >>>> components of
> >>>> the framework are working correctly prior to pushing out a release. I
> >>>> suppose that wouldn't be so much of a concern if we had better
> >>>> automated
> >>>> tests, but, hey, that's how things are.
> >>>>
> >>>> Moreover, frankly, some of the modules are best considered spikes and
> >>>> probably don't constitute something that we would consider
> >>>> production-ready. Or, at least, they haven't been used in a real-world
> >>>> context, so it's not possible to say whether they are really
> >>>> fit-for-purpose. I include here quite a lot of the stuff that I have
> >>>> worked
> >>>> on over the last few years, eg the wrapper-progmodel, the groovy
> >>>> progmodel,
> >>>> probably also the JUnit viewer and BDD viewer. Now that we are a
> >>>> top-level
> >>>> project, I'd like it that the code we put out is thought of as
> >>>> production
> >>>> ready.
> >>>>
> >>>> In order to make the framework easier to release, I propose that we
> >>>> use
> >>>> Maven profiles to be able to release subsets of modules, that a given
> >>>> contributor can stand behind and say: "yes, those modules are
> >>>> working and
> >>>> are fit for general consumption". Each release would consist of the
> >>>> certain
> >>>> core modules, along with selected additional viewers and object
> >>>> stores.
> >>>>
> >>>> For example, over time we might end up releasing:
> >>>>
> >>>> * v0.3.1 core + objectstore-jdo + viewer-wicket +
> >>>> viewer-restfulobjects
> >>>>    // a "wicket/jdo release" - eg tested and released by Dan
> >>>>
> >>>> * v0.4.0 core + objectstore-nosql + viewer-scimpi     // a
> >>>> "scimpi/nosql
> >>>> release" - eg tested and released by Rob
> >>>>
> >>>> * v0.5.0 core + objectstore-dflt + objectstore-xml + viewer-dnd
> >>>> // a
> >>>> "dev env release" - eg tested and released by Rob
> >>>>
> >>>> * v0.6.0 core + objectstore-jdo + viewer-wicket +
> >>>> viewer-restfulobjects
> >>>> // another "wicket/jdo release"
> >>>>
> >>>> * v0.7.0 core + objectstore-sql + viewer-html     // a "html/sql
> >>>> release"
> >>>> -
> >>>> eg tested and released by Kevin
> >>>>
> >>>> * v0.8.0 core + objectstore-jdo + viewer-wicket +
> >>>> viewer-restfulobjects
> >>>> // another "wicket/jdo release"
> >>>>
> >>>> Whenever a release goes out, we would update our website to
> >>>> indicate the
> >>>> most recent version of the components.
> >>>>
> >>>> Now, when I say "release", what I actually mean here is the
> >>>> deployment of
> >>>> binary artifacts up to the Maven central repo. This, after all, is
> >>>> what
> >>>> most users/would-be users in the community would use and consider a
> >>>> release. However, Apache's own formal definition of "release" is
> >>>> actually
> >>>> the source code release ... this is what the [VOTE] mechanism is
> >>>> for. I
> >>>> don't see this changing... the vote basically says that the software
> >>>> complies with all the legal license stuff etc. The whole codebase is
> >>>> tagged
> >>>> with that release number, and the generated src.zip is a zip of this
> >>>> release.
> >>>>
> >>>> One benefit of this is that it allows the deployment of other
> >>>> modules to
> >>>> be
> >>>> performed "after the fact". For example, suppose that I (Dan) puts
> >>>> out the
> >>>> v0.3.1 release as above, and then Rob later on tests the scimpi
> >>>> viewer in
> >>>> that tag and finds it works well. He can (I think) push the release
> >>>> of the
> >>>> scimpi viewer up to Maven central repo.
> >>>>
> >>>> As I see things there are several benefits to this scheme:
> >>>>
> >>>> a) (as already noted) the user community will only see binary releases
> >>>> that
> >>>> are known to be of production ready. This should mitigate the "is
> >>>> it safe
> >>>> to use this component" worry
> >>>> b) (as hinted at) it should be possible for individual contributors
> >>>> to put
> >>>> out releases of their modules more rapidly
> >>>> c) we get visibility of which modules aren't being released; for
> >>>> example,
> >>>> we might say that if a module hasn't been released by anyone for 18
> >>>> or 24
> >>>> months, say, then it's probably time to remove it from the codebase.
> >>>>
> >>>> ~~~
> >>>>
> >>>> In order to support the above scheme, I propose that we rearrange
> >>>> some of
> >>>> the modules so that they can be more easily included within Maven
> >>>> modules.  I've
> >>>> created a page on our wiki [1] which shows my proposed
> >>>> rearrangement.  It
> >>>> also repeats the above discussion text by way of context.
> >>>>
> >>>>
> >>>> Opinions welcome!
> >>>>
> >>>> Thx
> >>>>
> >>>> 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
> >
> >>>>
> >>>>
> >>>>
> >
>
>
> --
> ir. ing. Minto van der Sluis
> Software innovator / renovator
> Xup BV
>
> Mobiel: +31 (0) 626 014541
>
>

Re: [DISCUSSION] Making releases easier and more frequent

[Minto van der Sluis <mi...@xup.nl>]

Wouldn't is be better to separate components in objstores en viewers?
Like this:

org.apache.isis.objstores          isis-objstore-sql
org.apache.isis.objstores          isis-objstore-jdo
org.apache.isis.objstores          isis-objstore-nosql
org.apache.isis.objstores          isis-objstore-xxxxxx
org.apache.isis.viewers             isis-viewer-wicket
org.apache.isis.viewers             isis-viewer-restful
org.apache.isis.viewers             isis-viewer-html
org.apache.isis.viewers             isis-viewer-dnd
org.apache.isis.viewers             isis-viewer-scimpi
org.apache.isis.viewers             isis-viewer-xxxxxx

Also is security really part of the core? Or could it be like:

org.apache.isis.security                isis-security-default
org.apache.isis.security                isis-security-file
org.apache.isis.security                isis-security-xxxxxx

Regards,

MInto

Op 29-11-2012 23:38, Robert Matthews schreef:
> +1 for me. We'd also need a repo for the DnD.
>
> +1 for what Jeroen suggested also.
>
> While we are doing this it would be good to improve the module
> naming/identification.  I have just had a look at the Maven project
> (see http://maven.apache.org/shared/index.html and
> http://maven.apache.org/plugin-management.html) and if we followed
> there lead our modules would look something like this:-
>
> GroupId                                ArtifactId
> -------                             ----------
>
> org.apache.isis.core                isis-applib
>
> org.apache.isis.core                isis-core
> org.apache.isis.core                isis-bytecode
> org.apache.isis.core                isis-runtime
> org.apache.isis.core                isis-testsupport
> org.apache.isis.core                isis-webapp
> org.apache.isis.core                isis-webserver
> org.apache.isis.core                isis-progmodel
> org.apache.isis.core                isis-default-progmodel
> org.apache.isis.core                isis-default-security
> org.apache.isis.core                isis-file-security
> org.apache.isis.core                isis-compatibility (was tck)
> org.apache.isis.core                isis-xxxxxx
>
>
> org.apache.isis.components          isis-sql-objectstore
> org.apache.isis.components          isis-jdo-objectstore
> org.apache.isis.components          isis-nosql-objectstore
> org.apache.isis.components          isis-xxxxxx-objectstore
> org.apache.isis.components          isis-wicket-viewer
> org.apache.isis.components          isis-restful-viewer
> org.apache.isis.components          isis-html-viewer
> org.apache.isis.components          isis-dnd-viewer
> org.apache.isis.components          isis-scimpi-viewer
> org.apache.isis.components          isis-xxxxxx-viewer
>
>
> org.apache.isis.editions            isis-quickstart-edition
> org.apache.isis.editions            isis-modeller-edition
> org.apache.isis.editions            isis-webapp-edition
> org.apache.isis.editions            isis-xxxxxx-edition
>
> How does that look?
>
> Rob
>
>
> On 11/29/12 20:20, Dan Haywood wrote:
>> Hi Rob,
>>
>> Thanks for these thoughts... sounds like we are somewhat in the same
>> boat
>> in that we want to push out new releases, but don't know enough about
>> the
>> (state of the) other modules to know whether it is safe to do so.
>>
>> And so, yes, breaking up the codebase into separate submodules is the
>> obvious next step, and something that you and I have discussed several
>> times in the past off-list.  I don't have any issue with doing it
>> myself,
>> it's an obvious evolution from my proposal.
>>
>> The concept of an edition, then, I think equates to an archetype: it's a
>> project template to get a would-be used up-and-running quickly with a
>> precanned set of modules.
>>
>> What I therefore suggest is that we:
>>
>> 1. wait for Infra to move our code from svn to git (soon, I hope...)
>> 2. flatten out the modules as I outlined in the wiki page
>> 3. raise another ticket for infra to create new repos for each of the
>> modules that we want to release separately... seems to me that these
>> could
>> start out as clones of the original
>> 4. when those new submodule repos exist, we can zap remove all the
>> foreign
>> stuff; conversely, in the original repo, we zap the code for which there
>> are now submodule repos
>>
>> The new repos that I see us needing are:
>> - viewer-wicket
>> - viewer-scimpi
>> - viewer-restful
>> - viewer-html
>> - objectstore-jdo
>> - objectstore-nosql
>> - objectstore-sql
>> - editions                   // for the various archetypes we might
>> want to
>> create.
>>
>> For the other modules that are not core (eg progmodel-groovy, or
>> viewer-junit), I'd rather leave them in the "default" repo, but not
>> release
>> them until there is a need.  For these we can use a Maven profile to
>> exclude them from the release process.
>>
>> Although overall this introduces a little bit more formality into the
>> proceedings, I do think that the time is now right to do this.  And, I
>> think it properly answers all the objections that Giovanni raised
>> earlier
>> in this thread.
>>
>> What say we all?
>>
>> Dan
>>
>>
>> On 29 November 2012 20:00, Robert Matthews
>> <rm...@nakedobjects.org>wrote:
>>
>>> First and foremost, I think we should release things more granularly so
>>> individual components (most of our Maven modules) can be worked on more
>>> independently. I would find it great to be able to work on improving
>>> the
>>> NOSQL store or the Scimpi viewer without having to consider that every
>>> other module has to be got into a releasable state just so one ready
>>> module
>>> can be released.  Most of the modules, outside of the core,  are fairly
>>> independent, typically relying only on the core and will work other
>>> versions of other components, eg a viewer is not typically dependent
>>> on an
>>> object store. Basically, we have the core modules, which need to be
>>> maintained and released together, then we have a whole pile of major
>>> component, mostly that can be developed independently.
>>>
>>> The "editions", as I think someone referred to them, are a
>>> combination of
>>> the components that are useful together, but are just that. They are
>>> lightweight, just specifying how to pull those components together and
>>> providing supporting resources like examples, configurations and extra
>>> documentation.  Think of these like Linux distributions, they pull
>>> together
>>> a host of programs together to create a, sometimes unique, set up.  The
>>> distribution is just a collation of all the programs along with the
>>> installer, some specific graphics and preconfigured settings. The
>>> programs
>>> themselves are developed, and also available,  separately.
>>>
>>> Instead of keeping it all monolithic and using profiles to control
>>> what is
>>> released (and what isn't) I think we should break it up into:-
>>>
>>>      A "Core"
>>>      Individual "Components" (viewer, object stores etc)
>>>      Specially targetted "Editions" (SOA, Web Framework, Modeller's
>>> toolbox
>>> etc)
>>>
>>> This would obviously affect both the organisation of the code and be
>>> reflected in the site as a series of subprojects (like a number of
>>> Apache
>>> project do, like James, Maven, Velocity and Xerces).
>>>
>>> (Doesn't Eclipse actually something just like this - they have a core,
>>> there are are series of components that work with it and they provide
>>> different "editions" that target different types of user.)
>>>
>>> Another benefit of working this way is that a (new) developer can
>>> concentrate on a single component, i.e., check out a small amount of
>>> code,
>>> use Maven to sort of the dependencies to other framework classes, which
>>> will download the jars and then focus on just that one module.
>>>
>>> Just a few thoughts.
>>>
>>> Regards
>>>
>>> Rob
>>>
>>>
>>>
>>>
>>> On 11/29/12 14:36, Dan Haywood wrote:
>>>
>>>> This discussion post is mostly to the contributors, but cc:ing to user
>>>> list
>>>> for opinions also...
>>>>
>>>> ~~~
>>>>
>>>> At the moment it's a daunting task to fully verify all the
>>>> components of
>>>> the framework are working correctly prior to pushing out a release. I
>>>> suppose that wouldn't be so much of a concern if we had better
>>>> automated
>>>> tests, but, hey, that's how things are.
>>>>
>>>> Moreover, frankly, some of the modules are best considered spikes and
>>>> probably don't constitute something that we would consider
>>>> production-ready. Or, at least, they haven't been used in a real-world
>>>> context, so it's not possible to say whether they are really
>>>> fit-for-purpose. I include here quite a lot of the stuff that I have
>>>> worked
>>>> on over the last few years, eg the wrapper-progmodel, the groovy
>>>> progmodel,
>>>> probably also the JUnit viewer and BDD viewer. Now that we are a
>>>> top-level
>>>> project, I'd like it that the code we put out is thought of as
>>>> production
>>>> ready.
>>>>
>>>> In order to make the framework easier to release, I propose that we
>>>> use
>>>> Maven profiles to be able to release subsets of modules, that a given
>>>> contributor can stand behind and say: "yes, those modules are
>>>> working and
>>>> are fit for general consumption". Each release would consist of the
>>>> certain
>>>> core modules, along with selected additional viewers and object
>>>> stores.
>>>>
>>>> For example, over time we might end up releasing:
>>>>
>>>> * v0.3.1 core + objectstore-jdo + viewer-wicket +
>>>> viewer-restfulobjects
>>>>    // a "wicket/jdo release" - eg tested and released by Dan
>>>>
>>>> * v0.4.0 core + objectstore-nosql + viewer-scimpi     // a
>>>> "scimpi/nosql
>>>> release" - eg tested and released by Rob
>>>>
>>>> * v0.5.0 core + objectstore-dflt + objectstore-xml + viewer-dnd    
>>>> // a
>>>> "dev env release" - eg tested and released by Rob
>>>>
>>>> * v0.6.0 core + objectstore-jdo + viewer-wicket +
>>>> viewer-restfulobjects
>>>> // another "wicket/jdo release"
>>>>
>>>> * v0.7.0 core + objectstore-sql + viewer-html     // a "html/sql
>>>> release"
>>>> -
>>>> eg tested and released by Kevin
>>>>
>>>> * v0.8.0 core + objectstore-jdo + viewer-wicket +
>>>> viewer-restfulobjects
>>>> // another "wicket/jdo release"
>>>>
>>>> Whenever a release goes out, we would update our website to
>>>> indicate the
>>>> most recent version of the components.
>>>>
>>>> Now, when I say "release", what I actually mean here is the
>>>> deployment of
>>>> binary artifacts up to the Maven central repo. This, after all, is
>>>> what
>>>> most users/would-be users in the community would use and consider a
>>>> release. However, Apache's own formal definition of "release" is
>>>> actually
>>>> the source code release ... this is what the [VOTE] mechanism is
>>>> for. I
>>>> don't see this changing... the vote basically says that the software
>>>> complies with all the legal license stuff etc. The whole codebase is
>>>> tagged
>>>> with that release number, and the generated src.zip is a zip of this
>>>> release.
>>>>
>>>> One benefit of this is that it allows the deployment of other
>>>> modules to
>>>> be
>>>> performed "after the fact". For example, suppose that I (Dan) puts
>>>> out the
>>>> v0.3.1 release as above, and then Rob later on tests the scimpi
>>>> viewer in
>>>> that tag and finds it works well. He can (I think) push the release
>>>> of the
>>>> scimpi viewer up to Maven central repo.
>>>>
>>>> As I see things there are several benefits to this scheme:
>>>>
>>>> a) (as already noted) the user community will only see binary releases
>>>> that
>>>> are known to be of production ready. This should mitigate the "is
>>>> it safe
>>>> to use this component" worry
>>>> b) (as hinted at) it should be possible for individual contributors
>>>> to put
>>>> out releases of their modules more rapidly
>>>> c) we get visibility of which modules aren't being released; for
>>>> example,
>>>> we might say that if a module hasn't been released by anyone for 18
>>>> or 24
>>>> months, say, then it's probably time to remove it from the codebase.
>>>>
>>>> ~~~
>>>>
>>>> In order to support the above scheme, I propose that we rearrange
>>>> some of
>>>> the modules so that they can be more easily included within Maven
>>>> modules.  I've
>>>> created a page on our wiki [1] which shows my proposed
>>>> rearrangement.  It
>>>> also repeats the above discussion text by way of context.
>>>>
>>>>
>>>> Opinions welcome!
>>>>
>>>> Thx
>>>>
>>>> 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>
>>>>
>>>>
>>>>
>


-- 
ir. ing. Minto van der Sluis
Software innovator / renovator
Xup BV

Mobiel: +31 (0) 626 014541

Re: [DISCUSSION] Making releases easier and more frequent

[Robert Matthews <rm...@nakedobjects.org>]

+1 for me. We'd also need a repo for the DnD.

+1 for what Jeroen suggested also.

While we are doing this it would be good to improve the module 
naming/identification.  I have just had a look at the Maven project (see 
http://maven.apache.org/shared/index.html and 
http://maven.apache.org/plugin-management.html) and if we followed there 
lead our modules would look something like this:-

GroupId                                ArtifactId
-------                             ----------

org.apache.isis.core                isis-applib

org.apache.isis.core                isis-core
org.apache.isis.core                isis-bytecode
org.apache.isis.core                isis-runtime
org.apache.isis.core                isis-testsupport
org.apache.isis.core                isis-webapp
org.apache.isis.core                isis-webserver
org.apache.isis.core                isis-progmodel
org.apache.isis.core                isis-default-progmodel
org.apache.isis.core                isis-default-security
org.apache.isis.core                isis-file-security
org.apache.isis.core                isis-compatibility (was tck)
org.apache.isis.core                isis-xxxxxx


org.apache.isis.components          isis-sql-objectstore
org.apache.isis.components          isis-jdo-objectstore
org.apache.isis.components          isis-nosql-objectstore
org.apache.isis.components          isis-xxxxxx-objectstore
org.apache.isis.components          isis-wicket-viewer
org.apache.isis.components          isis-restful-viewer
org.apache.isis.components          isis-html-viewer
org.apache.isis.components          isis-dnd-viewer
org.apache.isis.components          isis-scimpi-viewer
org.apache.isis.components          isis-xxxxxx-viewer


org.apache.isis.editions            isis-quickstart-edition
org.apache.isis.editions            isis-modeller-edition
org.apache.isis.editions            isis-webapp-edition
org.apache.isis.editions            isis-xxxxxx-edition

How does that look?

Rob


On 11/29/12 20:20, Dan Haywood wrote:
> Hi Rob,
>
> Thanks for these thoughts... sounds like we are somewhat in the same boat
> in that we want to push out new releases, but don't know enough about the
> (state of the) other modules to know whether it is safe to do so.
>
> And so, yes, breaking up the codebase into separate submodules is the
> obvious next step, and something that you and I have discussed several
> times in the past off-list.  I don't have any issue with doing it myself,
> it's an obvious evolution from my proposal.
>
> The concept of an edition, then, I think equates to an archetype: it's a
> project template to get a would-be used up-and-running quickly with a
> precanned set of modules.
>
> What I therefore suggest is that we:
>
> 1. wait for Infra to move our code from svn to git (soon, I hope...)
> 2. flatten out the modules as I outlined in the wiki page
> 3. raise another ticket for infra to create new repos for each of the
> modules that we want to release separately... seems to me that these could
> start out as clones of the original
> 4. when those new submodule repos exist, we can zap remove all the foreign
> stuff; conversely, in the original repo, we zap the code for which there
> are now submodule repos
>
> The new repos that I see us needing are:
> - viewer-wicket
> - viewer-scimpi
> - viewer-restful
> - viewer-html
> - objectstore-jdo
> - objectstore-nosql
> - objectstore-sql
> - editions                   // for the various archetypes we might want to
> create.
>
> For the other modules that are not core (eg progmodel-groovy, or
> viewer-junit), I'd rather leave them in the "default" repo, but not release
> them until there is a need.  For these we can use a Maven profile to
> exclude them from the release process.
>
> Although overall this introduces a little bit more formality into the
> proceedings, I do think that the time is now right to do this.  And, I
> think it properly answers all the objections that Giovanni raised earlier
> in this thread.
>
> What say we all?
>
> Dan
>
>
> On 29 November 2012 20:00, Robert Matthews <rm...@nakedobjects.org>wrote:
>
>> First and foremost, I think we should release things more granularly so
>> individual components (most of our Maven modules) can be worked on more
>> independently. I would find it great to be able to work on improving the
>> NOSQL store or the Scimpi viewer without having to consider that every
>> other module has to be got into a releasable state just so one ready module
>> can be released.  Most of the modules, outside of the core,  are fairly
>> independent, typically relying only on the core and will work other
>> versions of other components, eg a viewer is not typically dependent on an
>> object store. Basically, we have the core modules, which need to be
>> maintained and released together, then we have a whole pile of major
>> component, mostly that can be developed independently.
>>
>> The "editions", as I think someone referred to them, are a combination of
>> the components that are useful together, but are just that. They are
>> lightweight, just specifying how to pull those components together and
>> providing supporting resources like examples, configurations and extra
>> documentation.  Think of these like Linux distributions, they pull together
>> a host of programs together to create a, sometimes unique, set up.  The
>> distribution is just a collation of all the programs along with the
>> installer, some specific graphics and preconfigured settings. The programs
>> themselves are developed, and also available,  separately.
>>
>> Instead of keeping it all monolithic and using profiles to control what is
>> released (and what isn't) I think we should break it up into:-
>>
>>      A "Core"
>>      Individual "Components" (viewer, object stores etc)
>>      Specially targetted "Editions" (SOA, Web Framework, Modeller's toolbox
>> etc)
>>
>> This would obviously affect both the organisation of the code and be
>> reflected in the site as a series of subprojects (like a number of Apache
>> project do, like James, Maven, Velocity and Xerces).
>>
>> (Doesn't Eclipse actually something just like this - they have a core,
>> there are are series of components that work with it and they provide
>> different "editions" that target different types of user.)
>>
>> Another benefit of working this way is that a (new) developer can
>> concentrate on a single component, i.e., check out a small amount of code,
>> use Maven to sort of the dependencies to other framework classes, which
>> will download the jars and then focus on just that one module.
>>
>> Just a few thoughts.
>>
>> Regards
>>
>> Rob
>>
>>
>>
>>
>> On 11/29/12 14:36, Dan Haywood wrote:
>>
>>> This discussion post is mostly to the contributors, but cc:ing to user
>>> list
>>> for opinions also...
>>>
>>> ~~~
>>>
>>> At the moment it's a daunting task to fully verify all the components of
>>> the framework are working correctly prior to pushing out a release. I
>>> suppose that wouldn't be so much of a concern if we had better automated
>>> tests, but, hey, that's how things are.
>>>
>>> Moreover, frankly, some of the modules are best considered spikes and
>>> probably don't constitute something that we would consider
>>> production-ready. Or, at least, they haven't been used in a real-world
>>> context, so it's not possible to say whether they are really
>>> fit-for-purpose. I include here quite a lot of the stuff that I have
>>> worked
>>> on over the last few years, eg the wrapper-progmodel, the groovy
>>> progmodel,
>>> probably also the JUnit viewer and BDD viewer. Now that we are a top-level
>>> project, I'd like it that the code we put out is thought of as production
>>> ready.
>>>
>>> In order to make the framework easier to release, I propose that we use
>>> Maven profiles to be able to release subsets of modules, that a given
>>> contributor can stand behind and say: "yes, those modules are working and
>>> are fit for general consumption". Each release would consist of the
>>> certain
>>> core modules, along with selected additional viewers and object stores.
>>>
>>> For example, over time we might end up releasing:
>>>
>>> * v0.3.1 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
>>>    // a "wicket/jdo release" - eg tested and released by Dan
>>>
>>> * v0.4.0 core + objectstore-nosql + viewer-scimpi     // a "scimpi/nosql
>>> release" - eg tested and released by Rob
>>>
>>> * v0.5.0 core + objectstore-dflt + objectstore-xml + viewer-dnd     // a
>>> "dev env release" - eg tested and released by Rob
>>>
>>> * v0.6.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
>>> // another "wicket/jdo release"
>>>
>>> * v0.7.0 core + objectstore-sql + viewer-html     // a "html/sql release"
>>> -
>>> eg tested and released by Kevin
>>>
>>> * v0.8.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
>>> // another "wicket/jdo release"
>>>
>>> Whenever a release goes out, we would update our website to indicate the
>>> most recent version of the components.
>>>
>>> Now, when I say "release", what I actually mean here is the deployment of
>>> binary artifacts up to the Maven central repo. This, after all, is what
>>> most users/would-be users in the community would use and consider a
>>> release. However, Apache's own formal definition of "release" is actually
>>> the source code release ... this is what the [VOTE] mechanism is for. I
>>> don't see this changing... the vote basically says that the software
>>> complies with all the legal license stuff etc. The whole codebase is
>>> tagged
>>> with that release number, and the generated src.zip is a zip of this
>>> release.
>>>
>>> One benefit of this is that it allows the deployment of other modules to
>>> be
>>> performed "after the fact". For example, suppose that I (Dan) puts out the
>>> v0.3.1 release as above, and then Rob later on tests the scimpi viewer in
>>> that tag and finds it works well. He can (I think) push the release of the
>>> scimpi viewer up to Maven central repo.
>>>
>>> As I see things there are several benefits to this scheme:
>>>
>>> a) (as already noted) the user community will only see binary releases
>>> that
>>> are known to be of production ready. This should mitigate the "is it safe
>>> to use this component" worry
>>> b) (as hinted at) it should be possible for individual contributors to put
>>> out releases of their modules more rapidly
>>> c) we get visibility of which modules aren't being released; for example,
>>> we might say that if a module hasn't been released by anyone for 18 or 24
>>> months, say, then it's probably time to remove it from the codebase.
>>>
>>> ~~~
>>>
>>> In order to support the above scheme, I propose that we rearrange some of
>>> the modules so that they can be more easily included within Maven
>>> modules.  I've
>>> created a page on our wiki [1] which shows my proposed rearrangement.  It
>>> also repeats the above discussion text by way of context.
>>>
>>>
>>> Opinions welcome!
>>>
>>> Thx
>>>
>>> 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

[Robert Matthews <rm...@nakedobjects.org>]

+1 for me. We'd also need a repo for the DnD.

+1 for what Jeroen suggested also.

While we are doing this it would be good to improve the module 
naming/identification.  I have just had a look at the Maven project (see 
http://maven.apache.org/shared/index.html and 
http://maven.apache.org/plugin-management.html) and if we followed there 
lead our modules would look something like this:-

GroupId                                ArtifactId
-------                             ----------

org.apache.isis.core                isis-applib

org.apache.isis.core                isis-core
org.apache.isis.core                isis-bytecode
org.apache.isis.core                isis-runtime
org.apache.isis.core                isis-testsupport
org.apache.isis.core                isis-webapp
org.apache.isis.core                isis-webserver
org.apache.isis.core                isis-progmodel
org.apache.isis.core                isis-default-progmodel
org.apache.isis.core                isis-default-security
org.apache.isis.core                isis-file-security
org.apache.isis.core                isis-compatibility (was tck)
org.apache.isis.core                isis-xxxxxx


org.apache.isis.components          isis-sql-objectstore
org.apache.isis.components          isis-jdo-objectstore
org.apache.isis.components          isis-nosql-objectstore
org.apache.isis.components          isis-xxxxxx-objectstore
org.apache.isis.components          isis-wicket-viewer
org.apache.isis.components          isis-restful-viewer
org.apache.isis.components          isis-html-viewer
org.apache.isis.components          isis-dnd-viewer
org.apache.isis.components          isis-scimpi-viewer
org.apache.isis.components          isis-xxxxxx-viewer


org.apache.isis.editions            isis-quickstart-edition
org.apache.isis.editions            isis-modeller-edition
org.apache.isis.editions            isis-webapp-edition
org.apache.isis.editions            isis-xxxxxx-edition

How does that look?

Rob


On 11/29/12 20:20, Dan Haywood wrote:
> Hi Rob,
>
> Thanks for these thoughts... sounds like we are somewhat in the same boat
> in that we want to push out new releases, but don't know enough about the
> (state of the) other modules to know whether it is safe to do so.
>
> And so, yes, breaking up the codebase into separate submodules is the
> obvious next step, and something that you and I have discussed several
> times in the past off-list.  I don't have any issue with doing it myself,
> it's an obvious evolution from my proposal.
>
> The concept of an edition, then, I think equates to an archetype: it's a
> project template to get a would-be used up-and-running quickly with a
> precanned set of modules.
>
> What I therefore suggest is that we:
>
> 1. wait for Infra to move our code from svn to git (soon, I hope...)
> 2. flatten out the modules as I outlined in the wiki page
> 3. raise another ticket for infra to create new repos for each of the
> modules that we want to release separately... seems to me that these could
> start out as clones of the original
> 4. when those new submodule repos exist, we can zap remove all the foreign
> stuff; conversely, in the original repo, we zap the code for which there
> are now submodule repos
>
> The new repos that I see us needing are:
> - viewer-wicket
> - viewer-scimpi
> - viewer-restful
> - viewer-html
> - objectstore-jdo
> - objectstore-nosql
> - objectstore-sql
> - editions                   // for the various archetypes we might want to
> create.
>
> For the other modules that are not core (eg progmodel-groovy, or
> viewer-junit), I'd rather leave them in the "default" repo, but not release
> them until there is a need.  For these we can use a Maven profile to
> exclude them from the release process.
>
> Although overall this introduces a little bit more formality into the
> proceedings, I do think that the time is now right to do this.  And, I
> think it properly answers all the objections that Giovanni raised earlier
> in this thread.
>
> What say we all?
>
> Dan
>
>
> On 29 November 2012 20:00, Robert Matthews <rm...@nakedobjects.org>wrote:
>
>> First and foremost, I think we should release things more granularly so
>> individual components (most of our Maven modules) can be worked on more
>> independently. I would find it great to be able to work on improving the
>> NOSQL store or the Scimpi viewer without having to consider that every
>> other module has to be got into a releasable state just so one ready module
>> can be released.  Most of the modules, outside of the core,  are fairly
>> independent, typically relying only on the core and will work other
>> versions of other components, eg a viewer is not typically dependent on an
>> object store. Basically, we have the core modules, which need to be
>> maintained and released together, then we have a whole pile of major
>> component, mostly that can be developed independently.
>>
>> The "editions", as I think someone referred to them, are a combination of
>> the components that are useful together, but are just that. They are
>> lightweight, just specifying how to pull those components together and
>> providing supporting resources like examples, configurations and extra
>> documentation.  Think of these like Linux distributions, they pull together
>> a host of programs together to create a, sometimes unique, set up.  The
>> distribution is just a collation of all the programs along with the
>> installer, some specific graphics and preconfigured settings. The programs
>> themselves are developed, and also available,  separately.
>>
>> Instead of keeping it all monolithic and using profiles to control what is
>> released (and what isn't) I think we should break it up into:-
>>
>>      A "Core"
>>      Individual "Components" (viewer, object stores etc)
>>      Specially targetted "Editions" (SOA, Web Framework, Modeller's toolbox
>> etc)
>>
>> This would obviously affect both the organisation of the code and be
>> reflected in the site as a series of subprojects (like a number of Apache
>> project do, like James, Maven, Velocity and Xerces).
>>
>> (Doesn't Eclipse actually something just like this - they have a core,
>> there are are series of components that work with it and they provide
>> different "editions" that target different types of user.)
>>
>> Another benefit of working this way is that a (new) developer can
>> concentrate on a single component, i.e., check out a small amount of code,
>> use Maven to sort of the dependencies to other framework classes, which
>> will download the jars and then focus on just that one module.
>>
>> Just a few thoughts.
>>
>> Regards
>>
>> Rob
>>
>>
>>
>>
>> On 11/29/12 14:36, Dan Haywood wrote:
>>
>>> This discussion post is mostly to the contributors, but cc:ing to user
>>> list
>>> for opinions also...
>>>
>>> ~~~
>>>
>>> At the moment it's a daunting task to fully verify all the components of
>>> the framework are working correctly prior to pushing out a release. I
>>> suppose that wouldn't be so much of a concern if we had better automated
>>> tests, but, hey, that's how things are.
>>>
>>> Moreover, frankly, some of the modules are best considered spikes and
>>> probably don't constitute something that we would consider
>>> production-ready. Or, at least, they haven't been used in a real-world
>>> context, so it's not possible to say whether they are really
>>> fit-for-purpose. I include here quite a lot of the stuff that I have
>>> worked
>>> on over the last few years, eg the wrapper-progmodel, the groovy
>>> progmodel,
>>> probably also the JUnit viewer and BDD viewer. Now that we are a top-level
>>> project, I'd like it that the code we put out is thought of as production
>>> ready.
>>>
>>> In order to make the framework easier to release, I propose that we use
>>> Maven profiles to be able to release subsets of modules, that a given
>>> contributor can stand behind and say: "yes, those modules are working and
>>> are fit for general consumption". Each release would consist of the
>>> certain
>>> core modules, along with selected additional viewers and object stores.
>>>
>>> For example, over time we might end up releasing:
>>>
>>> * v0.3.1 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
>>>    // a "wicket/jdo release" - eg tested and released by Dan
>>>
>>> * v0.4.0 core + objectstore-nosql + viewer-scimpi     // a "scimpi/nosql
>>> release" - eg tested and released by Rob
>>>
>>> * v0.5.0 core + objectstore-dflt + objectstore-xml + viewer-dnd     // a
>>> "dev env release" - eg tested and released by Rob
>>>
>>> * v0.6.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
>>> // another "wicket/jdo release"
>>>
>>> * v0.7.0 core + objectstore-sql + viewer-html     // a "html/sql release"
>>> -
>>> eg tested and released by Kevin
>>>
>>> * v0.8.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
>>> // another "wicket/jdo release"
>>>
>>> Whenever a release goes out, we would update our website to indicate the
>>> most recent version of the components.
>>>
>>> Now, when I say "release", what I actually mean here is the deployment of
>>> binary artifacts up to the Maven central repo. This, after all, is what
>>> most users/would-be users in the community would use and consider a
>>> release. However, Apache's own formal definition of "release" is actually
>>> the source code release ... this is what the [VOTE] mechanism is for. I
>>> don't see this changing... the vote basically says that the software
>>> complies with all the legal license stuff etc. The whole codebase is
>>> tagged
>>> with that release number, and the generated src.zip is a zip of this
>>> release.
>>>
>>> One benefit of this is that it allows the deployment of other modules to
>>> be
>>> performed "after the fact". For example, suppose that I (Dan) puts out the
>>> v0.3.1 release as above, and then Rob later on tests the scimpi viewer in
>>> that tag and finds it works well. He can (I think) push the release of the
>>> scimpi viewer up to Maven central repo.
>>>
>>> As I see things there are several benefits to this scheme:
>>>
>>> a) (as already noted) the user community will only see binary releases
>>> that
>>> are known to be of production ready. This should mitigate the "is it safe
>>> to use this component" worry
>>> b) (as hinted at) it should be possible for individual contributors to put
>>> out releases of their modules more rapidly
>>> c) we get visibility of which modules aren't being released; for example,
>>> we might say that if a module hasn't been released by anyone for 18 or 24
>>> months, say, then it's probably time to remove it from the codebase.
>>>
>>> ~~~
>>>
>>> In order to support the above scheme, I propose that we rearrange some of
>>> the modules so that they can be more easily included within Maven
>>> modules.  I've
>>> created a page on our wiki [1] which shows my proposed rearrangement.  It
>>> also repeats the above discussion text by way of context.
>>>
>>>
>>> Opinions welcome!
>>>
>>> Thx
>>>
>>> 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

[Jeroen van der Wal <je...@stromboli.it>]

Again a +1 from me

I would opt to leave the default repo as it is (and phase out when this
process has been succesfull) and for clarity ad two new ones:
- apache-isis-core
- apache-isis-extras (for unreleased stuff)

But these are just my thoughts, feel free to ignore when practicalities
prevent.

There's a thread on StackOverflow[1] on how do this with Git[1] and end up
with compact repositories.

Cheers,

Jeroen

[1]
http://stackoverflow.com/questions/359424/detach-subdirectory-into-separate-git-repository

On Thu, Nov 29, 2012 at 9:20 PM, Dan Haywood
<da...@haywood-associates.co.uk>wrote:

> Hi Rob,
>
> Thanks for these thoughts... sounds like we are somewhat in the same boat
> in that we want to push out new releases, but don't know enough about the
> (state of the) other modules to know whether it is safe to do so.
>
> And so, yes, breaking up the codebase into separate submodules is the
> obvious next step, and something that you and I have discussed several
> times in the past off-list.  I don't have any issue with doing it myself,
> it's an obvious evolution from my proposal.
>
> The concept of an edition, then, I think equates to an archetype: it's a
> project template to get a would-be used up-and-running quickly with a
> precanned set of modules.
>
> What I therefore suggest is that we:
>
> 1. wait for Infra to move our code from svn to git (soon, I hope...)
> 2. flatten out the modules as I outlined in the wiki page
> 3. raise another ticket for infra to create new repos for each of the
> modules that we want to release separately... seems to me that these could
> start out as clones of the original
> 4. when those new submodule repos exist, we can zap remove all the foreign
> stuff; conversely, in the original repo, we zap the code for which there
> are now submodule repos
>
> The new repos that I see us needing are:
> - viewer-wicket
> - viewer-scimpi
> - viewer-restful
> - viewer-html
> - objectstore-jdo
> - objectstore-nosql
> - objectstore-sql
> - editions                   // for the various archetypes we might want to
> create.
>
> For the other modules that are not core (eg progmodel-groovy, or
> viewer-junit), I'd rather leave them in the "default" repo, but not release
> them until there is a need.  For these we can use a Maven profile to
> exclude them from the release process.
>
> Although overall this introduces a little bit more formality into the
> proceedings, I do think that the time is now right to do this.  And, I
> think it properly answers all the objections that Giovanni raised earlier
> in this thread.
>
> What say we all?
>
> Dan
>
>
> On 29 November 2012 20:00, Robert Matthews <rmatthews@nakedobjects.org
> >wrote:
>
> > First and foremost, I think we should release things more granularly so
> > individual components (most of our Maven modules) can be worked on more
> > independently. I would find it great to be able to work on improving the
> > NOSQL store or the Scimpi viewer without having to consider that every
> > other module has to be got into a releasable state just so one ready
> module
> > can be released.  Most of the modules, outside of the core,  are fairly
> > independent, typically relying only on the core and will work other
> > versions of other components, eg a viewer is not typically dependent on
> an
> > object store. Basically, we have the core modules, which need to be
> > maintained and released together, then we have a whole pile of major
> > component, mostly that can be developed independently.
> >
> > The "editions", as I think someone referred to them, are a combination of
> > the components that are useful together, but are just that. They are
> > lightweight, just specifying how to pull those components together and
> > providing supporting resources like examples, configurations and extra
> > documentation.  Think of these like Linux distributions, they pull
> together
> > a host of programs together to create a, sometimes unique, set up.  The
> > distribution is just a collation of all the programs along with the
> > installer, some specific graphics and preconfigured settings. The
> programs
> > themselves are developed, and also available,  separately.
> >
> > Instead of keeping it all monolithic and using profiles to control what
> is
> > released (and what isn't) I think we should break it up into:-
> >
> >     A "Core"
> >     Individual "Components" (viewer, object stores etc)
> >     Specially targetted "Editions" (SOA, Web Framework, Modeller's
> toolbox
> > etc)
> >
> > This would obviously affect both the organisation of the code and be
> > reflected in the site as a series of subprojects (like a number of Apache
> > project do, like James, Maven, Velocity and Xerces).
> >
> > (Doesn't Eclipse actually something just like this - they have a core,
> > there are are series of components that work with it and they provide
> > different "editions" that target different types of user.)
> >
> > Another benefit of working this way is that a (new) developer can
> > concentrate on a single component, i.e., check out a small amount of
> code,
> > use Maven to sort of the dependencies to other framework classes, which
> > will download the jars and then focus on just that one module.
> >
> > Just a few thoughts.
> >
> > Regards
> >
> > Rob
> >
> >
> >
> >
> > On 11/29/12 14:36, Dan Haywood wrote:
> >
> >> This discussion post is mostly to the contributors, but cc:ing to user
> >> list
> >> for opinions also...
> >>
> >> ~~~
> >>
> >> At the moment it's a daunting task to fully verify all the components of
> >> the framework are working correctly prior to pushing out a release. I
> >> suppose that wouldn't be so much of a concern if we had better automated
> >> tests, but, hey, that's how things are.
> >>
> >> Moreover, frankly, some of the modules are best considered spikes and
> >> probably don't constitute something that we would consider
> >> production-ready. Or, at least, they haven't been used in a real-world
> >> context, so it's not possible to say whether they are really
> >> fit-for-purpose. I include here quite a lot of the stuff that I have
> >> worked
> >> on over the last few years, eg the wrapper-progmodel, the groovy
> >> progmodel,
> >> probably also the JUnit viewer and BDD viewer. Now that we are a
> top-level
> >> project, I'd like it that the code we put out is thought of as
> production
> >> ready.
> >>
> >> In order to make the framework easier to release, I propose that we use
> >> Maven profiles to be able to release subsets of modules, that a given
> >> contributor can stand behind and say: "yes, those modules are working
> and
> >> are fit for general consumption". Each release would consist of the
> >> certain
> >> core modules, along with selected additional viewers and object stores.
> >>
> >> For example, over time we might end up releasing:
> >>
> >> * v0.3.1 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
> >>   // a "wicket/jdo release" - eg tested and released by Dan
> >>
> >> * v0.4.0 core + objectstore-nosql + viewer-scimpi     // a "scimpi/nosql
> >> release" - eg tested and released by Rob
> >>
> >> * v0.5.0 core + objectstore-dflt + objectstore-xml + viewer-dnd     // a
> >> "dev env release" - eg tested and released by Rob
> >>
> >> * v0.6.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
> >> // another "wicket/jdo release"
> >>
> >> * v0.7.0 core + objectstore-sql + viewer-html     // a "html/sql
> release"
> >> -
> >> eg tested and released by Kevin
> >>
> >> * v0.8.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
> >> // another "wicket/jdo release"
> >>
> >> Whenever a release goes out, we would update our website to indicate the
> >> most recent version of the components.
> >>
> >> Now, when I say "release", what I actually mean here is the deployment
> of
> >> binary artifacts up to the Maven central repo. This, after all, is what
> >> most users/would-be users in the community would use and consider a
> >> release. However, Apache's own formal definition of "release" is
> actually
> >> the source code release ... this is what the [VOTE] mechanism is for. I
> >> don't see this changing... the vote basically says that the software
> >> complies with all the legal license stuff etc. The whole codebase is
> >> tagged
> >> with that release number, and the generated src.zip is a zip of this
> >> release.
> >>
> >> One benefit of this is that it allows the deployment of other modules to
> >> be
> >> performed "after the fact". For example, suppose that I (Dan) puts out
> the
> >> v0.3.1 release as above, and then Rob later on tests the scimpi viewer
> in
> >> that tag and finds it works well. He can (I think) push the release of
> the
> >> scimpi viewer up to Maven central repo.
> >>
> >> As I see things there are several benefits to this scheme:
> >>
> >> a) (as already noted) the user community will only see binary releases
> >> that
> >> are known to be of production ready. This should mitigate the "is it
> safe
> >> to use this component" worry
> >> b) (as hinted at) it should be possible for individual contributors to
> put
> >> out releases of their modules more rapidly
> >> c) we get visibility of which modules aren't being released; for
> example,
> >> we might say that if a module hasn't been released by anyone for 18 or
> 24
> >> months, say, then it's probably time to remove it from the codebase.
> >>
> >> ~~~
> >>
> >> In order to support the above scheme, I propose that we rearrange some
> of
> >> the modules so that they can be more easily included within Maven
> >> modules.  I've
> >> created a page on our wiki [1] which shows my proposed rearrangement.
>  It
> >> also repeats the above discussion text by way of context.
> >>
> >>
> >> Opinions welcome!
> >>
> >> Thx
> >>
> >> 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

[Dan Haywood <da...@haywood-associates.co.uk>]

Those are good points; I guess my only reservation is that it isn't that
common.

With github's massive influence, I think people are getting more used to
seeing lots of fairly granular repos that are then assembled together.
 This then allows a top-level README.md to describe the intent of just that
one repo, nicely rendered in the github website.

I know I am starting to work this way, and I see committers on projects
such as Wicket doing something similar [1].

All that said, I think we can take this in stages, and we should take this
step by step, refactoring to your proposed solution first, and then to
separate git repos afterwards if we feel we need to.

Let me go back to the wiki page and try to reflect these ideas.

[1] https://github.com/ivaynberg


On 29 November 2012 22:26, Matthew Adams <ma...@matthewadams.me> wrote:

> I'm not sure I understand the benefit of having separate git repos for each
> of the modules.  Why can't all of the isis code be stored in a single place
> as a multimodule maven project?  Although it's probably uncommon, there's
> nothing that says that all of the submodules share the same version as
> their parent or peers.
>
> The same git repo can house all isis modules, and modules representing each
> edition.  In fact, if each edition gets its own maven module, then I think
> its content wouldn't be much more than a little bit o'configuration along
> with some dependencies, and the edition could maintain its own version
> numbering, separate from those of its dependencies.
>
> Thoughts?
>
>
>
> On Thu, Nov 29, 2012 at 3:23 PM, Dan Haywood
> <da...@haywood-associates.co.uk>wrote:
>
> > It's the whole directory.
> >
> > In fact, it's the entire history of every directory. Sounds like it
> > couldn't possibly work.. but it turns out that it works just fine.
> >
> > By the way, if you look at the site, you'll see I've written some notes
> on
> > how I suggest we use git.
> >
> > Dan
> >
> > Sorry to be brief, sent from my phone
> > On Nov 29, 2012 9:11 PM, "Robert Matthews" <rm...@nakedobjects.org>
> > wrote:
> >
> > > Dan,
> > >
> > > Can you clarify something for me as I haven't had time to read my Git
> > > book. Do you have to check out the entire repository when using Git or
> > can
> > > you check a specific directory as you can with Subversion? I'm assuming
> > > that you have to as you're suggesting new repositories for for each
> > > subproject.
> > >
> > > Regards
> > >
> > > Rob
> > >
> > >
> > > On 11/29/12 20:20, Dan Haywood wrote:
> > >
> > >> Hi Rob,
> > >>
> > >> Thanks for these thoughts... sounds like we are somewhat in the same
> > boat
> > >> in that we want to push out new releases, but don't know enough about
> > the
> > >> (state of the) other modules to know whether it is safe to do so.
> > >>
> > >> And so, yes, breaking up the codebase into separate submodules is the
> > >> obvious next step, and something that you and I have discussed several
> > >> times in the past off-list.  I don't have any issue with doing it
> > myself,
> > >> it's an obvious evolution from my proposal.
> > >>
> > >> The concept of an edition, then, I think equates to an archetype:
> it's a
> > >> project template to get a would-be used up-and-running quickly with a
> > >> precanned set of modules.
> > >>
> > >> What I therefore suggest is that we:
> > >>
> > >> 1. wait for Infra to move our code from svn to git (soon, I hope...)
> > >> 2. flatten out the modules as I outlined in the wiki page
> > >> 3. raise another ticket for infra to create new repos for each of the
> > >> modules that we want to release separately... seems to me that these
> > could
> > >> start out as clones of the original
> > >> 4. when those new submodule repos exist, we can zap remove all the
> > foreign
> > >> stuff; conversely, in the original repo, we zap the code for which
> there
> > >> are now submodule repos
> > >>
> > >> The new repos that I see us needing are:
> > >> - viewer-wicket
> > >> - viewer-scimpi
> > >> - viewer-restful
> > >> - viewer-html
> > >> - objectstore-jdo
> > >> - objectstore-nosql
> > >> - objectstore-sql
> > >> - editions                   // for the various archetypes we might
> want
> > >> to
> > >> create.
> > >>
> > >> For the other modules that are not core (eg progmodel-groovy, or
> > >> viewer-junit), I'd rather leave them in the "default" repo, but not
> > >> release
> > >> them until there is a need.  For these we can use a Maven profile to
> > >> exclude them from the release process.
> > >>
> > >> Although overall this introduces a little bit more formality into the
> > >> proceedings, I do think that the time is now right to do this.  And, I
> > >> think it properly answers all the objections that Giovanni raised
> > earlier
> > >> in this thread.
> > >>
> > >> What say we all?
> > >>
> > >> Dan
> > >>
> > >>
> > >> On 29 November 2012 20:00, Robert Matthews <
> rmatthews@nakedobjects.org
> > >**
> > >> wrote:
> > >>
> > >>  First and foremost, I think we should release things more granularly
> so
> > >>> individual components (most of our Maven modules) can be worked on
> more
> > >>> independently. I would find it great to be able to work on improving
> > the
> > >>> NOSQL store or the Scimpi viewer without having to consider that
> every
> > >>> other module has to be got into a releasable state just so one ready
> > >>> module
> > >>> can be released.  Most of the modules, outside of the core,  are
> fairly
> > >>> independent, typically relying only on the core and will work other
> > >>> versions of other components, eg a viewer is not typically dependent
> on
> > >>> an
> > >>> object store. Basically, we have the core modules, which need to be
> > >>> maintained and released together, then we have a whole pile of major
> > >>> component, mostly that can be developed independently.
> > >>>
> > >>> The "editions", as I think someone referred to them, are a
> combination
> > of
> > >>> the components that are useful together, but are just that. They are
> > >>> lightweight, just specifying how to pull those components together
> and
> > >>> providing supporting resources like examples, configurations and
> extra
> > >>> documentation.  Think of these like Linux distributions, they pull
> > >>> together
> > >>> a host of programs together to create a, sometimes unique, set up.
>  The
> > >>> distribution is just a collation of all the programs along with the
> > >>> installer, some specific graphics and preconfigured settings. The
> > >>> programs
> > >>> themselves are developed, and also available,  separately.
> > >>>
> > >>> Instead of keeping it all monolithic and using profiles to control
> what
> > >>> is
> > >>> released (and what isn't) I think we should break it up into:-
> > >>>
> > >>>      A "Core"
> > >>>      Individual "Components" (viewer, object stores etc)
> > >>>      Specially targetted "Editions" (SOA, Web Framework, Modeller's
> > >>> toolbox
> > >>> etc)
> > >>>
> > >>> This would obviously affect both the organisation of the code and be
> > >>> reflected in the site as a series of subprojects (like a number of
> > Apache
> > >>> project do, like James, Maven, Velocity and Xerces).
> > >>>
> > >>> (Doesn't Eclipse actually something just like this - they have a
> core,
> > >>> there are are series of components that work with it and they provide
> > >>> different "editions" that target different types of user.)
> > >>>
> > >>> Another benefit of working this way is that a (new) developer can
> > >>> concentrate on a single component, i.e., check out a small amount of
> > >>> code,
> > >>> use Maven to sort of the dependencies to other framework classes,
> which
> > >>> will download the jars and then focus on just that one module.
> > >>>
> > >>> Just a few thoughts.
> > >>>
> > >>> Regards
> > >>>
> > >>> Rob
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On 11/29/12 14:36, Dan Haywood wrote:
> > >>>
> > >>>  This discussion post is mostly to the contributors, but cc:ing to
> user
> > >>>> list
> > >>>> for opinions also...
> > >>>>
> > >>>> ~~~
> > >>>>
> > >>>> At the moment it's a daunting task to fully verify all the
> components
> > of
> > >>>> the framework are working correctly prior to pushing out a release.
> I
> > >>>> suppose that wouldn't be so much of a concern if we had better
> > automated
> > >>>> tests, but, hey, that's how things are.
> > >>>>
> > >>>> Moreover, frankly, some of the modules are best considered spikes
> and
> > >>>> probably don't constitute something that we would consider
> > >>>> production-ready. Or, at least, they haven't been used in a
> real-world
> > >>>> context, so it's not possible to say whether they are really
> > >>>> fit-for-purpose. I include here quite a lot of the stuff that I have
> > >>>> worked
> > >>>> on over the last few years, eg the wrapper-progmodel, the groovy
> > >>>> progmodel,
> > >>>> probably also the JUnit viewer and BDD viewer. Now that we are a
> > >>>> top-level
> > >>>> project, I'd like it that the code we put out is thought of as
> > >>>> production
> > >>>> ready.
> > >>>>
> > >>>> In order to make the framework easier to release, I propose that we
> > use
> > >>>> Maven profiles to be able to release subsets of modules, that a
> given
> > >>>> contributor can stand behind and say: "yes, those modules are
> working
> > >>>> and
> > >>>> are fit for general consumption". Each release would consist of the
> > >>>> certain
> > >>>> core modules, along with selected additional viewers and object
> > stores.
> > >>>>
> > >>>> For example, over time we might end up releasing:
> > >>>>
> > >>>> * v0.3.1 core + objectstore-jdo + viewer-wicket +
> > viewer-restfulobjects
> > >>>>    // a "wicket/jdo release" - eg tested and released by Dan
> > >>>>
> > >>>> * v0.4.0 core + objectstore-nosql + viewer-scimpi     // a
> > "scimpi/nosql
> > >>>> release" - eg tested and released by Rob
> > >>>>
> > >>>> * v0.5.0 core + objectstore-dflt + objectstore-xml + viewer-dnd
> > // a
> > >>>> "dev env release" - eg tested and released by Rob
> > >>>>
> > >>>> * v0.6.0 core + objectstore-jdo + viewer-wicket +
> > viewer-restfulobjects
> > >>>> // another "wicket/jdo release"
> > >>>>
> > >>>> * v0.7.0 core + objectstore-sql + viewer-html     // a "html/sql
> > >>>> release"
> > >>>> -
> > >>>> eg tested and released by Kevin
> > >>>>
> > >>>> * v0.8.0 core + objectstore-jdo + viewer-wicket +
> > viewer-restfulobjects
> > >>>> // another "wicket/jdo release"
> > >>>>
> > >>>> Whenever a release goes out, we would update our website to indicate
> > the
> > >>>> most recent version of the components.
> > >>>>
> > >>>> Now, when I say "release", what I actually mean here is the
> deployment
> > >>>> of
> > >>>> binary artifacts up to the Maven central repo. This, after all, is
> > what
> > >>>> most users/would-be users in the community would use and consider a
> > >>>> release. However, Apache's own formal definition of "release" is
> > >>>> actually
> > >>>> the source code release ... this is what the [VOTE] mechanism is
> for.
> > I
> > >>>> don't see this changing... the vote basically says that the software
> > >>>> complies with all the legal license stuff etc. The whole codebase is
> > >>>> tagged
> > >>>> with that release number, and the generated src.zip is a zip of this
> > >>>> release.
> > >>>>
> > >>>> One benefit of this is that it allows the deployment of other
> modules
> > to
> > >>>> be
> > >>>> performed "after the fact". For example, suppose that I (Dan) puts
> out
> > >>>> the
> > >>>> v0.3.1 release as above, and then Rob later on tests the scimpi
> viewer
> > >>>> in
> > >>>> that tag and finds it works well. He can (I think) push the release
> of
> > >>>> the
> > >>>> scimpi viewer up to Maven central repo.
> > >>>>
> > >>>> As I see things there are several benefits to this scheme:
> > >>>>
> > >>>> a) (as already noted) the user community will only see binary
> releases
> > >>>> that
> > >>>> are known to be of production ready. This should mitigate the "is it
> > >>>> safe
> > >>>> to use this component" worry
> > >>>> b) (as hinted at) it should be possible for individual contributors
> to
> > >>>> put
> > >>>> out releases of their modules more rapidly
> > >>>> c) we get visibility of which modules aren't being released; for
> > >>>> example,
> > >>>> we might say that if a module hasn't been released by anyone for 18
> or
> > >>>> 24
> > >>>> months, say, then it's probably time to remove it from the codebase.
> > >>>>
> > >>>> ~~~
> > >>>>
> > >>>> In order to support the above scheme, I propose that we rearrange
> some
> > >>>> of
> > >>>> the modules so that they can be more easily included within Maven
> > >>>> modules.  I've
> > >>>> created a page on our wiki [1] which shows my proposed
> rearrangement.
> > >>>>  It
> > >>>> also repeats the above discussion text by way of context.
> > >>>>
> > >>>>
> > >>>> Opinions welcome!
> > >>>>
> > >>>> Thx
> > >>>>
> > >>>> 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
> > >
> > >>>> >
> > >>>>
> > >>>>
> > >>>>
> > >
> >
>
>
>
> --
> mailto:matthew@matthewadams.me <ma...@matthewadams.me>
> skype:matthewadams12
> googletalk:matthew@matthewadams.me
> http://matthewadams.me
> http://www.linkedin.com/in/matthewadams
>

Re: [DISCUSSION] Making releases easier and more frequent

[Matthew Adams <ma...@matthewadams.me>]

I'm not sure I understand the benefit of having separate git repos for each
of the modules.  Why can't all of the isis code be stored in a single place
as a multimodule maven project?  Although it's probably uncommon, there's
nothing that says that all of the submodules share the same version as
their parent or peers.

The same git repo can house all isis modules, and modules representing each
edition.  In fact, if each edition gets its own maven module, then I think
its content wouldn't be much more than a little bit o'configuration along
with some dependencies, and the edition could maintain its own version
numbering, separate from those of its dependencies.

Thoughts?



On Thu, Nov 29, 2012 at 3:23 PM, Dan Haywood
<da...@haywood-associates.co.uk>wrote:

> It's the whole directory.
>
> In fact, it's the entire history of every directory. Sounds like it
> couldn't possibly work.. but it turns out that it works just fine.
>
> By the way, if you look at the site, you'll see I've written some notes on
> how I suggest we use git.
>
> Dan
>
> Sorry to be brief, sent from my phone
> On Nov 29, 2012 9:11 PM, "Robert Matthews" <rm...@nakedobjects.org>
> wrote:
>
> > Dan,
> >
> > Can you clarify something for me as I haven't had time to read my Git
> > book. Do you have to check out the entire repository when using Git or
> can
> > you check a specific directory as you can with Subversion? I'm assuming
> > that you have to as you're suggesting new repositories for for each
> > subproject.
> >
> > Regards
> >
> > Rob
> >
> >
> > On 11/29/12 20:20, Dan Haywood wrote:
> >
> >> Hi Rob,
> >>
> >> Thanks for these thoughts... sounds like we are somewhat in the same
> boat
> >> in that we want to push out new releases, but don't know enough about
> the
> >> (state of the) other modules to know whether it is safe to do so.
> >>
> >> And so, yes, breaking up the codebase into separate submodules is the
> >> obvious next step, and something that you and I have discussed several
> >> times in the past off-list.  I don't have any issue with doing it
> myself,
> >> it's an obvious evolution from my proposal.
> >>
> >> The concept of an edition, then, I think equates to an archetype: it's a
> >> project template to get a would-be used up-and-running quickly with a
> >> precanned set of modules.
> >>
> >> What I therefore suggest is that we:
> >>
> >> 1. wait for Infra to move our code from svn to git (soon, I hope...)
> >> 2. flatten out the modules as I outlined in the wiki page
> >> 3. raise another ticket for infra to create new repos for each of the
> >> modules that we want to release separately... seems to me that these
> could
> >> start out as clones of the original
> >> 4. when those new submodule repos exist, we can zap remove all the
> foreign
> >> stuff; conversely, in the original repo, we zap the code for which there
> >> are now submodule repos
> >>
> >> The new repos that I see us needing are:
> >> - viewer-wicket
> >> - viewer-scimpi
> >> - viewer-restful
> >> - viewer-html
> >> - objectstore-jdo
> >> - objectstore-nosql
> >> - objectstore-sql
> >> - editions                   // for the various archetypes we might want
> >> to
> >> create.
> >>
> >> For the other modules that are not core (eg progmodel-groovy, or
> >> viewer-junit), I'd rather leave them in the "default" repo, but not
> >> release
> >> them until there is a need.  For these we can use a Maven profile to
> >> exclude them from the release process.
> >>
> >> Although overall this introduces a little bit more formality into the
> >> proceedings, I do think that the time is now right to do this.  And, I
> >> think it properly answers all the objections that Giovanni raised
> earlier
> >> in this thread.
> >>
> >> What say we all?
> >>
> >> Dan
> >>
> >>
> >> On 29 November 2012 20:00, Robert Matthews <rmatthews@nakedobjects.org
> >**
> >> wrote:
> >>
> >>  First and foremost, I think we should release things more granularly so
> >>> individual components (most of our Maven modules) can be worked on more
> >>> independently. I would find it great to be able to work on improving
> the
> >>> NOSQL store or the Scimpi viewer without having to consider that every
> >>> other module has to be got into a releasable state just so one ready
> >>> module
> >>> can be released.  Most of the modules, outside of the core,  are fairly
> >>> independent, typically relying only on the core and will work other
> >>> versions of other components, eg a viewer is not typically dependent on
> >>> an
> >>> object store. Basically, we have the core modules, which need to be
> >>> maintained and released together, then we have a whole pile of major
> >>> component, mostly that can be developed independently.
> >>>
> >>> The "editions", as I think someone referred to them, are a combination
> of
> >>> the components that are useful together, but are just that. They are
> >>> lightweight, just specifying how to pull those components together and
> >>> providing supporting resources like examples, configurations and extra
> >>> documentation.  Think of these like Linux distributions, they pull
> >>> together
> >>> a host of programs together to create a, sometimes unique, set up.  The
> >>> distribution is just a collation of all the programs along with the
> >>> installer, some specific graphics and preconfigured settings. The
> >>> programs
> >>> themselves are developed, and also available,  separately.
> >>>
> >>> Instead of keeping it all monolithic and using profiles to control what
> >>> is
> >>> released (and what isn't) I think we should break it up into:-
> >>>
> >>>      A "Core"
> >>>      Individual "Components" (viewer, object stores etc)
> >>>      Specially targetted "Editions" (SOA, Web Framework, Modeller's
> >>> toolbox
> >>> etc)
> >>>
> >>> This would obviously affect both the organisation of the code and be
> >>> reflected in the site as a series of subprojects (like a number of
> Apache
> >>> project do, like James, Maven, Velocity and Xerces).
> >>>
> >>> (Doesn't Eclipse actually something just like this - they have a core,
> >>> there are are series of components that work with it and they provide
> >>> different "editions" that target different types of user.)
> >>>
> >>> Another benefit of working this way is that a (new) developer can
> >>> concentrate on a single component, i.e., check out a small amount of
> >>> code,
> >>> use Maven to sort of the dependencies to other framework classes, which
> >>> will download the jars and then focus on just that one module.
> >>>
> >>> Just a few thoughts.
> >>>
> >>> Regards
> >>>
> >>> Rob
> >>>
> >>>
> >>>
> >>>
> >>> On 11/29/12 14:36, Dan Haywood wrote:
> >>>
> >>>  This discussion post is mostly to the contributors, but cc:ing to user
> >>>> list
> >>>> for opinions also...
> >>>>
> >>>> ~~~
> >>>>
> >>>> At the moment it's a daunting task to fully verify all the components
> of
> >>>> the framework are working correctly prior to pushing out a release. I
> >>>> suppose that wouldn't be so much of a concern if we had better
> automated
> >>>> tests, but, hey, that's how things are.
> >>>>
> >>>> Moreover, frankly, some of the modules are best considered spikes and
> >>>> probably don't constitute something that we would consider
> >>>> production-ready. Or, at least, they haven't been used in a real-world
> >>>> context, so it's not possible to say whether they are really
> >>>> fit-for-purpose. I include here quite a lot of the stuff that I have
> >>>> worked
> >>>> on over the last few years, eg the wrapper-progmodel, the groovy
> >>>> progmodel,
> >>>> probably also the JUnit viewer and BDD viewer. Now that we are a
> >>>> top-level
> >>>> project, I'd like it that the code we put out is thought of as
> >>>> production
> >>>> ready.
> >>>>
> >>>> In order to make the framework easier to release, I propose that we
> use
> >>>> Maven profiles to be able to release subsets of modules, that a given
> >>>> contributor can stand behind and say: "yes, those modules are working
> >>>> and
> >>>> are fit for general consumption". Each release would consist of the
> >>>> certain
> >>>> core modules, along with selected additional viewers and object
> stores.
> >>>>
> >>>> For example, over time we might end up releasing:
> >>>>
> >>>> * v0.3.1 core + objectstore-jdo + viewer-wicket +
> viewer-restfulobjects
> >>>>    // a "wicket/jdo release" - eg tested and released by Dan
> >>>>
> >>>> * v0.4.0 core + objectstore-nosql + viewer-scimpi     // a
> "scimpi/nosql
> >>>> release" - eg tested and released by Rob
> >>>>
> >>>> * v0.5.0 core + objectstore-dflt + objectstore-xml + viewer-dnd
> // a
> >>>> "dev env release" - eg tested and released by Rob
> >>>>
> >>>> * v0.6.0 core + objectstore-jdo + viewer-wicket +
> viewer-restfulobjects
> >>>> // another "wicket/jdo release"
> >>>>
> >>>> * v0.7.0 core + objectstore-sql + viewer-html     // a "html/sql
> >>>> release"
> >>>> -
> >>>> eg tested and released by Kevin
> >>>>
> >>>> * v0.8.0 core + objectstore-jdo + viewer-wicket +
> viewer-restfulobjects
> >>>> // another "wicket/jdo release"
> >>>>
> >>>> Whenever a release goes out, we would update our website to indicate
> the
> >>>> most recent version of the components.
> >>>>
> >>>> Now, when I say "release", what I actually mean here is the deployment
> >>>> of
> >>>> binary artifacts up to the Maven central repo. This, after all, is
> what
> >>>> most users/would-be users in the community would use and consider a
> >>>> release. However, Apache's own formal definition of "release" is
> >>>> actually
> >>>> the source code release ... this is what the [VOTE] mechanism is for.
> I
> >>>> don't see this changing... the vote basically says that the software
> >>>> complies with all the legal license stuff etc. The whole codebase is
> >>>> tagged
> >>>> with that release number, and the generated src.zip is a zip of this
> >>>> release.
> >>>>
> >>>> One benefit of this is that it allows the deployment of other modules
> to
> >>>> be
> >>>> performed "after the fact". For example, suppose that I (Dan) puts out
> >>>> the
> >>>> v0.3.1 release as above, and then Rob later on tests the scimpi viewer
> >>>> in
> >>>> that tag and finds it works well. He can (I think) push the release of
> >>>> the
> >>>> scimpi viewer up to Maven central repo.
> >>>>
> >>>> As I see things there are several benefits to this scheme:
> >>>>
> >>>> a) (as already noted) the user community will only see binary releases
> >>>> that
> >>>> are known to be of production ready. This should mitigate the "is it
> >>>> safe
> >>>> to use this component" worry
> >>>> b) (as hinted at) it should be possible for individual contributors to
> >>>> put
> >>>> out releases of their modules more rapidly
> >>>> c) we get visibility of which modules aren't being released; for
> >>>> example,
> >>>> we might say that if a module hasn't been released by anyone for 18 or
> >>>> 24
> >>>> months, say, then it's probably time to remove it from the codebase.
> >>>>
> >>>> ~~~
> >>>>
> >>>> In order to support the above scheme, I propose that we rearrange some
> >>>> of
> >>>> the modules so that they can be more easily included within Maven
> >>>> modules.  I've
> >>>> created a page on our wiki [1] which shows my proposed rearrangement.
> >>>>  It
> >>>> also repeats the above discussion text by way of context.
> >>>>
> >>>>
> >>>> Opinions welcome!
> >>>>
> >>>> Thx
> >>>>
> >>>> 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
> >
> >>>> >
> >>>>
> >>>>
> >>>>
> >
>



-- 
mailto:matthew@matthewadams.me <ma...@matthewadams.me>
skype:matthewadams12
googletalk:matthew@matthewadams.me
http://matthewadams.me
http://www.linkedin.com/in/matthewadams

Re: [DISCUSSION] Making releases easier and more frequent

[Dan Haywood <da...@haywood-associates.co.uk>]

It's the whole directory.

In fact, it's the entire history of every directory. Sounds like it
couldn't possibly work.. but it turns out that it works just fine.

By the way, if you look at the site, you'll see I've written some notes on
how I suggest we use git.

Dan

Sorry to be brief, sent from my phone
On Nov 29, 2012 9:11 PM, "Robert Matthews" <rm...@nakedobjects.org>
wrote:

> Dan,
>
> Can you clarify something for me as I haven't had time to read my Git
> book. Do you have to check out the entire repository when using Git or can
> you check a specific directory as you can with Subversion? I'm assuming
> that you have to as you're suggesting new repositories for for each
> subproject.
>
> Regards
>
> Rob
>
>
> On 11/29/12 20:20, Dan Haywood wrote:
>
>> Hi Rob,
>>
>> Thanks for these thoughts... sounds like we are somewhat in the same boat
>> in that we want to push out new releases, but don't know enough about the
>> (state of the) other modules to know whether it is safe to do so.
>>
>> And so, yes, breaking up the codebase into separate submodules is the
>> obvious next step, and something that you and I have discussed several
>> times in the past off-list.  I don't have any issue with doing it myself,
>> it's an obvious evolution from my proposal.
>>
>> The concept of an edition, then, I think equates to an archetype: it's a
>> project template to get a would-be used up-and-running quickly with a
>> precanned set of modules.
>>
>> What I therefore suggest is that we:
>>
>> 1. wait for Infra to move our code from svn to git (soon, I hope...)
>> 2. flatten out the modules as I outlined in the wiki page
>> 3. raise another ticket for infra to create new repos for each of the
>> modules that we want to release separately... seems to me that these could
>> start out as clones of the original
>> 4. when those new submodule repos exist, we can zap remove all the foreign
>> stuff; conversely, in the original repo, we zap the code for which there
>> are now submodule repos
>>
>> The new repos that I see us needing are:
>> - viewer-wicket
>> - viewer-scimpi
>> - viewer-restful
>> - viewer-html
>> - objectstore-jdo
>> - objectstore-nosql
>> - objectstore-sql
>> - editions                   // for the various archetypes we might want
>> to
>> create.
>>
>> For the other modules that are not core (eg progmodel-groovy, or
>> viewer-junit), I'd rather leave them in the "default" repo, but not
>> release
>> them until there is a need.  For these we can use a Maven profile to
>> exclude them from the release process.
>>
>> Although overall this introduces a little bit more formality into the
>> proceedings, I do think that the time is now right to do this.  And, I
>> think it properly answers all the objections that Giovanni raised earlier
>> in this thread.
>>
>> What say we all?
>>
>> Dan
>>
>>
>> On 29 November 2012 20:00, Robert Matthews <rm...@nakedobjects.org>**
>> wrote:
>>
>>  First and foremost, I think we should release things more granularly so
>>> individual components (most of our Maven modules) can be worked on more
>>> independently. I would find it great to be able to work on improving the
>>> NOSQL store or the Scimpi viewer without having to consider that every
>>> other module has to be got into a releasable state just so one ready
>>> module
>>> can be released.  Most of the modules, outside of the core,  are fairly
>>> independent, typically relying only on the core and will work other
>>> versions of other components, eg a viewer is not typically dependent on
>>> an
>>> object store. Basically, we have the core modules, which need to be
>>> maintained and released together, then we have a whole pile of major
>>> component, mostly that can be developed independently.
>>>
>>> The "editions", as I think someone referred to them, are a combination of
>>> the components that are useful together, but are just that. They are
>>> lightweight, just specifying how to pull those components together and
>>> providing supporting resources like examples, configurations and extra
>>> documentation.  Think of these like Linux distributions, they pull
>>> together
>>> a host of programs together to create a, sometimes unique, set up.  The
>>> distribution is just a collation of all the programs along with the
>>> installer, some specific graphics and preconfigured settings. The
>>> programs
>>> themselves are developed, and also available,  separately.
>>>
>>> Instead of keeping it all monolithic and using profiles to control what
>>> is
>>> released (and what isn't) I think we should break it up into:-
>>>
>>>      A "Core"
>>>      Individual "Components" (viewer, object stores etc)
>>>      Specially targetted "Editions" (SOA, Web Framework, Modeller's
>>> toolbox
>>> etc)
>>>
>>> This would obviously affect both the organisation of the code and be
>>> reflected in the site as a series of subprojects (like a number of Apache
>>> project do, like James, Maven, Velocity and Xerces).
>>>
>>> (Doesn't Eclipse actually something just like this - they have a core,
>>> there are are series of components that work with it and they provide
>>> different "editions" that target different types of user.)
>>>
>>> Another benefit of working this way is that a (new) developer can
>>> concentrate on a single component, i.e., check out a small amount of
>>> code,
>>> use Maven to sort of the dependencies to other framework classes, which
>>> will download the jars and then focus on just that one module.
>>>
>>> Just a few thoughts.
>>>
>>> Regards
>>>
>>> Rob
>>>
>>>
>>>
>>>
>>> On 11/29/12 14:36, Dan Haywood wrote:
>>>
>>>  This discussion post is mostly to the contributors, but cc:ing to user
>>>> list
>>>> for opinions also...
>>>>
>>>> ~~~
>>>>
>>>> At the moment it's a daunting task to fully verify all the components of
>>>> the framework are working correctly prior to pushing out a release. I
>>>> suppose that wouldn't be so much of a concern if we had better automated
>>>> tests, but, hey, that's how things are.
>>>>
>>>> Moreover, frankly, some of the modules are best considered spikes and
>>>> probably don't constitute something that we would consider
>>>> production-ready. Or, at least, they haven't been used in a real-world
>>>> context, so it's not possible to say whether they are really
>>>> fit-for-purpose. I include here quite a lot of the stuff that I have
>>>> worked
>>>> on over the last few years, eg the wrapper-progmodel, the groovy
>>>> progmodel,
>>>> probably also the JUnit viewer and BDD viewer. Now that we are a
>>>> top-level
>>>> project, I'd like it that the code we put out is thought of as
>>>> production
>>>> ready.
>>>>
>>>> In order to make the framework easier to release, I propose that we use
>>>> Maven profiles to be able to release subsets of modules, that a given
>>>> contributor can stand behind and say: "yes, those modules are working
>>>> and
>>>> are fit for general consumption". Each release would consist of the
>>>> certain
>>>> core modules, along with selected additional viewers and object stores.
>>>>
>>>> For example, over time we might end up releasing:
>>>>
>>>> * v0.3.1 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
>>>>    // a "wicket/jdo release" - eg tested and released by Dan
>>>>
>>>> * v0.4.0 core + objectstore-nosql + viewer-scimpi     // a "scimpi/nosql
>>>> release" - eg tested and released by Rob
>>>>
>>>> * v0.5.0 core + objectstore-dflt + objectstore-xml + viewer-dnd     // a
>>>> "dev env release" - eg tested and released by Rob
>>>>
>>>> * v0.6.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
>>>> // another "wicket/jdo release"
>>>>
>>>> * v0.7.0 core + objectstore-sql + viewer-html     // a "html/sql
>>>> release"
>>>> -
>>>> eg tested and released by Kevin
>>>>
>>>> * v0.8.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
>>>> // another "wicket/jdo release"
>>>>
>>>> Whenever a release goes out, we would update our website to indicate the
>>>> most recent version of the components.
>>>>
>>>> Now, when I say "release", what I actually mean here is the deployment
>>>> of
>>>> binary artifacts up to the Maven central repo. This, after all, is what
>>>> most users/would-be users in the community would use and consider a
>>>> release. However, Apache's own formal definition of "release" is
>>>> actually
>>>> the source code release ... this is what the [VOTE] mechanism is for. I
>>>> don't see this changing... the vote basically says that the software
>>>> complies with all the legal license stuff etc. The whole codebase is
>>>> tagged
>>>> with that release number, and the generated src.zip is a zip of this
>>>> release.
>>>>
>>>> One benefit of this is that it allows the deployment of other modules to
>>>> be
>>>> performed "after the fact". For example, suppose that I (Dan) puts out
>>>> the
>>>> v0.3.1 release as above, and then Rob later on tests the scimpi viewer
>>>> in
>>>> that tag and finds it works well. He can (I think) push the release of
>>>> the
>>>> scimpi viewer up to Maven central repo.
>>>>
>>>> As I see things there are several benefits to this scheme:
>>>>
>>>> a) (as already noted) the user community will only see binary releases
>>>> that
>>>> are known to be of production ready. This should mitigate the "is it
>>>> safe
>>>> to use this component" worry
>>>> b) (as hinted at) it should be possible for individual contributors to
>>>> put
>>>> out releases of their modules more rapidly
>>>> c) we get visibility of which modules aren't being released; for
>>>> example,
>>>> we might say that if a module hasn't been released by anyone for 18 or
>>>> 24
>>>> months, say, then it's probably time to remove it from the codebase.
>>>>
>>>> ~~~
>>>>
>>>> In order to support the above scheme, I propose that we rearrange some
>>>> of
>>>> the modules so that they can be more easily included within Maven
>>>> modules.  I've
>>>> created a page on our wiki [1] which shows my proposed rearrangement.
>>>>  It
>>>> also repeats the above discussion text by way of context.
>>>>
>>>>
>>>> Opinions welcome!
>>>>
>>>> Thx
>>>>
>>>> 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

[Minto van der Sluis <mi...@xup.nl>]

Hi Rob,

With git you clone an entire repository.

Regards,

Minto


Op 29-11-2012 22:12, Robert Matthews schreef:
> Dan,
>
> Can you clarify something for me as I haven't had time to read my Git
> book. Do you have to check out the entire repository when using Git or
> can you check a specific directory as you can with Subversion? I'm
> assuming that you have to as you're suggesting new repositories for
> for each subproject.
>
> Regards
>
> Rob
>
>
> On 11/29/12 20:20, Dan Haywood wrote:
>> Hi Rob,
>>
>> Thanks for these thoughts... sounds like we are somewhat in the same
>> boat
>> in that we want to push out new releases, but don't know enough about
>> the
>> (state of the) other modules to know whether it is safe to do so.
>>
>> And so, yes, breaking up the codebase into separate submodules is the
>> obvious next step, and something that you and I have discussed several
>> times in the past off-list.  I don't have any issue with doing it
>> myself,
>> it's an obvious evolution from my proposal.
>>
>> The concept of an edition, then, I think equates to an archetype: it's a
>> project template to get a would-be used up-and-running quickly with a
>> precanned set of modules.
>>
>> What I therefore suggest is that we:
>>
>> 1. wait for Infra to move our code from svn to git (soon, I hope...)
>> 2. flatten out the modules as I outlined in the wiki page
>> 3. raise another ticket for infra to create new repos for each of the
>> modules that we want to release separately... seems to me that these
>> could
>> start out as clones of the original
>> 4. when those new submodule repos exist, we can zap remove all the
>> foreign
>> stuff; conversely, in the original repo, we zap the code for which there
>> are now submodule repos
>>
>> The new repos that I see us needing are:
>> - viewer-wicket
>> - viewer-scimpi
>> - viewer-restful
>> - viewer-html
>> - objectstore-jdo
>> - objectstore-nosql
>> - objectstore-sql
>> - editions                   // for the various archetypes we might
>> want to
>> create.
>>
>> For the other modules that are not core (eg progmodel-groovy, or
>> viewer-junit), I'd rather leave them in the "default" repo, but not
>> release
>> them until there is a need.  For these we can use a Maven profile to
>> exclude them from the release process.
>>
>> Although overall this introduces a little bit more formality into the
>> proceedings, I do think that the time is now right to do this.  And, I
>> think it properly answers all the objections that Giovanni raised
>> earlier
>> in this thread.
>>
>> What say we all?
>>
>> Dan
>>
>>
>> On 29 November 2012 20:00, Robert Matthews
>> <rm...@nakedobjects.org>wrote:
>>
>>> First and foremost, I think we should release things more granularly so
>>> individual components (most of our Maven modules) can be worked on more
>>> independently. I would find it great to be able to work on improving
>>> the
>>> NOSQL store or the Scimpi viewer without having to consider that every
>>> other module has to be got into a releasable state just so one ready
>>> module
>>> can be released.  Most of the modules, outside of the core,  are fairly
>>> independent, typically relying only on the core and will work other
>>> versions of other components, eg a viewer is not typically dependent
>>> on an
>>> object store. Basically, we have the core modules, which need to be
>>> maintained and released together, then we have a whole pile of major
>>> component, mostly that can be developed independently.
>>>
>>> The "editions", as I think someone referred to them, are a
>>> combination of
>>> the components that are useful together, but are just that. They are
>>> lightweight, just specifying how to pull those components together and
>>> providing supporting resources like examples, configurations and extra
>>> documentation.  Think of these like Linux distributions, they pull
>>> together
>>> a host of programs together to create a, sometimes unique, set up.  The
>>> distribution is just a collation of all the programs along with the
>>> installer, some specific graphics and preconfigured settings. The
>>> programs
>>> themselves are developed, and also available,  separately.
>>>
>>> Instead of keeping it all monolithic and using profiles to control
>>> what is
>>> released (and what isn't) I think we should break it up into:-
>>>
>>>      A "Core"
>>>      Individual "Components" (viewer, object stores etc)
>>>      Specially targetted "Editions" (SOA, Web Framework, Modeller's
>>> toolbox
>>> etc)
>>>
>>> This would obviously affect both the organisation of the code and be
>>> reflected in the site as a series of subprojects (like a number of
>>> Apache
>>> project do, like James, Maven, Velocity and Xerces).
>>>
>>> (Doesn't Eclipse actually something just like this - they have a core,
>>> there are are series of components that work with it and they provide
>>> different "editions" that target different types of user.)
>>>
>>> Another benefit of working this way is that a (new) developer can
>>> concentrate on a single component, i.e., check out a small amount of
>>> code,
>>> use Maven to sort of the dependencies to other framework classes, which
>>> will download the jars and then focus on just that one module.
>>>
>>> Just a few thoughts.
>>>
>>> Regards
>>>
>>> Rob
>>>
>>>
>>>
>>>
>>> On 11/29/12 14:36, Dan Haywood wrote:
>>>
>>>> This discussion post is mostly to the contributors, but cc:ing to user
>>>> list
>>>> for opinions also...
>>>>
>>>> ~~~
>>>>
>>>> At the moment it's a daunting task to fully verify all the
>>>> components of
>>>> the framework are working correctly prior to pushing out a release. I
>>>> suppose that wouldn't be so much of a concern if we had better
>>>> automated
>>>> tests, but, hey, that's how things are.
>>>>
>>>> Moreover, frankly, some of the modules are best considered spikes and
>>>> probably don't constitute something that we would consider
>>>> production-ready. Or, at least, they haven't been used in a real-world
>>>> context, so it's not possible to say whether they are really
>>>> fit-for-purpose. I include here quite a lot of the stuff that I have
>>>> worked
>>>> on over the last few years, eg the wrapper-progmodel, the groovy
>>>> progmodel,
>>>> probably also the JUnit viewer and BDD viewer. Now that we are a
>>>> top-level
>>>> project, I'd like it that the code we put out is thought of as
>>>> production
>>>> ready.
>>>>
>>>> In order to make the framework easier to release, I propose that we
>>>> use
>>>> Maven profiles to be able to release subsets of modules, that a given
>>>> contributor can stand behind and say: "yes, those modules are
>>>> working and
>>>> are fit for general consumption". Each release would consist of the
>>>> certain
>>>> core modules, along with selected additional viewers and object
>>>> stores.
>>>>
>>>> For example, over time we might end up releasing:
>>>>
>>>> * v0.3.1 core + objectstore-jdo + viewer-wicket +
>>>> viewer-restfulobjects
>>>>    // a "wicket/jdo release" - eg tested and released by Dan
>>>>
>>>> * v0.4.0 core + objectstore-nosql + viewer-scimpi     // a
>>>> "scimpi/nosql
>>>> release" - eg tested and released by Rob
>>>>
>>>> * v0.5.0 core + objectstore-dflt + objectstore-xml + viewer-dnd    
>>>> // a
>>>> "dev env release" - eg tested and released by Rob
>>>>
>>>> * v0.6.0 core + objectstore-jdo + viewer-wicket +
>>>> viewer-restfulobjects
>>>> // another "wicket/jdo release"
>>>>
>>>> * v0.7.0 core + objectstore-sql + viewer-html     // a "html/sql
>>>> release"
>>>> -
>>>> eg tested and released by Kevin
>>>>
>>>> * v0.8.0 core + objectstore-jdo + viewer-wicket +
>>>> viewer-restfulobjects
>>>> // another "wicket/jdo release"
>>>>
>>>> Whenever a release goes out, we would update our website to
>>>> indicate the
>>>> most recent version of the components.
>>>>
>>>> Now, when I say "release", what I actually mean here is the
>>>> deployment of
>>>> binary artifacts up to the Maven central repo. This, after all, is
>>>> what
>>>> most users/would-be users in the community would use and consider a
>>>> release. However, Apache's own formal definition of "release" is
>>>> actually
>>>> the source code release ... this is what the [VOTE] mechanism is
>>>> for. I
>>>> don't see this changing... the vote basically says that the software
>>>> complies with all the legal license stuff etc. The whole codebase is
>>>> tagged
>>>> with that release number, and the generated src.zip is a zip of this
>>>> release.
>>>>
>>>> One benefit of this is that it allows the deployment of other
>>>> modules to
>>>> be
>>>> performed "after the fact". For example, suppose that I (Dan) puts
>>>> out the
>>>> v0.3.1 release as above, and then Rob later on tests the scimpi
>>>> viewer in
>>>> that tag and finds it works well. He can (I think) push the release
>>>> of the
>>>> scimpi viewer up to Maven central repo.
>>>>
>>>> As I see things there are several benefits to this scheme:
>>>>
>>>> a) (as already noted) the user community will only see binary releases
>>>> that
>>>> are known to be of production ready. This should mitigate the "is
>>>> it safe
>>>> to use this component" worry
>>>> b) (as hinted at) it should be possible for individual contributors
>>>> to put
>>>> out releases of their modules more rapidly
>>>> c) we get visibility of which modules aren't being released; for
>>>> example,
>>>> we might say that if a module hasn't been released by anyone for 18
>>>> or 24
>>>> months, say, then it's probably time to remove it from the codebase.
>>>>
>>>> ~~~
>>>>
>>>> In order to support the above scheme, I propose that we rearrange
>>>> some of
>>>> the modules so that they can be more easily included within Maven
>>>> modules.  I've
>>>> created a page on our wiki [1] which shows my proposed
>>>> rearrangement.  It
>>>> also repeats the above discussion text by way of context.
>>>>
>>>>
>>>> Opinions welcome!
>>>>
>>>> Thx
>>>>
>>>> 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>
>>>>
>>>>
>>>>
>


-- 
ir. ing. Minto van der Sluis
Software innovator / renovator
Xup BV

Mobiel: +31 (0) 626 014541

Re: [DISCUSSION] Making releases easier and more frequent

[Robert Matthews <rm...@nakedobjects.org>]

Dan,

Can you clarify something for me as I haven't had time to read my Git 
book. Do you have to check out the entire repository when using Git or 
can you check a specific directory as you can with Subversion? I'm 
assuming that you have to as you're suggesting new repositories for for 
each subproject.

Regards

Rob


On 11/29/12 20:20, Dan Haywood wrote:
> Hi Rob,
>
> Thanks for these thoughts... sounds like we are somewhat in the same boat
> in that we want to push out new releases, but don't know enough about the
> (state of the) other modules to know whether it is safe to do so.
>
> And so, yes, breaking up the codebase into separate submodules is the
> obvious next step, and something that you and I have discussed several
> times in the past off-list.  I don't have any issue with doing it myself,
> it's an obvious evolution from my proposal.
>
> The concept of an edition, then, I think equates to an archetype: it's a
> project template to get a would-be used up-and-running quickly with a
> precanned set of modules.
>
> What I therefore suggest is that we:
>
> 1. wait for Infra to move our code from svn to git (soon, I hope...)
> 2. flatten out the modules as I outlined in the wiki page
> 3. raise another ticket for infra to create new repos for each of the
> modules that we want to release separately... seems to me that these could
> start out as clones of the original
> 4. when those new submodule repos exist, we can zap remove all the foreign
> stuff; conversely, in the original repo, we zap the code for which there
> are now submodule repos
>
> The new repos that I see us needing are:
> - viewer-wicket
> - viewer-scimpi
> - viewer-restful
> - viewer-html
> - objectstore-jdo
> - objectstore-nosql
> - objectstore-sql
> - editions                   // for the various archetypes we might want to
> create.
>
> For the other modules that are not core (eg progmodel-groovy, or
> viewer-junit), I'd rather leave them in the "default" repo, but not release
> them until there is a need.  For these we can use a Maven profile to
> exclude them from the release process.
>
> Although overall this introduces a little bit more formality into the
> proceedings, I do think that the time is now right to do this.  And, I
> think it properly answers all the objections that Giovanni raised earlier
> in this thread.
>
> What say we all?
>
> Dan
>
>
> On 29 November 2012 20:00, Robert Matthews <rm...@nakedobjects.org>wrote:
>
>> First and foremost, I think we should release things more granularly so
>> individual components (most of our Maven modules) can be worked on more
>> independently. I would find it great to be able to work on improving the
>> NOSQL store or the Scimpi viewer without having to consider that every
>> other module has to be got into a releasable state just so one ready module
>> can be released.  Most of the modules, outside of the core,  are fairly
>> independent, typically relying only on the core and will work other
>> versions of other components, eg a viewer is not typically dependent on an
>> object store. Basically, we have the core modules, which need to be
>> maintained and released together, then we have a whole pile of major
>> component, mostly that can be developed independently.
>>
>> The "editions", as I think someone referred to them, are a combination of
>> the components that are useful together, but are just that. They are
>> lightweight, just specifying how to pull those components together and
>> providing supporting resources like examples, configurations and extra
>> documentation.  Think of these like Linux distributions, they pull together
>> a host of programs together to create a, sometimes unique, set up.  The
>> distribution is just a collation of all the programs along with the
>> installer, some specific graphics and preconfigured settings. The programs
>> themselves are developed, and also available,  separately.
>>
>> Instead of keeping it all monolithic and using profiles to control what is
>> released (and what isn't) I think we should break it up into:-
>>
>>      A "Core"
>>      Individual "Components" (viewer, object stores etc)
>>      Specially targetted "Editions" (SOA, Web Framework, Modeller's toolbox
>> etc)
>>
>> This would obviously affect both the organisation of the code and be
>> reflected in the site as a series of subprojects (like a number of Apache
>> project do, like James, Maven, Velocity and Xerces).
>>
>> (Doesn't Eclipse actually something just like this - they have a core,
>> there are are series of components that work with it and they provide
>> different "editions" that target different types of user.)
>>
>> Another benefit of working this way is that a (new) developer can
>> concentrate on a single component, i.e., check out a small amount of code,
>> use Maven to sort of the dependencies to other framework classes, which
>> will download the jars and then focus on just that one module.
>>
>> Just a few thoughts.
>>
>> Regards
>>
>> Rob
>>
>>
>>
>>
>> On 11/29/12 14:36, Dan Haywood wrote:
>>
>>> This discussion post is mostly to the contributors, but cc:ing to user
>>> list
>>> for opinions also...
>>>
>>> ~~~
>>>
>>> At the moment it's a daunting task to fully verify all the components of
>>> the framework are working correctly prior to pushing out a release. I
>>> suppose that wouldn't be so much of a concern if we had better automated
>>> tests, but, hey, that's how things are.
>>>
>>> Moreover, frankly, some of the modules are best considered spikes and
>>> probably don't constitute something that we would consider
>>> production-ready. Or, at least, they haven't been used in a real-world
>>> context, so it's not possible to say whether they are really
>>> fit-for-purpose. I include here quite a lot of the stuff that I have
>>> worked
>>> on over the last few years, eg the wrapper-progmodel, the groovy
>>> progmodel,
>>> probably also the JUnit viewer and BDD viewer. Now that we are a top-level
>>> project, I'd like it that the code we put out is thought of as production
>>> ready.
>>>
>>> In order to make the framework easier to release, I propose that we use
>>> Maven profiles to be able to release subsets of modules, that a given
>>> contributor can stand behind and say: "yes, those modules are working and
>>> are fit for general consumption". Each release would consist of the
>>> certain
>>> core modules, along with selected additional viewers and object stores.
>>>
>>> For example, over time we might end up releasing:
>>>
>>> * v0.3.1 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
>>>    // a "wicket/jdo release" - eg tested and released by Dan
>>>
>>> * v0.4.0 core + objectstore-nosql + viewer-scimpi     // a "scimpi/nosql
>>> release" - eg tested and released by Rob
>>>
>>> * v0.5.0 core + objectstore-dflt + objectstore-xml + viewer-dnd     // a
>>> "dev env release" - eg tested and released by Rob
>>>
>>> * v0.6.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
>>> // another "wicket/jdo release"
>>>
>>> * v0.7.0 core + objectstore-sql + viewer-html     // a "html/sql release"
>>> -
>>> eg tested and released by Kevin
>>>
>>> * v0.8.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
>>> // another "wicket/jdo release"
>>>
>>> Whenever a release goes out, we would update our website to indicate the
>>> most recent version of the components.
>>>
>>> Now, when I say "release", what I actually mean here is the deployment of
>>> binary artifacts up to the Maven central repo. This, after all, is what
>>> most users/would-be users in the community would use and consider a
>>> release. However, Apache's own formal definition of "release" is actually
>>> the source code release ... this is what the [VOTE] mechanism is for. I
>>> don't see this changing... the vote basically says that the software
>>> complies with all the legal license stuff etc. The whole codebase is
>>> tagged
>>> with that release number, and the generated src.zip is a zip of this
>>> release.
>>>
>>> One benefit of this is that it allows the deployment of other modules to
>>> be
>>> performed "after the fact". For example, suppose that I (Dan) puts out the
>>> v0.3.1 release as above, and then Rob later on tests the scimpi viewer in
>>> that tag and finds it works well. He can (I think) push the release of the
>>> scimpi viewer up to Maven central repo.
>>>
>>> As I see things there are several benefits to this scheme:
>>>
>>> a) (as already noted) the user community will only see binary releases
>>> that
>>> are known to be of production ready. This should mitigate the "is it safe
>>> to use this component" worry
>>> b) (as hinted at) it should be possible for individual contributors to put
>>> out releases of their modules more rapidly
>>> c) we get visibility of which modules aren't being released; for example,
>>> we might say that if a module hasn't been released by anyone for 18 or 24
>>> months, say, then it's probably time to remove it from the codebase.
>>>
>>> ~~~
>>>
>>> In order to support the above scheme, I propose that we rearrange some of
>>> the modules so that they can be more easily included within Maven
>>> modules.  I've
>>> created a page on our wiki [1] which shows my proposed rearrangement.  It
>>> also repeats the above discussion text by way of context.
>>>
>>>
>>> Opinions welcome!
>>>
>>> Thx
>>>
>>> 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

[Dan Haywood <da...@haywood-associates.co.uk>]

Hi Rob,

Thanks for these thoughts... sounds like we are somewhat in the same boat
in that we want to push out new releases, but don't know enough about the
(state of the) other modules to know whether it is safe to do so.

And so, yes, breaking up the codebase into separate submodules is the
obvious next step, and something that you and I have discussed several
times in the past off-list.  I don't have any issue with doing it myself,
it's an obvious evolution from my proposal.

The concept of an edition, then, I think equates to an archetype: it's a
project template to get a would-be used up-and-running quickly with a
precanned set of modules.

What I therefore suggest is that we:

1. wait for Infra to move our code from svn to git (soon, I hope...)
2. flatten out the modules as I outlined in the wiki page
3. raise another ticket for infra to create new repos for each of the
modules that we want to release separately... seems to me that these could
start out as clones of the original
4. when those new submodule repos exist, we can zap remove all the foreign
stuff; conversely, in the original repo, we zap the code for which there
are now submodule repos

The new repos that I see us needing are:
- viewer-wicket
- viewer-scimpi
- viewer-restful
- viewer-html
- objectstore-jdo
- objectstore-nosql
- objectstore-sql
- editions                   // for the various archetypes we might want to
create.

For the other modules that are not core (eg progmodel-groovy, or
viewer-junit), I'd rather leave them in the "default" repo, but not release
them until there is a need.  For these we can use a Maven profile to
exclude them from the release process.

Although overall this introduces a little bit more formality into the
proceedings, I do think that the time is now right to do this.  And, I
think it properly answers all the objections that Giovanni raised earlier
in this thread.

What say we all?

Dan


On 29 November 2012 20:00, Robert Matthews <rm...@nakedobjects.org>wrote:

> First and foremost, I think we should release things more granularly so
> individual components (most of our Maven modules) can be worked on more
> independently. I would find it great to be able to work on improving the
> NOSQL store or the Scimpi viewer without having to consider that every
> other module has to be got into a releasable state just so one ready module
> can be released.  Most of the modules, outside of the core,  are fairly
> independent, typically relying only on the core and will work other
> versions of other components, eg a viewer is not typically dependent on an
> object store. Basically, we have the core modules, which need to be
> maintained and released together, then we have a whole pile of major
> component, mostly that can be developed independently.
>
> The "editions", as I think someone referred to them, are a combination of
> the components that are useful together, but are just that. They are
> lightweight, just specifying how to pull those components together and
> providing supporting resources like examples, configurations and extra
> documentation.  Think of these like Linux distributions, they pull together
> a host of programs together to create a, sometimes unique, set up.  The
> distribution is just a collation of all the programs along with the
> installer, some specific graphics and preconfigured settings. The programs
> themselves are developed, and also available,  separately.
>
> Instead of keeping it all monolithic and using profiles to control what is
> released (and what isn't) I think we should break it up into:-
>
>     A "Core"
>     Individual "Components" (viewer, object stores etc)
>     Specially targetted "Editions" (SOA, Web Framework, Modeller's toolbox
> etc)
>
> This would obviously affect both the organisation of the code and be
> reflected in the site as a series of subprojects (like a number of Apache
> project do, like James, Maven, Velocity and Xerces).
>
> (Doesn't Eclipse actually something just like this - they have a core,
> there are are series of components that work with it and they provide
> different "editions" that target different types of user.)
>
> Another benefit of working this way is that a (new) developer can
> concentrate on a single component, i.e., check out a small amount of code,
> use Maven to sort of the dependencies to other framework classes, which
> will download the jars and then focus on just that one module.
>
> Just a few thoughts.
>
> Regards
>
> Rob
>
>
>
>
> On 11/29/12 14:36, Dan Haywood wrote:
>
>> This discussion post is mostly to the contributors, but cc:ing to user
>> list
>> for opinions also...
>>
>> ~~~
>>
>> At the moment it's a daunting task to fully verify all the components of
>> the framework are working correctly prior to pushing out a release. I
>> suppose that wouldn't be so much of a concern if we had better automated
>> tests, but, hey, that's how things are.
>>
>> Moreover, frankly, some of the modules are best considered spikes and
>> probably don't constitute something that we would consider
>> production-ready. Or, at least, they haven't been used in a real-world
>> context, so it's not possible to say whether they are really
>> fit-for-purpose. I include here quite a lot of the stuff that I have
>> worked
>> on over the last few years, eg the wrapper-progmodel, the groovy
>> progmodel,
>> probably also the JUnit viewer and BDD viewer. Now that we are a top-level
>> project, I'd like it that the code we put out is thought of as production
>> ready.
>>
>> In order to make the framework easier to release, I propose that we use
>> Maven profiles to be able to release subsets of modules, that a given
>> contributor can stand behind and say: "yes, those modules are working and
>> are fit for general consumption". Each release would consist of the
>> certain
>> core modules, along with selected additional viewers and object stores.
>>
>> For example, over time we might end up releasing:
>>
>> * v0.3.1 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
>>   // a "wicket/jdo release" - eg tested and released by Dan
>>
>> * v0.4.0 core + objectstore-nosql + viewer-scimpi     // a "scimpi/nosql
>> release" - eg tested and released by Rob
>>
>> * v0.5.0 core + objectstore-dflt + objectstore-xml + viewer-dnd     // a
>> "dev env release" - eg tested and released by Rob
>>
>> * v0.6.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
>> // another "wicket/jdo release"
>>
>> * v0.7.0 core + objectstore-sql + viewer-html     // a "html/sql release"
>> -
>> eg tested and released by Kevin
>>
>> * v0.8.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
>> // another "wicket/jdo release"
>>
>> Whenever a release goes out, we would update our website to indicate the
>> most recent version of the components.
>>
>> Now, when I say "release", what I actually mean here is the deployment of
>> binary artifacts up to the Maven central repo. This, after all, is what
>> most users/would-be users in the community would use and consider a
>> release. However, Apache's own formal definition of "release" is actually
>> the source code release ... this is what the [VOTE] mechanism is for. I
>> don't see this changing... the vote basically says that the software
>> complies with all the legal license stuff etc. The whole codebase is
>> tagged
>> with that release number, and the generated src.zip is a zip of this
>> release.
>>
>> One benefit of this is that it allows the deployment of other modules to
>> be
>> performed "after the fact". For example, suppose that I (Dan) puts out the
>> v0.3.1 release as above, and then Rob later on tests the scimpi viewer in
>> that tag and finds it works well. He can (I think) push the release of the
>> scimpi viewer up to Maven central repo.
>>
>> As I see things there are several benefits to this scheme:
>>
>> a) (as already noted) the user community will only see binary releases
>> that
>> are known to be of production ready. This should mitigate the "is it safe
>> to use this component" worry
>> b) (as hinted at) it should be possible for individual contributors to put
>> out releases of their modules more rapidly
>> c) we get visibility of which modules aren't being released; for example,
>> we might say that if a module hasn't been released by anyone for 18 or 24
>> months, say, then it's probably time to remove it from the codebase.
>>
>> ~~~
>>
>> In order to support the above scheme, I propose that we rearrange some of
>> the modules so that they can be more easily included within Maven
>> modules.  I've
>> created a page on our wiki [1] which shows my proposed rearrangement.  It
>> also repeats the above discussion text by way of context.
>>
>>
>> Opinions welcome!
>>
>> Thx
>>
>> 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

[Dan Haywood <da...@haywood-associates.co.uk>]

Hi Rob,

Thanks for these thoughts... sounds like we are somewhat in the same boat
in that we want to push out new releases, but don't know enough about the
(state of the) other modules to know whether it is safe to do so.

And so, yes, breaking up the codebase into separate submodules is the
obvious next step, and something that you and I have discussed several
times in the past off-list.  I don't have any issue with doing it myself,
it's an obvious evolution from my proposal.

The concept of an edition, then, I think equates to an archetype: it's a
project template to get a would-be used up-and-running quickly with a
precanned set of modules.

What I therefore suggest is that we:

1. wait for Infra to move our code from svn to git (soon, I hope...)
2. flatten out the modules as I outlined in the wiki page
3. raise another ticket for infra to create new repos for each of the
modules that we want to release separately... seems to me that these could
start out as clones of the original
4. when those new submodule repos exist, we can zap remove all the foreign
stuff; conversely, in the original repo, we zap the code for which there
are now submodule repos

The new repos that I see us needing are:
- viewer-wicket
- viewer-scimpi
- viewer-restful
- viewer-html
- objectstore-jdo
- objectstore-nosql
- objectstore-sql
- editions                   // for the various archetypes we might want to
create.

For the other modules that are not core (eg progmodel-groovy, or
viewer-junit), I'd rather leave them in the "default" repo, but not release
them until there is a need.  For these we can use a Maven profile to
exclude them from the release process.

Although overall this introduces a little bit more formality into the
proceedings, I do think that the time is now right to do this.  And, I
think it properly answers all the objections that Giovanni raised earlier
in this thread.

What say we all?

Dan


On 29 November 2012 20:00, Robert Matthews <rm...@nakedobjects.org>wrote:

> First and foremost, I think we should release things more granularly so
> individual components (most of our Maven modules) can be worked on more
> independently. I would find it great to be able to work on improving the
> NOSQL store or the Scimpi viewer without having to consider that every
> other module has to be got into a releasable state just so one ready module
> can be released.  Most of the modules, outside of the core,  are fairly
> independent, typically relying only on the core and will work other
> versions of other components, eg a viewer is not typically dependent on an
> object store. Basically, we have the core modules, which need to be
> maintained and released together, then we have a whole pile of major
> component, mostly that can be developed independently.
>
> The "editions", as I think someone referred to them, are a combination of
> the components that are useful together, but are just that. They are
> lightweight, just specifying how to pull those components together and
> providing supporting resources like examples, configurations and extra
> documentation.  Think of these like Linux distributions, they pull together
> a host of programs together to create a, sometimes unique, set up.  The
> distribution is just a collation of all the programs along with the
> installer, some specific graphics and preconfigured settings. The programs
> themselves are developed, and also available,  separately.
>
> Instead of keeping it all monolithic and using profiles to control what is
> released (and what isn't) I think we should break it up into:-
>
>     A "Core"
>     Individual "Components" (viewer, object stores etc)
>     Specially targetted "Editions" (SOA, Web Framework, Modeller's toolbox
> etc)
>
> This would obviously affect both the organisation of the code and be
> reflected in the site as a series of subprojects (like a number of Apache
> project do, like James, Maven, Velocity and Xerces).
>
> (Doesn't Eclipse actually something just like this - they have a core,
> there are are series of components that work with it and they provide
> different "editions" that target different types of user.)
>
> Another benefit of working this way is that a (new) developer can
> concentrate on a single component, i.e., check out a small amount of code,
> use Maven to sort of the dependencies to other framework classes, which
> will download the jars and then focus on just that one module.
>
> Just a few thoughts.
>
> Regards
>
> Rob
>
>
>
>
> On 11/29/12 14:36, Dan Haywood wrote:
>
>> This discussion post is mostly to the contributors, but cc:ing to user
>> list
>> for opinions also...
>>
>> ~~~
>>
>> At the moment it's a daunting task to fully verify all the components of
>> the framework are working correctly prior to pushing out a release. I
>> suppose that wouldn't be so much of a concern if we had better automated
>> tests, but, hey, that's how things are.
>>
>> Moreover, frankly, some of the modules are best considered spikes and
>> probably don't constitute something that we would consider
>> production-ready. Or, at least, they haven't been used in a real-world
>> context, so it's not possible to say whether they are really
>> fit-for-purpose. I include here quite a lot of the stuff that I have
>> worked
>> on over the last few years, eg the wrapper-progmodel, the groovy
>> progmodel,
>> probably also the JUnit viewer and BDD viewer. Now that we are a top-level
>> project, I'd like it that the code we put out is thought of as production
>> ready.
>>
>> In order to make the framework easier to release, I propose that we use
>> Maven profiles to be able to release subsets of modules, that a given
>> contributor can stand behind and say: "yes, those modules are working and
>> are fit for general consumption". Each release would consist of the
>> certain
>> core modules, along with selected additional viewers and object stores.
>>
>> For example, over time we might end up releasing:
>>
>> * v0.3.1 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
>>   // a "wicket/jdo release" - eg tested and released by Dan
>>
>> * v0.4.0 core + objectstore-nosql + viewer-scimpi     // a "scimpi/nosql
>> release" - eg tested and released by Rob
>>
>> * v0.5.0 core + objectstore-dflt + objectstore-xml + viewer-dnd     // a
>> "dev env release" - eg tested and released by Rob
>>
>> * v0.6.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
>> // another "wicket/jdo release"
>>
>> * v0.7.0 core + objectstore-sql + viewer-html     // a "html/sql release"
>> -
>> eg tested and released by Kevin
>>
>> * v0.8.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
>> // another "wicket/jdo release"
>>
>> Whenever a release goes out, we would update our website to indicate the
>> most recent version of the components.
>>
>> Now, when I say "release", what I actually mean here is the deployment of
>> binary artifacts up to the Maven central repo. This, after all, is what
>> most users/would-be users in the community would use and consider a
>> release. However, Apache's own formal definition of "release" is actually
>> the source code release ... this is what the [VOTE] mechanism is for. I
>> don't see this changing... the vote basically says that the software
>> complies with all the legal license stuff etc. The whole codebase is
>> tagged
>> with that release number, and the generated src.zip is a zip of this
>> release.
>>
>> One benefit of this is that it allows the deployment of other modules to
>> be
>> performed "after the fact". For example, suppose that I (Dan) puts out the
>> v0.3.1 release as above, and then Rob later on tests the scimpi viewer in
>> that tag and finds it works well. He can (I think) push the release of the
>> scimpi viewer up to Maven central repo.
>>
>> As I see things there are several benefits to this scheme:
>>
>> a) (as already noted) the user community will only see binary releases
>> that
>> are known to be of production ready. This should mitigate the "is it safe
>> to use this component" worry
>> b) (as hinted at) it should be possible for individual contributors to put
>> out releases of their modules more rapidly
>> c) we get visibility of which modules aren't being released; for example,
>> we might say that if a module hasn't been released by anyone for 18 or 24
>> months, say, then it's probably time to remove it from the codebase.
>>
>> ~~~
>>
>> In order to support the above scheme, I propose that we rearrange some of
>> the modules so that they can be more easily included within Maven
>> modules.  I've
>> created a page on our wiki [1] which shows my proposed rearrangement.  It
>> also repeats the above discussion text by way of context.
>>
>>
>> Opinions welcome!
>>
>> Thx
>>
>> 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

[Robert Matthews <rm...@nakedobjects.org>]

First and foremost, I think we should release things more granularly so 
individual components (most of our Maven modules) can be worked on more 
independently. I would find it great to be able to work on improving the 
NOSQL store or the Scimpi viewer without having to consider that every 
other module has to be got into a releasable state just so one ready 
module can be released.  Most of the modules, outside of the core,  are 
fairly independent, typically relying only on the core and will work 
other versions of other components, eg a viewer is not typically 
dependent on an object store. Basically, we have the core modules, which 
need to be maintained and released together, then we have a whole pile 
of major component, mostly that can be developed independently.

The "editions", as I think someone referred to them, are a combination 
of the components that are useful together, but are just that. They are 
lightweight, just specifying how to pull those components together and 
providing supporting resources like examples, configurations and extra 
documentation.  Think of these like Linux distributions, they pull 
together a host of programs together to create a, sometimes unique, set 
up.  The distribution is just a collation of all the programs along with 
the installer, some specific graphics and preconfigured settings. The 
programs themselves are developed, and also available,  separately.

Instead of keeping it all monolithic and using profiles to control what 
is released (and what isn't) I think we should break it up into:-

     A "Core"
     Individual "Components" (viewer, object stores etc)
     Specially targetted "Editions" (SOA, Web Framework, Modeller's 
toolbox etc)

This would obviously affect both the organisation of the code and be 
reflected in the site as a series of subprojects (like a number of 
Apache project do, like James, Maven, Velocity and Xerces).

(Doesn't Eclipse actually something just like this - they have a core, 
there are are series of components that work with it and they provide 
different "editions" that target different types of user.)

Another benefit of working this way is that a (new) developer can 
concentrate on a single component, i.e., check out a small amount of 
code, use Maven to sort of the dependencies to other framework classes, 
which will download the jars and then focus on just that one module.

Just a few thoughts.

Regards

Rob



On 11/29/12 14:36, Dan Haywood wrote:
> This discussion post is mostly to the contributors, but cc:ing to user list
> for opinions also...
>
> ~~~
>
> At the moment it's a daunting task to fully verify all the components of
> the framework are working correctly prior to pushing out a release. I
> suppose that wouldn't be so much of a concern if we had better automated
> tests, but, hey, that's how things are.
>
> Moreover, frankly, some of the modules are best considered spikes and
> probably don't constitute something that we would consider
> production-ready. Or, at least, they haven't been used in a real-world
> context, so it's not possible to say whether they are really
> fit-for-purpose. I include here quite a lot of the stuff that I have worked
> on over the last few years, eg the wrapper-progmodel, the groovy progmodel,
> probably also the JUnit viewer and BDD viewer. Now that we are a top-level
> project, I'd like it that the code we put out is thought of as production
> ready.
>
> In order to make the framework easier to release, I propose that we use
> Maven profiles to be able to release subsets of modules, that a given
> contributor can stand behind and say: "yes, those modules are working and
> are fit for general consumption". Each release would consist of the certain
> core modules, along with selected additional viewers and object stores.
>
> For example, over time we might end up releasing:
>
> * v0.3.1 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
>   // a "wicket/jdo release" - eg tested and released by Dan
>
> * v0.4.0 core + objectstore-nosql + viewer-scimpi     // a "scimpi/nosql
> release" - eg tested and released by Rob
>
> * v0.5.0 core + objectstore-dflt + objectstore-xml + viewer-dnd     // a
> "dev env release" - eg tested and released by Rob
>
> * v0.6.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
> // another "wicket/jdo release"
>
> * v0.7.0 core + objectstore-sql + viewer-html     // a "html/sql release" -
> eg tested and released by Kevin
>
> * v0.8.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
> // another "wicket/jdo release"
>
> Whenever a release goes out, we would update our website to indicate the
> most recent version of the components.
>
> Now, when I say "release", what I actually mean here is the deployment of
> binary artifacts up to the Maven central repo. This, after all, is what
> most users/would-be users in the community would use and consider a
> release. However, Apache's own formal definition of "release" is actually
> the source code release ... this is what the [VOTE] mechanism is for. I
> don't see this changing... the vote basically says that the software
> complies with all the legal license stuff etc. The whole codebase is tagged
> with that release number, and the generated src.zip is a zip of this
> release.
>
> One benefit of this is that it allows the deployment of other modules to be
> performed "after the fact". For example, suppose that I (Dan) puts out the
> v0.3.1 release as above, and then Rob later on tests the scimpi viewer in
> that tag and finds it works well. He can (I think) push the release of the
> scimpi viewer up to Maven central repo.
>
> As I see things there are several benefits to this scheme:
>
> a) (as already noted) the user community will only see binary releases that
> are known to be of production ready. This should mitigate the "is it safe
> to use this component" worry
> b) (as hinted at) it should be possible for individual contributors to put
> out releases of their modules more rapidly
> c) we get visibility of which modules aren't being released; for example,
> we might say that if a module hasn't been released by anyone for 18 or 24
> months, say, then it's probably time to remove it from the codebase.
>
> ~~~
>
> In order to support the above scheme, I propose that we rearrange some of
> the modules so that they can be more easily included within Maven
> modules.  I've
> created a page on our wiki [1] which shows my proposed rearrangement.  It
> also repeats the above discussion text by way of context.
>
>
> Opinions welcome!
>
> Thx
>
> Dan
>
>
> [1]
> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
>

Re: [DISCUSSION] Making releases easier and more frequent

[Dan Haywood <da...@haywood-associates.co.uk>]

Hi Giovanni,
Thanks for your thoughts on this.  I've commented inline.


On 29 November 2012 16:54, Giovanni Júnior <gi...@gmail.com> wrote:

>
> I don't know much about the development and packaging process of Isis yet,
> and I agree with any improvements that streamline it, but I want to make a
> comment, hoping I haven't read the above too fast.
>
> Assuming that the numbers v0.3.1, v0.4.0 etc correspond to sequential
> releases, users normally expect their content to be similar. Therefore the
> "distributions" approach suggested by Mathew, also used by Eclipse.
>
> Yes, that is a good point.

That said, I suspect that for many would-be users, their entry point will
be to use a quickstart archetype.  Assuming that each of the editions
provides such an archetype, then the drive-by user won't necessarily be
bothered if the versions of those match or not.

If later on a user wants to pull in modules from different editions, then
we can help out on the mailing list.




> But in the case of Isis, I fear that this approach wouldn't work well,
> since there are several interchangeable modules that would cause an
> explosion of distributions (Cartesian product or almost that).
>
> Indeed, I wouldn't expect us to provide every single combination.



> In my view, a better approach is to have only a "basic"
> distribution, containing just the modules that an ordinary user would most
> likely use (eg sql objectstore + wicket viewer + restful). The team should
> commit to maintain those modules stable in all releases.
>
>
I can see the sense in that.... and in practice, I think this is what is
likely to happen.  My expectation is that wicket/restful/JDO will be
released regularly.  If and when the other "editions" want to push out a
release, I'm likely to make sure that the wicket/restful/JDO is also
fit-to-go and can be included.   That edition would therefore be a de-facto
base.

One thing that we could do though (and Rob Matthews and I have discussed
this several times over the years) is to spawn off some separate git repos,
one per main module.  So, the core would advance 0.3.0, 0.4.0, 0.5.0 and
the owner of each module could either choose to release that module or not,
as their time/inclination allows.   That is, probably, the correct thing to
do.  It's what projects such as Maven and Hadoop do.




> Besides that, the website and the documentation would show the status of
> each of the other modules in each release, along with instructions on how
> to use them to replace the basic distribution modules.
>
> If you look at the website now you'll see that on the documentation page
[1] I am now indicating the current release status.

The instructions for replacing are (now) actually pretty easy enough: it's
a matter of commenting in the appropriate line in isis.properties, along
with providing a supplemental configuration file for the module in question
(eg persistor_datanucleus.properties for the JDO/DataNucleus objectstore).




> P. S.: Considering that Isis is becoming a top-level project,


Has become :-)


> as outlined
> above, I think we should plan an effort to gradually pay the technical
> debt that seems to exist in the automated testing area of the project.
>


Ah yes.  We should.  Patches always welcome.

Cheers
Dan

[1] http://isis.apache.org/documentation.html


> Regards,
>
> Giovanni
>
>
> 2012/11/29 Jeroen van der Wal <je...@stromboli.it>
>
> > +1
> >
> > This would make releasing so much easier. But it could also be
> interpreted
> > it as a guilt- free pass to break other editions in order to release your
> > own. And what does the master branch represent in this scenario?
> >
> > Cheers,
> >
> > Jeroen
> >
> >
> > On Thu, Nov 29, 2012 at 4:39 PM, Dan Haywood
> > <da...@haywood-associates.co.uk>wrote:
> >
> > > Hi Matthew,
> > >
> > > That's a good insight/metaphor.  Agreed.
> > >
> > > Your mail prompted me to look a little deeper into how the Apache
> release
> > > process in the master POM [1] creates the src.zip (actually, I note
> it's
> > > called source-release.zip).  And, as you hinted at, it is created by
> the
> > > maven-assembly-plugin, during the release:perform stage.  And in fact
> the
> > > name of the artifact is already parameterized as the
> > > ${sourceReleaseAssemblyDescriptor} parameter.
> > >
> > > So, picking up on your idea, I think we could have profiles that:
> > > (a) list a set of <modules>, and (b) override this parameter.
> > >
> > > To do a release would consist of:
> > >
> > > release:prepare  - tags and edits the poms
> > > release:perform   -P xxx    - builds the source zip for the "edition"
> and
> > > deploys this zip and the binary artifacts to be voted on.
> > >
> > > That seems better to me.  It would mean that a retrospective release of
> > > other editions from the same tag would require a separate run of
> > > release:perform and their own vote, but that's probably for the best.
> > >
> > > Thanks!
> > >
> > > Dan
> > >
> > >
> > > On 29 November 2012 15:09, Matthew Adams <ma...@matthewadams.me>
> > wrote:
> > >
> > > > Wouldn't these certified objectstore/viewer combos be called
> > "assemblies"
> > > > (maven), "distributions" or "distros" (geeks & me) or "editions"
> > > > (marketeze), then?  Like, "Isis: JDO/Wicket Edition" and "Isis:
> > > > NoSQL/Scimpi Edition", etc.
> > > >
> > > > Maven profiles could be used along with maven-assembly-plugin to
> > produce
> > > > the editions, and there would be a one-to-one relationship between
> > Maven
> > > > profile and edition.
> > > >
> > > > -matthew
> > > >
> > > >
> > > > On Thu, Nov 29, 2012 at 8:36 AM, Dan Haywood
> > > > <da...@haywood-associates.co.uk>wrote:
> > > >
> > > > > This discussion post is mostly to the contributors, but cc:ing to
> > user
> > > > list
> > > > > for opinions also...
> > > > >
> > > > > ~~~
> > > > >
> > > > > At the moment it's a daunting task to fully verify all the
> components
> > > of
> > > > > the framework are working correctly prior to pushing out a
> release. I
> > > > > suppose that wouldn't be so much of a concern if we had better
> > > automated
> > > > > tests, but, hey, that's how things are.
> > > > >
> > > > > Moreover, frankly, some of the modules are best considered spikes
> and
> > > > > probably don't constitute something that we would consider
> > > > > production-ready. Or, at least, they haven't been used in a
> > real-world
> > > > > context, so it's not possible to say whether they are really
> > > > > fit-for-purpose. I include here quite a lot of the stuff that I
> have
> > > > worked
> > > > > on over the last few years, eg the wrapper-progmodel, the groovy
> > > > progmodel,
> > > > > probably also the JUnit viewer and BDD viewer. Now that we are a
> > > > top-level
> > > > > project, I'd like it that the code we put out is thought of as
> > > production
> > > > > ready.
> > > > >
> > > > > In order to make the framework easier to release, I propose that we
> > use
> > > > > Maven profiles to be able to release subsets of modules, that a
> given
> > > > > contributor can stand behind and say: "yes, those modules are
> working
> > > and
> > > > > are fit for general consumption". Each release would consist of the
> > > > certain
> > > > > core modules, along with selected additional viewers and object
> > stores.
> > > > >
> > > > > For example, over time we might end up releasing:
> > > > >
> > > > > * v0.3.1 core + objectstore-jdo + viewer-wicket +
> > viewer-restfulobjects
> > > > >  // a "wicket/jdo release" - eg tested and released by Dan
> > > > >
> > > > > * v0.4.0 core + objectstore-nosql + viewer-scimpi     // a
> > > "scimpi/nosql
> > > > > release" - eg tested and released by Rob
> > > > >
> > > > > * v0.5.0 core + objectstore-dflt + objectstore-xml + viewer-dnd
> > //
> > > a
> > > > > "dev env release" - eg tested and released by Rob
> > > > >
> > > > > * v0.6.0 core + objectstore-jdo + viewer-wicket +
> > viewer-restfulobjects
> > > > > // another "wicket/jdo release"
> > > > >
> > > > > * v0.7.0 core + objectstore-sql + viewer-html     // a "html/sql
> > > > release" -
> > > > > eg tested and released by Kevin
> > > > >
> > > > > * v0.8.0 core + objectstore-jdo + viewer-wicket +
> > viewer-restfulobjects
> > > > > // another "wicket/jdo release"
> > > > >
> > > > > Whenever a release goes out, we would update our website to
> indicate
> > > the
> > > > > most recent version of the components.
> > > > >
> > > > > Now, when I say "release", what I actually mean here is the
> > deployment
> > > of
> > > > > binary artifacts up to the Maven central repo. This, after all, is
> > what
> > > > > most users/would-be users in the community would use and consider a
> > > > > release. However, Apache's own formal definition of "release" is
> > > actually
> > > > > the source code release ... this is what the [VOTE] mechanism is
> > for. I
> > > > > don't see this changing... the vote basically says that the
> software
> > > > > complies with all the legal license stuff etc. The whole codebase
> is
> > > > tagged
> > > > > with that release number, and the generated src.zip is a zip of
> this
> > > > > release.
> > > > >
> > > > > One benefit of this is that it allows the deployment of other
> modules
> > > to
> > > > be
> > > > > performed "after the fact". For example, suppose that I (Dan) puts
> > out
> > > > the
> > > > > v0.3.1 release as above, and then Rob later on tests the scimpi
> > viewer
> > > in
> > > > > that tag and finds it works well. He can (I think) push the release
> > of
> > > > the
> > > > > scimpi viewer up to Maven central repo.
> > > > >
> > > > > As I see things there are several benefits to this scheme:
> > > > >
> > > > > a) (as already noted) the user community will only see binary
> > releases
> > > > that
> > > > > are known to be of production ready. This should mitigate the "is
> it
> > > safe
> > > > > to use this component" worry
> > > > > b) (as hinted at) it should be possible for individual contributors
> > to
> > > > put
> > > > > out releases of their modules more rapidly
> > > > > c) we get visibility of which modules aren't being released; for
> > > example,
> > > > > we might say that if a module hasn't been released by anyone for 18
> > or
> > > 24
> > > > > months, say, then it's probably time to remove it from the
> codebase.
> > > > >
> > > > > ~~~
> > > > >
> > > > > In order to support the above scheme, I propose that we rearrange
> > some
> > > of
> > > > > the modules so that they can be more easily included within Maven
> > > > > modules.  I've
> > > > > created a page on our wiki [1] which shows my proposed
> rearrangement.
> > >  It
> > > > > also repeats the above discussion text by way of context.
> > > > >
> > > > >
> > > > > Opinions welcome!
> > > > >
> > > > > Thx
> > > > >
> > > > > Dan
> > > > >
> > > > >
> > > > > [1]
> > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > mailto:matthew@matthewadams.me <ma...@matthewadams.me>
> > > > skype:matthewadams12
> > > > googletalk:matthew@matthewadams.me
> > > > http://matthewadams.me
> > > > http://www.linkedin.com/in/matthewadams
> > > >
> > >
> >
>

Re: [DISCUSSION] Making releases easier and more frequent

[Dan Haywood <da...@haywood-associates.co.uk>]

Hi Giovanni,
Thanks for your thoughts on this.  I've commented inline.


On 29 November 2012 16:54, Giovanni Júnior <gi...@gmail.com> wrote:

>
> I don't know much about the development and packaging process of Isis yet,
> and I agree with any improvements that streamline it, but I want to make a
> comment, hoping I haven't read the above too fast.
>
> Assuming that the numbers v0.3.1, v0.4.0 etc correspond to sequential
> releases, users normally expect their content to be similar. Therefore the
> "distributions" approach suggested by Mathew, also used by Eclipse.
>
> Yes, that is a good point.

That said, I suspect that for many would-be users, their entry point will
be to use a quickstart archetype.  Assuming that each of the editions
provides such an archetype, then the drive-by user won't necessarily be
bothered if the versions of those match or not.

If later on a user wants to pull in modules from different editions, then
we can help out on the mailing list.




> But in the case of Isis, I fear that this approach wouldn't work well,
> since there are several interchangeable modules that would cause an
> explosion of distributions (Cartesian product or almost that).
>
> Indeed, I wouldn't expect us to provide every single combination.



> In my view, a better approach is to have only a "basic"
> distribution, containing just the modules that an ordinary user would most
> likely use (eg sql objectstore + wicket viewer + restful). The team should
> commit to maintain those modules stable in all releases.
>
>
I can see the sense in that.... and in practice, I think this is what is
likely to happen.  My expectation is that wicket/restful/JDO will be
released regularly.  If and when the other "editions" want to push out a
release, I'm likely to make sure that the wicket/restful/JDO is also
fit-to-go and can be included.   That edition would therefore be a de-facto
base.

One thing that we could do though (and Rob Matthews and I have discussed
this several times over the years) is to spawn off some separate git repos,
one per main module.  So, the core would advance 0.3.0, 0.4.0, 0.5.0 and
the owner of each module could either choose to release that module or not,
as their time/inclination allows.   That is, probably, the correct thing to
do.  It's what projects such as Maven and Hadoop do.




> Besides that, the website and the documentation would show the status of
> each of the other modules in each release, along with instructions on how
> to use them to replace the basic distribution modules.
>
> If you look at the website now you'll see that on the documentation page
[1] I am now indicating the current release status.

The instructions for replacing are (now) actually pretty easy enough: it's
a matter of commenting in the appropriate line in isis.properties, along
with providing a supplemental configuration file for the module in question
(eg persistor_datanucleus.properties for the JDO/DataNucleus objectstore).




> P. S.: Considering that Isis is becoming a top-level project,


Has become :-)


> as outlined
> above, I think we should plan an effort to gradually pay the technical
> debt that seems to exist in the automated testing area of the project.
>


Ah yes.  We should.  Patches always welcome.

Cheers
Dan

[1] http://isis.apache.org/documentation.html


> Regards,
>
> Giovanni
>
>
> 2012/11/29 Jeroen van der Wal <je...@stromboli.it>
>
> > +1
> >
> > This would make releasing so much easier. But it could also be
> interpreted
> > it as a guilt- free pass to break other editions in order to release your
> > own. And what does the master branch represent in this scenario?
> >
> > Cheers,
> >
> > Jeroen
> >
> >
> > On Thu, Nov 29, 2012 at 4:39 PM, Dan Haywood
> > <da...@haywood-associates.co.uk>wrote:
> >
> > > Hi Matthew,
> > >
> > > That's a good insight/metaphor.  Agreed.
> > >
> > > Your mail prompted me to look a little deeper into how the Apache
> release
> > > process in the master POM [1] creates the src.zip (actually, I note
> it's
> > > called source-release.zip).  And, as you hinted at, it is created by
> the
> > > maven-assembly-plugin, during the release:perform stage.  And in fact
> the
> > > name of the artifact is already parameterized as the
> > > ${sourceReleaseAssemblyDescriptor} parameter.
> > >
> > > So, picking up on your idea, I think we could have profiles that:
> > > (a) list a set of <modules>, and (b) override this parameter.
> > >
> > > To do a release would consist of:
> > >
> > > release:prepare  - tags and edits the poms
> > > release:perform   -P xxx    - builds the source zip for the "edition"
> and
> > > deploys this zip and the binary artifacts to be voted on.
> > >
> > > That seems better to me.  It would mean that a retrospective release of
> > > other editions from the same tag would require a separate run of
> > > release:perform and their own vote, but that's probably for the best.
> > >
> > > Thanks!
> > >
> > > Dan
> > >
> > >
> > > On 29 November 2012 15:09, Matthew Adams <ma...@matthewadams.me>
> > wrote:
> > >
> > > > Wouldn't these certified objectstore/viewer combos be called
> > "assemblies"
> > > > (maven), "distributions" or "distros" (geeks & me) or "editions"
> > > > (marketeze), then?  Like, "Isis: JDO/Wicket Edition" and "Isis:
> > > > NoSQL/Scimpi Edition", etc.
> > > >
> > > > Maven profiles could be used along with maven-assembly-plugin to
> > produce
> > > > the editions, and there would be a one-to-one relationship between
> > Maven
> > > > profile and edition.
> > > >
> > > > -matthew
> > > >
> > > >
> > > > On Thu, Nov 29, 2012 at 8:36 AM, Dan Haywood
> > > > <da...@haywood-associates.co.uk>wrote:
> > > >
> > > > > This discussion post is mostly to the contributors, but cc:ing to
> > user
> > > > list
> > > > > for opinions also...
> > > > >
> > > > > ~~~
> > > > >
> > > > > At the moment it's a daunting task to fully verify all the
> components
> > > of
> > > > > the framework are working correctly prior to pushing out a
> release. I
> > > > > suppose that wouldn't be so much of a concern if we had better
> > > automated
> > > > > tests, but, hey, that's how things are.
> > > > >
> > > > > Moreover, frankly, some of the modules are best considered spikes
> and
> > > > > probably don't constitute something that we would consider
> > > > > production-ready. Or, at least, they haven't been used in a
> > real-world
> > > > > context, so it's not possible to say whether they are really
> > > > > fit-for-purpose. I include here quite a lot of the stuff that I
> have
> > > > worked
> > > > > on over the last few years, eg the wrapper-progmodel, the groovy
> > > > progmodel,
> > > > > probably also the JUnit viewer and BDD viewer. Now that we are a
> > > > top-level
> > > > > project, I'd like it that the code we put out is thought of as
> > > production
> > > > > ready.
> > > > >
> > > > > In order to make the framework easier to release, I propose that we
> > use
> > > > > Maven profiles to be able to release subsets of modules, that a
> given
> > > > > contributor can stand behind and say: "yes, those modules are
> working
> > > and
> > > > > are fit for general consumption". Each release would consist of the
> > > > certain
> > > > > core modules, along with selected additional viewers and object
> > stores.
> > > > >
> > > > > For example, over time we might end up releasing:
> > > > >
> > > > > * v0.3.1 core + objectstore-jdo + viewer-wicket +
> > viewer-restfulobjects
> > > > >  // a "wicket/jdo release" - eg tested and released by Dan
> > > > >
> > > > > * v0.4.0 core + objectstore-nosql + viewer-scimpi     // a
> > > "scimpi/nosql
> > > > > release" - eg tested and released by Rob
> > > > >
> > > > > * v0.5.0 core + objectstore-dflt + objectstore-xml + viewer-dnd
> > //
> > > a
> > > > > "dev env release" - eg tested and released by Rob
> > > > >
> > > > > * v0.6.0 core + objectstore-jdo + viewer-wicket +
> > viewer-restfulobjects
> > > > > // another "wicket/jdo release"
> > > > >
> > > > > * v0.7.0 core + objectstore-sql + viewer-html     // a "html/sql
> > > > release" -
> > > > > eg tested and released by Kevin
> > > > >
> > > > > * v0.8.0 core + objectstore-jdo + viewer-wicket +
> > viewer-restfulobjects
> > > > > // another "wicket/jdo release"
> > > > >
> > > > > Whenever a release goes out, we would update our website to
> indicate
> > > the
> > > > > most recent version of the components.
> > > > >
> > > > > Now, when I say "release", what I actually mean here is the
> > deployment
> > > of
> > > > > binary artifacts up to the Maven central repo. This, after all, is
> > what
> > > > > most users/would-be users in the community would use and consider a
> > > > > release. However, Apache's own formal definition of "release" is
> > > actually
> > > > > the source code release ... this is what the [VOTE] mechanism is
> > for. I
> > > > > don't see this changing... the vote basically says that the
> software
> > > > > complies with all the legal license stuff etc. The whole codebase
> is
> > > > tagged
> > > > > with that release number, and the generated src.zip is a zip of
> this
> > > > > release.
> > > > >
> > > > > One benefit of this is that it allows the deployment of other
> modules
> > > to
> > > > be
> > > > > performed "after the fact". For example, suppose that I (Dan) puts
> > out
> > > > the
> > > > > v0.3.1 release as above, and then Rob later on tests the scimpi
> > viewer
> > > in
> > > > > that tag and finds it works well. He can (I think) push the release
> > of
> > > > the
> > > > > scimpi viewer up to Maven central repo.
> > > > >
> > > > > As I see things there are several benefits to this scheme:
> > > > >
> > > > > a) (as already noted) the user community will only see binary
> > releases
> > > > that
> > > > > are known to be of production ready. This should mitigate the "is
> it
> > > safe
> > > > > to use this component" worry
> > > > > b) (as hinted at) it should be possible for individual contributors
> > to
> > > > put
> > > > > out releases of their modules more rapidly
> > > > > c) we get visibility of which modules aren't being released; for
> > > example,
> > > > > we might say that if a module hasn't been released by anyone for 18
> > or
> > > 24
> > > > > months, say, then it's probably time to remove it from the
> codebase.
> > > > >
> > > > > ~~~
> > > > >
> > > > > In order to support the above scheme, I propose that we rearrange
> > some
> > > of
> > > > > the modules so that they can be more easily included within Maven
> > > > > modules.  I've
> > > > > created a page on our wiki [1] which shows my proposed
> rearrangement.
> > >  It
> > > > > also repeats the above discussion text by way of context.
> > > > >
> > > > >
> > > > > Opinions welcome!
> > > > >
> > > > > Thx
> > > > >
> > > > > Dan
> > > > >
> > > > >
> > > > > [1]
> > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > mailto:matthew@matthewadams.me <ma...@matthewadams.me>
> > > > skype:matthewadams12
> > > > googletalk:matthew@matthewadams.me
> > > > http://matthewadams.me
> > > > http://www.linkedin.com/in/matthewadams
> > > >
> > >
> >
>

Re: [DISCUSSION] Making releases easier and more frequent

[Giovanni Júnior <gi...@gmail.com>]

Hi everyone,

Please excuse my Google Translate english...

I don't know much about the development and packaging process of Isis yet,
and I agree with any improvements that streamline it, but I want to make a
comment, hoping I haven't read the above too fast.

Assuming that the numbers v0.3.1, v0.4.0 etc correspond to sequential
releases, users normally expect their content to be similar. Therefore the
"distributions" approach suggested by Mathew, also used by Eclipse.

But in the case of Isis, I fear that this approach wouldn't work well,
since there are several interchangeable modules that would cause an
explosion of distributions (Cartesian product or almost that).

In my view, a better approach is to have only a "basic"
distribution, containing just the modules that an ordinary user would most
likely use (eg sql objectstore + wicket viewer + restful). The team should
commit to maintain those modules stable in all releases.

Besides that, the website and the documentation would show the status of
each of the other modules in each release, along with instructions on how
to use them to replace the basic distribution modules.

P. S.: Considering that Isis is becoming a top-level project, as outlined
above, I think we should plan an effort to gradually pay the technical
debt that seems to exist in the automated testing area of the project.

Regards,

Giovanni


2012/11/29 Jeroen van der Wal <je...@stromboli.it>

> +1
>
> This would make releasing so much easier. But it could also be interpreted
> it as a guilt- free pass to break other editions in order to release your
> own. And what does the master branch represent in this scenario?
>
> Cheers,
>
> Jeroen
>
>
> On Thu, Nov 29, 2012 at 4:39 PM, Dan Haywood
> <da...@haywood-associates.co.uk>wrote:
>
> > Hi Matthew,
> >
> > That's a good insight/metaphor.  Agreed.
> >
> > Your mail prompted me to look a little deeper into how the Apache release
> > process in the master POM [1] creates the src.zip (actually, I note it's
> > called source-release.zip).  And, as you hinted at, it is created by the
> > maven-assembly-plugin, during the release:perform stage.  And in fact the
> > name of the artifact is already parameterized as the
> > ${sourceReleaseAssemblyDescriptor} parameter.
> >
> > So, picking up on your idea, I think we could have profiles that:
> > (a) list a set of <modules>, and (b) override this parameter.
> >
> > To do a release would consist of:
> >
> > release:prepare  - tags and edits the poms
> > release:perform   -P xxx    - builds the source zip for the "edition" and
> > deploys this zip and the binary artifacts to be voted on.
> >
> > That seems better to me.  It would mean that a retrospective release of
> > other editions from the same tag would require a separate run of
> > release:perform and their own vote, but that's probably for the best.
> >
> > Thanks!
> >
> > Dan
> >
> >
> > On 29 November 2012 15:09, Matthew Adams <ma...@matthewadams.me>
> wrote:
> >
> > > Wouldn't these certified objectstore/viewer combos be called
> "assemblies"
> > > (maven), "distributions" or "distros" (geeks & me) or "editions"
> > > (marketeze), then?  Like, "Isis: JDO/Wicket Edition" and "Isis:
> > > NoSQL/Scimpi Edition", etc.
> > >
> > > Maven profiles could be used along with maven-assembly-plugin to
> produce
> > > the editions, and there would be a one-to-one relationship between
> Maven
> > > profile and edition.
> > >
> > > -matthew
> > >
> > >
> > > On Thu, Nov 29, 2012 at 8:36 AM, Dan Haywood
> > > <da...@haywood-associates.co.uk>wrote:
> > >
> > > > This discussion post is mostly to the contributors, but cc:ing to
> user
> > > list
> > > > for opinions also...
> > > >
> > > > ~~~
> > > >
> > > > At the moment it's a daunting task to fully verify all the components
> > of
> > > > the framework are working correctly prior to pushing out a release. I
> > > > suppose that wouldn't be so much of a concern if we had better
> > automated
> > > > tests, but, hey, that's how things are.
> > > >
> > > > Moreover, frankly, some of the modules are best considered spikes and
> > > > probably don't constitute something that we would consider
> > > > production-ready. Or, at least, they haven't been used in a
> real-world
> > > > context, so it's not possible to say whether they are really
> > > > fit-for-purpose. I include here quite a lot of the stuff that I have
> > > worked
> > > > on over the last few years, eg the wrapper-progmodel, the groovy
> > > progmodel,
> > > > probably also the JUnit viewer and BDD viewer. Now that we are a
> > > top-level
> > > > project, I'd like it that the code we put out is thought of as
> > production
> > > > ready.
> > > >
> > > > In order to make the framework easier to release, I propose that we
> use
> > > > Maven profiles to be able to release subsets of modules, that a given
> > > > contributor can stand behind and say: "yes, those modules are working
> > and
> > > > are fit for general consumption". Each release would consist of the
> > > certain
> > > > core modules, along with selected additional viewers and object
> stores.
> > > >
> > > > For example, over time we might end up releasing:
> > > >
> > > > * v0.3.1 core + objectstore-jdo + viewer-wicket +
> viewer-restfulobjects
> > > >  // a "wicket/jdo release" - eg tested and released by Dan
> > > >
> > > > * v0.4.0 core + objectstore-nosql + viewer-scimpi     // a
> > "scimpi/nosql
> > > > release" - eg tested and released by Rob
> > > >
> > > > * v0.5.0 core + objectstore-dflt + objectstore-xml + viewer-dnd
> //
> > a
> > > > "dev env release" - eg tested and released by Rob
> > > >
> > > > * v0.6.0 core + objectstore-jdo + viewer-wicket +
> viewer-restfulobjects
> > > > // another "wicket/jdo release"
> > > >
> > > > * v0.7.0 core + objectstore-sql + viewer-html     // a "html/sql
> > > release" -
> > > > eg tested and released by Kevin
> > > >
> > > > * v0.8.0 core + objectstore-jdo + viewer-wicket +
> viewer-restfulobjects
> > > > // another "wicket/jdo release"
> > > >
> > > > Whenever a release goes out, we would update our website to indicate
> > the
> > > > most recent version of the components.
> > > >
> > > > Now, when I say "release", what I actually mean here is the
> deployment
> > of
> > > > binary artifacts up to the Maven central repo. This, after all, is
> what
> > > > most users/would-be users in the community would use and consider a
> > > > release. However, Apache's own formal definition of "release" is
> > actually
> > > > the source code release ... this is what the [VOTE] mechanism is
> for. I
> > > > don't see this changing... the vote basically says that the software
> > > > complies with all the legal license stuff etc. The whole codebase is
> > > tagged
> > > > with that release number, and the generated src.zip is a zip of this
> > > > release.
> > > >
> > > > One benefit of this is that it allows the deployment of other modules
> > to
> > > be
> > > > performed "after the fact". For example, suppose that I (Dan) puts
> out
> > > the
> > > > v0.3.1 release as above, and then Rob later on tests the scimpi
> viewer
> > in
> > > > that tag and finds it works well. He can (I think) push the release
> of
> > > the
> > > > scimpi viewer up to Maven central repo.
> > > >
> > > > As I see things there are several benefits to this scheme:
> > > >
> > > > a) (as already noted) the user community will only see binary
> releases
> > > that
> > > > are known to be of production ready. This should mitigate the "is it
> > safe
> > > > to use this component" worry
> > > > b) (as hinted at) it should be possible for individual contributors
> to
> > > put
> > > > out releases of their modules more rapidly
> > > > c) we get visibility of which modules aren't being released; for
> > example,
> > > > we might say that if a module hasn't been released by anyone for 18
> or
> > 24
> > > > months, say, then it's probably time to remove it from the codebase.
> > > >
> > > > ~~~
> > > >
> > > > In order to support the above scheme, I propose that we rearrange
> some
> > of
> > > > the modules so that they can be more easily included within Maven
> > > > modules.  I've
> > > > created a page on our wiki [1] which shows my proposed rearrangement.
> >  It
> > > > also repeats the above discussion text by way of context.
> > > >
> > > >
> > > > Opinions welcome!
> > > >
> > > > Thx
> > > >
> > > > Dan
> > > >
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
> > > >
> > >
> > >
> > >
> > > --
> > > mailto:matthew@matthewadams.me <ma...@matthewadams.me>
> > > skype:matthewadams12
> > > googletalk:matthew@matthewadams.me
> > > http://matthewadams.me
> > > http://www.linkedin.com/in/matthewadams
> > >
> >
>

Re: [DISCUSSION] Making releases easier and more frequent

[Giovanni Júnior <gi...@gmail.com>]

Hi everyone,

Please excuse my Google Translate english...

I don't know much about the development and packaging process of Isis yet,
and I agree with any improvements that streamline it, but I want to make a
comment, hoping I haven't read the above too fast.

Assuming that the numbers v0.3.1, v0.4.0 etc correspond to sequential
releases, users normally expect their content to be similar. Therefore the
"distributions" approach suggested by Mathew, also used by Eclipse.

But in the case of Isis, I fear that this approach wouldn't work well,
since there are several interchangeable modules that would cause an
explosion of distributions (Cartesian product or almost that).

In my view, a better approach is to have only a "basic"
distribution, containing just the modules that an ordinary user would most
likely use (eg sql objectstore + wicket viewer + restful). The team should
commit to maintain those modules stable in all releases.

Besides that, the website and the documentation would show the status of
each of the other modules in each release, along with instructions on how
to use them to replace the basic distribution modules.

P. S.: Considering that Isis is becoming a top-level project, as outlined
above, I think we should plan an effort to gradually pay the technical
debt that seems to exist in the automated testing area of the project.

Regards,

Giovanni


2012/11/29 Jeroen van der Wal <je...@stromboli.it>

> +1
>
> This would make releasing so much easier. But it could also be interpreted
> it as a guilt- free pass to break other editions in order to release your
> own. And what does the master branch represent in this scenario?
>
> Cheers,
>
> Jeroen
>
>
> On Thu, Nov 29, 2012 at 4:39 PM, Dan Haywood
> <da...@haywood-associates.co.uk>wrote:
>
> > Hi Matthew,
> >
> > That's a good insight/metaphor.  Agreed.
> >
> > Your mail prompted me to look a little deeper into how the Apache release
> > process in the master POM [1] creates the src.zip (actually, I note it's
> > called source-release.zip).  And, as you hinted at, it is created by the
> > maven-assembly-plugin, during the release:perform stage.  And in fact the
> > name of the artifact is already parameterized as the
> > ${sourceReleaseAssemblyDescriptor} parameter.
> >
> > So, picking up on your idea, I think we could have profiles that:
> > (a) list a set of <modules>, and (b) override this parameter.
> >
> > To do a release would consist of:
> >
> > release:prepare  - tags and edits the poms
> > release:perform   -P xxx    - builds the source zip for the "edition" and
> > deploys this zip and the binary artifacts to be voted on.
> >
> > That seems better to me.  It would mean that a retrospective release of
> > other editions from the same tag would require a separate run of
> > release:perform and their own vote, but that's probably for the best.
> >
> > Thanks!
> >
> > Dan
> >
> >
> > On 29 November 2012 15:09, Matthew Adams <ma...@matthewadams.me>
> wrote:
> >
> > > Wouldn't these certified objectstore/viewer combos be called
> "assemblies"
> > > (maven), "distributions" or "distros" (geeks & me) or "editions"
> > > (marketeze), then?  Like, "Isis: JDO/Wicket Edition" and "Isis:
> > > NoSQL/Scimpi Edition", etc.
> > >
> > > Maven profiles could be used along with maven-assembly-plugin to
> produce
> > > the editions, and there would be a one-to-one relationship between
> Maven
> > > profile and edition.
> > >
> > > -matthew
> > >
> > >
> > > On Thu, Nov 29, 2012 at 8:36 AM, Dan Haywood
> > > <da...@haywood-associates.co.uk>wrote:
> > >
> > > > This discussion post is mostly to the contributors, but cc:ing to
> user
> > > list
> > > > for opinions also...
> > > >
> > > > ~~~
> > > >
> > > > At the moment it's a daunting task to fully verify all the components
> > of
> > > > the framework are working correctly prior to pushing out a release. I
> > > > suppose that wouldn't be so much of a concern if we had better
> > automated
> > > > tests, but, hey, that's how things are.
> > > >
> > > > Moreover, frankly, some of the modules are best considered spikes and
> > > > probably don't constitute something that we would consider
> > > > production-ready. Or, at least, they haven't been used in a
> real-world
> > > > context, so it's not possible to say whether they are really
> > > > fit-for-purpose. I include here quite a lot of the stuff that I have
> > > worked
> > > > on over the last few years, eg the wrapper-progmodel, the groovy
> > > progmodel,
> > > > probably also the JUnit viewer and BDD viewer. Now that we are a
> > > top-level
> > > > project, I'd like it that the code we put out is thought of as
> > production
> > > > ready.
> > > >
> > > > In order to make the framework easier to release, I propose that we
> use
> > > > Maven profiles to be able to release subsets of modules, that a given
> > > > contributor can stand behind and say: "yes, those modules are working
> > and
> > > > are fit for general consumption". Each release would consist of the
> > > certain
> > > > core modules, along with selected additional viewers and object
> stores.
> > > >
> > > > For example, over time we might end up releasing:
> > > >
> > > > * v0.3.1 core + objectstore-jdo + viewer-wicket +
> viewer-restfulobjects
> > > >  // a "wicket/jdo release" - eg tested and released by Dan
> > > >
> > > > * v0.4.0 core + objectstore-nosql + viewer-scimpi     // a
> > "scimpi/nosql
> > > > release" - eg tested and released by Rob
> > > >
> > > > * v0.5.0 core + objectstore-dflt + objectstore-xml + viewer-dnd
> //
> > a
> > > > "dev env release" - eg tested and released by Rob
> > > >
> > > > * v0.6.0 core + objectstore-jdo + viewer-wicket +
> viewer-restfulobjects
> > > > // another "wicket/jdo release"
> > > >
> > > > * v0.7.0 core + objectstore-sql + viewer-html     // a "html/sql
> > > release" -
> > > > eg tested and released by Kevin
> > > >
> > > > * v0.8.0 core + objectstore-jdo + viewer-wicket +
> viewer-restfulobjects
> > > > // another "wicket/jdo release"
> > > >
> > > > Whenever a release goes out, we would update our website to indicate
> > the
> > > > most recent version of the components.
> > > >
> > > > Now, when I say "release", what I actually mean here is the
> deployment
> > of
> > > > binary artifacts up to the Maven central repo. This, after all, is
> what
> > > > most users/would-be users in the community would use and consider a
> > > > release. However, Apache's own formal definition of "release" is
> > actually
> > > > the source code release ... this is what the [VOTE] mechanism is
> for. I
> > > > don't see this changing... the vote basically says that the software
> > > > complies with all the legal license stuff etc. The whole codebase is
> > > tagged
> > > > with that release number, and the generated src.zip is a zip of this
> > > > release.
> > > >
> > > > One benefit of this is that it allows the deployment of other modules
> > to
> > > be
> > > > performed "after the fact". For example, suppose that I (Dan) puts
> out
> > > the
> > > > v0.3.1 release as above, and then Rob later on tests the scimpi
> viewer
> > in
> > > > that tag and finds it works well. He can (I think) push the release
> of
> > > the
> > > > scimpi viewer up to Maven central repo.
> > > >
> > > > As I see things there are several benefits to this scheme:
> > > >
> > > > a) (as already noted) the user community will only see binary
> releases
> > > that
> > > > are known to be of production ready. This should mitigate the "is it
> > safe
> > > > to use this component" worry
> > > > b) (as hinted at) it should be possible for individual contributors
> to
> > > put
> > > > out releases of their modules more rapidly
> > > > c) we get visibility of which modules aren't being released; for
> > example,
> > > > we might say that if a module hasn't been released by anyone for 18
> or
> > 24
> > > > months, say, then it's probably time to remove it from the codebase.
> > > >
> > > > ~~~
> > > >
> > > > In order to support the above scheme, I propose that we rearrange
> some
> > of
> > > > the modules so that they can be more easily included within Maven
> > > > modules.  I've
> > > > created a page on our wiki [1] which shows my proposed rearrangement.
> >  It
> > > > also repeats the above discussion text by way of context.
> > > >
> > > >
> > > > Opinions welcome!
> > > >
> > > > Thx
> > > >
> > > > Dan
> > > >
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
> > > >
> > >
> > >
> > >
> > > --
> > > mailto:matthew@matthewadams.me <ma...@matthewadams.me>
> > > skype:matthewadams12
> > > googletalk:matthew@matthewadams.me
> > > http://matthewadams.me
> > > http://www.linkedin.com/in/matthewadams
> > >
> >
>

Re: [DISCUSSION] Making releases easier and more frequent

[Jeroen van der Wal <je...@stromboli.it>]

+1

This would make releasing so much easier. But it could also be interpreted
it as a guilt- free pass to break other editions in order to release your
own. And what does the master branch represent in this scenario?

Cheers,

Jeroen


On Thu, Nov 29, 2012 at 4:39 PM, Dan Haywood
<da...@haywood-associates.co.uk>wrote:

> Hi Matthew,
>
> That's a good insight/metaphor.  Agreed.
>
> Your mail prompted me to look a little deeper into how the Apache release
> process in the master POM [1] creates the src.zip (actually, I note it's
> called source-release.zip).  And, as you hinted at, it is created by the
> maven-assembly-plugin, during the release:perform stage.  And in fact the
> name of the artifact is already parameterized as the
> ${sourceReleaseAssemblyDescriptor} parameter.
>
> So, picking up on your idea, I think we could have profiles that:
> (a) list a set of <modules>, and (b) override this parameter.
>
> To do a release would consist of:
>
> release:prepare  - tags and edits the poms
> release:perform   -P xxx    - builds the source zip for the "edition" and
> deploys this zip and the binary artifacts to be voted on.
>
> That seems better to me.  It would mean that a retrospective release of
> other editions from the same tag would require a separate run of
> release:perform and their own vote, but that's probably for the best.
>
> Thanks!
>
> Dan
>
>
> On 29 November 2012 15:09, Matthew Adams <ma...@matthewadams.me> wrote:
>
> > Wouldn't these certified objectstore/viewer combos be called "assemblies"
> > (maven), "distributions" or "distros" (geeks & me) or "editions"
> > (marketeze), then?  Like, "Isis: JDO/Wicket Edition" and "Isis:
> > NoSQL/Scimpi Edition", etc.
> >
> > Maven profiles could be used along with maven-assembly-plugin to produce
> > the editions, and there would be a one-to-one relationship between Maven
> > profile and edition.
> >
> > -matthew
> >
> >
> > On Thu, Nov 29, 2012 at 8:36 AM, Dan Haywood
> > <da...@haywood-associates.co.uk>wrote:
> >
> > > This discussion post is mostly to the contributors, but cc:ing to user
> > list
> > > for opinions also...
> > >
> > > ~~~
> > >
> > > At the moment it's a daunting task to fully verify all the components
> of
> > > the framework are working correctly prior to pushing out a release. I
> > > suppose that wouldn't be so much of a concern if we had better
> automated
> > > tests, but, hey, that's how things are.
> > >
> > > Moreover, frankly, some of the modules are best considered spikes and
> > > probably don't constitute something that we would consider
> > > production-ready. Or, at least, they haven't been used in a real-world
> > > context, so it's not possible to say whether they are really
> > > fit-for-purpose. I include here quite a lot of the stuff that I have
> > worked
> > > on over the last few years, eg the wrapper-progmodel, the groovy
> > progmodel,
> > > probably also the JUnit viewer and BDD viewer. Now that we are a
> > top-level
> > > project, I'd like it that the code we put out is thought of as
> production
> > > ready.
> > >
> > > In order to make the framework easier to release, I propose that we use
> > > Maven profiles to be able to release subsets of modules, that a given
> > > contributor can stand behind and say: "yes, those modules are working
> and
> > > are fit for general consumption". Each release would consist of the
> > certain
> > > core modules, along with selected additional viewers and object stores.
> > >
> > > For example, over time we might end up releasing:
> > >
> > > * v0.3.1 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
> > >  // a "wicket/jdo release" - eg tested and released by Dan
> > >
> > > * v0.4.0 core + objectstore-nosql + viewer-scimpi     // a
> "scimpi/nosql
> > > release" - eg tested and released by Rob
> > >
> > > * v0.5.0 core + objectstore-dflt + objectstore-xml + viewer-dnd     //
> a
> > > "dev env release" - eg tested and released by Rob
> > >
> > > * v0.6.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
> > > // another "wicket/jdo release"
> > >
> > > * v0.7.0 core + objectstore-sql + viewer-html     // a "html/sql
> > release" -
> > > eg tested and released by Kevin
> > >
> > > * v0.8.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
> > > // another "wicket/jdo release"
> > >
> > > Whenever a release goes out, we would update our website to indicate
> the
> > > most recent version of the components.
> > >
> > > Now, when I say "release", what I actually mean here is the deployment
> of
> > > binary artifacts up to the Maven central repo. This, after all, is what
> > > most users/would-be users in the community would use and consider a
> > > release. However, Apache's own formal definition of "release" is
> actually
> > > the source code release ... this is what the [VOTE] mechanism is for. I
> > > don't see this changing... the vote basically says that the software
> > > complies with all the legal license stuff etc. The whole codebase is
> > tagged
> > > with that release number, and the generated src.zip is a zip of this
> > > release.
> > >
> > > One benefit of this is that it allows the deployment of other modules
> to
> > be
> > > performed "after the fact". For example, suppose that I (Dan) puts out
> > the
> > > v0.3.1 release as above, and then Rob later on tests the scimpi viewer
> in
> > > that tag and finds it works well. He can (I think) push the release of
> > the
> > > scimpi viewer up to Maven central repo.
> > >
> > > As I see things there are several benefits to this scheme:
> > >
> > > a) (as already noted) the user community will only see binary releases
> > that
> > > are known to be of production ready. This should mitigate the "is it
> safe
> > > to use this component" worry
> > > b) (as hinted at) it should be possible for individual contributors to
> > put
> > > out releases of their modules more rapidly
> > > c) we get visibility of which modules aren't being released; for
> example,
> > > we might say that if a module hasn't been released by anyone for 18 or
> 24
> > > months, say, then it's probably time to remove it from the codebase.
> > >
> > > ~~~
> > >
> > > In order to support the above scheme, I propose that we rearrange some
> of
> > > the modules so that they can be more easily included within Maven
> > > modules.  I've
> > > created a page on our wiki [1] which shows my proposed rearrangement.
>  It
> > > also repeats the above discussion text by way of context.
> > >
> > >
> > > Opinions welcome!
> > >
> > > Thx
> > >
> > > Dan
> > >
> > >
> > > [1]
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
> > >
> >
> >
> >
> > --
> > mailto:matthew@matthewadams.me <ma...@matthewadams.me>
> > skype:matthewadams12
> > googletalk:matthew@matthewadams.me
> > http://matthewadams.me
> > http://www.linkedin.com/in/matthewadams
> >
>

Re: [DISCUSSION] Making releases easier and more frequent

[Jeroen van der Wal <je...@stromboli.it>]

+1

This would make releasing so much easier. But it could also be interpreted
it as a guilt- free pass to break other editions in order to release your
own. And what does the master branch represent in this scenario?

Cheers,

Jeroen


On Thu, Nov 29, 2012 at 4:39 PM, Dan Haywood
<da...@haywood-associates.co.uk>wrote:

> Hi Matthew,
>
> That's a good insight/metaphor.  Agreed.
>
> Your mail prompted me to look a little deeper into how the Apache release
> process in the master POM [1] creates the src.zip (actually, I note it's
> called source-release.zip).  And, as you hinted at, it is created by the
> maven-assembly-plugin, during the release:perform stage.  And in fact the
> name of the artifact is already parameterized as the
> ${sourceReleaseAssemblyDescriptor} parameter.
>
> So, picking up on your idea, I think we could have profiles that:
> (a) list a set of <modules>, and (b) override this parameter.
>
> To do a release would consist of:
>
> release:prepare  - tags and edits the poms
> release:perform   -P xxx    - builds the source zip for the "edition" and
> deploys this zip and the binary artifacts to be voted on.
>
> That seems better to me.  It would mean that a retrospective release of
> other editions from the same tag would require a separate run of
> release:perform and their own vote, but that's probably for the best.
>
> Thanks!
>
> Dan
>
>
> On 29 November 2012 15:09, Matthew Adams <ma...@matthewadams.me> wrote:
>
> > Wouldn't these certified objectstore/viewer combos be called "assemblies"
> > (maven), "distributions" or "distros" (geeks & me) or "editions"
> > (marketeze), then?  Like, "Isis: JDO/Wicket Edition" and "Isis:
> > NoSQL/Scimpi Edition", etc.
> >
> > Maven profiles could be used along with maven-assembly-plugin to produce
> > the editions, and there would be a one-to-one relationship between Maven
> > profile and edition.
> >
> > -matthew
> >
> >
> > On Thu, Nov 29, 2012 at 8:36 AM, Dan Haywood
> > <da...@haywood-associates.co.uk>wrote:
> >
> > > This discussion post is mostly to the contributors, but cc:ing to user
> > list
> > > for opinions also...
> > >
> > > ~~~
> > >
> > > At the moment it's a daunting task to fully verify all the components
> of
> > > the framework are working correctly prior to pushing out a release. I
> > > suppose that wouldn't be so much of a concern if we had better
> automated
> > > tests, but, hey, that's how things are.
> > >
> > > Moreover, frankly, some of the modules are best considered spikes and
> > > probably don't constitute something that we would consider
> > > production-ready. Or, at least, they haven't been used in a real-world
> > > context, so it's not possible to say whether they are really
> > > fit-for-purpose. I include here quite a lot of the stuff that I have
> > worked
> > > on over the last few years, eg the wrapper-progmodel, the groovy
> > progmodel,
> > > probably also the JUnit viewer and BDD viewer. Now that we are a
> > top-level
> > > project, I'd like it that the code we put out is thought of as
> production
> > > ready.
> > >
> > > In order to make the framework easier to release, I propose that we use
> > > Maven profiles to be able to release subsets of modules, that a given
> > > contributor can stand behind and say: "yes, those modules are working
> and
> > > are fit for general consumption". Each release would consist of the
> > certain
> > > core modules, along with selected additional viewers and object stores.
> > >
> > > For example, over time we might end up releasing:
> > >
> > > * v0.3.1 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
> > >  // a "wicket/jdo release" - eg tested and released by Dan
> > >
> > > * v0.4.0 core + objectstore-nosql + viewer-scimpi     // a
> "scimpi/nosql
> > > release" - eg tested and released by Rob
> > >
> > > * v0.5.0 core + objectstore-dflt + objectstore-xml + viewer-dnd     //
> a
> > > "dev env release" - eg tested and released by Rob
> > >
> > > * v0.6.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
> > > // another "wicket/jdo release"
> > >
> > > * v0.7.0 core + objectstore-sql + viewer-html     // a "html/sql
> > release" -
> > > eg tested and released by Kevin
> > >
> > > * v0.8.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
> > > // another "wicket/jdo release"
> > >
> > > Whenever a release goes out, we would update our website to indicate
> the
> > > most recent version of the components.
> > >
> > > Now, when I say "release", what I actually mean here is the deployment
> of
> > > binary artifacts up to the Maven central repo. This, after all, is what
> > > most users/would-be users in the community would use and consider a
> > > release. However, Apache's own formal definition of "release" is
> actually
> > > the source code release ... this is what the [VOTE] mechanism is for. I
> > > don't see this changing... the vote basically says that the software
> > > complies with all the legal license stuff etc. The whole codebase is
> > tagged
> > > with that release number, and the generated src.zip is a zip of this
> > > release.
> > >
> > > One benefit of this is that it allows the deployment of other modules
> to
> > be
> > > performed "after the fact". For example, suppose that I (Dan) puts out
> > the
> > > v0.3.1 release as above, and then Rob later on tests the scimpi viewer
> in
> > > that tag and finds it works well. He can (I think) push the release of
> > the
> > > scimpi viewer up to Maven central repo.
> > >
> > > As I see things there are several benefits to this scheme:
> > >
> > > a) (as already noted) the user community will only see binary releases
> > that
> > > are known to be of production ready. This should mitigate the "is it
> safe
> > > to use this component" worry
> > > b) (as hinted at) it should be possible for individual contributors to
> > put
> > > out releases of their modules more rapidly
> > > c) we get visibility of which modules aren't being released; for
> example,
> > > we might say that if a module hasn't been released by anyone for 18 or
> 24
> > > months, say, then it's probably time to remove it from the codebase.
> > >
> > > ~~~
> > >
> > > In order to support the above scheme, I propose that we rearrange some
> of
> > > the modules so that they can be more easily included within Maven
> > > modules.  I've
> > > created a page on our wiki [1] which shows my proposed rearrangement.
>  It
> > > also repeats the above discussion text by way of context.
> > >
> > >
> > > Opinions welcome!
> > >
> > > Thx
> > >
> > > Dan
> > >
> > >
> > > [1]
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
> > >
> >
> >
> >
> > --
> > mailto:matthew@matthewadams.me <ma...@matthewadams.me>
> > skype:matthewadams12
> > googletalk:matthew@matthewadams.me
> > http://matthewadams.me
> > http://www.linkedin.com/in/matthewadams
> >
>

Re: [DISCUSSION] Making releases easier and more frequent

[Dan Haywood <da...@haywood-associates.co.uk>]

Hi Matthew,

That's a good insight/metaphor.  Agreed.

Your mail prompted me to look a little deeper into how the Apache release
process in the master POM [1] creates the src.zip (actually, I note it's
called source-release.zip).  And, as you hinted at, it is created by the
maven-assembly-plugin, during the release:perform stage.  And in fact the
name of the artifact is already parameterized as the
${sourceReleaseAssemblyDescriptor} parameter.

So, picking up on your idea, I think we could have profiles that:
(a) list a set of <modules>, and (b) override this parameter.

To do a release would consist of:

release:prepare  - tags and edits the poms
release:perform   -P xxx    - builds the source zip for the "edition" and
deploys this zip and the binary artifacts to be voted on.

That seems better to me.  It would mean that a retrospective release of
other editions from the same tag would require a separate run of
release:perform and their own vote, but that's probably for the best.

Thanks!

Dan


On 29 November 2012 15:09, Matthew Adams <ma...@matthewadams.me> wrote:

> Wouldn't these certified objectstore/viewer combos be called "assemblies"
> (maven), "distributions" or "distros" (geeks & me) or "editions"
> (marketeze), then?  Like, "Isis: JDO/Wicket Edition" and "Isis:
> NoSQL/Scimpi Edition", etc.
>
> Maven profiles could be used along with maven-assembly-plugin to produce
> the editions, and there would be a one-to-one relationship between Maven
> profile and edition.
>
> -matthew
>
>
> On Thu, Nov 29, 2012 at 8:36 AM, Dan Haywood
> <da...@haywood-associates.co.uk>wrote:
>
> > This discussion post is mostly to the contributors, but cc:ing to user
> list
> > for opinions also...
> >
> > ~~~
> >
> > At the moment it's a daunting task to fully verify all the components of
> > the framework are working correctly prior to pushing out a release. I
> > suppose that wouldn't be so much of a concern if we had better automated
> > tests, but, hey, that's how things are.
> >
> > Moreover, frankly, some of the modules are best considered spikes and
> > probably don't constitute something that we would consider
> > production-ready. Or, at least, they haven't been used in a real-world
> > context, so it's not possible to say whether they are really
> > fit-for-purpose. I include here quite a lot of the stuff that I have
> worked
> > on over the last few years, eg the wrapper-progmodel, the groovy
> progmodel,
> > probably also the JUnit viewer and BDD viewer. Now that we are a
> top-level
> > project, I'd like it that the code we put out is thought of as production
> > ready.
> >
> > In order to make the framework easier to release, I propose that we use
> > Maven profiles to be able to release subsets of modules, that a given
> > contributor can stand behind and say: "yes, those modules are working and
> > are fit for general consumption". Each release would consist of the
> certain
> > core modules, along with selected additional viewers and object stores.
> >
> > For example, over time we might end up releasing:
> >
> > * v0.3.1 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
> >  // a "wicket/jdo release" - eg tested and released by Dan
> >
> > * v0.4.0 core + objectstore-nosql + viewer-scimpi     // a "scimpi/nosql
> > release" - eg tested and released by Rob
> >
> > * v0.5.0 core + objectstore-dflt + objectstore-xml + viewer-dnd     // a
> > "dev env release" - eg tested and released by Rob
> >
> > * v0.6.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
> > // another "wicket/jdo release"
> >
> > * v0.7.0 core + objectstore-sql + viewer-html     // a "html/sql
> release" -
> > eg tested and released by Kevin
> >
> > * v0.8.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
> > // another "wicket/jdo release"
> >
> > Whenever a release goes out, we would update our website to indicate the
> > most recent version of the components.
> >
> > Now, when I say "release", what I actually mean here is the deployment of
> > binary artifacts up to the Maven central repo. This, after all, is what
> > most users/would-be users in the community would use and consider a
> > release. However, Apache's own formal definition of "release" is actually
> > the source code release ... this is what the [VOTE] mechanism is for. I
> > don't see this changing... the vote basically says that the software
> > complies with all the legal license stuff etc. The whole codebase is
> tagged
> > with that release number, and the generated src.zip is a zip of this
> > release.
> >
> > One benefit of this is that it allows the deployment of other modules to
> be
> > performed "after the fact". For example, suppose that I (Dan) puts out
> the
> > v0.3.1 release as above, and then Rob later on tests the scimpi viewer in
> > that tag and finds it works well. He can (I think) push the release of
> the
> > scimpi viewer up to Maven central repo.
> >
> > As I see things there are several benefits to this scheme:
> >
> > a) (as already noted) the user community will only see binary releases
> that
> > are known to be of production ready. This should mitigate the "is it safe
> > to use this component" worry
> > b) (as hinted at) it should be possible for individual contributors to
> put
> > out releases of their modules more rapidly
> > c) we get visibility of which modules aren't being released; for example,
> > we might say that if a module hasn't been released by anyone for 18 or 24
> > months, say, then it's probably time to remove it from the codebase.
> >
> > ~~~
> >
> > In order to support the above scheme, I propose that we rearrange some of
> > the modules so that they can be more easily included within Maven
> > modules.  I've
> > created a page on our wiki [1] which shows my proposed rearrangement.  It
> > also repeats the above discussion text by way of context.
> >
> >
> > Opinions welcome!
> >
> > Thx
> >
> > Dan
> >
> >
> > [1]
> >
> >
> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
> >
>
>
>
> --
> mailto:matthew@matthewadams.me <ma...@matthewadams.me>
> skype:matthewadams12
> googletalk:matthew@matthewadams.me
> http://matthewadams.me
> http://www.linkedin.com/in/matthewadams
>

Re: [DISCUSSION] Making releases easier and more frequent

[Dan Haywood <da...@haywood-associates.co.uk>]

Hi Matthew,

That's a good insight/metaphor.  Agreed.

Your mail prompted me to look a little deeper into how the Apache release
process in the master POM [1] creates the src.zip (actually, I note it's
called source-release.zip).  And, as you hinted at, it is created by the
maven-assembly-plugin, during the release:perform stage.  And in fact the
name of the artifact is already parameterized as the
${sourceReleaseAssemblyDescriptor} parameter.

So, picking up on your idea, I think we could have profiles that:
(a) list a set of <modules>, and (b) override this parameter.

To do a release would consist of:

release:prepare  - tags and edits the poms
release:perform   -P xxx    - builds the source zip for the "edition" and
deploys this zip and the binary artifacts to be voted on.

That seems better to me.  It would mean that a retrospective release of
other editions from the same tag would require a separate run of
release:perform and their own vote, but that's probably for the best.

Thanks!

Dan


On 29 November 2012 15:09, Matthew Adams <ma...@matthewadams.me> wrote:

> Wouldn't these certified objectstore/viewer combos be called "assemblies"
> (maven), "distributions" or "distros" (geeks & me) or "editions"
> (marketeze), then?  Like, "Isis: JDO/Wicket Edition" and "Isis:
> NoSQL/Scimpi Edition", etc.
>
> Maven profiles could be used along with maven-assembly-plugin to produce
> the editions, and there would be a one-to-one relationship between Maven
> profile and edition.
>
> -matthew
>
>
> On Thu, Nov 29, 2012 at 8:36 AM, Dan Haywood
> <da...@haywood-associates.co.uk>wrote:
>
> > This discussion post is mostly to the contributors, but cc:ing to user
> list
> > for opinions also...
> >
> > ~~~
> >
> > At the moment it's a daunting task to fully verify all the components of
> > the framework are working correctly prior to pushing out a release. I
> > suppose that wouldn't be so much of a concern if we had better automated
> > tests, but, hey, that's how things are.
> >
> > Moreover, frankly, some of the modules are best considered spikes and
> > probably don't constitute something that we would consider
> > production-ready. Or, at least, they haven't been used in a real-world
> > context, so it's not possible to say whether they are really
> > fit-for-purpose. I include here quite a lot of the stuff that I have
> worked
> > on over the last few years, eg the wrapper-progmodel, the groovy
> progmodel,
> > probably also the JUnit viewer and BDD viewer. Now that we are a
> top-level
> > project, I'd like it that the code we put out is thought of as production
> > ready.
> >
> > In order to make the framework easier to release, I propose that we use
> > Maven profiles to be able to release subsets of modules, that a given
> > contributor can stand behind and say: "yes, those modules are working and
> > are fit for general consumption". Each release would consist of the
> certain
> > core modules, along with selected additional viewers and object stores.
> >
> > For example, over time we might end up releasing:
> >
> > * v0.3.1 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
> >  // a "wicket/jdo release" - eg tested and released by Dan
> >
> > * v0.4.0 core + objectstore-nosql + viewer-scimpi     // a "scimpi/nosql
> > release" - eg tested and released by Rob
> >
> > * v0.5.0 core + objectstore-dflt + objectstore-xml + viewer-dnd     // a
> > "dev env release" - eg tested and released by Rob
> >
> > * v0.6.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
> > // another "wicket/jdo release"
> >
> > * v0.7.0 core + objectstore-sql + viewer-html     // a "html/sql
> release" -
> > eg tested and released by Kevin
> >
> > * v0.8.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
> > // another "wicket/jdo release"
> >
> > Whenever a release goes out, we would update our website to indicate the
> > most recent version of the components.
> >
> > Now, when I say "release", what I actually mean here is the deployment of
> > binary artifacts up to the Maven central repo. This, after all, is what
> > most users/would-be users in the community would use and consider a
> > release. However, Apache's own formal definition of "release" is actually
> > the source code release ... this is what the [VOTE] mechanism is for. I
> > don't see this changing... the vote basically says that the software
> > complies with all the legal license stuff etc. The whole codebase is
> tagged
> > with that release number, and the generated src.zip is a zip of this
> > release.
> >
> > One benefit of this is that it allows the deployment of other modules to
> be
> > performed "after the fact". For example, suppose that I (Dan) puts out
> the
> > v0.3.1 release as above, and then Rob later on tests the scimpi viewer in
> > that tag and finds it works well. He can (I think) push the release of
> the
> > scimpi viewer up to Maven central repo.
> >
> > As I see things there are several benefits to this scheme:
> >
> > a) (as already noted) the user community will only see binary releases
> that
> > are known to be of production ready. This should mitigate the "is it safe
> > to use this component" worry
> > b) (as hinted at) it should be possible for individual contributors to
> put
> > out releases of their modules more rapidly
> > c) we get visibility of which modules aren't being released; for example,
> > we might say that if a module hasn't been released by anyone for 18 or 24
> > months, say, then it's probably time to remove it from the codebase.
> >
> > ~~~
> >
> > In order to support the above scheme, I propose that we rearrange some of
> > the modules so that they can be more easily included within Maven
> > modules.  I've
> > created a page on our wiki [1] which shows my proposed rearrangement.  It
> > also repeats the above discussion text by way of context.
> >
> >
> > Opinions welcome!
> >
> > Thx
> >
> > Dan
> >
> >
> > [1]
> >
> >
> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
> >
>
>
>
> --
> mailto:matthew@matthewadams.me <ma...@matthewadams.me>
> skype:matthewadams12
> googletalk:matthew@matthewadams.me
> http://matthewadams.me
> http://www.linkedin.com/in/matthewadams
>

Re: [DISCUSSION] Making releases easier and more frequent

[Matthew Adams <ma...@matthewadams.me>]

Wouldn't these certified objectstore/viewer combos be called "assemblies"
(maven), "distributions" or "distros" (geeks & me) or "editions"
(marketeze), then?  Like, "Isis: JDO/Wicket Edition" and "Isis:
NoSQL/Scimpi Edition", etc.

Maven profiles could be used along with maven-assembly-plugin to produce
the editions, and there would be a one-to-one relationship between Maven
profile and edition.

-matthew


On Thu, Nov 29, 2012 at 8:36 AM, Dan Haywood
<da...@haywood-associates.co.uk>wrote:

> This discussion post is mostly to the contributors, but cc:ing to user list
> for opinions also...
>
> ~~~
>
> At the moment it's a daunting task to fully verify all the components of
> the framework are working correctly prior to pushing out a release. I
> suppose that wouldn't be so much of a concern if we had better automated
> tests, but, hey, that's how things are.
>
> Moreover, frankly, some of the modules are best considered spikes and
> probably don't constitute something that we would consider
> production-ready. Or, at least, they haven't been used in a real-world
> context, so it's not possible to say whether they are really
> fit-for-purpose. I include here quite a lot of the stuff that I have worked
> on over the last few years, eg the wrapper-progmodel, the groovy progmodel,
> probably also the JUnit viewer and BDD viewer. Now that we are a top-level
> project, I'd like it that the code we put out is thought of as production
> ready.
>
> In order to make the framework easier to release, I propose that we use
> Maven profiles to be able to release subsets of modules, that a given
> contributor can stand behind and say: "yes, those modules are working and
> are fit for general consumption". Each release would consist of the certain
> core modules, along with selected additional viewers and object stores.
>
> For example, over time we might end up releasing:
>
> * v0.3.1 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
>  // a "wicket/jdo release" - eg tested and released by Dan
>
> * v0.4.0 core + objectstore-nosql + viewer-scimpi     // a "scimpi/nosql
> release" - eg tested and released by Rob
>
> * v0.5.0 core + objectstore-dflt + objectstore-xml + viewer-dnd     // a
> "dev env release" - eg tested and released by Rob
>
> * v0.6.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
> // another "wicket/jdo release"
>
> * v0.7.0 core + objectstore-sql + viewer-html     // a "html/sql release" -
> eg tested and released by Kevin
>
> * v0.8.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
> // another "wicket/jdo release"
>
> Whenever a release goes out, we would update our website to indicate the
> most recent version of the components.
>
> Now, when I say "release", what I actually mean here is the deployment of
> binary artifacts up to the Maven central repo. This, after all, is what
> most users/would-be users in the community would use and consider a
> release. However, Apache's own formal definition of "release" is actually
> the source code release ... this is what the [VOTE] mechanism is for. I
> don't see this changing... the vote basically says that the software
> complies with all the legal license stuff etc. The whole codebase is tagged
> with that release number, and the generated src.zip is a zip of this
> release.
>
> One benefit of this is that it allows the deployment of other modules to be
> performed "after the fact". For example, suppose that I (Dan) puts out the
> v0.3.1 release as above, and then Rob later on tests the scimpi viewer in
> that tag and finds it works well. He can (I think) push the release of the
> scimpi viewer up to Maven central repo.
>
> As I see things there are several benefits to this scheme:
>
> a) (as already noted) the user community will only see binary releases that
> are known to be of production ready. This should mitigate the "is it safe
> to use this component" worry
> b) (as hinted at) it should be possible for individual contributors to put
> out releases of their modules more rapidly
> c) we get visibility of which modules aren't being released; for example,
> we might say that if a module hasn't been released by anyone for 18 or 24
> months, say, then it's probably time to remove it from the codebase.
>
> ~~~
>
> In order to support the above scheme, I propose that we rearrange some of
> the modules so that they can be more easily included within Maven
> modules.  I've
> created a page on our wiki [1] which shows my proposed rearrangement.  It
> also repeats the above discussion text by way of context.
>
>
> Opinions welcome!
>
> Thx
>
> Dan
>
>
> [1]
>
> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
>



-- 
mailto:matthew@matthewadams.me <ma...@matthewadams.me>
skype:matthewadams12
googletalk:matthew@matthewadams.me
http://matthewadams.me
http://www.linkedin.com/in/matthewadams

Re: [DISCUSSION] Making releases easier and more frequent

[Mike Burton <mi...@mycosystems.co.uk>]

+1
For reason a) , ease new users in. 

Best Regards

Mike Burton
(Sent from my iPhone)




On 29 Nov 2012, at 14:36, Dan Haywood <da...@haywood-associates.co.uk> wrote:

> This discussion post is mostly to the contributors, but cc:ing to user list
> for opinions also...
> 
> ~~~
> 
> At the moment it's a daunting task to fully verify all the components of
> the framework are working correctly prior to pushing out a release. I
> suppose that wouldn't be so much of a concern if we had better automated
> tests, but, hey, that's how things are.
> 
> Moreover, frankly, some of the modules are best considered spikes and
> probably don't constitute something that we would consider
> production-ready. Or, at least, they haven't been used in a real-world
> context, so it's not possible to say whether they are really
> fit-for-purpose. I include here quite a lot of the stuff that I have worked
> on over the last few years, eg the wrapper-progmodel, the groovy progmodel,
> probably also the JUnit viewer and BDD viewer. Now that we are a top-level
> project, I'd like it that the code we put out is thought of as production
> ready.
> 
> In order to make the framework easier to release, I propose that we use
> Maven profiles to be able to release subsets of modules, that a given
> contributor can stand behind and say: "yes, those modules are working and
> are fit for general consumption". Each release would consist of the certain
> core modules, along with selected additional viewers and object stores.
> 
> For example, over time we might end up releasing:
> 
> * v0.3.1 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
> // a "wicket/jdo release" - eg tested and released by Dan
> 
> * v0.4.0 core + objectstore-nosql + viewer-scimpi     // a "scimpi/nosql
> release" - eg tested and released by Rob
> 
> * v0.5.0 core + objectstore-dflt + objectstore-xml + viewer-dnd     // a
> "dev env release" - eg tested and released by Rob
> 
> * v0.6.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
> // another "wicket/jdo release"
> 
> * v0.7.0 core + objectstore-sql + viewer-html     // a "html/sql release" -
> eg tested and released by Kevin
> 
> * v0.8.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects
> // another "wicket/jdo release"
> 
> Whenever a release goes out, we would update our website to indicate the
> most recent version of the components.
> 
> Now, when I say "release", what I actually mean here is the deployment of
> binary artifacts up to the Maven central repo. This, after all, is what
> most users/would-be users in the community would use and consider a
> release. However, Apache's own formal definition of "release" is actually
> the source code release ... this is what the [VOTE] mechanism is for. I
> don't see this changing... the vote basically says that the software
> complies with all the legal license stuff etc. The whole codebase is tagged
> with that release number, and the generated src.zip is a zip of this
> release.
> 
> One benefit of this is that it allows the deployment of other modules to be
> performed "after the fact". For example, suppose that I (Dan) puts out the
> v0.3.1 release as above, and then Rob later on tests the scimpi viewer in
> that tag and finds it works well. He can (I think) push the release of the
> scimpi viewer up to Maven central repo.
> 
> As I see things there are several benefits to this scheme:
> 
> a) (as already noted) the user community will only see binary releases that
> are known to be of production ready. This should mitigate the "is it safe
> to use this component" worry
> b) (as hinted at) it should be possible for individual contributors to put
> out releases of their modules more rapidly
> c) we get visibility of which modules aren't being released; for example,
> we might say that if a module hasn't been released by anyone for 18 or 24
> months, say, then it's probably time to remove it from the codebase.
> 
> ~~~
> 
> In order to support the above scheme, I propose that we rearrange some of
> the modules so that they can be more easily included within Maven
> modules.  I've
> created a page on our wiki [1] which shows my proposed rearrangement.  It
> also repeats the above discussion text by way of context.
> 
> 
> Opinions welcome!
> 
> Thx
> 
> Dan
> 
> 
> [1]
> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent