Re: Classloader hierarchy with extensions

Have you seen [1]? Not sure how much Maven 3.x changed since I wrote that page, but multi-artifact extensions needed META-INF/maven/extension.xml descriptor to defined what artifacts are part of the extension and what are exported to the plugins. [1]

Re: Help with testing on OS/X 10

To make sure I understand, you need somebody to run that test in a Docker container running on OS/X host, did I get it right? The reason I ask, Docker runs containers in a linux virtual machine on OS/X hosts, which is quite different environment compared to what I _think_ the bug reporter is

Re: beam leaving maven, anything doable?

I wouldn't bother with Takari local repository, it's broken broken, see [1] and [2]. Default Aether local repository impl is thread-safe enough, at least when local repository is used from single-process multi-threaded build. [1] https://github.com/takari/takari-local-repository/issues/4 [2]

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

hint of > “plugin” would make sense to me) > > Alternatively, we document “thou shalt not” and be done with it... > > But these are the kinds of things we need to resolve before I feel I can > close the 3.5.1 vote one way or another. > > -- Regards, Igor > On Sun 24 Sep 2017 at 20:06, Igor Fed

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

is too soon I can see if I have a window later this week > > On Sun 24 Sep 2017 at 18:58, Igor Fedorenko <i...@ifedorenko.com> wrote: > > > See my answers/comments inline > > > > > > On Sun, Sep 24, 2017, at 12:07 PM, Stephen Connolly wrote: > > > https

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

ompat behaviour. > I'm keeping the 3.5.1 release in staging until we get a clear vision for > how we want to have classloading so that I can assess whether the 3.5.1 > actuality is only moving nearer to the vision (ok to release) or has > moved > nearer in some ways but further in

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

lly > <stephen.alan.conno...@gmail.com> wrote: > > > On Wed 20 Sep 2017 at 01:29, Igor Fedorenko <i...@ifedorenko.com> wrote: > > > >> In that case, can I suggest couple of changes to the test project > >> > >> * I thinks it makes more sense t

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

e.org/jira/browse/MNG-4381 -- Regards, Igor On Wed, Sep 20, 2017, at 03:12 AM, Stephen Connolly wrote: > On Wed 20 Sep 2017 at 01:29, Igor Fedorenko <i...@ifedorenko.com> wrote: > > > In that case, can I suggest couple of changes to the test project > > > > * I

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

, Stephen Connolly wrote: > Yes, the expectations are key. Depending on what they are we may either > drop 3.5.1 or go ahead as it depends on whether this is more correct than > 3.5.0 or swapping one fix for a bug > > On Tue 19 Sep 2017 at 21:39, Igor Fedorenko <i...@ifedorenko.com&g

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

> >> > >> I hope I didn't make any mistakes. > >> Tomorrow I have enough time to see if I understand what's happening > >> here. > >> > >> I will come back with my conclusions. > >> > >> Robert > >> >

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

TL;DR your test project exposed two existing bugs, one change in behaviour and one quirk I can't explain * Build `` are loaded by two classloaders, which is a bug in DefaultProjectBuildingHelper#createProjectRealm and explains why you see extjar1/extjar2 in the output * ClassRealm does not allow

Re: [VOTE] Release Apache Maven 3.5.1

extensions - unless I misunderstand) > > Once I have the required information I will be better able to assess > whether we should release 3.5.1 and follow up with a quick 3.5.2 or just > drop 3.5.1 and go straight to 3.5.2. > > -Stephen > > On 15 September 2017 at 05:45, Igor Fedo

Re: [VOTE] Release Apache Maven 3.5.1

Steven > Wilson, > Porcupine Tree > > On Sat, Sep 16, 2017 at 12:22 AM, Anders Hammar <and...@hammar.net> > wrote: > > > Based on Igor's feedback I'm changing my vote to +1. > > > > Having this class loader change in a bug fix release is probably not > &

Re: [VOTE] Release Apache Maven 3.5.1

I answered in more details on m2e-dev, but I believe we can compensate for the change from m2e end. In the worst case we'll bundle hacked version of DefaultClassRealmManager with m2e, not ideal, but not the end of the world either. -- Regards, Igor On Fri, Sep 15, 2017, at 07:21 AM, Anders

