from:"Daniel Widdis"

Re: Feedback sought

2023-10-15 Thread Daniel Widdis

Spotless is another great option. spotless/plugin-maven/README.md at main · diffplug/spotlessgithub.comSent from my iPhoneOn Oct 15, 2023, at 7:16 AM, Joseph Kesselman  wrote:Hm. Doesn't handle language-semantic formatting (yet?), which in my experience is often a bigger deal than spaces vs tabs. Good start, though.--   /_  Joe Kesselman (he/him/his)-/ _) My Alexa skill for New Music/New Sounds fans:   /   https://www.amazon.com/dp/B09WJ3H657/() Plaintext Ribbon Campaign/\ Stamp out HTML mail!From: Nils Breunese Sent: Sunday, October 15, 2023 3:01:28 AMTo: Maven Users List Subject: Re: Feedback soughtJoseph Kesselman  wrote:Re "IDE droppings"... My experience is that they can actually be useful in expressing things like preferred code formatting style in importable/executable form. (I'd rather have a standard cross-editor way if representing that, but I don't know of one.)You could take a look at EditorConfig: https://editorconfig.org/Nils.

Re: [m-javadoc-plugin] how to exclude transitive dependency

2023-03-26 Thread Daniel Widdis

Here's a good blog post to link to that explains why all maintainers should do 
this even if they're not migrating.

http://branchandbound.net/blog/java/2017/12/automatic-module-name/


On 3/26/23, 8:13 PM, "Maxim Solodovnik" mailto:solo...@apache.org>> wrote:


Thanks a lot for the answer!


I'll try to contact authors of problematic library.


It is weirs this library causing the issue, since it's classes are not
being used directly
(it it is transitive dependency)
Compilation is successful and only Javadoc is failing ...


