I think for most changes the intent is to get the patch back into the upstream
OSS project. But it's kind of dependent on who made the patch and whether the
upstream project would accept it.
Jason van Zyl wrote:
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 <bri...@infinity.nu>
To: Maven Developers List <dev@maven.apache.org>
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<pg...@redhat.com> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
