[jira] (MPIR-269) (optionally) create dependency convergence also for single module projects
[ https://jira.codehaus.org/browse/MPIR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=321557#comment-321557 ] Steven Swor commented on MPIR-269: -- Agreed. The ready for release info in this report is useful for single-module projects. I just spent a good half hour trying to figure out why the report wouldn't run for my project, and ended up stepping through the code in a debugger until I found it. If the behavior isn't going to be changed, can someone please at least update the documentation for this goal to mention that it requires a reactor build (or only generates a report for multi-module projects)? (optionally) create dependency convergence also for single module projects -- Key: MPIR-269 URL: https://jira.codehaus.org/browse/MPIR-269 Project: Maven 2.x Project Info Reports Plugin Issue Type: Improvement Components: dependency-convergence Affects Versions: 2.6 Reporter: Michael Wenig We are using the dependency convergence report for a quick check if a project could be released or not. Unfortunately the report is not created for single module projects. MPIR-10 mentions that it is useful for multi module and therefore disabled by default for single module projects. Unfortunately by default is not correct as there is no option to activate it. At our site the report also makes sense for single modules. The report shows if there are snapshot versions of other projects used. Of course someone could take a look into the dependency report and search for SNAPSHOT. But it is a lot easier for the developers to follow a simple rule look into this report - and it could be used programmatically if the report is alway present. Is there any reason against activating this report also for single module (an option which is false per default would be sufficient)? -- 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] (MPIR-269) (optionally) create dependency convergence also for single module projects
[ https://jira.codehaus.org/browse/MPIR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=321557#comment-321557 ] Steven Swor edited comment on MPIR-269 at 3/6/13 4:29 PM: -- Agreed. The ready for release info in this report is useful for single-module projects. I just spent a good half hour trying to figure out why the report wouldn't run for my project, and ended up stepping through the code in a debugger until I found it. At the very least, can someone please at least update the documentation for this goal to mention that it requires a reactor build (or only generates a report for multi-module projects)? was (Author: sworisbreathing): Agreed. The ready for release info in this report is useful for single-module projects. I just spent a good half hour trying to figure out why the report wouldn't run for my project, and ended up stepping through the code in a debugger until I found it. If the behavior isn't going to be changed, can someone please at least update the documentation for this goal to mention that it requires a reactor build (or only generates a report for multi-module projects)? (optionally) create dependency convergence also for single module projects -- Key: MPIR-269 URL: https://jira.codehaus.org/browse/MPIR-269 Project: Maven 2.x Project Info Reports Plugin Issue Type: Improvement Components: dependency-convergence Affects Versions: 2.6 Reporter: Michael Wenig We are using the dependency convergence report for a quick check if a project could be released or not. Unfortunately the report is not created for single module projects. MPIR-10 mentions that it is useful for multi module and therefore disabled by default for single module projects. Unfortunately by default is not correct as there is no option to activate it. At our site the report also makes sense for single modules. The report shows if there are snapshot versions of other projects used. Of course someone could take a look into the dependency report and search for SNAPSHOT. But it is a lot easier for the developers to follow a simple rule look into this report - and it could be used programmatically if the report is alway present. Is there any reason against activating this report also for single module (an option which is false per default would be sufficient)? -- 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] (MPDF-29) Improve figure scaling
[
https://jira.codehaus.org/browse/MPDF-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=320601#comment-320601
]
Steven Swor commented on MPDF-29:
-
For SVG graphics exported from Google Docs, {{scale-to-fit}} seems to work
better than {{scale-down-to-fit}}. Otherwise the image can end up being really
tiny.
Improve figure scaling
--
Key: MPDF-29
URL: https://jira.codehaus.org/browse/MPDF-29
Project: Maven 2.x PDF Plugin
Issue Type: Improvement
Affects Versions: 1.0
Reporter: Lukas Theussl
Assignee: Lukas Theussl
Fix For: 1.2
From a private mail:
Today, I found an extremely useful tip for how to get the images/graphics
right both in HTML and PDF. As you know and write in the FAQ, there is a
challenge with scaling the images, especially when using APT.
I think it would be useful for others, if you could publish this tip on the
site for the plugin.
What I did was this:
I made a copy of the original fo-styles.xslt, names it pdf-config.xml in my
src/site/resources.
Then I replaced the following section:
{code:xml}
xsl:attribute-set name=figure.graphics
xsl:attribute name=widthauto/xsl:attribute
xsl:attribute name=heightauto/xsl:attribute
xsl:attribute name=content-widthauto/xsl:attribute
xsl:attribute name=content-heightauto/xsl:attribute
/xsl:attribute-set
{code}
with this:
{code:xml}
xsl:attribute-set name=figure.graphics
xsl:attribute name=content-widthscale-down-to-fit/xsl:attribute
xsl:attribute name=content-heightscale-down-to-fit/xsl:attribute
xsl:attribute name=width100%/xsl:attribute
xsl:attribute name=height100%/xsl:attribute
/xsl:attribute-set
{code}
And VOILA, the scaling was perfect!
--
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] (MPDF-8) Create one PDF from a multi module project
[
https://jira.codehaus.org/browse/MPDF-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=320607#comment-320607
]
Steven Swor commented on MPDF-8:
Until this issue is resolved, here is a workaround. Essentially, it flattens
the site hierarchy, before running the PDF plugin, by copying the sources from
the parent and all child modules into a single folder.
In the parent's pom.xml:
{code:xml}
properties
site.aggregate.dir${project.build.directory}/pdf-aggregate/site.aggregate.dir
/properties
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-resources-plugin/artifactId
executions
execution
idaggregate-pdf-sources/id
phasepre-site/phase
goals
goalcopy-resources/goal
/goals
configuration
outputDirectory${site.aggregate.dir}/outputDirectory
resources
resource
directorysrc/site//directory
/resource
!-- repeat for each module --
resource
directorymodule1/src/site/directory
excludes
excludesite.xml/exclude
/excludes
/resource
/resources
/configuration
/execution
/executions
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-pdf-plugin/artifactId
version1.2/version
configuration
siteDirectory${site.aggregate.dir}/siteDirectory
/configuration
/plugin
/plugins
/build
{code}
This works well when the PDF plugin is configured to run as part of the site
phase. If not, simply run {{mvn pre-site pdf:pdf}}.
Create one PDF from a multi module project
--
Key: MPDF-8
URL: https://jira.codehaus.org/browse/MPDF-8
Project: Maven 2.x PDF Plugin
Issue Type: New Feature
Reporter: Lukas Theussl
--
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] (MNGSITE-171) Doxia Tools dead links
Steven Swor created MNGSITE-171: --- Summary: Doxia Tools dead links Key: MNGSITE-171 URL: https://jira.codehaus.org/browse/MNGSITE-171 Project: Maven Project Web Site Issue Type: Bug Reporter: Steven Swor The navigation bar for http://maven.apache.org/doxia/ includes a link to http://maven.apache.org/doxia/doxia-tools/index.html under the Developer Docs menu, but the link is broken. On a related note (probably caused by the same issue), the link to the Book Descriptor Reference from http://maven.apache.org/doxia/book/index.html is dead (it links to http://maven.apache.org/doxia/doxia-tools/doxia-book-renderer/book.html) -- 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-5091) Add option to fail build if WARNING's appear in POM
[
https://jira.codehaus.org/browse/MNG-5091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=315365#comment-315365
]
Steven Swor commented on MNG-5091:
--
Any chance the patch with the {{--validation-level}} switch will make it into
3.0.x?
Add option to fail build if WARNING's appear in POM
---
Key: MNG-5091
URL: https://jira.codehaus.org/browse/MNG-5091
Project: Maven 2 3
Issue Type: Improvement
Components: Command Line, POM
Affects Versions: 3.0.3
Reporter: Karl Heinz Marbaise
Priority: Minor
Fix For: 3.1.x
Attachments: MNG-5091-maven-embedder.patch
It would be nice to have the option to let a build fail if something like
this will appear:
{code}
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model
for com.soebes.training.module:050-project-without-warnings:jar:0.1.0-SNAPSHOT
[WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must
be unique: org.slf4j:slf4j-api:jar - duplicate declaration of version 1.6.1
@ line 28, column 14
[WARNING]
[WARNING] It is highly recommended to fix these problems because they
threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
[WARNING]
{code}
This shoud be done for WARNING's in case of missing versions for plugins etc.
Currently it is possible to set the Validation leven in Jenkins/Hudson
already but it is not possible on command line. So an option on command line
like:
{code}
mvn --fail-warning ...
{code}
would be great. Or may be a good supplemental option to set the validation
level like:
{code}
mvn --validation-level MINIMAL
mvn --validation-level MAVEN20
mvn --validation-level MAVEN30
mvn --validation-level MAVEN31
mvn --validation-level DEFAULT
{code}
or may be both. May this might be an enhancement for Maven 3.0.4 ?
--
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-5091) Add option to fail build if WARNING's appear in POM
[
https://jira.codehaus.org/browse/MNG-5091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=315371#comment-315371
]
Steven Swor commented on MNG-5091:
--
As a workaround, you can use the GMaven plugin to set the validation level
during the Maven build. Here's an example which coerces it down to
{{org.apache.maven.model.building.ModelBuildingRequest.VALIDATION_LEVEL_MAVEN_2_0}}
during the {{validate}} phase. Add the following to your
{{project.build.plugins}} section
{code}
plugin
groupIdorg.codehaus.gmaven/groupId
artifactIdgmaven-plugin/artifactId
version1.5/version
configuration
!--
This tells gmaven-plugin we want to run against Groovy 2
--
providerSelection2.0/providerSelection
/configuration
executions
execution
idchange-validation-level/id
phasevalidate/phase
goals
goalexecute/goal
/goals
configuration
source
def desiredValidationLevel =
org.apache.maven.model.building.ModelBuildingRequest.VALIDATION_LEVEL_MAVEN_2_0
def request = session.request.projectBuildingRequest
if (request.validationLevel desiredValidationLevel) {
log.warn(Correcting validation level. Was {}. Now
{}, request.validationLevel, desiredValidationLevel)
request.validationLevel = desiredValidationLevel
}
/source
/configuration
/execution
/executions
dependencies
dependency
groupIdorg.codehaus.groovy/groupId
artifactIdgroovy-all/artifactId
version2.0.5/version
/dependency
dependency
groupIdorg.codehaus.gmaven.runtime/groupId
artifactIdgmaven-runtime-2.0/artifactId
version1.5/version
exclusions
exclusion
groupIdorg.codehaus.groovy/groupId
artifactIdgroovy-all/artifactId
/exclusion
/exclusions
/dependency
/dependencies
/plugin
{code}
Note: I'm not sure if forcing GMaven to use Groovy 2 is required. I just
copied an existing usage of the plugin and tweaked it for this example.
Add option to fail build if WARNING's appear in POM
---
Key: MNG-5091
URL: https://jira.codehaus.org/browse/MNG-5091
Project: Maven 2 3
Issue Type: Improvement
Components: Command Line, POM
Affects Versions: 3.0.3
Reporter: Karl Heinz Marbaise
Priority: Minor
Fix For: 3.1.x
Attachments: MNG-5091-maven-embedder.patch
It would be nice to have the option to let a build fail if something like
this will appear:
{code}
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model
for com.soebes.training.module:050-project-without-warnings:jar:0.1.0-SNAPSHOT
[WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must
be unique: org.slf4j:slf4j-api:jar - duplicate declaration of version 1.6.1
@ line 28, column 14
[WARNING]
[WARNING] It is highly recommended to fix these problems because they
threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
[WARNING]
{code}
This shoud be done for WARNING's in case of missing versions for plugins etc.
Currently it is possible to set the Validation leven in Jenkins/Hudson
already but it is not possible on command line. So an option on command line
like:
{code}
mvn --fail-warning ...
{code}
would be great. Or may be a good supplemental option to set the validation
level like:
{code}
mvn --validation-level MINIMAL
mvn --validation-level MAVEN20
mvn --validation-level MAVEN30
mvn --validation-level MAVEN31
mvn --validation-level DEFAULT
{code}
or may be both. May this might be an enhancement for Maven 3.0.4 ?
--
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-5091) Add option to fail build if WARNING's appear in POM
[
https://jira.codehaus.org/browse/MNG-5091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=315371#comment-315371
]
Steven Swor edited comment on MNG-5091 at 12/10/12 5:51 PM:
As a workaround, you can use the GMaven plugin to set the validation level
during the Maven build. Here's an example which checks the validation level
during the {{validate}} phase and fails the build if it's above
{{org.apache.maven.model.building.ModelBuildingRequest.VALIDATION_LEVEL_MAVEN_2_0}}.
Add the following to your {{project.build.plugins}} section
{code}
plugin
groupIdorg.codehaus.gmaven/groupId
artifactIdgmaven-plugin/artifactId
version1.5/version
configuration
!--
This tells gmaven-plugin we want to run against Groovy 2
--
providerSelection2.0/providerSelection
/configuration
executions
execution
idchange-validation-level/id
phasevalidate/phase
goals
goalexecute/goal
/goals
configuration
source
def desiredValidationLevel =
org.apache.maven.model.building.ModelBuildingRequest.VALIDATION_LEVEL_MAVEN_2_0
def request = session.request.projectBuildingRequest
if (request.validationLevel desiredValidationLevel) {
/*
* Comment out the following line and uncomment the two
below
* to coerce the validation level instead of failing
the build
*/
throw new RuntimeException(Validation level is too
high)
// log.warn(Correcting validation level. Was {}. Now
{}, request.validationLevel, desiredValidationLevel)
// request.validationLevel = desiredValidationLevel
}
/source
/configuration
/execution
/executions
dependencies
dependency
groupIdorg.codehaus.groovy/groupId
artifactIdgroovy-all/artifactId
version2.0.5/version
/dependency
dependency
groupIdorg.codehaus.gmaven.runtime/groupId
artifactIdgmaven-runtime-2.0/artifactId
version1.5/version
exclusions
exclusion
groupIdorg.codehaus.groovy/groupId
artifactIdgroovy-all/artifactId
/exclusion
/exclusions
/dependency
/dependencies
/plugin
{code}
Note: I'm not sure if forcing GMaven to use Groovy 2 is required. I just
copied an existing usage of the plugin and tweaked it for this example.
was (Author: sworisbreathing):
As a workaround, you can use the GMaven plugin to set the validation level
during the Maven build. Here's an example which coerces it down to
{{org.apache.maven.model.building.ModelBuildingRequest.VALIDATION_LEVEL_MAVEN_2_0}}
during the {{validate}} phase. Add the following to your
{{project.build.plugins}} section
{code}
plugin
groupIdorg.codehaus.gmaven/groupId
artifactIdgmaven-plugin/artifactId
version1.5/version
configuration
!--
This tells gmaven-plugin we want to run against Groovy 2
--
providerSelection2.0/providerSelection
/configuration
executions
execution
idchange-validation-level/id
phasevalidate/phase
goals
goalexecute/goal
/goals
configuration
source
def desiredValidationLevel =
org.apache.maven.model.building.ModelBuildingRequest.VALIDATION_LEVEL_MAVEN_2_0
def request = session.request.projectBuildingRequest
if (request.validationLevel desiredValidationLevel) {
log.warn(Correcting validation level. Was {}. Now
{}, request.validationLevel, desiredValidationLevel)
request.validationLevel = desiredValidationLevel
}
/source
/configuration
/execution
/executions
dependencies
dependency
groupIdorg.codehaus.groovy/groupId
artifactIdgroovy-all/artifactId
version2.0.5/version
/dependency
dependency
groupIdorg.codehaus.gmaven.runtime/groupId
artifactIdgmaven-runtime-2.0/artifactId
version1.5/version
exclusions
exclusion
groupIdorg.codehaus.groovy/groupId
artifactIdgroovy-all/artifactId
/exclusion
/exclusions
/dependency
/dependencies
/plugin
{code}
Note: I'm not sure if forcing
[jira] (MNG-5091) Add option to fail build if WARNING's appear in POM
[
https://jira.codehaus.org/browse/MNG-5091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=315371#comment-315371
]
Steven Swor edited comment on MNG-5091 at 12/10/12 5:54 PM:
As a workaround, you can use the GMaven plugin to set the validation level
during the Maven build. Here's an example which checks the validation level
during the {{validate}} phase and fails the build if it's above
{{org.apache.maven.model.building.ModelBuildingRequest.VALIDATION_LEVEL_MAVEN_2_0}}.
Add the following to your {{project.build.plugins}} section
{code}
plugin
groupIdorg.codehaus.gmaven/groupId
artifactIdgmaven-plugin/artifactId
version1.5/version
configuration
!--
This tells gmaven-plugin we want to run against Groovy 2
--
providerSelection2.0/providerSelection
/configuration
executions
execution
idchange-validation-level/id
phasevalidate/phase
goals
goalexecute/goal
/goals
configuration
source
def desiredValidationLevel =
org.apache.maven.model.building.ModelBuildingRequest.VALIDATION_LEVEL_MAVEN_2_0
def request = session.request.projectBuildingRequest
if (request.validationLevel desiredValidationLevel) {
/*
* Comment out the following line and uncomment the two
below
* to coerce the validation level instead of failing
the build
*/
throw new RuntimeException(Validation level is too
high)
// log.warn(Correcting validation level. Was {}. Now
{}, request.validationLevel, desiredValidationLevel)
// request.validationLevel = desiredValidationLevel
}
/source
/configuration
/execution
/executions
dependencies
dependency
groupIdorg.codehaus.groovy/groupId
artifactIdgroovy-all/artifactId
version2.0.5/version
/dependency
dependency
groupIdorg.codehaus.gmaven.runtime/groupId
artifactIdgmaven-runtime-2.0/artifactId
version1.5/version
exclusions
exclusion
groupIdorg.codehaus.groovy/groupId
artifactIdgroovy-all/artifactId
/exclusion
/exclusions
/dependency
/dependencies
/plugin
{code}
Note: I'm not sure if forcing GMaven to use Groovy 2 is required. I just
copied an existing usage of the plugin and tweaked it for this example.
The trick works because gmaven injects the {{MavenSession}} into the script,
which has access to the {{ProjectBuildingRequest}} via its
{{MavenExecutionRequest}}. I'd suggest having a look at the Maven core API
docs and maven build API docs. You might be able to get access to the warnings
somehow.
was (Author: sworisbreathing):
As a workaround, you can use the GMaven plugin to set the validation level
during the Maven build. Here's an example which checks the validation level
during the {{validate}} phase and fails the build if it's above
{{org.apache.maven.model.building.ModelBuildingRequest.VALIDATION_LEVEL_MAVEN_2_0}}.
Add the following to your {{project.build.plugins}} section
{code}
plugin
groupIdorg.codehaus.gmaven/groupId
artifactIdgmaven-plugin/artifactId
version1.5/version
configuration
!--
This tells gmaven-plugin we want to run against Groovy 2
--
providerSelection2.0/providerSelection
/configuration
executions
execution
idchange-validation-level/id
phasevalidate/phase
goals
goalexecute/goal
/goals
configuration
source
def desiredValidationLevel =
org.apache.maven.model.building.ModelBuildingRequest.VALIDATION_LEVEL_MAVEN_2_0
def request = session.request.projectBuildingRequest
if (request.validationLevel desiredValidationLevel) {
/*
* Comment out the following line and uncomment the two
below
* to coerce the validation level instead of failing
the build
*/
throw new RuntimeException(Validation level is too
high)
// log.warn(Correcting validation level. Was {}. Now
{}, request.validationLevel, desiredValidationLevel)
// request.validationLevel = desiredValidationLevel
}
/source
/configuration
[jira] (MPDF-29) Improve figure scaling
[
https://jira.codehaus.org/browse/MPDF-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=294957#comment-294957
]
Steven Swor commented on MPDF-29:
-
Thanks!
Improve figure scaling
--
Key: MPDF-29
URL: https://jira.codehaus.org/browse/MPDF-29
Project: Maven 2.x PDF Plugin
Issue Type: Improvement
Affects Versions: 1.0
Reporter: Lukas Theussl
Assignee: Lukas Theussl
Fix For: 1.2
From a private mail:
Today, I found an extremely useful tip for how to get the images/graphics
right both in HTML and PDF. As you know and write in the FAQ, there is a
challenge with scaling the images, especially when using APT.
I think it would be useful for others, if you could publish this tip on the
site for the plugin.
What I did was this:
I made a copy of the original fo-styles.xslt, names it pdf-config.xml in my
src/site/resources.
Then I replaced the following section:
{code:xml}
xsl:attribute-set name=figure.graphics
xsl:attribute name=widthauto/xsl:attribute
xsl:attribute name=heightauto/xsl:attribute
xsl:attribute name=content-widthauto/xsl:attribute
xsl:attribute name=content-heightauto/xsl:attribute
/xsl:attribute-set
{code}
with this:
{code:xml}
xsl:attribute-set name=figure.graphics
xsl:attribute name=content-widthscale-down-to-fit/xsl:attribute
xsl:attribute name=content-heightscale-down-to-fit/xsl:attribute
xsl:attribute name=width100%/xsl:attribute
xsl:attribute name=height100%/xsl:attribute
/xsl:attribute-set
{code}
And VOILA, the scaling was perfect!
--
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-360) When using mulitple Spring dependencies, the files from META-INF (from the Spring jars) overwrite each other in an executable jar-with-dependencies.
[ https://jira.codehaus.org/browse/MASSEMBLY-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=294886#comment-294886 ] Steven Swor commented on MASSEMBLY-360: --- I still have this issue with Spring 3.1.1-RELEASE and maven-assembly-plugin 2.3 in Maven 3.0.3. I went with Bernhard's solution because it did not require me to add any additional files to my project as a workaround. When using mulitple Spring dependencies, the files from META-INF (from the Spring jars) overwrite each other in an executable jar-with-dependencies. Key: MASSEMBLY-360 URL: https://jira.codehaus.org/browse/MASSEMBLY-360 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-2 Environment: Windows XP, Java 5 Reporter: Marielle Enderman Assignee: John Casey Fix For: 2.2 I'm working on a Java 5 project with maven 2 and I need to deliver an executable jar file. In this project I'm using different Spring dependencies: dependency groupIdorg.springframework/groupId artifactIdspring-beans/artifactId version2.5.5/version /dependency dependency groupIdorg.springframework/groupId artifactIdspring-context/artifactId version2.5.5/version /dependency For maven packaging I'm using the maven-assembly plugin to create an executable jar with dependencies (using the jar-with-dependencies descriptor). Everything works fine, except that Spring's XSD files can't be found. At least: not all of them. The fact is: Every Spring JAR file contains a META-INF directory with files like spring.handlers and spring.schemas which contain list of locations of respectively namespace handlers and schemas. Unfortunately these files aren't merged during packaging so the META_INF of the executable JAR file only contains the last one added. This can result in errors like this: Example 1: The spring-context-2.5.xsd can't be found: WARN org.springframework.beans.factory.xml.XmlBeanDefinitionReader - Ignored XML validation warning org.xml.sax.SAXParseException: schema_reference.4: Failed to read schema document 'http://www.springframework.org/schema/context/spring-context-2.5.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not xsd:schema. Example 2: The NamespaceHandler for the spring context namespace can't be located: Exception in thread main org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://www.springframework.org/schema/context] When I manually merge the files, the executable JAR file works fine. I hope this problem can be solved. -- 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] (MPDF-29) Improve figure scaling
[
https://jira.codehaus.org/browse/MPDF-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=294907#comment-294907
]
Steven Swor commented on MPDF-29:
-
This specific example is not given in the plugin usage page, and there is
little documentation on what attribute sets are used by the PDF plugin. Can
you please take a second look at this ticket, and either make this the default
behavior in the PDF plugin, or update the documentation?
Improve figure scaling
--
Key: MPDF-29
URL: https://jira.codehaus.org/browse/MPDF-29
Project: Maven 2.x PDF Plugin
Issue Type: Improvement
Affects Versions: 1.0
Reporter: Lukas Theussl
Assignee: Lukas Theussl
From a private mail:
Today, I found an extremely useful tip for how to get the images/graphics
right both in HTML and PDF. As you know and write in the FAQ, there is a
challenge with scaling the images, especially when using APT.
I think it would be useful for others, if you could publish this tip on the
site for the plugin.
What I did was this:
I made a copy of the original fo-styles.xslt, names it pdf-config.xml in my
src/site/resources.
Then I replaced the following section:
{code:xml}
xsl:attribute-set name=figure.graphics
xsl:attribute name=widthauto/xsl:attribute
xsl:attribute name=heightauto/xsl:attribute
xsl:attribute name=content-widthauto/xsl:attribute
xsl:attribute name=content-heightauto/xsl:attribute
/xsl:attribute-set
{code}
with this:
{code:xml}
xsl:attribute-set name=figure.graphics
xsl:attribute name=content-widthscale-down-to-fit/xsl:attribute
xsl:attribute name=content-heightscale-down-to-fit/xsl:attribute
xsl:attribute name=width100%/xsl:attribute
xsl:attribute name=height100%/xsl:attribute
/xsl:attribute-set
{code}
And VOILA, the scaling was perfect!
--
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] Created: (DOXIA-354) Add images to example-book
Add images to example-book -- Key: DOXIA-354 URL: http://jira.codehaus.org/browse/DOXIA-354 Project: Maven Doxia Issue Type: Improvement Components: Book Affects Versions: 1.1.1 Reporter: Steven Swor Priority: Blocker Images are an important feature of a technical manual or book, yet try as I might, I cannot get them to work with a Doxia book. Could someone please update the example-book to include at least one image, so that the rest of the world may benefit from knowing how to properly add images to a Doxia book? It would be beneficial if the example could show how to add an image from a local file as well as from a URL. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MPDF-23) Definition Lists are not formatted correctly
[
http://jira.codehaus.org/browse/MPDF-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Swor updated MPDF-23:
Attachment: pdfPluginDefinitionTest.zip
Here's a sample Maven project with the resulting PDF in the target folder. If
this is not the output that you get when you try to run it, then something is
wonky on my box.
P.S. I'm running Maven 2.2.0 (r788681; 2009-06-26 08:04:01-0500)
Definition Lists are not formatted correctly
Key: MPDF-23
URL: http://jira.codehaus.org/browse/MPDF-23
Project: Maven 2.x PDF Plugin
Issue Type: Improvement
Affects Versions: 1.0
Environment: OS: Mac OS X (10.5.7)
Java Version: (1.6.0_13)
PDF Plugin Implementation: itext
Documentation Source Format: APT
Reporter: Steven Swor
Priority: Trivial
Attachments: pdfPluginDefinitionTest.zip
When creating a definition list using APT, the resulting PDF is formatted
incorrectly. For example:
{noformat}
[Term 1] Definition 1.
[Term 2] Definition 2.
[Term 3] Definition 3.
[]
{noformat}
produces the following output
{noformat}
Term 1
Definition 1. Term 2.
Definition 2. Term 3.
Definition 3.
{noformat}
The two problems I have with this are that 1) new terms are on the same line
as the definition of the previous term, and 2) there is not enough formatting
difference between terms and their definitions. It'd be nice to make the
terms bold-face, or indent the definitions, or something like that, to make
the PDF more human-readable.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPDF-23) Definition Lists are not formatted correctly
Definition Lists are not formatted correctly Key: MPDF-23 URL: http://jira.codehaus.org/browse/MPDF-23 Project: Maven 2.x PDF Plugin Issue Type: Improvement Affects Versions: 1.0 Environment: OS: Mac OS X (10.5.7) Java Version: (1.6.0_13) PDF Plugin Implementation: itext Documentation Source Format: APT Reporter: Steven Swor Priority: Trivial When creating a definition list using APT, the resulting PDF is formatted incorrectly. For example: [Term 1] Definition 1. [Term 2] Definition 2. [Term 3] Definition 3. [] produces the following output Term 1 Definition 1. Term 2. Definition 2. Term 3. Definition 3. The two problems I have with this are that 1) new terms are on the same line as the definition of the previous term, and 2) there is not enough formatting difference between terms and their definitions. It'd be nice to make the terms bold-face, or indent the definitions, or something like that, to make the PDF more human-readable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPDF-23) Definition Lists are not formatted correctly
[ http://jira.codehaus.org/browse/MPDF-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=185025#action_185025 ] Steven Swor commented on MPDF-23: - In my APT files, the definition lists are indented in accordance with http://maven.apache.org/doxia/references/apt-format.html (the extra whitespace was stripped out by JIRA) Definition Lists are not formatted correctly Key: MPDF-23 URL: http://jira.codehaus.org/browse/MPDF-23 Project: Maven 2.x PDF Plugin Issue Type: Improvement Affects Versions: 1.0 Environment: OS: Mac OS X (10.5.7) Java Version: (1.6.0_13) PDF Plugin Implementation: itext Documentation Source Format: APT Reporter: Steven Swor Priority: Trivial When creating a definition list using APT, the resulting PDF is formatted incorrectly. For example: [Term 1] Definition 1. [Term 2] Definition 2. [Term 3] Definition 3. [] produces the following output Term 1 Definition 1. Term 2. Definition 2. Term 3. Definition 3. The two problems I have with this are that 1) new terms are on the same line as the definition of the previous term, and 2) there is not enough formatting difference between terms and their definitions. It'd be nice to make the terms bold-face, or indent the definitions, or something like that, to make the PDF more human-readable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
