date:20181114

Re: maven and java11

2018-11-14 Thread Romain Manni-Bucau

@Andreas: no, the bug is in plexus as explained before, jaxb is provided
but plexus classloader is not java11 compatible
@Hervé: i'll try to send a PR on plexus soon, will probably be faster than
mail exchanges ;)

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 15 nov. 2018 à 07:56, Andreas Dangel  a
écrit :

> The problem is maybe, that JAXB has been removed with java11: [1]
>
> The reference implementation [2] can be used as a replacement.
>
>
> Regards,
>
> Andreas
>
>
> 1: https://openjdk.java.net/jeps/320
>
> 2:
>
> https://search.maven.org/#search%7Cga%7C1%7Cg%3A%22com.sun.xml.bind%22%20AND%20a%3A%22jaxb-ri%22
>
>
> Am 14.11.2018 um 16:34 schrieb Romain Manni-Bucau:
> > assume i have a standard package-info.json with @XmlSchema, nothing crazy
> > in jaxb land.
> >
> > jaxb will do a loadClass(module, "com.foo.mypackage.package-info"), this
> > will call findClass(String /*module.getName()*/, String) which will call
> > findClass(String) (default impl in ClassLoader parent class of any
> > classloader impl).
> >
> > ClassRealm will expect findClass(String) to be loaded from
> > loadClass(String[,boolean]) so always throws ClassNotFoundException since
> > it is not expected to be used (instead the lookup strategy - API -  is
> > used).
> >
> > So in the previous cases of jaxb the loadClass will throw a ClassNotFound
> > which makes the metadata just wrong.
> >
> > This is a vicious bug which means not a single mojo can use the java 11
> > classloader API. By itself it sounds ok but since a lot of libs are
> > starting to use it, it means mojo are not working under java 11 until the
> > mojo creates another classloader which is not the case for standard
> simple
> > tasks mojos.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mer. 14 nov. 2018 à 10:00, Tibor Digana  a
> > écrit :
> >
> >> Hi Romain,
> >>
> >> Which class could not be loaded?
> >> JAXB or CDI class?
> >> Some class from Maven dist or another one?
> >>
> >> BR,
> >> Tibor
> >>
> >> On Tue, Nov 13, 2018 at 5:35 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> >> wrote:
> >>
> >>> Hi guys,
> >>>
> >>> did you plan to fix and upgrade classworlds to support java11?
> >>>
> >>> The trick is in
> >> org.codehaus.plexus.classworlds.realm.ClassRealm#findClass.
> >>> This method assumes it can't be called outside
> >> loadClass(String[,boolean])
> >>> but in j11 there is loadClass(String, String) defaulting to it as well
> so
> >>> it just fails and breaks a lot of mojo. One lib using that feature is
> >> jaxb
>  = 2.3.0 so any mojo relying on jaxb 2.3 is broken.
> >>> Romain Manni-Bucau
> >>> @rmannibucau  |  Blog
> >>>  | Old Blog
> >>>  | Github <
> >>> https://github.com/rmannibucau> |
> >>> LinkedIn  | Book
> >>> <
> >>>
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: maven and java11

2018-11-14 Thread Andreas Dangel

The problem is maybe, that JAXB has been removed with java11: [1]

The reference implementation [2] can be used as a replacement.


Regards,

Andreas


1: https://openjdk.java.net/jeps/320

2:
https://search.maven.org/#search%7Cga%7C1%7Cg%3A%22com.sun.xml.bind%22%20AND%20a%3A%22jaxb-ri%22


