Re: Testing plugins in JUnit 5

[Russell Gold]

Not sure why it would be any different from testing anything else with external 
dependencies. You can see some examples at 
https://github.com/oracle/weblogic-monitoring-exporter/tree/main/build-helper-mojo/src
 

> On Nov 5, 2022, at 7:07 AM, Mark Raynsford 
>  wrote:
> 
> Hello!
> 
> As the subject says: Is there a documented way to write tests for
> plugins under JUnit 5? The only thing I've been able to find is the
> takari testing project:
> 
>  https://github.com/takari/takari-plugin-testing-project
> 
> There seems to be some preliminary support there, but it's not in any
> of the available releases and nobody seems to have touched the project
> for almost a year.
> 
> -- 
> Mark Raynsford | https://www.io7m.com
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


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

Re: Help with shading jar

[Russell Gold]

Are they part of the same build?

Can you create a minimal example and post it to GitHub? There’s really not 
enough detail to understand what you are trying to do.

> On Jul 2, 2020, at 5:18 PM, Quiyan H  wrote:
> 
> Hi All
> I am stuck with one shading stuff, Need help if there is known way out.
> I have a project module which has bunch of dependencies and I want to shade
> and relocate one of the dependency. I did that, but the problem is the
> other dependency also uses the dependency that I shaded, but that doesn’t
> use the relocated class, is there any way to make the other dependency use
> the relocated shaded class instead of the original.
> The catch is I can’t shade this other dependency due to other conflicts.
> 
> Module
> DependencyA (uses dependency B as well)
> DependencyB (shaded and relocated)
> 
> Want to make dependency A use relocated classes in the Module rather than
> direct dependency B
> 
> Any help, even if it is something which can not be done, Please let me
> know!!!
> 
> Waiting for a response!!!


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

Re: [ANN] Apache Maven JDeprScan Plugin 3.0.0-alpha-1 Released

[Russell Gold]

If you go to the project page 
https://maven.apache.org/plugins/maven-jdeprscan-plugin/, you will see more 
information, including how to check out the sources:

svn checkout 
http://svn.apache.org/repos/asf/maven/plugins/tags/maven-jdeprscan-plugin-3.0.0-alpha-1
 maven-jdeprscan-plugin

and how to reference it in your project


  org.apache.maven.plugins
  maven-jdeprscan-plugin
  3.0.0-alpha-1
  maven-plugin


- Russ

> On Nov 17, 2017, at 5:01 AM, sebb  wrote:
> 
> On 17 November 2017 at 09:27, Robert Scholte  wrote:
>> The Apache Maven team is pleased to announce the first release of the Apache
>> Maven JDeprScan Plugin, version 3.0.0-alpha-1
>> 
>> The Maven JDeprScan plugin is used to scan class files for uses of
>> deprecated API elements. It uses the jdeprscan tool as provided with Java 9.
>> 
>> https://maven.apache.org/plugins/maven-jdeprscan-plugin/
>> 
>> You should specify the version in your project's plugin configuration:
>> 
>> 
>>  org.apache.maven.plugins
>>  maven-jdeprscan-plugin
>>  3.0.0-alpha-1
>> 
>> 
>> You can download the appropriate sources etc. from the download page:
>> 
>> https://maven.apache.org/plugins/maven-jdeprscan-plugin/download.cgi
> 
> The download link points to the top-level of the ASF mirror system.
> 
> This makes it very hard to use.
> 
>> Enjoy,
> 
> Looking for the needle in the haystack?
> 
>> -The Apache Maven team
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Re: [jira] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9

[Russell Gold]

Is there a way to disable this hack? 

I am trying to build the glassfish-corba project 
, which defines its own version of 
classes in the javax.rmi.CORBA package, and having --add-modules java.se.ee on 
the command line means that those classes aren’t found during unit tests.

- Russ

> On Sep 29, 2017, at 4:55 AM, Enrico Olivelli  wrote:
> 
> 2017-09-29 10:41 GMT+02:00 Alan Bateman :
> 
>> On 29/09/2017 08:57, Enrico Olivelli wrote:
>> 
>>> :
>>> 
>>> 2) dealing with modules like java.sql which as not in java.base (
>>> http://download.java.net/java/jdk9/docs/api/java.base-summary.html)
>>> Currently I have no solution as there is no official maven dependency for
>>> java.sql package
>>> 
>>> You shouldn't need to be concerned with the java.sql module.
> 
> 
> From the point of view of a developer which uses Maven there is no Maven
> style way to use java.sql module, like "adding a dependency"
> The hack on surefire tried to solve this problem.
> 
> Using JDK_JAVA_OPTIONS is an option, but as it is a env entry it must be
> set externally to the maven pom.xml or config
> Using .mvn/jvm.config will prevent the build to work on java8 (except from
> using -XX:+IgnoreUnrecognizedVMOptions which will be dropped in java11 ??)
> 
> Which is the best suggestion to give to maven users ?
> 
> -- Enrico
> 
> 
> 
>> The only modules that you need to be concerned about are:
>> 
>> java.corba
>> java.transaction
>> java.activation
>> java.xml.bind
>> java.xml.ws
>> java.xml.ws.annotation
>> 
>> and the java.se.ee aggregator.
>> 
>> These modules are deprecated in Java SE and are proposed to be removed in
>> a future release.
>> 
>> Aside from java.corba, the 5 modules shared with Java EE are standalone
>> technologies, each with one or more JSRs and its own download. Each of
>> these projects used to be on java.net but moved to the Java EE github
>> project recently. I don't know if the move to Eclipse will change anything
>> there.
>> 
>> In any case, each of the standalone versions can be deployed on the class
>> path with JDK 9.
>> 
>> In time they will be deployable as modules too and this will allow them to
>> be deployed on the upgrade module path (--upgrade-module-path) to
>> upgrade/override the module in the run-time image with the standalone or
>> Java EE module. This will actually work with all except for the transaction
>> API as there are a couple of issues to sort out there before it can be
>> deployed as a module.
>> 
>> As I understand it, the Spring folks in the JIRA issue are deploying the
>> JTA JAR file on the class path. That should just work but is complicated by
>> `--add-module=java.se.ee` as that will cause the java.transaction module
>> to be resolved. You can't split the javax.transaction package between a
>> module and the class path.
>> 
>> For the surefire plugin then dropping the --add-modules should be looked
>> at. You'll need to do that anyway once java.se.ee goes away. If the
>> plugin relies on JAXB then adding a dependency on the standalone version
>> should work.
>> 
>> -Alan
>> 
>> 
>> 
>> 
>> 

Mojo testing with JUnit 4?

[Russell Gold]

Are there versions of the base test cases (AbstractMojoTestCase, 
PlexusTestCase) that are usable with JUnit 4? If not, has anyone published a 
pattern for testing mojos with JUnit 4?
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org