2008/8/4 Mark Hobson <[EMAIL PROTECTED]>:
> Looks like this is not going to get resolved any time soon. In the
> meantime, I'll submit an upload request with the above changes if I
> hear no objections.
I decided not to rock the boat, so kept the group id as 'bouncycastle'
and the incorrect versi
2008/7/31 Mark Hobson <[EMAIL PROTECTED]>:
> 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
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
> vers
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
John Casey wrote:
I've been talking to various people in the Maven community about this
sort of thing for ages, probably more than two years at this point.
Some of the most interesting conversations come when you talk to
people interested in using Maven to build C projects, where certain
lib
John Casey wrote:
To me, all of this points to a dire need to separate dependency metadata
from the POM that all of these derivative artifacts shares.
I could imagine this would also ease long-term interoperability of
different Maven versions with the repository. Imagine the day when the
POM
I've been talking to various people in the Maven community about this
sort of thing for ages, probably more than two years at this point. Some
of the most interesting conversations come when you talk to people
interested in using Maven to build C projects, where certain libraries
are required t
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 ja
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, a
On 31-Jul-08, at 8:04 AM, Jesse McConnell wrote:
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
To me that seems over complicated in that you need a whole other sub-
system in Maven to define the requirements of a target. Why not just
state explicitly what the target needs and dispense with the rest of
the machinery. Dependencies accrued via profiles is a very nasty beast
in the projec
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
I had some ideas about expanding classifier usage for use with NMaven. May
be worth a look:
http://docs.codehaus.org/display/MAVENUSER/Expanded+Classifier+Support
Shane
On Thu, Jul 31, 2008 at 8:04 AM, Jesse McConnell
<[EMAIL PROTECTED]>wrote:
> > Maybe we extend the definition of a classifier t
> 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.
>
This is what
Yea, there are bunches of examples. Any JAX-WS or JAXB thing
wouldn't need the jaxb/jaxws api jars if running on Java 6. Recent
xml apis are in java 5. Java 7 will probably have a ton of other
things.
I'm wondering if we could activate profiles based on classifiers.
On Thu, Jul 31, 2008 at 4:43 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote:
> 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.
But that seems to be quite naturally to me. Consider the
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 runwa
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.
Stephen Connolly wrote:
> On Wed, Jul 23, 2008 at 9:22 AM, Jörg Schaible wrote:
>
>> Another prominent use case are ejb-client artifacts. They do
>> normally not have the same dependencies as the EJB itself.
>>
>
> Is/should that not be more a case of a separate artifact rather than
> the same a
On Wed, Jul 23, 2008 at 9:22 AM, Jörg Schaible <
[EMAIL PROTECTED]> wrote:
> Stephen Connolly wrote:
> > On Wed, Jul 23, 2008 at 1:39 AM, Brett Porter
> > <[EMAIL PROTECTED]> wrote:
> >
> >>
> >> On 23/07/2008, at 1:34 AM, Jason van Zyl wrote:
> >>
> >> Ok,
> >>>
> >>> I have a package for the ne
Stephen Connolly wrote:
> On Wed, Jul 23, 2008 at 1:39 AM, Brett Porter
> <[EMAIL PROTECTED]> wrote:
>
>>
>> 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 u
On Wed, Jul 23, 2008 at 1:39 AM, Brett Porter <[EMAIL PROTECTED]> wrote:
>
> 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
>>
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) Foll
23 matches
Mail list logo