Re: ATTN: Maven core build is broken

Checking my notes [1], maven-dependency-tree seems to be an interesting case. It calls (or at least used to call) ClassLoader#loadClass to guess which version of aether to use and its tests may misbehave if there is "another" set of aether in system classloader. [1]

Re: ATTN: Maven core build is broken

gin to use env > variable CLASSPATH. > > On Thu, Aug 31, 2017 at 12:24 AM, Igor Fedorenko <i...@ifedorenko.com> > wrote: > > > How does surefire setup jvm classpath when it runs plugin unit and > > integration tests? > > > > -- > > Regards, >

Re: ATTN: Maven core build is broken

How does surefire setup jvm classpath when it runs plugin unit and integration tests? -- Regards, Igor On Wed, Aug 30, 2017, at 05:22 PM, Stephen Connolly wrote: > Unit test is still present in my branch, so should be a yes (if your unit > test works) > > On Wed 30 Aug 2017 at 21:50, Robert

Re: [jira] [Commented] (MNG-6275) ServiceLoaderFactory can't find implementations via ClassRealm

> subprojects as well. > > thanks, > Robert > > ps Stephen gave me the +1 for merging. > > > On Thu, 24 Aug 2017 14:30:00 +0200, Igor Fedorenko (JIRA) > <j...@apache.org> wrote: > > > > > [ > > https://issues.apache.or

Re: Loading providers in named modules with ServiceLoader using a plugin class realm

Can you explain little more why plugins won't see classes loaded by maven core or maven core extensions classloaders? This is implemented in classwords and I was under impression that java9 still allowed custom classloading schemes like what we do or like what OSGi does. -- Regards, Igor On

Re: Is the Maven 3 lifecycle extensions documentation page up to date?

Build extensions are loaded too late to contribute event spies, see how EventSpyDispatcher makes a copy of spies when it's created. And even if EventSpyDispatcher didn't make the copy, I think build extensions are not in scope to capture all events, i.e. things that happen before/after individual

convert maven-resolver-provider to jsr330

I'd like to ask for somebody to second my change described in [MNG-6233]. The change cleans up mixture of jsr330 and plexus annotations used in maven-resolver-provider, leaving only jsr330. The change is small and I believe safe, does not change any user-observable behaviour during normal maven

Re: [MNG-5935] Optional true getting lost in managed dependencies when transitive

+1 -- Regards, Igor On Tue, May 9, 2017, at 05:46 PM, Michael Osipov wrote: > Who seconds MNG-5935 for 3.5.1? > > IT has been added too. Jenkins job is running... > > Michael > > - > To unsubscribe, e-mail:

Re: Maven 3.5.1 - MNG-6025

+1 In the longer run I think we need to review the many caches we have in Maven (including the resolver) and come up with a coherent strategy how to manage those caches. -- Regards, Igor On Wed, May 3, 2017, at 01:49 AM, Karl Heinz Marbaise wrote: > Hi, > > MNG-6025 branch is there, IT's

Re: is 3.5.1 open for business?

tephen Connolly < stephen.alan.conno...@gmail.com> wrote: None here! On Thu 13 Apr 2017 at 23:30, Igor Fedorenko <i...@ifedorenko.com> wrote: Thank you for the explanation, didn't find this job. Now that both branch builds are happy, any objections I merge then to master? -- Regards, I

Re: is 3.5.1 open for business?

Thank you for the explanation, didn't find this job. Now that both branch builds are happy, any objections I merge then to master? -- Regards, Igor On April 13, 2017 1:20:24 PM Karl Heinz Marbaise <khmarba...@gmx.de> wrote: Hi Igor, On 13/04/17 22:09, Igor Fedorenko wrote: I pus

Re: is 3.5.1 open for business?

I pushed my changes to feature branches. How do I trigger CI builds now? -- Regards, Igor On April 7, 2017 9:24:06 AM Igor Fedorenko <i...@ifedorenko.com> wrote: I completely agree we need to prove each code change does not break existing integration tests (and I did run the tests l

Re: is 3.5.1 open for business?

ave an > integration test run before merging. > > We were trying to get consensus on a process but the debate died without > a > conclusion > > On Fri 7 Apr 2017 at 16:21, Igor Fedorenko <i...@ifedorenko.com> wrote: > > > I have two of small-ish fixes

Re: is 3.5.1 open for business?

Thank you for quick response, Karl. I'll create feature branches and push proposed fixes there. Is there a preference between apache and github for code review branches? -- Regards, Igor On Fri, Apr 7, 2017, at 11:32 AM, Karl Heinz Marbaise wrote: > Hi Igor, > >> > >> Also, does anyone know

is 3.5.1 open for business?

I have two of small-ish fixes I'd like to submit, so I was wondering if master is open for 3.5.1 changes already or we want to give it little more time in case we need to release any emergency patches. Also, what is the general bug fixing protocol now, push to directly to master and be prepared

Re: [VOTE] Release Apache Maven 3.5.0

+1 -- Regards, Igor On Tue, Apr 4, 2017, at 10:21 AM, Petr Široký wrote: > +1 (non-binding) > > Tested on several big projects, with dozens of different plugins. No > issue > found. > > On Tue, Apr 4, 2017 at 12:14 AM Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > Hi, > >

Re: maven-3.x-jenkinsfile/embedded-ITs - build #3 - UNSTABLE

TEMY a écrit : > > > thanks for the complements > > > FTR, I checked and added pointers to code > > > > > > Regards, > > > > > > Hervé > > > > > > Le samedi 25 mars 2017, 07:38:30 CET Igor Fedorenko a écrit : > > > > Good des

Re: maven-3.x-jenkinsfile/embedded-ITs - build #3 - UNSTABLE

Good description, Hervé. One small addition. I believe -Pembedded enables "auto" mode, where verifier uses "forked" mode for tests that set environment variables and "embedded" mode for all other cases. Individual ITs can still force forked mode with verifier.setForkJvm, of course. -- Regards,

Re: Implementing XDG base directory support

Can you explain "the obvious reasons"? There are some fundamental problems with current maven local repository approach, but this is the first time I hear somebody complains about the default location, so I'd like to understand better the problem(s) you are trying to solve. -- Regards, Igor On

Re: Launcher script issues in 3.5.0.

On all platforms .mvn/ search is expected to start with directory specified by -f parameter and keep doing "cd .." until it files .mvn/ subdirectory or hits the filesystem root. The idea is to use .mvn/ subdirectory as a marker of multimodule project basedir. The build can be started from any

Re: Injecting MavenProject

MavenProject is injected as a MojoExecutionScope'd component (see DefaultBuildPluginManager around line 119). Since old-style Plexus components are singleton's by default, there is only one AsciidoctorParser instance which holds the first MavenProject it was used with for the entire build. Couple

Re: Fwd: How to name modules, automatic and otherwise

Can't we just block auto-named modules from the build? We control dependencies and should be able to look inside and barf if we don't like anything, no? I realize this does not set good defaults for non-maven projects, so there will be some friction there, but hopefully maven userbase is big

Re: Running a plugin integration test from an IDE?

I don't use intellij, but if you are willing to try eclipse/m2e then there are at least two viable ways to implement "debuggable" integration tests. Personally I prefer takari plugin testing harness [1] (disclosure: I wrote the thing, so I am definitely biased). Alternatively, you can also use

Re: [DISCUSS] How do we want to handle false positives in the integration tests

> B. Fix the test, but exclude the broken versions of Maven from the range with a comment explaining why I sometimes rerun integration tests against released versions of Maven to validate the tests are still working and I know other developers who do that too. Having failures would just mean

Re: Requesting a single Monorepo enhancement for Maven

Don't mean to derail the discussion, but I am wondering if sparse checkout is the last/biggest problem you have to solve to use maven for your "one bg ass trunk". We are using maven for a monorepo (maybe not as "bg ass" as google's but pretty big nonetheless) for few years now and lack

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

+1 -- Regards, Igor On Wed, Jan 4, 2017, at 08:31 AM, Andreas Gudian wrote: > +1 > > > Anders Hammar schrieb am Mi. 4. Jan. 2017 um 13:22: > > > +1 > > > > > > > > /Anders > > > > > > > > On Wed, Jan 4, 2017 at 1:16 PM, Stephen Connolly < > > > >

Re: Maven 3.4.0 Release

No, I meant just eclipse->apache move, not all changes that went into maven-resolver. The idea is to have a release branch we can maintain while things stabilize in master. -- Regards, Igor On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote: > Am 2016-12-18 um 18:44 schrieb Igor Fed

Re: Maven 3.4.0 Release

I wonder if it makes sense to release 3.3.10 with just the new aether and give 3.4 more time to bake on master. -- Regards, Igor On Sun, Dec 18, 2016, at 07:33 AM, Robert Scholte wrote: > I did investigate some time in this request. The conclusion is that the > discussion should be in the

Re: extensions.xml (Re: [4/7] maven git commit: [MNG-6110] Upgrade Aether to Maven Resolver 1.2)

The list of exported artifacts appears to be correct. It effectively removes listed artifacts from plugin realms and forces plugins to use classes exported from core realm. We obviously need to do this org.eclipse.aether artifacts to avoid multiple versions of the same classes present both in

Re: Parent Version maybe not needed in child POM

t;c...@schulte.it> wrote: Am 12/13/16 um 01:33 schrieb Igor Fedorenko: This suggests inefficiency in existing implementation. We use this model internally with some custom optimizations for a very large codebase. Maybe. Netbeans is using the Maven API for all of this. It's like building the full r

Re: Parent Version maybe not needed in child POM

This suggests inefficiency in existing implementation. We use this model internally with some custom optimizations for a very large codebase. -- Regards, Igor On December 12, 2016 3:25:35 PM Christian Schulte <c...@schulte.it> wrote: Am 12/12/16 um 23:23 schrieb Igor Fedorenko: Di

Re: Parent Version maybe not needed in child POM

a single module of a multimodule without -am it is *your* responsibility to add the versions to those dependencies, so these are pulled from a repository. That will still work, but will remove the safety belt (jigsaw(tm)?) Robert On Mon, 12 Dec 2016 23:23:51 +0100, Igor Fedorenko <i...@ifedorenko.com>

Re: Parent Version maybe not needed in child POM

Disagree. I think in most if not all cases we build entire project, not just random part of a project. Regards, Igor On December 12, 2016 11:22:50 AM Christian Schulte wrote: Am 12/12/16 um 10:16 schrieb Tibor Digana: Is it really necessary to specify version of parent

Re: future of aether

https://projects.eclipse.org/projects/technology.aether/reviews/termination-review -- Regards, Igor On December 12, 2016 11:13:28 AM "Manfred Moser" wrote: There should be some eclipse notes about the move of the project to the attic and the migration. But I

Re: Parent Version maybe not needed in child POM

I think this is a good idea. And I'd go one step further and use "versionless" to represent in-reactor version. -- Regards, Igor On December 12, 2016 1:16:49 AM Tibor Digana wrote: Is it really necessary to specify version of parent artifact in ? Suppose we have

Re: Maven 3.4.0 Release

.it> wrote: Am 12/11/16 um 03:29 schrieb Igor Fedorenko: Why do you say Dependency A is transitive? Maven plugin directly depends on Dependency A, so I expect it to be present on the plugin classpath. This is consistent with how project direct optional dependencies are always present on cla

Re: Maven 3.4.0 Release

Why do you say Dependency A is transitive? Maven plugin directly depends on Dependency A, so I expect it to be present on the plugin classpath. This is consistent with how project direct optional dependencies are always present on classpath. Note that the project does not *depend* on the plugin.

Re: [MNG-5761] Dependency management is not transitive.

You are right, I was using the old version of the test project. The latest version does work with 3.4 and does make sense. Thank you for the explanation. -- Regards, Igor On Sat, Nov 19, 2016, at 09:36 PM, Christian Schulte wrote: > Am 11/20/16 um 03:28 schrieb Igor Fedorenko: > > I

Re: [MNG-5761] Dependency management is not transitive.

PM, Christian Schulte wrote: > Am 11/20/16 um 02:56 schrieb Christian Schulte: > > Am 11/20/16 um 00:12 schrieb Igor Fedorenko: > >> Let me rephrase my question. What IT shows how to use parent version > >> ranges with Maven 3.4? > > > > MNG-2199 > > >

Re: [MNG-5761] Dependency management is not transitive.

Schulte wrote: > Am 11/19/16 um 13:35 schrieb Igor Fedorenko: > > What is parent version range syntax that works with 3.4? Or you are > > saying parent version ranges are not supported at all now? > > They got introduced in 3.2.2. This commit > <https://git-wip-us.apach

Re: [MNG-5761] Dependency management is not transitive.

What is parent version range syntax that works with 3.4? Or you are saying parent version ranges are not supported at all now? -- Regards, Igor On Fri, Nov 18, 2016, at 10:57 PM, Christian Schulte wrote: > Am 11/19/16 um 03:58 schrieb Igor Fedorenko: > > Thank you for the

Re: [MNG-5761] Dependency management is not transitive.

; Am 11/17/16 um 21:43 schrieb Christian Schulte: > > Am 11/17/16 um 06:00 schrieb Igor Fedorenko: > >> FWIW, I ran maven integration tests (commit 73a2b7) against current > >> maven master and got this > >> > >>> Tests run: 771, Failures: 3, Errors: 21, S

Re: [MNG-5761] Dependency management is not transitive.

FWIW, I ran maven integration tests (commit 73a2b7) against current maven master and got this > Tests run: 771, Failures: 3, Errors: 21, Skipped: 0 Running the same test checkout with Maven 3.3.9 > Tests run: 771, Failures: 0, Errors: 0, Skipped: 0 -- Regards, Igor On Wed, Nov 16, 2016, at

Re: Maven 3.4.0-SNAPSHOT 2016-10-09 and setttings.xml?

6:22:20 +0200, Christian Schulte <c...@schulte.it> > wrote: > > > Am 10.10.2016 um 16:16 schrieb Christian Schulte: > >> Am 10.10.2016 um 15:35 schrieb Igor Fedorenko: > >>> It is common to use repository with id=central in settings.xml to > >>&g

Re: Maven 3.4.0-SNAPSHOT 2016-10-09 and setttings.xml?

Are repositories and other configuration defined in user settings.xml take precedence over global settings.xml? -- Regards, Igor On Mon, Oct 10, 2016, at 10:16 AM, Christian Schulte wrote: > Am 10.10.2016 um 15:35 schrieb Igor Fedorenko: > > It is common to use repository with i

Re: Maven 3.4.0-SNAPSHOT 2016-10-09 and setttings.xml?

It is common to use repository with id=central in settings.xml to override central location. This functionality should continue to work, regardless how it is implemented in Maven internally. -- Regards, Igor On Mon, Oct 10, 2016, at 09:10 AM, Christian Schulte wrote: > Am 10/10/16 um 14:45

Re: Using maven-artifact-transfer component

} > > > Another good idea / hint? > > Kind regards > Karl Heinz Marbaise > > On 04/09/16 20:29, Karl Heinz Marbaise wrote: > > Hi Igor, > > > > On 04/09/16 19:40, Igor Fedorenko wrote: > >> Sisu does not print component lookup exceptio