On Mon, 27 Mar 2023 at 09:17, Daniel Widdis mailto:wid...@gmail.com>> wrote:
>
> The root of the problem is the automatic module name generation of the 
> jool-java-8 jar file. By default it becomes jool.java.8 and a number by 
> itself is an illegal portion of a module name.
>
> Without using "Automatic-Module-Name" your project builds on the classpath as 
> always. When including that, it attempts to build on the module path and the 
> Javadoc plugin apparently does not handle that well.
>
> I fought similar issues for a while and eventually got rid of the problematic 
> dependency.
>
> You might try moditect to insert a module name of your choice. You might try 
> approaching the authors of jool-java-8 and requesting they provide a valid 
> automatic module name.
>
> On 3/26/23, 6:46 PM, "Maxim Solodovnik"  <mailto:solo...@apache.org> <mailto:solo...@apache.org 
> <mailto:solo...@apache.org>>> wrote:
>
>
> I get zero responses for my emails :((
> Maybe I should provide more details?
> Or my English is not good enough? :(
>
>
> This issue blocks our release process, I'd love to get some help
>
>
> Thanks in advance :)
>
>
> On Sat, 25 Mar 2023 at 23:34, Maxim Solodovnik  <mailto:solomax...@gmail.com> <mailto:solomax...@gmail.com 
> <mailto:solomax...@gmail.com>>> wrote:
> >
> > Here is the sample project: https://github.com/solomax/javadoc-exclude 
> > <https://github.com/solomax/javadoc-exclude> 
> > <https://github.com/solomax/javadoc-exclude> 
> > <https://github.com/solomax/javadoc-exclude>;>
> >
> > The issue is NOT reproducible if "Automatic-Module-Name" is absent
> >
> > On Tue, 14 Feb 2023 at 13:42, Maxim Solodovnik  > <mailto:solomax...@gmail.com> <mailto:solomax...@gmail.com 
> > <mailto:solomax...@gmail.com>>> wrote:
> > >
> > > Same results with version 3.5.0
> > >
> > > On Tue, 14 Feb 2023 at 12:07, Maxim Solodovnik  > > <mailto:solomax...@gmail.com> <mailto:solomax...@gmail.com 
> > > <mailto:solomax...@gmail.com>>> wrote:
> > > >
> > > > Hello All,
> > > >
> > > > I'm getting following error while running `javadoc:3.4.1:jar`:
> > > >
> > > > [ERROR] Failed to execute goal
> > > > org.apache.maven.plugins:maven-javadoc-plugin:3.4.1:jar
> > > > (attach-javadocs) on project openmeetings-util: Execution
> > > > attach-javadocs of goal
> > > > org.apache.maven.plugins:maven-javadoc-plugin:3.4.1:jar failed: Unable
> > > > to derive module descriptor for
> > > > /home/solomax/.m2/repository/org/jooq/jool-java-8/0.9.14/jool-java-8-0.9.14.jar:
> > > > jool.java.8: Invalid module name: '8' is not a Java identifier ->
> > > > [Help 1]
> > > >
> > > > this "broken" jar is transitive dependency I would like to exclude
> > > > from javadoc generation
> > > >
> > > > [INFO] --- dependency:3.5.0:tree (default-cli) @ openmeetings-util ---
> > > > [INFO] org.apache.openmeetings:openmeetings-util:jar:7.1.0-SNAPSHOT
> > > > [INFO] +- org.dom4j:dom4j:jar:2.1.4:compile
> > > > [INFO] +- org.mnode.ical4j:ical4j:jar:4.0.0-beta5:compile
> > > > [INFO] | +- org.apache.commons:commons-collections4:jar:4.4:compile
> > > > [INFO] | +- commons-validator:commons-validator:jar:1.7:compile
> > > > [INFO] | | +- commons-beanutils:commons-beanutils:jar:1.9.4:compile
> > > > [INFO] | | +- commons-digester:commons-digester:jar:2.1:compile
> > > > [INFO] | | +- commons-logging:commons-logging:jar:1.2:compile
> > > > [INFO] | | \- commons-collections:commons-collections:jar:3.2.2:compile
> > > > [INFO] | +- org.threeten:threeten-extra:jar:1.7.0:compile
> > > > [INFO] | \- org.jooq:jool-java-8:jar:0.9.14:compile
> > > >
> > > > How this can be achived?
> > > >
> > > > I've already

Re: [m-javadoc-plugin] how to exclude transitive dependency

2023-03-26 Thread Daniel Widdis

The root of the problem is the automatic module name generation of the 
jool-java-8 jar file.  By default it becomes jool.java.8 and a number by itself 
is an illegal portion of a module name.

Without using "Automatic-Module-Name" your project builds on the classpath as 
always.  When including that, it attempts to build on the module path and the 
Javadoc plugin apparently does not handle that well.

I fought similar issues for a while and eventually got rid of the problematic 
dependency.  

You might try moditect to insert a module name of your choice.  You might try 
approaching the authors of jool-java-8 and requesting they provide a valid 
automatic module name.

On 3/26/23, 6:46 PM, "Maxim Solodovnik" mailto:solo...@apache.org>> wrote:


I get zero responses for my emails :((
Maybe I should provide more details?
Or my English is not good enough? :(


This issue blocks our release process, I'd love to get some help


Thanks in advance :)


On Sat, 25 Mar 2023 at 23:34, Maxim Solodovnik mailto:solomax...@gmail.com>> wrote:
>
> Here is the sample project: https://github.com/solomax/javadoc-exclude 
> 
>
> The issue is NOT reproducible if "Automatic-Module-Name" is absent
>
> On Tue, 14 Feb 2023 at 13:42, Maxim Solodovnik  > wrote:
> >
> > Same results with version 3.5.0
> >
> > On Tue, 14 Feb 2023 at 12:07, Maxim Solodovnik  > > wrote:
> > >
> > > Hello All,
> > >
> > > I'm getting following error while running `javadoc:3.4.1:jar`:
> > >
> > > [ERROR] Failed to execute goal
> > > org.apache.maven.plugins:maven-javadoc-plugin:3.4.1:jar
> > > (attach-javadocs) on project openmeetings-util: Execution
> > > attach-javadocs of goal
> > > org.apache.maven.plugins:maven-javadoc-plugin:3.4.1:jar failed: Unable
> > > to derive module descriptor for
> > > /home/solomax/.m2/repository/org/jooq/jool-java-8/0.9.14/jool-java-8-0.9.14.jar:
> > > jool.java.8: Invalid module name: '8' is not a Java identifier ->
> > > [Help 1]
> > >
> > > this "broken" jar is transitive dependency I would like to exclude
> > > from javadoc generation
> > >
> > > [INFO] --- dependency:3.5.0:tree (default-cli) @ openmeetings-util ---
> > > [INFO] org.apache.openmeetings:openmeetings-util:jar:7.1.0-SNAPSHOT
> > > [INFO] +- org.dom4j:dom4j:jar:2.1.4:compile
> > > [INFO] +- org.mnode.ical4j:ical4j:jar:4.0.0-beta5:compile
> > > [INFO] | +- org.apache.commons:commons-collections4:jar:4.4:compile
> > > [INFO] | +- commons-validator:commons-validator:jar:1.7:compile
> > > [INFO] | | +- commons-beanutils:commons-beanutils:jar:1.9.4:compile
> > > [INFO] | | +- commons-digester:commons-digester:jar:2.1:compile
> > > [INFO] | | +- commons-logging:commons-logging:jar:1.2:compile
> > > [INFO] | | \- commons-collections:commons-collections:jar:3.2.2:compile
> > > [INFO] | +- org.threeten:threeten-extra:jar:1.7.0:compile
> > > [INFO] | \- org.jooq:jool-java-8:jar:0.9.14:compile
> > >
> > > How this can be achived?
> > >
> > > I've already tried
> > > 
> > > 
> > >
> > > with no luck
> > >
> > >  has default value `false`
> > >
> > > Will appreciate any help :)))
> > >
> > > My configuration is
> > >
> > > Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> > > Maven home: /opt/maven
> > > Java version: 17.0.5, vendor: Private Build, runtime:
> > > /usr/lib/jvm/java-17-openjdk-amd64
> > > Default locale: en_US, platform encoding: UTF-8
> > > OS name: "linux", version: "5.15.0-60-generic", arch: "amd64", family: 
> > > "unix"
> > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Maxim
> >
> >
> >
> > --
> > Best regards,
> > Maxim
>
>
>
> --
> Best regards,
> Maxim


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org 

For additional commands, e-mail: users-h...@maven.apache.org 








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

Re: m-javadoc-plugin with JPMS

2022-10-17 Thread Daniel Widdis

I have filed issue 
https://issues.apache.org/jira/projects/MJAVADOC/issues/MJAVADOC-736 

 

Simple reproducer project here (mvn javadoc:jar or mvn javadoc:javadoc fail): 
https://github.com/dbwiddis/foo 

 

 

From: Daniel Widdis 
Date: Sunday, October 16, 2022 at 10:47 PM
To: Maven Users List 
Subject: Re: m-javadoc-plugin with JPMS

 

Ah, finally got past this bug to release by just backing out the one change in 
my POM that I’d dismissed as irrelevant.  I had entered this code in the 
problematic module’s POM to work around a bug failing modular builds without an 
intervening clean:

 





org.apache.maven.plugins

maven-clean-plugin





auto-clean



clean



initialize







 

While that effectively added a “clean” at the start of the build it appears to 
have also triggered the behavior described in the thread below.  I still think 
there’s a bug in AbstractJavadocMojo in the if/else looking for a module 
descriptor, which fails to look for the module descriptor in the case that an 
output directory exists but a jar does not.

 

Workaround if you’re not using junit-platform-maven-plugin is to add a package 
or install (or possibly site?) prior to the goal you’re trying to use.

 

 

From: "Daniel B. Widdis" 
Date: Sunday, October 16, 2022 at 10:04 PM
To: Maven Users List 
Subject: Re: m-javadoc-plugin with JPMS

 

It's amusing when you come upon an error, google the error message, and find an 
email thread you participated in and forgot about.

 

Resurrecting this thread from last July and hoping for some insight.

 

I last released my project using maven-release-plugin on July 20, 2022 with no 
issues.  My project setup includes a parent pom and modules

 - one module builds with compatibility for Java 8 and has automatic-module-name

 - another module builds 

 - another module contains only the src/main/java/module-info.java file, and 
uses the maven-resources-plugin to add source and resource paths to the other 
module's source tree

 - I have made no significant changes to my POM since the previous release, and 
it works just fine for test, verify, deploy goals, but breaks on maven 
release:perform with the message cited earlier in this thread:

 

[ERROR] Creating an aggregated report for both named and unnamed modules is not 
possible.
[ERROR] Ensure that every module has a module descriptor or is a jar with a 
MANIFEST.MF containing an Automatic-Module-Name.
[ERROR] Fix the following projects:
[ERROR]  - com.github.oshi:oshi-core-java11

 

The error message is not helpful, as that module descriptor IS in that module.

 

I can reproduce the error on the commandline by running mvn javadoc:jar.   I 
can work around it by running mvn package javadoc:jar.  However, attempting to 
add the package goal to the maven release plugin does not fix the problem.

 

I have tried adding an automatic module name in addition to the module 
descriptor.  Same problem.

 

I have tried changing the lifecycle phase during which these javadoc goals are 
executed.  Same problem.

 

I have tried adding "dummy" class files in the problematic module's source tree 
just in case the solo file and lack of support for the added source files is an 
issue.  Same problem.

 

I have traced the error down to the following code:

 

The log error message is generated in AbstractJavadocMogo line 5085 when the 
unnamedProjects list is not empty.

https://github.com/apache/maven-javadoc-plugin/blob/8b589325762280cef9ff8df2bc3431d4fccafbc7/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L5087-L5094

 

That occurs when the conditional on line 5046 (result not null and 
getModuleDescriptor not null) fails.

https://github.com/apache/maven-javadoc-plugin/blob/8b589325762280cef9ff8df2bc3431d4fccafbc7/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L5046

 

The result variable checks two sources.  First, it looks for a jar with 
getClassesFile() if it exists, and selects the automatic module name from it.  
Even if result fails here, it does not bother to check for a descriptor 
elsewhere due to the if/else.  

https://github.com/apache/maven-javadoc-plugin/blob/8b589325762280cef9ff8df2bc3431d4fccafbc7/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L5003

 

Tracing through getClasses() it eventually returns the output directory if it's 
not null, so in the case there's no jar in the output directory, I think this 
fails and never gets to the "else" case (findMainDescriptor())  where it 
actually looks for module-info.java

https://github.com/apache/maven-javadoc-plugin/blob/8b589325762280cef9ff8df2bc3431d4fccafbc7/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L5031

 

I believe this may be the bug reported earlier in this thread by Maxim 
Solodovnik, and may be the r

Re: m-javadoc-plugin with JPMS

2022-10-16 Thread Daniel Widdis

 Aug 28, 2022 at 10:25 PM Maxim Solodovnik  wrote:

maven-javadoc-plugin:3.4.1 - same error :(((

On Wed, 20 Jul 2022 at 22:19, Maxim Solodovnik  wrote:
>
> done,
>
> same error :(
>
> On Wed, 20 Jul 2022 at 22:13, Maxim Solodovnik  wrote:
> >
> > well,
> >
> > m-javadoc-plugin is being called at `*db` module only which is only
> > depends on `*util` module
> > both has `module-info.java`
> >
> > let me add `module-info.java` to all modules (not sure why) so we can
> > ensure this is not a problem :)
> >
> > On Wed, 20 Jul 2022 at 21:51, Daniel Widdis  wrote:
> > >
> > > Some modules have module-info.java and some don’t.  That’s exactly what 
> > > the error says.
> > >
> > > > On Jul 20, 2022, at 7:24 AM, Maxim Solodovnik  
> > > > wrote:
> > > >
> > > > On Tue, 19 Jul 2022 at 17:20, Olivier Lamy  wrote:
> > > >>
> > > >>> On Tue, 19 Jul 2022 at 16:42, Maxim Solodovnik  
> > > >>> wrote:
> > > >>>
> > > >>> On Tue, 19 Jul 2022 at 13:16, Daniel Widdis  wrote:
> > > >>>>
> > > >>>>> The only problem of having both is redundancy :)
> > > >>>>
> > > >>>> Technically speaking, you always have an automatic module name even 
> > > >>>> if
> > > >>> you don't explicitly name it.  It will use your jar filename to deduce
> > > >>> one.   Unless you use a reserved word in your jar, and then the world
> > > >>> breaks. __
> > > >>>
> > > >>> I thought maybe this is the issue in m-javadoc-plugin: it is weird to
> > > >>> check `automatic module name` in manifest if module-info.java present
> > > >>>
> > > >>
> > > >> Sounds possibly a bug.
> > > >> Do you have an easy project to reproduce you could provide?
> > > >>
> > > >
> > > > sorry for delay :)
> > > > here is very simple example project:
> > > > https://github.com/solomax/multimodule-with-war
> > > >
> > > >>
> > > >>
> > > >>>
> > > >>>
> > > >>>>
> > > >>>> On 7/18/22, 11:07 PM, "Maxim Solodovnik"  
> > > >>>> wrote:
> > > >>>>
> > > >>>>Thanks for the answer Daniel :)
> > > >>>>
> > > >>>>On Tue, 19 Jul 2022 at 13:03, Daniel Widdis 
> > > >>> wrote:
> > > >>>>>
> > > >>>>> I think you're asking on the right list.  And it's not a "basic"
> > > >>> question but it isn't an obvious answer either.
> > > >>>>>
> > > >>>>> I'm not sure your question has enough detail for anyone to deduce
> > > >>> the answer.  Linking to your project may help you get more attention 
> > > >>> on it.
> > > >>>>>
> > > >>>>> FWIW, I have both an automatic module name and module-info in my
> > > >>> modular projects and it doesn't cause any problems, but that's 
> > > >>> clearly not
> > > >>> your problem.
> > > >>>>
> > > >>>>The only problem of having both is redundancy :)
> > > >>>>(and they should be in-sync)
> > > >>>>
> > > >>>>everything works as expected in case `Automatic-Module-Name` is in
> > > >>> manifest
> > > >>>>
> > > >>>>I'll try to create simple project to illustrate the problem :)
> > > >>>>
> > > >>>>>
> > > >>>>> On 7/18/22, 10:55 PM, "Maxim Solodovnik" 
> > > >>> wrote:
> > > >>>>>
> > > >>>>>Hello,
> > > >>>>>
> > > >>>>>Is the question too basic?
> > > >>>>>Or maybe I'm asking wrong list? :)
> > > >>>>>
> > > >>>>>On Fri, 15 Jul 2022 at 15:41, Maxim Solodovnik <
> > > >>> solomax...@gmail.com> wrote:
> > > >>>>>>
> > > >>>>>>