Am 14.11.2018 um 16:34 schrieb Romain Manni-Bucau:
> assume i have a standard package-info.json with @XmlSchema, nothing crazy
> in jaxb land.
>
> jaxb will do a loadClass(module, "com.foo.mypackage.package-info"), this
> will call findClass(String /*module.getName()*/, String) which will call
> findClass(String) (default impl in ClassLoader parent class of any
> classloader impl).
>
> ClassRealm will expect findClass(String) to be loaded from
> loadClass(String[,boolean]) so always throws ClassNotFoundException since
> it is not expected to be used (instead the lookup strategy - API -  is
> used).
>
> So in the previous cases of jaxb the loadClass will throw a ClassNotFound
> which makes the metadata just wrong.
>
> This is a vicious bug which means not a single mojo can use the java 11
> classloader API. By itself it sounds ok but since a lot of libs are
> starting to use it, it means mojo are not working under java 11 until the
> mojo creates another classloader which is not the case for standard simple
> tasks mojos.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
>
>
> Le mer. 14 nov. 2018 à 10:00, Tibor Digana  a
> écrit :
>
>> Hi Romain,
>>
>> Which class could not be loaded?
>> JAXB or CDI class?
>> Some class from Maven dist or another one?
>>
>> BR,
>> Tibor
>>
>> On Tue, Nov 13, 2018 at 5:35 PM Romain Manni-Bucau 
>> wrote:
>>
>>> Hi guys,
>>>
>>> did you plan to fix and upgrade classworlds to support java11?
>>>
>>> The trick is in
>> org.codehaus.plexus.classworlds.realm.ClassRealm#findClass.
>>> This method assumes it can't be called outside
>> loadClass(String[,boolean])
>>> but in j11 there is loadClass(String, String) defaulting to it as well so
>>> it just fails and breaks a lot of mojo. One lib using that feature is
>> jaxb
 = 2.3.0 so any mojo relying on jaxb 2.3 is broken.
>>> Romain Manni-Bucau
>>> @rmannibucau  |  Blog
>>>  | Old Blog
>>>  | Github <
>>> https://github.com/rmannibucau> |
>>> LinkedIn  | Book
>>> <
>>>
>> https://www.packtpub.com/application-development/java-ee-8-high-performance



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven and java11

2018-11-14 Thread Hervé BOUTEMY

oh, subtle issue

can you provide a unit test, please?

regards,

Hervé

Le mercredi 14 novembre 2018, 16:34:30 CET Romain Manni-Bucau a écrit :
> assume i have a standard package-info.json with @XmlSchema, nothing crazy
> in jaxb land.
> 
> jaxb will do a loadClass(module, "com.foo.mypackage.package-info"), this
> will call findClass(String /*module.getName()*/, String) which will call
> findClass(String) (default impl in ClassLoader parent class of any
> classloader impl).
> 
> ClassRealm will expect findClass(String) to be loaded from
> loadClass(String[,boolean]) so always throws ClassNotFoundException since
> it is not expected to be used (instead the lookup strategy - API -  is
> used).
> 
> So in the previous cases of jaxb the loadClass will throw a ClassNotFound
> which makes the metadata just wrong.
> 
> This is a vicious bug which means not a single mojo can use the java 11
> classloader API. By itself it sounds ok but since a lot of libs are
> starting to use it, it means mojo are not working under java 11 until the
> mojo creates another classloader which is not the case for standard simple
> tasks mojos.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github 
> | LinkedIn  | Book
>  >
> 
> 
> Le mer. 14 nov. 2018 à 10:00, Tibor Digana  a
> 
> écrit :
> > Hi Romain,
> > 
> > Which class could not be loaded?
> > JAXB or CDI class?
> > Some class from Maven dist or another one?
> > 
> > BR,
> > Tibor
> > 
> > On Tue, Nov 13, 2018 at 5:35 PM Romain Manni-Bucau 
> > 
> > wrote:
> > > Hi guys,
> > > 
> > > did you plan to fix and upgrade classworlds to support java11?
> > > 
> > > The trick is in
> > 
> > org.codehaus.plexus.classworlds.realm.ClassRealm#findClass.
> > 
> > > This method assumes it can't be called outside
> > 
> > loadClass(String[,boolean])
> > 
> > > but in j11 there is loadClass(String, String) defaulting to it as well
> > > so
> > > it just fails and breaks a lot of mojo. One lib using that feature is
> > 
> > jaxb
> > 
> > > >= 2.3.0 so any mojo relying on jaxb 2.3 is broken.
> > > 
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> > 
> > https://www.packtpub.com/application-development/java-ee-8-high-performanc
> > e




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Extension does not work from .mvn/extensions.xml

2018-11-14 Thread Romain Manni-Bucau

Hi Lewis

You can debug using mvnDebug but i think it is cause there is already a
property handler -
https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/profile/activation/PropertyProfileActivator.java
- so depending the scanning order you take one or the other. Try using
another marker maybe or making yours higher priority probably.


Le mer. 14 nov. 2018 22:24, J. Lewis Muir  a écrit :

