Re: maven 4.0.0 new XML stuff

> Created https://issues.apache.org/jira/browse/MNG-7067 to start, now we have an umbrella let's refine the description if needed. Excellent and thanks. > regarding jgitver ... Do you have a stacktrace for this? there is no error/problem because it dumps the model manually to a pom.xml file and

Re: maven 4.0.0 new XML stuff

Created https://issues.apache.org/jira/browse/MNG-7067 to start, now we have an umbrella let's refine the description if needed. Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github

Re: maven 4.0.0 new XML stuff

Thank you, now we have something to work on. polyglot should still work, but it looks like it is getting the wrong set of options. So that needs to be fixed. Please create an issue[1] regarding jgitver and don't see an issue at first glance. It is using MavenXpp3Reader, which is low level, no

Re: maven 4.0.0 new XML stuff

Robert, Point is that without using in memory pom model, produced pom will always require rework to be properly consumed. We must avoid it I think and do what you said: read pom -> extend it -> make it immutable (optional for me) -> dump *this* model. This is what makes a consumable feature

Re: maven 4.0.0 new XML stuff

> You both keep talking about extensions, but I haven't touched that part. > I suggest to test current Maven 4 first and to find cases where those extensions don't work anymore. I do not know the exact internals of polyglot but for jgitver, in order to produce a pom-4.0.0.xml compliant file,

Re: maven 4.0.0 new XML stuff

You both keep talking about extensions, but I haven't touched that part. I suggest to test current Maven 4 first and to find cases where those extensions don't work anymore. Next we can see if this makes sense or not and how to solve it. Robert On 5-1-2021 12:28:59, Matthieu Brouillard wrote:

Re: maven 4.0.0 new XML stuff

> Currently the model is mutable and this causes issues. For me it is not the root cause, it does not help for sure but IMO the problem is more that there are currently several sources of trust : the POM & the pom.xml. Personally (only my opinion) I see no other way for the future of maven than

Re: maven 4.0.0 new XML stuff

Hmm, extensions define this kind of lifecycle, at least the afterModelRead which is a hook before it could be immutable no? So not sure how it changes the issue, or do you push to drop extensions support? Romain Manni-Bucau @rmannibucau | Blog

Re: maven 4.0.0 new XML stuff

Currently the model is mutable and this causes issues. Instead I would like to see that once the BuildPlan is finished, the model becomes immutable. To give a concrete example: It must be possible for code generating goals to add dependencies.  Now, when using modello readers/writers you often

Re: maven 4.0.0 new XML stuff

So it seems we must enhance that read/write logic with these elements to make them usable: 1. Make it extension/Maven-IoC (even without extensions you can have the same issue with just guice components) friendly (code showing the bug is in a previous response) 2. Decide what is the produced pom,

Re: maven 4.0.0 new XML stuff

> Can you give an example? Like Romain has shown: dynamically added dependencies or a version computation. > Most important is the support for CI-friendly versions But if extensions dynamically compute and set the versions in the POM using the API, the changes will not be reflected. That's why

Re: maven 4.0.0 new XML stuff

answers are below. Robert On 4-1-2021 16:52:23, Matthieu Brouillard wrote: @Robert nothing is broken atm, the changes for consumer/build are currently behind your feature flag. Robert Scholte:  It is active by default, so it is actually not hidden. But as I feared previously, and as Romain

Re: maven 4.0.0 new XML stuff

@Robert nothing is broken atm, the changes for consumer/build are currently behind your feature flag. But as I feared previously, and as Romain pointed it, by working at XML level (and not at POM level) the produced consumer pom does not reflect changes from extensions. I really thought that all

Re: maven 4.0.0 new XML stuff

Hmm, I don't get a few things of this IT: 1. the formatting seems not expected even if valid (the comments are finishing with the first tag for example "--> { final Dependency dependency = new Dependency(); dependency.setGroupId("junit");

Re: maven 4.0.0 new XML stuff

https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-6957-buildconsumer is the most complete IT On 4-1-2021 12:59:51, Romain Manni-Bucau wrote: Le lun. 4 janv. 2021 à 12:36, Robert Scholte a écrit : > There's just one thing I want to say: > I'm

