-classloading.html
--
Regards,
Igor
On Sat, Oct 3, 2020, at 19:49, Michael Osipov wrote:
> Folks,
>
> hopefully someone of you is able to make me understand the following:
>
> Maven 3 class loading [1] says that extensions are available to
> plugins.
> E.g., Wagon FTP should be avai
configuration details missing from the original report.
--
Regards,
Igor
On Fri, Apr 13, 2018, at 4:32 AM, Tibor Digana wrote:
> Hi All,
>
> I want to ask you to help us with testing one issue which can be reproduced
> only on OS/X 10.
> I tried to run a small test on Ubuntu 17 x86
ssues/4
[2] https://github.com/takari/takari-local-repository/issues/5
--
Regards,
Igor
On Mon, Nov 27, 2017, at 03:28 PM, Michael Osipov wrote:
> I really would like to see the same numbers with Takari Smart Builder
> and thread-safe local repo module.
>
> Am 2017-11-27 um 20:52 schr
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 S
quot; to
mess with classloading in bug fix release, then maybe do what Anders
suggests (I think), bump the version to 3.6.0, document the behaviour we
have on master and move on.
--
Regards,
Igor
On Sun, Sep 24, 2017, at 02:28 PM, Stephen Connolly wrote:
> I wonder should we do a hangout
safer to keep the current maven2-compat 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
be used in real life.
[1]
https://github.com/apache/maven/blob/maven-3.5.1/maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuildingHelper.java#L210-L219
--
Regards,
Igor
On Wed, Sep 20, 2017, at 03:29 AM, Robert Scholte wrote:
> On Wed, 20 Sep 2017 09:12:47 +0200, Ste
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 wrote:
>
> > In that case, can I suggest couple of changes to the test project
> >
> > * I thinks it makes more sense t
maven2-compat mode and are not representative of likely real-world
extensions.
* I think we should introduce META-INF/maven/extension.xml to the test
extensions. This metadata what introduced to configure classpath
visibility, so lets use it.
--
Regards,
Igor
On Tue, Sep 19, 2017, at 05:12 PM
,
Igor
On Tue, Sep 19, 2017, at 03:52 PM, Robert Scholte wrote:
> Let's do it like this:
> https://cwiki.apache.org/confluence/download/attachments/2329841/classrealms.pdf?api=v2
>
> Robert
>
> On Tue, 19 Sep 2017 21:08:39 +0200, Stephen Connolly
> wrote:
>
> &
it impossible to load the same
resource from multiple plugins/extensions.
* Extensions plugins cannot access their own private (i.e. not exported)
resources via TCCL, this is change in behaviour introduced by mng-6209
fix
Hope this helps
--
Regards,
Igor
On Mon, Sep 18, 2017, at 11:46 AM, Ste
to project realm for projects that have
extensions (and to plugin realm otherwise) during plugin execution.
Problem is, neither project realm nor any of the plugin realms have
access to jvm extensions classloader, so ServiceLoader can't get classes
from there.
--
Regards,
Igor
On Fri, Sep
classpath too much.
--
Regards,
Igor
On Fri, Sep 15, 2017, at 08:32 AM, Mark Derricutt wrote:
> Would it be possible to handle this in a somewhat similar way to
> threadSafe
> mojos - some form of plugin flag that says "extensionSafe" [1], that if
> the
> plugin has true dec
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, A
com/takari/takari-plugin-testing-project/blob/master/classloading.md
--
Regards,
Igor
On Thu, Aug 31, 2017, at 09:28 AM, Stephen Connolly wrote:
> Do we have a list of integrator contacts we can send an FYI to?
>
> By the sounds of it, we should be OK for merging this fix - at least for
>
Also, if you decide to go ahead with this change, PARENT_CLASSLOADER
will be used as both URLClassLoader parent and ClassRealm parent, which
I think is redundant.
--
Regards,
Igor
On Wed, Aug 30, 2017, at 06:45 PM, Tibor Digana wrote:
> Class-Path is used in Manifest unless you configure the p
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 2
Sorry, didn't mean to request a rollback, was merely trying to highlight
areas likely affected by the change.
--
Regards,
Igor
On Thu, Aug 24, 2017, at 12:33 PM, Robert Scholte wrote:
> Hi Igor,
>
> moving this to dev-list.
> I've asked an explanation of the Java develop
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
O
ari.io/book/91-maven-classloading.html
--
Regards,
Igor
On Thu, Jun 1, 2017, at 06:22 AM, Paul Hammant wrote:
> This page:
> https://maven.apache.org/examples/maven-3-lifecycle-extensions.html
>
> My problem: I have an extension that works just fine
> in ${maven.home}/lib/ext/ isn'
maven build and all ITs pass.
[MNG-6233] https://issues.apache.org/jira/browse/MNG-6233
--
Regards,
Igor
PS: Unfortunately I already submitted the change to master (by bad,
sorry about that) but will revert the change if I don't get +1s or get
any -1s within
+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 unsubscri
+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 th
Will do. Thank you.
--
Regards,
Igor
On April 13, 2017 3:55:43 PM Stephen Connolly
wrote:
Just be sure to delete the branch after merging so that the job will get
cleaned up (in 3 days time - retention strategy)
On Thu 13 Apr 2017 at 23:53, Stephen Connolly <
stephen.alan.co
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 wrote:
Hi Igor,
On 13/04/17 22:09, Igor Fedorenko wrote:
I pushed my changes to fe
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 wrote:
I completely agree we need to prove each code change does not break
existing integration tests (and I did run the tests locally with my
changes, fwiw
I completely agree we need to prove each code change does not break
existing integration tests (and I did run the tests locally with my
changes, fwiw)
--
Regards,
Igor
On Fri, Apr 7, 2017, at 11:58 AM, Stephen Connolly wrote:
> I want every issue that changes code (not docs or javadocs) to h
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,
> >>
> >&
nyone know how to get my JIRA account fixed so I can
assign/close/etc bugs?
Thank you in advance.
https://issues.apache.org/jira/browse/MNG-6210
https://issues.apache.org/jira/browse/MNG-6209
--
Regards,
Igor
-
To unsubscri
+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...@
rifier or force "forked"
mode from the affected tests.
--
Regards,
Igor
On Tue, Mar 28, 2017, at 03:51 AM, Stephen Connolly wrote:
> Does it force a fork if there is a .mvn/maven.config file to be picked
> up?
>
> On Tue 28 Mar 2017 at 07:07, Hervé BOUTEMY wrote:
>
&g
rkJvm, of
course.
--
Regards,
Igor
On Sat, Mar 25, 2017, at 01:02 AM, Hervé BOUTEMY wrote:
> ok, let's share what I know from embedded ITs (sorry, long email, but
> IMHO
> useful to share some details):
>
> - by default, Verifier forks for every IT and launches Maven wi
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.
--
Re
d from any submodule, but multimodule
project basedir will be always the same.
--
Regards,
Igor
On Wed, Feb 22, 2017, at 09:19 PM, Christian Schulte wrote:
> Both issues seem to be related to MNG-5889. MNG-5889 branch created. If
> no one objects, I'll merge it to master when th
r-lookup").
If AsciidoctorParser must be a singleton, then you need to use
javax.inject.Provider to access current context MavenProject instance.
Hope this helps.
--
Regards,
Igor
On Tue, Feb 21, 2017, at 05:12 PM, Hervé BOUTEMY wrote:
> ie. see line 61 of the maven-plugin-tools annotations re
ase is big
enough to create sufficient pressure for non-maven projects to provide
explicit module names.
--
Regards,
Igor
On Thu, Feb 16, 2017, at 01:11 PM, Brian Fox wrote:
> I generally agree the concerns were mostly ignored. Specifically the
> dangers in not carefully approaching and settin
r/
[3] https://github.com/ifedorenko/com.ifedorenko.m2e.mavendev
--
Regards,
Igor
On Thu, Feb 16, 2017, at 04:03 AM, org.apache.maven.u...@io7m.com wrote:
> On 2017-02-14T15:13:46 +
> org.apache.maven.u...@io7m.com wrote:
> >
> > I can't work out how to run this integration
>
ean tests are broken and can be
ignored IMHO.
--
Regards,
Igor
On Tue, Jan 31, 2017, at 06:42 AM, Stephen Connolly wrote:
> We have kind of established a consensus on how to handle the case where
> we
> want to change the specification of how Maven works going forward.
> Specifically, if
e user, with the required dependencies coming
as prebuilt artifacts from a repository. This is conceptually what
--projects and -SNAPSHOTs claim do, only hardened to scale for large
number of modules and developers.
--
Regards,
Igor
On Tue, Jan 24, 2017, at 12:05 AM, Paul Hammant wrote:
> O
+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
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
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
.html
--
Regards,
Igor
On Sun, Dec 11, 2016, at 05:41 PM, Christian Schulte wrote:
> Can someone please take a look at this and verify the changes are
> correct? I am not sure the former artifacts also need to be exported.
> For the sonatype ones the package names are different. For the ecli
But reactor dependencies make perfect sense in m2e! Also, keep in mind that
we are talking about new maven concept, it does not currently exist and
can't be supported by m2e, netbeans or any other existing tool.
--
Regards,
Igor
On December 12, 2016 4:38:30 PM Christian Schulte wrote:
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 wrote:
Am 12/12/16 um 23:23 schrieb Igor Fedorenko:
Disagree. I think in most
-am should be aware of entire multimodule project and resolve in reactor
dependencies accordingly.
--
Regards,
Igor
On December 12, 2016 2:36:08 PM "Robert Scholte" wrote:
Absolutely agreeing with Igor. And if you want to be able to build a
single module of a multimodule without
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 artifact in
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 dont know where the
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 mult
I'm traveling until next weekend and won't be able to review your changes
properly until I'm back. I do want to stress that maven plugins are not
dependencies, they are resolved the same way as projects.
--
Regards,
Igor
On December 11, 2016 1:59:39 PM Christian Schulte wr
. From dependency
resolution point of view, the plugin is standalone "top-level" entity at
the same level as the project.
--
Regards,
Igor
On Sat, Dec 10, 2016, at 06:26 PM, Christian Schulte wrote:
> Am 12/10/16 um 13:39 schrieb Hervé BOUTEMY:
> > I just tested the patch ass
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
ROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[1]
https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=tree;f=core-it-suite/src/test/resources/mng-2199-parent-version-range;hb=HEAD
--
Regards,
Igor
On Sat, Nov 19, 2016, at 09:10
Let me rephrase my question. What IT shows how to use parent version
ranges with Maven 3.4?
We actually use parent version ranges quite extensively internally, so I
am trying to assess the impact of 3.4 changes for our users.
--
Regards,
Igor
On Sat, Nov 19, 2016, at 05:57 PM, Christian
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 analysis
gate these further.
MavenITmng5640LifecycleParticipantAfterSessionEnd.testBuildErrorRt
worked for me under linux with java7 but failed on osx with java8. I did
not investigate this further.
I agree with the rest of your conclusion.
--
Regards,
Igor
On Thu, Nov 17, 2016, at 09:16 PM, Christian Schulte wrote
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, 20
e versions of maven side-by-side (think jenkins, for example).
And more generally, forcing settings.xml update is going to be a major
effort for larger organizations, with 100x or 1000x developers.
--
Regards,
Igor
On Mon, Oct 10, 2016, at 02:33 PM, Robert Scholte wrote:
> On Mon, 10 Oct 2016 1
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 id=c
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
Not sure I follow. Are you asking about ArtifactDeployer maven-compat or
some other class? If you can share your code via github (or some other
means) and tell me how to reproduce the problem, I'll have a look.
--
Regards,
Igor
On Sun, Sep 4, 2016, at 02:59 PM, Karl Heinz Marbaise wrote:
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 t
org.apache.maven.resolver
> > - artifactId: resolver(-*)
>
> Same here maven-resolver-...?
>
>
I like these better, artifactId in particular.
--
Regards,
Igor
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
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
> v
+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.
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
> t
-
Regards,
Igor
On Tue, Jul 5, 2016, at 04:57 AM, Christofer Dutz wrote:
> Hi,
>
>
> I just noticed that the extensions.xml doesn't seem to support
> configuring an extension. Is this intentional because it would break
> things or is it simply that none needed or imp
uld expect to have to change tooling around the build.
--
Regards,
Igor
On Wed, Jun 15, 2016, at 01:02 AM, Mark Derricutt wrote:
> Hey all,
> At work we're now making use of some custom
> AbstractMavenLifecycleParticipant's declared in .mvn/extensions.xml
> and whilst
m2e uses WorkspaceReader to implement this
http://git.eclipse.org/c/m2e/org.eclipse.m2e.workspace.git/tree/org.eclipse.m2e.workspace.cli/src/main/java/org/eclipse/m2e/workspace/internal/Maven31WorkspaceReader.java
--
Regards,
Igor
On Fri, Jun 3, 2016, at 02:17 AM, James Roper wrote:
> O
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 defa
I completely misunderstand the question?
--
Regards,
Igor
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
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 f
://git.eclipse.org/c/m2e/m2e-core.git/tree/org.eclipse.m2e.core/src/org/eclipse/m2e/core/internal/embedder/MavenImpl.java
--
Regards,
Igor
On Mon, May 30, 2016, at 09:33 PM, James Roper wrote:
> On 30 May 2016 at 17:39, Michael Osipov <1983-01...@gmx.net> wrote:
> >
> > I think, you
+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
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 AM
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
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,
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 AbstractRe
%40webmail.messagingengine.com%3E
--
Regards,
Igor
On Thu, Jan 7, 2016, at 09:01 AM, Arnaud Héritier wrote:
> And couldn't we have some optional extensions in the distribution ?
> Not activated by default but that users can easily activate by moving a
> jar
> ?
>
> On Thu, Jan 7, 201
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 6
On Mon, Jan 4, 2016, at 03:18 PM, Robert Scholte wrote:
> Op Mon, 04 Jan 2016 00:28:24 +0100 schreef Igor Fedorenko
> :
>
> > Good you agreed we don't need to add modulepath to MavenProject :-)
> >
> > I see few ways forward with java 9 module system support
t directories follow
modulepath naming convention. this is my least favourite approach
because I think it makes module system support too invasive. we can
probably make it almost invisible to the enduser with some clever
super-pom profile, so it may be not so bad.
--
Regards,
Igor
On Sun, Jan 3, 2016,
adding modulepath info to MavenProject is going to help?
--
Regards,
Igor
On Sun, Jan 3, 2016, at 02:30 PM, Robert Scholte wrote:
> I would really prefer a solution without changing Maven Project,
> especially since we're talking about non-generic or language-specific
> elements.
#x27;t use
existing getCompileClasspathElements/getTestClasspathElements in takari
lifecycle and I suspect I will not be able to use
getCompileModulepathElements/getTestModulepathElements either.
--
Regards,
Igor
On Sun, Jan 3, 2016, at 12:35 PM, Robert Scholte wrote:
> getCompileModulepathE
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 :mav
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:
>
&
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 u
I am pretty sure mojo defaults are used by the tests as
expected.
--
Regards,
Igor
On Sun, Nov 22, 2015, at 11:13 AM, Karl Heinz Marbaise wrote:
> Hi,
>
> currently i'm trying to fix some issues in the maven-ejb-plugin and
> within the test there is a setup like this:
>
&
If shade plugin is always bound to package phase, then I'd say it should
not get reactor dependency target/classes folders under normal
circumstances.
--
Regards,
Igor
On Sun, Nov 15, 2015, at 03:21 PM, Kristian Rosenvold wrote:
> Yeah, I sort of understand.
>
> But that really
) @
mshade171-base ---
Although jar:jar sets project artifact file to packaged jar, the second
compiler:compile compile invocation sets it back to target/classes
folder.
--
Regards,
Igor
On Sat, Nov 14, 2015, at 09:55 AM, Kristian Rosenvold wrote:
> I've been using the test project attached to
alled during
"test" run at all. What phase is the plugin bound to in your project?
--
Regards,
Igor
On Sat, Nov 14, 2015, at 06:45 AM, Robert Scholte wrote:
> Op Sat, 14 Nov 2015 11:53:41 +0100 schreef Kristian Rosenvold
> :
>
> > While working on MSHADE-171, I fi
+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&version=12333074
>
+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&version=12333074
>
master. I timed the build only once with each version, so this
is very likely just a fluke... unless others notice performance
decrease, of course ;-).
--
Regards,
Igor
On Thu, Oct 29, 2015, at 09:35 PM, Jason van Zyl wrote:
> I took a look and added a test. Can you see if mas
previous version from git.
--
Regards,
Igor
On Wed, Oct 28, 2015, at 09:30 AM, Jason van Zyl wrote:
> Hi,
>
> Time to release Maven 3.3.7!
>
> Here is a link to the issues resolved:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=1233
I think this only highlights the need to have immutable core model. The
bundle plugin has no way to know how the shade plugin manipulates the
pom and the generated bundle manifest will be based on original project
model. (assuming I understand your suggested usecase)
--
Regards,
Igor
On Tue
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.
>
add optional=true to relevant
dependencies and fail the build if this is not the case. Maybe provide a
way to automatically change source pom.xml on filesystem before failing
the build too.
--
Regards,
Igor
On Tue, Oct 27, 2015, at 09:35 AM, Jason van Zyl wrote:
> The core model has to be mutable.
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 Mara
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 f
1 - 100 of 461 matches
Mail list logo