Re: Using maven-artifact-transfer component

Sisu does not print component lookup exceptions by default, you need to run jvm with -Dsisu.debug system property to see them (and ton of other sisu debug information). -- Regards, Igor On Sun, Sep 4, 2016, at 08:17 AM, Karl Heinz Marbaise wrote: > Hi, > > currently I'm trying to implement an

Re: [DISCUSSION] finishing Aether import: help find a new name

On Fri, Aug 26, 2016, at 12:51 AM, Michael Osipov wrote: > Am 2016-08-25 um 23:20 schrieb Hervé BOUTEMY: > > ok, we can change groupId > > > > everybody ok for: > > - name: "Artifact Resolver" > > Not Maven Artifact Resolver? > > > - groupId: org.apache.maven.resolver > > - artifactId:

Re: Building Maven from scratch

Out of curiosity, what is your usecase? -- Regards, Igor On Tue, Aug 23, 2016, at 02:25 AM, Björn Höfling wrote: > I want to build maven without haven _ANY_ maven/plugin binary. How can > I do that? > > I found out that there is a build.xml and it start building a first > version of Maven.

Re: Maven Core Command Line

+1 Sorry I missed this in my original implementation. I should have added a test too. -- Regards, Igor On Sat, Aug 6, 2016, at 10:15 AM, Christian Schulte wrote: > Am 08/06/16 um 16:08 schrieb Karl Heinz Marbaise: > > So the question is WDYT ? > > +1 > > Consistency. Almost all properties

