On 31-Jul-08, at 8:04 AM, Jesse McConnell wrote:
Maybe we extend the definition of a classifier to explicitly refer
to things
like sources and javadocs which have no impact on the dependency
requirements. GWT for the MAC is really a different artifact then
GWT for
Linux and maybe we should just start treating them as such.
This is what I was thinking when reading through this thread. Jan has
grumbled about us maven guys and our double standards every time I
pull out the classifier card in jetty. I have defended it because of
things like the sources and javadoc are perfect additive artifact-lite
additions to the repository and metadata of an artifact. But they are
linked to that core artifact in question very strongly. As soon as we
start adding classifiers for things like jdk version and need to alter
the core dependency set associated with the artifact it feels like we
have lost our way a bit.
I've never had anything against derived artifacts (multiple JDKs,
remoting clients), or truly secondary artifacts like javadoc and
sources. If many of those come from one project that has never been
the problem in my mind. The multiple artifacts per project has always
been an architectural concern. A simple example being don't stick the
client code, server code, and shared utility code in one build because
it leads to problems in coupling, testing, maintainable, reusability,
and separating of concerns. If one project actually ejected 3
artifacts where there was one for each JDK that project wished to
support that's fine. I don't we we have any religious fervor around
that idea. It's the architectural muddling we want to avoid.
classifiers have become a bit like profiles in that sense, they are a
point in maven that is easy to abuse and we are increasingly abusing
it...Just the other day the apacheds guys were trying to get test
cases from one artifact usable in another and it seemed logical to
wrap those tests up in a classifier and use them (which we advocate in
places) but that didn't really cut it, they didn't want to extend the
test classes in the test classified component, they wanted the actual
tests run, probably configured to use some new component. Sure this
could be added to surefire if there is a way to looking up the
classnames with Test in them.. but you could do it _now_ under the
current classifier setup if you produce a new artifact that is
composed of the test source itself and then dropping that source into
a place to be compiled and used as tests...(they didn't do this I
don't think)
my point is that this is quickly leaving the realm of 'one artifact
per pom' since we can easily have multi-purpose artifacts being
produced...and if it can be done it probably will be done (or I have
already done it and busted something else :P)
That has always been the case, but there are two very distinct
accompaniments. Assistive accompaniments like javadoc and source jars,
and what we've come to see now like test jars, jdk specific variants,
and possibly platform specific variants. These are really different
things and I think we can support this while still not allowing the
multiple artifacts in the architecturally muddling sense.
Obviously having to make 28 POMs for one project to eject support for
different platforms is dumb. That's not the fundamental idea around
"one artifact per build", it's one of a separation of concerns. We can
accommodate both those ideas. I think a simple change in a definition
where we say secondary artifacts are things like javadoc and source
jars. And things like test jars, jdk specific version, and platform
specific versions are indeed truly different artifacts and they should
be treated as such. Then we need how to decide if a secondary artifact
maps to many primary artifacts. Does the javadoc jar for example map
to the many JDK specific versions.
The only real critical element that matters is that for anything truly
different can you deployment, retrieve accurate metadata so you can
reason about said artifact, and that you can retrieve it. The big
whole currently is the metadata part which is a huge problem. We can,
and probably do, misrepresent artifacts.
jesse
--
jesse mcconnell
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
Three people can keep a secret provided two of them are dead.
-- Unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