Re: maven 4.0.0 new XML stuff

Le lun. 4 janv. 2021 à 12:36, Robert Scholte a écrit : > There's just one thing I want to say: > I'm having trouble with the term "broken". > Well, literally meant broken as decorelated from the user intent and extension model. Anyway, didn't intend to blame but more identify the blockers for a

Re: maven 4.0.0 new XML stuff

There's just one thing I want to say: I'm having trouble with the term "broken". If a Maven project could be built with M3.6.3, it can still be built with M4. If not, it is either regression (MNG-6957, MNG-7063) which must be fixed, or it requires changes to a plugin for understandable reasons

Re: maven 4.0.0 new XML stuff

Le dim. 3 janv. 2021 à 19:04, Robert Scholte a écrit : > I don't remember all those details anymore, because I hit those in the > beginning. > Trying things over and over again I decided that this is probably the most > successful approach. > > > What of the goals was to keep the pom.xml as is

Re: maven 4.0.0 new XML stuff

I don't remember all those details anymore, because I hit those in the beginning. Trying things over and over again I decided that this is probably the most successful approach. What of the goals was to keep the pom.xml as is as much as possible. We can only decide for the specific Maven

Re: maven 4.0.0 new XML stuff

Le dim. 3 janv. 2021 à 16:18, Robert Scholte a écrit : > > So what I was expecting was: raw xml model -> converted to unified > consumed model -> extensions -> model processing. > > This is only the build pom part. You're missing the consume part, where > the xml is distributed. > Yes but with

Re: maven 4.0.0 new XML stuff

> So what I was expecting was: raw xml model -> converted to unified consumed >model -> extensions -> model processing. This is only the build pom part. You're missing the consume part, where the xml is distributed. Build is raw + enrich, consumer is raw + enrich + reduce (removing relativePath

Re: maven 4.0.0 new XML stuff

Hi all, I kind of join Matthieu thoughts there, there is no point to work at xml level to create the consumed pom - comments is not a point since it can commonly/easily refer to a dropped part of the pom so they should be stripped. Current extension model got proven adapted and adopted, using a

Re: maven 4.0.0 new XML stuff

Hi Matthieu, As you understand, something had to be changed to move Maven forward. I've decided to pick up that challenge and came up with the current solution. My main concerns was that I wanted to keep the fileModel as much as is. That includes the license, comments and element order.  This

Re: maven 4.0.0 new XML stuff

Thanks Robert for the video link. I fully understand the rationales behind the separation of build/consumer pom and the video provides some insights on it and you explain the actual implementation to introduce this change. Still I do not fully understand why it was decided to work on top of XML

Re: maven 4.0.0 new XML stuff

Yes, I think so. Per artifact, if it includes the POM, we need to decide which one to include. It should never be the raw one (e.g. it might miss the version to its parent), most of the time the consumer POM, but sometimes the build POM. Robert On 1-1-2021 15:14:52, Gary Gregory wrote: Great

Re: maven 4.0.0 new XML stuff

Great idea to record this video, TY! I would guess that the javadoc plugin would change in the same way the source plugin needs to change, right? Gary On Thu, Dec 31, 2020, 13:01 Robert Scholte wrote: > I've made a recording[1] about it, which hopefully answers most questions. > > Robert > >

Re: maven 4.0.0 new XML stuff

I've made a recording[1] about it, which hopefully answers most questions. Robert [1] https://youtu.be/KDAmlNKZJto On 31-12-2020 16:18:57, Matthieu Brouillard wrote: > Not exactly sure what work you mean everything related to maven-xml: Build/ConsumerPomXMLFilterxxx,

Re: maven 4.0.0 new XML stuff

> Not exactly sure what work you mean everything related to maven-xml: Build/ConsumerPomXMLFilterxxx, Build/ConsumerModelSource and the transformer stuff. Especially, when looking at classes like CiFriendlyXMLFilter, I would have thought that such things could have been done elsewhere, working

Re: maven 4.0.0 new XML stuff

Hello, Not exactly sure what work you mean and I fully agree that using a core model should still be the API for plugins and extensions to work with, however specifically the consumer POM integrates with so many external ecosystems, I would expect it to be defined in terms of XML Schema with

