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
Hi Benjamin,
2009/7/7, Benjamin Bentmann benjamin.bentm...@udo.edu:
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
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
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 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
Hi,
On Tue, Jul 7, 2009 at 5:42 PM, Daniel Kulpdk...@apache.org 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
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
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 c...@schulte.it:
Hi,
a few weeks ago I contributed a maven-jarsigner-plugin which got
committed to the maven
how about host it at Jlint at sourceforge?
-D
On Wed, Jul 8, 2009 at 11:35 AM, Freddy Malletfreddy.mal...@gmail.com 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
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
AFAIK, repository and pluginRepository 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 repository or
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.
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
Benjamin is right, if you rebuild something it should be under your groupId
On Wed, Jul 8, 2009 at 1:13 PM, Benjamin
Bentmannbenjamin.bentm...@udo.edu 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
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
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 HERITIERaherit...@gmail.com wrote:
But it creates many issues to resolve
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
we really need some sort of
provides
groupIdlog4jgroupId
artifactIdlog4j/artifactId
version[1.2.5,1.3)/version
/provides
another option would be to add a new scope, e.g. implemented
dependency
groupIdlog4jgroupId
artifactIdlog4j/artifactId
version[1.2.5,1.3)/version
other possible names for the scope could be encapsulated, or bundled
2009/7/8 Stephen Connolly stephen.alan.conno...@gmail.com:
we really need some sort of
provides
groupIdlog4jgroupId
artifactIdlog4j/artifactId
version[1.2.5,1.3)/version
/provides
another option would be to add a new
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,
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
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
Connollystephen.alan.conno...@gmail.com wrote:
Hmmm, how would this work
2009/7/8 Stephen Connolly stephen.alan.conno...@gmail.com:
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
On Wed, Jul 8, 2009 at 10:23 PM, Daniel Kulp dk...@apache.org 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
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 :
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
Tirunagaridurga.tirunag...@sun.com wrote:
can one of
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
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 Gierpg...@redhat.com wrote:
Daniel Kulp wrote:
On Wed July 8 2009 4:13:24 pm Benjamin Bentmann
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
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 stephen.alan.conno...@gmail.com
1. maintain the ability for a user to checkout your code and run mvn
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 bri...@infinity.nu
To: Maven Developers List dev@maven.apache.org
Sent: Wed Jul 08 17:36:55 2009
Subject: Re:
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.
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
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 jvan...@sonatype.com
To: Maven Developers List
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:
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):
36 matches
Mail list logo