Re: [DISCUSSION] finishing Aether import: help find a new name

Tycho does not use Aether to resolve p2 artifacts. -- Regards, Igor On Thu, Jul 28, 2016, at 10:07 AM, Anders Hammar wrote: > This might be a language thing. "Maven Artifact Resolver API" makes me > think this is only for resolving Maven artifacts, but my understanding is > that p2 artifacts is

Re: Is there a reason extensions in ".mvn/extensions.xml" don't seem to support configuration?

The latter. My original prototype had configuration support (may still have the code somewhere, not sure) but we took it out because we didn't have immediate usecase and didn't want to commit to any specific format and api without clear understanding how it was going to be used.. -- Regards,

Re: Maven Embedder and Lifecycle extensions

extensions.xml was meant for "non-functional" extensions, things like Takari SmartBuilder, which improves multi-threaded build scheduling but does not affect overall build results. If your extensions change build behaviour in non-trivial ways, your build is not Maven any more and you should expect

Re: Integrating maven with other tooling

n 3 June 2016 at 13:36, Igor Fedorenko <i...@ifedorenko.com> wrote: > > > On Mon, May 30, 2016, at 11:34 PM, James Roper wrote: > > > > > > One question that I'm trying to solve now, when resolving dependencies, > > > if > > > you want to do so w

