On Thu, Jul 31, 2008 at 6:55 PM, Stephen Connolly <
[EMAIL PROTECTED]> wrote:
> 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.
>
And if two artifacts specify different classifiers... dependency resolution
fails and you need to use exclusions
>
>
> 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.
>
fooreloaded would specify that it depends on bar-jdk15 in order to force the
jdk15 artifact.
Hmmm... perhaps some additional rules... pom's with classifiers can only add
dependencies to the pom without... we could do this with a merge of the
dependencies section.... actually that could work even better...
pom with classifier is just
*bar-jdk14.pom*
<project>
<parent>
<groupId>blah</groupId>
<artifactId>bar</artifactId>
<version>...</version>
</parent>
<dependencies>
<dependency>
....
</dependency>
</dependencies>
</project>
And that is the only elements allowed in it.
we pick them up in the source code as pom-jdk14.xml beside pom.xml and all
it specifies is the extra dependencies
It pulls the rest from the parent pom.
>
> 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]
>>
>>
>