Re: m-javadoc-plugin with JPMS

2022-07-20 Thread Daniel Widdis

Some modules have module-info.java and some don’t.  That’s exactly what the 
error says.  

> On Jul 20, 2022, at 7:24 AM, Maxim Solodovnik  wrote:
> 
> On Tue, 19 Jul 2022 at 17:20, Olivier Lamy  wrote:
>> 
>>> On Tue, 19 Jul 2022 at 16:42, Maxim Solodovnik  wrote:
>>> 
>>> On Tue, 19 Jul 2022 at 13:16, Daniel Widdis  wrote:
>>>> 
>>>>> The only problem of having both is redundancy :)
>>>> 
>>>> Technically speaking, you always have an automatic module name even if
>>> you don't explicitly name it.  It will use your jar filename to deduce
>>> one.   Unless you use a reserved word in your jar, and then the world
>>> breaks. __
>>> 
>>> I thought maybe this is the issue in m-javadoc-plugin: it is weird to
>>> check `automatic module name` in manifest if module-info.java present
>>> 
>> 
>> Sounds possibly a bug.
>> Do you have an easy project to reproduce you could provide?
>> 
> 
> sorry for delay :)
> here is very simple example project:
> https://github.com/solomax/multimodule-with-war
> 
>> 
>> 
>>> 
>>> 
>>>> 
>>>> On 7/18/22, 11:07 PM, "Maxim Solodovnik"  wrote:
>>>> 
>>>>Thanks for the answer Daniel :)
>>>> 
>>>>On Tue, 19 Jul 2022 at 13:03, Daniel Widdis 
>>> wrote:
>>>>> 
>>>>> I think you're asking on the right list.  And it's not a "basic"
>>> question but it isn't an obvious answer either.
>>>>> 
>>>>> I'm not sure your question has enough detail for anyone to deduce
>>> the answer.  Linking to your project may help you get more attention on it.
>>>>> 
>>>>> FWIW, I have both an automatic module name and module-info in my
>>> modular projects and it doesn't cause any problems, but that's clearly not
>>> your problem.
>>>> 
>>>>The only problem of having both is redundancy :)
>>>>(and they should be in-sync)
>>>> 
>>>>everything works as expected in case `Automatic-Module-Name` is in
>>> manifest
>>>> 
>>>>I'll try to create simple project to illustrate the problem :)
>>>> 
>>>>> 
>>>>> On 7/18/22, 10:55 PM, "Maxim Solodovnik" 
>>> wrote:
>>>>> 
>>>>>Hello,
>>>>> 
>>>>>Is the question too basic?
>>>>>Or maybe I'm asking wrong list? :)
>>>>> 
>>>>>On Fri, 15 Jul 2022 at 15:41, Maxim Solodovnik <
>>> solomax...@gmail.com> wrote:
>>>>>> 
>>>>>> Hello All,
>>>>>> 
>>>>>> I'm trying to migrate our project to JPMS
>>>>>> After adding module-info.java to my modules (and removing
>>> explicitly
>>>>>> set `Automatic-Module-Name`)
>>>>>> I'm getting:
>>>>>> 
>>>>>> [INFO] --- maven-javadoc-plugin:3.4.0:javadoc-no-fork
>>> (default)
>>>>>> [ERROR] Creating an aggregated report for both named and
>>> unnamed
>>>>>> modules is not possible.
>>>>>> [ERROR] Ensure that every module has a module descriptor or
>>> is a jar
>>>>>> with a MANIFEST.MF containing an Automatic-Module-Name.
>>>>>> 
>>>>>> I thought `Automatic-Module-Name` should be added only if
>>>>>> `module-info.java` is missing
>>>>>> Is it bug in maven-javadoc-plugin or maybe I'm doing
>>> something wrong? :)
>>>>>> 
>>>>>> java 17
>>>>>> Apache Maven 3.8.5
>>>>>> 
>>>>>> --
>>>>>> Best regards,
>>>>>> Maxim
>>>>> 
>>>>> 
>>>>> 
>>>>>--
>>>>>Best regards,
>>>>>Maxim
>>>>> 
>>>>> 
>>> -
>>>>>To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>>>>For additional commands, e-mail: users-h...@maven.apache.org
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>> -
>>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>>> 
>>>> 
>>>> 
>>>>--
>>>>Best regards,
>>>>Maxim
>>>> 
>>>>-
>>>>To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>>>For additional commands, e-mail: users-h...@maven.apache.org
>>>> 
>>>> 
>>>> 
>>>> 
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>> 
>>> 
>>> 
>>> --
>>> Best regards,
>>> Maxim
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>> 
>>> 
> 
> 
> 
> -- 
> Best regards,
> Maxim
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 

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