> Hello, all!
>
> I have an extension
>
>   https://github.com/imca-cat/profile-activation-advanced
>
> that allows property-based profile activation based on an MVEL
> expression.
>
> My problem is that it works
>
> ===
> $ mvn help:active-profiles validate
> ...
> The following profiles are active:
>
>  - foo_env-development (source: org.example.foo:foo:1.0.0)
> ...
> ===
>
> when loaded via Maven's lib/ext directory or when specified on the
> command line with "-Dmaven.ext.class.path=", but
> does *not* work
>
> ===
> $ mvn help:active-profiles validate
> ...
> The following profiles are active:
>
> ...
> ===
>
> when loaded via a project's .mvn/extensions.xml file.
>
> The extension hijacks the normal property activator like this
>
>   @Component(role = ProfileActivator.class, hint = "property")
>   public class AdvancedProfileActivator implements ProfileActivator {
> ...
>   }
>
> and evaluates the property value as an MVEL expression if the property
> name equals "mvel" or "mvel("  ")".
>
> Does anyone know why it would work from Maven's lib/ext directory, but
> not from a project's .mvn/extensions.xml file?  Or does anyone know how
> to debug this?
>
> Is it possible that the hijack doesn't work when loaded from a
> project's .mvn/extensions.xml because the original profile activator is
> found on the class path *before* the AdvancedProfileActivator of the
> extension, but when the extension JAR is placed in Maven's lib/ext,
> the AdvancedProfileActivator is found on the class path *before* the
> original profile activator?  (Just a wild guess.)
>
> The full source code of the extension's profile activator is at
>
>
> https://github.com/imca-cat/profile-activation-advanced/blob/master/src/main/java/org/imca_cat/maven/profile_activation_advanced/AdvancedProfileActivator.java
>
> To reproduce the problem, simply create a new Maven project directory
> containing the following pom.xml file:
>
> ===
> 
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
>   4.0.0
>   org.example.foo
>   foo
>   1.0.0
>   pom
>   
> 
>   foo_env-development
>   
> 
>   mvel
>   (!isdef foo_env) || foo_env == "development"
> 
>   
> 
>   
> 
> ===
>
> (The foo_env-development profile should activate if the foo_env property
> (or system property) is not set or is set to the string "development".)
>
> Create .mvn/extensions.xml:
>
> ===
> 
> http://maven.apache.org/EXTENSIONS/1.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/EXTENSIONS/1.0.0
> http://maven.apache.org/xsd/core-extensions-1.0.0.xsd";>
>   
> org.imca-cat.maven
> profile-activation-advanced
> 0.1.0
>   
> 
> ===
>
> Run the following command:
>
> ===
> $ mvn help:active-profiles validate
> ===
>
> It should report that the foo_env-development profile is active (because
> the foo_env property is not set), but it does not. :-(
>
> I previously asked on the Maven User list
>
>
> https://lists.apache.org/thread.html/99ee87ba1bc86d98652173482b3a5882a52e344fad18df2cd50e8750@%3Cusers.maven.apache.org%3E
>
> but did not receive any replies.
>
> Thank you for your help!
>
> Lewis
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Extension does not work from .mvn/extensions.xml

2018-11-14 Thread J. Lewis Muir

Hello, all!

I have an extension

  https://github.com/imca-cat/profile-activation-advanced

that allows property-based profile activation based on an MVEL
expression.

My problem is that it works

===
$ mvn help:active-profiles validate
...
The following profiles are active:

 - foo_env-development (source: org.example.foo:foo:1.0.0)
...
===

when loaded via Maven's lib/ext directory or when specified on the
command line with "-Dmaven.ext.class.path=", but
does *not* work

===
$ mvn help:active-profiles validate
...
The following profiles are active:

...
===

when loaded via a project's .mvn/extensions.xml file.

The extension hijacks the normal property activator like this

  @Component(role = ProfileActivator.class, hint = "property")
  public class AdvancedProfileActivator implements ProfileActivator {
...
  }

and evaluates the property value as an MVEL expression if the property
name equals "mvel" or "mvel("  ")".

Does anyone know why it would work from Maven's lib/ext directory, but
not from a project's .mvn/extensions.xml file?  Or does anyone know how
to debug this?

Is it possible that the hijack doesn't work when loaded from a
project's .mvn/extensions.xml because the original profile activator is
found on the class path *before* the AdvancedProfileActivator of the
extension, but when the extension JAR is placed in Maven's lib/ext,
the AdvancedProfileActivator is found on the class path *before* the
original profile activator?  (Just a wild guess.)

The full source code of the extension's profile activator is at

  
https://github.com/imca-cat/profile-activation-advanced/blob/master/src/main/java/org/imca_cat/maven/profile_activation_advanced/AdvancedProfileActivator.java

To reproduce the problem, simply create a new Maven project directory
containing the following pom.xml file:

===

http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
  4.0.0
  org.example.foo
  foo
  1.0.0
  pom
  

  foo_env-development
  

  mvel
  (!isdef foo_env) || foo_env == "development"

  

  

===

(The foo_env-development profile should activate if the foo_env property
(or system property) is not set or is set to the string "development".)

Create .mvn/extensions.xml:

===

http://maven.apache.org/EXTENSIONS/1.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/EXTENSIONS/1.0.0
http://maven.apache.org/xsd/core-extensions-1.0.0.xsd";>
  
org.imca-cat.maven
profile-activation-advanced
0.1.0
  

===

Run the following command:

===
$ mvn help:active-profiles validate
===

It should report that the foo_env-development profile is active (because
the foo_env property is not set), but it does not. :-(

I previously asked on the Maven User list

  
https://lists.apache.org/thread.html/99ee87ba1bc86d98652173482b3a5882a52e344fad18df2cd50e8750@%3Cusers.maven.apache.org%3E

but did not receive any replies.

Thank you for your help!

Lewis

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven and java11

2018-11-14 Thread Romain Manni-Bucau

assume i have a standard package-info.json with @XmlSchema, nothing crazy
in jaxb land.

jaxb will do a loadClass(module, "com.foo.mypackage.package-info"), this
will call findClass(String /*module.getName()*/, String) which will call
findClass(String) (default impl in ClassLoader parent class of any
classloader impl).

ClassRealm will expect findClass(String) to be loaded from
loadClass(String[,boolean]) so always throws ClassNotFoundException since
it is not expected to be used (instead the lookup strategy - API -  is
used).

So in the previous cases of jaxb the loadClass will throw a ClassNotFound
which makes the metadata just wrong.

This is a vicious bug which means not a single mojo can use the java 11
classloader API. By itself it sounds ok but since a lot of libs are
starting to use it, it means mojo are not working under java 11 until the
mojo creates another classloader which is not the case for standard simple
tasks mojos.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book

Le mer. 14 nov. 2018 à 10:00, Tibor Digana  a
écrit :

> Hi Romain,
>
> Which class could not be loaded?
> JAXB or CDI class?
> Some class from Maven dist or another one?
>
> BR,
> Tibor
>
> On Tue, Nov 13, 2018 at 5:35 PM Romain Manni-Bucau 
> wrote:
>
> > Hi guys,
> >
> > did you plan to fix and upgrade classworlds to support java11?
> >
> > The trick is in
> org.codehaus.plexus.classworlds.realm.ClassRealm#findClass.
> > This method assumes it can't be called outside
> loadClass(String[,boolean])
> > but in j11 there is loadClass(String, String) defaulting to it as well so
> > it just fails and breaks a lot of mojo. One lib using that feature is
> jaxb
> > >= 2.3.0 so any mojo relying on jaxb 2.3 is broken.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
>

[MNG-5180] Versioning's snapshot version list is not included in metadata merge

2018-11-14 Thread Przemysław Fusik

 Hi guys,

I have a question related with the maven-metadata.xml file and
versioning's snapshot version list.

Should the versioning's snapshot version list contain all of the known
snapshot versions OR there should be only the last one (related with the
timestamp) version ?

Thanks in advance !

Regards,

Przemysław Fusik

Re: maven and java11

2018-11-14 Thread Tibor Digana

Hi Romain,

Which class could not be loaded?
JAXB or CDI class?
Some class from Maven dist or another one?

BR,
Tibor

On Tue, Nov 13, 2018 at 5:35 PM Romain Manni-Bucau 
wrote:

> Hi guys,
>
> did you plan to fix and upgrade classworlds to support java11?
>
> The trick is in org.codehaus.plexus.classworlds.realm.ClassRealm#findClass.
> This method assumes it can't be called outside loadClass(String[,boolean])
> but in j11 there is loadClass(String, String) defaulting to it as well so
> it just fails and breaks a lot of mojo. One lib using that feature is jaxb
> >= 2.3.0 so any mojo relying on jaxb 2.3 is broken.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>

Re: maven and java11

Re: maven and java11

Re: maven and java11

Re: Extension does not work from .mvn/extensions.xml

Extension does not work from .mvn/extensions.xml

Re: maven and java11

[MNG-5180] Versioning's snapshot version list is not included in metadata merge

Re: maven and java11

8 matches

Site Navigation

Mail list logo

Footer information