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
Hi
Sorry a bit out of time ATM for testing this.
Well I trust Arnaud testing that especially if this improve the performance
of this very great/awesome/users oriented plugin :P
On 13 September 2017 at 22:19, Arnaud Héritier wrote:
> Damned, can't we be anonymous on Github ?
> I maintain it is a
On Mon, 18 Sep 2017 19:57:33 +0200, Mark Raynsford
wrote:
On 2017-09-18T19:44:54 +0200
"Robert Scholte" wrote:
For every deliverable you will have one Maven project (and 1 pom.xml).
So for a Maven point of view it doesn't make sense to support the jigsaw
multi module option.
Good! That's
On 2017-09-18T19:44:54 +0200
"Robert Scholte" wrote:
> For every deliverable you will have one Maven project (and 1 pom.xml).
> So for a Maven point of view it doesn't make sense to support the jigsaw
> multi module option.
Good! That's what I'd suspected (and hoped!)
> Here are the things yo
On 2017-09-18T19:06:12 +0200
Karl Heinz Marbaise wrote:
> Hi Mark,
>
> On 18/09/17 17:11, Mark Raynsford wrote:
> >
> > The directory layout is "src/com.me.mymodule/module-info.java". This
> > obviously doesn't match the "src/main/java" convention that Maven uses.
>
> That is the same which
For every deliverable you will have one Maven project (and 1 pom.xml).
So for a Maven point of view it doesn't make sense to support the jigsaw
multi module option.
Here are the things you *DON'T* have to change:
- folder structure
- dependencies of your pom.xml (you don't specify which jars a
Hi Mark,
On 18/09/17 17:11, Mark Raynsford wrote:
Hello.
With Java 9 due out in a few days time, I'm looking at moving all of my
60+ projects to Java 9. I have no intention of keeping support for any
version of Java less than 9, so the projects will become pure Java 9
(modularized) projects.
I
Oh if only... there is some subtleties going on here.
Classes are managed by the "plexus" / "classworlds" stuff, so you cannot
override core classes etc.
The problem is what extensions are visible and from which classloader
On 18 September 2017 at 08:42, Charles Honton wrote:
> From a security
From a security perspective, I would expect that core classes can not be
overridden by extensions or plugins. Likewise, extension classes can not be
overridden by plugins.
Given the use case of defaulting resources, I would expect that the plugin
resources are first, followed by plugin specifi
Hello.
With Java 9 due out in a few days time, I'm looking at moving all of my
60+ projects to Java 9. I have no intention of keeping support for any
version of Java less than 9, so the projects will become pure Java 9
(modularized) projects.
I'm curious as whether Java 9 changes any of the conve
Hmmm, so I did some experiments:
If you want to ride along, the experiments are at:
https://github.com/stephenc/mng-6209
So basically I have a plugin that does three different tests:
getLog().info("Injected by @Component:");
for (Lifecycle l : lifecycles) {
if (l.get
11 matches
Mail list logo
