[jira] (MRELEASE-861) Rule for JSP comments
Marc Pompl created MRELEASE-861: --- Summary: Rule for JSP comments Key: MRELEASE-861 URL: https://jira.codehaus.org/browse/MRELEASE-861 Project: Maven Release Plugin Issue Type: Wish Affects Versions: 2.1 Reporter: Marc Pompl Priority: Minor It would be really nice if there was a rule to enforce JSP style comments instead of HTML comments. JSP comments have the benefit of be stripped from the rendered HTML. For this, it increases security since developers leave regularly hints for attackers. So, the rule has to find usages of i.e. and suggest the usage of <%-- no my clue is hidden from any browser --> -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-861) Rule for JSP comments
[
https://jira.codehaus.org/browse/MRELEASE-861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-861.
---
Resolution: Won't Fix
Assignee: Robert Scholte
This is not directly related to the maven-release-plugin. Such rules should be
checked during every build or any time you want, not only during a release.
{quote}... if there was a rule to enforce ... {quote}
Now there's this plugin called the [Maven Enforcer
Plugin|http://maven.apache.org/enforcer/maven-enforcer-plugin/] for which you
can specify rules. Sounds like a 100% match, right?
This plugin has a standard set of rules, but these are all Maven related, while
yours is JSP related. So such a rule won't become part of the standard rules.
However, there's an
[API|http://maven.apache.org/enforcer/enforcer-api/writing-a-custom-rule.html]
with which you can write your own rules. That would be the best solution for
you. If you want to share it, maybe the [Codehaus Mojo
team|http://mojo.codehaus.org/extra-enforcer-rules/] is interested.
> Rule for JSP comments
> -
>
> Key: MRELEASE-861
> URL: https://jira.codehaus.org/browse/MRELEASE-861
> Project: Maven Release Plugin
> Issue Type: Wish
>Affects Versions: 2.1
>Reporter: Marc Pompl
>Assignee: Robert Scholte
>Priority: Minor
>
> It would be really nice if there was a rule to enforce JSP style comments
> instead of HTML comments. JSP comments have the benefit of be stripped from
> the rendered HTML. For this, it increases security since developers leave
> regularly hints for attackers.
> So, the rule has to find usages of i.e.
>
> and suggest the usage of
> <%-- no my clue is hidden from any browser -->
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINVOKER-163) Command line -D's are not interpolated
[
https://jira.codehaus.org/browse/MINVOKER-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=338025#comment-338025
]
Robert Scholte commented on MINVOKER-163:
-
@[~bmargulies]: if it wasn't a bug, what was it?
> Command line -D's are not interpolated
> --
>
> Key: MINVOKER-163
> URL: https://jira.codehaus.org/browse/MINVOKER-163
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Benson Margulies
>Assignee: Benson Margulies
>
> Consider an entry in filterProperties like:
>${some-prop}
> If the only definition of 'some-prop' is '-Dsome-prop=someval' on the command
> line, this will not interpolate.
> Somewhat frustratingly, this cannot be demonstrated by using test.properties
> in the invoker itself, because _that_ works fine. So I won't be able to add
> an integration test for this unless someone has some other suggestion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-861) Rule for JSP comments
[ https://jira.codehaus.org/browse/MRELEASE-861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=338029#comment-338029 ] Marc Pompl commented on MRELEASE-861: - Sorry Robert, wrong component. :-) JIRA mucked me about. :-/ I will close this request and file it for the correct project. > Rule for JSP comments > - > > Key: MRELEASE-861 > URL: https://jira.codehaus.org/browse/MRELEASE-861 > Project: Maven Release Plugin > Issue Type: Wish >Affects Versions: 2.1 >Reporter: Marc Pompl >Assignee: Robert Scholte >Priority: Minor > > It would be really nice if there was a rule to enforce JSP style comments > instead of HTML comments. JSP comments have the benefit of be stripped from > the rendered HTML. For this, it increases security since developers leave > regularly hints for attackers. > So, the rule has to find usages of i.e. > > and suggest the usage of > <%-- no my clue is hidden from any browser --> -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-701) IT failures with Jdk 8 (EA)
[
https://jira.codehaus.org/browse/MSITE-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=338034#comment-338034
]
Robert Scholte commented on MSITE-701:
--
Both cause of both failing ITs is the maven-javadoc-plugin. They still use 2.7,
however 2.9.1 doesn't fix the issue either.
They all have to do with invalid/incomplete doclet tags:
{code:title=new-configuration}
2 errors
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 44.270s
[INFO] Finished at: Fri Jan 03 13:32:00 CET 2014
[INFO] Final Memory: 28M/157M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.4-SNAPSHOT:site (default-cli) on
project new-configuration: Error during page generation: Error rendering Maven
report:
[ERROR] Exit code: 1 -
E:\java-workspace\apache-maven-plugins\maven-site-plugin\target\it\new-configuration\src\main\java\org\apache\maven\plugins\it\MyMojo.java:29:
error: unknown tag: goal
[ERROR] * @goal touch
[ERROR] ^
[ERROR]
E:\java-workspace\apache-maven-plugins\maven-site-plugin\target\it\new-configuration\src\main\java\org\apache\maven\plugins\it\MyMojo.java:31:
error: unknown tag: phase
[ERROR] * @phase process-sources
[ERROR] ^
[ERROR]
[ERROR] Command line was: "c:\Program
Files\Java\jdk1.8.0\jre\..\bin\javadoc.exe" @options @packages
{code}
{code:title=MSITE-506}
1 error
100 warnings
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 59.640s
[INFO] Finished at: Fri Jan 03 13:31:12 CET 2014
[INFO] Final Memory: 24M/147M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.4-SNAPSHOT:site (default-site) on
project testmaven3: Error during page generation: Error rendering Maven report:
[ERROR] Exit code: 1 -
E:\java-workspace\apache-maven-plugins\maven-site-plugin\target\it\MSITE-506\target\distro-javadoc-sources\junit-3.8.1-sources\junit\awtui\TestRunner.java:109:
warning: no @return
[ERROR] protected Menu createJUnitMenu() {
[ERROR] ^
...
[ERROR]
E:\java-workspace\apache-maven-plugins\maven-site-plugin\target\it\MSITE-506\target\distro-javadoc-sources\junit-3.8.1-sources\junit\runner\TestCollector.java:9:
error: reference not found
[ERROR] * @see TestSelector
[ERROR] ^
[ERROR]
[ERROR] Command line was: "c:\Program
Files\Java\jdk1.8.0\jre\..\bin\javadoc.exe" @options @packages
{code}
So it seems that javadoc has become a bit stricter. I quick look at the
{{--help}} shows no option for JDK7 behavior.
For the latter I can image this is marked as an error, so we should probably
fix the IT.
For the first we need doclettags for the plugin API, I don't think these exist.
> IT failures with Jdk 8 (EA)
> ---
>
> Key: MSITE-701
> URL: https://jira.codehaus.org/browse/MSITE-701
> Project: Maven Site Plugin
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Herve Boutemy
>
> see
> https://builds.apache.org/view/M-R/view/Maven/job/maven-plugins-ITs-m3.1.x-with-maven-plugin-jdk-1.8/modules
> {noformat}[INFO] --- maven-invoker-plugin:1.8:verify (integration-test) @
> maven-site-plugin ---
> [INFO] -
> [INFO] Build Summary:
> [INFO] Passed: 47, Failed: 2, Errors: 0, Skipped: 0
> [INFO] -
> [ERROR] The following builds failed:
> [ERROR] * new-configuration/pom.xml
> [ERROR] * MSITE-506/pom.xml
> [INFO] -{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINVOKER-163) Command line -D's are not interpolated
[
https://jira.codehaus.org/browse/MINVOKER-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=338043#comment-338043
]
Benson Margulies commented on MINVOKER-163:
---
The _documentation_ says that explicit, in-the-pom, properties are interpolated
for things not defined in filterProperties. So it's working as documented. My
ability to read, on the other hand, was clearly not.
> Command line -D's are not interpolated
> --
>
> Key: MINVOKER-163
> URL: https://jira.codehaus.org/browse/MINVOKER-163
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Benson Margulies
>Assignee: Benson Margulies
>
> Consider an entry in filterProperties like:
>${some-prop}
> If the only definition of 'some-prop' is '-Dsome-prop=someval' on the command
> line, this will not interpolate.
> Somewhat frustratingly, this cannot be demonstrated by using test.properties
> in the invoker itself, because _that_ works fine. So I won't be able to add
> an integration test for this unless someone has some other suggestion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-161) DefaultMavenFileFilter.getDefaultFilterWrappers loads filters from the current directory instead of using basedir
[
https://jira.codehaus.org/browse/MSHARED-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=338050#comment-338050
]
Dominique Jean-Prost commented on MSHARED-161:
--
Hello,
Any news concerning this issue ? The workaround mentionned in
http://jira.codehaus.org/browse/MWAR-301?focusedCommentId=333877&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-333877
does work though.
By the way, the TODO in java code does seem to agree this point of view ?
{{// TODO new File should be new File(mavenProject.getBasedir(), filterfile )
?}}
Dom
> DefaultMavenFileFilter.getDefaultFilterWrappers loads filters from the
> current directory instead of using basedir
> -
>
> Key: MSHARED-161
> URL: https://jira.codehaus.org/browse/MSHARED-161
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Affects Versions: maven-filtering-1.0-beta-3, maven-filtering-1.0-beta-4
>Reporter: Jeff MAURY
>
> If a POM is a sub module and has filtered configured other than with the
> build section (through the configuration part of the WAR plugin for example),
> then the call to this method will fail if Maven is run from the parent POM
> because the filters are loaded without any regard to absolute/relative paths
> and projet basedir.
> Please note that the Maven project is available to these methods but not used
> for this purpose.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4618) maven-javadoc-plugin aggregate-jar fails with maven3 and multiple modules
[
https://jira.codehaus.org/browse/MNG-4618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=338057#comment-338057
]
Qadeer Ahmad commented on MNG-4618:
---
I have the same problem. See my stackoverflow
[question|http://stackoverflow.com/questions/20496972/maven-javadoc-aggregate-jar-plugin-fails-because-of-unresolved-dependencies].
> maven-javadoc-plugin aggregate-jar fails with maven3 and multiple modules
> -
>
> Key: MNG-4618
> URL: https://jira.codehaus.org/browse/MNG-4618
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0-alpha-7
>Reporter: bob mcwhirter
>Assignee: Benjamin Bentmann
> Fix For: 3.0-beta-1
>
> Attachments: MNG-4618.zip
>
>
> Binding javadoc:aggregate-jar to package in an aggregator project works with
> maven 2.
> In maven3, it attempts to build the aggregate javadocs before completing the
> full reactor.
> When executing 'mvn install', I'd expect it to run the reactor and install
> all modules before attempting the 'compile' dependency resolution for the
> javadoc execution.
> During early execution, I get output such as:
> {noformat}
> [WARNING] The dependency:
> [org.torquebox:torquebox-common-spi:jar:1.0.0.Beta19] can't be resolved but
> has been found in the reactor (probably snapshots).
> This dependency has been excluded from the Javadoc classpath. You should
> rerun javadoc after executing mvn install.
> {noformat}
> In maven2, it'd react, install all submodules, then, as the last act, do the
> javadoc:aggregate-jar.
> If I add a for each module to the maven-javadoc-plugin's
> section, then it will get the order correct. I'd just kinda
> think that'd be implicit.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-315) Unsign jars are still not ok
Tony Chemit created MSHARED-315: --- Summary: Unsign jars are still not ok Key: MSHARED-315 URL: https://jira.codehaus.org/browse/MSHARED-315 Project: Maven Shared Components Issue Type: Bug Components: maven-jarsigner Affects Versions: maven-jarsigner-1.3 Reporter: Tony Chemit A typo came in code and the manifest file is not ok, main attributes are cleared instead of entries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-315) Unsign jars are still not ok
[ https://jira.codehaus.org/browse/MSHARED-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tony Chemit updated MSHARED-315: Assignee: Tony Chemit > Unsign jars are still not ok > > > Key: MSHARED-315 > URL: https://jira.codehaus.org/browse/MSHARED-315 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-jarsigner >Affects Versions: maven-jarsigner-1.3 >Reporter: Tony Chemit >Assignee: Tony Chemit > > A typo came in code and the manifest file is not ok, main attributes are > cleared instead of entries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-315) Unsign jars are still not ok
[ https://jira.codehaus.org/browse/MSHARED-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tony Chemit closed MSHARED-315. --- Resolution: Fixed Fix Version/s: maven-jarsigner-1.3.1 > Unsign jars are still not ok > > > Key: MSHARED-315 > URL: https://jira.codehaus.org/browse/MSHARED-315 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-jarsigner >Affects Versions: maven-jarsigner-1.3 >Reporter: Tony Chemit >Assignee: Tony Chemit > Fix For: maven-jarsigner-1.3.1 > > > A typo came in code and the manifest file is not ok, main attributes are > cleared instead of entries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-315) Unsign jars are still not ok
[ https://jira.codehaus.org/browse/MSHARED-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=338059#comment-338059 ] Tony Chemit commented on MSHARED-315: - Fixed in [r1555198|http://svn.apache.org/r1555198] > Unsign jars are still not ok > > > Key: MSHARED-315 > URL: https://jira.codehaus.org/browse/MSHARED-315 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-jarsigner >Affects Versions: maven-jarsigner-1.3 >Reporter: Tony Chemit >Assignee: Tony Chemit > Fix For: maven-jarsigner-1.3.1 > > > A typo came in code and the manifest file is not ok, main attributes are > cleared instead of entries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJARSIGNER-33) Sign already signed jar still does not work
Tony Chemit created MJARSIGNER-33: - Summary: Sign already signed jar still does not work Key: MJARSIGNER-33 URL: https://jira.codehaus.org/browse/MJARSIGNER-33 Project: Maven Jar Signer Plugin Issue Type: Bug Affects Versions: 1.3 Reporter: Tony Chemit See MSHARED-315. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJARSIGNER-33) Sign already signed jar still does not work
[ https://jira.codehaus.org/browse/MJARSIGNER-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tony Chemit updated MJARSIGNER-33: -- Assignee: Tony Chemit > Sign already signed jar still does not work > --- > > Key: MJARSIGNER-33 > URL: https://jira.codehaus.org/browse/MJARSIGNER-33 > Project: Maven Jar Signer Plugin > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Tony Chemit >Assignee: Tony Chemit > > See MSHARED-315. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJARSIGNER-33) Sign already signed jar still does not work
[ https://jira.codehaus.org/browse/MJARSIGNER-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tony Chemit closed MJARSIGNER-33. - Resolution: Fixed Fix Version/s: 1.3.1 Done in [r1555223|http://svn.apache.org/r1555223] > Sign already signed jar still does not work > --- > > Key: MJARSIGNER-33 > URL: https://jira.codehaus.org/browse/MJARSIGNER-33 > Project: Maven Jar Signer Plugin > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Tony Chemit >Assignee: Tony Chemit > Fix For: 1.3.1 > > > See MSHARED-315. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1038) Regression: Method depends on nonexistent group
[
https://jira.codehaus.org/browse/SUREFIRE-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Gudian closed SUREFIRE-1038.
Resolution: Fixed
@Gili, if you like, check 2.17-SNAPSHOT (your attached test case works with
that version, but you may have other tests).
Thanks for your report! :)
> Regression: Method depends on nonexistent group
> ---
>
> Key: SUREFIRE-1038
> URL: https://jira.codehaus.org/browse/SUREFIRE-1038
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 2.16
>Reporter: Gili
>Assignee: Andreas Gudian
>Priority: Critical
> Fix For: 2.17
>
> Attachments: SUREFIRE-1038.zip
>
>
> Version 2.16 contains a regression that prevents the use of TestNG groups.
> Version 2.15 works fine.
> When I run my unit tests I get the following error:
> {code}
> Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.16:test (default-test) on
> project web.backend: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.16:test failed: There was an
> error in the forked process
> org.testng.TestNGException:
> DependencyMap::Method "CallTest.createCall()[pri:0,
> instance:com.vtlr.web.backend.resource.CallTest@53635ac1]" depends on
> nonexistent group "department"
> at org.testng.DependencyMap.getMethodsThatBelongTo(DependencyMap.java:46)
> at org.testng.TestRunner.createDynamicGraph(TestRunner.java:1074)
> at org.testng.TestRunner.privateRun(TestRunner.java:734)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
> at org.testng.SuiteRunner.run(SuiteRunner.java:240)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
> at org.testng.TestNG.run(TestNG.java:1057)
> at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:91)
> at
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeMulti(TestNGDirectoryTestSuite.java:204)
> at
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:107)
> at
> org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:113)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}
> I checked and group "department" exists. Furthermore, downgrading back to
> 2.15 makes the problem go away.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