Re: Maven Memory Consumption

Somewhat related, Jason convinced me to opensource better logging support for multithreaded builds I implemented some time ago. https://github.com/takari/concurrent-build-logger -- Regards, Igor On Thu, Jun 2, 2016, at 11:37 PM, Manfred Moser wrote: > If we plan to switch it to on be default

Re: Integrating maven with other tooling

On Mon, May 30, 2016, at 11:34 PM, James Roper wrote: > > One question that I'm trying to solve now, when resolving dependencies, > if > you want to do so without actually building the project it seems that you > would probably have to create your own WorkspaceReader implementation > that > will

Re: Maven Memory Consumption

I wonder if this fix also solves "remote shared parent" memory inefficiency described in https://issues.apache.org/jira/browse/MNG-5669 -- Regards, Igor On Tue, May 31, 2016, at 06:14 PM, Karl Heinz Marbaise wrote: > Hi, > > tested without the patch (-Xmx6g) ...run time for the test project

Re: Integrating maven with other tooling

There is no good/sane Maven embedding API. You really need to reimplement relevant parts of MavenCli and DefaultMaven in your code. You can check how we do this in m2e [1], although embedding Maven in long-running OSGi application certainly adds its own lever of complexity. [1]

Re: [VOTE] Retire Maven Ant Tasks

