Return-Path: X-Original-To: apmail-maven-users-archive@www.apache.org Delivered-To: apmail-maven-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A5376E306 for ; Thu, 14 Feb 2013 09:11:18 +0000 (UTC) Received: (qmail 48230 invoked by uid 500); 14 Feb 2013 09:11:16 -0000 Delivered-To: apmail-maven-users-archive@maven.apache.org Received: (qmail 48169 invoked by uid 500); 14 Feb 2013 09:11:16 -0000 Mailing-List: contact users-help@maven.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Maven Users List" Reply-To: "Maven Users List" Delivered-To: mailing list users@maven.apache.org Received: (qmail 48146 invoked by uid 99); 14 Feb 2013 09:11:15 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Feb 2013 09:11:15 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of stephen.alan.connolly@gmail.com designates 74.125.82.179 as permitted sender) Received: from [74.125.82.179] (HELO mail-we0-f179.google.com) (74.125.82.179) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Feb 2013 09:11:11 +0000 Received: by mail-we0-f179.google.com with SMTP id x43so1762685wey.24 for ; Thu, 14 Feb 2013 01:10:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=aIrmmK2KV4mYKz6pu+Knm8WosoJ5aGTXuN6dCyE0Rfc=; b=dfvhLXpvy8dScrsq50posG2EAnr02TsZhAXjc99vl3unnizZ68m+x1e71KMbFyGhM0 b/TA9bYB4axO9tNuV8KsGFNkVY7OqEBeCVxlBo+YYKDLRkdpSeEdw5S0jDwz3/XEc4qX vRjFgrvsFpfWcN8/Lhmt75KPQhS3KQDsJGYs1/+t8JiIpJRIFTolpkkLhVNGycTTkZji DZ6VKX4TawLHIN+RixvVCEuHZ2tv5qobEln5Kj0JjMnQ+Cf4aaaVt1D45vKKLmU4UMHy iJqULtd4F/d9Kx4jXlIEvnm+OQ+LhbHjfpCPuNP0y//cYAQuk6hZAO67dF8SgK45sEWj 5o1w== MIME-Version: 1.0 X-Received: by 10.180.109.82 with SMTP id hq18mr15502520wib.0.1360833049483; Thu, 14 Feb 2013 01:10:49 -0800 (PST) Received: by 10.194.20.33 with HTTP; Thu, 14 Feb 2013 01:10:49 -0800 (PST) In-Reply-To: <511CA416.4060409@mgm-tp.com> References: <5118B740.6010908@mgm-tp.com> <5118FFDD.1030007@artifact-software.com> <511BA927.9080304@mgm-tp.com> <511CA416.4060409@mgm-tp.com> Date: Thu, 14 Feb 2013 09:10:49 +0000 Message-ID: Subject: Re: Dependency resolution kicks in too early From: Stephen Connolly To: Maven Users List Content-Type: multipart/alternative; boundary=e89a8f3b9d9d835ac804d5aba215 X-Virus-Checked: Checked by ClamAV on apache.org --e89a8f3b9d9d835ac804d5aba215 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 14 February 2013 08:45, Reinhard N=E4gele w= rote: > I don't think it is a good idea to pollute Maven Central with this > artifact under a different groupId. > > Nor do I, except when it is necessary... the old advice was to do it that way... the new advice is that it should be a last resort... this is largely a result of the lack of a mechanism in pom v4.0.0, which forces an almighty collection of on people... when I do push things to central under my group Id you will find that I have the source code public and in my github repo, so in a sense I am maintaining a fork of the project. In the case of https://github.com/stephenc/redmine-java-api this is now a complete fork as I disagree with how the forked project has implemented some features, and at some point in time I will rejig the back end to be based off of async-http-client, so there is a legitimate reason for the alternate groupId (given that the two artifacts are not equivalent) If you are going to publish something under your own groupId you should at least be ensuring that the source repository of what you are publishing is available as anonymous read and independent of the "original" project as then it is clear that you are maintaining a fork. One of the features I would like to get into POM v5.0.0 is the idea of a "provides" mechanism... Thus one could indicate that org.apache.geronimo.specs geronimo-servlet_2.5_spec 1.2 org.apache.tomcat servlet-api org.mortbay.jetty servlet-api And the org.apache.geronimo.specs:geronimo-servlet_2.5_spec pom itself may indicate that it provides javax.servlet:servlet-api Not that I am saying that is how it would work... but in essence some feature like the above is required. My thinking is that a POM would have a element equivalent to a where it listed the "apis" that this module provides, additionally you can add additional entries to the project's list when you pull it in as a dependency, because there is no way for a project to know up front all the GroupId:ArtifactIds that it provides... and this would just be done "right". The harder part is mapping onto transitive consumers who are using POM 4.0.0 parsers... but in a sense they are no worse off at the moment, as long as the 4.0.0 compatible POM that we push to the repo as part of the POM 5.0.0 deploy pins the dependency version (i.e. removing ranges) it can add the necessary exclusions on its dependencies so that the transitives injected into the consuming projects tree will be as clean as it can inject them... IOW the consumer will be no worse off. > Reinhard > > Am 13.02.2013 17:09, schrieb Stephen Connolly: > > Yes, I agree, but I have had to do it myself some times... in more radic= al >> cases this has evolved into a complete fork for me (e.g. redmine-java-ap= i) >> >> >> On 13 February 2013 15:33, Anders Hammar wrote: >> >> Right, I was thinking they would deploy it to their Nexus instance wher= e >>> they deploy their own oss product. >>> Having the same jar in two different groupIds in central only confuses >>> people and causes problems I think. We should try to avoid that. >>> >>> /Anders >>> >>> >>> On Wed, Feb 13, 2013 at 4:27 PM, Stephen Connolly < >>> stephen.alan.connolly@gmail.**com > >>> wrote: >>> >>> On 13 February 2013 15:19, Anders Hammar wrote: >>>> >>>> deploy it to your own groupId >>>>>> >>>>>> Isn't it better if he uses the original groupId and artifactId, but >>>>> >>>> adds >>> >>>> a >>>> >>>>> qualifier to the version indicating that it's their release? >>>>> >>>> >>>> Well... the chain you have to go when deploying something into central >>>> under a groupId that you do not own is something like: >>>> >>>> 1. Show that you have engaged the owning project and that they are not >>>> pushing a version >>>> 2. Show blah blah blah >>>> 3. >>>> 4. >>>> 5. Ok, create the bundle and upload it >>>> >>>> And given that he said the owning project is working on uploading to >>>> central, he's going to fail on step 1... so if it is urgent the lesser >>>> >>> evil >>> >>>> is his own groupId... >>>> >>>> That said it would be best to keep the groupId it will end up with. >>>> >>>> >>>> Like if he >>>>> would have patched an official release. >>>>> >>>>> /Anders >>>>> >>>>> >>>>> >>>>>> On 13 February 2013 14:54, Reinhard N=E4gele < >>>>>> >>>>> reinhard.naegele@mgm-tp.com >>>> >>>>> wrote: >>>>>>> Normally, I'd deploy it to our Nexus. But in this case, this is not >>>>>>> possible. We are open-sourcing one of our products and need a >>>>>>> >>>>>> third-party >>>>> >>>>>> dependency which is not yet available on Maven Central. We are >>>>>>> >>>>>> working >>>> >>>>> with >>>>>> >>>>>>> the developer of the library to fix this, but until this is the >>>>>>> >>>>>> case, >>> >>>> we >>>>> >>>>>> need a temporary solution. >>>>>>> >>>>>>> Reinhard >>>>>>> >>>>>>> >>>>>>> Am 11.02.2013 15:27, schrieb Ron Wheeler: >>>>>>> >>>>>>> Why not just load these stray orphans into your MRM once and then >>>>>>> >>>>>> treat >>>>> >>>>>> them and normal dependencies. >>>>>>>> >>>>>>>> Ron >>>>>>>> >>>>>>>> On 11/02/2013 4:17 AM, Reinhard N=E4gele wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>>> >>>>>>>>> A couple of years ago I used a plugin execution in the validate >>>>>>>>> >>>>>>>> phase >>>> >>>>> to >>>>>> >>>>>>> bootstrap jars that were not available on Maven Central as >>>>>>>>> >>>>>>>> suggested >>>> >>>>> in >>>>> >>>>>> [1]. I needed to do the same thing again today but noticed that >>>>>>>>> >>>>>>>> this >>>> >>>>> approach does not seem to work any more with Maven 3. Right after >>>>>>>>> >>>>>>>> running >>>>>> >>>>>>> Maven, dependency resolution kicks in making the build fail even >>>>>>>>> >>>>>>>> before the >>>>>> >>>>>>> install plugin gets a chance to install the missing dependency. >>>>>>>>> >>>>>>>> Here's >>>>> >>>>>> what >>>>>> >>>>>>> I'm doing: >>>>>>>>> >>>>>>>>> >>>>>>>>> org.apache.maven.****plugins >>>>>>>>> maven-install-****plugin >>>>>>>>> >>>>>>>>> >>>>>>>>> boostrap-some-depencency >>>>>>>>> >>>>>>>>> install-file >>>>>>>>> >>>>>>>>> validate >>>>>>>>> >>>>>>>>> com.some.groupid >>>>>>>>> some-artifact >>>>>>>>> ${some.artifact.****version} >>>>>>>>> jar >>>>>>>>> bootstrap-lib/some-****artifact-${some.artifact.** >>>>>>>>> version}.jar >>>>>>>>> >>>>>>>>> bootstrap-lib/some-****artifact-${some.artifact.**** >>> version}-sources.jar >>> >>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ... >>>>>>>>> >>>>>>>>> com.some.groupid >>>>>>>>> some-artifact >>>>>>>>> ${some.artifact.****version} >>>>>>>>> >>>>>>>>> ... >>>>>>>>> >>>>>>>>> 1.2.3 >>>>>>>>> >>>>>>>>> >>>>>>>>> [1] http://www.blackbit.be/2010/****04/15/maven-automatically-**<= http://www.blackbit.be/2010/**04/15/maven-automatically-**> >>>>>>>>> install-dependencies-during-****build/< >>>>>>>>> >>>>>>>> http://www.blackbit.be/2010/**04/15/maven-automatically-** >>> install-dependencies-during-**build/ >>> >>>> Is this no longer possible? I'd really prefer this approach over >>>>>>>>> >>>>>>>> using >>>>> >>>>>> a >>>>>> >>>>>>> system dependency. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Reinhard >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------****----------------------------** >>>>>>>>> --** >>>>>>>>> --------- >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apac**he.org >>>>>>>>> < >>>>>>>>> >>>>>>>> users-unsubscribe@maven.**apache.org >>>>>> > >>>>>> >>>>>>> For additional commands, e-mail: users-help@maven.apache.org >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> ------------------------------****----------------------------** >>> --**--------- >>> >>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apac**he.org >>>>>>> < >>>>>>> >>>>>> users-unsubscribe@maven.**apache.org >>>>>> > >>>>>> >>>>>>> For additional commands, e-mail: users-help@maven.apache.org >>>>>>> >>>>>>> >>>>>>> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org > > For additional commands, e-mail: users-help@maven.apache.org > > --e89a8f3b9d9d835ac804d5aba215--