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
On Jul 22, 2008, at 11: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) F
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 technica
On 23/07/2008, at 12:23 AM, Daniel Kulp wrote:
Brett,
What are you doing about the fact that we cannot ship any versions
of bouncycastle that is currently in the central repository due to
the IDEA patent encumbered algorithm in it?
(FYI: they did create a new "140" version with it remov
Brett,
What are you doing about the fact that we cannot ship any versions of
bouncycastle that is currently in the central repository due to the
IDEA patent encumbered algorithm in it?
(FYI: they did create a new "140" version with it removed, but it's
not at central yet)
Dan
On Jul
Okay. I had read the page but I wasn't clear whether you meant that
configured keyring to be where the verifier looked for a specified key
or if you expected the verifier to iterate over those keys. I'm gllad
it was the second option.
I think this pretty much covers what I was expecting then
On 22/07/2008, at 11:54 PM, Chad La Joie wrote:
Yeah, the code is a bit spread out at the moment. ;) Thanks for
the links though, that helped me find the rest of what I needed.
Looking at the code I have one question. Is the assumption that a
devloper would specifiy the signature-valida
Yeah, the code is a bit spread out at the moment. ;) Thanks for the
links though, that helped me find the rest of what I needed.
Looking at the code I have one question. Is the assumption that a
devloper would specifiy the signature-validating key, which will need to
be in their keyring, fo
On 22/07/2008, at 7:30 PM, Chad La Joie wrote:
So, I had a look at the code wagon manager code and it looks pretty
much as I'd have expected. I was not able to find the
WagonOpenPgpSignatureVerifierObserver class. Could you point me to
that?
Thanks.
http://svn.apache.org/viewvc/maven
So, I had a look at the code wagon manager code and it looks pretty much
as I'd have expected. I was not able to find the
WagonOpenPgpSignatureVerifierObserver class. Could you point me to that?
Thanks.
Brett Porter wrote:
Hi Chad,
2008/7/22 Chad La Joie <[EMAIL PROTECTED]>:
Thanks Brett,
32 matches
Mail list logo