+1 -- Regards, Igor On Mon, May 16, 2016, at 01:43 AM, Anders Hammar wrote: > +1 > > /Anders (mobile) > On May 15, 2016 23:24, "Michael Osipov" wrote: > > > Hi, > > > > this component hasn't been touched for years effectively and we rely now > > on Maven for Maven (dog

Re: Why is MavenProject.getDependencyArtifacts() deprecated?

https://issues.apache.org/jira/browse/MNG-5818 Also, note that the method only returns direct project dependencies and the result is only populated during build lifecycle execution. In most cases you likely want getDependencies or getArtifact. -- Regards, Igor On Mon, Feb 22, 2016, at 03:45

one IT fails with the latest master

MavenITmng5227DependencyOptionalFlagManagementTest fail when I run Maven ITs with the latest master. Can somebody confirm the test works for them before I start looking for problems in my environment? I am on OSX and use java 1.7.0_79-b15 to run the tests. -- Regards, Igor

Re: [Jigsaw] Fwd: Specifying module paths

This is a very good proposal. My only suggestion is to extend javax.tools CompilationTask API to take modulepath map as in-memory parameter. Not a big deal, but it'll be silly to write properties file to disk for it to be immediately read by the code executed in the same jvm. -- Regards, Igor

Re: Log4j Warning

