n - all you have is version number to play with.
>
> Stan
>
>
>
> -Original Message-
> From: Paul Gier [mailto:pg...@redhat.com]
> Sent: Thursday, July 09, 2009 11:54 AM
> To: Maven Developers List
> Subject: Re: Depending on Artifacts not in central
>
&g
coordinate sets were really the same up to version number ?
Until then - all you have is version number to play with.
Stan
-Original Message-
From: Paul Gier [mailto:pg...@redhat.com]
Sent: Thursday, July 09, 2009 11:54 AM
To: Maven Developers List
Subject: Re: Depending on Artifacts not in
x
To: Maven Developers List
Sent: Wed Jul 08 17:36:55 2009
Subject: Re: Depending on Artifacts not in central
BTW, we already wrote a proposal on this that got relatively little
feedback:
http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repository+discovery
On Wed, Jul 8, 2009 at 5:
ndency tree.
Stan
- Original Message -
From: Brian Fox
To: Maven Developers List
Sent: Wed Jul 08 17:36:55 2009
Subject: Re: Depending on Artifacts not in central
BTW, we already wrote a proposal on this that got relatively little
feedback:
http://docs.codehaus.org/display/MAVEN/Art
Arnaud HERITIER schrieb:
> For the repository constraint I agree.But what can we recommend to jboss and
> others company which have this need to be a good maven citizen ?
> I'll have the same issue soon with my company exoplatform.
> We are interested to deploy nexus and push some of our artifacts
We could have this also for mirrors.Another thing we could have in mirror
definition is to say if this is for releases, snapshots or both.
Arnaud
On Thu, Jul 9, 2009 at 4:13 PM, Daniel Kulp wrote:
>
> I've long thought that the entry in the poms (or wherever it
> moves to) and mirrors in sett
I've long thought that the entry in the poms (or wherever it
moves to) and mirrors in settings.xml should have some sort of "filters" on
it. Like:
java.net
http://download.java.net/maven/1/
com.sun.*:*
javax.xml.*:*
That would allow limiting sear
Here is some feedback on
http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repositor
y+discovery
Of the 4 requirements listed:
1. ability to checkout and build with no prior setup (extremely
important)
3. separate plugin dependency resolution from project dependency
On 09/07/2009, at 7:36 AM, Brian Fox wrote:
BTW, we already wrote a proposal on this that got relatively little
feedback:
http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repository+discovery
In case it got drowned out:
http://mail-archives.apache.org/mod_mbox/maven-dev/200907
Subject: Re: Depending on Artifacts not in central
On 8-Jul-09, at 6:57 PM, Stan Devitt wrote:
> The only thing that halfway works for rebuilt / modified artifacts
> is to modify the version number (e.g. 3.5-mod-by-NameOModifier).
>
I agree.
As once the patches reach the OSS project i
eased version someone has signed and then becomes your
responsibility. If you break it, you buy it. You rebuild it, you own it.
Stan
- Original Message -
From: Brian Fox
To: Maven Developers List
Sent: Wed Jul 08 17:36:55 2009
Subject: Re: Depending on Artifacts not in central
BTW, we al
-mod-by-NameOModifier).
Stan
- Original Message -
From: Brian Fox
To: Maven Developers List
Sent: Wed Jul 08 17:36:55 2009
Subject: Re: Depending on Artifacts not in central
BTW, we already wrote a proposal on this that got relatively little
feedback:
http://docs.codehaus.org/display
The only thing that halfway works for rebuilt / modified artifacts is to modify
the version number (e.g. 3.5-mod-by-NameOModifier).
Stan
- Original Message -
From: Brian Fox
To: Maven Developers List
Sent: Wed Jul 08 17:36:55 2009
Subject: Re: Depending on Artifacts not in central
A solution I am tending towards is a repositories.xml file adjacent to the
pom.xml
This covers #1 and makes #2 redundant
#3 and #4 are separate issues IMHO
2009/7/8 Stephen Connolly
>
>>1. maintain the ability for a user to checkout your code and run mvn
>>install and have it work with
>
>
>1. maintain the ability for a user to checkout your code and run mvn
>install and have it work with no prior setup on their part.
>
> Hmmm... there are +++'s and ---'s with this one
>
>1.
>2. be able to depend on some jar and not worry about any repositories
>required for
BTW, we already wrote a proposal on this that got relatively little
feedback:
http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repository+discovery
On Wed, Jul 8, 2009 at 5:29 PM, Paul Gier wrote:
> Daniel Kulp wrote:
>>
>> On Wed July 8 2009 4:13:24 pm Benjamin Bentmann wrote:
>>>
Daniel Kulp wrote:
On Wed July 8 2009 4:13:24 pm Benjamin Bentmann wrote:
Paul Gier wrote:
One issue that will need to be resolved before we can sync, is how to
handle our rebuilt thirdparty jars. For example, if a jboss project
needs to patch some thirdparty jar, rebuild it, and upload it to
For the repository constraint I agree.But what can we recommend to jboss and
others company which have this need to be a good maven citizen ?
I'll have the same issue soon with my company exoplatform.
We are interested to deploy nexus and push some of our artifacts in central
but what to do with :
On Wed, Jul 8, 2009 at 10:23 PM, Daniel Kulp wrote:
> On Wed July 8 2009 4:13:24 pm Benjamin Bentmann wrote:
> > Paul Gier wrote:
> > > One issue that will need to be resolved before we can sync, is how to
> > > handle our rebuilt thirdparty jars. For example, if a jboss project
> > > needs to p
2009/7/8 Stephen Connolly :
> OK, a problem...
>
> what if I have both org.jboss.thirdparty:log4j *and*
> com.sun.thirdparty:log4j on my classpath?
>
> we have to give a warning of some sort... perhaps fail the build and
> let the user resolve this through exclusions
>
> in this regard a scope
see MNG-2316 about handling this issue, it has been there for a long time
but talking about the repository it is impossible for jboss to publish
their builds under the log4j group
On Wed, Jul 8, 2009 at 1:43 PM, Stephen
Connolly wrote:
> Hmmm, how would this work w.r.t. resolving...
>
> If I add
OK, a problem...
what if I have both org.jboss.thirdparty:log4j *and*
com.sun.thirdparty:log4j on my classpath?
we have to give a warning of some sort... perhaps fail the build and
let the user resolve this through exclusions
in this regard a scope of "relocation" might be better... as we wo
Hmmm, how would this work w.r.t. resolving...
If I add log4j:log4j and org.jboss.thirdparty:log4j as dependencies,
then I would get both artifacts on my classpath with a warning from
Maven.
If I add log4j:log4j as a direct, and org.jboss.thirdparty:log4j as a
transitive via another dependency, th
other possible names for the scope could be "encapsulated", or "bundled"
2009/7/8 Stephen Connolly :
> we really need some sort of
>
>
> log4j
> log4j
> [1.2.5,1.3)
>
>
> another option would be to add a new scope, e.g. implemented
>
>
> log4j
> log4j
> [1.2.5,1.3)
> implemented
>
>
> t
we really need some sort of
log4j
log4j
[1.2.5,1.3)
another option would be to add a new scope, e.g. implemented
log4j
log4j
[1.2.5,1.3)
implemented
that way we can filter out any artifacts which are implemented from the tree...
e.g.
if I depend on org.jboss.thirdparty:log4j
On Wed July 8 2009 4:13:24 pm Benjamin Bentmann wrote:
> Paul Gier wrote:
> > One issue that will need to be resolved before we can sync, is how to
> > handle our rebuilt thirdparty jars. For example, if a jboss project
> > needs to patch some thirdparty jar, rebuild it, and upload it to our
> > r
if they rebuild it then it must have something different and they
would need to handle the differences in some way.
I can't imagine they rebuild the jars just for the sake of doing it.
On Wed, Jul 8, 2009 at 1:18 PM, Arnaud HERITIER wrote:
> But it creates many issues to resolve transitive depende
But it creates many issues to resolve transitive dependencies. With that you
can have in a tree org.jboss.log4j:log4j:1.2.36 and log4j:log4j:1.2.12Is it
working fine if in the pom of org.jboss.log4j:log4j:1.2.36 we set a
relocation ? Can it have some others impacts ?
Arnaud
On Wed, Jul 8, 2009
Benjamin is right, if you rebuild something it should be under your groupId
On Wed, Jul 8, 2009 at 1:13 PM, Benjamin
Bentmann wrote:
> Paul Gier wrote:
>
>> One issue that will need to be resolved before we can sync, is how to
>> handle our rebuilt thirdparty jars. For example, if a jboss projec
Paul Gier wrote:
One issue that will need to be resolved before we can sync, is how to
handle our rebuilt thirdparty jars. For example, if a jboss project
needs to patch some thirdparty jar, rebuild it, and upload it to our
repository
AFAIK, somebody building a patched third-party artifact
As far as the JBoss stuff in central, we've been trying to get automatic
synching going between repositories for a while. The artifacts that are there
now were uploaded manually. The synching will probably happen someday, but
jboss.org is undergoing a long painful migration process and the rep
AFAIK, and entries are banned from
artifacts published to central (unless they are for snapshots only, or
unless they are in an inactive by default profile)
I do not think anything is enforcing this ban though.
I would agree with this policy. Having or
definitions in a pom.xml can have a mas
Hi Everyone
I recently found out that the buildhelper-maven-plugin has a transitive
dependency not located in the central maven repository (MOJO-1401). This causes
problems with a strict repository setup (using mirror settings, etc). But most
users probably don't notice this because the depe
33 matches
Mail list logo
