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] > >