Re: m-javadoc-plugin with JPMS

2022-07-18 Thread Daniel Widdis

> The only problem of having both is redundancy :)

Technically speaking, you always have an automatic module name even if you 
don't explicitly name it.  It will use your jar filename to deduce one.   
Unless you use a reserved word in your jar, and then the world breaks. __ 

On 7/18/22, 11:07 PM, "Maxim Solodovnik"  wrote:

Thanks for the answer Daniel :)

On Tue, 19 Jul 2022 at 13:03, Daniel Widdis  wrote:
>
> I think you're asking on the right list.  And it's not a "basic" question 
but it isn't an obvious answer either.
>
> I'm not sure your question has enough detail for anyone to deduce the 
answer.  Linking to your project may help you get more attention on it.
>
> FWIW, I have both an automatic module name and module-info in my modular 
projects and it doesn't cause any problems, but that's clearly not your problem.

The only problem of having both is redundancy :)
(and they should be in-sync)

everything works as expected in case `Automatic-Module-Name` is in manifest

I'll try to create simple project to illustrate the problem :)

>
> On 7/18/22, 10:55 PM, "Maxim Solodovnik"  wrote:
>
> Hello,
>
> Is the question too basic?
> Or maybe I'm asking wrong list? :)
>
> On Fri, 15 Jul 2022 at 15:41, Maxim Solodovnik  
wrote:
> >
> > Hello All,
> >
> > I'm trying to migrate our project to JPMS
> > After adding module-info.java to my modules (and removing explicitly
> > set `Automatic-Module-Name`)
> > I'm getting:
> >
> > [INFO] --- maven-javadoc-plugin:3.4.0:javadoc-no-fork (default)
> > [ERROR] Creating an aggregated report for both named and unnamed
> > modules is not possible.
> > [ERROR] Ensure that every module has a module descriptor or is a jar
> > with a MANIFEST.MF containing an Automatic-Module-Name.
> >
> > I thought `Automatic-Module-Name` should be added only if
> > `module-info.java` is missing
> > Is it bug in maven-javadoc-plugin or maybe I'm doing something 
wrong? :)
> >
> > java 17
> > Apache Maven 3.8.5
> >
> > --
> > Best regards,
> > Maxim
>
>
>
> --
> Best regards,
> Maxim
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>


