On 30 November 2012 19:41, Kevin Meyer - KMZ <[email protected]> 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 <[email protected]
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 <[email protected]>
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
<[email protected]>**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 <[email protected]>
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
<[email protected]>**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
