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 Mon, 03 Dec 2012 07:47:53 GMT
On 2 December 2012 22:07, Robert Matthews <rmatthews@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 <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<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+****<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
>>>>
>>>>
>>>>
>>>>
>

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