You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Brett Porter <br...@apache.org> on 2008/07/23 02:39:24 UTC
Re: bouncycastle in central was: Mojo for validating PGP signature
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?
- Brett
> On 22-Jul-08, at 10: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 removed, but it's
>> not at central yet)
>>
>> Dan
>>
>>
>>
>> On Jul 22, 2008, at 9:07 AM, Brett Porter wrote:
>>
>>>
>>> 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/sandbox/trunk/wagon/wagon-
>>> openpgp/
>>>
>>> You'll also be looking for:
>>> http://svn.apache.org/viewvc/commons/sandbox/openpgp/trunk/
>>>
>>> Both of these should have snapshots deployed already.
>>>
>>> There's certainly too many levels of indirection in here - it
>>> started out with a different intent and I'll likely be cutting it
>>> down a bit once it is working.
>>>
>>> Cheers,
>>> Brett
>>>
>>> --
>>> Brett Porter
>>> brett@apache.org
>>> http://blogs.exist.com/bporter/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---
>> Daniel Kulp
>> dkulp@apache.org
>> http://www.dankulp.com/blog
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> We know what we are, but know not what we may be.
>
> -- Shakespeare
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: bouncycastle in central was: Mojo for validating PGP signature
Posted by Jörg Schaible <Jo...@Elsag-Solutions.com>.
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 artifact?
The ejb-client *is* a separate artifact, see maven-ejb-plugin docs.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: bouncycastle in central was: Mojo for validating PGP signature
Posted by Stephen Connolly <st...@gmail.com>.
On Wed, Jul 23, 2008 at 9:22 AM, Jörg Schaible <
Joerg.Schaible@elsag-solutions.com> wrote:
> Stephen Connolly wrote:
> > On Wed, Jul 23, 2008 at 1:39 AM, Brett Porter
> > <br...@apache.org> 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 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?
> >>
> >> - Brett
> >
> >
> > Is there any plans to fix this general problem?
> >
> > I.e. where the classifiers have different dependencies than the main
> > artifact.
> >
> > It would seem to be the use case that classifiers suggest using.
> >
> > i.e. a jdk1.4 classifier is not only compiled with 1.4 source, but has
> > additional dependencies because the 1.4 jre does not have all
> > the apis that
> > 1.5 has... so the jdk1.4 build should pull in those dependencies.
> >
> > I know one solution would be the schema-changing solution...
> > but what about
> > having poms with classifiers too? OK, so that would not get
> > picked up by
> > Maven <= 2.0.11... but still
>
> 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 artifact?
>
> - Jörg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
RE: bouncycastle in central was: Mojo for validating PGP signature
Posted by Jörg Schaible <Jo...@Elsag-Solutions.com>.
Stephen Connolly wrote:
> On Wed, Jul 23, 2008 at 1:39 AM, Brett Porter
> <br...@apache.org> 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 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?
>>
>> - Brett
>
>
> Is there any plans to fix this general problem?
>
> I.e. where the classifiers have different dependencies than the main
> artifact.
>
> It would seem to be the use case that classifiers suggest using.
>
> i.e. a jdk1.4 classifier is not only compiled with 1.4 source, but has
> additional dependencies because the 1.4 jre does not have all
> the apis that
> 1.5 has... so the jdk1.4 build should pull in those dependencies.
>
> I know one solution would be the schema-changing solution...
> but what about
> having poms with classifiers too? OK, so that would not get
> picked up by
> Maven <= 2.0.11... but still
Another prominent use case are ejb-client artifacts. They do normally not have the same dependencies as the EJB itself.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: bouncycastle in central was: Mojo for validating PGP signature
Posted by Stephen Connolly <st...@gmail.com>.
On Wed, Jul 23, 2008 at 1:39 AM, Brett Porter <br...@apache.org> 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
>> 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?
>
> - Brett
Is there any plans to fix this general problem?
I.e. where the classifiers have different dependencies than the main
artifact.
It would seem to be the use case that classifiers suggest using.
i.e. a jdk1.4 classifier is not only compiled with 1.4 source, but has
additional dependencies because the 1.4 jre does not have all the apis that
1.5 has... so the jdk1.4 build should pull in those dependencies.
I know one solution would be the schema-changing solution... but what about
having poms with classifiers too? OK, so that would not get picked up by
Maven <= 2.0.11... but still
>
>
>
> On 22-Jul-08, at 10: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 removed, but it's not
>>> at central yet)
>>>
>>> Dan
>>>
>>>
>>>
>>> On Jul 22, 2008, at 9:07 AM, Brett Porter wrote:
>>>
>>>
>>>> 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/sandbox/trunk/wagon/wagon-openpgp/
>>>>
>>>> You'll also be looking for:
>>>> http://svn.apache.org/viewvc/commons/sandbox/openpgp/trunk/
>>>>
>>>> Both of these should have snapshots deployed already.
>>>>
>>>> There's certainly too many levels of indirection in here - it started
>>>> out with a different intent and I'll likely be cutting it down a bit once it
>>>> is working.
>>>>
>>>> Cheers,
>>>> Brett
>>>>
>>>> --
>>>> Brett Porter
>>>> brett@apache.org
>>>> http://blogs.exist.com/bporter/
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>> ---
>>> Daniel Kulp
>>> dkulp@apache.org
>>> http://www.dankulp.com/blog
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>> We know what we are, but know not what we may be.
>>
>> -- Shakespeare
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: bouncycastle in central was: Mojo for validating PGP signature
Posted by Mark Hobson <ma...@gmail.com>.
2008/8/4 Mark Hobson <ma...@gmail.com>:
> 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 versioning scheme of 140:
http://jira.codehaus.org/browse/MAVENUPLOAD-2165
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: bouncycastle in central was: Mojo for validating PGP signature
Posted by Mark Hobson <ma...@gmail.com>.
2008/7/31 Mark Hobson <ma...@gmail.com>:
> 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
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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: bouncycastle in central was: Mojo for validating PGP signature
Posted by Shane Isbell <sh...@gmail.com>.
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
<je...@gmail.com>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 just start treating them as such.
> >
>
> This is what I was thinking when reading through this thread. Jan has
> grumbled about us maven guys and our double standards every time I
> pull out the classifier card in jetty. I have defended it because of
> things like the sources and javadoc are perfect additive artifact-lite
> additions to the repository and metadata of an artifact. But they are
> linked to that core artifact in question very strongly. As soon as we
> start adding classifiers for things like jdk version and need to alter
> the core dependency set associated with the artifact it feels like we
> have lost our way a bit.
>
> classifiers have become a bit like profiles in that sense, they are a
> point in maven that is easy to abuse and we are increasingly abusing
> it...Just the other day the apacheds guys were trying to get test
> cases from one artifact usable in another and it seemed logical to
> wrap those tests up in a classifier and use them (which we advocate in
> places) but that didn't really cut it, they didn't want to extend the
> test classes in the test classified component, they wanted the actual
> tests run, probably configured to use some new component. Sure this
> could be added to surefire if there is a way to looking up the
> classnames with Test in them.. but you could do it _now_ under the
> current classifier setup if you produce a new artifact that is
> composed of the test source itself and then dropping that source into
> a place to be compiled and used as tests...(they didn't do this I
> don't think)
>
> my point is that this is quickly leaving the realm of 'one artifact
> per pom' since we can easily have multi-purpose artifacts being
> produced...and if it can be done it probably will be done (or I have
> already done it and busted something else :P)
>
> jesse
>
> --
> jesse mcconnell
> jesse.mcconnell@gmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: bouncycastle in central was: Mojo for validating PGP signature
Posted by Jason van Zyl <ja...@maven.org>.
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 just start treating them as such.
>>
>
> This is what I was thinking when reading through this thread. Jan has
> grumbled about us maven guys and our double standards every time I
> pull out the classifier card in jetty. I have defended it because of
> things like the sources and javadoc are perfect additive artifact-lite
> additions to the repository and metadata of an artifact. But they are
> linked to that core artifact in question very strongly. As soon as we
> start adding classifiers for things like jdk version and need to alter
> the core dependency set associated with the artifact it feels like we
> have lost our way a bit.
>
I've never had anything against derived artifacts (multiple JDKs,
remoting clients), or truly secondary artifacts like javadoc and
sources. If many of those come from one project that has never been
the problem in my mind. The multiple artifacts per project has always
been an architectural concern. A simple example being don't stick the
client code, server code, and shared utility code in one build because
it leads to problems in coupling, testing, maintainable, reusability,
and separating of concerns. If one project actually ejected 3
artifacts where there was one for each JDK that project wished to
support that's fine. I don't we we have any religious fervor around
that idea. It's the architectural muddling we want to avoid.
> classifiers have become a bit like profiles in that sense, they are a
> point in maven that is easy to abuse and we are increasingly abusing
> it...Just the other day the apacheds guys were trying to get test
> cases from one artifact usable in another and it seemed logical to
> wrap those tests up in a classifier and use them (which we advocate in
> places) but that didn't really cut it, they didn't want to extend the
> test classes in the test classified component, they wanted the actual
> tests run, probably configured to use some new component. Sure this
> could be added to surefire if there is a way to looking up the
> classnames with Test in them.. but you could do it _now_ under the
> current classifier setup if you produce a new artifact that is
> composed of the test source itself and then dropping that source into
> a place to be compiled and used as tests...(they didn't do this I
> don't think)
>
> my point is that this is quickly leaving the realm of 'one artifact
> per pom' since we can easily have multi-purpose artifacts being
> produced...and if it can be done it probably will be done (or I have
> already done it and busted something else :P)
>
That has always been the case, but there are two very distinct
accompaniments. Assistive accompaniments like javadoc and source jars,
and what we've come to see now like test jars, jdk specific variants,
and possibly platform specific variants. These are really different
things and I think we can support this while still not allowing the
multiple artifacts in the architecturally muddling sense.
Obviously having to make 28 POMs for one project to eject support for
different platforms is dumb. That's not the fundamental idea around
"one artifact per build", it's one of a separation of concerns. We can
accommodate both those ideas. I think a simple change in a definition
where we say secondary artifacts are things like javadoc and source
jars. And things like test jars, jdk specific version, and platform
specific versions are indeed truly different artifacts and they should
be treated as such. Then we need how to decide if a secondary artifact
maps to many primary artifacts. Does the javadoc jar for example map
to the many JDK specific versions.
The only real critical element that matters is that for anything truly
different can you deployment, retrieve accurate metadata so you can
reason about said artifact, and that you can retrieve it. The big
whole currently is the metadata part which is a huge problem. We can,
and probably do, misrepresent artifacts.
> jesse
>
> --
> jesse mcconnell
> jesse.mcconnell@gmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
Three people can keep a secret provided two of them are dead.
-- Unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: bouncycastle in central was: Mojo for validating PGP signature
Posted by Jesse McConnell <je...@gmail.com>.
> 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 I was thinking when reading through this thread. Jan has
grumbled about us maven guys and our double standards every time I
pull out the classifier card in jetty. I have defended it because of
things like the sources and javadoc are perfect additive artifact-lite
additions to the repository and metadata of an artifact. But they are
linked to that core artifact in question very strongly. As soon as we
start adding classifiers for things like jdk version and need to alter
the core dependency set associated with the artifact it feels like we
have lost our way a bit.
classifiers have become a bit like profiles in that sense, they are a
point in maven that is easy to abuse and we are increasingly abusing
it...Just the other day the apacheds guys were trying to get test
cases from one artifact usable in another and it seemed logical to
wrap those tests up in a classifier and use them (which we advocate in
places) but that didn't really cut it, they didn't want to extend the
test classes in the test classified component, they wanted the actual
tests run, probably configured to use some new component. Sure this
could be added to surefire if there is a way to looking up the
classnames with Test in them.. but you could do it _now_ under the
current classifier setup if you produce a new artifact that is
composed of the test source itself and then dropping that source into
a place to be compiled and used as tests...(they didn't do this I
don't think)
my point is that this is quickly leaving the realm of 'one artifact
per pom' since we can easily have multi-purpose artifacts being
produced...and if it can be done it probably will be done (or I have
already done it and busted something else :P)
jesse
--
jesse mcconnell
jesse.mcconnell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: bouncycastle in central was: Mojo for validating PGP signature
Posted by Jason van Zyl <ja...@maven.org>.
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 project builder.
On 31-Jul-08, at 7:59 AM, Daniel Kulp wrote:
>
> 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.
>
> <profile>
> <activation>
> <classifier>jdk15</classifer>
> </activation>
> <dependencies>
> .....
> </dependencies>
> </profile>
>
> or similar.
>
> Dan
>
>
> On Jul 31, 2008, at 10:53 AM, Jochen Wiedmann wrote:
>
>> On Thu, Jul 31, 2008 at 4:43 PM, Jason van Zyl <ja...@maven.org>
>> 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 case of a
>> jar
>> file which has been processed by RetroTranslator or something
>> similar.
>> The artifact with the jdk14-classifier might (for example) need
>> additional retrotranslator libraries. It might also need jaxp3 and
>> lots of other stuff thats in JDK 1.5 by default.
>>
>>
>>> 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.
>>
>> Ok, but in that case I would also suggest to reconsider the "one
>> artifact per project" dogma. At least, I wouldn't be overly happy to
>> split a lot of projects into multiple just because they finally run
>> retrotranslator to obtain a JDK 1.4 version.
>>
>>
>> Jochen
>>
>>
>> --
>> Look, that's why there's rules, understand? So that you think before
>> you break 'em.
>>
>> -- (Terry Pratchett, Thief of Time)
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: bouncycastle in central was: Mojo for validating PGP signature
Posted by Daniel Kulp <dk...@apache.org>.
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.
<profile>
<activation>
<classifier>jdk15</classifer>
</activation>
<dependencies>
.....
</dependencies>
</profile>
or similar.
Dan
On Jul 31, 2008, at 10:53 AM, Jochen Wiedmann wrote:
> On Thu, Jul 31, 2008 at 4:43 PM, Jason van Zyl <ja...@maven.org>
> 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 case of a jar
> file which has been processed by RetroTranslator or something similar.
> The artifact with the jdk14-classifier might (for example) need
> additional retrotranslator libraries. It might also need jaxp3 and
> lots of other stuff thats in JDK 1.5 by default.
>
>
>> 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.
>
> Ok, but in that case I would also suggest to reconsider the "one
> artifact per project" dogma. At least, I wouldn't be overly happy to
> split a lot of projects into multiple just because they finally run
> retrotranslator to obtain a JDK 1.4 version.
>
>
> Jochen
>
>
> --
> Look, that's why there's rules, understand? So that you think before
> you break 'em.
>
> -- (Terry Pratchett, Thief of Time)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: bouncycastle in central was: Mojo for validating PGP signature
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Thu, Jul 31, 2008 at 4:43 PM, Jason van Zyl <ja...@maven.org> 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 case of a jar
file which has been processed by RetroTranslator or something similar.
The artifact with the jdk14-classifier might (for example) need
additional retrotranslator libraries. It might also need jaxp3 and
lots of other stuff thats in JDK 1.5 by default.
> 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.
Ok, but in that case I would also suggest to reconsider the "one
artifact per project" dogma. At least, I wouldn't be overly happy to
split a lot of projects into multiple just because they finally run
retrotranslator to obtain a JDK 1.4 version.
Jochen
--
Look, that's why there's rules, understand? So that you think before
you break 'em.
-- (Terry Pratchett, Thief of Time)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: bouncycastle in central was: Mojo for validating PGP signature
Posted by Stephen Connolly <st...@gmail.com>.
On Thu, Jul 31, 2008 at 6:55 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> 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 <ja...@maven.org> 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 <ja...@maven.org> 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 <br...@apache.org>:
>>>>
>>>>>
>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>> 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: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
Re: bouncycastle in central was: Mojo for validating PGP signature
Posted by Stephen Connolly <st...@gmail.com>.
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 <ja...@maven.org> 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 <ja...@maven.org> 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 <br...@apache.org>:
>>>
>>>>
>>>> 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: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>> 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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: bouncycastle in central was: Mojo for validating PGP signature
Posted by Oleg Gusakov <ol...@gmail.com>.
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
> libraries are required to be installed on the system already, even
> with a specific path in some cases.
>
> It seems like what we really need is to understand the difference
> between the dependency information contained in a project's POM and
> the rest. If you have a single project that can produce X different
> artifacts for different environmental configurations, they will all
> share the same source code and build process (when you consider that
> different profiles can be used to introduce dependencies and plugins
> into the build process as needed).
>
> However, each artifact produced from this project will serve different
> needs, and may require different dependencies of its own. In the case
> of assemblies that roll in their dependencies, for instance,
> dependency metadata should have all versions locked down to a
> single-version range and all included dependencies should be marked
> 'provided'. In the case of JDK 1.5 source that's been retrowoven (?)
> it'll have some additional dependencies.
>
> As others on this thread have even pointed out, the exact same
> artifact when consumed under a certain JDK/environment may need
> additional dependencies (like jaxb, etc.) that are provided in more
> recent JDK versions.
>
> To me, all of this points to a dire need to separate dependency
> metadata from the POM that all of these derivative artifacts shares.
> Each artifact should have its own dependency metadata, and this
> metadata needs to act more like a set of rules that will evaluate the
> environment detected or supplied to the current build, and return the
> set of transitive dependencies needed IN THAT CASE.
100% agree - dependency metadata should be freed, otherwise a simple
dependency calculator requires a full blown model builder to work, that
is not sane. And dependencies should be expressed as rules, otherwise
all it's not useful.
>
> The problem is, this could require cycling through many, many
> candidate artifacts' metadata in order to find a match. In the
> traditional way we store metadata - files - this means a lot of
> network I/O required to resolve dependencies, relative to what we have
> now. This has always been a show-stopper in my mind, at least up to now.
Even with the files and dumb https servers we can index resolution
metadata on the client - I can try to POC that in Mercury. With Nexus -
there are no limitations - all data could be indexed and available in
microseconds. Add SAT resolver on top, which can vet thousands and
thousands of candidates very effectively and I bet this is not a show
stopper any more.
>
> We now have the tooling, and precedent, to provide more complex index
> files for groups of candidate artifacts that could be downloaded and
> queried. Additionally, we might even be able to delegate this
> candidate-auditioning process to a component in the artifact-handling
> code, such that we could provide alternative implementations that
> would work directly with a repository manager for queries, instead of
> going the index-file route (which would be the default, of course). I
> don't think such an index should be maintained for a whole repository,
> but for a groupId, which is a natural domain of control for a given
> project...which allows simpler aggregating of multiple repository
> fragments without merging files.
>
Index could reside on the client and provide a maven user's view of the
world. Say - indexed dependency information for local repo releases.
With tools to maintain it, of cause.
Thanks,
Oleg
> Just some thoughts.
>
> -john
>
> 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
>> 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 <ja...@maven.org> 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 <br...@apache.org>:
>>>>>
>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>> 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: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>
>> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: repository metadata was: bouncycastle in central
Posted by Brett Porter <br...@apache.org>.
On 01/08/2008, at 3:16 AM, Benjamin Bentmann wrote:
> 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 evolves to the next model version which to my knowledge will
> prevent any Maven 2.0.x from reading such a POM, failing the build.
> Those projects that employ Maven 2.1+ will populate the repo with
> these new POMs. It would be quite frustrating for a Maven 2.0.x user
> that he cannot use the artifacts built by Maven 2.1+ as dependencies
> just because the POM format has changed. If the artifact metadata is
> separated from the POM, the POM could more freely evolve without the
> risk of breaking consumers of a dependency as long as only the
> artifact metadata model is compatible.
++1
I mentioned this is one of the challenges in changing the pom format
earlier this year (http://markmail.org/message/sbouq623fdlujmzt).
I also recall talking about this and my desire for a "repository
interchange format" when we met at JavaOne 2007 and Kenney raised the
question of classifiers. Now that the work on artifact is being picked
up it's a good time to see this added.
One POM, one main artifact, many derivatives is the right way to
describe the build, but there are plenty of cases to be more specific
in the information stored about each individual deployed artifact for
consumption purposes and to not need the tools to understand the whole
POM construction mechanism.
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: bouncycastle in central was: Mojo for validating PGP signature
Posted by Benjamin Bentmann <be...@udo.edu>.
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 evolves to the next model version which to my knowledge will prevent
any Maven 2.0.x from reading such a POM, failing the build. Those
projects that employ Maven 2.1+ will populate the repo with these new
POMs. It would be quite frustrating for a Maven 2.0.x user that he
cannot use the artifacts built by Maven 2.1+ as dependencies just
because the POM format has changed. If the artifact metadata is
separated from the POM, the POM could more freely evolve without the
risk of breaking consumers of a dependency as long as only the artifact
metadata model is compatible.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: bouncycastle in central was: Mojo for validating PGP signature
Posted by John Casey <jd...@commonjava.org>.
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 to be installed on the system already, even with a specific
path in some cases.
It seems like what we really need is to understand the difference
between the dependency information contained in a project's POM and the
rest. If you have a single project that can produce X different
artifacts for different environmental configurations, they will all
share the same source code and build process (when you consider that
different profiles can be used to introduce dependencies and plugins
into the build process as needed).
However, each artifact produced from this project will serve different
needs, and may require different dependencies of its own. In the case of
assemblies that roll in their dependencies, for instance, dependency
metadata should have all versions locked down to a single-version range
and all included dependencies should be marked 'provided'. In the case
of JDK 1.5 source that's been retrowoven (?) it'll have some additional
dependencies.
As others on this thread have even pointed out, the exact same artifact
when consumed under a certain JDK/environment may need additional
dependencies (like jaxb, etc.) that are provided in more recent JDK
versions.
To me, all of this points to a dire need to separate dependency metadata
from the POM that all of these derivative artifacts shares. Each
artifact should have its own dependency metadata, and this metadata
needs to act more like a set of rules that will evaluate the environment
detected or supplied to the current build, and return the set of
transitive dependencies needed IN THAT CASE.
The problem is, this could require cycling through many, many candidate
artifacts' metadata in order to find a match. In the traditional way we
store metadata - files - this means a lot of network I/O required to
resolve dependencies, relative to what we have now. This has always been
a show-stopper in my mind, at least up to now.
We now have the tooling, and precedent, to provide more complex index
files for groups of candidate artifacts that could be downloaded and
queried. Additionally, we might even be able to delegate this
candidate-auditioning process to a component in the artifact-handling
code, such that we could provide alternative implementations that would
work directly with a repository manager for queries, instead of going
the index-file route (which would be the default, of course). I don't
think such an index should be maintained for a whole repository, but for
a groupId, which is a natural domain of control for a given
project...which allows simpler aggregating of multiple repository
fragments without merging files.
Just some thoughts.
-john
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 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 <ja...@maven.org> 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 <br...@apache.org>:
>>>>
>>>>> 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: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>> 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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: bouncycastle in central was: Mojo for validating PGP signature
Posted by Oleg Gusakov <ol...@gmail.com>.
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 jars.
How would you treat jdk14 vs. jdk15 as classifier - one of them hits the
classpath. But I don't think they should be different IDs, do they?
What if we limit classifiers to post-testing processing only: have one
major binary product that could be post-processed into classifiers? Then
we avoid server/client/shared nightmare ..
And we must have this information recorded in some form or shape! Better
a POM per classifier with references from the main POM.
>
> 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 <ja...@maven.org> 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 <br...@apache.org>:
>>>>
>>>>> 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: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>> 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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: bouncycastle in central was: Mojo for validating PGP signature
Posted by Jason van Zyl <ja...@maven.org>.
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 <ja...@maven.org>
> 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 <br...@apache.org>:
>>>
>>>> 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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: bouncycastle in central was: Mojo for validating PGP signature
Posted by Stephen Connolly <st...@gmail.com>.
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 <ja...@maven.org> 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 <br...@apache.org>:
>>
>>> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: bouncycastle in central was: Mojo for validating PGP signature
Posted by Jason van Zyl <ja...@maven.org>.
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 <br...@apache.org>:
>> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: bouncycastle in central was: Mojo for validating PGP signature
Posted by Mark Hobson <ma...@gmail.com>.
2008/7/23 Brett Porter <br...@apache.org>:
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org