But perhaps it should be! Consider this case...
I have an artifact foo... it depends on bar... it does not really care what JDK Another artifact manchu also depends on bar... but it needs the jdk14 version My webapp foomanchu depends on both foo and manchu and is targetted at jdk14, while the webapp fooreloaded depends on foo and only runs on jdk15. If we use different artifactIds then we end up with useless dependency resolution because we have no information to tell us that bar-jdk14 and bar-jdk15 are equivalent in providing foo's dependencies. What I would propose is that: 1. in the absence of any poms with classifiers... there is only one classpath allowed artifact. 2. in the presence of poms with classifiers, then dependencies that do not specify a classifier can match any of the pom's with classifiers but will default to the pom without. with that scheme, foo would declare a dependency on bar without specifying the classifier. manchu would declate a dependency on bar and specify the classifier as jdk14 in foomanchu we would see that foo needs any bar while manchu needs jdk14... thereby fullfilling foo's needs. I don't see how we can fix this type of think with different artifactId's without changing the DOM -Stephen On Thu, Jul 31, 2008 at 5:26 PM, Jason van Zyl <[EMAIL PROTECTED]> 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. > > > 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] > >
