Jason van Zyl wrote:
That's really not fundamentally different then just using a different
artifact id. I think where I'm going is that classifiers are not
suitable for the bits that make up the build path and classpath. Those
are really for secondary artifacts like javadoc jars and source jars.
How would you treat jdk14 vs. jdk15 as classifier - one of them hits the
classpath. But I don't think they should be different IDs, do they?
What if we limit classifiers to post-testing processing only: have one
major binary product that could be post-processed into classifiers? Then
we avoid server/client/shared nightmare ..
And we must have this information recorded in some form or shape! Better
a POM per classifier with references from the main POM.
On 31-Jul-08, at 8:48 AM, Stephen Connolly wrote:
My solution is to allow pom's with classifiers!
That way the -jdk14 jar has a -jdk14 pom to specify it's dependencies.
If the pom is not there then you assume the pom for without the
classifier.... thus not requiring a DOM change... i.e. could be made
work
for 2.0.11. And plus it will only affect new artifacts
Now as to generating these pom's... I presume we could have a simple
plugin
that outputs to target a copy of the pom with the dependencies for a
specified profile and attaches that pom to the build...
In fact such a plugin would be of use more generally... for example
internally we have one pom that lists all the developers... however
if we
publish the artifact we don't want customers contacting the developers
directly... so we'd prefer to deploy a transformed pom to the repo,
not the
one that we use for development.
-Stephen
On Thu, Jul 31, 2008 at 3:43 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote:
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]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.
-- Buddha
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
