[jira] [Issue Comment Deleted] (MJAVADOC-551) Error if path to project contains a spaces
[
https://issues.apache.org/jira/browse/MJAVADOC-551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesko Jochum updated MJAVADOC-551:
--
Comment: was deleted
(was: Sehr geehrte Damen und Herren,
vielen Dank für Ihre Nachricht. Ich bin ab Mo 07.01.2019 wieder im Büro für Sie
zu erreichen.
Mit freundlichen Grüßen,
Jesko Jochum
)
> Error if path to project contains a spaces
> --
>
> Key: MJAVADOC-551
> URL: https://issues.apache.org/jira/browse/MJAVADOC-551
> Project: Maven Javadoc Plugin
> Issue Type: Sub-task
> Components: fix
>Affects Versions: 3.0.1
> Environment: Windows 7 x64
> Apache Maven 3.5.4
>Reporter: Jesko Jochum
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.1.0
>
>
> This was no problem in version 2.10.4!
> If a project (e.g. the one appended to MJAVADOC-549 ) is stored in a
> subfolder, e.g. {{C:\Sub Folder\mjavadoc-fix-goal-example}} and the command
> mentioned in MJAVADOC-549 is called, then the following "file not found"
> error gets thrown:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.0.1:fix (default-cli) on
> project mjavadoc-fix-goal-example: IOException:
> C:\Sub%20Folder\mjavadoc-fix-goal-example\src\main\java\my\group\id\mjavadoc\MyApplication.java
> (Das System kann den angegebenen Pfad nicht finden) -> [Help 1]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-551) Error if path to project contains a spaces
[
https://issues.apache.org/jira/browse/MJAVADOC-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16727438#comment-16727438
]
Jesko Jochum commented on MJAVADOC-551:
---
Sehr geehrte Damen und Herren,
vielen Dank für Ihre Nachricht. Ich bin ab Mo 07.01.2019 wieder im Büro für Sie
zu erreichen.
Mit freundlichen Grüßen,
Jesko Jochum
> Error if path to project contains a spaces
> --
>
> Key: MJAVADOC-551
> URL: https://issues.apache.org/jira/browse/MJAVADOC-551
> Project: Maven Javadoc Plugin
> Issue Type: Sub-task
> Components: fix
>Affects Versions: 3.0.1
> Environment: Windows 7 x64
> Apache Maven 3.5.4
>Reporter: Jesko Jochum
>Priority: Major
>
> This was no problem in version 2.10.4!
> If a project (e.g. the one appended to MJAVADOC-549 ) is stored in a
> subfolder, e.g. {{C:\Sub Folder\mjavadoc-fix-goal-example}} and the command
> mentioned in MJAVADOC-549 is called, then the following "file not found"
> error gets thrown:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.0.1:fix (default-cli) on
> project mjavadoc-fix-goal-example: IOException:
> C:\Sub%20Folder\mjavadoc-fix-goal-example\src\main\java\my\group\id\mjavadoc\MyApplication.java
> (Das System kann den angegebenen Pfad nicht finden) -> [Help 1]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MJAVADOC-552) Author tag is removed, even though it should be excluded using the fixTags-setting
Jesko Jochum created MJAVADOC-552:
-
Summary: Author tag is removed, even though it should be excluded
using the fixTags-setting
Key: MJAVADOC-552
URL: https://issues.apache.org/jira/browse/MJAVADOC-552
Project: Maven Javadoc Plugin
Issue Type: Sub-task
Components: fix
Affects Versions: 3.0.1
Environment: Windows 7 x64
Apache Maven 3.5.4
Reporter: Jesko Jochum
The javadoc:fix goal overrides the {{@author}} tag(s) by default, which is a
pity if several developers deserve credit
{noformat}
/**
* Class developed by several authors.
*
* @author Developer, One
* @author Developer, Two
* @author Developer, Three
* @version 1.0.9, 2018-12-19
* @since 0.0.1
*/
{noformat}
for the work.
That is why I tried to specifically exclude the {{@author}} tag by adding the
configuration:
{noformat}
version,since,param,return,throws,link
{noformat}
Instead of ignoring the {{@author}} tag, i.e. leaving it as it is, it is
completely removed!
This effectively makes the {{javadoc:fix}} goal unusable to me.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-550) Additional update* and add* settings
[
https://issues.apache.org/jira/browse/MJAVADOC-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725023#comment-16725023
]
Jesko Jochum commented on MJAVADOC-550:
---
I found out that instead of using {{$\{date:-MM-DD HH:MM:SS\}}} one can use
the following settings
{noformat}
...
-MM-dd
HH:mm:ss
...
${project.version}, ${maven.build.timestamp}
...
{noformat}
> Additional update* and add* settings
>
>
> Key: MJAVADOC-550
> URL: https://issues.apache.org/jira/browse/MJAVADOC-550
> Project: Maven Javadoc Plugin
> Issue Type: Sub-task
> Components: fix, javadoc
>Affects Versions: 3.0.1
> Environment: Windows 7 x64
> Apache Maven 3.5.4
>Reporter: Jesko Jochum
>Priority: Minor
>
> It would be good to have more settings.
> The {{default*}} setting, seem to be used if there is no tag yet. The
> {{defaultVersion}} should be changed to something like:
> {noformat}
> defaultVersion=${project.version}, ${date:-MM-DD HH:MM:SS}
> {noformat}
> , with the {{$\{date:-MM-DD HH:MM:SS\}}} to show the build date and time
> time
> Several {{update*}} settings could be used to replace the old tags with a new
> ones, especially an {{updateVersion}} setting would be sensible.
> {noformat}
> updateAuthor=${user.name}
> updateVersion=${project.version}, ${date:-MM-DD HH:MM:SS}
> updateSince=${project.version} // Probably not necessary
> {noformat}
> An {{addAuthor}} settings could be used to append an author to the existing
> ones, if the existing string does not yet contain the one to add.
> {noformat}
> addAuthor=${user.name}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MJAVADOC-551) Error if path to project contains a spaces
Jesko Jochum created MJAVADOC-551:
-
Summary: Error if path to project contains a spaces
Key: MJAVADOC-551
URL: https://issues.apache.org/jira/browse/MJAVADOC-551
Project: Maven Javadoc Plugin
Issue Type: Sub-task
Components: fix
Affects Versions: 3.0.1
Environment: Windows 7 x64
Apache Maven 3.5.4
Reporter: Jesko Jochum
This was no problem in version 2.10.4!
If a project (e.g. the one appended to MJAVADOC-549 ) is stored in a subfolder,
e.g. {{C:\Sub Folder\mjavadoc-fix-goal-example}} and the command mentioned in
MJAVADOC-549 is called, then the following "file not found" error gets thrown:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.0.1:fix (default-cli) on
project mjavadoc-fix-goal-example: IOException:
C:\Sub%20Folder\mjavadoc-fix-goal-example\src\main\java\my\group\id\mjavadoc\MyApplication.java
(Das System kann den angegebenen Pfad nicht finden) -> [Help 1]
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MJAVADOC-549) Version tag comes and goes on several javadoc:fix goal runs
Jesko Jochum created MJAVADOC-549:
-
Summary: Version tag comes and goes on several javadoc:fix goal
runs
Key: MJAVADOC-549
URL: https://issues.apache.org/jira/browse/MJAVADOC-549
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: fix, javadoc
Affects Versions: 3.0.1
Environment: Windows 7 x64
Apache Maven 3.5.4
Reporter: Jesko Jochum
Attachments: mjavadoc-fix-goal-example.zip
Running the command
{noformat}
mvn org.apache.maven.plugins:maven-javadoc-plugin:3.0.1:fix
-DdefaultAuthor="Firstname Lastname" -DdefaultVersion="1.0.0, 2018-12-19"
-DefaultSince=1.0.0 -Dforce
{noformat}
for the first time, on the given example, generates the {{@author}} and
{{@version}} tags.
Running it the second time (every even time) the {{@version}} tag is removed.
Every odd time the {{@version}} tag is added again.
The {{@since}} tag is never added.
If there is already a javadoc comment for the {{MyApplication}} class, like
e.g.:
{noformat}
/**
* MyApplication class.
*
* @author Asdf Asdf
* @version 0.0.1-SNAPSHOT
*/
{noformat}
, both the {{@author}} and {{@version}} tags do not get updated.
I understand the {{@author}} tag does not get updated, but I would like to be
able to update the {{@version}} tag everytime before I release my software.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MJAVADOC-550) Additional update* and add* settings
Jesko Jochum created MJAVADOC-550:
-
Summary: Additional update* and add* settings
Key: MJAVADOC-550
URL: https://issues.apache.org/jira/browse/MJAVADOC-550
Project: Maven Javadoc Plugin
Issue Type: Sub-task
Components: fix, javadoc
Affects Versions: 3.0.1
Environment: Windows 7 x64
Apache Maven 3.5.4
Reporter: Jesko Jochum
It would be good to have more settings.
The {{default*}} setting, seem to be used if there is no tag yet. The
{{defaultVersion}} should be changed to something like:
{noformat}
defaultVersion=${project.version}, ${date:-MM-DD HH:MM:SS}
{noformat}
, with the {{$\{date:-MM-DD HH:MM:SS\}}} to show the build date and time
time
Several {{update*}} settings could be used to replace the old tags with a new
ones, especially an {{updateVersion}} setting would be sensible.
{noformat}
updateAuthor=${user.name}
updateVersion=${project.version}, ${date:-MM-DD HH:MM:SS}
updateSince=${project.version} // Probably not necessary
{noformat}
An {{addAuthor}} settings could be used to append an author to the existing
ones, if the existing string does not yet contain the one to add.
{noformat}
addAuthor=${user.name}
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MJAVADOC-548) Misleading Setting "excludePackageNames"
[
https://issues.apache.org/jira/browse/MJAVADOC-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16708355#comment-16708355
]
Jesko Jochum edited comment on MJAVADOC-548 at 12/4/18 8:16 AM:
How do you mean?
I do not have any colons, commas or semicolons in my {{excludePackageNames}},
because I do not have anything else to exclude. You could also change the value
to {{\*.temp.\*:}} or {{\*.temp}} or {{\*.temp.\*:org.acme.exclude1.\*}}
without a change in the error caused by the project being inside a folder named
{{temp}}.
Anyways, I copied the given example setting
{{\*.internal:org.acme.exclude1.\*:org.acme.exclude2}},
renamed the folder my project resides in from {{D:\temp}} to {{D:\internal}},
and I have the same result of no javadoc being generated.
Please see the attached example [^mjavadoc-548-example.zip], with my project
already residing inside a folder called {{internal}}. Extract the files and run
{{mvn javadoc:jar}} inside the project folder {{mjavadoc-548-example}} and you
will see that no javadoc is generated. Move the project out of the folder
called {{internal}} and run {{mvn javadoc:jar}} inside the project folder
again, and you will see the javadoc is generated as expected.
was (Author: jejo86):
How do you mean?
I do not have any colons, commas or semicolons in my {{excludePackageNames}},
because I do not have anything else to exclude. You could also change the value
to {{*.temp.*:}} or {{*.temp}} or {{*.temp.*:org.acme.exclude1.*}} without a
change in the error caused by the project being inside a folder named {{temp}}.
Anyways, I copied the given example setting
{{*.internal:org.acme.exclude1.*:org.acme.exclude2}},
renamed the folder my project resides in from {{D:\temp}} to {{D:\internal}},
and I have the same result of no javadoc being generated.
Please see the attached example [^mjavadoc-548-example.zip], with my project
already residing inside a folder called {{internal}}. Extract the files and run
{{mvn javadoc:jar}} inside the project folder {{mjavadoc-548-example}} and you
will see that no javadoc is generated. Move the project out of the folder
called {{internal}} and run {{mvn javadoc:jar}} inside the project folder
again, and you will see the javadoc is generated as expected.
> Misleading Setting "excludePackageNames"
>
>
> Key: MJAVADOC-548
> URL: https://issues.apache.org/jira/browse/MJAVADOC-548
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
> Components: javadoc
>Affects Versions: 2.10.4, 3.0.1
> Environment: Windows 7 x64
> Apache Maven 3.5.4
>Reporter: Jesko Jochum
>Priority: Minor
> Attachments: mjavadoc-548-example.zip
>
>
> The setting {{excludePackageNames}} is not working, as I would expect, or
> should be renamed to something like {{excludePathNames}} with an updated
> description, to reveal what it is really doing.
> I have the default layout for the sources, i.e. they get stored in the
> {{${project.basedir}\src\main\java}} subfolder of my project.
> For testing purposes I sometimes create classes in the subpackage
> {{my.companyname.temp}}, which I do not want to have included in the
> generated javadoc, why I use the following {{excludePackageNames}} setting:
> {noformat}
> ...
>
> *.temp.*
> ...
> {noformat}
> in my {{pom.xml}}.
> By doing this, I wanted to exclude all .java sources in the folders
> {{${project.basedir}\src\main\java*\temp*}} from the javadoc generation, but
> what I got was an exclusion of all .java sources, if there is a subfolder
> with the name {{temp}} in any segment of the path, even in the
> {{$\{project.basedir}}}.
> So, after moving the project into e.g. the folder {{D:\temp\}} no javadoc
> gets generated at all.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-548) Misleading Setting "excludePackageNames"
[
https://issues.apache.org/jira/browse/MJAVADOC-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16708355#comment-16708355
]
Jesko Jochum commented on MJAVADOC-548:
---
How do you mean?
I do not have any colons, commas or semicolons in my {{excludePackageNames}},
because I do not have anything else to exclude. You could also change the value
to {{*.temp.*:}} or {{*.temp}} or {{*.temp.*:org.acme.exclude1.*}} without a
change in the error caused by the project being inside a folder named {{temp}}.
Anyways, I copied the given example setting
{{*.internal:org.acme.exclude1.*:org.acme.exclude2}},
renamed the folder my project resides in from {{D:\temp}} to {{D:\internal}},
and I have the same result of no javadoc being generated.
Please see the attached example [^mjavadoc-548-example.zip], with my project
already residing inside a folder called {{internal}}. Extract the files and run
{{mvn javadoc:jar}} inside the project folder {{mjavadoc-548-example}} and you
will see that no javadoc is generated. Move the project out of the folder
called {{internal}} and run {{mvn javadoc:jar}} inside the project folder
again, and you will see the javadoc is generated as expected.
> Misleading Setting "excludePackageNames"
>
>
> Key: MJAVADOC-548
> URL: https://issues.apache.org/jira/browse/MJAVADOC-548
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
> Components: javadoc
>Affects Versions: 2.10.4, 3.0.1
> Environment: Windows 7 x64
> Apache Maven 3.5.4
>Reporter: Jesko Jochum
>Priority: Minor
> Attachments: mjavadoc-548-example.zip
>
>
> The setting {{excludePackageNames}} is not working, as I would expect, or
> should be renamed to something like {{excludePathNames}} with an updated
> description, to reveal what it is really doing.
> I have the default layout for the sources, i.e. they get stored in the
> {{${project.basedir}\src\main\java}} subfolder of my project.
> For testing purposes I sometimes create classes in the subpackage
> {{my.companyname.temp}}, which I do not want to have included in the
> generated javadoc, why I use the following {{excludePackageNames}} setting:
> {noformat}
> ...
>
> *.temp.*
> ...
> {noformat}
> in my {{pom.xml}}.
> By doing this, I wanted to exclude all .java sources in the folders
> {{${project.basedir}\src\main\java*\temp*}} from the javadoc generation, but
> what I got was an exclusion of all .java sources, if there is a subfolder
> with the name {{temp}} in any segment of the path, even in the
> {{$\{project.basedir}}}.
> So, after moving the project into e.g. the folder {{D:\temp\}} no javadoc
> gets generated at all.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MJAVADOC-548) Misleading Setting "excludePackageNames"
[
https://issues.apache.org/jira/browse/MJAVADOC-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesko Jochum updated MJAVADOC-548:
--
Attachment: mjavadoc-548-example.zip
> Misleading Setting "excludePackageNames"
>
>
> Key: MJAVADOC-548
> URL: https://issues.apache.org/jira/browse/MJAVADOC-548
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
> Components: javadoc
>Affects Versions: 2.10.4, 3.0.1
> Environment: Windows 7 x64
> Apache Maven 3.5.4
>Reporter: Jesko Jochum
>Priority: Minor
> Attachments: mjavadoc-548-example.zip
>
>
> The setting {{excludePackageNames}} is not working, as I would expect, or
> should be renamed to something like {{excludePathNames}} with an updated
> description, to reveal what it is really doing.
> I have the default layout for the sources, i.e. they get stored in the
> {{${project.basedir}\src\main\java}} subfolder of my project.
> For testing purposes I sometimes create classes in the subpackage
> {{my.companyname.temp}}, which I do not want to have included in the
> generated javadoc, why I use the following {{excludePackageNames}} setting:
> {noformat}
> ...
>
> *.temp.*
> ...
> {noformat}
> in my {{pom.xml}}.
> By doing this, I wanted to exclude all .java sources in the folders
> {{${project.basedir}\src\main\java*\temp*}} from the javadoc generation, but
> what I got was an exclusion of all .java sources, if there is a subfolder
> with the name {{temp}} in any segment of the path, even in the
> {{$\{project.basedir}}}.
> So, after moving the project into e.g. the folder {{D:\temp\}} no javadoc
> gets generated at all.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MJAVADOC-548) Misleading Setting "excludePackageNames"
Jesko Jochum created MJAVADOC-548:
-
Summary: Misleading Setting "excludePackageNames"
Key: MJAVADOC-548
URL: https://issues.apache.org/jira/browse/MJAVADOC-548
Project: Maven Javadoc Plugin
Issue Type: Improvement
Components: javadoc
Affects Versions: 3.0.1, 2.10.4
Environment: Windows 7 x64
Apache Maven 3.5.4
Reporter: Jesko Jochum
The setting {{excludePackageNames}} is not working, as I would expect, or
should be renamed to something like {{excludePathNames}} with an updated
description, to reveal what it is really doing.
I have the default layout for the sources, i.e. they get stored in the
{{${project.basedir}\src\main\java}} subfolder of my project.
For testing purposes I sometimes create classes in the subpackage
{{my.companyname.temp}}, which I do not want to have included in the generated
javadoc, why I use the following {{excludePackageNames}} setting:
{noformat}
...
*.temp.*
...
{noformat}
in my {{pom.xml}}.
By doing this, I wanted to exclude all .java sources in the folders
{{${project.basedir}\src\main\java*\temp*}} from the javadoc generation, but
what I got was an exclusion of all .java sources, if there is a subfolder with
the name {{temp}} in any segment of the path, even in the
{{$\{project.basedir}}}.
So, after moving the project into e.g. the folder {{D:\temp\}} no javadoc gets
generated at all.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-547) Plugin not working if project is NOT on %SYSTEMDRIVE%
[
https://issues.apache.org/jira/browse/MJAVADOC-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706894#comment-16706894
]
Jesko Jochum commented on MJAVADOC-547:
---
Ahh, I see what is going on now. I had the project in a subfolder called
{{temp}} and additionally the setting
{{\*.temp.\*}}. When moving the
project into any (sub)folder without a folder with the name {{temp}} in the
path, or when removing that {{excludePackageNames}} setting, the goal is
completed as expected.
So this ticket can be closed. I will create a new one for the unexpected
behavior (at least for me) of the {{excludePackageNames}} setting.
> Plugin not working if project is NOT on %SYSTEMDRIVE%
> -
>
> Key: MJAVADOC-547
> URL: https://issues.apache.org/jira/browse/MJAVADOC-547
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4, 3.0.1
> Environment: Windows 7 x64
> Apache Maven 3.5.4
>Reporter: Jesko Jochum
>Priority: Minor
>
> If running e.g. _mvn javadoc:jar_ on a project stored on C: (my
> %SYSTEMDRIVE%) everything works as expected, i.e. the javadoc gets generated
> and packed into a .jar file.
> If I move the project to a different drive, e.g. D: and run the same
> _javadoc:jar_ goal, nothing is generated. There is no error printed to
> console, and the only output is
> {{\artifact-id-of-application\target\javadoc-bundle-options\javadoc-options-javadoc-resources.xml}}
> as you can see in the following excerpt:
> {noformat}
> [INFO] --< my.package.dummy:artifact-id-of-application >---
> [INFO] Building Full Application Name 0.0.1-SNAPSHOT
> [5/7]
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] — maven-javadoc-plugin:3.0.1:jar (default-cli) @
> artifact-id-of-application —
> [INFO]
> [INFO] --< my.package.dummy:dummy-distribution >---
> [INFO] Building Distribution Project 0.0.1-SNAPSHOT
> [6/7]
> [INFO] [ pom
> ]-
> [INFO]
> [INFO] — maven-javadoc-plugin:3.0.1:jar (default-cli) @ dummy-distribution —
> [INFO] Not executing Javadoc as the project is not a Java classpath-capable
> package
> [INFO]
> {noformat}
> Can anyone reproduce this? Is this a known error?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MJAVADOC-547) Plugin not working if project is NOT on %SYSTEMDRIVE%
Jesko Jochum created MJAVADOC-547:
-
Summary: Plugin not working if project is NOT on %SYSTEMDRIVE%
Key: MJAVADOC-547
URL: https://issues.apache.org/jira/browse/MJAVADOC-547
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: javadoc
Affects Versions: 3.0.1, 2.10.4
Environment: Windows 7 x64
Apache Maven 3.5.4
Reporter: Jesko Jochum
If running e.g. _mvn javadoc:jar_ on a project stored on C: (my %SYSTEMDRIVE%)
everything works as expected, i.e. there the javadoc gets generated and packed
into a .jar file.
If I move the project to a different drive, e.g. D: and run the same
_javadoc:jar_ goal, nothing is generated. There is no error printed to console,
and the only output is
{{\artifact-id-of-application\target\javadoc-bundle-options\javadoc-options-javadoc-resources.xml"}}
as you can see in the following excerpt:
{{...}}
[INFO] --< my.package.dummy:artifact-id-of-application >---
[INFO] Building Full Application Name 0.0.1-SNAPSHOT [5/7]
[INFO] [ jar ]-
[INFO]
[INFO] --- maven-javadoc-plugin:3.0.1:jar (default-cli) @
artifact-id-of-application ---
[INFO]
[INFO] --< my.package.dummy:dummy-distribution >---
[INFO] Building Distribution Project 0.0.1-SNAPSHOT [6/7]
[INFO] [ pom ]-
[INFO]
[INFO] --- maven-javadoc-plugin:3.0.1:jar (default-cli) @ dummy-distribution ---
[INFO] Not executing Javadoc as the project is not a Java classpath-capable
package
[INFO]
...
Can anyone reproduce this? Is this a known error?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MJAVADOC-547) Plugin not working if project is NOT on %SYSTEMDRIVE%
[
https://issues.apache.org/jira/browse/MJAVADOC-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesko Jochum updated MJAVADOC-547:
--
Description:
If running e.g. _mvn javadoc:jar_ on a project stored on C: (my %SYSTEMDRIVE%)
everything works as expected, i.e. the javadoc gets generated and packed into a
.jar file.
If I move the project to a different drive, e.g. D: and run the same
_javadoc:jar_ goal, nothing is generated. There is no error printed to console,
and the only output is
{{\artifact-id-of-application\target\javadoc-bundle-options\javadoc-options-javadoc-resources.xml}}
as you can see in the following excerpt:
{{...}}
[INFO] --< my.package.dummy:artifact-id-of-application >---
[INFO] Building Full Application Name 0.0.1-SNAPSHOT [5/7]
[INFO] [ jar ]-
[INFO]
[INFO] — maven-javadoc-plugin:3.0.1:jar (default-cli) @
artifact-id-of-application —
[INFO]
[INFO] --< my.package.dummy:dummy-distribution >---
[INFO] Building Distribution Project 0.0.1-SNAPSHOT [6/7]
[INFO] [ pom ]-
[INFO]
[INFO] — maven-javadoc-plugin:3.0.1:jar (default-cli) @ dummy-distribution —
[INFO] Not executing Javadoc as the project is not a Java classpath-capable
package
[INFO]
...
Can anyone reproduce this? Is this a known error?
was:
If running e.g. _mvn javadoc:jar_ on a project stored on C: (my %SYSTEMDRIVE%)
everything works as expected, i.e. there the javadoc gets generated and packed
into a .jar file.
If I move the project to a different drive, e.g. D: and run the same
_javadoc:jar_ goal, nothing is generated. There is no error printed to console,
and the only output is
{{\artifact-id-of-application\target\javadoc-bundle-options\javadoc-options-javadoc-resources.xml"}}
as you can see in the following excerpt:
{{...}}
[INFO] --< my.package.dummy:artifact-id-of-application >---
[INFO] Building Full Application Name 0.0.1-SNAPSHOT [5/7]
[INFO] [ jar ]-
[INFO]
[INFO] --- maven-javadoc-plugin:3.0.1:jar (default-cli) @
artifact-id-of-application ---
[INFO]
[INFO] --< my.package.dummy:dummy-distribution >---
[INFO] Building Distribution Project 0.0.1-SNAPSHOT [6/7]
[INFO] [ pom ]-
[INFO]
[INFO] --- maven-javadoc-plugin:3.0.1:jar (default-cli) @ dummy-distribution ---
[INFO] Not executing Javadoc as the project is not a Java classpath-capable
package
[INFO]
...
Can anyone reproduce this? Is this a known error?
> Plugin not working if project is NOT on %SYSTEMDRIVE%
> -
>
> Key: MJAVADOC-547
> URL: https://issues.apache.org/jira/browse/MJAVADOC-547
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4, 3.0.1
> Environment: Windows 7 x64
> Apache Maven 3.5.4
>Reporter: Jesko Jochum
>Priority: Minor
>
> If running e.g. _mvn javadoc:jar_ on a project stored on C: (my
> %SYSTEMDRIVE%) everything works as expected, i.e. the javadoc gets generated
> and packed into a .jar file.
> If I move the project to a different drive, e.g. D: and run the same
> _javadoc:jar_ goal, nothing is generated. There is no error printed to
> console, and the only output is
> {{\artifact-id-of-application\target\javadoc-bundle-options\javadoc-options-javadoc-resources.xml}}
> as you can see in the following excerpt:
> {{...}}
> [INFO] --< my.package.dummy:artifact-id-of-application >---
> [INFO] Building Full Application Name 0.0.1-SNAPSHOT
> [5/7]
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] — maven-javadoc-plugin:3.0.1:jar (default-cli) @
> artifact-id-of-application —
> [INFO]
> [INFO] --< my.package.dummy:dummy-distribution >---
> [INFO] Building Distribution Project 0.0.1-SNAPSHOT
> [6/7]
> [INFO] [ pom
> ]-
> [INFO]
> [INFO] — maven-javadoc-plugin:3.0.1:jar (default-cli) @ dummy-distribution —
> [INFO] Not executing Javadoc as the project is not a Java classpath-capable
> package
> [INFO]
> ...
> Can anyone reproduce this? Is this a known error?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MRELEASE-933) maven-release-plugin:perform from a tag is broken for Git in version 2.5.3
[
https://issues.apache.org/jira/browse/MRELEASE-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16591383#comment-16591383
]
Jesko Jochum edited comment on MRELEASE-933 at 8/24/18 9:30 AM:
thanks for the quick response. apparently it is just a matter of changing the
superclass of
PerformReleaseMojo|https://issues.apache.org/jira/browse/SCM-729?focusedCommentId=14448351=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14448351].
it definitely works in version 2.3.2.
i will see whether i can fix this myself and contribute a patch to the project.
was (Author: jejo86):
thanks for the quick response. apparently it is just a matter of changing the
superclass of PerformReleaseMojo.
it definitely works in version 2.3.2.
i will see whether i can fix this myself and contribute a patch to the project.
> maven-release-plugin:perform from a tag is broken for Git in version 2.5.3
> --
>
> Key: MRELEASE-933
> URL: https://issues.apache.org/jira/browse/MRELEASE-933
> Project: Maven Release Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Eric Leventhal Arthen
>Priority: Major
>
> We are also blocked from using {{maven-release-plugin:2.5:perform}} for Git
> releases because it no longer passes in the tag name so the "git clone" fails.
> This worked correctly in {{maven-release-plugin:2.3.2:perform}}, with that
> version we got a command like this:
> {noformat}
> git clone --branch my-base-1.4.6 git@bithub:abcde/fghij.git
> /home/buildacct/work/5f89075470257ef1/base/target/checkout
> {noformat}
> (Note that the name here is (correctly) a tag name created by
> release:prepare, even though it is passed to --branch.)
> With {{maven-release-plugin:2.5:perform}} it does not include the actual tag
> name after "--branch" so the command fails.
> {noformat}
> git clone --branch g...@bithub.brightcove.com:abcde/fghij.git
> /home/buildacct/work/7483cd6cc5ce81ea/target/checkout
>[ERROR] The git-clone command failed.
> {noformat}
> We have to downgrade to the older maven-release-plugin, 2.3.2. From the
> ticket below this also worked in 2.2.1. I have not tried other versions.
> Found a description of this problem in SCM-729 in a comment in Feb 2015, but
> are creating this ticket because the issue is a recently introduced bug and
> that ticket is a feature request for a different component.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MRELEASE-933) maven-release-plugin:perform from a tag is broken for Git in version 2.5.3
[
https://issues.apache.org/jira/browse/MRELEASE-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16591383#comment-16591383
]
Jesko Jochum edited comment on MRELEASE-933 at 8/24/18 9:30 AM:
thanks for the quick response. apparently it is just a matter of [changing the
superclass of
PerformReleaseMojo|https://issues.apache.org/jira/browse/SCM-729?focusedCommentId=14448351=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14448351].
it definitely works in version 2.3.2.
i will see whether i can fix this myself and contribute a patch to the project.
was (Author: jejo86):
thanks for the quick response. apparently it is just a matter of changing the
superclass of
PerformReleaseMojo|https://issues.apache.org/jira/browse/SCM-729?focusedCommentId=14448351=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14448351].
it definitely works in version 2.3.2.
i will see whether i can fix this myself and contribute a patch to the project.
> maven-release-plugin:perform from a tag is broken for Git in version 2.5.3
> --
>
> Key: MRELEASE-933
> URL: https://issues.apache.org/jira/browse/MRELEASE-933
> Project: Maven Release Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Eric Leventhal Arthen
>Priority: Major
>
> We are also blocked from using {{maven-release-plugin:2.5:perform}} for Git
> releases because it no longer passes in the tag name so the "git clone" fails.
> This worked correctly in {{maven-release-plugin:2.3.2:perform}}, with that
> version we got a command like this:
> {noformat}
> git clone --branch my-base-1.4.6 git@bithub:abcde/fghij.git
> /home/buildacct/work/5f89075470257ef1/base/target/checkout
> {noformat}
> (Note that the name here is (correctly) a tag name created by
> release:prepare, even though it is passed to --branch.)
> With {{maven-release-plugin:2.5:perform}} it does not include the actual tag
> name after "--branch" so the command fails.
> {noformat}
> git clone --branch g...@bithub.brightcove.com:abcde/fghij.git
> /home/buildacct/work/7483cd6cc5ce81ea/target/checkout
>[ERROR] The git-clone command failed.
> {noformat}
> We have to downgrade to the older maven-release-plugin, 2.3.2. From the
> ticket below this also worked in 2.2.1. I have not tried other versions.
> Found a description of this problem in SCM-729 in a comment in Feb 2015, but
> are creating this ticket because the issue is a recently introduced bug and
> that ticket is a feature request for a different component.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRELEASE-933) maven-release-plugin:perform from a tag is broken for Git in version 2.5.3
[
https://issues.apache.org/jira/browse/MRELEASE-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16591383#comment-16591383
]
Jesko Jochum commented on MRELEASE-933:
---
thanks for the quick response. apparently it is just a matter of changing the
superclass of PerformReleaseMojo.
it definitely works in version 2.3.2.
i will see whether i can fix this myself and contribute a patch to the project.
> maven-release-plugin:perform from a tag is broken for Git in version 2.5.3
> --
>
> Key: MRELEASE-933
> URL: https://issues.apache.org/jira/browse/MRELEASE-933
> Project: Maven Release Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Eric Leventhal Arthen
>Priority: Major
>
> We are also blocked from using {{maven-release-plugin:2.5:perform}} for Git
> releases because it no longer passes in the tag name so the "git clone" fails.
> This worked correctly in {{maven-release-plugin:2.3.2:perform}}, with that
> version we got a command like this:
> {noformat}
> git clone --branch my-base-1.4.6 git@bithub:abcde/fghij.git
> /home/buildacct/work/5f89075470257ef1/base/target/checkout
> {noformat}
> (Note that the name here is (correctly) a tag name created by
> release:prepare, even though it is passed to --branch.)
> With {{maven-release-plugin:2.5:perform}} it does not include the actual tag
> name after "--branch" so the command fails.
> {noformat}
> git clone --branch g...@bithub.brightcove.com:abcde/fghij.git
> /home/buildacct/work/7483cd6cc5ce81ea/target/checkout
>[ERROR] The git-clone command failed.
> {noformat}
> We have to downgrade to the older maven-release-plugin, 2.3.2. From the
> ticket below this also worked in 2.2.1. I have not tried other versions.
> Found a description of this problem in SCM-729 in a comment in Feb 2015, but
> are creating this ticket because the issue is a recently introduced bug and
> that ticket is a feature request for a different component.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRELEASE-933) maven-release-plugin:perform from a tag is broken for Git in version 2.5.3
[
https://issues.apache.org/jira/browse/MRELEASE-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16591285#comment-16591285
]
Jesko Jochum commented on MRELEASE-933:
---
why is this still not fixed and why is the latest release almost 3 years old
(Oktober 2015)?
it seems like there is some quite recent activity in the project
[GitHub|https://github.com/apache/maven-release]/[Gitbox|https://gitbox.apache.org/repos/asf?p=maven-release.git]!?
> maven-release-plugin:perform from a tag is broken for Git in version 2.5.3
> --
>
> Key: MRELEASE-933
> URL: https://issues.apache.org/jira/browse/MRELEASE-933
> Project: Maven Release Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Eric Leventhal Arthen
>Priority: Major
>
> We are also blocked from using {{maven-release-plugin:2.5:perform}} for Git
> releases because it no longer passes in the tag name so the "git clone" fails.
> This worked correctly in {{maven-release-plugin:2.3.2:perform}}, with that
> version we got a command like this:
> {noformat}
> git clone --branch my-base-1.4.6 git@bithub:abcde/fghij.git
> /home/buildacct/work/5f89075470257ef1/base/target/checkout
> {noformat}
> (Note that the name here is (correctly) a tag name created by
> release:prepare, even though it is passed to --branch.)
> With {{maven-release-plugin:2.5:perform}} it does not include the actual tag
> name after "--branch" so the command fails.
> {noformat}
> git clone --branch g...@bithub.brightcove.com:abcde/fghij.git
> /home/buildacct/work/7483cd6cc5ce81ea/target/checkout
>[ERROR] The git-clone command failed.
> {noformat}
> We have to downgrade to the older maven-release-plugin, 2.3.2. From the
> ticket below this also worked in 2.2.1. I have not tried other versions.
> Found a description of this problem in SCM-729 in a comment in Feb 2015, but
> are creating this ticket because the issue is a recently introduced bug and
> that ticket is a feature request for a different component.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MNG-6175) Whitespace gets deleted in properties value text
[ https://issues.apache.org/jira/browse/MNG-6175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesko Jochum updated MNG-6175: -- Comment: was deleted (was: Sehr geehrte Damen und Herren, vielen Dank für Ihre Nachricht. Ich bin ab Mo 18.06.2018 wieder im Büro für Sie zu erreichen. Mit freundlichen Grüßen, Jesko Jochum ) > Whitespace gets deleted in properties value text > > > Key: MNG-6175 > URL: https://issues.apache.org/jira/browse/MNG-6175 > Project: Maven > Issue Type: Bug > Components: Plugin API >Affects Versions: 3.3.9 >Reporter: Jesko Jochum >Priority: Minor > > Leading and trailing whitespaces in the "pom.xml" get deleted. > Exemplary excerpt of a "pom.xml" file: > ... > > 1 > > ... > Checking the "effective pom" results in: > ... > > ... > 1 > ... > > ... > So the leading and trailing whitespaces have been deleted. [MNG-5380] states > this to be resolved since version 3.0.4. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6175) Regression from version 3.0.4: Whitespaces get deleted in "pom.xml".
[ https://issues.apache.org/jira/browse/MNG-6175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16515213#comment-16515213 ] Jesko Jochum commented on MNG-6175: --- Sehr geehrte Damen und Herren, vielen Dank für Ihre Nachricht. Ich bin ab Mo 18.06.2018 wieder im Büro für Sie zu erreichen. Mit freundlichen Grüßen, Jesko Jochum > Regression from version 3.0.4: Whitespaces get deleted in "pom.xml". > > > Key: MNG-6175 > URL: https://issues.apache.org/jira/browse/MNG-6175 > Project: Maven > Issue Type: Sub-task > Components: Plugin API >Affects Versions: 3.3.9 >Reporter: Jesko Jochum >Priority: Minor > Labels: regression > > Leading and trailing whitespaces in the "pom.xml" get deleted. > Exemplary excerpt of a "pom.xml" file: > ... > > 1 > > ... > Checking the "effective pom" results in: > ... > > ... > 1 > ... > > ... > So the leading and trailing whitespaces have been deleted. [MNG-5380] states > this to be resolved since version 3.0.4. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6175) Regression from version 3.0.4: Whitespaces get deleted in "pom.xml".
Jesko Jochum created MNG-6175: - Summary: Regression from version 3.0.4: Whitespaces get deleted in "pom.xml". Key: MNG-6175 URL: https://issues.apache.org/jira/browse/MNG-6175 Project: Maven Issue Type: Sub-task Components: Plugin API Affects Versions: 3.3.9 Reporter: Jesko Jochum Priority: Minor Fix For: 3.0.4 Leading and trailing whitespaces in the "pom.xml" get deleted. Exemplary excerpt of a "pom.xml" file: ... 1 ... Checking the "effective pom" results in: ... ... 1 ... ... So the leading and trailing whitespaces have been deleted. [MNG-5380] states this to be resolved since version 3.0.4. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