Re: Maven 4.0.0

I would like to have SCM Hook from CI or SCM Agent. Maven 4 should run only changed modules similar to "mvn -pl...". If we get a list of changed files, the Eclipse compiler might be faster and then only tests for changed classes will run. Then I would like to have clean and site executed on

Re: Maven 4.0.0

Hi Jörg, fully unrelated (cross topic). About tycho I often end up doing a custom script hacking the resolvedArtifacts and using a local cache (m2 fake repo) because tycho plugin is way to slow in practise. It can look like

Re: Maven 4.0.0

Hi Romain, Am Thu, 09 Nov 2017 09:32:12 +0100 schrieb Romain Manni-Bucau: > FYI opened https://github.com/apache/maven/pull/136 for the MNG-6302 > (guess we can switch from thread to discuss it now?) How is this issue related with my topic regarding improved Tycho support in Maven 4.0.0?

Re: Maven 4.0.0

On 12 Nov 2017, at 23:06, Stephen Connolly wrote: > That could end up duplicating the local repo cache... unless we default the > cache to ~/.m2/repository anyway... otoh a concurrency safe local repo > cache may mandate a new location... but double the downloads for inter-op > with older Maven

Re: Maven 4.0.0

Keep in mind, Maven is not the only pom consumer. Expression changes outside the pom are probably fine. Expression changes inside the pom will probably require the 4.0.0 (optional scope) feature to bring flatten Maven plugin type features to first class core support (ie deploy the pom with new

Re: Maven 4.0.0

On Sun 12 Nov 2017 at 07:41, Chris Graham wrote: > required: > - *everything* in settings.xml can be put in a profile section in > settings.xml. > > I often move around/between projects and having to redo mirrors section, > and unable to add servers into the profile

Re: Maven 4.0.0

One more: Better support for classifiers. ideally be able to reference them via a {$project.classifier} type of construct, esp so I can use/reference them in assemble transformations. This might be able to be done without bumping to V4 though. On Sun, Nov 12, 2017 at 6:41 PM, Chris Graham

Re: Maven 4.0.0

required: - *everything* in settings.xml can be put in a profile section in settings.xml. I often move around/between projects and having to redo mirrors section, and unable to add servers into the profile section for clarity is a pain. For me, it's just a matter of convienence. On Sat, Nov 4,

Re: Maven 4.0.0

FYI opened https://github.com/apache/maven/pull/136 for the MNG-6302 (guess we can switch from thread to discuss it now?) Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github | LinkedIn 2017-11-09 9:30 GMT+01:00 Jörg Schaible : > Hi, > > one wish: Better

Re: Maven 4.0.0

Hi, one wish: Better integration with pom-less Tycho projects. Currently it is not possible to run Maven and use standard Maven-based and pom-less Tycho-based projects in one reactor if the Tycho projects have dependencies on the Maven-based projects. AFAICS the problem is that Polyglott is

Re: Maven 4.0.0

ww.linkedin.com/in/rmannibucau> >>> >> >>> >> 2017-11-05 22:27 GMT+01:00 Bernd Eckenfels <e...@zusammenkunft.net>: >>> >> >>> >> > Hello, >>> >> > >>> >> > >>> >> >

Re: Maven 4.0.0

.linkedin.com/in/rmannibucau> >> >> >> >> 2017-11-05 22:27 GMT+01:00 Bernd Eckenfels <e...@zusammenkunft.net>: >> >> >> >> > Hello, >> >> > >> >> > >> >> > >> >> > Adding annot

Re: Maven 4.0.0

27 GMT+01:00 Bernd Eckenfels <e...@zusammenkunft.net>: > >> > >> > Hello, > >> > > >> > > >> > > >> > Adding annotations and processor as a compiletime dependency sounds > like > >> a > >> &g

Re: Maven 4.0.0

package needs to go on the classpath and which is processor impl. (and >> > having a different artifact for runtime) >> > >> > >> > >> > Gruss >> > >> > Bernd >> > >> > >> > >> > *Von: *Mark Derricutt &l

Re: Maven 4.0.0

having a different artifact for runtime) > > > > > > > > Gruss > > > > Bernd > > > > > > > > *Von: *Mark Derricutt <m...@talios.com> > > *Gesendet: *Sonntag, 5. November 2017 22:20 > > *An: *Maven Developers List <dev

