Re: Please UnSubscribe
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:dev-unsubscr...@maven.apache.org
If you send it from the email address you listed it *should* work.
Don't need to fill in anything special for the subject or body.
Hope this helps!
-David
On Jul 8, 2009, at 11:42 AM, Durga Deep Tirunagari wrote:
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.
System Administrators have complete administrative rights including
permission to manage underlying JIRA system configuration such as
backups and services.
* Alan Cabrera
* Andrew Eisenberg
* Arnaud Heritier
* Ben Walding
* bob mcwhirter
* Brett Porter
* Brian Topping
* Bruce Snyder
* Contegix Support
* Dain Sundstrom
* Dan Diephouse
* Dan North
* David Blevins
* Dennis Lundberg
* Edward Povazan
* Emmanuel Venisse
* Eugene Kuleshov
* Guillaume Laforge
* Jacques Morel
* James E. Ervin
* James Macgill
* Jason Dillon
* Jason van Zyl
* Jody Garnett
* Paul Hammant
* Peter Donald
* peter royal
* Rodrigo B. de Oliveira
* Scott Farquhar
* Trygve Laugstol
* Vincent Massol
* Werner Guttmann
* Xircles System User
Thanks a bunch
On Jul 8, 2009, at 11:38 AM, Benjamin Bentmann (JIRA) wrote:
[ http://jira.codehaus.org/browse/MNG-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=182983#action_182983
]
Benjamin Bentmann commented on MNG-4232:
In which file exactly does this substitution happen? In the POM or
in some resource file? Could you provide an example project to
demonstrate this?
Property substitution of ${project.build.directory} on Windows FAILS
Key: MNG-4232
URL: http://jira.codehaus.org/browse/MNG-4232
Project: Maven 2
Issue Type: Bug
Components: Bootstrap & Build
Affects Versions: 2.2.0
Environment: Windows XP 32 bits
Reporter: Rodolfo Rothganger
For a project target directory on C:\project\target, the maven
build substitutes the project property ${project.build.directory}
with c\:\\project\\target. The c\:\\ should be c:\\
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
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.mbox/%3c415cc13b-4f80-4782-9a0f-5f0051a93...@apache.org%3e - Brett - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
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 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 it is much easier to make the change to use the updated library. Paul, but do you rebuild the whole transitive chain? If you actually rebuild everything -- which I though was your policy -- then you are really the maintainer of the transitive chain for your users. Even if you take a tag and rebuild it yourself you've tampered with a released 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 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: 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 is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. >>> >>> Except there THEN becomes the issue if someone depends on the >>> normal log4j >>> artifact as well as some JBoss artifact that then transitively >>> pulls in >>> org.jboss:log4j, they end up with two versions of log4j on the >>> classpath >>> with all kinds of non-fun things happening. >>> >>> Dan >>> >> >> Yes, this is the major problem that we would have with changing the >> groupId >> for rebuilt artifacts. It works fine for small projects, but for a >> large >> dependency tree it is currently a big hassle to try to track down and >> exclude every place where the original groupId/artifactId is included >> transitively. >> >> Allowing some kind of global exclusions would be a good start >> (MNG-1977, >> MNG-3196). We currently use the enforcer plugin, but I still have >> to add in >> exclusions every time the same dependency is reintroduced in a new >> location >> in the tree. Also, anyone depending on the JBoss project might >> then have to >> add exclusions to their projects to get only the correct >> dependencies. >> >> But ideally there would be some way to link groupId:artifactId >> combinations >> as suggested by Stephen and Carlos. This would also help resolve >> artifacts >> that are renamed between versions which happens occasionally. Is >> there any >> work to handle this use case in Mercury? >> >>> Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > > - > This transmission (including any attachments) may contain > confidential information, privileged material (including material > protected by the solicitor-client or other applicable privileges), > or constitute non-public information. Any use of this information by > anyone other than the intended recipient is prohibited. If you have > received this transmission in error, please immediately reply to the > sender and delete this information from your system. Use, > dissemination, distribution, or reproduction of this transmission by > unintended recipients is not authorized and may be unlawful. > > -
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 it is much easier to make the change to use the updated library. Paul, but do you rebuild the whole transitive chain? If you actually rebuild everything -- which I though was your policy -- then you are really the maintainer of the transitive chain for your users. Even if you take a tag and rebuild it yourself you've tampered with a released 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 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: 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 is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. Except there THEN becomes the issue if someone depends on the normal log4j artifact as well as some JBoss artifact that then transitively pulls in org.jboss:log4j, they end up with two versions of log4j on the classpath with all kinds of non-fun things happening. Dan Yes, this is the major problem that we would have with changing the groupId for rebuilt artifacts. It works fine for small projects, but for a large dependency tree it is currently a big hassle to try to track down and exclude every place where the original groupId/artifactId is included transitively. Allowing some kind of global exclusions would be a good start (MNG-1977, MNG-3196). We currently use the enforcer plugin, but I still have to add in exclusions every time the same dependency is reintroduced in a new location in the tree. Also, anyone depending on the JBoss project might then have to add exclusions to their projects to get only the correct dependencies. But ideally there would be some way to link groupId:artifactId combinations as suggested by Stephen and Carlos. This would also help resolve artifacts that are renamed between versions which happens occasionally. Is there any work to handle this use case in Mercury? Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/SonatypeNexus http://twitter.com/SonatypeM2E -- You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow
Re: Depending on Artifacts not in central
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-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/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: 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 is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. Except there THEN becomes the issue if someone depends on the normal log4j artifact as well as some JBoss artifact that then transitively pulls in org.jboss:log4j, they end up with two versions of log4j on the classpath with all kinds of non-fun things happening. Dan Yes, this is the major problem that we would have with changing the groupId for rebuilt artifacts. It works fine for small projects, but for a large dependency tree it is currently a big hassle to try to track down and exclude every place where the original groupId/artifactId is included transitively. Allowing some kind of global exclusions would be a good start (MNG-1977, MNG-3196). We currently use the enforcer plugin, but I still have to add in exclusions every time the same dependency is reintroduced in a new location in the tree. Also, anyone depending on the JBoss project might then have to add exclusions to their projects to get only the correct dependencies. But ideally there would be some way to link groupId:artifactId combinations as suggested by Stephen and Carlos. This would also help resolve artifacts that are renamed between versions which happens occasionally. Is there any work to handle this use case in Mercury? Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/SonatypeNexus http://twitter.com/SonatypeM2E -- the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
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 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: >>> >>> 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 is supposed to >>> not deploy this derived artifact with its original group id but with the >>> group id of the patch creator. So if JBoss creates a patched version of >>> say log4j, it would need to get deployed with org.jboss:log4j or >>> similar. This should be allowed to get synced into central as it can be >>> distinguished from the original log4j:log4j artifact of the project >>> owner. >> >> Except there THEN becomes the issue if someone depends on the normal log4j >> artifact as well as some JBoss artifact that then transitively pulls in >> org.jboss:log4j, they end up with two versions of log4j on the classpath >> with all kinds of non-fun things happening. >> >> Dan >> > > Yes, this is the major problem that we would have with changing the groupId > for rebuilt artifacts. It works fine for small projects, but for a large > dependency tree it is currently a big hassle to try to track down and > exclude every place where the original groupId/artifactId is included > transitively. > > Allowing some kind of global exclusions would be a good start (MNG-1977, > MNG-3196). We currently use the enforcer plugin, but I still have to add in > exclusions every time the same dependency is reintroduced in a new location > in the tree. Also, anyone depending on the JBoss project might then have to > add exclusions to their projects to get only the correct dependencies. > > But ideally there would be some way to link groupId:artifactId combinations > as suggested by Stephen and Carlos. This would also help resolve artifacts > that are renamed between versions which happens occasionally. Is there any > work to handle this use case in Mercury? > >> >>> >>> Benjamin >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
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 no prior setup on their part. >> >> Hmmm... there are +++'s and ---'s with this one > I see this as a separate problem from repositories in the pom > > >>1. >>2. be able to depend on some jar and not worry about any repositories >>required for transitive resolution (ie discover the repositories >>transitively as dependencies are processed) *(this is controversial >>and may be eliminated. First it contributes to the Problem #4 above in >> that >>SAT can't be done on a bounded list of repositories. It also doesn't work >>normally behind a repository manager because the list of repos is usually >>controlled in the repo manager and thus autodiscovery is intentionally >>blocked, usually via a mirrorOf * to circumvent the repos maven finds in >> the >>poms.)* >> >> Not sure i agree with this one > I think this is a bad plan. It's your build, you specify where dependencies can come from. If somebody else depends on your artifact, they specify where dependencies can come from. We should provide tools to make it easy for them to grab the repos you specified (assuming they trust you ;-) ) > > >>1. ** >>2. be able to separate the dependencies needed by maven plugins from >>those needed by the build. This means not only where they are resolved >> from, >>but also how they are stored locally to prevent cross-contamination. >> >> I am less convinced this is necessary these days... better is separation > of repo caches in local > >> >>1. >>2. Repository identification: at this point we are pretty much in >>agreement that the URL should be the unique identifier for a repository. >>People who care about what they are publishing either need to use >> canonical >>repositories like Maven central or need to guarantee the existence of the >>repositories or have decent pointers. In a fully distributed system the >>relocation mechanism we have does not work in a fully distributed system >>without a master to manage relocations. >> >> +1 > > > 2009/7/8 Brian Fox : > > > 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: > > 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 is supposed to > not deploy this derived artifact with its original group id but with > the > group id of the patch creator. So if JBoss creates a patched version > of > say log4j, it would need to get deployed with org.jboss:log4j or > similar. This should be allowed to get synced into central as it can > be > distinguished from the original log4j:log4j artifact of the project > owner. > >>> > >>> Except there THEN becomes the issue if someone depends on the normal > log4j > >>> artifact as well as some JBoss artifact that then transitively pulls in > >>> org.jboss:log4j, they end up with two versions of log4j on the > classpath > >>> with all kinds of non-fun things happening. > >>> > >>> Dan > >>> > >> > >> Yes, this is the major problem that we would have with changing the > groupId > >> for rebuilt artifacts. It works fine for small projects, but for a > large > >> dependency tree it is currently a big hassle to try to track down and > >> exclude every place where the original groupId/artifactId is included > >> transitively. > >> > >> Allowing some kind of global exclusions would be a good start (MNG-1977, > >> MNG-3196). We currently use the enforcer plugin, but I still have to > add in > >> exclusions every time the same dependency is reintroduced in a new > location > >> in the tree. Also, anyone depending on the JBoss project might then > have to > >> add exclusions to their projects to get only the correct dependencies. > >> > >> But ideally there would be some way to link groupId:artifactId > combinations > >> as suggested by Stephen and Carlos. This would also help resolve > artifacts > >> that are renamed between versions which happens occasionally. Is there > any > >> work to handle this use case in Mercury? > >> > >>> > > Benjamin > > - > To unsubscribe, e-mail: dev-uns
Re: Depending on Artifacts not in central
> > >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 transitive resolution (ie discover the repositories >transitively as dependencies are processed) *(this is controversial and >may be eliminated. First it contributes to the Problem #4 above in that SAT >can't be done on a bounded list of repositories. It also doesn't work >normally behind a repository manager because the list of repos is usually >controlled in the repo manager and thus autodiscovery is intentionally >blocked, usually via a mirrorOf * to circumvent the repos maven finds in > the >poms.)* > > Not sure i agree with this one > >1. ** >2. be able to separate the dependencies needed by maven plugins from >those needed by the build. This means not only where they are resolved > from, >but also how they are stored locally to prevent cross-contamination. > > I am less convinced this is necessary these days... better is separation of repo caches in local > >1. >2. Repository identification: at this point we are pretty much in >agreement that the URL should be the unique identifier for a repository. >People who care about what they are publishing either need to use canonical >repositories like Maven central or need to guarantee the existence of the >repositories or have decent pointers. In a fully distributed system the >relocation mechanism we have does not work in a fully distributed system >without a master to manage relocations. > > +1 2009/7/8 Brian Fox : > 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: 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 is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. >>> >>> Except there THEN becomes the issue if someone depends on the normal log4j >>> artifact as well as some JBoss artifact that then transitively pulls in >>> org.jboss:log4j, they end up with two versions of log4j on the classpath >>> with all kinds of non-fun things happening. >>> >>> Dan >>> >> >> Yes, this is the major problem that we would have with changing the groupId >> for rebuilt artifacts. It works fine for small projects, but for a large >> dependency tree it is currently a big hassle to try to track down and >> exclude every place where the original groupId/artifactId is included >> transitively. >> >> Allowing some kind of global exclusions would be a good start (MNG-1977, >> MNG-3196). We currently use the enforcer plugin, but I still have to add in >> exclusions every time the same dependency is reintroduced in a new location >> in the tree. Also, anyone depending on the JBoss project might then have to >> add exclusions to their projects to get only the correct dependencies. >> >> But ideally there would be some way to link groupId:artifactId combinations >> as suggested by Stephen and Carlos. This would also help resolve artifacts >> that are renamed between versions which happens occasionally. Is there any >> work to handle this use case in Mercury? >> >>> Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
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:29 PM, Paul Gier 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 our repository >>> >>> AFAIK, somebody building a patched third-party artifact is supposed to >>> not deploy this derived artifact with its original group id but with the >>> group id of the patch creator. So if JBoss creates a patched version of >>> say log4j, it would need to get deployed with org.jboss:log4j or >>> similar. This should be allowed to get synced into central as it can be >>> distinguished from the original log4j:log4j artifact of the project >>> owner. >> >> Except there THEN becomes the issue if someone depends on the normal log4j >> artifact as well as some JBoss artifact that then transitively pulls in >> org.jboss:log4j, they end up with two versions of log4j on the classpath >> with all kinds of non-fun things happening. >> >> Dan >> > > Yes, this is the major problem that we would have with changing the groupId > for rebuilt artifacts. It works fine for small projects, but for a large > dependency tree it is currently a big hassle to try to track down and > exclude every place where the original groupId/artifactId is included > transitively. > > Allowing some kind of global exclusions would be a good start (MNG-1977, > MNG-3196). We currently use the enforcer plugin, but I still have to add in > exclusions every time the same dependency is reintroduced in a new location > in the tree. Also, anyone depending on the JBoss project might then have to > add exclusions to their projects to get only the correct dependencies. > > But ideally there would be some way to link groupId:artifactId combinations > as suggested by Stephen and Carlos. This would also help resolve artifacts > that are renamed between versions which happens occasionally. Is there any > work to handle this use case in Mercury? > >> >>> >>> Benjamin >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
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 our repository AFAIK, somebody building a patched third-party artifact is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. Except there THEN becomes the issue if someone depends on the normal log4j artifact as well as some JBoss artifact that then transitively pulls in org.jboss:log4j, they end up with two versions of log4j on the classpath with all kinds of non-fun things happening. Dan Yes, this is the major problem that we would have with changing the groupId for rebuilt artifacts. It works fine for small projects, but for a large dependency tree it is currently a big hassle to try to track down and exclude every place where the original groupId/artifactId is included transitively. Allowing some kind of global exclusions would be a good start (MNG-1977, MNG-3196). We currently use the enforcer plugin, but I still have to add in exclusions every time the same dependency is reintroduced in a new location in the tree. Also, anyone depending on the JBoss project might then have to add exclusions to their projects to get only the correct dependencies. But ideally there would be some way to link groupId:artifactId combinations as suggested by Stephen and Carlos. This would also help resolve artifacts that are renamed between versions which happens occasionally. Is there any work to handle this use case in Mercury? Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [jira] Closed: (MAVENUPLOAD-2464) Please upload Clojure 1.0.0
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 ( 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. > > System Administrators have complete administrative rights including > permission to manage underlying JIRA system configuration such as backups > and services. > > * Alan Cabrera > * Andrew Eisenberg > * Arnaud Heritier > * Ben Walding > * bob mcwhirter > * Brett Porter > * Brian Topping > * Bruce Snyder > * Contegix Support > * Dain Sundstrom > * Dan Diephouse > * Dan North > * David Blevins > * Dennis Lundberg > * Edward Povazan > * Emmanuel Venisse > * Eugene Kuleshov > * Guillaume Laforge > * Jacques Morel > * James E. Ervin > * James Macgill > * Jason Dillon > * Jason van Zyl > * Jody Garnett > * Paul Hammant > * Peter Donald > * peter royal > * Rodrigo B. de Oliveira > * Scott Farquhar > * Trygve Laugstol > * Vincent Massol > * Werner Guttmann > * Xircles System User > > Thanks a bunch > On Jul 8, 2009, at 1:26 PM, Carlos Sanchez (JIRA) wrote: > >> >> [ >> http://jira.codehaus.org/browse/MAVENUPLOAD-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] >> >> Carlos Sanchez closed MAVENUPLOAD-2464. >> --- >> >> Assignee: Carlos Sanchez >> Resolution: Fixed >> >>> Please upload Clojure 1.0.0 >>> --- >>> >>> Key: MAVENUPLOAD-2464 >>> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2464 >>> Project: Maven Upload Requests >>> Issue Type: Wish >>> Reporter: Stefan Hübner >>> Assignee: Carlos Sanchez >>> >>> Please upload Clojure 1.0.0 to Maven Central. The bundle contains the >>> following files: >>> - pom.xml >>> - clojure-1.0.0.jar >>> - clojure-1.0.0-slim.jar (variant of clojure-1.0.0.jar without >>> precompiled Lisp sources) >>> - clojure-1.0.0-sources.jar >>> The Clojure project lives at http://clojure.org which is owned by >>> Clojure's creator Rich Hickey (see >>> http://whois.domaintools.com/clojure.org). >>> I'm submitting this bundle on behalf of the Clojure community (see this >>> thread: >>> http://groups.google.com/group/clojure/browse_thread/thread/fd538f118613cbbf). >>> Thank you, >>> Stefan Hübner >> >> -- >> This message is automatically generated by JIRA. >> - >> If you think it was sent incorrectly contact one of the administrators: >> http://jira.codehaus.org/secure/Administrators.jspa >> - >> For more information on JIRA, see: http://www.atlassian.com/software/jira >> >> > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
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 : - artifacts deployed on repositories not synched with central (java.net & co) - modified oss libraires Cheers, Arnaud # Arnaud Héritier # Software Factory Manager # eXo Platform # http://www.exoplatform.com # http://blog.aheritier.net On Wed, Jul 8, 2009 at 10:46 PM, Carlos Sanchez wrote: > 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 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, then I get both artitfacts and > > Maven would print a warning > > > > If I add org.jboss.thirdparty:log4j as a direct, and log4j:log4j as a > > transitive via another dependency, then I get only > > org.jboss.thirdparty:log4j as the transitive dependency has already > > been provided by a nearer dependency > > > > > > 2009/7/8 Stephen Connolly : > >> 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 > >>> > >>> > >>> that way we can filter out any artifacts which are implemented from the > tree... > >>> > >>> e.g. > >>> > >>> if I depend on org.jboss.thirdparty:log4j > >>> > >>> Maven 2.3.0+, 3.0.0+ can see that this implements log4j:log4j, so that > >>> it does not need to be pulled in via transative dependencies > >>> > >>> 2009/7/8 Daniel Kulp : > 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 > > > repository > > > > AFAIK, somebody building a patched third-party artifact is supposed > to > > not deploy this derived artifact with its original group id but with > the > > group id of the patch creator. So if JBoss creates a patched version > of > > say log4j, it would need to get deployed with org.jboss:log4j or > > similar. This should be allowed to get synced into central as it can > be > > distinguished from the original log4j:log4j artifact of the project > owner. > > Except there THEN becomes the issue if someone depends on the normal > log4j > artifact as well as some JBoss artifact that then transitively pulls > in > org.jboss:log4j, they end up with two versions of log4j on the > classpath with > all kinds of non-fun things happening. > > Dan > > > > > > > > Benjamin > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > -- > Daniel Kulp > dk...@apache.org > http://www.dankulp.com/blog > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > > >>> > >> > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Depending on Artifacts not in central
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 patch some thirdparty jar, rebuild it, and upload it to our > > > repository > > > > AFAIK, somebody building a patched third-party artifact is supposed to > > not deploy this derived artifact with its original group id but with the > > group id of the patch creator. So if JBoss creates a patched version of > > say log4j, it would need to get deployed with org.jboss:log4j or > > similar. This should be allowed to get synced into central as it can be > > distinguished from the original log4j:log4j artifact of the project > owner. > > Except there THEN becomes the issue if someone depends on the normal log4j > artifact as well as some JBoss artifact that then transitively pulls in > org.jboss:log4j, they end up with two versions of log4j on the classpath > with > all kinds of non-fun things happening. > > Dan yes it was the case I had in mind Arnaud
Re: Depending on Artifacts not in central
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 of "relocation" might be better... as we would > not want people "bundling" several artifacts into the one artifact. > Or we could blow up the build if you try to have more than one "implements" scope dependency in any one project... that'll solve it! > 2009/7/8 Stephen Connolly : >> 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, then I get both artitfacts and >> Maven would print a warning >> >> If I add org.jboss.thirdparty:log4j as a direct, and log4j:log4j as a >> transitive via another dependency, then I get only >> org.jboss.thirdparty:log4j as the transitive dependency has already >> been provided by a nearer dependency >> >> >> 2009/7/8 Stephen Connolly : >>> 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 that way we can filter out any artifacts which are implemented from the tree... e.g. if I depend on org.jboss.thirdparty:log4j Maven 2.3.0+, 3.0.0+ can see that this implements log4j:log4j, so that it does not need to be pulled in via transative dependencies 2009/7/8 Daniel Kulp : > 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 >> > repository >> >> AFAIK, somebody building a patched third-party artifact is supposed to >> not deploy this derived artifact with its original group id but with the >> group id of the patch creator. So if JBoss creates a patched version of >> say log4j, it would need to get deployed with org.jboss:log4j or >> similar. This should be allowed to get synced into central as it can be >> distinguished from the original log4j:log4j artifact of the project >> owner. > > Except there THEN becomes the issue if someone depends on the normal log4j > artifact as well as some JBoss artifact that then transitively pulls in > org.jboss:log4j, they end up with two versions of log4j on the classpath > with > all kinds of non-fun things happening. > > Dan > > >> >> >> Benjamin >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org > > -- > Daniel Kulp > dk...@apache.org > http://www.dankulp.com/blog > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > >>> >> > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
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 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, then I get both artitfacts and > Maven would print a warning > > If I add org.jboss.thirdparty:log4j as a direct, and log4j:log4j as a > transitive via another dependency, then I get only > org.jboss.thirdparty:log4j as the transitive dependency has already > been provided by a nearer dependency > > > 2009/7/8 Stephen Connolly : >> 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 >>> >>> >>> that way we can filter out any artifacts which are implemented from the >>> tree... >>> >>> e.g. >>> >>> if I depend on org.jboss.thirdparty:log4j >>> >>> Maven 2.3.0+, 3.0.0+ can see that this implements log4j:log4j, so that >>> it does not need to be pulled in via transative dependencies >>> >>> 2009/7/8 Daniel Kulp : 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 > > repository > > AFAIK, somebody building a patched third-party artifact is supposed to > not deploy this derived artifact with its original group id but with the > group id of the patch creator. So if JBoss creates a patched version of > say log4j, it would need to get deployed with org.jboss:log4j or > similar. This should be allowed to get synced into central as it can be > distinguished from the original log4j:log4j artifact of the project owner. Except there THEN becomes the issue if someone depends on the normal log4j artifact as well as some JBoss artifact that then transitively pulls in org.jboss:log4j, they end up with two versions of log4j on the classpath with all kinds of non-fun things happening. Dan > > > Benjamin > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org >>> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
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 would not want people "bundling" several artifacts into the one artifact. 2009/7/8 Stephen Connolly : > 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, then I get both artitfacts and > Maven would print a warning > > If I add org.jboss.thirdparty:log4j as a direct, and log4j:log4j as a > transitive via another dependency, then I get only > org.jboss.thirdparty:log4j as the transitive dependency has already > been provided by a nearer dependency > > > 2009/7/8 Stephen Connolly : >> 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 >>> >>> >>> that way we can filter out any artifacts which are implemented from the >>> tree... >>> >>> e.g. >>> >>> if I depend on org.jboss.thirdparty:log4j >>> >>> Maven 2.3.0+, 3.0.0+ can see that this implements log4j:log4j, so that >>> it does not need to be pulled in via transative dependencies >>> >>> 2009/7/8 Daniel Kulp : 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 > > repository > > AFAIK, somebody building a patched third-party artifact is supposed to > not deploy this derived artifact with its original group id but with the > group id of the patch creator. So if JBoss creates a patched version of > say log4j, it would need to get deployed with org.jboss:log4j or > similar. This should be allowed to get synced into central as it can be > distinguished from the original log4j:log4j artifact of the project owner. Except there THEN becomes the issue if someone depends on the normal log4j artifact as well as some JBoss artifact that then transitively pulls in org.jboss:log4j, they end up with two versions of log4j on the classpath with all kinds of non-fun things happening. Dan > > > Benjamin > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org >>> >> > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
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, then I get both artitfacts and Maven would print a warning If I add org.jboss.thirdparty:log4j as a direct, and log4j:log4j as a transitive via another dependency, then I get only org.jboss.thirdparty:log4j as the transitive dependency has already been provided by a nearer dependency 2009/7/8 Stephen Connolly : > 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 >> >> >> that way we can filter out any artifacts which are implemented from the >> tree... >> >> e.g. >> >> if I depend on org.jboss.thirdparty:log4j >> >> Maven 2.3.0+, 3.0.0+ can see that this implements log4j:log4j, so that >> it does not need to be pulled in via transative dependencies >> >> 2009/7/8 Daniel Kulp : >>> 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 > repository AFAIK, somebody building a patched third-party artifact is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. >>> >>> Except there THEN becomes the issue if someone depends on the normal log4j >>> artifact as well as some JBoss artifact that then transitively pulls in >>> org.jboss:log4j, they end up with two versions of log4j on the classpath >>> with >>> all kinds of non-fun things happening. >>> >>> Dan >>> >>> Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> -- >>> Daniel Kulp >>> dk...@apache.org >>> http://www.dankulp.com/blog >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> >> > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
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 > > > that way we can filter out any artifacts which are implemented from the > tree... > > e.g. > > if I depend on org.jboss.thirdparty:log4j > > Maven 2.3.0+, 3.0.0+ can see that this implements log4j:log4j, so that > it does not need to be pulled in via transative dependencies > > 2009/7/8 Daniel Kulp : >> 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 >>> > repository >>> >>> AFAIK, somebody building a patched third-party artifact is supposed to >>> not deploy this derived artifact with its original group id but with the >>> group id of the patch creator. So if JBoss creates a patched version of >>> say log4j, it would need to get deployed with org.jboss:log4j or >>> similar. This should be allowed to get synced into central as it can be >>> distinguished from the original log4j:log4j artifact of the project owner. >> >> Except there THEN becomes the issue if someone depends on the normal log4j >> artifact as well as some JBoss artifact that then transitively pulls in >> org.jboss:log4j, they end up with two versions of log4j on the classpath with >> all kinds of non-fun things happening. >> >> Dan >> >> >>> >>> >>> Benjamin >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >> >> -- >> Daniel Kulp >> dk...@apache.org >> http://www.dankulp.com/blog >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
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 Maven 2.3.0+, 3.0.0+ can see that this implements log4j:log4j, so that it does not need to be pulled in via transative dependencies 2009/7/8 Daniel Kulp : > 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 >> > repository >> >> AFAIK, somebody building a patched third-party artifact is supposed to >> not deploy this derived artifact with its original group id but with the >> group id of the patch creator. So if JBoss creates a patched version of >> say log4j, it would need to get deployed with org.jboss:log4j or >> similar. This should be allowed to get synced into central as it can be >> distinguished from the original log4j:log4j artifact of the project owner. > > Except there THEN becomes the issue if someone depends on the normal log4j > artifact as well as some JBoss artifact that then transitively pulls in > org.jboss:log4j, they end up with two versions of log4j on the classpath with > all kinds of non-fun things happening. > > Dan > > >> >> >> Benjamin >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org > > -- > Daniel Kulp > dk...@apache.org > http://www.dankulp.com/blog > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
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 > > repository > > AFAIK, somebody building a patched third-party artifact is supposed to > not deploy this derived artifact with its original group id but with the > group id of the patch creator. So if JBoss creates a patched version of > say log4j, it would need to get deployed with org.jboss:log4j or > similar. This should be allowed to get synced into central as it can be > distinguished from the original log4j:log4j artifact of the project owner. Except there THEN becomes the issue if someone depends on the normal log4j artifact as well as some JBoss artifact that then transitively pulls in org.jboss:log4j, they end up with two versions of log4j on the classpath with all kinds of non-fun things happening. Dan > > > Benjamin > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
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 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 at 10:13 PM, Benjamin Bentmann < > benjamin.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 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 is supposed to not >> deploy this derived artifact with its original group id but with the group >> id of the patch creator. So if JBoss creates a patched version of say log4j, >> it would need to get deployed with org.jboss:log4j or similar. This should >> be allowed to get synced into central as it can be distinguished from the >> original log4j:log4j artifact of the project owner. >> >> >> Benjamin >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
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 at 10:13 PM, Benjamin Bentmann < benjamin.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 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 is supposed to not > deploy this derived artifact with its original group id but with the group > id of the patch creator. So if JBoss creates a patched version of say log4j, > it would need to get deployed with org.jboss:log4j or similar. This should > be allowed to get synced into central as it can be distinguished from the > original log4j:log4j artifact of the project owner. > > > Benjamin > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Depending on Artifacts not in central
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 project needs >> to patch some thirdparty jar, rebuild it, and upload it to our repository > > AFAIK, somebody building a patched third-party artifact is supposed to not > deploy this derived artifact with its original group id but with the group > id of the patch creator. So if JBoss creates a patched version of say log4j, > it would need to get deployed with org.jboss:log4j or similar. This should > be allowed to get synced into central as it can be distinguished from the > original log4j:log4j artifact of the project owner. > > > Benjamin > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
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 is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
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 repository stuff has been low priority for the people working on it. 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, then we run into a problem with synching. We can't publish this jar to central because we are not the owner of the project, and we can't publish our own projects because they depend on a jar that's only in our repository. Stephen Connolly wrote: 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 massive performance impact... as eery artifact then gets checked in these extra repositories. The biggest issues I see are that two big java companies are very poor at pushing artifacts to central... 1. This company called "Sun" are very poor when it comes to pushing artifacts to central, preferring to keep all their artifacts in a repo that has *both* snapshots and non-snapshots... EEK!!! 2. This other company called "RedHat" have a subsidiary called "JBoss" that maintain their own repository with a whole pile of really useful artifacts as well as a pile of stuff from central. If you happen to know somebody in either of these companies, I would suggest applying some pressure to maintain artifacts in central ;-) I also think that somebody needs to put in place a means of policing the (perhaps informal) rules about artifacts in central or we will have much bigger problems going forward. -Stephen 2009/7/8 Paul Gier : 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 dependency introduces the needed repository into builds through the repo listed in the dependency's POM. Is there a policy or guideline that any artifacts in central should have all their dependencies available in central? Is there any way to enforce this? This is also related to the issue of dependencies being able to introduce repositories into the build (MNG-3056). Will this be fixed in 3.0? In my opinion, the repositories section should be removed from the POM completely. I realize this causes a useability problem in that you have to configure all repositories in settings.xml before building the project. Maybe we can allow a project specific settings.xml located in the same directory as the POM that could be checked into svn and allow project specific settings. Thanks! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Please UnSubscribe
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.
System Administrators have complete administrative rights including
permission to manage underlying JIRA system configuration such as
backups and services.
* Alan Cabrera
* Andrew Eisenberg
* Arnaud Heritier
* Ben Walding
* bob mcwhirter
* Brett Porter
* Brian Topping
* Bruce Snyder
* Contegix Support
* Dain Sundstrom
* Dan Diephouse
* Dan North
* David Blevins
* Dennis Lundberg
* Edward Povazan
* Emmanuel Venisse
* Eugene Kuleshov
* Guillaume Laforge
* Jacques Morel
* James E. Ervin
* James Macgill
* Jason Dillon
* Jason van Zyl
* Jody Garnett
* Paul Hammant
* Peter Donald
* peter royal
* Rodrigo B. de Oliveira
* Scott Farquhar
* Trygve Laugstol
* Vincent Massol
* Werner Guttmann
* Xircles System User
Thanks a bunch
On Jul 8, 2009, at 11:38 AM, Benjamin Bentmann (JIRA) wrote:
[ http://jira.codehaus.org/browse/MNG-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=182983#action_182983
]
Benjamin Bentmann commented on MNG-4232:
In which file exactly does this substitution happen? In the POM or
in some resource file? Could you provide an example project to
demonstrate this?
Property substitution of ${project.build.directory} on Windows FAILS
Key: MNG-4232
URL: http://jira.codehaus.org/browse/MNG-4232
Project: Maven 2
Issue Type: Bug
Components: Bootstrap & Build
Affects Versions: 2.2.0
Environment: Windows XP 32 bits
Reporter: Rodolfo Rothganger
For a project target directory on C:\project\target, the maven
build substitutes the project property ${project.build.directory}
with c\:\\project\\target. The c\:\\ should be c:\\
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
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 massive performance impact... as eery artifact then gets checked in these extra repositories. The biggest issues I see are that two big java companies are very poor at pushing artifacts to central... 1. This company called "Sun" are very poor when it comes to pushing artifacts to central, preferring to keep all their artifacts in a repo that has *both* snapshots and non-snapshots... EEK!!! 2. This other company called "RedHat" have a subsidiary called "JBoss" that maintain their own repository with a whole pile of really useful artifacts as well as a pile of stuff from central. If you happen to know somebody in either of these companies, I would suggest applying some pressure to maintain artifacts in central ;-) I also think that somebody needs to put in place a means of policing the (perhaps informal) rules about artifacts in central or we will have much bigger problems going forward. -Stephen 2009/7/8 Paul Gier : > 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 dependency introduces > the needed repository into builds through the repo listed in the > dependency's POM. > > Is there a policy or guideline that any artifacts in central should have all > their dependencies available in central? Is there any way to enforce this? > > This is also related to the issue of dependencies being able to introduce > repositories into the build (MNG-3056). Will this be fixed in 3.0? > > In my opinion, the repositories section should be removed from the POM > completely. I realize this causes a useability problem in that you have to > configure all repositories in settings.xml before building the project. > Maybe we can allow a project specific settings.xml located in the same > directory as the POM that could be checked into svn and allow project > specific settings. > > Thanks! > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Developed new maven plugin for Jlint
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 your request to the Mojo dev mailing list, mention > that you're already a contributor on the Sonar plugins project. > > cheers, > Freddy > > > Freddy Mallet > www.SonarSource.com > Sonar.codehaus.org > http://twitter.com/FreddyMallet > > > > On Wed, Jul 8, 2009 at 10:09 AM, Benjamin Bentmann < > benjamin.bentm...@udo.edu> wrote: > >> 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 of other Maven plugins. See [0] for some instructions. >> >> >> Benjamin >> >> >> [0] http://mojo.codehaus.org/contribution/submitting-a-plugin.html >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Regarding MSANDBOX-46
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. 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 am using that plugin since it got added to the > sandbox and I am currently in the process of preparing a project for > release which depends on it. My question is how to proceed to get that > plugin released. I am currently not an apache committer so I cannot do > much about it other than asking here. If that plugin needs to be > maintained by someone, I could do that, of course. > > -- > Christian > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Developed new maven plugin for Jlint
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 project. cheers, Freddy Freddy Mallet www.SonarSource.com Sonar.codehaus.org http://twitter.com/FreddyMallet On Wed, Jul 8, 2009 at 10:09 AM, Benjamin Bentmann < benjamin.bentm...@udo.edu> wrote: > 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 of other Maven plugins. See [0] for some instructions. > > > Benjamin > > > [0] http://mojo.codehaus.org/contribution/submitting-a-plugin.html > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Incorrect license metadata after inheriting org.apache:apache:6
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 the > current and past versions of the product: > > Apache [PRODUCT_NAME] > Copyright [] The Apache Software Foundation > > Note it specifically says "year(s)". Good point, though I still think it's incorrect. :-) I'm engaging legal-discuss@ to know for sure. > Thus, I think the current version is correct. Agreed. I'll get back to this in case the status quo changes. BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Depending on Artifacts not in central
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 dependency introduces the needed repository into builds through the repo listed in the dependency's POM. Is there a policy or guideline that any artifacts in central should have all their dependencies available in central? Is there any way to enforce this? This is also related to the issue of dependencies being able to introduce repositories into the build (MNG-3056). Will this be fixed in 3.0? In my opinion, the repositories section should be removed from the POM completely. I realize this causes a useability problem in that you have to configure all repositories in settings.xml before building the project. Maybe we can allow a project specific settings.xml located in the same directory as the POM that could be checked into svn and allow project specific settings. Thanks! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Bring Maven to the Color age
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
Regarding MSANDBOX-46
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 am using that plugin since it got added to the sandbox and I am currently in the process of preparing a project for release which depends on it. My question is how to proceed to get that plugin released. I am currently not an apache committer so I cannot do much about it other than asking here. If that plugin needs to be maintained by someone, I could do that, of course. -- Christian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r791464 - in /maven/plugins/trunk/maven-javadoc-plugin/src: main/java/org/apache/maven/plugin/javadoc/AbstractFixJavadocMojo.java test/java/org/apache/maven/plugin/javadoc/FixJavadoc
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. > expect this setting to be at least configurable. Or do I miss an existing > way for a user to adjust this setting? If user get init error of VM, he should adjust its MAVEN_OPTS. Thanks! Vincent - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Developed new maven plugin for Jlint
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 of other Maven plugins. See [0] for some instructions. Benjamin [0] http://mojo.codehaus.org/contribution/submitting-a-plugin.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
