[jira] (MEAR-186) Source and Resource Directories are Ignored
[ https://jira.codehaus.org/browse/MEAR-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=346090#comment-346090 ] Thomas Beauvais commented on MEAR-186: -- Not to be a burden but would someone be able to provide an update? Is there a way to work around this? Why was this changed to 'improvement'? This is a feature gap.. why doesn't the plugin just use the sources/resources provided by the project rather than have to specify custom configuration? Typically EAR projects aren't compiling sources, right? > Source and Resource Directories are Ignored > --- > > Key: MEAR-186 > URL: https://jira.codehaus.org/browse/MEAR-186 > Project: Maven Ear Plugin > Issue Type: Improvement >Affects Versions: 2.9 > Environment: Ubuntu 13.10 >Reporter: Thomas Beauvais > Attachments: pom.xml > > > Due to an odd necessity for different source and resource directories because > of using another IDE that can't be configued (JDeveloper). > When running the EAR plugin, I expect the to be included in the > base of the EAR file. > > src > > > .adf > > > ... > > Here is the project tree: > ./src > ./src/META-INF > ./src/META-INF/jps-config.xml > ./src/META-INF/weblogic-application.xml > ./.adf > ./.adf/META-INF > ./.adf/META-INF/adf-config.xml > ./.adf/META-INF/connections.xml > ./pom.xml > Here is the contents of the EAR: > META-INF/ > META-INF/MANIFEST.MF > META-INF/application.xml > web-0.0.1-SNAPSHOT.war > META-INF/maven/ > META-INF/maven/org.my.company/ > META-INF/maven/org.my.company/ssxa/ > META-INF/maven/org.my.company/ssxa/pom.xml > META-INF/maven/org.my.company/ssxa/pom.properties > Notice, it doesn't include either the source or the resources. I know that I > can include a but this only allows for a single > directory and I have two (.adf and src). > Attached is the pom.xml used. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-741) scm:validate for svn should offer a way to check the current directory actually matches what's declared in the pom
[ https://jira.codehaus.org/browse/SCM-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=346093#comment-346093 ] Baptiste Mathus commented on SCM-741: - Thanks a lot for the work Hervé. > scm:validate for svn should offer a way to check the current directory > actually matches what's declared in the pom > -- > > Key: SCM-741 > URL: https://jira.codehaus.org/browse/SCM-741 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-svn >Reporter: Baptiste Mathus >Assignee: Herve Boutemy > Fix For: 1.10 > > > scm:validate for svn currently only validates the URL has a good format, but > nothing about its actual validity. > The first thing that could be done is to offer a way use the svn info output, > retrieve the "URL:" line and check if it matches the > project/scm/developerConnection declaration (or one of them?). > This would be useful to the release-plugin. A lot of people already got > burned by the svn copy that would actually copy something else that the > current project content to the tag because the URL was wrong (see > MRELEASE-512 and MRELEASE-494 and MRELEASE-445 for just some examples). > Currently working on a patch for it. But if you have any feedback, I'd be > glad to hear about it. > Cheers and thanks for the work guys. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-186) Source and Resource Directories are Ignored
[
https://jira.codehaus.org/browse/MEAR-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=346104#comment-346104
]
Stéphane Nicoll edited comment on MEAR-186 at 5/12/14 6:32 AM:
---
It's not a bug, it's intentional. The only reason why this one is not closed as
won't fix (as MEAR-82) is because you have an additional requirement of having
several resource directories.
{{mvn ear:ear}} can be ran in a non-ear project (with packaging type whatever).
{{earear Source and Resource Directories are Ignored
> ---
>
> Key: MEAR-186
> URL: https://jira.codehaus.org/browse/MEAR-186
> Project: Maven Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.9
> Environment: Ubuntu 13.10
>Reporter: Thomas Beauvais
> Attachments: pom.xml
>
>
> Due to an odd necessity for different source and resource directories because
> of using another IDE that can't be configued (JDeveloper).
> When running the EAR plugin, I expect the to be included in the
> base of the EAR file.
>
> src
>
>
> .adf
>
>
> ...
>
> Here is the project tree:
> ./src
> ./src/META-INF
> ./src/META-INF/jps-config.xml
> ./src/META-INF/weblogic-application.xml
> ./.adf
> ./.adf/META-INF
> ./.adf/META-INF/adf-config.xml
> ./.adf/META-INF/connections.xml
> ./pom.xml
> Here is the contents of the EAR:
> META-INF/
> META-INF/MANIFEST.MF
> META-INF/application.xml
> web-0.0.1-SNAPSHOT.war
> META-INF/maven/
> META-INF/maven/org.my.company/
> META-INF/maven/org.my.company/ssxa/
> META-INF/maven/org.my.company/ssxa/pom.xml
> META-INF/maven/org.my.company/ssxa/pom.properties
> Notice, it doesn't include either the source or the resources. I know that I
> can include a but this only allows for a single
> directory and I have two (.adf and src).
> Attached is the pom.xml used.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNGSITE-152) Maven websites don't follow ASF rules on License
[ https://jira.codehaus.org/browse/MNGSITE-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345972#comment-345972 ] SebbASF commented on MNGSITE-152: - Example looks fine to me. > Maven websites don't follow ASF rules on License > > > Key: MNGSITE-152 > URL: https://jira.codehaus.org/browse/MNGSITE-152 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: SebbASF > Attachments: screenshot-license.png > > > ASF projects are supposed to provide a prominent link [0] to the ASF licenses > page [1] > AIUI, websites are not supposed to provide their own license pages. > [0] http://apache.org/foundation/marks/pmcs.html#navigation > [1] http://www.apache.org/licenses/ -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-186) Source and Resource Directories are Ignored
[
https://jira.codehaus.org/browse/MEAR-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=346104#comment-346104
]
Stéphane Nicoll commented on MEAR-186:
--
It's not a bug, it's intentional. The only reason why this one is not closed as
won't fix (as MEAR-82) is because you have an additional requirement of having
several resources directory.
{{mvn ear:ear}} can be ran in a non-ear project (with packaging type whatever).
{{ear Source and Resource Directories are Ignored
> ---
>
> Key: MEAR-186
> URL: https://jira.codehaus.org/browse/MEAR-186
> Project: Maven Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.9
> Environment: Ubuntu 13.10
>Reporter: Thomas Beauvais
> Attachments: pom.xml
>
>
> Due to an odd necessity for different source and resource directories because
> of using another IDE that can't be configued (JDeveloper).
> When running the EAR plugin, I expect the to be included in the
> base of the EAR file.
>
> src
>
>
> .adf
>
>
> ...
>
> Here is the project tree:
> ./src
> ./src/META-INF
> ./src/META-INF/jps-config.xml
> ./src/META-INF/weblogic-application.xml
> ./.adf
> ./.adf/META-INF
> ./.adf/META-INF/adf-config.xml
> ./.adf/META-INF/connections.xml
> ./pom.xml
> Here is the contents of the EAR:
> META-INF/
> META-INF/MANIFEST.MF
> META-INF/application.xml
> web-0.0.1-SNAPSHOT.war
> META-INF/maven/
> META-INF/maven/org.my.company/
> META-INF/maven/org.my.company/ssxa/
> META-INF/maven/org.my.company/ssxa/pom.xml
> META-INF/maven/org.my.company/ssxa/pom.properties
> Notice, it doesn't include either the source or the resources. I know that I
> can include a but this only allows for a single
> directory and I have two (.adf and src).
> Attached is the pom.xml used.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5631) WARNING about not triggered patterns in assembly descriptor
[
https://jira.codehaus.org/browse/MNG-5631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise updated MNG-5631:
-
Fix Version/s: 3.2.2
> WARNING about not triggered patterns in assembly descriptor
> ---
>
> Key: MNG-5631
> URL: https://jira.codehaus.org/browse/MNG-5631
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Bootstrap & Build
>Affects Versions: 3.2.1
> Environment: all
>Reporter: Karl-Heinz Marbaise
>Priority: Minor
> Fix For: 3.2.2
>
>
> Currently you get warnings like this:
> {code}
> [INFO] --- maven-site-plugin:3.3:attach-descriptor (attach-descriptor) @
> apache-maven ---
> [INFO]
> [INFO] --- maven-assembly-plugin:2.4:single (create-distro) @ apache-maven ---
> [INFO] Reading assembly descriptor: src/main/assembly/bin.xml
> [WARNING] The following patterns were never triggered in this artifact
> exclusion filter:
> o 'junit:junit'
> o 'commons-logging:commons-logging-api'
> [INFO] Building zip:
> /Users/kama/ws-git/apache/maven/apache-maven/target/apache-maven-3.2.2-SNAPSHOT-bin.zip
> [WARNING] The following patterns were never triggered in this artifact
> exclusion filter:
> o 'junit:junit'
> o 'commons-logging:commons-logging-api'
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5631) WARNING about not triggered patterns in assembly descriptor
Karl-Heinz Marbaise created MNG-5631:
Summary: WARNING about not triggered patterns in assembly
descriptor
Key: MNG-5631
URL: https://jira.codehaus.org/browse/MNG-5631
Project: Maven 2 & 3
Issue Type: Improvement
Components: Bootstrap & Build
Affects Versions: 3.2.1
Environment: all
Reporter: Karl-Heinz Marbaise
Priority: Minor
Currently you get warnings like this:
{code}
[INFO] --- maven-site-plugin:3.3:attach-descriptor (attach-descriptor) @
apache-maven ---
[INFO]
[INFO] --- maven-assembly-plugin:2.4:single (create-distro) @ apache-maven ---
[INFO] Reading assembly descriptor: src/main/assembly/bin.xml
[WARNING] The following patterns were never triggered in this artifact
exclusion filter:
o 'junit:junit'
o 'commons-logging:commons-logging-api'
[INFO] Building zip:
/Users/kama/ws-git/apache/maven/apache-maven/target/apache-maven-3.2.2-SNAPSHOT-bin.zip
[WARNING] The following patterns were never triggered in this artifact
exclusion filter:
o 'junit:junit'
o 'commons-logging:commons-logging-api'
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPMD-176) upgrade to last 5.0.5
[ https://jira.codehaus.org/browse/MPMD-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345934#comment-345934 ] Andrey Utis commented on MPMD-176: -- I looked at this a little bit as well, and it looks like there's a maven-enforcer-plugin rule defined in maven-parent-24.pom (parent of parent pom) that requires maxJdkVersion=1.5. I'm not really sure why maven parent pom is mandating this as the max version. Are we planning to override this for pmd plugin? > upgrade to last 5.0.5 > - > > Key: MPMD-176 > URL: https://jira.codehaus.org/browse/MPMD-176 > Project: Maven PMD Plugin > Issue Type: Bug > Components: PMD >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 3.1 > > > need a workaround to a PMD bug. > see https://github.com/apache/maven-plugins/pull/16 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5243) If a transitive dependency is missing, the error message makes it very hard to find out where it comes from
[
https://jira.codehaus.org/browse/MNG-5243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=346119#comment-346119
]
S.Leske commented on MNG-5243:
--
Also, I changed the type from "Bug" to "Improvement" - while annoying, the
current behaviour is not a bug.
> If a transitive dependency is missing, the error message makes it very hard
> to find out where it comes from
> ---
>
> Key: MNG-5243
> URL: https://jira.codehaus.org/browse/MNG-5243
> Project: Maven 2 & 3
> Issue Type: Improvement
>Reporter: S.Leske
>Priority: Minor
> Attachments: dependency-bug.tgz
>
>
> If a transitive dependency cannot be resolved during the build, the build
> fails (so far obviously OK). However, the error message printed does not
> indicate where the dependency came from. It may have been pulled in via
> several layers of transitive dependencies, in that case it is very difficult
> to figure out how it got included.
> Example:
> Project dependencies are: A -> B -> C. Error message during build of A, if C
> is missing from the repo:
> {noformat}
> [...]
> [WARNING] The POM for dependency-bug-test:C:jar:1 is missing, no
> dependency information available
> [INFO] ---
> [INFO] BUILD FAILURE
> [INFO] ---
> [...]
> [ERROR] Failed to execute goal on project A: Could not resolve dependencies
> for project dependency-bug-test:A:jar:1:
> Failure to find dependency-bug-test:C:jar:1 in
> http://repo.maven.apache.org/maven2 was cached in the local repository,
> resolution will not be reattempted until the update interval of
> central has elapsed or updates are forced -> [Help 1]
> [...]
> {noformat}
> Note the error message gives no indication whatsoever that the missing C is
> required because B depends on it. With more complex dependencies, this makes
> tracking down the culprit very difficult.
> Also note that "mvn dependency:tree" does not help in this case, because it
> fails with the same unhelpful error :-(.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5243) If a transitive dependency is missing, the error message makes it very hard to find out where it comes from
[
https://jira.codehaus.org/browse/MNG-5243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
S.Leske reopened MNG-5243:
--
Reopening, as the problem still occurs.
A complete test case is included (see attached dependency-bug.tgz), so I hope
this can be addressed.
> If a transitive dependency is missing, the error message makes it very hard
> to find out where it comes from
> ---
>
> Key: MNG-5243
> URL: https://jira.codehaus.org/browse/MNG-5243
> Project: Maven 2 & 3
> Issue Type: Bug
>Reporter: S.Leske
>Priority: Minor
> Attachments: dependency-bug.tgz
>
>
> If a transitive dependency cannot be resolved during the build, the build
> fails (so far obviously OK). However, the error message printed does not
> indicate where the dependency came from. It may have been pulled in via
> several layers of transitive dependencies, in that case it is very difficult
> to figure out how it got included.
> Example:
> Project dependencies are: A -> B -> C. Error message during build of A, if C
> is missing from the repo:
> {noformat}
> [...]
> [WARNING] The POM for dependency-bug-test:C:jar:1 is missing, no
> dependency information available
> [INFO] ---
> [INFO] BUILD FAILURE
> [INFO] ---
> [...]
> [ERROR] Failed to execute goal on project A: Could not resolve dependencies
> for project dependency-bug-test:A:jar:1:
> Failure to find dependency-bug-test:C:jar:1 in
> http://repo.maven.apache.org/maven2 was cached in the local repository,
> resolution will not be reattempted until the update interval of
> central has elapsed or updates are forced -> [Help 1]
> [...]
> {noformat}
> Note the error message gives no indication whatsoever that the missing C is
> required because B depends on it. With more complex dependencies, this makes
> tracking down the culprit very difficult.
> Also note that "mvn dependency:tree" does not help in this case, because it
> fails with the same unhelpful error :-(.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5632) Optional tag in dependencyManagement not inherited - disallow and/or document
S.Leske created MNG-5632:
Summary: Optional tag in dependencyManagement not inherited -
disallow and/or document
Key: MNG-5632
URL: https://jira.codehaus.org/browse/MNG-5632
Project: Maven 2 & 3
Issue Type: Improvement
Affects Versions: 3.2.1, 3.1.1
Reporter: S.Leske
Priority: Minor
As explained in MNG-1630 adn MNG-4600, specifying
{code}
true
{code}
in dependencyManagement has no effect. "optional" only takes effect when
specified directly in the "dependencies" section of the POM.
However, this is not documented anywhere, and rather unexpected, because both
version and scope can be set from dependencyManagement.
If the current behaviour is intentional, it should be documented. Ideally,
Maven should also disallow the use of "" in dependencyManagement (or
at least issue a warning).
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5243) If a transitive dependency is missing, the error message makes it very hard to find out where it comes from
[
https://jira.codehaus.org/browse/MNG-5243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
S.Leske updated MNG-5243:
-
Issue Type: Improvement (was: Bug)
> If a transitive dependency is missing, the error message makes it very hard
> to find out where it comes from
> ---
>
> Key: MNG-5243
> URL: https://jira.codehaus.org/browse/MNG-5243
> Project: Maven 2 & 3
> Issue Type: Improvement
>Reporter: S.Leske
>Priority: Minor
> Attachments: dependency-bug.tgz
>
>
> If a transitive dependency cannot be resolved during the build, the build
> fails (so far obviously OK). However, the error message printed does not
> indicate where the dependency came from. It may have been pulled in via
> several layers of transitive dependencies, in that case it is very difficult
> to figure out how it got included.
> Example:
> Project dependencies are: A -> B -> C. Error message during build of A, if C
> is missing from the repo:
> {noformat}
> [...]
> [WARNING] The POM for dependency-bug-test:C:jar:1 is missing, no
> dependency information available
> [INFO] ---
> [INFO] BUILD FAILURE
> [INFO] ---
> [...]
> [ERROR] Failed to execute goal on project A: Could not resolve dependencies
> for project dependency-bug-test:A:jar:1:
> Failure to find dependency-bug-test:C:jar:1 in
> http://repo.maven.apache.org/maven2 was cached in the local repository,
> resolution will not be reattempted until the update interval of
> central has elapsed or updates are forced -> [Help 1]
> [...]
> {noformat}
> Note the error message gives no indication whatsoever that the missing C is
> required because B depends on it. With more complex dependencies, this makes
> tracking down the culprit very difficult.
> Also note that "mvn dependency:tree" does not help in this case, because it
> fails with the same unhelpful error :-(.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSITE-712) maven-site-plugin generates incorrect git -tag command
Martin Gainty created MSITE-712:
---
Summary: maven-site-plugin generates incorrect git -tag command
Key: MSITE-712
URL: https://jira.codehaus.org/browse/MSITE-712
Project: Maven Site Plugin
Issue Type: Bug
Components: multi module
Affects Versions: 3.3
Environment: maven 3.0.2
jdk 1.7
Reporter: Martin Gainty
Priority: Trivial
/*commit pom.xml */
Executing: /bin/sh -c cd "/opt/jenkins-home/jobs/Section
4362/workspace/section4362-parent" && git commit --verbose -F
/tmp/maven-scm-217365030.commit '/opt/jenkins-home/jobs/Section
4362/workspace/section4362-services/pom.xml' '/opt/jenkins-home/jobs/Section
4362/workspace/section4362-webapp/pom.xml' '/opt/jenkins-home/jobs/Section
4362/workspace/section4362-static/pom.xml' pom.xml
/*commit to HEAD */
> [INFO] Working directory: /opt/jenkins-home/jobs/Section
> 4362/workspace/section4362-parent
> [INFO] Executing: /bin/sh -c cd "/opt/jenkins-home/jobs/Section
> 4362/workspace/section4362-parent" && git symbolic-ref HEAD
> [INFO] Working directory: /opt/jenkins-home/jobs/Section
> 4362/workspace/section4362-parent
> [INFO] Executing: /bin/sh -c cd "/opt/jenkins-home/jobs/Section
> 4362/workspace/section4362-parent" && git push
> ssh://g...@github.com/{org}/Section4362.git
> maven-release-test:maven-release-test
> [INFO] Working directory: /opt/jenkins-home/jobs/Section
> 4362/workspace/section4362-parent
> [INFO] Tagging release with the label section4362-parent-0.3...
> [INFO] Executing: /bin/sh -c cd "/opt/jenkins-home/jobs/Section
> 4362/workspace" && git tag -F /tmp/maven-scm-882610155.commit
> section4362-parent-0.3
/*-a, -s, and -u are absent, -a is implied. so -a should have been
supplied but was not so we'll bypass this for now */
/*
The name of the tag to create, delete, or describe. The new tag name must pass
ALL checks defined by git-check-ref-format(1). Some of these checks may
restrict the characters allowed in a tag name.
*/
since tagname is missing
the generated git tag command doesnt know the name of what to commit to in
refs/tags/
(refs/tags/$tagname is used unless -d/-l/-v is given to delete, list or verify
tags.)
temp workaround is to commit everything at command line to git
then use maven-site-plugin
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5630) improve display of forked executions
[
https://jira.codehaus.org/browse/MNG-5630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=346142#comment-346142
]
Herve Boutemy commented on MNG-5630:
I understand your point
I'm convincend this information on what *is* forked is even more useful at INFO
level that what *has* forked
perhaps we can remove the mojoExecutionId (ie "(report:aggregate)" in the
example) since it will be displayed when running the mojo?
> improve display of forked executions
>
>
> Key: MNG-5630
> URL: https://jira.codehaus.org/browse/MNG-5630
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.1
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
> Fix For: 3.2.2
>
>
> actually, we have
> {noformat}[INFO]
> [INFO] >>> maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) @
> forked-lifecycle >>>
> [INFO]
> [INFO] <<< maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) @
> forked-lifecycle <<<{noformat}
> it doesn't tell what is the forked goal or phase, which would be useful
> proposed new format in case of phase:
> {noformat}[INFO]
> [INFO] >>> maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) >
> [optional lifecycle]generate-sources @ forked-lifecycle >>>
> [INFO]
> [INFO] <<< maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) <
> [optional lifecycle]generate-sources @ forked-lifecycle <<<{noformat}
> and in case of goal:
> proposed new format in case of phase:
> {noformat}[INFO]
> [INFO] >>> maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) > :goal @
> forked-lifecycle >>>
> [INFO]
> [INFO] <<< maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) < :goal @
> forked-lifecycle <<<{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHARED-266) run aggregator reports only when current projet is pom packaging and has modules
[ https://jira.codehaus.org/browse/MSHARED-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=346141#comment-346141 ] Herve Boutemy commented on MSHARED-266: --- glad to know you appreciate :) it was frustrating not to understand > run aggregator reports only when current projet is pom packaging and has > modules > > > Key: MSHARED-266 > URL: https://jira.codehaus.org/browse/MSHARED-266 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-reporting-exec >Affects Versions: maven-reporting-exec-1.0.2 >Reporter: Herve Boutemy >Assignee: Herve Boutemy > Fix For: maven-reporting-exec-1.2 > > > would fix MSITE-454 > simply adding a plugin to reporting section, without defining any reportSets, > will avoid running aggregate reports in every module > notice: this will work only with Maven 3, since Maven 2 runs reports from > core and not from m-site-p/m-reporting-exec -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5631) WARNING about not triggered patterns in assembly descriptor
[
https://jira.codehaus.org/browse/MNG-5631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise closed MNG-5631.
Resolution: Fixed
Assignee: Karl-Heinz Marbaise
Fixed in
[550966dfa711417b9c355a37941869182ef0fb24|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=550966dfa711417b9c355a37941869182ef0fb24]
> WARNING about not triggered patterns in assembly descriptor
> ---
>
> Key: MNG-5631
> URL: https://jira.codehaus.org/browse/MNG-5631
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Bootstrap & Build
>Affects Versions: 3.2.1
> Environment: all
>Reporter: Karl-Heinz Marbaise
>Assignee: Karl-Heinz Marbaise
>Priority: Minor
> Fix For: 3.2.2
>
>
> Currently you get warnings like this:
> {code}
> [INFO] --- maven-site-plugin:3.3:attach-descriptor (attach-descriptor) @
> apache-maven ---
> [INFO]
> [INFO] --- maven-assembly-plugin:2.4:single (create-distro) @ apache-maven ---
> [INFO] Reading assembly descriptor: src/main/assembly/bin.xml
> [WARNING] The following patterns were never triggered in this artifact
> exclusion filter:
> o 'junit:junit'
> o 'commons-logging:commons-logging-api'
> [INFO] Building zip:
> /Users/kama/ws-git/apache/maven/apache-maven/target/apache-maven-3.2.2-SNAPSHOT-bin.zip
> [WARNING] The following patterns were never triggered in this artifact
> exclusion filter:
> o 'junit:junit'
> o 'commons-logging:commons-logging-api'
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-396) @author tag added to header instead of above class declaration
Kevin S. Clarke created MJAVADOC-396:
Summary: @author tag added to header instead of above class
declaration
Key: MJAVADOC-396
URL: https://jira.codehaus.org/browse/MJAVADOC-396
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.9.1
Environment: Linux ksclarke-laptop 3.13.0-18-generic #38-Ubuntu SMP
Mon Mar 17 21:40:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
java version "1.7.0_55"
OpenJDK Runtime Environment (IcedTea 2.4.7) (7u55-2.4.7-1ubuntu1)
OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)
Reporter: Kevin S. Clarke
When running the following command:
mvn javadoc:test-fix -Dforce=true -DfixMethodComment=false
-DfixFieldComment=false -DfixTags=author -DdefaultAuthor=ksclarke
-Dincludes=**/RdfLexiconTest.java
The expectation is that the @author tag will be added to a Javadoc comment
above the class declaration. The result is that the @author tag is added to
the header (which is in a Javadoc comment) rather than a Javadoc comment above
the class declaration.
This is an example of what our files look like:
/**
* Copyright 2014 DuraSpace, Inc.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*
*/
package org.fcrepo.kernel;
import static org.junit.Assert.assertTrue;
import org.junit.Test;
public class RdfLexiconTest {
[...]
}
Changing our header notice to use slash-asterisk style:
/*
*
*/
instead of Javadoc style "solves" the problem and the @author is added in the
right place. Fwiw, we use the license-maven-plugin to generate our headers.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNGSITE-152) Maven websites don't follow ASF rules on License
[ https://jira.codehaus.org/browse/MNGSITE-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345968#comment-345968 ] Karl-Heinz Marbaise commented on MNGSITE-152: - Hi, can you check the example site which Hervé has created: http://maven.apache.org/plugins-archives/maven-scm-publish-plugin-LATEST/ WDYT ? > Maven websites don't follow ASF rules on License > > > Key: MNGSITE-152 > URL: https://jira.codehaus.org/browse/MNGSITE-152 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: SebbASF > Attachments: screenshot-license.png > > > ASF projects are supposed to provide a prominent link [0] to the ASF licenses > page [1] > AIUI, websites are not supposed to provide their own license pages. > [0] http://apache.org/foundation/marks/pmcs.html#navigation > [1] http://www.apache.org/licenses/ -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-741) scm:validate for svn should offer a way to check the current directory actually matches what's declared in the pom
[ https://jira.codehaus.org/browse/SCM-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=346143#comment-346143 ] Herve Boutemy commented on SCM-741: --- team working: everybody brings his own piece :) > scm:validate for svn should offer a way to check the current directory > actually matches what's declared in the pom > -- > > Key: SCM-741 > URL: https://jira.codehaus.org/browse/SCM-741 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-svn >Reporter: Baptiste Mathus >Assignee: Herve Boutemy > Fix For: 1.10 > > > scm:validate for svn currently only validates the URL has a good format, but > nothing about its actual validity. > The first thing that could be done is to offer a way use the svn info output, > retrieve the "URL:" line and check if it matches the > project/scm/developerConnection declaration (or one of them?). > This would be useful to the release-plugin. A lot of people already got > burned by the svn copy that would actually copy something else that the > current project content to the tag because the URL was wrong (see > MRELEASE-512 and MRELEASE-494 and MRELEASE-445 for just some examples). > Currently working on a patch for it. But if you have any feedback, I'd be > glad to hear about it. > Cheers and thanks for the work guys. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSITE-712) maven-site-plugin generates incorrect git -tag command
[
https://jira.codehaus.org/browse/MSITE-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=346150#comment-346150
]
Dennis Lundberg commented on MSITE-712:
---
Hi Martin
We need to see more parts of the log to be able to help you. Specifically the
Maven command line that Jenkins runs and the lines just before the part that
you included, that shows what plugin has run.
This issue is not related to the site plugin, but probably the release plugin.
Do you use the release plugin?
> maven-site-plugin generates incorrect git -tag command
> --
>
> Key: MSITE-712
> URL: https://jira.codehaus.org/browse/MSITE-712
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 3.3
> Environment: maven 3.0.2
> jdk 1.7
>Reporter: Martin Gainty
>Priority: Trivial
>
> /*commit pom.xml */
> Executing: /bin/sh -c cd "/opt/jenkins-home/jobs/Section
> 4362/workspace/section4362-parent" && git commit --verbose -F
> /tmp/maven-scm-217365030.commit '/opt/jenkins-home/jobs/Section
> 4362/workspace/section4362-services/pom.xml' '/opt/jenkins-home/jobs/Section
> 4362/workspace/section4362-webapp/pom.xml' '/opt/jenkins-home/jobs/Section
> 4362/workspace/section4362-static/pom.xml' pom.xml
> /*commit to HEAD */
> > [INFO] Working directory: /opt/jenkins-home/jobs/Section
> > 4362/workspace/section4362-parent
> > [INFO] Executing: /bin/sh -c cd "/opt/jenkins-home/jobs/Section
> > 4362/workspace/section4362-parent" && git symbolic-ref HEAD
> > [INFO] Working directory: /opt/jenkins-home/jobs/Section
> > 4362/workspace/section4362-parent
> > [INFO] Executing: /bin/sh -c cd "/opt/jenkins-home/jobs/Section
> > 4362/workspace/section4362-parent" && git push
> > ssh://g...@github.com/{org}/Section4362.git
> > maven-release-test:maven-release-test
> > [INFO] Working directory: /opt/jenkins-home/jobs/Section
> > 4362/workspace/section4362-parent
> > [INFO] Tagging release with the label section4362-parent-0.3...
> > [INFO] Executing: /bin/sh -c cd "/opt/jenkins-home/jobs/Section
> > 4362/workspace" && git tag -F /tmp/maven-scm-882610155.commit
> > section4362-parent-0.3
> /*-a, -s, and -u are absent, -a is implied. so -a should have been
> supplied but was not so we'll bypass this for now */
> /*
> The name of the tag to create, delete, or describe. The new tag name must
> pass ALL checks defined by git-check-ref-format(1). Some of these checks may
> restrict the characters allowed in a tag name.
> */
> since tagname is missing
> the generated git tag command doesnt know the name of what to commit to in
> refs/tags/
> (refs/tags/$tagname is used unless -d/-l/-v is given to delete, list or
> verify tags.)
> temp workaround is to commit everything at command line to git
> then use maven-site-plugin
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5630) improve display of forked executions
[
https://jira.codehaus.org/browse/MNG-5630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=346151#comment-346151
]
Michael Osipov commented on MNG-5630:
-
Hervè, this might be better, yes. Are you able to produce a real world example
on the Maven master with the changes to visualize the new ouput? That would
ease the discussion.
> improve display of forked executions
>
>
> Key: MNG-5630
> URL: https://jira.codehaus.org/browse/MNG-5630
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.1
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
> Fix For: 3.2.2
>
>
> actually, we have
> {noformat}[INFO]
> [INFO] >>> maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) @
> forked-lifecycle >>>
> [INFO]
> [INFO] <<< maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) @
> forked-lifecycle <<<{noformat}
> it doesn't tell what is the forked goal or phase, which would be useful
> proposed new format in case of phase:
> {noformat}[INFO]
> [INFO] >>> maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) >
> [optional lifecycle]generate-sources @ forked-lifecycle >>>
> [INFO]
> [INFO] <<< maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) <
> [optional lifecycle]generate-sources @ forked-lifecycle <<<{noformat}
> and in case of goal:
> proposed new format in case of phase:
> {noformat}[INFO]
> [INFO] >>> maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) > :goal @
> forked-lifecycle >>>
> [INFO]
> [INFO] <<< maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) < :goal @
> forked-lifecycle <<<{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5630) improve display of forked executions
[
https://jira.codehaus.org/browse/MNG-5630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-5630:
Description:
Currently we have
{noformat}[INFO]
[INFO] >>> maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) @
forked-lifecycle >>>
[INFO]
[INFO] <<< maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) @
forked-lifecycle <<<{noformat}
it doesn't tell what is the forked goal or phase, which would be useful
proposed new format in case of phase:
{noformat}[INFO]
[INFO] >>> maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) > [optional
lifecycle]generate-sources @ forked-lifecycle >>>
[INFO]
[INFO] <<< maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) < [optional
lifecycle]generate-sources @ forked-lifecycle <<<{noformat}
and in case of goal:
proposed new format in case of phase:
{noformat}[INFO]
[INFO] >>> maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) > :goal @
forked-lifecycle >>>
[INFO]
[INFO] <<< maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) < :goal @
forked-lifecycle <<<{noformat}
was:
actually, we have
{noformat}[INFO]
[INFO] >>> maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) @
forked-lifecycle >>>
[INFO]
[INFO] <<< maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) @
forked-lifecycle <<<{noformat}
it doesn't tell what is the forked goal or phase, which would be useful
proposed new format in case of phase:
{noformat}[INFO]
[INFO] >>> maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) > [optional
lifecycle]generate-sources @ forked-lifecycle >>>
[INFO]
[INFO] <<< maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) < [optional
lifecycle]generate-sources @ forked-lifecycle <<<{noformat}
and in case of goal:
proposed new format in case of phase:
{noformat}[INFO]
[INFO] >>> maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) > :goal @
forked-lifecycle >>>
[INFO]
[INFO] <<< maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) < :goal @
forked-lifecycle <<<{noformat}
> improve display of forked executions
>
>
> Key: MNG-5630
> URL: https://jira.codehaus.org/browse/MNG-5630
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.1
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
> Fix For: 3.2.2
>
>
> Currently we have
> {noformat}[INFO]
> [INFO] >>> maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) @
> forked-lifecycle >>>
> [INFO]
> [INFO] <<< maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) @
> forked-lifecycle <<<{noformat}
> it doesn't tell what is the forked goal or phase, which would be useful
> proposed new format in case of phase:
> {noformat}[INFO]
> [INFO] >>> maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) >
> [optional lifecycle]generate-sources @ forked-lifecycle >>>
> [INFO]
> [INFO] <<< maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) <
> [optional lifecycle]generate-sources @ forked-lifecycle <<<{noformat}
> and in case of goal:
> proposed new format in case of phase:
> {noformat}[INFO]
> [INFO] >>> maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) > :goal @
> forked-lifecycle >>>
> [INFO]
> [INFO] <<< maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) < :goal @
> forked-lifecycle <<<{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
