[jira] (SUREFIRE-900) System.err seems to be ignored
[ https://jira.codehaus.org/browse/SUREFIRE-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305857#comment-305857 ] Marco Brandizi commented on SUREFIRE-900: - Thanks for your reply. System.setErr() solved my specific problem. In general, it's strange for me that one cannot do something as easy as mvn test 2>/dev/null and see just the standard output, not the standard error, which might give non-useful information in certain situations. But OK, I can live with that. > System.err seems to be ignored > -- > > Key: SUREFIRE-900 > URL: https://jira.codehaus.org/browse/SUREFIRE-900 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.7.2 > Environment: OS/X 10.7.4 >Reporter: Marco Brandizi >Assignee: Kristian Rosenvold >Priority: Minor > Attachments: testSureFireStdErr.zip > > > See the attached project. If I send something to System.err from a JUnit test > and then I try 'mvn test 2>/dev/null', I can still see the output on the > console, surefire (or Maven?!) seems to ignore this. I've tried with > -Dsurefire.forkMode=false too. Is it possible to redirect the standard error? > I'd like to do that because I have a few tests that tests a line command (ie, > main()). Since the command is supposed to return XML to the invoker (which, > for example, might pipe it to another command), I've implemented this command > line by sending all the logging output to System.err (that's possible in > Logback via the 'Target' option in the Console appender). When I invoke this > line command outside Maven/Surefire it works as I want. In Maven, instead, I > cannot what I described. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4226) Better detection of JAVA_HOME on Apple Mac OS X
[
https://jira.codehaus.org/browse/MNG-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Elliot updated MNG-4226:
Attachment: MNG-4226-apache-maven.patch
Patch to fix java version detection on OS/X so that it uses the standard Java
Preferences mechanism rather than always using Java 6.
> Better detection of JAVA_HOME on Apple Mac OS X
> ---
>
> Key: MNG-4226
> URL: https://jira.codehaus.org/browse/MNG-4226
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Command Line
>Reporter: Alin Dreghiciu
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: MNG-4226-apache-maven.patch
>
>
> On mac JAVA_HOME is detected by using the following code:
> {code}
>if [ -z "$JAVA_VERSION" ] ; then
> JAVA_VERSION="CurrentJDK"
>else
> echo "Using Java version: $JAVA_VERSION"
>fi
>if [ -z "$JAVA_HOME" ] ; then
>
> JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/${JAVA_VERSION}/Home
>fi
> {code}
> But this does not work in collaboration with Using "Java preferences" to
> change the actual java version to use as "CurrentJDK" does not change once
> you update the "java applications" order.
> There is an alternative (at least on Leopard) for determining current java
> home that is based on Java Preferences by using an apple provided script. So,
> as a replacement fo rthe code above the following could be used.
> {code}
>if [ -z "$JAVA_HOME" ] ; then
> JAVA_HOME=`/usr/libexec/java_home | tail -1`
>fi
> {code}
> Could also be taht this is teh first attempt and if fails use the current way
> of determining home.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4226) Better detection of JAVA_HOME on Apple Mac OS X
[
https://jira.codehaus.org/browse/MNG-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305856#comment-305856
]
Rob Elliot commented on MNG-4226:
-
I just wasted an evening trying to establish why setting the preferred Java
version to Java 7 in Mac's Java Preferences still left Maven using Java 6, due
to this issue. Ant does it the right way, via /usr/libexec/java_home.
Attached is a patch.
> Better detection of JAVA_HOME on Apple Mac OS X
> ---
>
> Key: MNG-4226
> URL: https://jira.codehaus.org/browse/MNG-4226
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Command Line
>Reporter: Alin Dreghiciu
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: MNG-4226-apache-maven.patch
>
>
> On mac JAVA_HOME is detected by using the following code:
> {code}
>if [ -z "$JAVA_VERSION" ] ; then
> JAVA_VERSION="CurrentJDK"
>else
> echo "Using Java version: $JAVA_VERSION"
>fi
>if [ -z "$JAVA_HOME" ] ; then
>
> JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/${JAVA_VERSION}/Home
>fi
> {code}
> But this does not work in collaboration with Using "Java preferences" to
> change the actual java version to use as "CurrentJDK" does not change once
> you update the "java applications" order.
> There is an alternative (at least on Leopard) for determining current java
> home that is based on Java Preferences by using an apple provided script. So,
> as a replacement fo rthe code above the following could be used.
> {code}
>if [ -z "$JAVA_HOME" ] ; then
> JAVA_HOME=`/usr/libexec/java_home | tail -1`
>fi
> {code}
> Could also be taht this is teh first attempt and if fails use the current way
> of determining home.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPIR-248) NPE while DependenciesReport
[
https://jira.codehaus.org/browse/MPIR-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tony Chemit closed MPIR-248.
Resolution: Fixed
Fix Version/s: 2.6
System scope dependencies with no artifact file were not exclude.
[Fixed in rev 1370872|http://svn.apache.org/viewvc?rev=1370872&view=rev]
> NPE while DependenciesReport
>
>
> Key: MPIR-248
> URL: https://jira.codehaus.org/browse/MPIR-248
> Project: Maven 2.x Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 2.5
>Reporter: Tony Chemit
>Assignee: Tony Chemit
>Priority: Blocker
> Fix For: 2.6
>
>
> See trace {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails(Dependencies.java:243)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed(DependenciesRenderer.java:1453)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails(DependenciesRenderer.java:547)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:274)
> at
> org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:79)
> at
> org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:186)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPIR-248) NPE while DependenciesReport
[
https://jira.codehaus.org/browse/MPIR-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tony Chemit reassigned MPIR-248:
Assignee: Tony Chemit
> NPE while DependenciesReport
>
>
> Key: MPIR-248
> URL: https://jira.codehaus.org/browse/MPIR-248
> Project: Maven 2.x Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 2.5
>Reporter: Tony Chemit
>Assignee: Tony Chemit
>Priority: Blocker
>
> See trace {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails(Dependencies.java:243)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed(DependenciesRenderer.java:1453)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails(DependenciesRenderer.java:547)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:274)
> at
> org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:79)
> at
> org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:186)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPIR-248) NPE while DependenciesReport
[
https://jira.codehaus.org/browse/MPIR-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tony Chemit updated MPIR-248:
-
Description:
See trace {code}
Caused by: java.lang.NullPointerException
at
org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails(Dependencies.java:243)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed(DependenciesRenderer.java:1453)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails(DependenciesRenderer.java:547)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:274)
at
org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:79)
at
org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:186)
{code}
was:
See trace {code}
Caused by: java.lang.NullPointerException
at
org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails(Dependencies.java:243)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed(DependenciesRenderer.java:1453)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails(DependenciesRenderer.java:547)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:274)
at
org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:79)
at
org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:186)
{code}
Priority: Blocker (was: Major)
> NPE while DependenciesReport
>
>
> Key: MPIR-248
> URL: https://jira.codehaus.org/browse/MPIR-248
> Project: Maven 2.x Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 2.5
>Reporter: Tony Chemit
>Priority: Blocker
>
> See trace {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails(Dependencies.java:243)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed(DependenciesRenderer.java:1453)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails(DependenciesRenderer.java:547)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:274)
> at
> org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:79)
> at
> org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:186)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPIR-248) NPE while DependenciesReport
[
https://jira.codehaus.org/browse/MPIR-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305838#comment-305838
]
Tony Chemit commented on MPIR-248:
--
With version 2.4, the problem does not occurs.
I will add a test for this, but I blame commit at first glance [commit
1103555|http://svn.apache.org/viewvc?rev=1103555&view=rev]
> NPE while DependenciesReport
>
>
> Key: MPIR-248
> URL: https://jira.codehaus.org/browse/MPIR-248
> Project: Maven 2.x Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 2.5
>Reporter: Tony Chemit
>
> See trace {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails(Dependencies.java:243)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed(DependenciesRenderer.java:1453)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails(DependenciesRenderer.java:547)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:274)
> at
> org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:79)
> at
> org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:186)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPIR-248) NPE while DependenciesReport
Tony Chemit created MPIR-248:
Summary: NPE while DependenciesReport
Key: MPIR-248
URL: https://jira.codehaus.org/browse/MPIR-248
Project: Maven 2.x Project Info Reports Plugin
Issue Type: Bug
Components: dependencies
Affects Versions: 2.5
Reporter: Tony Chemit
See trace {code}
Caused by: java.lang.NullPointerException
at
org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails(Dependencies.java:243)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed(DependenciesRenderer.java:1453)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails(DependenciesRenderer.java:547)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:274)
at
org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:79)
at
org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:186)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRESOURCES-159) Error loading property file: 'D:\my-ins\src\main\filters\filter.properties'
[ https://jira.codehaus.org/browse/MRESOURCES-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MRESOURCES-159. -- Resolution: Incomplete No feedback from user. > Error loading property file: 'D:\my-ins\src\main\filters\filter.properties' > --- > > Key: MRESOURCES-159 > URL: https://jira.codehaus.org/browse/MRESOURCES-159 > Project: Maven 2.x Resources Plugin > Issue Type: Bug >Reporter: finstechj > > I've deployed filtering files named "filter.properties" in the filters > directory. When I execute the command "process-resources", the console > indicates that " Failed to execute goal > org.apache.maven.plugins:maven-resources-plugin ", Error loading property > file. > In the first place I presume it comes to the version issue, or the location > of the default local repository, but I still could not make it.Three errors > as follows: > 1,Caused by: org.apache.maven.plugin.MojoExecutionException: Error loading > propert > y file 'D:\my-ins\src\main\filters\filter.properties' > 2,Caused by: org.apache.maven.shared.filtering.MavenFilteringException: > 3,Caused by: java.io.FileNotFoundException: > D:\my-ins\src\main\filters\filter.prop > erties > Any suggestions? Thanks a lot. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRESOURCES-161) Some incorrect HTML in the description of the delimiters parameter
[ https://jira.codehaus.org/browse/MRESOURCES-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MRESOURCES-161. -- Resolution: Fixed Fix Version/s: 2.6 Assignee: Dennis Lundberg Fixed in [r1370795|http://svn.apache.org/viewvc?view=revision&revision=1370795]. > Some incorrect HTML in the description of the delimiters parameter > -- > > Key: MRESOURCES-161 > URL: https://jira.codehaus.org/browse/MRESOURCES-161 > Project: Maven 2.x Resources Plugin > Issue Type: Improvement > Components: delimiters >Affects Versions: 2.5 > Environment: Eclipse Indigo, build 20110916-0149 > Eclipse M2E plugin version 1.0.100.20110804-1717 >Reporter: Maarten van Schouwen >Assignee: Dennis Lundberg >Priority: Trivial > Fix For: 2.6 > > > The description of the delimiters parameter contains entities, < etc., > to render a POM fragment as an example, but some of these entities are > written as "<" instead of "<". > If you're editing a POM file in Eclipse with the M2E plugin, the description > shows this as "@</delimiter>", which looks bad. In the > command line, through "mvn resources:help", everything looks OK. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MECLIPSE-730) Support creation of Android project with "mvn eclipse:eclipse"
Andreas Schildbach created MECLIPSE-730: --- Summary: Support creation of Android project with "mvn eclipse:eclipse" Key: MECLIPSE-730 URL: https://jira.codehaus.org/browse/MECLIPSE-730 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Reporter: Andreas Schildbach Currently it's a pita to manually correct all the problems a "mvn eclipse:eclipse" creates on Android projects. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-2205) "provided" scope dependencies must be transitive
[
https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305822#comment-305822
]
David Boden commented on MNG-2205:
--
For what it's worth, I no longer agree with this issue that I started 6 years
ago! I have a best-practice document which I apply to my projects and have
pasted here in this comment. Under this strategy, I always declare compile-time
dependencies in any project that has an import; statement referring to the
class. I don't rely on transitive dependencies when I'm actually using a
dependency for compilation. I think this is what the Maven authors intended,
which is why "provided" has stayed like it is for such a long time.
1. in parent pom
Declare the versions for all dependencies in the project's parent pom using the
section. You're setting the versions that will be used
if the submodules decide to declare dependencies. Using dependency management
ensures that the version of all of your dependencies is entirely consistent
across all your sub-projects. This is especially important if you're creating a
single deployment consisting of many of these sub-modules and you are going to
deploy one set of dependency jars
Declare few or no dependencies in the section of the parent
pom. It's fair to assume that all your projects will depend on JUnit and a
logging framework so you may want to add those. Anything else results in
unnecessary dependencies making their way into your sub-projects.
It's not too useful to declare versions at an even higher level (e.g. the pom
that's the parent of all your projects) but in some cases it can make life
easier.
Failing to add a dependencyManagement section results in a classic problem of
scripts being generated in sub-projects which reference jar versions that don't
end up being packaged in the final assemby's lib folder.
2. Declare dependencies where you use them - don't rely on transitive
dependencies
Transitive dependencies are very useful. If you're using the public API of a
library in your code then you shouldn't have to care how its internals work.
Your sub-project should declare a dependency on the library that your code is
using; Maven will helpfully pull in the library's transitive dependencies. The
library is free to change how its internals work and what transitive
dependencies it declares for each version.
If you're using a library, you should declare it in the section
of your pom. Don't rely on transitive dependencies. If your Java code (or
Spring config; that's code too) uses commons-beanutils then you should declare
that dependency. If you don't, your build is brittle; internal changes to other
components can break your component's build.
Run:
mvn dependency:analyze
This tool will tell you about artifacts that you've failed to declare
dependencies for and will also tell you if you have extra dependencies declared
that you don't need. Be careful about dependencies that you don't use in your
.java files; the dependency plugin is only scanning those. If you use a class
in Spring config then you do really need it, even if the dependency plugin is
telling you that you don't. In these cases I find it useful to make sure that
the dependency is set to runtime. That way, when I get the
dependency:analyze report telling me that these are extra dependencies I know
that I probably set them to runtime because they're used by spring config. I
ignore the runtime dependencies and only weed out the compile scope ones.
3. Use sparingly (in the parent pom)
Declaring all dependency versions in properties and then using those properties
in the section is a little like the (bad) practice of
unnecessarily declaring all your Java variables right at the top of a method.
When there's a single artifact to configure, favour hardcoding the version into
the 1.0 tag.
Use properties when there are multiple artifacts to control. For example, set:
3.1.1.RELEASE
and then use:
${spring.version}
for artifacts like spring-core
Properties are public, not private. When you declare a property in the parent
pom, it's available anywhere in the build. Adding a property pollutes the
(build) environment.
4. Use the enforcer plugin to guard against old or unwanted dependencies
The enforcer plugin can fail your build based on duplicate classes found (the
same classes in more than one jar file on the build classpath) or can allow you
to ban old or unwanted dependencies. This is especially useful when the owner
of a library has changed the groupId or artifactId of their artifact. This
stops the Maven dependency mechanism from picking the latest version; you'll
end up with 2 similar artifacts on the classpath. For example, from Spring 2 to
Spring 3 they changed an artifactId from spring to spring-core. Without banning
the older spring dependency, it can easily transitively creep back onto your
classpath. Then when you
[jira] (MSHARED-234) fileset.mdo missing xmlns
tradej created MSHARED-234: -- Summary: fileset.mdo missing xmlns Key: MSHARED-234 URL: https://jira.codehaus.org/browse/MSHARED-234 Project: Maven Shared Components Issue Type: Bug Components: file-management Affects Versions: file-management-1.2.1 Environment: modello 1.5 Reporter: tradej Attachments: 0001-Added-xmlns.patch When building with Maven 3, Modello gives me this error: [ERROR] /builddir/build/BUILD/file-management-1.2.1/src/main/mdo/fileset.mdo [1:1]: Error generating: Cannot generate xsd without xmlns specification: or org.apache.maven.plugin.MojoExecutionException: Error generating: Cannot generate xsd without xmlns specification: or Please, include a xmlns specification in the file. A patch is attached for your convenience. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5323) Add ability to interrupt a build with SUCCESS status from maven plugins.
[ https://jira.codehaus.org/browse/MNG-5323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Tyurikov updated MNG-5323: Attachment: build_succeed_exception.patch A whip up patch demonstrated the idea is attached. > Add ability to interrupt a build with SUCCESS status from maven plugins. > > > Key: MNG-5323 > URL: https://jira.codehaus.org/browse/MNG-5323 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: General, Plugin API >Affects Versions: 3.0.5 > Environment: any >Reporter: Stanislav Tyurikov >Priority: Critical > Attachments: build_succeed_exception.patch > > > Add ability to successfully finish a build from maven plugin. It can help to > create maven plugins for build optimization. Currently we can interrupt a > build only to fail it (by throwing an exception from the execute method of a > mojo). > This functionality can be easily implemented by adding BuildSuccessException > to the maven core and modifying LifecycleModuleBuilder and > DefaultBuildPluginManager to process this exception and finish the build as > succeed. Any custom maven plugin can throw BuildSuccessException to indicate > the build is OK and no further steps are needed to be executed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5323) Add ability to interrupt a build with SUCCESS status from maven plugins.
Stanislav Tyurikov created MNG-5323: --- Summary: Add ability to interrupt a build with SUCCESS status from maven plugins. Key: MNG-5323 URL: https://jira.codehaus.org/browse/MNG-5323 Project: Maven 2 & 3 Issue Type: Improvement Components: General, Plugin API Affects Versions: 3.0.5 Environment: any Reporter: Stanislav Tyurikov Priority: Critical Add ability to successfully finish a build from maven plugin. It can help to create maven plugins for build optimization. Currently we can interrupt a build only to fail it (by throwing an exception from the execute method of a mojo). This functionality can be easily implemented by adding BuildSuccessException to the maven core and modifying LifecycleModuleBuilder and DefaultBuildPluginManager to process this exception and finish the build as succeed. Any custom maven plugin can throw BuildSuccessException to indicate the build is OK and no further steps are needed to be executed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-2205) "provided" scope dependencies must be transitive
[ https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305819#comment-305819 ] Sergey commented on MNG-2205: - Issue has been created: 06/Apr/06 5:37 AM 6 years old!!! Should be already fixed. > "provided" scope dependencies must be transitive > > > Key: MNG-2205 > URL: https://jira.codehaus.org/browse/MNG-2205 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: David Boden >Priority: Critical > Fix For: 3.x / Backlog > > Attachments: transitivetest.zip > > > A provided scope dependency can also be thought of as "compile-only". > Project A requires Sybase JConnect on the runtime classpath. Project A > declares a "provided" dependency on Sybase JConnect. > Project B depends upon Project A. Project B declares a "compile" dependency > on Project A. > Project C depends upon Project B. Project C declares a "compile" dependency > on Project B. > C > | - compile dependency > B > | - compile dependency > A > | - provided dependency > Sybase JConnect > So, does Project C transitively depend on Sybase JConnect. Yes, of course! > The "provided" dependency needs to be transitive. > Ultimately, when Project C gets deployed, Sybase JConnect needs to be > somewhere on the runtime classpath in order for the application to function. > It's valid for Project C to assume that Sybase JConnect is available and use > JDBC all over the Project C code. Project C is safe to do this because it can > happily deduce that Sybase JConnect will be there in the runtime environment > because Project A NEEDS IT. > I've got Use Cases all over my aggregated build which make it absolutely > critical and common sense that provided scope dependencies are transitive. > For the (very rare) odd case where you don't want to inherit provided > dependencies, you can them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-621) directoryMode not enforced
Asif Akhtar created MASSEMBLY-621:
-
Summary: directoryMode not enforced
Key: MASSEMBLY-621
URL: https://jira.codehaus.org/browse/MASSEMBLY-621
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2.1
Environment: Linux x86_64 Fedora 17
Reporter: Asif Akhtar
Maven assembly plugin does not enforce directoryMode when specified for the
outputdirectory.
For example:
{code}
src/main/conf
0644
0755/directoryMode>
conf
{code}
The directories still appear as 775.
{code}
drwxrwxr-x
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-139) Regex rule example is incorrect; matching is not described
SebbASF created MENFORCER-139:
-
Summary: Regex rule example is incorrect; matching is not described
Key: MENFORCER-139
URL: https://jira.codehaus.org/browse/MENFORCER-139
Project: Maven 2.x Enforcer Plugin
Issue Type: Bug
Components: Standard Rules
Environment:
http://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
Reporter: SebbASF
The documentation page [1] has an example rule containing:
{noformat}
\d
You must have a digit in your baseDir!
{noformat}
This is very misleading, as \d only matches a single digit.
The example should be:
{noformat}
.*\d.*
You must have a digit in your baseDir!
{noformat}
or possibly:
{noformat}
\d
Your baseDir must consist of a single digit only!
{noformat}
The documentation should state that the regex is applied to the entire value of
the property.
That is, it uses regex "match" rather than regex "contains", effectively the
regex string is enclosed in "^" and "$" before use.
[1] http://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
