isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Haywood <...@haywood-associates.co.uk>
Subject Re: [DISCUSSION] Making releases easier and more frequent
Date Sat, 01 Dec 2012 13:44:14 GMT
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 <dan@haywood-associates.co.uk> wrote:

>
>
> On 30 November 2012 19:41, Kevin Meyer - KMZ <kevin@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 <rafael@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
>> > >>> <dan@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 <rafael@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
>> > >>>>> <dan@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
>>
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message