-- 
Best regards,
Maxim

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




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

Re: m-javadoc-plugin with JPMS

2022-07-18 Thread Daniel Widdis

I think you're asking on the right list.  And it's not a "basic" question but 
it isn't an obvious answer either.

I'm not sure your question has enough detail for anyone to deduce the answer.  
Linking to your project may help you get more attention on it.

FWIW, I have both an automatic module name and module-info in my modular 
projects and it doesn't cause any problems, but that's clearly not your problem.

On 7/18/22, 10:55 PM, "Maxim Solodovnik"  wrote:

Hello,

Is the question too basic?
Or maybe I'm asking wrong list? :)

On Fri, 15 Jul 2022 at 15:41, Maxim Solodovnik  wrote:
>
> Hello All,
>
> I'm trying to migrate our project to JPMS
> After adding module-info.java to my modules (and removing explicitly
> set `Automatic-Module-Name`)
> I'm getting:
>
> [INFO] --- maven-javadoc-plugin:3.4.0:javadoc-no-fork (default)
> [ERROR] Creating an aggregated report for both named and unnamed
> modules is not possible.
> [ERROR] Ensure that every module has a module descriptor or is a jar
> with a MANIFEST.MF containing an Automatic-Module-Name.
>
> I thought `Automatic-Module-Name` should be added only if
> `module-info.java` is missing
> Is it bug in maven-javadoc-plugin or maybe I'm doing something wrong? :)
>
> java 17
> Apache Maven 3.8.5
>
> --
> Best regards,
> Maxim

