Return-Path: X-Original-To: apmail-maven-dev-archive@www.apache.org Delivered-To: apmail-maven-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4089B100F5 for ; Fri, 20 Feb 2015 05:25:54 +0000 (UTC) Received: (qmail 69281 invoked by uid 500); 20 Feb 2015 05:25:53 -0000 Delivered-To: apmail-maven-dev-archive@maven.apache.org Received: (qmail 69196 invoked by uid 500); 20 Feb 2015 05:25:53 -0000 Mailing-List: contact dev-help@maven.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Maven Developers List" Reply-To: "Maven Developers List" Delivered-To: mailing list dev@maven.apache.org Received: (qmail 69185 invoked by uid 99); 20 Feb 2015 05:25:53 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Feb 2015 05:25:53 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [216.86.168.182] (HELO mxout-07.mxes.net) (216.86.168.182) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Feb 2015 05:25:47 +0000 Received: from mpb.ifedorenko.com (unknown [69.196.134.73]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B55A422E267 for ; Fri, 20 Feb 2015 00:24:55 -0500 (EST) Message-ID: <54E6C526.1090006@ifedorenko.com> Date: Fri, 20 Feb 2015 00:24:54 -0500 From: Igor Fedorenko User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: dev@maven.apache.org Subject: Re: MavenPluginManager#setupPluginRealm "imports" parameter References: <54D140D7.6050808@ifedorenko.com> <1700063.XlGJAF0AB7@herve-desktop> <54D1A09C.4060604@ifedorenko.com> <1921474.hu3kGuGYZd@herve-desktop> In-Reply-To: <1921474.hu3kGuGYZd@herve-desktop> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org I believe all maven class realms lookup classes and resources in the following order 1. realm imports 2. self 3. parent This means you should be okay unless reporting plugins and site plugin need to agree on some common classes but the classes are present in both plugin dependencies. It also means that ClassLoader#getResources (i.e. plural) will return resources from both reporting and site plugin dependencies, so things like ServiceLoader mey be confused by some unexpected resources. -- Regards, Igor On 2015-02-19 23:14, Herv� BOUTEMY wrote: > Hi, > > Sorry for the delay: needed to take time to really think about the impact > > effective real world tests confirm that "imports" parameter is not taken into > account: lately, we found the first plugin I know of that was bitten by this > fact. It's Apache Rat Maven Plugin, that is bitten by Xerces injected by Maven > Site Plugin even if these classes are not in the "import" parameter. See > RAT-158 [1] > > The import parameter is used to export Doxia from maven-site-plugin to the > reporting plugins, and only Doxia, not the full maven-site-plugin transitive > dependencies [1] > > I don't think that any report plugin really /requires/ a dependency to be > injected by maven-site-plugin, since a report plugin can be used standalone > too, without the maven-site-plugin then its classes. > > On the other hand, a report mojo can be confused if its own dependency version > is overridden by maven-site-plugin: do you know what's the order of > dependencies for report plugin? > > If the order makes maven-site-plugin's dependencies override report plugins > ones, I think the import parameter should be taken into acccount: of course, > this should be tested to be sure there is no unexpected side effect. > > if the order makes report plugin hav its wn version override maven-site- > plugin, I suppose it's safer to stay as is > > What is clear is that this bug wasn't found by anybody before, so it doesn't > have too much consequences in real life: great code review :) > > Regards, > > Herv� > > [1] http://maven.apache.org/plugins/maven-site-plugin/dependencies.html > > [1] https://issues.apache.org/jira/browse/RAT-158 > > Le mardi 3 f�vrier 2015 23:31:24 Igor Fedorenko a �crit : >> MavenPluginManager#setupPluginRealm "imports" parameter is not used in >> any meaningful way. No matter what packages are passed in, the created >> plugin realm will have access to all classes from the provided parent >> classloader. I did some more digging and looks like this is how Maven >> behaved for last 4+ years, so I assume all existing plugins are happy >> with this. >> >> By "fix" I meant to change the code to honour parent imports, but I now >> think it's too risky given how long the current behaviour was in place. >> I plan to update javadoc to state the parameter is ignored and possible >> cleanup the implementation. >> >> -- >> Regards, >> Igor >> >> On 2015-02-03 22:04, Herv� BOUTEMY wrote: >>> Le mardi 3 f�vrier 2015 16:42:47 Igor Fedorenko a �crit : >>>> Does anyone have a usecase that demonstrates use of >>>> MavenPluginManager#setupPluginRealm "imports" parameter? I've found >>>> DefaultMavenReportExecutor from maven-reporting-exec, which provides >>>> list of imported packages, but not sure how to use it from a project. >>> >>> what do you mean by "use it from a project"? >>> >>> maven-reporting-exec is used by maven-site-plugin to execute reports: >>> maven- site-plugin is the only plugin I know of that launches plugins >>> (here called "reports"), but this is the general use case = "plugins >>> launching plugins" >>> >>> I really need it for m-site-p >>> >>>> From what I can tell, this parameter is currently masked by >>>> >>>> DefaultMavenPluginManager implementation and plugins can use any classes >>>> from the provided parent classloader. So I am not sure if we should fix >>>> parent imports implementation or get rid of it completely. >>> >>> "fix"? what is the bug you're trying to fix? >>> is this API causing issue for some evolution? >>> >>> Regards, >>> >>> Herv� >>> >>>> Thank you in advance. >>>> >>>> -- >>>> Regards, >>>> Igor >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org >> For additional commands, e-mail: dev-help@maven.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org > For additional commands, e-mail: dev-help@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional commands, e-mail: dev-help@maven.apache.org