u did the work > > and have consistently done work in the core that you should really be able > > to make the change. I was just trying to be consistent with what we said > > we’d do. > > > > > On Jan 6, 2016, at 10:26 PM, Igor Fedorenko <i...@ifedorenko.com> wro

Re: NoSuchMethodError maven-plugin-testing-harness:3.0.0

You should really try Takari plugin testing harness. It's good, works for all 3.x maven versions too. -- Regards, Igor On Thu, Jan 7, 2016, at 08:04 AM, Stephen Connolly wrote: > Ha! I'm knee deep in trying to switch maven-release over to Maven 3 and > fighting the AbstractReleaseTestCase is

Re: Log4j Warning

It is already possible to implement advanced logging as an extension. This was what I did when my offer to provide multi-threaded logging support in the core was turned down on this list few months ago. So at this point the discussion/decision is purely political. -- Regards, Igor On Wed, Jan

Re: [Jigsaw] classpaths and modulepaths

On Mon, Jan 4, 2016, at 03:18 PM, Robert Scholte wrote: > Op Mon, 04 Jan 2016 00:28:24 +0100 schreef Igor Fedorenko > <i...@ifedorenko.com>: > > > Good you agreed we don't need to add modulepath to MavenProject :-) > > > > I see few ways forward with java

Re: [Jigsaw] classpaths and modulepaths

I > also need something which points to target/mods. > > Options I can think of: > - there's one interesting method still available: artifact.addMetadata(). > Maybe I can store data here > - purely based on convention (no configuration): if file points to > target/mods

Re: [Jigsaw] classpaths and modulepaths

What changes to MavenProject do you have in mind? -- Regards, Igor On Sun, Jan 3, 2016, at 11:55 AM, Robert Scholte wrote: > Hi, > > I've been able to locally *package* a subset of the MavenModules enriched > with module-info. > > mvn package -pl :maven-settings-builder -am

Re: [Jigsaw] classpaths and modulepaths

; > Robert > > Op Sun, 03 Jan 2016 18:09:52 +0100 schreef Igor Fedorenko > <i...@ifedorenko.com>: > > > What changes to MavenProject do you have in mind? > > - > To unsubscribe,

Re: [Jigsaw] classpaths and modulepaths

ject? I hope not, but it would be a simple > solution to keep the classpath in tact, but it doesn't solve the > modulepath problem required by other modules of the multimodule project. > > Robert > > Op Sun, 03 Jan 2016 18:59:25 +0100 schreef Igor Fedorenko > <i..

Re: RFE support jar as modulepath argument

Exploded modules are useful in developer usecases. For example, I work on a codebase with 25M+ lines of code spread over 1100+ projects. To save time, we suppress packaging of jars when developers run builds locally. -- Regards, Igor On Fri, Dec 4, 2015, at 07:03 AM, Alan Bateman wrote: > > On

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

I'd like to see Java 8 in maven core too. I don't particularly care if it will be 3.4.x or 4.0.x. -- Regards, Igor On Mon, Nov 30, 2015, at 05:52 PM, Mark Derricutt wrote: > On 1 Dec 2015, at 11:44, Stephen Connolly wrote: > > > In my view there are some advantages to using the 4.0.x version

Re: Plugin Testing Harness 2.1 - Problem with Default Values

I think you need to specify all parameter values in test pom.xml, at least this used to be one of annoying limitations of apache plugin harness in the past. Personally I gave up on apache harness long time ago. The harness I've written at Takari works much better everywhere I used it and I am

