[jira] [Updated] (MDEP-938) 'mdep.overIfNewer' is misnamed from its usage of 'mdep.overWriteIfNewer'

[Jeremy Landis (Jira)]

 [ 
https://issues.apache.org/jira/browse/MDEP-938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Landis updated MDEP-938:
---
Description: 
This is a follow up of older PR I raised to fix this 
[https://github.com/apache/maven-dependency-plugin/pull/285.]  After looking 
again and regrouping on this, made adjustments to deprecate the old property 
and creating jira.

 

This means added 'overIfNewer' that is immediately deprecated and goes unused.  
The use case is rare in how issue was exposed.  Looking at the code overall, 
its only messed up in this one unique way but correct everywhere else.  Added 
suggested time this shows up as 3.7.0.

  was:
This is a follow up of older PR I raised to fix this 
[https://github.com/apache/maven-dependency-plugin/pull/285.]  After looking 
again and regrouping on this, made adjustments to deprecate the old property 
and creating jira.  Using same PR for fix.

 

This means added 'overIfNewer' that is immediately deprecated and goes unused.  
The use case is rare in how issue was exposed.  Looking at the code overall, 
its only messed up in this one unique way but correct everywhere else.


> 'mdep.overIfNewer' is misnamed from its usage of 'mdep.overWriteIfNewer'
> 
>
> Key: MDEP-938
> URL: https://issues.apache.org/jira/browse/MDEP-938
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>Reporter: Jeremy Landis
>Priority: Minor
>
> This is a follow up of older PR I raised to fix this 
> [https://github.com/apache/maven-dependency-plugin/pull/285.]  After looking 
> again and regrouping on this, made adjustments to deprecate the old property 
> and creating jira.
>  
> This means added 'overIfNewer' that is immediately deprecated and goes 
> unused.  The use case is rare in how issue was exposed.  Looking at the code 
> overall, its only messed up in this one unique way but correct everywhere 
> else.  Added suggested time this shows up as 3.7.0.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (MDEP-938) 'mdep.overIfNewer' is misnamed from its usage of 'mdep.overWriteIfNewer'

[Jeremy Landis (Jira)]

 [ 
https://issues.apache.org/jira/browse/MDEP-938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Landis updated MDEP-938:
---
Description: 
This is a follow up of older PR I raised to fix this 
[https://github.com/apache/maven-dependency-plugin/pull/285.]  After looking 
again and regrouping on this, made adjustments to deprecate the old property so 
its in sync as requested and creating jira.  Using same PR for fix.

 

This means added 'overIfNewer' that is immediately deprecated and goes unused.  
The use case is rare in how issue was exposed.  Looking at the code overall, 
its only messed up in this one unique way but correct everywhere else.

  was:
This is a follow up of older PR I raised to fix this 
[https://github.com/apache/maven-dependency-plugin/pull/285.]  After looking 
again and regrouping on this, made adjustments to deprecate the old property so 
its in sync as requested and creating jira.  Using same PR for fix.

 

This means added 'overIfNewer' that is immediately deprecated with both 
getter/setter for same to account for making new property to hold the misnamed 
value to allow transition over.


> 'mdep.overIfNewer' is misnamed from its usage of 'mdep.overWriteIfNewer'
> 
>
> Key: MDEP-938
> URL: https://issues.apache.org/jira/browse/MDEP-938
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>Reporter: Jeremy Landis
>Priority: Minor
>
> This is a follow up of older PR I raised to fix this 
> [https://github.com/apache/maven-dependency-plugin/pull/285.]  After looking 
> again and regrouping on this, made adjustments to deprecate the old property 
> so its in sync as requested and creating jira.  Using same PR for fix.
>  
> This means added 'overIfNewer' that is immediately deprecated and goes 
> unused.  The use case is rare in how issue was exposed.  Looking at the code 
> overall, its only messed up in this one unique way but correct everywhere 
> else.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (MDEP-938) 'mdep.overIfNewer' is misnamed from its usage of 'mdep.overWriteIfNewer'

[Jeremy Landis (Jira)]

 [ 
https://issues.apache.org/jira/browse/MDEP-938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Landis updated MDEP-938:
---
Description: 
This is a follow up of older PR I raised to fix this 
[https://github.com/apache/maven-dependency-plugin/pull/285.]  After looking 
again and regrouping on this, made adjustments to deprecate the old property 
and creating jira.  Using same PR for fix.

 

This means added 'overIfNewer' that is immediately deprecated and goes unused.  
The use case is rare in how issue was exposed.  Looking at the code overall, 
its only messed up in this one unique way but correct everywhere else.

  was:
This is a follow up of older PR I raised to fix this 
[https://github.com/apache/maven-dependency-plugin/pull/285.]  After looking 
again and regrouping on this, made adjustments to deprecate the old property so 
its in sync as requested and creating jira.  Using same PR for fix.

 

This means added 'overIfNewer' that is immediately deprecated and goes unused.  
The use case is rare in how issue was exposed.  Looking at the code overall, 
its only messed up in this one unique way but correct everywhere else.


> 'mdep.overIfNewer' is misnamed from its usage of 'mdep.overWriteIfNewer'
> 
>
> Key: MDEP-938
> URL: https://issues.apache.org/jira/browse/MDEP-938
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>Reporter: Jeremy Landis
>Priority: Minor
>
> This is a follow up of older PR I raised to fix this 
> [https://github.com/apache/maven-dependency-plugin/pull/285.]  After looking 
> again and regrouping on this, made adjustments to deprecate the old property 
> and creating jira.  Using same PR for fix.
>  
> This means added 'overIfNewer' that is immediately deprecated and goes 
> unused.  The use case is rare in how issue was exposed.  Looking at the code 
> overall, its only messed up in this one unique way but correct everywhere 
> else.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (MDEP-938) 'mdep.overIfNewer' is misnamed from its usage of 'mdep.overWriteIfNewer'

[Jeremy Landis (Jira)]

Jeremy Landis created MDEP-938:
--

 Summary: 'mdep.overIfNewer' is misnamed from its usage of 
'mdep.overWriteIfNewer'
 Key: MDEP-938
 URL: https://issues.apache.org/jira/browse/MDEP-938
 Project: Maven Dependency Plugin
  Issue Type: Bug
Reporter: Jeremy Landis


This is a follow up of older PR I raised to fix this 
[https://github.com/apache/maven-dependency-plugin/pull/285.]  After looking 
again and regrouping on this, made adjustments to deprecate the old property so 
its in sync as requested and creating jira.  Using same PR for fix.

 

This means added 'overIfNewer' that is immediately deprecated with both 
getter/setter for same to account for making new property to hold the misnamed 
value to allow transition over.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MSITE-1002) Maven Site 4 will break code highlight of site generated by Markdown

[Jeremy Landis (Jira)]

[ 
https://issues.apache.org/jira/browse/MSITE-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825075#comment-17825075
 ] 

Jeremy Landis commented on MSITE-1002:
--

Sounds like highlight.js is a good replacement.  See 
https://github.com/highlightjs/highlight.js/

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


> Maven Site 4 will break code highlight of site generated by Markdown
> 
>
> Key: MSITE-1002
> URL: https://issues.apache.org/jira/browse/MSITE-1002
> Project: Maven Site Plugin
>  Issue Type: Bug
>  Components: doxia integration
>Affects Versions: 4.0.0-M13
>Reporter: Xavi Lee
>Assignee: Konrad Windszus
>Priority: Major
> Attachments: maven-site-3.png, maven-site-4.png, test-v3.html, 
> test-v4.html
>
>
> repro repo https://github.com/awxiaoxian2020/code-render-bug
> master branch is Maven Site 3 with Fluido skin 1
> v4 branch is Maven Site 4 with Fluido skin 2.
> Open their respective `target/site/test.html` files in local to see the 
> rendered result.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MSITE-1002) Maven Site 4 will break code highlight of site generated by Markdown

[Jeremy Landis (Jira)]

[ 
https://issues.apache.org/jira/browse/MSITE-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17813992#comment-17813992
 ] 

Jeremy Landis commented on MSITE-1002:
--

Also see [https://github.com/mybatis/parent/issues/600.]  A work around was 
found that fixes it which may help resolve the issue.  Seems this issue 
happened a number of years ago so possibly some renaming of stuff but haven't 
found exactly where yet inside doxia.

> Maven Site 4 will break code highlight of site generated by Markdown
> 
>
> Key: MSITE-1002
> URL: https://issues.apache.org/jira/browse/MSITE-1002
> Project: Maven Site Plugin
>  Issue Type: Bug
>  Components: doxia integration
>Affects Versions: 4.0.0-M13
>Reporter: Xavi Lee
>Priority: Major
> Attachments: maven-site-3.png, maven-site-4.png
>
>
> repro repo https://github.com/awxiaoxian2020/code-render-bug
> master branch is Maven Site 3 with Fluido skin 1
> v4 branch is Maven Site 4 with Fluido skin 2.
> Open their respective `target/site/test.html` files in local to see the 
> rendered result.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MSITE-948) Site stage/deploy should respect 'child.site.url.inherit.append.path="false"' and not use relativePath related to that parent

[Jeremy Landis (Jira)]

[ 
https://issues.apache.org/jira/browse/MSITE-948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17712060#comment-17712060
 ] 

Jeremy Landis edited comment on MSITE-948 at 12/8/23 3:50 AM:
--

Discovered a work around which was not very clear and maybe right answer is to 
just make this more clear in FAQ.  While site isn't coded to handle the child 
inherit flags directly and fact that it doesn't make much sense when configured 
using git as site location, there was a work around hidden in plain site.  
Think other tickets will need to get linked in here as many relate to same 
issue and could help others resolve.  I can look into finding all of them and 
linking.

While debugging and knowing this calculation comes about in 
'getTopLevelProject(MavenProject)' or 'getDeployModuleDirectory' and while 
looking at the site pages documentation, realized the following...

 
|{{[|https://maven.apache.org/plugins/maven-site-plugin/stage-mojo.html#topSiteURL]}}|{{String}}|{{3.3}}|Top
 distribution management site url, for manual configuration when 
auto-calculated value doesn't match expectations. Relative module directory 
will be calculated from this url.
{*}User property is{*}: {{{}topSiteURL{}}}.|

 

To me and probably others that is not very clear at all.  Especially when what 
happens seems like a bug and at least some sort of flag to disable such as the 
long provided child url inherit flags.  The naming doesn't exactly scream out 
site url directly and is unnecessary long winded way of a boolean.  At any 
rate, setting that to 
'${project.distributionManagement.site.url}' in 
addition to the inherit child set to false in the parent ensures it can work 
as-is.  I do want to confirm if the inherit child even needs set but presume it 
must as it could just set top site oddly otherwise but at the moment, I was 
able to clear the ../repo.git related occurrence locally and scm publish worked 
correctly.  I'm pretty sure that further fixes site plugin usage directly 
without need for scm publish.  For multi module it further needs inherit set 
back to true in downstream projects so the site can get all staging.  Staging 
at least in context of running needs to pull it all together so this 
complicates the release plugin a bit in that I believe need goals to run as: 
deploy site site:stage site:deploy.  A 'site-stage' would be nice to clean that 
up a bit when scm publish is being used along with maybe a flag for that 
instead of defining .

I want to do a bit more testing in automated fashion to make sure things work 
out with release plugin involved.  I'll still look to getting a small 
reproducible together as I kind of feel like some improvements can be made to 
this.  Knowing how difficult this has been, seeing many tickets through the 
years on similar related issues, knowing others in OSS have same struggles with 
site, etc.  But bottom line for now, think there was enough here to fully 
figure this out.  I may end up using 'mybatis' to actually demo this entire 
thing out more publicly as we are using a very old plugin to pull off site and 
not maven directly due to issues over the years but that uses jsch and is 
starting to show issues on mac.  And its in probably best position to show this 
overall.

As long as I can continue to add links to help others out here and continue 
posting as needed, feel free to just close out the ticket as it stands.  Part 
of me opening this was clearly what was needed to at least cause me to figure 
it out.  Sorry to be a bother here and hoping this at a minimum helps others 
out with site usage.


was (Author: hazendaz):
Discovered a work around which was not very clear and maybe right answer is to 
just make this more clear in FAQ.  While site isn't coded to handle the child 
inherit flags directly and fact that it doesn't make much sense when configured 
using git as site location, there was a work around hidden in plain site.  
Think other tickets will need to get linked in here as many relate to same 
issue and could help others resolve.  I can look into finding all of them and 
linking.

While debugging and knowing this calculation comes about in 
'getTopLevelProject(MavenProject)' or 'getDeployModuleDirectory' and while 
looking at the site pages documentation, realized the following...

 
|{{[|https://maven.apache.org/plugins/maven-site-plugin/stage-mojo.html#topSiteURL]}}|{{String}}|{{3.3}}|Top
 distribution management site url, for manual configuration when 
auto-calculated value doesn't match expectations. Relative module directory 
will be calculated from this url.
{*}User property is{*}: {{{}topSiteURL{}}}.|

 

To me and probably others that is not very clear at all.  Especially when what 
happens seems like a bug and at least some sort of flag to disable such as the 
long provided child url inherit flags.  The naming doesn't exactly scream out 
site u

[jira] [Commented] (MSITE-988) Documentation

[Jeremy Landis (Jira)]

[ 
https://issues.apache.org/jira/browse/MSITE-988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17794499#comment-17794499
 ] 

Jeremy Landis commented on MSITE-988:
-

[~michael-o] I believe you mean the converter during the build converts it and 
issues the warning, correct?  What I'm asking is if the tool can output the 
updates without having to manually do it by hand so the warning is cleared and 
its properly up to date.

> Documentation
> -
>
> Key: MSITE-988
> URL: https://issues.apache.org/jira/browse/MSITE-988
> Project: Maven Site Plugin
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 4.0.0-M9
>Reporter: Ernst Reissner
>Assignee: Michael Osipov
>Priority: Major
>
> Create old pre-version 2.0.0 model. 
> If using newer versions, 4.0.0-M9 to the current M11, 
> then an error occurs: 
> ```
> Site model of 
> 'eu.simuline.m2latex:latex-maven-plugin:maven-plugin:2.0-SNAPSHOT' 
> for locale 'en' is still using the old pre-version 2.0.0 model. 
> You MUST migrate to the new model as soon as possible 
> otherwise your build will break in the future!
> ```
> This is due to an old form of `site.xml` 
> The first problem is the documentation, 
> `https://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html`
>  
> which describes the old form and refers to the new one only in a link. 
> What would be needed is a clear statement on the mapping of the version to 
> the form. 
> Also the new form is not completely supported: 
> ```
>xmlns="http://maven.apache.org/SITE/2.0.0";
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>   xsi:schemaLocation="http://maven.apache.org/SITE/2.0.0 
> https://maven.apache.org/xsd/site-2.0.0.xsd";> 
> ...
> 
> ```
> well, the link `https://maven.apache.org/xsd/site-2.0.0.xsd` does not exist, 
> resulting in a warning in my IDE. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MSITE-988) Documentation

[Jeremy Landis (Jira)]

[ 
https://issues.apache.org/jira/browse/MSITE-988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787694#comment-17787694
 ] 

Jeremy Landis commented on MSITE-988:
-

The xsd  `[https://maven.apache.org/xsd/site-2.0.0.xsd]` now exists.  Just 
tried it myself on 4.0.0.M11 and it worked out.  What IMO is not clear is that 
most of the site needs switched around to attributes.  Is there a tool to do 
this automatically?

> Documentation
> -
>
> Key: MSITE-988
> URL: https://issues.apache.org/jira/browse/MSITE-988
> Project: Maven Site Plugin
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 4.0.0-M9
>Reporter: Ernst Reissner
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.0-M12
>
>
> Create old pre-version 2.0.0 model. 
> If using newer versions, 4.0.0-M9 to the current M11, 
> then an error occurs: 
> ```
> Site model of 
> 'eu.simuline.m2latex:latex-maven-plugin:maven-plugin:2.0-SNAPSHOT' 
> for locale 'en' is still using the old pre-version 2.0.0 model. 
> You MUST migrate to the new model as soon as possible 
> otherwise your build will break in the future!
> ```
> This is due to an old form of `site.xml` 
> The first problem is the documentation, 
> `https://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html`
>  
> which describes the old form and refers to the new one only in a link. 
> What would be needed is a clear statement on the mapping of the version to 
> the form. 
> Also the new form is not completely supported: 
> ```
>xmlns="http://maven.apache.org/SITE/2.0.0";
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>   xsi:schemaLocation="http://maven.apache.org/SITE/2.0.0 
> https://maven.apache.org/xsd/site-2.0.0.xsd";> 
> ...
> 
> ```
> well, the link `https://maven.apache.org/xsd/site-2.0.0.xsd` does not exist, 
> resulting in a warning in my IDE. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MSITE-948) Site stage/deploy should respect 'child.site.url.inherit.append.path="false"' and not use relativePath related to that parent

[Jeremy Landis (Jira)]

[ 
https://issues.apache.org/jira/browse/MSITE-948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17712060#comment-17712060
 ] 

Jeremy Landis commented on MSITE-948:
-

Discovered a work around which was not very clear and maybe right answer is to 
just make this more clear in FAQ.  While site isn't coded to handle the child 
inherit flags directly and fact that it doesn't make much sense when configured 
using git as site location, there was a work around hidden in plain site.  
Think other tickets will need to get linked in here as many relate to same 
issue and could help others resolve.  I can look into finding all of them and 
linking.

While debugging and knowing this calculation comes about in 
'getTopLevelProject(MavenProject)' or 'getDeployModuleDirectory' and while 
looking at the site pages documentation, realized the following...

 
|{{[|https://maven.apache.org/plugins/maven-site-plugin/stage-mojo.html#topSiteURL]}}|{{String}}|{{3.3}}|Top
 distribution management site url, for manual configuration when 
auto-calculated value doesn't match expectations. Relative module directory 
will be calculated from this url.
{*}User property is{*}: {{{}topSiteURL{}}}.|

 

To me and probably others that is not very clear at all.  Especially when what 
happens seems like a bug and at least some sort of flag to disable such as the 
long provided child url inherit flags.  The naming doesn't exactly scream out 
site url directly and is unnecessary long winded way of a boolean.  At any 
rate, setting that to 
'${project.distributionManagement.site.url}' in 
addition to the inherit child set to false in the parent ensures it can work 
as-is.  I do want to confirm if the inherit child even needs set but presume it 
must as it could just set top site oddly otherwise but at the moment, I was 
able to clear the ../repo.git related occurrence locally and scm publish worked 
correctly.  I'm pretty sure that further fixes site plugin usage directly 
without need for scm publish.  For multi module it further needs inherit set 
back to true in downstream projects so the site can get all staging.  Staging 
at least in context of running needs to pull it all together so this 
complicates the release plugin a bit in that I believe need goals to run as: 
deploy site site:stage site:deploy.  A 'site-stage' would be nice to clean that 
up a bit when scm publish is being used along with maybe a flag for that 
instead of defining .

I want to do a bit more testing in automated fashion to make sure things work 
out with release plugin involved.  I'll still look to getting a small 
reproducible together as I kind of feel like some improvements can be made to 
this.  Knowing how difficult this has been, seeing many tickets through the 
years on similar related issues, knowing others in OSS have same struggles with 
site, etc.  But bottom line for now, think there was enough here to fully 
figure this out.  I may end up using 'mybatis' to actually demo this entire 
thing out more publicly as we are using a very old plugin to pull off site and 
not maven directly due to issues over the years but that uses jsch and is 
starting to show issues on mac.  And its in probably best position to show this 
overall.

As long as I can continue to add links to help others out here and continue 
posting as needed, feel free to just close out the ticket as it stands.  Part 
of me opening this was clearly what was needed to at least cause me to figure 
it out.  Sorry to be a bother here and hoping this at a minimum helps others 
out with site usage.

> Site stage/deploy should respect 'child.site.url.inherit.append.path="false"' 
> and not use relativePath related to that parent
> -
>
> Key: MSITE-948
> URL: https://issues.apache.org/jira/browse/MSITE-948
> Project: Maven Site Plugin
>  Issue Type: Bug
>  Components: site:stage(-deploy)
>Affects Versions: 3.12.1, 4.0.0-M7
>Reporter: Jeremy Landis
>Priority: Major
>
> All versions of maven have long been affected by this and there are many 
> tickets opened / closed claiming to have resolved or seem to be outstanding 
> for years with no resolution.  I believe they are mostly related.
> The 'child.site.url.inherit.append.path="false"' was added back in maven 
> 3.6.0 with claim to stop this behaviour but its never worked outside of 
> effective pom looks right IMO.  At least most platforms support that now 
> (artifactory was late in that game).
> Currently regardless of that setting, the maven site plugin doesn't respect 
> it or even look at it from what I can tell.  Its there in the debug tree but 
> the code doesn't appear to look at that to determine what it will do with 
> relativePath.
> So, if I have p

[jira] [Commented] (MSITE-948) Site stage/deploy should respect 'child.site.url.inherit.append.path="false"' and not use relativePath related to that parent

[Jeremy Landis (Jira)]

[ 
https://issues.apache.org/jira/browse/MSITE-948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17711302#comment-17711302
 ] 

Jeremy Landis commented on MSITE-948:
-

Testing is using 4.0.0-M7 site plugin with fluido 2.0.0-M5 along with scm 
publish 3.2.1.  Combination doesn't much matter, its been a problem for a very 
long time.  Short problem is simply that it keeps trying to stage artifacts out 
of the 'target/staging' folder one directory up.  Reason is simple, its 
miscalculates parent that should not be used for such purposes as both hosted 
on same site (using github or bitbucket, doesn't matter what git tooling) and 
since host matches except for project key it determines to go up one directly 
which results in the issues faced.  Easiest possible fix IMO would be to simply 
prevent it from jumping out of the 'target/staging' folder like that.  The 
folder it ends up using is named after the git repo such as 'target/repo.git'.  
Possible a simple check could resolve that.  Will be continuing debugging to 
see what adjustments can be made to find a possible easy solution.

> Site stage/deploy should respect 'child.site.url.inherit.append.path="false"' 
> and not use relativePath related to that parent
> -
>
> Key: MSITE-948
> URL: https://issues.apache.org/jira/browse/MSITE-948
> Project: Maven Site Plugin
>  Issue Type: Bug
>  Components: site:stage(-deploy)
>Affects Versions: 3.12.1, 4.0.0-M7
>Reporter: Jeremy Landis
>Priority: Major
>
> All versions of maven have long been affected by this and there are many 
> tickets opened / closed claiming to have resolved or seem to be outstanding 
> for years with no resolution.  I believe they are mostly related.
> The 'child.site.url.inherit.append.path="false"' was added back in maven 
> 3.6.0 with claim to stop this behaviour but its never worked outside of 
> effective pom looks right IMO.  At least most platforms support that now 
> (artifactory was late in that game).
> Currently regardless of that setting, the maven site plugin doesn't respect 
> it or even look at it from what I can tell.  Its there in the debug tree but 
> the code doesn't appear to look at that to determine what it will do with 
> relativePath.
> So, if I have project example [https://github.com/hazendaz/base-parent] and I 
> happen to have those set (such as 
> [https://github.com/hazendaz/base-parent/commit/58e9f8a7749a80e74e8197d5b90b17458cadb161]),
>  then anything downstream using that parent which is unrelated I would expect 
> to adhere to the request and not attempt to use the super pom for its 
> calculations at all.  But it does not do so.
> I suspect areas of code problematic are getTopLevelProject(MavenProject) or 
> 'getDeployModuleDirectory'.  The later being where it matters with 
> 'relativePath' determined.
> The main issue is with multi module downstream projects.  Fixing this issue I 
> suspect would have immediate impact on being able to use the site plugin 
> directly and not need scm publish.  Scm publish tends to work for single 
> module but it still suffers from fact that the site plugin messes up the data 
> before it ever gets there.
> For example, if my project is 'somerepo.git', I would expect site:stage to 
> put the data in 'target/staging' as the documentation states it will do so.  
> It however does not, regardless of the above noted setting.  What it does 
> instead is determine that it needs the relative path to be '../somerepo.git' 
> just because it has a parent pom from some other project from same hosted 
> platform (gh-pages on github).  So the staging then puts that in 
> 'target/somerepo.git' instead.  So maven scm publish cannot even see that.  
> The site deploy fails to do it correctly as it completely changes out the 
> repo to deploy to and tries to go to the parent which in most cases like this 
> isn't related at all.  My base super pom for example is used by quite a 
> number of repos and they all have issues with site distributions as a result.
> So how can we make the site plugin actually respect 
> 'child.site.url.inherit.append.path="false"'?  Or any way to actually make 
> that easier like configure it to just stop doing that logic as unnecessary.  
> The pom settings IMO are over bearing as it is so a config option would be 
> far better and easier to implement.
> I've debugged this far enough to just keep changing the site plugins 
> determination on the relativePath to be './' which fixes the issue.  Note: 
> The rest of relative path for multi module is needed but starting part was 
> wrong '../' vs './'.
> IMO I don't think maven should even be touching items like this, its so hard 
> to understand the math as a result.  Thus wh

[jira] [Commented] (MNG-7760) Site stage/deploy should respect 'child.site.url.inherit.append.path="false"' and not use relativePath related to that parent

[Jeremy Landis (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17711299#comment-17711299
 ] 

Jeremy Landis commented on MNG-7760:


Actually can you close this as not seeing option to do so, opened same here 
[https://issues.apache.org/jira/projects/MSITE/issues/MSITE-948?filter=allopenissues.]
  I updated only one thing as would be confusing on relative path on what I was 
fixing during debug but same otherwise.  Will also get a reproducible sample by 
end of the weekend over there.  Sorry to open in wrong spot was jumping back 
and forth trying to find original add of the inherit variables.

> Site stage/deploy should respect 'child.site.url.inherit.append.path="false"' 
> and not use relativePath related to that parent
> -
>
> Key: MNG-7760
> URL: https://issues.apache.org/jira/browse/MNG-7760
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.9.1
>Reporter: Jeremy Landis
>Priority: Major
>
> All versions of maven have long been affected by this and there are many 
> tickets opened / closed claiming to have resolved or seem to be outstanding 
> for years with no resolution.  I believe they are mostly related.
> The 'child.site.url.inherit.append.path="false"' was added back in maven 
> 3.6.0 with claim to stop this behaviour but its never worked outside of 
> effective pom looks right IMO.  At least most platforms support that now 
> (artifactory was late in that game).
> Currently regardless of that setting, the maven site plugin doesn't respect 
> it or even look at it from what I can tell.  Its there in the debug tree but 
> the code doesn't appear to look at that to determine what it will do with 
> relativePath.
> So, if I have project example [https://github.com/hazendaz/base-parent] and I 
> happen to have those set (such as 
> https://github.com/hazendaz/base-parent/commit/58e9f8a7749a80e74e8197d5b90b17458cadb161),
>  then anything downstream using that parent which is unrelated I would expect 
> to adhere to the request and not attempt to use the super pom for its 
> calculations at all.  But it does not do so.
> I suspect areas of code problematic are getTopLevelProject(MavenProject) or 
> 'getDeployModuleDirectory'.  The later being where it matters with 
> 'relativePath' determined.
> The main issue is with multi module downstream projects.  Fixing this issue I 
> suspect would have immediate impact on being able to use the site plugin 
> directly and not need scm publish.  Scm publish tends to work for single 
> module but it still suffers from fact that the site plugin messes up the data 
> before it ever gets there.
> For example, if my project is 'somerepo.git', I would expect site:stage to 
> put the data in 'target/staging' as the documentation states it will do so.  
> It however does not, regardless of the above noted setting.  What it does 
> instead is determine that it needs the relative path to be '../somerepo.git' 
> just because it has a parent pom from some other project from same hosted 
> platform (gh-pages on github).  So the staging then puts that in 
> 'target/somerepo.git' instead.  So maven scm publish cannot even see that.  
> The site deploy fails to do it correctly as it completely changes out the 
> repo to deploy to and tries to go to the parent which in most cases like this 
> isn't related at all.  My base super pom for example is used by quite a 
> number of repos and they all have issues with site distributions as a result.
> So how can we make the site plugin actually respect 
> 'child.site.url.inherit.append.path="false"'?  Or any way to actually make 
> that easier like configure it to just stop doing that logic as unnecessary.  
> The pom settings IMO are over bearing as it is so a config option would be 
> far better and easier to implement.
> I've debugged this far enough to just keep changing the site plugins 
> determination on the relativePath to be './' which fixes the issue.
> IMO I don't think maven should even be touching items like this, its so hard 
> to understand the math as a result.  Thus why so many tickets get opened for 
> same thing in various different ways.  Over the years we have tried just 
> about everything to make this work and honestly the only thing that really 
> does currently is to drop maven from doing the site distribution entirely and 
> use gh-actions to do the same or other solutions on different platforms.  It 
> would be better IMO to use maven site plugin directly and/or with scm publish 
> if it consistently worked as documented.  Maybe a flag isn't even need, maybe 
> just fixing maven site plugin to stop going outside of the staging folder 
> would be a good step 1 as scm publish should be ok th

[jira] [Created] (MSITE-948) Site stage/deploy should respect 'child.site.url.inherit.append.path="false"' and not use relativePath related to that parent

[Jeremy Landis (Jira)]

Jeremy Landis created MSITE-948:
---

 Summary: Site stage/deploy should respect 
'child.site.url.inherit.append.path="false"' and not use relativePath related 
to that parent
 Key: MSITE-948
 URL: https://issues.apache.org/jira/browse/MSITE-948
 Project: Maven Site Plugin
  Issue Type: Bug
  Components: site:stage(-deploy)
Affects Versions: 4.0.0-M7, 3.12.1
Reporter: Jeremy Landis


All versions of maven have long been affected by this and there are many 
tickets opened / closed claiming to have resolved or seem to be outstanding for 
years with no resolution.  I believe they are mostly related.

The 'child.site.url.inherit.append.path="false"' was added back in maven 3.6.0 
with claim to stop this behaviour but its never worked outside of effective pom 
looks right IMO.  At least most platforms support that now (artifactory was 
late in that game).

Currently regardless of that setting, the maven site plugin doesn't respect it 
or even look at it from what I can tell.  Its there in the debug tree but the 
code doesn't appear to look at that to determine what it will do with 
relativePath.

So, if I have project example [https://github.com/hazendaz/base-parent] and I 
happen to have those set (such as 
[https://github.com/hazendaz/base-parent/commit/58e9f8a7749a80e74e8197d5b90b17458cadb161]),
 then anything downstream using that parent which is unrelated I would expect 
to adhere to the request and not attempt to use the super pom for its 
calculations at all.  But it does not do so.

I suspect areas of code problematic are getTopLevelProject(MavenProject) or 
'getDeployModuleDirectory'.  The later being where it matters with 
'relativePath' determined.

The main issue is with multi module downstream projects.  Fixing this issue I 
suspect would have immediate impact on being able to use the site plugin 
directly and not need scm publish.  Scm publish tends to work for single module 
but it still suffers from fact that the site plugin messes up the data before 
it ever gets there.

For example, if my project is 'somerepo.git', I would expect site:stage to put 
the data in 'target/staging' as the documentation states it will do so.  It 
however does not, regardless of the above noted setting.  What it does instead 
is determine that it needs the relative path to be '../somerepo.git' just 
because it has a parent pom from some other project from same hosted platform 
(gh-pages on github).  So the staging then puts that in 'target/somerepo.git' 
instead.  So maven scm publish cannot even see that.  The site deploy fails to 
do it correctly as it completely changes out the repo to deploy to and tries to 
go to the parent which in most cases like this isn't related at all.  My base 
super pom for example is used by quite a number of repos and they all have 
issues with site distributions as a result.

So how can we make the site plugin actually respect 
'child.site.url.inherit.append.path="false"'?  Or any way to actually make that 
easier like configure it to just stop doing that logic as unnecessary.  The pom 
settings IMO are over bearing as it is so a config option would be far better 
and easier to implement.

I've debugged this far enough to just keep changing the site plugins 
determination on the relativePath to be './' which fixes the issue.  Note: The 
rest of relative path for multi module is needed but starting part was wrong 
'../' vs './'.

IMO I don't think maven should even be touching items like this, its so hard to 
understand the math as a result.  Thus why so many tickets get opened for same 
thing in various different ways.  Over the years we have tried just about 
everything to make this work and honestly the only thing that really does 
currently is to drop maven from doing the site distribution entirely and use 
gh-actions to do the same or other solutions on different platforms.  It would 
be better IMO to use maven site plugin directly and/or with scm publish if it 
consistently worked as documented.  Maybe a flag isn't even need, maybe just 
fixing maven site plugin to stop going outside of the staging folder would be a 
good step 1 as scm publish should be ok then.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MNG-7760) Site stage/deploy should respect 'child.site.url.inherit.append.path="false"' and not use relativePath related to that parent

[Jeremy Landis (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17711298#comment-17711298
 ] 

Jeremy Landis commented on MNG-7760:


closing will reopen, meant to be against site plugin.

> Site stage/deploy should respect 'child.site.url.inherit.append.path="false"' 
> and not use relativePath related to that parent
> -
>
> Key: MNG-7760
> URL: https://issues.apache.org/jira/browse/MNG-7760
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.9.1
>Reporter: Jeremy Landis
>Priority: Major
>
> All versions of maven have long been affected by this and there are many 
> tickets opened / closed claiming to have resolved or seem to be outstanding 
> for years with no resolution.  I believe they are mostly related.
> The 'child.site.url.inherit.append.path="false"' was added back in maven 
> 3.6.0 with claim to stop this behaviour but its never worked outside of 
> effective pom looks right IMO.  At least most platforms support that now 
> (artifactory was late in that game).
> Currently regardless of that setting, the maven site plugin doesn't respect 
> it or even look at it from what I can tell.  Its there in the debug tree but 
> the code doesn't appear to look at that to determine what it will do with 
> relativePath.
> So, if I have project example [https://github.com/hazendaz/base-parent] and I 
> happen to have those set (such as 
> https://github.com/hazendaz/base-parent/commit/58e9f8a7749a80e74e8197d5b90b17458cadb161),
>  then anything downstream using that parent which is unrelated I would expect 
> to adhere to the request and not attempt to use the super pom for its 
> calculations at all.  But it does not do so.
> I suspect areas of code problematic are getTopLevelProject(MavenProject) or 
> 'getDeployModuleDirectory'.  The later being where it matters with 
> 'relativePath' determined.
> The main issue is with multi module downstream projects.  Fixing this issue I 
> suspect would have immediate impact on being able to use the site plugin 
> directly and not need scm publish.  Scm publish tends to work for single 
> module but it still suffers from fact that the site plugin messes up the data 
> before it ever gets there.
> For example, if my project is 'somerepo.git', I would expect site:stage to 
> put the data in 'target/staging' as the documentation states it will do so.  
> It however does not, regardless of the above noted setting.  What it does 
> instead is determine that it needs the relative path to be '../somerepo.git' 
> just because it has a parent pom from some other project from same hosted 
> platform (gh-pages on github).  So the staging then puts that in 
> 'target/somerepo.git' instead.  So maven scm publish cannot even see that.  
> The site deploy fails to do it correctly as it completely changes out the 
> repo to deploy to and tries to go to the parent which in most cases like this 
> isn't related at all.  My base super pom for example is used by quite a 
> number of repos and they all have issues with site distributions as a result.
> So how can we make the site plugin actually respect 
> 'child.site.url.inherit.append.path="false"'?  Or any way to actually make 
> that easier like configure it to just stop doing that logic as unnecessary.  
> The pom settings IMO are over bearing as it is so a config option would be 
> far better and easier to implement.
> I've debugged this far enough to just keep changing the site plugins 
> determination on the relativePath to be './' which fixes the issue.
> IMO I don't think maven should even be touching items like this, its so hard 
> to understand the math as a result.  Thus why so many tickets get opened for 
> same thing in various different ways.  Over the years we have tried just 
> about everything to make this work and honestly the only thing that really 
> does currently is to drop maven from doing the site distribution entirely and 
> use gh-actions to do the same or other solutions on different platforms.  It 
> would be better IMO to use maven site plugin directly and/or with scm publish 
> if it consistently worked as documented.  Maybe a flag isn't even need, maybe 
> just fixing maven site plugin to stop going outside of the staging folder 
> would be a good step 1 as scm publish should be ok then.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (MNG-7760) Site stage/deploy should respect 'child.site.url.inherit.append.path="false"' and not use relativePath related to that parent

[Jeremy Landis (Jira)]

Jeremy Landis created MNG-7760:
--

 Summary: Site stage/deploy should respect 
'child.site.url.inherit.append.path="false"' and not use relativePath related 
to that parent
 Key: MNG-7760
 URL: https://issues.apache.org/jira/browse/MNG-7760
 Project: Maven
  Issue Type: Bug
Affects Versions: 3.9.1
Reporter: Jeremy Landis


All versions of maven have long been affected by this and there are many 
tickets opened / closed claiming to have resolved or seem to be outstanding for 
years with no resolution.  I believe they are mostly related.

The 'child.site.url.inherit.append.path="false"' was added back in maven 3.6.0 
with claim to stop this behaviour but its never worked outside of effective pom 
looks right IMO.  At least most platforms support that now (artifactory was 
late in that game).

Currently regardless of that setting, the maven site plugin doesn't respect it 
or even look at it from what I can tell.  Its there in the debug tree but the 
code doesn't appear to look at that to determine what it will do with 
relativePath.

So, if I have project example [https://github.com/hazendaz/base-parent] and I 
happen to have those set (such as 
https://github.com/hazendaz/base-parent/commit/58e9f8a7749a80e74e8197d5b90b17458cadb161),
 then anything downstream using that parent which is unrelated I would expect 
to adhere to the request and not attempt to use the super pom for its 
calculations at all.  But it does not do so.

I suspect areas of code problematic are getTopLevelProject(MavenProject) or 
'getDeployModuleDirectory'.  The later being where it matters with 
'relativePath' determined.

The main issue is with multi module downstream projects.  Fixing this issue I 
suspect would have immediate impact on being able to use the site plugin 
directly and not need scm publish.  Scm publish tends to work for single module 
but it still suffers from fact that the site plugin messes up the data before 
it ever gets there.

For example, if my project is 'somerepo.git', I would expect site:stage to put 
the data in 'target/staging' as the documentation states it will do so.  It 
however does not, regardless of the above noted setting.  What it does instead 
is determine that it needs the relative path to be '../somerepo.git' just 
because it has a parent pom from some other project from same hosted platform 
(gh-pages on github).  So the staging then puts that in 'target/somerepo.git' 
instead.  So maven scm publish cannot even see that.  The site deploy fails to 
do it correctly as it completely changes out the repo to deploy to and tries to 
go to the parent which in most cases like this isn't related at all.  My base 
super pom for example is used by quite a number of repos and they all have 
issues with site distributions as a result.

So how can we make the site plugin actually respect 
'child.site.url.inherit.append.path="false"'?  Or any way to actually make that 
easier like configure it to just stop doing that logic as unnecessary.  The pom 
settings IMO are over bearing as it is so a config option would be far better 
and easier to implement.

I've debugged this far enough to just keep changing the site plugins 
determination on the relativePath to be './' which fixes the issue.

IMO I don't think maven should even be touching items like this, its so hard to 
understand the math as a result.  Thus why so many tickets get opened for same 
thing in various different ways.  Over the years we have tried just about 
everything to make this work and honestly the only thing that really does 
currently is to drop maven from doing the site distribution entirely and use 
gh-actions to do the same or other solutions on different platforms.  It would 
be better IMO to use maven site plugin directly and/or with scm publish if it 
consistently worked as documented.  Maybe a flag isn't even need, maybe just 
fixing maven site plugin to stop going outside of the staging folder would be a 
good step 1 as scm publish should be ok then.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MSITE-922) Using 4.0.0-M4 w/ maven-fluido-skin breaks table formatting in generated pages

[Jeremy Landis (Jira)]

[ 
https://issues.apache.org/jira/browse/MSITE-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17678048#comment-17678048
 ] 

Jeremy Landis commented on MSITE-922:
-

Hi [~davewichers],

Sent you a PR to fix inheritance for fluido version per your comments in the 
pom/site -> https://github.com/nahsra/antisamy/pull/289

I further tested just the change to site 4.0.0-M3 vs 4.0.0-M4 to see the 
difference.  I applied Changes [~michael-o] noted here and ran on a snapshot 
with 4.0.0-M4 of antisamy site.  The report was restored by doing so.  The PR 
on that is building currently at 
[https://github.com/spotbugs/spotbugs-maven-plugin/pull/532] and will be merged 
shortly.

On release of spotbugs next maven release, doing some work on spotbugs I hope 
to pick up before doing thus it may be a little while before a release is 
pushed. 

> Using 4.0.0-M4 w/ maven-fluido-skin breaks table formatting in generated 
> pages 
> ---
>
> Key: MSITE-922
> URL: https://issues.apache.org/jira/browse/MSITE-922
> Project: Maven Site Plugin
>  Issue Type: Bug
>Affects Versions: 4.0.0-M4
>Reporter: Dave Wichers
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> If, after you set the maven-site-plugin version to 4.0.0-M4 in the AntiSamy 
> ([https://github.com/nahsra/antisamy]) pom.xml, you run: 'mvn site' against 
> the main branch of this project: 
> It generates the site docs just fine, but the tables are broken in many of 
> the pages, which are rendered fine with the 4.0.0-M3 version of the 
> maven-site-plugin.
> I did the following diff of 1 broken vs. OK generated site page file and 
> here's what it shows:
> antisamy % diff target/site/spotbugs.html ../targetBroken/site/spotbugs.html
> 5c5
> {quote}<  | Generated by Apache Maven Doxia Site Renderer 1.11.1 from 
> com.github.spotbugs:spotbugs-maven-plugin:4.7.3.0:spotbugs at 2023-01-16
> ---
> >  | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from 
> >com.github.spotbugs:spotbugs-maven-plugin:4.7.3.0:spotbugs at 2023-01-16
> 8c8
> < http://www.w3.org/1999/xhtml"; lang="en">
> ---
> > http://www.w3.org/1999/xhtml"; lang="">
> 12c12
> <     
> ---
> >     
> 70c70
> < SpotBugs Bug Detector 
> Report
> ---
> > SpotBugs Bug Detector Report
> 75,76c75
> < Summary
> < 
> ---
> > Summary
> 87,88c86
> < Files
> < 
> ---
> > Files
> 97,99c95,96
> < 1 name="org.owasp.validator.css.CssHandler">
> <  name="org.owasp.validator.css.CssHandler">org.owasp.validator.css.CssHandler
> < 
> ---
> > 1 > id="org.owasp.validator.css.CssHandler">
> > org.owasp.validator.css.CssHandler
> 123,125c120,121
> < Medium name="org.owasp.validator.css.CssScanner">
> <  name="org.owasp.validator.css.CssScanner">org.owasp.validator.css.CssScanner
> < 
> ---
> > Medium > id="org.owasp.validator.css.CssScanner">
> > org.owasp.validator.css.CssScanner
> {quote}
> Given that it works with 4.0.0-M3 this seems like a bug.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (MWRAPPER-67) mvnw script does not download jar if used in git bash in windows

[Jeremy Landis (Jira)]

Jeremy Landis created MWRAPPER-67:
-

 Summary: mvnw script does not download jar if used in git bash in 
windows
 Key: MWRAPPER-67
 URL: https://issues.apache.org/jira/browse/MWRAPPER-67
 Project: Maven Wrapper
  Issue Type: Bug
  Components: Maven Wrapper Scripts
Affects Versions: 3.1.1
Reporter: Jeremy Landis


Usage of git bash will not download the maven wrapper jar along with curl 
(probably others) due to having windows line endings in the URL (trailing).  To 
ensure that is not the case, make sure to strip invalid line endings out before 
usage.

Use case, ./mvnw in powershell will use mvnw.cmd and has no issues downloading. 
 If user does same in git bash, it will fail with invalid URL error with curl.  
Using ./mvnw.cmd there will work but not natural usage.  To ensure this simply 
just works for full support, trim out invalid line feeds.

note: This only affected the download.  It worked otherwise.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (MRELEASE-993) Use shallow checkout per default (git scm)

[Jeremy Landis (Jira)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1753#comment-1753
 ] 

Jeremy Landis commented on MRELEASE-993:


@michael osipov This plugin after the change here was made broke during release 
process as it doesn't run off a shallow clone.

```


         com.mycila
         license-maven-plugin
         
               true
         
 

```

Adding that block to release profile or using license.skip=true does address 
the issue so its not a big deal at this point.  The behaviour change though was 
not expected to break existing use cases.  Although running such a plugin 
during release shouldn't be necessary given code should have already ran it 
previously.  That is probably true for many plugins that end up unnecessarily 
running.  Given its been a year like this and not seeing any better way to deal 
with this, the work around is good enough.  I don't think anything further 
needs done other than awareness which is now listed on that specific plugin.

> Use shallow checkout per default (git scm)
> --
>
> Key: MRELEASE-993
> URL: https://issues.apache.org/jira/browse/MRELEASE-993
> Project: Maven Release Plugin
>  Issue Type: Improvement
>  Components: scm
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.0.0-M1
>
>




--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (MJAVADOC-586) --add-modules ALL-MODULE-PATH can only be used when compiling the unnamed module

[Jeremy Landis (Jira)]

[ 
https://issues.apache.org/jira/browse/MJAVADOC-586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17410780#comment-17410780
 ] 

Jeremy Landis commented on MJAVADOC-586:


[~rfscholte] This still feels like a bug here.  The parameter is provided by 
maven javadoc plugin in 
[https://github.com/apache/maven-javadoc-plugin/blob/master/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java]
 line #5316.  The issue presents itself when automatic module naming is used 
throughout and classpath is still present.  Per the error, its not unnamed, its 
named per automatic module naming.  Could a fix be added to not add that flag 
when automtic module naming is in use?  

 

```java
| |

|if ( mainResolvePathResult != null|

|&& ModuleNameSource.MANIFEST.equals( 
mainResolvePathResult.getModuleNameSource() ) )|

|{|

|arguments.add( "--add-modules" );|

|arguments.add( "ALL-MODULE-PATH" );|

}

```

Or at very least some way to turn this off?  My use case is that I need to run 
javadoc plugin during verify stages spefically to enforce clean javadocs during 
builds before we get to CI.  Only fixes I've seen talk about turning that off 
during such cycles which defeats the purpose.  Due to this issue, when 
targetting jdk 11, I have to force  and  on the javadoc plugin 
back to 8 in order to work.  That in turn throws warnings like crazy when java 
11 constructs used like 'var'.  Perference would be that this actually works 
and best I can tell, adding of that flag isn't allowed.  We are using jdk 
11.0.12 from oracle currently.  Unless something else is going on causing this 
that is being done wrong, the easiest solution seems to be to add a flag to not 
add that if not wanted (at least without putting any thought into it).

> --add-modules ALL-MODULE-PATH can only be used when compiling the unnamed 
> module
> 
>
> Key: MJAVADOC-586
> URL: https://issues.apache.org/jira/browse/MJAVADOC-586
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>  Components: jar
>Affects Versions: 3.1.0
> Environment: JDK 13-ea+11
> Maven 3.6.0
>Reporter: Gili
>Assignee: Robert Scholte
>Priority: Major
> Attachments: javadoc-mojo-requires-module.zip
>
>
> # Extract testcase
>  # Run "mvn clean install javadoc:jar" under JDK 13-ea+11
>  # Build fails with: {{--add-modules ALL-MODULE-PATH can only be used when 
> compiling the unnamed module}}
> This testcase works fine under JDK 12-ea+33.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MRELEASE-993) Use shallow checkout per default (git scm)

[Jeremy Landis (Jira)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17344207#comment-17344207
 ] 

Jeremy Landis commented on MRELEASE-993:


This change breaks plugins that work with git commits.  Would it be possible to 
enhance this to be configurable?

> Use shallow checkout per default (git scm)
> --
>
> Key: MRELEASE-993
> URL: https://issues.apache.org/jira/browse/MRELEASE-993
> Project: Maven Release Plugin
>  Issue Type: Improvement
>  Components: scm
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.0.0-M1
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MCOMPILER-339) Skip --release flag if compilerVersion is lower than 1.9

[Jeremy Landis (Jira)]

[ 
https://issues.apache.org/jira/browse/MCOMPILER-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17070029#comment-17070029
 ] 

Jeremy Landis commented on MCOMPILER-339:
-

Please note: For clarity.  The usage is correct of 'release'.  Its the fact 
that if jdk 8 is used to compile, that shouldn't be provided to java.  It 
doesn't work.  It cannot give false impression it will, it won't.  It's not 
valid for that jdk and the jdk will rejected the compilation.  Thus I'm not 
seeing danger here at all.  I'd be happen if there was just a flag for that 
considered danger.  Default as it does now, but let me configure it to ignore 
invalid parameters.

> Skip --release flag if compilerVersion is lower than 1.9
> 
>
> Key: MCOMPILER-339
> URL: https://issues.apache.org/jira/browse/MCOMPILER-339
> Project: Maven Compiler Plugin
>  Issue Type: Improvement
>Affects Versions: 3.7.0
>Reporter: David J. M. Karlsen
>Priority: Major
>
> usecase: I have a build which is jdk10 by default, declared via the 
> parent-pom.
>  However, one submodule must be compiled and run with java8. I had hoped to 
> get this working, by setting:
> {noformat}
> 
>   8
>   1.8
>   1.8
>   1.8
> 
> {noformat}
>  
> but it will fail with 
> {noformat}
> Caused by: java.lang.IllegalArgumentException: invalid flag: 
> --release*11:53:45* at com.sun.tools.javac.api.JavacTool.processOptions 
> (JavacTool.java:206)*11:53:45* at 
> com.sun.tools.javac.api.JavacTool.getTask (JavacTool.java:156)*11:53:45* 
> at com.sun.tools.javac.api.JavacTool.getTask (JavacTool.java:107)*11:53:45*   
>   at com.sun.tools.javac.api.JavacTool.getTask (JavacTool.java:64)*11:53:45*  
>at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess 
> (JavaxToolsCompiler.java:125)*11:53:45* at 
> org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile 
> (JavacCompiler.java:174)*11:53:45* at 
> org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute 
> (AbstractCompilerMojo.java:1075)*11:53:45* at 
> org.apache.maven.plugin.compiler.TestCompilerMojo.execute 
> (TestCompilerMojo.java:176)*11:53:45* at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:134)*11:53:45* at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:208)*11:53:45* at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:154)*11:53:45* at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:146)*11:53:45* at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:117)*11:53:45* at 
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
>  (MultiThreadedBuilder.java:200)*11:53:45* at 
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
>  (MultiThreadedBuilder.java:196)*11:53:45* at 
> java.util.concurrent.FutureTask.run (FutureTask.java:266)*11:53:45* at 
> java.util.concurrent.Executors$RunnableAdapter.call 
> (Executors.java:511)*11:53:45* at java.util.concurrent.FutureTask.run 
> (FutureTask.java:266)*11:53:45* at 
> java.util.concurrent.ThreadPoolExecutor.runWorker 
> (ThreadPoolExecutor.java:1149)*11:53:45* at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run 
> (ThreadPoolExecutor.java:624)*11:53:45* at java.lang.Thread.run 
> (Thread.java:748)
> {noformat}
> If the release flag could only be enabled for compiler versions supporting it 
> it would be easier to juggle the build.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (MCOMPILER-339) Skip --release flag if compilerVersion is lower than 1.9

[Jeremy Landis (Jira)]

[ 
https://issues.apache.org/jira/browse/MCOMPILER-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17070024#comment-17070024
 ] 

Jeremy Landis edited comment on MCOMPILER-339 at 3/28/20, 8:34 PM:
---

Hi [~rfscholte], That results in hard-coding that isn't easily controlled.  I 
had to use spring boot styled property setup and already have numerous profiles 
for that.  Its extremely complicated that I cannot just state 
x as root property outside of 
a profile and it work down to jdk 8 which is lowest jdk we allow.  We fully 
have animal sniffer compiled globally as well and further are using enforcer 
extra to ensure binary compatibility of other jars which none of this even 
accounts for.  I find this too hard lined as even your comments in 2018 
suggested to make a property available to avoid such issue here.  I presume 
that was just this.  This is why echo of a warning (ie maven.compiler.release 
set to 8 but not applied due to jdk 8 usage, use jdk 9 or better for that 
parameter).  The idea is to allow some flexibility here as the jdk is too hard 
on this and will fail compilation.  The profile does work, but it requires a 
significant amount of additional configuration.  All of which I'm past but I 
would prefer to cleanup my configuration.  My use case is 400+ repos using same 
parent super pom that supports builds on jdk 8, 9, 10, 11, 12, 13, 14, or 15 
currently.  Thus it is extremely complicated for me in general and a pain in my 
opinion.  The danger is what?  That the compiler at runtime will fail with 
wrong class error when loaded?  That happens almost immediately under most 
circumstances and 'release' itself again doesn't protect any third party 
dependencies compiled with higher jdks anyways (I wish it did).  So the issue 
it suggests to fix is still present even with 'release' or animal sniffer.  
'release' improves a bit as it will prevent java agents during build that are 
higher jdk but that is effectively it.


was (Author: hazendaz):
Hi [~rfscholte], That results in hard-coding that isn't easily controlled.  I 
had to use spring boot styled property setup and already have numerous profiles 
for that.  Its extremely complicated that I cannot just state 
x as root property outside of 
a profile and it work down to jdk 8 which is lowest jdk we allow.  We fully 
have animal sniffer compiled globally as well and further are using enforcer 
extra to ensure binary compatibility of other jars which none of this even 
accounts for.  I find this too hard lined as even your comments in 2018 
suggested to make a property available to avoid such issue here.  I presume 
that was just this.  This is why echo of a warning (ie maven.compiler.release 
set to 8 but not applied due to jdk 8 usage, use jdk 9 or better for that 
parameter).  The idea is to allow some flexibility here as the jdk is too hard 
on this and will fail compilation.  The profile does work, but it requires a 
significant amount of additional configuration.  All of wish I'm past but I 
would prefer to cleanup my configuration.  My use case is 400+ repos using same 
parent super pom that supports builds on jdk 8, 9, 10, 11, 12, 13, 14, or 15 
currently.  Thus it is extremely complicated for me in general and a pain in my 
opinion.  The danger is what?  That the compiler at runtime will fail with 
wrong class error when loaded?  That happens almost immediately under most 
circumstances and 'release' itself again doesn't protect any third party 
dependencies compiled with higher jdks anyways (I wish it did).  So the issue 
it suggests to fix is still present even with 'release' or animal sniffer.  
'release' improves a bit as it will prevent java agents during build that are 
higher jdk but that is effectively it.

> Skip --release flag if compilerVersion is lower than 1.9
> 
>
> Key: MCOMPILER-339
> URL: https://issues.apache.org/jira/browse/MCOMPILER-339
> Project: Maven Compiler Plugin
>  Issue Type: Improvement
>Affects Versions: 3.7.0
>Reporter: David J. M. Karlsen
>Priority: Major
>
> usecase: I have a build which is jdk10 by default, declared via the 
> parent-pom.
>  However, one submodule must be compiled and run with java8. I had hoped to 
> get this working, by setting:
> {noformat}
> 
>   8
>   1.8
>   1.8
>   1.8
> 
> {noformat}
>  
> but it will fail with 
> {noformat}
> Caused by: java.lang.IllegalArgumentException: invalid flag: 
> --release*11:53:45* at com.sun.tools.javac.api.JavacTool.processOptions 
> (JavacTool.java:206)*11:53:45* at 
> com.sun.tools.javac.api.JavacTool.getTask (JavacTool.java:156)*11:53:45* 
> at com.sun.tools.javac.api.JavacTool.getTask (JavacTool.java:107)*11:53:45*   
>   at com.sun.tools.javac.api.JavacTool.getTask (JavacTool.java:64)

[jira] [Commented] (MCOMPILER-339) Skip --release flag if compilerVersion is lower than 1.9

[Jeremy Landis (Jira)]

[ 
https://issues.apache.org/jira/browse/MCOMPILER-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17070024#comment-17070024
 ] 

Jeremy Landis commented on MCOMPILER-339:
-

Hi [~rfscholte], That results in hard-coding that isn't easily controlled.  I 
had to use spring boot styled property setup and already have numerous profiles 
for that.  Its extremely complicated that I cannot just state 
x as root property outside of 
a profile and it work down to jdk 8 which is lowest jdk we allow.  We fully 
have animal sniffer compiled globally as well and further are using enforcer 
extra to ensure binary compatibility of other jars which none of this even 
accounts for.  I find this too hard lined as even your comments in 2018 
suggested to make a property available to avoid such issue here.  I presume 
that was just this.  This is why echo of a warning (ie maven.compiler.release 
set to 8 but not applied due to jdk 8 usage, use jdk 9 or better for that 
parameter).  The idea is to allow some flexibility here as the jdk is too hard 
on this and will fail compilation.  The profile does work, but it requires a 
significant amount of additional configuration.  All of wish I'm past but I 
would prefer to cleanup my configuration.  My use case is 400+ repos using same 
parent super pom that supports builds on jdk 8, 9, 10, 11, 12, 13, 14, or 15 
currently.  Thus it is extremely complicated for me in general and a pain in my 
opinion.  The danger is what?  That the compiler at runtime will fail with 
wrong class error when loaded?  That happens almost immediately under most 
circumstances and 'release' itself again doesn't protect any third party 
dependencies compiled with higher jdks anyways (I wish it did).  So the issue 
it suggests to fix is still present even with 'release' or animal sniffer.  
'release' improves a bit as it will prevent java agents during build that are 
higher jdk but that is effectively it.

> Skip --release flag if compilerVersion is lower than 1.9
> 
>
> Key: MCOMPILER-339
> URL: https://issues.apache.org/jira/browse/MCOMPILER-339
> Project: Maven Compiler Plugin
>  Issue Type: Improvement
>Affects Versions: 3.7.0
>Reporter: David J. M. Karlsen
>Priority: Major
>
> usecase: I have a build which is jdk10 by default, declared via the 
> parent-pom.
>  However, one submodule must be compiled and run with java8. I had hoped to 
> get this working, by setting:
> {noformat}
> 
>   8
>   1.8
>   1.8
>   1.8
> 
> {noformat}
>  
> but it will fail with 
> {noformat}
> Caused by: java.lang.IllegalArgumentException: invalid flag: 
> --release*11:53:45* at com.sun.tools.javac.api.JavacTool.processOptions 
> (JavacTool.java:206)*11:53:45* at 
> com.sun.tools.javac.api.JavacTool.getTask (JavacTool.java:156)*11:53:45* 
> at com.sun.tools.javac.api.JavacTool.getTask (JavacTool.java:107)*11:53:45*   
>   at com.sun.tools.javac.api.JavacTool.getTask (JavacTool.java:64)*11:53:45*  
>at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess 
> (JavaxToolsCompiler.java:125)*11:53:45* at 
> org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile 
> (JavacCompiler.java:174)*11:53:45* at 
> org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute 
> (AbstractCompilerMojo.java:1075)*11:53:45* at 
> org.apache.maven.plugin.compiler.TestCompilerMojo.execute 
> (TestCompilerMojo.java:176)*11:53:45* at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:134)*11:53:45* at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:208)*11:53:45* at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:154)*11:53:45* at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:146)*11:53:45* at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:117)*11:53:45* at 
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
>  (MultiThreadedBuilder.java:200)*11:53:45* at 
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
>  (MultiThreadedBuilder.java:196)*11:53:45* at 
> java.util.concurrent.FutureTask.run (FutureTask.java:266)*11:53:45* at 
> java.util.concurrent.Executors$RunnableAdapter.call 
> (Executors.java:511)*11:53:45* at java.util.concurrent.FutureTask.run 
> (FutureTask.java:266)*11:53:45* at 
> java.util.concurrent.ThreadPoolExecutor.runWorker 
> (ThreadPoolExecutor.java:1149)*11:53:45* at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run 
> (ThreadPoolExecutor.java:624)*11:53:45* at java.lang.Thread.run 
> (Thread.java:748)
> {noformat}
>

[jira] [Commented] (MCOMPILER-339) Skip --release flag if compilerVersion is lower than 1.9

[Jeremy Landis (Jira)]

[ 
https://issues.apache.org/jira/browse/MCOMPILER-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17068335#comment-17068335
 ] 

Jeremy Landis commented on MCOMPILER-339:
-

I don't think this is a duplicate.  This is a design issue.  What is is asking 
is to stop giving java the 'release' option if we are not compiling with java 9 
or better.  If using jdk 8 to run a build which maven should know, don't 
provide the release option to java.  It's just going to fail.  This is making 
it hard for us to have super poms that work in reasonable way.  We have to set 
other variables first, then try to get things working latest.  It's extremely 
complicated.  Th rule of thumb is this, if I configured 'release' or 
'testRelease', and the jdk being used to build is not jdk 9 or better, don't 
give that parameter to java.  Just issue a warning if you must. 

 

For reference, my use case, I have a super pom that supports 400+ repos and 
supports from java 7 through java 15 EA.  It runs with java 8 at lowest level 
using cross compilation.  My super pom, I cannot just deside that 'release' is 
not to be set as a property.  I have to have many profiles and set some dummy 
value first then later set the real value.  It's not very clear like the old 
ones were and causes a lot of friction. 

 

The best rule of thumb here is simply don't pass java options it doesn't 
support even if users misconfigure.  I can assure you, like the reporter here, 
I have not misconfigured.  We are stuck due to a glitch in what is being done 
now.  The only way around it is to write extra properties that daisy chain 
together which makes it more complicated on the setup.  These are pretty 
advanced and I'm sure the reporters is as well.  I've personally been meaning 
to report this for some time but just now doing so.  So I'm glad I'm not alone. 
 But it is not an ask to translate anything.  It's simple to ignore the 
'release' / 'testRelease' if not intended for that jdk no matter the other 
settings.  That is all...

 

What reporter is doing is that he is getting stuck with a parent pom that 
defined that variable.  You cannot undo that portion.  I was able to but it is 
not pretty.  Yes he is incorrectly setting 8 there, but really it shold just be 
ignored, its wrong, its not applicable to jdk 8 thus it should not be provided 
to the jdk to process.

 

> Skip --release flag if compilerVersion is lower than 1.9
> 
>
> Key: MCOMPILER-339
> URL: https://issues.apache.org/jira/browse/MCOMPILER-339
> Project: Maven Compiler Plugin
>  Issue Type: Improvement
>Affects Versions: 3.7.0
>Reporter: David J. M. Karlsen
>Priority: Major
>
> usecase: I have a build which is jdk10 by default, declared via the 
> parent-pom.
>  However, one submodule must be compiled and run with java8. I had hoped to 
> get this working, by setting:
> {noformat}
> 
>   8
>   1.8
>   1.8
>   1.8
> 
> {noformat}
>  
> but it will fail with 
> {noformat}
> Caused by: java.lang.IllegalArgumentException: invalid flag: 
> --release*11:53:45* at com.sun.tools.javac.api.JavacTool.processOptions 
> (JavacTool.java:206)*11:53:45* at 
> com.sun.tools.javac.api.JavacTool.getTask (JavacTool.java:156)*11:53:45* 
> at com.sun.tools.javac.api.JavacTool.getTask (JavacTool.java:107)*11:53:45*   
>   at com.sun.tools.javac.api.JavacTool.getTask (JavacTool.java:64)*11:53:45*  
>at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess 
> (JavaxToolsCompiler.java:125)*11:53:45* at 
> org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile 
> (JavacCompiler.java:174)*11:53:45* at 
> org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute 
> (AbstractCompilerMojo.java:1075)*11:53:45* at 
> org.apache.maven.plugin.compiler.TestCompilerMojo.execute 
> (TestCompilerMojo.java:176)*11:53:45* at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:134)*11:53:45* at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:208)*11:53:45* at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:154)*11:53:45* at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:146)*11:53:45* at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:117)*11:53:45* at 
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
>  (MultiThreadedBuilder.java:200)*11:53:45* at 
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
>  (MultiThreadedBuilder.java:196)*11:53:45* at 
> java.util.concurrent.FutureTask.run (FutureTask.java:266)*11:53:45* at 
> java.ut

[jira] [Created] (MJAVADOC-647) Support for Split jdk 7 during build

[Jeremy Landis (Jira)]

Jeremy Landis created MJAVADOC-647:
--

 Summary: Support for Split jdk 7 during build
 Key: MJAVADOC-647
 URL: https://issues.apache.org/jira/browse/MJAVADOC-647
 Project: Maven Javadoc Plugin
  Issue Type: Dependency upgrade
  Components: javadoc
Affects Versions: 3.2.0
Reporter: Jeremy Landis


Currently it is possible to split the source / test code to compile 
differently.  Example use case is requirement to cross compile source target to 
jdk 7 and test with jdk 8.  This works fine, but the javadoc plugin doesn't 
seem to handle this very well. The moment java 8 items such as lambdas are 
introduced, it fails on javadoc generation on test side only.  I'm not sure how 
the pre java 9 setup is, but the post java 9 setup seems to rely only on 
maven.compiler.release and it should also take into account 
maven.compiler.testRelease.  Is it possible to have this added?

 

I am working around this by forcing the higher javadoc solution directly on the 
plugin configuration.  My preference is to not have to make special overrides 
when the simple flags suffice.

 

So for java 9+, asking that this handles

 

${java.release.version}
 
${java.test.release.version}

 

properly.

 

I suspect although didn't see in the source, that for java 8 or earlier it is 
either using something on its own or somehow relying on the old source/target 
settings but doesn't use the test variation during test java doc creation.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MRELEASE-1038) releaseProfiles get overriden by exec.pomFileName

[Jeremy Landis (Jira)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032030#comment-17032030
 ] 

Jeremy Landis commented on MRELEASE-1038:
-

Ugly fix...really hoping this is fixed soon.  By my count 3 plugins recently 
released all have pretty major regressions.  This just bit me today when 
releasing where I needed  to split release activity from 
signing activity.  Those still doing open source and using obsolete and 
unsupported oss-parent probably haven't noticed.  Really hoping this regression 
is fixed and patch released ASAP.  There is very little on the master since the 
first milestone and this is a rather ugly solution which has numerous jiras now 
from what I've found regarding this.

> releaseProfiles get overriden by exec.pomFileName
> -
>
> Key: MRELEASE-1038
> URL: https://issues.apache.org/jira/browse/MRELEASE-1038
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: perform
>Affects Versions: 3.0.0-M1
>Reporter: Benoit MESSAGER
>Priority: Minor
>
> Profiles specified in . are overrided by the 
> pom file name.
> This come from : org.apache.maven.shared.release.config.ReleaseUtils line 130 
> :
> {code:java}
> if ( properties.containsKey( "exec.activateProfiles" ) )
> {
> builder.setActivateProfiles( Arrays.asList( properties.getProperty( 
> "exec.pomFileName" ).split( "," ) ) );
> }
> {code}
> this look like a failed copy/paste
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MCHECKSTYLE-389) MCHECKSTYLE-365 introduces regression with 'rules' aggregate count section on report

[Jeremy Landis (Jira)]

Jeremy Landis created MCHECKSTYLE-389:
-

 Summary: MCHECKSTYLE-365 introduces regression with 'rules' 
aggregate count section on report
 Key: MCHECKSTYLE-389
 URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-389
 Project: Maven Checkstyle Plugin
  Issue Type: Dependency upgrade
Affects Versions: 3.1.0
Reporter: Jeremy Landis


Commit eee0ba1 in CheckstyleReportGenerator.java sets the default 'severity' is 
set as 'error'.  The suggestion is that it fixes count issues per adjusted 
comment at that time.  While that may or may not be true, what it does do is 
incorrectly shut down the entire section of rules aggregation counts in some 
cases.  The severity only takes into account that specific one to then 
aggregate.  Selecting just one other than null is going to mess up the logic as 
implemented here.  This change needs reverted for that one specific change 
only.  The original issue should be reopened as it was not properly fixed.  The 
IT tests fails to take into account individual types.  It includes both 'info' 
and 'error' thus the only reason it even works.

In my test case, I'm using 'mybatis-3'.  I have configured it to use google 
checks so nothing else setup.  It has 0 info, 3151warnings, and 0 errors.  
Switching it to any other value will cause it to only reflect that section.  So 
using 'info', nothing shows up.  Using 'error' as coded now, nothing shows up.  
Using 'warning', it does show up.  Continuing to use null as originally the 
case, it does show up.

There really was a miscount somewhere, but that was not the right fix.  For my 
test, I get a miscount of +5 if using 'warning' or the original null.  That is 
entirely better than nothing. And therefore, the best solution for now is to 
revert this change.

While my test does not have a combination of issues in 'info', 'warning', and 
'error', presumably most do and thus why this was not reported after almost a 
year since the release of 3.1.0. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MCHECKSTYLE-384) Incompatibility to Checkstyle version >= 8.24

[Jeremy Landis (Jira)]

[ 
https://issues.apache.org/jira/browse/MCHECKSTYLE-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17019765#comment-17019765
 ] 

Jeremy Landis commented on MCHECKSTYLE-384:
---

I'm going to open a new issue that is somewhat related.  Plugin 3.1.0 of 
checkstyle has a major regression in my opinion which started me down the path 
of cleaning things up.  The reports do not show the resulting aggregated rules 
that are violated.  If I drop back to 3.0.0, I get that up through checkstyle 
8.24.  So to the outside user, maven checkstyle plugin 3.0.0 supports through 
checkstyle 8.24 with override without a problem.  It breaks after due to api 
changes.  Maven checkstyle plugin 3.1.0 regardless of the version it claims to 
use (8.19) through 8.28 fails to generate the aggregated rule violation 
section.  Its there, just empty.  I'm now reviewing 3.0.0 to 3.1.0 release to 
see if I can find where the problem is especially since version 3.0.0 actually 
works to a point.

> Incompatibility to Checkstyle version >= 8.24 
> --
>
> Key: MCHECKSTYLE-384
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-384
> Project: Maven Checkstyle Plugin
>  Issue Type: Bug
>  Components: checkstyle:check
>Affects Versions: 3.1.0
>Reporter: Martin
>Priority: Blocker
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The latest {{maven-checkstyle-plugin}} is incompatible to Checkstyle version 
> 8.24 and newer. The check for "LineLength" was moved from "TreeWalker" to 
> "Checker". 
> For further details see "Breaking backward compatibility" under 
> https://checkstyle.org/releasenotes.html#Release_8.24
>  
> {code:none|title=Maven Console Output}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-checkstyle-plugin:3.1.0:check (validate) on 
> project top-secrect: Failed during checkstyle configuration: LineLength is 
> not allowed as a child in Checker -> [Help 1]
> [ERROR] ...
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MCHECKSTYLE-384) Incompatibility to Checkstyle version >= 8.24

[Jeremy Landis (Jira)]

[ 
https://issues.apache.org/jira/browse/MCHECKSTYLE-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17019223#comment-17019223
 ] 

Jeremy Landis commented on MCHECKSTYLE-384:
---

The build is actually incompatible with IT tests as indicated here.  I'm 
working on fixing those now.  The change alone would indicate to those using 
this that there were issues post the points i'm marking per checkstyle change 
log.  That may help others.  I do just plan to target this Jira ticket.

> Incompatibility to Checkstyle version >= 8.24 
> --
>
> Key: MCHECKSTYLE-384
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-384
> Project: Maven Checkstyle Plugin
>  Issue Type: Bug
>  Components: checkstyle:check
>Affects Versions: 3.1.0
>Reporter: Martin
>Priority: Blocker
>
> The latest {{maven-checkstyle-plugin}} is incompatible to Checkstyle version 
> 8.24 and newer. The check for "LineLength" was moved from "TreeWalker" to 
> "Checker". 
> For further details see "Breaking backward compatibility" under 
> https://checkstyle.org/releasenotes.html#Release_8.24
>  
> {code:none|title=Maven Console Output}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-checkstyle-plugin:3.1.0:check (validate) on 
> project top-secrect: Failed during checkstyle configuration: LineLength is 
> not allowed as a child in Checker -> [Help 1]
> [ERROR] ...
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MCHECKSTYLE-388) Update internal dependencies with low impact

[Jeremy Landis (Jira)]

 [ 
https://issues.apache.org/jira/browse/MCHECKSTYLE-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Landis updated MCHECKSTYLE-388:
--
Description: 
Bring up to date all low impact dependencies which do not require any changes 
to code.  Both mvn clean install and mvn site will continue to work.

 
 * build helper from 1.9.1 to 3.0.0
 * junit from 4.8.2 to 4.13
 * plexus-interpolation from 1.24 to 1.26
 * plexus-velocity from 1.1.8 to 1.2
 * velocity from 1.5 to 1.7
 * commons-collections from 3.2.1 to 3.2.2
 * animal sniffer from 1.16 to 1.18
 * plexus-utils from 3.0.24 to 3.3.0 *1
 * jaxb-api 2.3.0 to 2.3.1
 * l10n plugin from 1.0-alpha-2 to last on googlecode of 1.8

*1 Resolves CVE issue

  was:
Bring up to date all low impact dependencies which do not require any changes 
to code.  Both mvn clean install and mvn site will continue to work.

 
 * build helper from 1.9.1 to 3.0.0
 * junit from 4.8.2 to 4.13
 * plexus-interpolation from 1.24 to 1.26
 * plexus-velocity from 1.1.8 to 1.2
 * velocity from 1.5 to 1.7
 * commons-collections from 3.2.1 to 3.2.2
 * animal sniffer from 1.16 to 1.18
 * plexus-utils from 3.0.24 to 3.3.0 *1
 * jaxb-api 2.3.0 to 2.3.1
 * checkstyle from 8.19 to 8.28 *2
 * l10n plugin from 1.0-alpha-2 to last on googlecode of 1.8

*1 Resolves CVE issue

*2 Does not address configuration needs as noted on other Jira tickets as users 
can configure their own checkstyle.xml.

 


> Update internal dependencies with low impact
> 
>
> Key: MCHECKSTYLE-388
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-388
> Project: Maven Checkstyle Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.1.0
>Reporter: Jeremy Landis
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Bring up to date all low impact dependencies which do not require any changes 
> to code.  Both mvn clean install and mvn site will continue to work.
>  
>  * build helper from 1.9.1 to 3.0.0
>  * junit from 4.8.2 to 4.13
>  * plexus-interpolation from 1.24 to 1.26
>  * plexus-velocity from 1.1.8 to 1.2
>  * velocity from 1.5 to 1.7
>  * commons-collections from 3.2.1 to 3.2.2
>  * animal sniffer from 1.16 to 1.18
>  * plexus-utils from 3.0.24 to 3.3.0 *1
>  * jaxb-api 2.3.0 to 2.3.1
>  * l10n plugin from 1.0-alpha-2 to last on googlecode of 1.8
> *1 Resolves CVE issue



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MCHECKSTYLE-388) Update internal dependencies with low impact

[Jeremy Landis (Jira)]

Jeremy Landis created MCHECKSTYLE-388:
-

 Summary: Update internal dependencies with low impact
 Key: MCHECKSTYLE-388
 URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-388
 Project: Maven Checkstyle Plugin
  Issue Type: Dependency upgrade
Affects Versions: 3.1.0
Reporter: Jeremy Landis


Bring up to date all low impact dependencies which do not require any changes 
to code.  Both mvn clean install and mvn site will continue to work.

 
 * build helper from 1.9.1 to 3.0.0
 * junit from 4.8.2 to 4.13
 * plexus-interpolation from 1.24 to 1.26
 * plexus-velocity from 1.1.8 to 1.2
 * velocity from 1.5 to 1.7
 * commons-collections from 3.2.1 to 3.2.2
 * animal sniffer from 1.16 to 1.18
 * plexus-utils from 3.0.24 to 3.3.0 *1
 * jaxb-api 2.3.0 to 2.3.1
 * checkstyle from 8.19 to 8.28 *2
 * l10n plugin from 1.0-alpha-2 to last on googlecode of 1.8

*1 Resolves CVE issue

*2 Does not address configuration needs as noted on other Jira tickets as users 
can configure their own checkstyle.xml.

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (SCM-931) [travis-ci] Re-establish working travis-ci for pull requests

[Jeremy Landis (Jira)]

Jeremy Landis created SCM-931:
-

 Summary: [travis-ci] Re-establish working travis-ci for pull 
requests
 Key: SCM-931
 URL: https://issues.apache.org/jira/browse/SCM-931
 Project: Maven SCM
  Issue Type: Improvement
  Components: Technical tasks
Affects Versions: 1.11.2
Reporter: Jeremy Landis


{color:#24292e}While internally jenkins is used to perform testing, outside 
developers will not generally know that. The project currently contains 
travis-ci and flipping it on shows that it fails for numerous reasons.{color}

{color:#24292e}    - Project moved to jdk7 some time back so openjdk6 is going 
to fail regardless{color}

{color:#24292e}    - The default travis-ci ubuntu platform is now on xenial. 
Thus 'oracle' will fail due to licensing restrictions now so only openjdk is 
viable.{color}

{color:#24292e}    - Xenial builds use a script to get jdks and jdk 7 is no 
longer valid so both 'oracle' and 'open' variations will fail. {color}

{color:#24292e}    - Going back to 'trusty' will get 'oracle' for jdk 8 working 
but won't help with jdk7 at all.
{color}

{color:#24292e}    - Going back to 'precise' will acheive getting 'openjdk7', 
'oraclejdk7', and 'oraclejdk8' working.{color}

{color:#24292e} As that is the furthest back travis-ci can go, its likely this 
will pop up with failures in the future once that is completely discontinued. 
At that time, 'oracle' should be dropped and only openjdk8 and above should be 
used. That will put more reliance on animal sniffer being accurate which feels 
mostly the case here.{color}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (SCM-930) Raise libraries to java 7 level and fix travis-ci build

[Jeremy Landis (Jira)]

Jeremy Landis created SCM-930:
-

 Summary: Raise libraries to java 7 level and fix travis-ci build
 Key: SCM-930
 URL: https://issues.apache.org/jira/browse/SCM-930
 Project: Maven SCM
  Issue Type: Improvement
  Components: maven-scm-provider-integrity, maven-scm-provider-jgit
Affects Versions: 1.11.2
Reporter: Jeremy Landis


Reviewing poms for libraries to upgrade with following results.
 * Groovy-all from 1.7.6 to 2.4.17
 * Slf4j-simple from 1.7.25 to 1.7.30
 * Junit from 4.12 to 4.13
 * Plexus-utils from 3.1.0 to 3.3.0

Further discovered some trailing spacing and excessive breaking around plugin 
execution filters.

In order to confirm this worked on the build, I enabled travis-ci on my fork.  
I noted a number of problems there.  In order to limit changes, I put it onto 
'precise' and removed openjdk6 (project is on 7 currently). 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (SCM-884) Upgrade jgit to last version of java 7 release (4.5.0.201609210915-r)

[Jeremy Landis (JIRA)]

Jeremy Landis created SCM-884:
-

 Summary: Upgrade jgit to last version of java 7 release 
(4.5.0.201609210915-r)
 Key: SCM-884
 URL: https://issues.apache.org/jira/browse/SCM-884
 Project: Maven SCM
  Issue Type: Improvement
  Components: maven-scm-provider-jgit
Affects Versions: 1.9.5
Reporter: Jeremy Landis


revwalk.release is now revwalk.close in newer versions which prevents usage of 
this plugin with newer revisions.  To allow all newer revsions (4.9 at time of 
last check), this plugin would need to be raised to java 7 and can safely be on 
4.5.0 jgit.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MRELEASE-974) HTTP in project element

[Jeremy Landis (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15823015#comment-15823015
 ] 

Jeremy Landis commented on MRELEASE-974:


The work around originally mentioned has been confirmed to work just fine so I 
am able to set https as I wanted without any issues.  This can otherwise be 
closed if you like.  Thanks.

> HTTP in project element
> ---
>
> Key: MRELEASE-974
> URL: https://issues.apache.org/jira/browse/MRELEASE-974
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: prepare
>Affects Versions: 2.5.3
>Reporter: Jeremy Landis
>Priority: Minor
>
> In the pom on the  tag, I'd like to use https as they are available 
> for the xmlns, xmlns:xsi, and xsi:schemaLocation locations.  When I run other 
> plugins it's fine but if I try to release it fails.  It initially fails with 
> xmlns:xsi issue.  If I set that back to http, then it flags tags all with 
> http throughout and crashes.  
> What I have to use now...
> ```
> http://maven.apache.org/POM/4.0.0"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> ```
> What I would like to use...
> ```
> https://maven.apache.org/POM/4.0.0"; 
> xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"; 
> xsi:schemaLocation="https://maven.apache.org/POM/4.0.0 
> https://maven.apache.org/xsd/maven-4.0.0.xsd";>
> ```
> Is this possible?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MRELEASE-974) https in project tag

[Jeremy Landis (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15803229#comment-15803229
 ] 

Jeremy Landis edited comment on MRELEASE-974 at 1/6/17 2:04 AM:


Not really a misunderstanding issue but rather I am trying to remove any 
reference from 'http' throughout my code bases.  What I didn't expect was the 
release plugin to fail.  The addSchema false option makes sense as maven has 
always rewritten the project tag which affects my formatting.  Eventually I 
gave up on that formatting not knowing I could disable that behaviour.  If that 
works for me (haven't tried yet), then the work around is perfect.

Can you tell me a bit more on what exactly maven is doing internally that 
required the rewriting of project tag in the first place?


was (Author: hazendaz):
Not really a misunderstanding issue but rather I am trying to remove any 
reference from 'http' throughout my code bases.  What I didn't expect was the 
release plugin to fail.  The addSchema false optino makes sense as maven has 
always rewritten the project tag which affects my formatting.  Eventually I 
gave up on that formatting not knowing I could disable that behaviour.  If that 
works for me (haven't tried yet), then the work around is perfect.

Can you tell me a bit more on what exactly maven is doing internally that 
required the rewriting of project tag in the first place?

> https in project tag
> 
>
> Key: MRELEASE-974
> URL: https://issues.apache.org/jira/browse/MRELEASE-974
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: prepare
>Affects Versions: 2.5.3
>Reporter: Jeremy Landis
>Priority: Minor
>
> In the pom on the  tag, I'd like to use https as they are available 
> for the xmlns, xmlns:xsi, and xsi:schemaLocation locations.  When I run other 
> plugins it's fine but if I try to release it fails.  It initially fails with 
> xmlns:xsi issue.  If I set that back to http, then it flags tags all with 
> http throughout and crashes.  
> What I have to use now...
> ```
> http://maven.apache.org/POM/4.0.0"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> ```
> What I would like to use...
> ```
> https://maven.apache.org/POM/4.0.0"; 
> xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"; 
> xsi:schemaLocation="https://maven.apache.org/POM/4.0.0 
> https://maven.apache.org/xsd/maven-4.0.0.xsd";>
> ```
> Is this possible?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MRELEASE-974) https in project tag

[Jeremy Landis (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15803229#comment-15803229
 ] 

Jeremy Landis commented on MRELEASE-974:


Not really a misunderstanding issue but rather I am trying to remove any 
reference from 'http' throughout my code bases.  What I didn't expect was the 
release plugin to fail.  The addSchema false optino makes sense as maven has 
always rewritten the project tag which affects my formatting.  Eventually I 
gave up on that formatting not knowing I could disable that behaviour.  If that 
works for me (haven't tried yet), then the work around is perfect.

Can you tell me a bit more on what exactly maven is doing internally that 
required the rewriting of project tag in the first place?

> https in project tag
> 
>
> Key: MRELEASE-974
> URL: https://issues.apache.org/jira/browse/MRELEASE-974
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: prepare
>Affects Versions: 2.5.3
>Reporter: Jeremy Landis
>Priority: Minor
>
> In the pom on the  tag, I'd like to use https as they are available 
> for the xmlns, xmlns:xsi, and xsi:schemaLocation locations.  When I run other 
> plugins it's fine but if I try to release it fails.  It initially fails with 
> xmlns:xsi issue.  If I set that back to http, then it flags tags all with 
> http throughout and crashes.  
> What I have to use now...
> ```
> http://maven.apache.org/POM/4.0.0"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> ```
> What I would like to use...
> ```
> https://maven.apache.org/POM/4.0.0"; 
> xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"; 
> xsi:schemaLocation="https://maven.apache.org/POM/4.0.0 
> https://maven.apache.org/xsd/maven-4.0.0.xsd";>
> ```
> Is this possible?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MRELEASE-974) https in project tag

[Jeremy Landis (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15792199#comment-15792199
 ] 

Jeremy Landis commented on MRELEASE-974:


Thanks for the tip.  I'll give that a try.  I will be performing a release in a 
week.  I'll respond back here if that works.

> https in project tag
> 
>
> Key: MRELEASE-974
> URL: https://issues.apache.org/jira/browse/MRELEASE-974
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: prepare
>Affects Versions: 2.5.3
>Reporter: Jeremy Landis
>Priority: Minor
>
> In the pom on the  tag, I'd like to use https as they are available 
> for the xmlns, xmlns:xsi, and xsi:schemaLocation locations.  When I run other 
> plugins it's fine but if I try to release it fails.  It initially fails with 
> xmlns:xsi issue.  If I set that back to http, then it flags tags all with 
> http throughout and crashes.  
> What I have to use now...
> ```
> http://maven.apache.org/POM/4.0.0"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> ```
> What I would like to use...
> ```
> https://maven.apache.org/POM/4.0.0"; 
> xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"; 
> xsi:schemaLocation="https://maven.apache.org/POM/4.0.0 
> https://maven.apache.org/xsd/maven-4.0.0.xsd";>
> ```
> Is this possible?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MRELEASE-974) https in project tag

[Jeremy Landis (JIRA)]

Jeremy Landis created MRELEASE-974:
--

 Summary: https in project tag
 Key: MRELEASE-974
 URL: https://issues.apache.org/jira/browse/MRELEASE-974
 Project: Maven Release Plugin
  Issue Type: Bug
  Components: prepare
Affects Versions: 2.5.3
Reporter: Jeremy Landis
Priority: Minor


In the pom on the  tag, I'd like to use https as they are available 
for the xmlns, xmlns:xsi, and xsi:schemaLocation locations.  When I run other 
plugins it's fine but if I try to release it fails.  It initially fails with 
xmlns:xsi issue.  If I set that back to http, then it flags tags all with http 
throughout and crashes.  

What I have to use now...
```
http://maven.apache.org/POM/4.0.0"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
```

What I would like to use...
```
https://maven.apache.org/POM/4.0.0"; 
xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"; 
xsi:schemaLocation="https://maven.apache.org/POM/4.0.0 
https://maven.apache.org/xsd/maven-4.0.0.xsd";>
```

Is this possible?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MPIR-268) Add Gradle dependency information

[Jeremy Landis (JIRA)]

[ 
https://issues.apache.org/jira/browse/MPIR-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14939038#comment-14939038
 ] 

Jeremy Landis commented on MPIR-268:


Please reopen this issue.  Fix is on PR 
https://github.com/apache/maven-plugins/pull/44

> Add Gradle dependency information
> -
>
> Key: MPIR-268
> URL: https://issues.apache.org/jira/browse/MPIR-268
> Project: Maven Project Info Reports Plugin
>  Issue Type: Bug
>  Components: dependency-info
>Affects Versions: 2.6
>Reporter: Michael Osipov
>
> The Dependency Information report is missing a Gradle dependency snippet.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] (MPIR-268) Add Gradle dependency information

[Jeremy Landis (JIRA)]

[ 
https://jira.codehaus.org/browse/MPIR-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=363209#comment-363209
 ] 

Jeremy Landis commented on MPIR-268:


I mistyped originally...maven central shows 'Gradle / Grails'.  

Anyway, like this is out there.

Dependency Information
--
Apache Buildr
Apache Ivy
Groovy Grape
Gradle/Grails
Scala SBT
Leiningen

I'll look at doing the patch over on github if that works.  Thanks.

> Add Gradle dependency information
> -
>
> Key: MPIR-268
> URL: https://jira.codehaus.org/browse/MPIR-268
> Project: Maven Project Info Reports Plugin
>  Issue Type: Bug
>  Components: dependency-info
>Affects Versions: 2.6
>Reporter: Michael Osipov
>
> The Dependency Information report is missing a Gradle dependency snippet.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MPIR-268) Add Gradle dependency information

[Jeremy Landis (JIRA)]

[ 
https://jira.codehaus.org/browse/MPIR-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=363205#comment-363205
 ] 

Jeremy Landis commented on MPIR-268:


Maven central shows 'Groovy / Grails' line.  Maybe this should be done.  It's 
most likely very easy to do.  Same goes for SBT.  It shows 'Scala SBT'.  I 
think for clarity purposes these should match.

> Add Gradle dependency information
> -
>
> Key: MPIR-268
> URL: https://jira.codehaus.org/browse/MPIR-268
> Project: Maven Project Info Reports Plugin
>  Issue Type: Bug
>  Components: dependency-info
>Affects Versions: 2.6
>Reporter: Michael Osipov
>
> The Dependency Information report is missing a Gradle dependency snippet.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MPMD-197) Bring Dependencies current and Resolve Minor Java Warnings

[Jeremy Landis (JIRA)]

Jeremy Landis created MPMD-197:
--

 Summary: Bring Dependencies current and Resolve Minor Java Warnings
 Key: MPMD-197
 URL: https://jira.codehaus.org/browse/MPMD-197
 Project: Maven PMD Plugin
  Issue Type: Improvement
  Components: PMD
Affects Versions: 3.3
Reporter: Jeremy Landis
Priority: Trivial


Bring various dependencies in pmd plugin current to more recent changes in the 
maven ecosystem.  

maven-site-plugin to 3.4
maven-plugin-testing-harness to 1.3
animal-sniffer-maven-plugin to 1.12
java16 signature to 1.1
plexus-utils to 3.0.21

remove modello-maven-plugin version as it is overriding parent unnecessarily.

Update maven-plugins parent to 27 and remove maven-compiler-plugin and TODO as 
it is part of this updated parent.

Remove unnecessary 'unchecked' suppress warnings, add java 6 requested 
@Overrides, and give types to lists.




--
This message was sent by Atlassian JIRA
(v6.1.6#6162)