In the past I've tried to set several maven(core) dependencies of a plugin to
provided and it broke!
I didn't understand it and didn't had the time to analyze it.
Just a huge warning that you can expect surprises.
I think we can start thinking of "provided" if we have clear APIs and SPIs
defined
Yup,
this can be approached on "two ends": from Maven and from Plugins
Note: let's name artifacts having GA org.apache.maven:maven-* as "maven
runtime", artifacts being "the maven", in short: MR.
>From plugin end, I never understood why MR dependencies are NOT declared as
"provided".
maven-p
Hi everyone,
Does it mean we have two action items:
1. make maven plugin plugin warn or fail (with a toggle) if a maven stack
plugin is in scope compile and not provided
2. filter a bit what we "know" (probably using semver in a whitelist of
dependencies)
2 is not perfect from a design point of
Yup, "provided" scope would make it, but, as you say, it would require all
(ours and non-ours) to be "fixed".
Just for example, in tooling we did for Nexus 2, the NX plugin packaging
(equivalent of maven plugin packaging)
was ENFORCING that any NX artifact used as NX plugin dependency be declared
thinking about plexus-utils case: only XPP3 class is shared by Maven core
Then I imagine that it that dependency is filtered at runtime, many calls from
plugins to other features of that lib will fail...
If you don't beat at me, I'll try to test tonight
Another idea: would marking libraries as "p
Created https://issues.apache.org/jira/browse/MNG-7097
On Thu, Feb 11, 2021 at 8:41 AM Tamás Cservenák wrote:
> Hi Robert,
>
> I agree with you: is a really small change.
> Re non-exported packages: will take a look into those a bit more, my POC
> was just at "artifact level"... (but given Maven
Hi Robert,
I agree with you: is a really small change.
Re non-exported packages: will take a look into those a bit more, my POC
was just at "artifact level"... (but given Maven toss away downloaded
plugin dependency, is plugin today able to use core artifact's non-exported
package?)
Yes, several m
Hi Tamas,
based on the number of lines you wrote versus the amount of downloads that are
prevented (and storage) I think it is worth adding.
My biggest worry about this solution was about the non exported packages of the
exported artifacts. Would such changes have a negative and inconsistent eff
Just for fun, tried it on another, a bit bigger project (137 modules), and
as 3.6.3 and master was "so close", tried master and patch only:
mvn master (4.0.0-alpha-1, ab20190a1a9fecdc8f85b40e8d03d806f3da4fc6)
total time 1:49 min
total files in local repo: 7679
total bytes in local repo: 652624
cou
Howdy,
Some time ago I stumbled upon Robert S. remark in "[DISCUSS] MNG-7020
Remove Maven 2 WagonExcluder backward compat code" thread: "Why download,
if they are being removed from the classpath afterwards due to classworld
config". Similarly, there is a thread "maven-site-plugin and
sisu-inject-
On 01/06/07, Brett Porter <[EMAIL PROTECTED]> wrote:
Hi Mark,
Sure, jump on in your morning (or grab me on google talk, yahoo,
skype :). I'll still be here. Emmanuel should be around then too, and
he's done the most work on the release plugin recently.
We can post back with what we figure out..
Hi Mark,
Sure, jump on in your morning (or grab me on google talk, yahoo,
skype :). I'll still be here. Emmanuel should be around then too, and
he's done the most work on the release plugin recently.
We can post back with what we figure out...
- Brett
On 01/06/2007, at 1:36 AM, Mark Hobso
On 30/05/07, Mark Hobson <[EMAIL PROTECTED]> wrote:
On 29/05/07, Brett Porter <[EMAIL PROTECTED]> wrote:
> So the sequence might need to be:
> - resolve the project dependencies, filtering out the reactor projects
> - add the reactor projects to the list of resolved artifacts
> - iterate through
On 29/05/07, Brett Porter <[EMAIL PROTECTED]> wrote:
Heh. Nice catch! Can you get that into JIRA?
Done: http://jira.codehaus.org/browse/MNG-3015
> Sure, I was envisaging that it could be fixed in 2.0.7 after which the
> release plugin could have 2.0.7 as a prerequisite.
Still an unreleased v
On 25/05/2007, at 6:55 PM, Mark Hobson wrote:
On 25/05/07, Brett Porter <[EMAIL PROTECTED]> wrote:
On 25/05/2007, at 12:57 AM, Mark Hobson wrote:
> Looks like an infinite loop in the first DefaultDownloader.download
> method.
Not sure what you're saying - you've tried it and it doesn't work,
[ http://jira.codehaus.org/browse/MNG-494?page=all ]
Brett Porter closed MNG-494:
Resolution: Fixed
Fix Version: (was: 2.0-beta-1)
2.0-alpha-3
> defer plugin dependency resolution to execution rather than at addPlu
[ http://jira.codehaus.org/browse/MNG-494?page=all ]
Brett Porter reopened MNG-494:
--
reopen to fix version
> defer plugin dependency resolution to execution rather than at addPlu
[ http://jira.codehaus.org/browse/MNG-494?page=all ]
John Casey closed MNG-494:
--
Resolution: Fixed
> defer plugin dependency resolution to execution rather than at addPlu
defer plugin dependency resolution to execution rather than at addPlugin
Key: MNG-494
URL: http://jira.codehaus.org/browse/MNG-494
Project: Maven 2
Type: Improvement
Components: maven-core
19 matches
Mail list logo
