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:40:30 GMT
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