date:20230916

Re: thoughts about SUREFIRE-2191

2023-09-16 Thread Romain Manni-Bucau

Hi,

Generally speaking the simplest way would be to let surefire load by
reflection junit5 and auto open it.
That said a solution like junit-platform maven plugin is more native when
you need to control the command (the issue with jpms is you need to
manually tune module and clqss paths, no exit to that not nice work).

So if the standard module duplication in test hack does not work i would
just use a fork based plugin (junit-platform, exec with junit launcher,
tool, ...)

Maybe @sormuras can give us more insight but think it is our current status
and until we have a fork provider surefire does not instrument or does with
an agent (slow) we'll get this issue.

Le dim. 17 sept. 2023 à 09:16, Henning Schmiedehausen <
henn...@schmiedehausen.org> a écrit :

> So I looked a bit more into that bug and why it crashes the way it crashes.
> I also added this as a comment to the ticket but given the silence on most
> tickets, I'd like to push for some discussion here on the mailing list.
>
>
> I have two modules, core and testing (these are defined modules, they have
> a module descriptor)
>
> "core" is just a regular build, it uses junit5 as its test framework.
>
> surefire creates a classpath with all the surefire deps (surefire-api,
> surefire-extensions, surefire-junit-platform, surefire-logging-api,
> surefire-shared-utils) and the junit deps (junit-jupiter-api,
> junit-jupiter-engine, junit-jupiter-params, junit-platform-commons,
> junit-platform-engine, junit-platform-launcher). The module path only gets
> the actual module dependencies of module A
>
> All works well in that case.
>
> Now the "testing" module declares org.junit.jupiter.api as a dependency and
> has requires org.junit.jupiter.api in its module descriptor (transitive or
> not transitive does not matter) because there is code that implements some
> of those APIs.
>
> surefire now creates a classpath with the same surefire deps and only a
> subset of junit deps. The missing deps (junit-jupiter-api and
> junit-platform-commons) are pulled onto the module path.
>
> This explains the error message:
>
> *java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherDiscoveryRequestBuilder (in
> unnamed module @0x6392827e) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6392827e*
>
> The launcher (in junit-platform-launcher) lives on the classpath and is
> therefore in the unnamed module. But the launcher requires the
> org.junit.platform.commons module from the junit-platform-commons jar,
> which is on the module path. And the junit-platform-commons module has the
> following clause in its module descriptor:
>
> exports org.junit.platform.commons.util to
> [...]
> org.junit.platform.launcher,
> [...];
>
> and it does not export the package to the unnamed module. And now JVM fails
> with the error above.
>
> I can not see any good solution:
>
> - The current solution does not work (see above)
> - The junit-jupiter-api jar which contains org.junit.jupiter.api can not go
> on the class path because now the main artifact which requires it can not
> find it (the classes would be in the unnamed module and the main module
> requests org.junit.jupiter.api)
> - It can not be patched into the main module because now
> the org.junit.jupiter.api module would be invisible to everything else on
> the module path (packages can't exist twice)
> - It can only stay on the module path if everything that depends on it gets
> pulled there as well. This requires a "bottom up" resolution of all modules
> that depend on this (in this case org.junit.jupiter.api) and may interfere
> with the ability of the surefire launcher to launch code.
> - We could fall back to "legacy" mode where everything is on the classpath
> and the module path is ignored. This is problematic as tests may pass and
> code later fails because of not matching entries in the module descriptor
>
> Thoughts? This seems to be a blocker for projects that want to use JPMS and
> implement test code.
>
> -h
>

thoughts about SUREFIRE-2191

2023-09-16 Thread Henning Schmiedehausen

So I looked a bit more into that bug and why it crashes the way it crashes.
I also added this as a comment to the ticket but given the silence on most
tickets, I'd like to push for some discussion here on the mailing list.


I have two modules, core and testing (these are defined modules, they have
a module descriptor)

"core" is just a regular build, it uses junit5 as its test framework.

surefire creates a classpath with all the surefire deps (surefire-api,
surefire-extensions, surefire-junit-platform, surefire-logging-api,
surefire-shared-utils) and the junit deps (junit-jupiter-api,
junit-jupiter-engine, junit-jupiter-params, junit-platform-commons,
junit-platform-engine, junit-platform-launcher). The module path only gets
the actual module dependencies of module A

All works well in that case.

Now the "testing" module declares org.junit.jupiter.api as a dependency and
has requires org.junit.jupiter.api in its module descriptor (transitive or
not transitive does not matter) because there is code that implements some
of those APIs.

surefire now creates a classpath with the same surefire deps and only a
subset of junit deps. The missing deps (junit-jupiter-api and
junit-platform-commons) are pulled onto the module path.

This explains the error message:

*java.lang.IllegalAccessError: class
org.junit.platform.launcher.core.LauncherDiscoveryRequestBuilder (in
unnamed module @0x6392827e) cannot access class
org.junit.platform.commons.util.Preconditions (in module
org.junit.platform.commons) because module org.junit.platform.commons does
not export org.junit.platform.commons.util to unnamed module @0x6392827e*

The launcher (in junit-platform-launcher) lives on the classpath and is
therefore in the unnamed module. But the launcher requires the
org.junit.platform.commons module from the junit-platform-commons jar,
which is on the module path. And the junit-platform-commons module has the
following clause in its module descriptor:

exports org.junit.platform.commons.util to
[...]
org.junit.platform.launcher,
[...];

and it does not export the package to the unnamed module. And now JVM fails
with the error above.

I can not see any good solution:

- The current solution does not work (see above)
- The junit-jupiter-api jar which contains org.junit.jupiter.api can not go
on the class path because now the main artifact which requires it can not
find it (the classes would be in the unnamed module and the main module
requests org.junit.jupiter.api)
- It can not be patched into the main module because now
the org.junit.jupiter.api module would be invisible to everything else on
the module path (packages can't exist twice)
- It can only stay on the module path if everything that depends on it gets
pulled there as well. This requires a "bottom up" resolution of all modules
that depend on this (in this case org.junit.jupiter.api) and may interfere
with the ability of the surefire launcher to launch code.
- We could fall back to "legacy" mode where everything is on the classpath
and the module path is ignored. This is problematic as tests may pass and
code later fails because of not matching entries in the module descriptor

Thoughts? This seems to be a blocker for projects that want to use JPMS and
implement test code.

-h

dependency metadata

2023-09-16 Thread Henning Schmiedehausen

The more I spend time with JPMS and maven, the more I wonder if we need to
have some kind of additional metadata for our dependency declarations.

Up until Java 8, dependencies were pretty straightforward: They go on the
classpath depending on their scope. Some are only on the compile classpath,
some on the test classpath, some on the runtime classpath.

In the Java 9+ world, things get trickier.

- If a project builds a regular jar (no module descriptor or only an entry
in the Manifest), then the world still works as above.
- If a project builds a JPMS module (has a module descriptor)...
  - A dependency that has a module descriptor (module-info) normally goes
on the module path
  - A dependency that does not have a module descriptor may go onto the
module path (where it lives as an automatic module) *OR* could go on the
class path where it would be part of the unnamed module. The latter may be
necessary for dependencies that have overlapping packages.

So for any dependency, there is a default (classpath for a regular project,
module path for a project with a module descriptor) but there are
situations where that default may need to be overridden. And, what is
worse, there may be situations where overriding depends on whether it is
used for compilation or testing.

There is currently no way to communicate to maven as a user whether a given
dependency should be on the module path or the class path short of adding a
config option to a plugin that controls this. We have this scenario in
multiple places where dependency specific configuration is added to a
plugin because there is no better place.

I wonder if there is an opportunity when overhauling the POM right now, to
add a "properties bag" to each dependency. Basically


  ...
  ...
  ...
  ...
  ...
  ...




*  some-value
some-value  *

which would allow general metadata association to the dependencies.

In that scenario, I could see using e.g.


  true


or


  compile


to hint the various plugins whether a given dependency should be treated as
a module path or a classpath element.

-h

Re: plexus-utils 4.x and Xpp3DomBuilder

2023-09-16 Thread Slawomir Jaranowski

sob., 16 wrz 2023 o 16:19 Jeremy Landis 
napisał(a):

> Site plugin on maven release doesn't like if this was used this way.
> Using the site 3 series.
>

Can you provide more details or reproduce for the site plugin?


>
> Sent from my Verizon, Samsung Galaxy smartphone
> Get Outlook for Android
> 
> From: Slawomir Jaranowski 
> Sent: Saturday, September 16, 2023 9:50:51 AM
> To: Maven Developers List 
> Subject: Re: plexus-utils 4.x and Xpp3DomBuilder
>
> śr., 13 wrz 2023 o 08:47 Hervé Boutemy  napisał(a):
>
> > can you try plexus-xml 3.0.0 and confirm this works as you expected
> > initially,
> > please?
> >
> >
> plexus-utils 4.x and plexsu-xml 3.0.0 can be used on both Maven 3.x and 4.x
>
> So now it will be ok.
>
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fmaven-enforcer%2Fpull%2F291&data=05%7C01%7C%7Ce6745d0f864b45e3466208dbb6bc020d%7C84df9e7fe9f640afb435%7C1%7C0%7C638304690830758434%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=KsmhwtW2HAnr8Abgq3NzrcC9AsKeKwvnI1UaKCseMQg%3D&reserved=0
> 
>
> Regards,
> >
> > Hervé
> >
> > Le mardi 25 juillet 2023, 20:56:04 CEST Slawomir Jaranowski a écrit :
> > > Hi
> > >
> > > I'm trying to update plexus-utils 3.5.x to plexus-utils/plexus-xml 4.x
> in
> > > maven-enforcer 
> > >
> > > In maven-enforcer (and in many other plugins ...) is used, code like:
> > >
> > > Xpp3Dom enforcerRules =
> > Xpp3DomBuilder.build(descriptorStream,
> > > "UTF-8");
> > >
> > > Xpp3Dom and Xpp3DomBuilder - has new implementation in plexus-xml 
> > but
> > > Maven 3.x exports
> > >
> > > 
> > >
> >  org.codehaus.plexus.util.xml.Xpp3Dom
> > >
> > >
> >
> org.codehaus.plexus.util.xml.pull.XmlPullParser > > ckage>
> > >
> > >
> >
> org.codehaus.plexus.util.xml.pull.XmlPullParserException > > xportedPackage>
> > >
> > >
> >
> org.codehaus.plexus.util.xml.pull.XmlSerializer > > ckage>
> > >
> > > It is very magical that we export classes but not export artifact
> > > which contains those classes ...
> > >
> > > so incompatibilite code for Xpp3Dom is used ...
> > >
> > > Any hints on how to process it.
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> --
> Sławomir Jaranowski
>


-- 
Sławomir Jaranowski

Re: plexus-utils 4.x and Xpp3DomBuilder

2023-09-16 Thread Jeremy Landis

Site plugin on maven release doesn't like if this was used this way.  Using the 
site 3 series.

Sent from my Verizon, Samsung Galaxy smartphone
Get Outlook for Android

From: Slawomir Jaranowski 
Sent: Saturday, September 16, 2023 9:50:51 AM
To: Maven Developers List 
Subject: Re: plexus-utils 4.x and Xpp3DomBuilder

śr., 13 wrz 2023 o 08:47 Hervé Boutemy  napisał(a):

> can you try plexus-xml 3.0.0 and confirm this works as you expected
> initially,
> please?
>
>
plexus-utils 4.x and plexsu-xml 3.0.0 can be used on both Maven 3.x and 4.x

So now it will be ok.

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fmaven-enforcer%2Fpull%2F291&data=05%7C01%7C%7Ce6745d0f864b45e3466208dbb6bc020d%7C84df9e7fe9f640afb435%7C1%7C0%7C638304690830758434%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=KsmhwtW2HAnr8Abgq3NzrcC9AsKeKwvnI1UaKCseMQg%3D&reserved=0

Regards,
>
> Hervé
>
> Le mardi 25 juillet 2023, 20:56:04 CEST Slawomir Jaranowski a écrit :
> > Hi
> >
> > I'm trying to update plexus-utils 3.5.x to plexus-utils/plexus-xml 4.x in
> > maven-enforcer 
> >
> > In maven-enforcer (and in many other plugins ...) is used, code like:
> >
> > Xpp3Dom enforcerRules =
> Xpp3DomBuilder.build(descriptorStream,
> > "UTF-8");
> >
> > Xpp3Dom and Xpp3DomBuilder - has new implementation in plexus-xml 
> but
> > Maven 3.x exports
> >
> > 
> >
>  org.codehaus.plexus.util.xml.Xpp3Dom
> >
> >
> org.codehaus.plexus.util.xml.pull.XmlPullParser > ckage>
> >
> >
> org.codehaus.plexus.util.xml.pull.XmlPullParserException > xportedPackage>
> >
> >
> org.codehaus.plexus.util.xml.pull.XmlSerializer > ckage>
> >
> > It is very magical that we export classes but not export artifact
> > which contains those classes ...
> >
> > so incompatibilite code for Xpp3Dom is used ...
> >
> > Any hints on how to process it.
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

--
Sławomir Jaranowski

Re: plexus-utils 4.x and Xpp3DomBuilder

2023-09-16 Thread Slawomir Jaranowski

śr., 13 wrz 2023 o 08:47 Hervé Boutemy  napisał(a):

> can you try plexus-xml 3.0.0 and confirm this works as you expected
> initially,
> please?
>
>
plexus-utils 4.x and plexsu-xml 3.0.0 can be used on both Maven 3.x and 4.x

So now it will be ok.

https://github.com/apache/maven-enforcer/pull/291

Regards,
>
> Hervé
>
> Le mardi 25 juillet 2023, 20:56:04 CEST Slawomir Jaranowski a écrit :
> > Hi
> >
> > I'm trying to update plexus-utils 3.5.x to plexus-utils/plexus-xml 4.x in
> > maven-enforcer 
> >
> > In maven-enforcer (and in many other plugins ...) is used, code like:
> >
> > Xpp3Dom enforcerRules =
> Xpp3DomBuilder.build(descriptorStream,
> > "UTF-8");
> >
> > Xpp3Dom and Xpp3DomBuilder - has new implementation in plexus-xml 
> but
> > Maven 3.x exports
> >
> > 
> >
>  org.codehaus.plexus.util.xml.Xpp3Dom
> >
> >
> org.codehaus.plexus.util.xml.pull.XmlPullParser > ckage>
> >
> >
> org.codehaus.plexus.util.xml.pull.XmlPullParserException > xportedPackage>
> >
> >
> org.codehaus.plexus.util.xml.pull.XmlSerializer > ckage>
> >
> > It is very magical that we export classes but not export artifact
> > which contains those classes ...
> >
> > so incompatibilite code for Xpp3Dom is used ...
> >
> > Any hints on how to process it.
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

Re: thoughts about SUREFIRE-2191

thoughts about SUREFIRE-2191

dependency metadata

Re: plexus-utils 4.x and Xpp3DomBuilder

Re: plexus-utils 4.x and Xpp3DomBuilder

Re: plexus-utils 4.x and Xpp3DomBuilder

6 matches

Site Navigation

Mail list logo

Footer information