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] http://takari.io/book/91-maven-classloading.
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 doi
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] https
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
decide who we need and an actual agenda.
>
> If Monday is too soon I can see if I have a window later this week
>
> On Sun 24 Sep 2017 at 18:58, Igor Fedorenko wrote:
>
> > See my answers/comments inline
> >
> >
> > On Sun, Sep 24, 2017, at 12:07 PM, Steph
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
phen 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 to configure extjar1 and extjar2 as
> >> ext
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
, 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 wrote:
>
>
7;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
> >>
> >> On Tue, 19 Sep 2017 06:55:08 +0200, I
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 s
e they are providing 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 Sept
things" — Steven
> Wilson,
> Porcupine Tree
>
> On Sat, Sep 16, 2017 at 12:22 AM, Anders Hammar
> 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
> &g
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 Hamm
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]
https://github.com/takari/takar
lugin to use env
> variable CLASSPATH.
>
> On Thu, Aug 31, 2017 at 12:24 AM, Igor Fedorenko
> wrote:
>
> > How does surefire setup jvm classpath when it runs plugin unit and
> > integration tests?
> >
> > --
> > Regards,
> > Igor
> &
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 Sch
ation locally and run other Maven
> 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)
> wrote:
>
> >
> > [
> > https://issu
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 Sun,
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 p
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 bui
+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: dev-unsubscr...@ma
+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 were
nno...@gmail.com> wrote:
None here!
On Thu 13 Apr 2017 at 23:30, Igor Fedorenko 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,
Igor
On April 13, 2017 1:20:24 PM Karl Heinz Marbaise
w
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
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 wrote:
>
> > I have two of small-ish fixes I'd like to submit, so I w
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 how
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 to
+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,
> >
gt; > 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 description, Hervé. One sm
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,
Ig
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
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 subm
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
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
enoug
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 Mave
> 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 tests
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 of
+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 <
> >
> > stephen.alan.conno...@gmail.com> wrote:
> >
>
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 in the open
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 mav
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 reactor on the co
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 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
wrote:
Disagree. I think in most if not all case
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 ?
It
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 they would be.
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 multimodule reactor proje
ote:
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 classpath.
Yes.
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. F
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
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
> >
>
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.apache.
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
:
> 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:
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 1
6:22:20 +0200, Christian Schulte
> 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
> >>> override ce
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:45 schri
}
>
>
> 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 except
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 e
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: resolver(
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. But
+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 can
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
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,
Igor
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
n 3 June 2016 at 13:36, Igor Fedorenko 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 without actually buildi
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 at
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 r
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 mor
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]
http://git.eclipse.
+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 food). Additionally, An
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,
Igor
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 pr
; > 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 wrote:
> > >
> > > It is al
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
arget/classes or the jar. But
> 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 confi
-java9 project? 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
>
t would be fine.
>
> Robert
>
> Op Sun, 03 Jan 2016 18:09:52 +0100 schreef Igor Fedorenko
> :
>
> > What changes to MavenProject do you have in mind?
>
> -
> To unsubscribe, e-mail
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 -Denforcer.s
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
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 nu
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 prett
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 :
> > Run the build with -X and see what mojos are executed for mshade171-base
> >
> 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 believe "mvn clean package" runs the default lifecycl
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.
+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
>
> Staging repo:
> https://repository.apa
+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
>
> Staging repo:
> https://repository.apa
ter
> (f684761dee739b4ec8a7e6db5a0a6a0b809e66c9) fixes your issue?
>
> > On Oct 29, 2015, at 5:21 PM, Igor Fedorenko wrote:
> >
> > -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
&g
-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 pre
, Oct 27, 2015, at 10:12 AM, Benson Margulies wrote:
> On Tue, Oct 27, 2015 at 9:58 AM, Igor Fedorenko
> 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 be mutable, but
> >
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,
>
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 tr
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 educate
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].
1 - 100 of 454 matches
Mail list logo