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
