I've been looking through the wiki page again at the naming. As a
comparison here are some of the Maven modules:-
GroupId ArtifactId
org.apache.maven.shared file-maven
org.apache.maven.shared management-archiver
org.apache.maven.shared maven-artifact-resolver
org.apache.maven.shared maven-common-artifact-filters
org.apache.maven.shared maven-dependency-analyzer
org.apache.maven.shared maven-doxia-tools
org.apache.maven.shared maven-filtering
org.apache.maven.shared maven-invoker
org.apache.maven.shared maven-repository-builder
org.apache.maven.plugins maven-antrun-plugin
org.apache.maven.plugins maven-assembly-plugin
org.apache.maven.plugins maven-clean-plugin
org.apache.maven.plugins maven-compiler-plugin
org.apache.maven.plugins maven-dependency-plugin
org.apache.maven.plugins maven-deploy-plugin
org.apache.maven.plugins maven-docck-plugin
org.apache.maven.plugins maven-enforcer-plugin
org.apache.maven.plugins maven-failsafe-plugin
When I look at this list, several things strike me:-
1) on the whole it's clean and consice, yet clear what each module is.
2) the artifact id tells me everything I want to know about that module:
it tells me that it's part of Maven; whether it's a core part or a
plugin; and what the module is for. The group id actually adds nothing,
it just indicates who's responsible for that module.
3) the artifact ids read easily, for example, the maven-compiler-plugin
is the Maven compiler plugin (as we say in the UK it does what it says
on the tin).
After these observation I would like to suggest the following:-
1) we don't need a proliferation of group ids - is it part of the core
or not.
2) the names we use should read clearly, the JDO module is an object
store, so say that - ie., isis-jdo-objectstore, and not
isis-objectstore-jdo. Also this groups the components that use the same
technology, eg isis-sql-objectstore, isis-sql-security and
isis-sql-profilestore all reflect my choice to use a SQL database (if
I'm using SQL persistence then I probably want to use it for everything).
3) non-standard abbreviations should be avoided. Can we call default
modules "default" rather than "dflt". I know you can't do the same thing
for package names, but that's fine. An alternative is to use the term
"fallback", "basic" or "simple".
Not directly related, but I'm still not sure about the runtime modules.
Actually I'm confused. What are they all about, what is a "runtime
runtime"? When I look at the list of core Maven modules they seem to
relate to my understanding of how Maven works. With Isis i just know I
need everything to make it work. Not a good advert for encouraging
others to get involved in the core.
Rob
PS don't retire the XML store, I'm always making use of it.
On 11/30/12 16:52, Dan Haywood wrote:
... and, for the same reason, probably should add the component type there
also, as suggested by both Rob and Minto. Else, "isis-sql" might be the
object store, or might be a security impl.
I guess the artifactIds are a bit long as a result, but better that than
ambiguity and the possibility of clashes.
On 30 November 2012 16:46, Dan Haywood <[email protected]> wrote:
Ah, ok. Yeah, that does make sense... I do indeed stand corrected.
In that case, we probably should follow the convention of other
frameworks. Let me go update that wiki page now [1].
Thx
Dan
[1]
https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent
On 30 November 2012 16:43, Rafael Chaves <[email protected]> wrote:
Dan, I never mentioned a manual process. In the process of packaging a
Java
app, the common scenario is that all dependencies are fetched and placed
in
a single directory (for instance, the WEB-INF/lib dir for JEE webapps).
Once a Java application is packaged, Maven groups disappear. No surprise,
since Maven is a development/build time tool only. It is then that a
common
prefix makes a big difference.
Hope it was clear now. Cheers,
Rafael
A J2EE webapp I know fetches As part of the build process all the
dependencies used by the application (be it a web app, are (automatically)
fetched into
On Fri, Nov 30, 2012 at 8:31 AM, Dan Haywood
<[email protected]>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