-- 
Best regards,
Maxim

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

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

Re: JPMS – Test sources extra Java SE module dependencies

2022-07-02 Thread Daniel Widdis

You are traveling a well-known path to many of us.

I highly recommend taking a look at junit-platform-maven-plugin: 
https://github.com/sormuras/junit-platform-maven-plugin

Blog post outlining how to do what you'e doing is here:
https://sormuras.github.io/blog/2018-09-11-testing-in-the-modular-world.html

TLDR:  
1. you keep the one module-info.java in your main project
2. you add a module-info.test in your test directory with appropriate command 
line entries for add-opens (to see your source code) and add-reads (essentially 
replacing the additional "requires")


On 7/2/22, 4:46 PM, "Stanimir Stamenkov"  wrote:

I can't figure out what's the best practice or just proper way for 
setting up a JPMS Maven project with test sources that have additional 
Java SE module dependencies to those of the main sources.

I have the following basic project structure:

 pom.xml
 src/
 ├─ main/
 │  └─ java/
 │ ├─ module-info.java
 │ └─ net/example/stanio/jpms/
 │└─ HelloJPMS.java
 └─ test/
└─ java/
   └─ net/example/stanio/jpms/
  └─ HelloJPMSTest.java

The `module-info.java` is:

 module net.example.stanio.jpms {
 exports net.example.stanio.jpms;
 }

