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
>

Reply via email to