I just started dialog with the BC guys to look at Mercury so I will
see what there thoughts are.
If it is the case where it is common that for a given GAV the
classified artifact requires different dependencies then I think we
have some flaws in the system. It means we just ran out of runway
because we can't actually express what an artifact needs correctly.
It does not seem unlikely that a different JDK or a different platform
might require something different. If this is prevalent then our
definition of a classifier is in correct. It works for non-runtime
artifacts like javadocs and sources as those are obviously don't
require any dependency changes.
Oleg and I were talking about this yesterday in fact where an artifact
that may potentially be in the classpath should have it's own POM. We
also have the case today where artifacts with classifiers are not
reflected in the metadata explicitly. We can scan a repository with
Nexus and find out what artifacts have sources and javadocs, but you
can't tell normally without making a query and have it succeed or fail.
That said, if people know of many cases where a classified artifact
does indeed require changes in the dependency set I don't think we can
use classifiers. The asymmetry in the requirements for an artifact
with a classifier look problematic in this case. For an artifact that
participates in a build or runtime, it needs a POM of its own if the
system is going to be deterministic.
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.
On 31-Jul-08, at 4:49 AM, Mark Hobson wrote:
2008/7/23 Brett Porter <[EMAIL PROTECTED]>:
On 23/07/2008, at 1:34 AM, Jason van Zyl wrote:
Ok,
I have a package for the new 140 version as that's what I'm using
but what
they have in central currently doesn't use classifiers which is
probably not
so good.
http://repo1.maven.org/maven2/org/bouncycastle/
So we can either:
1) Follow what they have their which is incorrect technically
2) Deploy using classifiers as it probably should. Leave the old
version
130 there as it but also redeploy it using classifiers
If we can decide I'll push version 140 into central.
I think part of the problem is that there will be only one POM, but
you need
to express dependencies, and all those have classifiers. This is
probably
why I put them in in the form I did some time back. I'd prefer
classifiers
myself if there's some way we can think to work around that?
Was any consensus reached regarding uploading bouncycastle 140 to
central? I was about to submit an upload request and then recalled
this discussion. Whilst we're doing this, shall we fix the
following?:
- use org.bouncycastle group id rather than bouncycastle
- add dependencies, e.g. bcmail should depend on bcprov
- supply source and javadoc jars
- [contentious] change version to 1.40 instead of 140, as detailed in
the release notes
And as discussed above:
- [impossible?] use classifiers for jdk
Mark
---------------------------------------------------------------------
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
----------------------------------------------------------
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