Re: Maven 4.0.0

impl. (and > having a different artifact for runtime) > > > > Gruss > > Bernd > > > > *Von: *Mark Derricutt <m...@talios.com> > *Gesendet: *Sonntag, 5. November 2017 22:20 > *An: *Maven Developers List <dev@maven.apache.org> > *Betreff: *Re: Ma

Re: Maven 4.0.0

On 5 Nov 2017, at 10:42, Robert Scholte wrote: > I would like to drop strict scopes in general and give plugins the > opportunity to depend on > specific scoped dependencies. How would this help with annotations tho? The main issue I'm facing is having a standard m-c-p plugin definition in a

Re: Maven 4.0.0

On Sun, 05 Nov 2017 07:04:54 +0100, Hervé BOUTEMY wrote: Le samedi 4 novembre 2017, 22:35:35 CET Robert Scholte a écrit : On Sat, 04 Nov 2017 18:34:14 +0100, Romain Manni-Bucau wrote: > 2017-11-04 18:17 GMT+01:00 Stephen Connolly > >

Re: Maven 4.0.0

Le samedi 4 novembre 2017, 22:35:35 CET Robert Scholte a écrit : > On Sat, 04 Nov 2017 18:34:14 +0100, Romain Manni-Bucau > > wrote: > > 2017-11-04 18:17 GMT+01:00 Stephen Connolly > > > > : > >> On Sat 4 Nov 2017 at 17:11, Romain

Re: Maven 4.0.0

