Hi Durga,
I think your information is bad. I and most the people on this list
don't have admin on this list -- seems the list is related to Codehaus
which is a different organization like Eclipse or Java.net.
Try clicking this link (hoping your email client makes it clickable):
mailto:d
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
Note that even changing the pom (say the dependency section, but really anythng
in the pom) is enough to trigger the need for a version change even if the jars
remain untouched.
Stan
- Original Message -
From: Jason van Zyl
To: Maven Developers List
Sent: Wed Jul 08 20:58:43 2009
Subj
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 it is much easier to make
the change to use the updated libr
Paul,
Does JBoss never intend to get the patches back to the respective OSS
projects? You plan to maintain these forks indefinitely?
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
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
BT
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
you have to send emails to
dev-unsubscribe-durga.tirunagari=sun@maven.apache.org
issues-unsubscribe-durga.tirunagari=sun@maven.apache.org
...and so on for the lists you are subscribed to
On Wed, Jul 8, 2009 at 2:12 PM, Durga Deep
Tirunagari wrote:
> can one of the people listed in here
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
can one of the people listed in here ( with no clickable e-mail
address ). Remove me from this user list ?
E-mail (durga.tirunag...@sun.com )
http://jira.codehaus.org/secure/Administrators.jspa
System Administrators
Here is the list of system administrators for this installation of JIRA.
Sy
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
how about host it at Jlint at sourceforge?
-D
On Wed, Jul 8, 2009 at 11:35 AM, Freddy Mallet wrote:
> Hi Christopher,
>
> I also suggest you to join the Mojo project as you'll use the same Codehaus
> infrastructure to support your Sonar Jlint plugin and your Maven Jlint
> plugin. When you'll send
If you are a mojo committer, call a vote to promote out of sandbox.
If you are not a mojo committer, find a mojo committer willing to call a vote
-Stephen
2009/7/8 Christian Schulte :
> Hi,
>
> a few weeks ago I contributed a maven-jarsigner-plugin which got
> committed to the maven sandbox. Tha
Hi Christopher,
I also suggest you to join the Mojo project as you'll use the same Codehaus
infrastructure to support your Sonar Jlint plugin and your Maven Jlint
plugin. When you'll send your request to the Mojo dev mailing list, mention
that you're already a contributor on the Sonar plugins proj
Hi,
On Tue, Jul 7, 2009 at 5:42 PM, Daniel Kulp wrote:
> The text on the apache legal page states:
> http://www.apache.org/legal/src-headers.html#notice
>
> The top of each NOTICE file should include the following text, suitably
> modified to reflect the product name and year(s) of distribution of
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
Hi,
I have written a patch for plexus ConsoleLogger (PLX-421) so that Maven's
output are colorized if you are using a pseud-terminal and have set the
system property 'colorized.console' to 'true'. This could provides a
solution to http://jira.codehaus.org/browse/MNG-3507.
Emmanuel
Hi,
a few weeks ago I contributed a maven-jarsigner-plugin which got
committed to the maven sandbox. That plugin is meant to become the
successor for the maven-jar-plugin:sign goal which does not support
signing sources jar, javadoc jar or any other java capable artifact
attached to a project. I a
Hi Benjamin,
2009/7/7, Benjamin Bentmann :
> Why not simply pass the MAVEN_OPTS from the current process through to the
> forked one (this should be the default behavior IIRC)? Otherwise I would
Well, I was not aware of this default behaviour...but I think it is
enough from an user point of view
Hi Christopher,
I have developed a maven plugin for Jlint 3.1 and want to contribute the
plugin code back to the maven project. [...]
Can someone please point me to any instructions related to this.
Probably best to try and contribute the code to the Mojo project that
already hosts a bunch o
36 matches
Mail list logo
