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