On Sat, 04 Nov 2017 21:42:34 +0100, Mark Derricutt wrote: Would adding support for 2 new scopes be viable without changing the pom model ( the DTD/XSD doesn't actually define the values so that should be ok). Specifically I'm thinking 'annotation' ( having annotationPaths on

Re: Maven 4.0.0

On Sat, 04 Nov 2017 18:34:14 +0100, Romain Manni-Bucau wrote: 2017-11-04 18:17 GMT+01:00 Stephen Connolly : On Sat 4 Nov 2017 at 17:11, Romain Manni-Bucau wrote: My wishlist as a user would be: - incremental

Re: Maven 4.0.0

Would adding support for 2 new scopes be viable without changing the pom model ( the DTD/XSD doesn't actually define the values so that should be ok). Specifically I'm thinking 'annotation' ( having annotationPaths on m-c-p was a workaround, but kinda horrible in practice ), and maybe "module"

Re: Maven 4.0.0

On Sat 4 Nov 2017 at 17:52, Hervé BOUTEMY wrote: > Le samedi 4 novembre 2017, 18:34:14 CET Romain Manni-Bucau a écrit : > > > And scripting is the path to the dark side of imperative builds... but > > > proposals welcome > > > > This is true but this is also mandatory

Re: Maven 4.0.0

Le samedi 4 novembre 2017, 18:34:14 CET Romain Manni-Bucau a écrit : > > And scripting is the path to the dark side of imperative builds... but > > proposals welcome > > This is true but this is also mandatory today. There is a small > alternative to that and I would be as happy if maven can do

Re: Maven 4.0.0

2017-11-04 18:17 GMT+01:00 Stephen Connolly : > On Sat 4 Nov 2017 at 17:11, Romain Manni-Bucau > wrote: > >> My wishlist as a user would be: >> >> - incremental build (based on scm is fine) >> - some built in scripting (groovy based?) > > >

Re: Maven 4.0.0

On Sat 4 Nov 2017 at 17:11, Romain Manni-Bucau wrote: > My wishlist as a user would be: > > - incremental build (based on scm is fine) > - some built in scripting (groovy based?) I have a worry for groovy with Java 9+ And scripting is the path to the dark side of

Re: Maven 4.0.0

My wishlist as a user would be: - incremental build (based on scm is fine) - some built in scripting (groovy based?) - plugin sorting from the pom (current rules are deterministic but too hard to use so defining a dependency between two executions in the same phase would be very handy -

Re: Maven 4.0.0

On 4 November 2017 at 07:30, Hervé BOUTEMY wrote: > Le samedi 4 novembre 2017, 14:43:46 CET John Patrick a écrit : > > I've got a few updates I feel would be useful for the next major > version; > > > > 1) Packaging type generic 'archive', or specific zip or tar.gz > > -

Re: Maven 4.0.0

Le samedi 4 novembre 2017, 14:43:46 CET John Patrick a écrit : > I've got a few updates I feel would be useful for the next major version; > > 1) Packaging type generic 'archive', or specific zip or tar.gz > - maybe a user property to enable zip and/or tar.gz > > 2) Packaging type generic

Re: Maven 4.0.0

I've got a few updates I feel would be useful for the next major version; 1) Packaging type generic 'archive', or specific zip or tar.gz - maybe a user property to enable zip and/or tar.gz 2) Packaging type generic 'application', or specific rpm or deb - in future could be extended for windows

Re: Maven 4.0.0

On Sat 4 Nov 2017 at 12:52, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > On Sat 4 Nov 2017 at 12:49, Michael Osipov wrote: > >> Am 2017-11-04 um 13:20 schrieb Stephen Connolly: >> > The past two days, Hervé, Robert and I have been discussing our next >>

Re: Maven 4.0.0

On Sat 4 Nov 2017 at 13:18, Paul Hammant wrote: > > > > > > > > > > > > *3. More pluggable dependency resolver:* > > > > > > > I am willing to let this be optional scope for now. May be yanked if too > > risky or not ready in time > > > > > > > I don't see how you can even make

Re: Maven 4.0.0

> > > > > > > *3. More pluggable dependency resolver:* > > > > I am willing to let this be optional scope for now. May be yanked if too > risky or not ready in time > > > I don't see how you can even make it optional without a pom specified way of saying "not maven central, this way/place instead"

Re: Maven 4.0.0

On Sat 4 Nov 2017 at 12:24, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > On Sat 4 Nov 2017 at 12:20, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > >> The past two days, Hervé, Robert and I have been discussing our next >> steps. >> >> I think we have a

Re: Maven 4.0.0

On Sat 4 Nov 2017 at 12:50, Paul Hammant wrote: > To add to scope for Maven 4, IMO: > > *1. tag could have an optional arg:* > > > my-team,mycorp > com.thoughtworks.xstream > xstream > 1.4.10 > No. We are pushing pom model changes to 5.0.0 (as modelVersion

Re: Maven 4.0.0

On Sat 4 Nov 2017 at 12:49, Michael Osipov wrote: > Am 2017-11-04 um 13:20 schrieb Stephen Connolly: > > The past two days, Hervé, Robert and I have been discussing our next > steps. > > > > I think we have a semi-consensus which I want to bring back to the list: > > > > We

Re: Maven 4.0.0

To add to scope for Maven 4, IMO: *1. tag could have an optional arg:* my-team,mycorp com.thoughtworks.xstream xstream 1.4.10 In the above, central is not checked at all. my-team and my-corp are defined elsewhere. *2. GAV as a first class thing (optional):*

Re: Maven 4.0.0

Am 2017-11-04 um 13:20 schrieb Stephen Connolly: The past two days, Hervé, Robert and I have been discussing our next steps. I think we have a semi-consensus which I want to bring back to the list: We keep 3.5.x as a stable branch with critical bug fixes only We switch master to 4.0.0 and

Re: Maven 4.0.0

On Sat 4 Nov 2017 at 12:20, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > The past two days, Hervé, Robert and I have been discussing our next steps. > > I think we have a semi-consensus which I want to bring back to the list: > > We keep 3.5.x as a stable branch with critical bug

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

Hello all, Let’s see if we can focus on the issue at hand here. 12 apr 2014 kl. 16:59 skrev Jason van Zyl ja...@takari.io: On Apr 12, 2014, at 7:24 AM, Lennart Jörelid lennart.jore...@gmail.com wrote: Oh I know it is the recommended practise, but I believe that particular

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

On Apr 13, 2014, at 8:11 AM, Lennart Jörelid lennart.jore...@gmail.com wrote: Hello all, Let’s see if we can focus on the issue at hand here. 12 apr 2014 kl. 16:59 skrev Jason van Zyl ja...@takari.io: On Apr 12, 2014, at 7:24 AM, Lennart Jörelid lennart.jore...@gmail.com wrote:

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

Isn't the point here that compile scope would turn into runtime scope *when transitive*? So this is not the same as the current trick of putting optionaltrue/optional on a dependency. In general I am in favour if demoting dependencies to runtime when transitive (we always warned this was the

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

The decision was we couldn't add scopes until the modelVersion gets a bump... Which is on the cards for maven 4.0. On Saturday, 12 April 2014, Benson Margulies bimargul...@gmail.com wrote: On Fri, Apr 11, 2014 at 5:57 PM, Stephen Connolly stephen.alan.conno...@gmail.com javascript:; wrote:

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

Op Fri, 11 Apr 2014 23:50:54 +0200 schreef Benson Margulies bimargul...@gmail.com: On Fri, Apr 11, 2014 at 5:29 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 11 April 2014 22:10, Benson Margulies bimargul...@gmail.com wrote: Fwiw, I don't recall the dependency plugin

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

Oh I know it is the recommended practise, but I believe that particular recommendation is flawed since it does not consider the needs of *big* systems with reactors containing lots of projects. Basically the recommendation is to repeat some information (i.e. dependency specs) which is already

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

Le vendredi 11 avril 2014 15:10:01 Chris Graham a écrit : Sent from my iPhone On 11/04/2014, at 9:23 AM, Barrie Treloar baerr...@gmail.com wrote: On 10 April 2014 23:37, Lennart Jörelid lennart.jore...@gmail.com wrote: So ... the consequence of your approach would be that POMs throughout a

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

after thinking more at it, it seems the scope for such artifacts is the plugin parameter name so why not resolve artifacts (or collections of artifacts) when injecting parameters? I'm not sure we really need a need elemen in pom. Regards, Hervé Le samedi 12 avril 2014 10:14:51 Robert

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

What about (ab-)using the runtime scope for this? The core could inspect the pom and inject runtime dependencies into the class path. Regards Mirko -- Sent from my mobile On Apr 12, 2014 2:08 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: after thinking more at it, it seems the scope for such

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

On Apr 12, 2014, at 7:24 AM, Lennart Jörelid lennart.jore...@gmail.com wrote: Oh I know it is the recommended practise, but I believe that particular recommendation is flawed since it does not consider the needs of *big* systems with reactors containing lots of projects. This simply is not

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

On Apr 12, 2014, at 8:02 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: In short, if I've followed and understood this correctly, and I may not have (holiday time for me), it sounds a very bad idea Igon. IMHO, each choice is debatable: this should be an option in compiler plugin. Something

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

I think allowing plugins to resolve things with annotations is not a good idea as we already have project dependencies resolution that happens on the fly per project. This means it's impossible to fully reason about the requirements of a project being built up front. This, in practice, leads to

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

My proposal is strictly to prohibit a plugin from modifying a project's classpath implicitly. That this become fully explicit such that I can remove some of the convoluted logic in the core to account for this. Not allowing plugins to randomly inject new dependencies makes sense. I see some

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

Op Fri, 11 Apr 2014 22:57:01 +0200 schreef Brian Fox bri...@infinity.nu: My proposal is strictly to prohibit a plugin from modifying a project's classpath implicitly. That this become fully explicit such that I can remove some of the convoluted logic in the core to account for this. Not

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

Fwiw, I don't recall the dependency plugin actually injecting stuff into the project class path but equally wish that the copy/unpack goals could simply go away regardless. (in leu of the more normal xxx-dependencies versions) If you make them go away, please find them a new home. I use them

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

On 11 April 2014 22:10, Benson Margulies bimargul...@gmail.com wrote: Fwiw, I don't recall the dependency plugin actually injecting stuff into the project class path but equally wish that the copy/unpack goals could simply go away regardless. (in leu of the more normal xxx-dependencies

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

On Fri, Apr 11, 2014 at 5:29 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 11 April 2014 22:10, Benson Margulies bimargul...@gmail.com wrote: Fwiw, I don't recall the dependency plugin actually injecting stuff into the project class path but equally wish that the

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

That's a sign that we need a new scope... On 11 April 2014 22:50, Benson Margulies bimargul...@gmail.com wrote: On Fri, Apr 11, 2014 at 5:29 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 11 April 2014 22:10, Benson Margulies bimargul...@gmail.com wrote: Fwiw, I

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

On Fri, Apr 11, 2014 at 5:57 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: That's a sign that we need a new scope... The person who decided that we couldn't just use an arbitrary custom value as a scope (thus breaking the tomcat plugin of the time) might want to reconsider that

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

On Fri, Apr 11, 2014 at 5:50 PM, Benson Margulies bimargul...@gmail.comwrote: On Fri, Apr 11, 2014 at 5:29 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 11 April 2014 22:10, Benson Margulies bimargul...@gmail.com wrote: Fwiw, I don't recall the dependency plugin

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

I realize folks are busy, I'll just run with this given I think we all agree immutable classpaths are better and fiddly magic in the core is bad. I'm going to remove the capability to dynamically fiddle with the project classpath and the IT for MNG-4363 will be omitted from the run for Maven

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

So ... the consequence of your approach would be that POMs throughout a maven reactor would have to repeat a dependency declaration if the classes in your maven project directly import a type. This - to me - seems not only complex to resolve in a big reactor, but quite user-unfriendly as well. An

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

On 10 April 2014 23:37, Lennart Jörelid lennart.jore...@gmail.com wrote: So ... the consequence of your approach would be that POMs throughout a maven reactor would have to repeat a dependency declaration if the classes in your maven project directly import a type. This - to me - seems not

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

On Apr 10, 2014, at 10:07 AM, Lennart Jörelid lennart.jore...@gmail.com wrote: So ... the consequence of your approach would be that POMs throughout a maven reactor would have to repeat a dependency declaration if the classes in your maven project directly import a type. This - to me - seems

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

Sent from my iPhone On 11/04/2014, at 9:23 AM, Barrie Treloar baerr...@gmail.com wrote: On 10 April 2014 23:37, Lennart Jörelid lennart.jore...@gmail.com wrote: So ... the consequence of your approach would be that POMs throughout a maven reactor would have to repeat a dependency

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

On 11 April 2014 14:40, Chris Graham chrisgw...@gmail.com wrote: Sent from my iPhone On 11/04/2014, at 9:23 AM, Barrie Treloar baerr...@gmail.com wrote: On 10 April 2014 23:37, Lennart Jörelid lennart.jore...@gmail.com wrote: So ... the consequence of your approach would be that POMs

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

Hi Mark, Mark Derricutt wrote: On 7 Apr 2014, at 12:32, Benson Margulies wrote: We then have other logical classpaths. . Something like javadoc should be able to define another named classpath structure; combining the dependencies of the plugin's implementation with dynamic code (doclets,

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

Hi Jason, Jason van Zyl wrote: Hi, I started making of list of things I'd like to remove in Maven 4.0.0, but I would like to start getting some agreement on what we can yank and this is the first concrete request. I would like to remove the ability for plugins to magically inject

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

I don't understand the difference between what you suggest here, Mark, and simply disabling transitive dependencies. Could you elaborate somewhat? 2014-04-07 3:41 GMT+02:00 Mark Derricutt m...@talios.com: On 7 Apr 2014, at 12:32, Benson Margulies wrote: We then have other logical

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

I believe he's talking about what's mentioned here (see the asterix): http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope /Anders On Mon, Apr 7, 2014 at 9:37 AM, Lennart Jörelid lennart.jore...@gmail.comwrote: I don't understand the

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

Just wanted to through 2c in. Jason, you mentioned supporting other uses cases such an Android builds. I thought I'd explain what's required from that perspective. The Android team have defined an Android archive (AAR) that holds a JAR and various Android resources. When the AAR is declared as a

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

Yes, I realize what Mark was referring to - but I still cannot see the point in having to repeat oneself WRT importing an already imported compile-scope dependency in all projects where it would be used. This would imply loads of redundant imports in all dependent poms in a multi-module reactor

  1   2   >