That is the main sources don't have any dependencies other than 
`java.base`, but the tests use some JAXP (`java.xml`).

My `pom.xml` is like:

 
 4.0.0

 net.example.stanio
 maven-jpms
 0.0.1-SNAPSHOT

 maven-jpms

 
 
UTF-8
 9
 
true
 

 
 
 junit
 junit
 4.13.2
 test
 
 

 
 
 
maven-compiler-plugin
3.10.1
 
 
 
 

Running `mvn -V clean test` I'm getting:

```
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: C:\...
Java version: 11.0.12, vendor: Oracle Corporation, runtime: C:\...
Default locale: en_US, platform encoding: Cp1251
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
[INFO] Scanning for projects...
...
[INFO] --- maven-compiler-plugin:3.10.1:testCompile (default-testCompile) @ 
maven-jpms ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 1 source file to C:\...\maven-jpms\target\test-classes
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR] 
/C:/.../maven-jpms/src/test/java/net/example/stanio/jpms/HelloJPMSTest.java:[7,17]
 package javax.xml.transform is not visible
   (package javax.xml.transform is declared in module jdk.pack, but module 
net.example.stanio.jpms does not read it)
[ERROR] 
/C:/.../maven-jpms/src/test/java/net/example/stanio/jpms/HelloJPMSTest.java:[8,27]
 package javax.xml.transform.sax is not visible
   (package javax.xml.transform.sax is declared in module jdk.pack, but 
module net.example.stanio.jpms does not read it)
[ERROR] 
/C:/.../maven-jpms/src/test/java/net/example/stanio/jpms/HelloJPMSTest.java:[9,27]
 package javax.xml.transform.sax is not visible
   (package javax.xml.transform.sax is declared in module jdk.pack, but 
module net.example.stanio.jpms does not read it)
[ERROR] 
/C:/.../maven-jpms/src/test/java/net/example/stanio/jpms/HelloJPMSTest.java:[10,27]
 package javax.xml.transform.stream is not visible
   (package javax.xml.transform.stream is declared in module jdk.pack, but 
module net.example.stanio.jpms does not read it)
[INFO] 4 errors
[INFO] -
[INFO] 

[INFO] BUILD FAILURE
[INFO] 

[INFO] Total time:  2.668 s
[INFO] Finished at: 2022-07-03T01:49:22+03:00
[INFO] 

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.10.1:testCompile 
(default-testCompile) on project maven-jpms: Compilation failure: Compilation 
failure:
...
```

So I've added `src/test/java/module-info.java` like:

 module net.example.stanio.jpms {
 requires java.xml;
 requires junit;
 }

that appears to have solved the test compilation failure.  Note, I had 
to re-declare the other test dependencies (junit), as well. I would 
really like to avoid that double dependency bookkeepi

Re: Feedback sought

Re: [m-javadoc-plugin] how to exclude transitive dependency

Re: [m-javadoc-plugin] how to exclude transitive dependency

Re: m-javadoc-plugin with JPMS

Re: m-javadoc-plugin with JPMS

Re: m-javadoc-plugin with JPMS

Re: m-javadoc-plugin with JPMS

Re: m-javadoc-plugin with JPMS

Re: JPMS – Test sources extra Java SE module dependencies

9 matches

Site Navigation

Mail list logo

Footer information