Re: Shade plugin from directories instead of jars in multimodule builds ?

lly means there is no "good" use case for letting shade > read classes from target/classes within the reactor(?) > > Kristian > > > 2015-11-14 20:15 GMT+01:00 Igor Fedorenko <i...@ifedorenko.com>: > > Run the build with -X and see what mojos are executed

Re: Shade plugin from directories instead of jars in multimodule builds ?

I believe "mvn clean package" runs the default lifecycle twice, first to "package" phase, when reactor dependencies are resolved to packaged jars, then to "test" phase, when reactor dependencies are resolved to target/classes folders. I am surprised shade plugin is called during "test" run at all.

Re: Shade plugin from directories instead of jars in multimodule builds ?

https://issues.apache.org/jira/browse/MSHADE-171, single threaded. > Shade is bound to package. > > I really dont understand this :) > > K > > > 2015-11-14 13:57 GMT+01:00 Igor Fedorenko <i...@ifedorenko.com>: > > I believe "mvn clean package" run

Re: [VOTE] Maven 3.3.9

+1 -- Regards, Igor On Tue, Nov 10, 2015, at 12:16 PM, Jason van Zyl wrote: > Hi, > > Time to release Maven 3.3.9! > > Here is a link to the issues resolved: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12333074 > > Staging repo: >

Re: [VOTE] Maven 3.3.7

ter > (f684761dee739b4ec8a7e6db5a0a6a0b809e66c9) fixes your issue? > > > On Oct 29, 2015, at 5:21 PM, Igor Fedorenko <i...@ifedorenko.com> wrote: > > > > -1 > > > > 3.3.7 fails with string-index-out-of-range exception when parent pom has > >

Re: [VOTE] Maven 3.3.8

+1 -- Regards, Igor On Fri, Oct 30, 2015, at 12:58 PM, Jason van Zyl wrote: > Hi, > > Time to release Maven 3.3.8! > > Here is a link to the issues resolved: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12333074 > > Staging repo: >

Re: [VOTE] Maven 3.3.7

-1 3.3.7 fails with string-index-out-of-range exception when parent pom has scm and I assume other elements with empty child I think the problem was introduced with recent changes in DefaultInheritanceAssembler, at least the problem goes away if I replace the class with the

Re: MNG-5899 Project models are no longer mutable in reactor

, Oct 27, 2015, at 10:12 AM, Benson Margulies wrote: > On Tue, Oct 27, 2015 at 9:58 AM, Igor Fedorenko <i...@ifedorenko.com> > wrote: > > Did you really mean "the core model has to be mutable"? The rest of your > > message appears to suggest you do not want the model to

Re: MNG-5899 Project models are no longer mutable in reactor

Did you really mean "the core model has to be mutable"? The rest of your message appears to suggest you do not want the model to be mutable, but I am not sure. In any case, I think the core model must not be mutable. If the core model is mutable, this means pom.xml is not the ultimate source of

Re: Starting to cut Maven 3.3.7

This was announced 7 days ago on this list http://mail-archives.apache.org/mod_mbox/maven-dev/201510.mbox/%3CFFA7C22B-DD49-40C7-8D78-2C6D02B87D97%40takari.io%3E -- Regards, Igor On Tue, Oct 27, 2015, at 09:54 AM, Michael Osipov wrote: > > I’m going to start cutting the 3.3.7 now. > > Jason, >

Re: Can anyone explain this missing plexus utils class?

I think you meant [foo], i.e. both square brackets, for version range that means "version foo and nothing else". -- Regards, Igor On Tue, Oct 13, 2015, at 08:44 AM, Benson Margulies wrote: > I got a lecture on this from Stephen Connolly, who took some time out > from Marathon training to

Re: Dependencies in Dep Mngt without version

I believe MNG-5727 is a different issue. Here you have unused invalid element. I don't have strong opinion if such elements should cause build failure or ignored. -- Regards, Igor On Wed, Oct 7, 2015, at 05:24 PM, Michael Osipov wrote: > Hi folks, > > I am currently trying to fix MDEP-506

  1   2   3   4   5   >