[jira] Commented: (MEAR-129) ejb3Module broken and deprecated but not indicated as such in website documentation
[ http://jira.codehaus.org/browse/MEAR-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=229796#action_229796 ] Stephane Nicoll commented on MEAR-129: -- I am confused by your report. The http://maven.apache.org/plugins/maven-ear-plugin/modules.html#ejb3Module redirects to a page where it's stated ejb3Module (deprecated. ejbModule provides the same functionality) And, as far as I know, it's not broken. Why are you saying it's broken? ejb3Module broken and deprecated but not indicated as such in website documentation --- Key: MEAR-129 URL: http://jira.codehaus.org/browse/MEAR-129 Project: Maven 2.x Ear Plugin Issue Type: Improvement Reporter: David Wallace Croft EAR configuration ejb3Module is listed in documentation as though it were still working: http://maven.apache.org/plugins/maven-ear-plugin/modules.html#ejb3Module User gets Artifact[ejb3:*.*.*] is not a dependency of the project. error. User, being new to Maven, spends a couple of hours trying to fix the error by tweaking his other POMs to set dependency type to EJB3, etc. User turns to Google. User discovers that ejb3Module is broken and deprecated and has been for over a year or two: http://www.5341.com/msg/224841.html http://jira.codehaus.org/browse/MEAR-40 (see comments) -- 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: (MNG-4633) Make weave mode work reliably
[
http://jira.codehaus.org/browse/MNG-4633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=229804#action_229804
]
Robert Munteanu commented on MNG-4633:
--
The plugin is the maven-compiler-plugin , and it's bound to two executions :
once in generate-sources, another in default-compiler. And yes, module B
depends on the classes from module A. It's worth mentioning that all execution
so far was done on a single thread, judging from the thread names.
Also, I get some warnings regarding n...@threadsafe plugins. Should I worry
about these:
{code}
[WARNING] The following plugins are not marked @threadSafe in ...:
[WARNING] org.apache.maven.plugins:maven-surefire-plugin:2.5
[WARNING] org.codehaus.mojo:build-helper-maven-plugin:1.5
[WARNING] org.apache.maven.plugins:maven-enforcer-plugin:1.0-beta-1
{code}
Since I'm running a SNAPSHOT build I need to skip the enforcer plugin. I've
also tried with the tests skipped, but that made no difference.
Make weave mode work reliably
-
Key: MNG-4633
URL: http://jira.codehaus.org/browse/MNG-4633
Project: Maven 2 3
Issue Type: Improvement
Affects Versions: 3.0-beta-1
Reporter: Kristian Rosenvold
Assignee: Kristian Rosenvold
Fix For: 3.0-beta-2
m3 trunk currently contains two different concurrent-build implementations;
parallel and weave. The main target for m3 is for production quality
parallel to be ready; there are numerous plugins that will need to adjust
to this functionality.
Alongside this activity weave mode will also be fine-tuned and evaluated; due
to the generally tighter concurrency in this model, weave mode is more likely
to reveal concurrency related issues in both maven, plugins, libraries and
the jdk.
This task is used to collect all commits related to making weave mode work
reliably. The final evaluation of weave mode will be taken at a later stage.
In the event that Weave mode is to be abandoned, the class
LifecycleWeaveBuilder contains instructions on how/what can be removed from
m3 core.
--
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: (MNG-4740) Maven hangs with big aggregators with lots of inter-modules dependencies
Maven hangs with big aggregators with lots of inter-modules dependencies Key: MNG-4740 URL: http://jira.codehaus.org/browse/MNG-4740 Project: Maven 2 3 Issue Type: Bug Components: Bootstrap Build Affects Versions: 3.0-beta-1 Reporter: Vincent Latombe Attachments: hangs.patch Hello, On my main aggregator (~280 modules, lots of inter-modules dependencies), I noticed that since 3.0-beta-1, maven hangs after displaying the list of modules to build. The problem was not occurring with alpha-7. After investigation, it seems that with the introduction of parallel build in beta-1, the whole list of module dependencies is computed at the beginning of the build (see http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/lifecycle/internal/ProjectSegment.java?r1=931884r2=935334diff_format=h) It turns out that this calculation, done inside DefaultProjectDependencyGraph, is very unefficient : if a module is referenced n times, its dependencies will be computed n times. The attached patch solves the problem by computing the dependency tree for a given projectId only once. -- 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: (MRESOURCES-128) Custom resource filters
Custom resource filters
---
Key: MRESOURCES-128
URL: http://jira.codehaus.org/browse/MRESOURCES-128
Project: Maven 2.x Resources Plugin
Issue Type: New Feature
Reporter: Laurent Martelli
It would be very nice to be able to use some custom resource filters in
addition to properties substitutions. For instance, one may want to optimize
PNG images which may contain big proprietary chunks inserted by the editing
software, which are totally useless to the running webapp, but usefull for
editing the image.
Being able to run an external program (like pngcrush in the case mentioned
above) may be an option, but for maximum portability, a Java interface would be
better (filtering PNG chunks is actually easy, and I already have a few Java
classes to do that). The interface could look like this :
public interface ResourceFilter {
void filterResource(InputStream input, OutputStream output, MavenContext
context);
}
The context (I don't know if the class exists) could be used to retrieve the
filter's configuration (some criteria specifying which chunks to include or
exclude, for instance). Or maybe Maven is able to directly configure beans
using their properties.
--
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: (MRESOURCES-128) Custom resource filters
[
http://jira.codehaus.org/browse/MRESOURCES-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=229849#action_229849
]
Dennis Lundberg commented on MRESOURCES-128:
This is an interesting idea that I've been thinking about as well.
There is something like this in Maven Shade Plugin, called
[ResourceTransformer|https://svn.apache.org/viewvc/maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/resource/ResourceTransformer.java?revision=894664view=markup].
Perhaps that can be extracted and made available as a shared component.
One of my use cases is convert EOL for certain text-based resources, like
properties files.
Custom resource filters
---
Key: MRESOURCES-128
URL: http://jira.codehaus.org/browse/MRESOURCES-128
Project: Maven 2.x Resources Plugin
Issue Type: New Feature
Reporter: Laurent Martelli
Assignee: Olivier Lamy
It would be very nice to be able to use some custom resource filters in
addition to properties substitutions. For instance, one may want to
optimize PNG images which may contain big proprietary chunks inserted by
the editing software, which are totally useless to the running webapp, but
usefull for editing the image.
Being able to run an external program (like pngcrush in the case mentioned
above) may be an option, but for maximum portability, a Java interface would
be better (filtering PNG chunks is actually easy, and I already have a few
Java classes to do that). The interface could look like this :
public interface ResourceFilter {
void filterResource(InputStream input, OutputStream output, MavenContext
context);
}
The context (I don't know if the class exists) could be used to retrieve the
filter's configuration (some criteria specifying which chunks to include or
exclude, for instance). Or maybe Maven is able to directly configure beans
using their properties.
--
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: (DOXIASITETOOLS-38) Specifiy a version for the default skin
Specifiy a version for the default skin
---
Key: DOXIASITETOOLS-38
URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-38
Project: Maven Doxia Sitetools
Issue Type: Improvement
Components: Decoration model
Affects Versions: 1.1.3
Reporter: Dennis Lundberg
The default value used when a skin is not specified should include a version.
This is done in the modello file in the code segment for
{code}getDefaultSkin(){code}.
--
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: (MNG-4301) Invalid checksums on deploy when using webdav without extension
[ http://jira.codehaus.org/browse/MNG-4301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=229854#action_229854 ] Cornel Masson commented on MNG-4301: We are experiencing the same bug and it's now a show-stopper for our Maven release. We have a large build and are seeing numerous CHECKSUM failures, even on Maven jars from Central. We are using: * Maven 2.2.1 * Nexus Open Source Edition, Version: 1.6.0 We have tried all the suggestions on the Net, including: * setting the wagon provider to httpclient * setting http.authentication.preemptive to true (as above) * setting the specific wagon-webdav version (as above) and nothing works. Each time we run the build, a random selection of artifacts fail with CHECKSUM errors. This happens for both internal (self-deployed) and external artifacts. Here's an example failure: 4425K downloaded (groovy-all-1.6.5.jar) [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = '9c6a38100085d8fbfb3f017ac82e396999e64f92'; remote = 'PK If you examine the remote checksum, it seems it references the actual *contents* of the JAR, not a checksum file(!!). We also get 'invalid POM' errors as a result of some failures, so our build actually breaks at the end (no use just ignoring the bad checksums). Example: 40b downloaded (plexus-utils-1.5.6.pom) [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = '8394a409e7b98020aac9429157265db0fb8cfac6'; remote = '?xml' - IGNORING [WARNING] POM for 'org.codehaus.plexus:plexus-utils:pom:1.5.6:runtime' is invalid. Please help! Invalid checksums on deploy when using webdav without extension --- Key: MNG-4301 URL: http://jira.codehaus.org/browse/MNG-4301 Project: Maven 2 3 Issue Type: Bug Components: Deployment Affects Versions: 2.2.1 Environment: n/a Reporter: Kevin Shekleton Priority: Blocker With maven 2.2.1, our deployments via webdav are producing invalid checksums, similar to the issue reported in MNG-4235. From maven 2.0.8 and previous, the following build extension was required to deploy via webdav: extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-webdav/artifactId version1.0-beta-2/version /extension /extensions Starting with maven 2.0.9 (see MNG-3418), webdav was included by default and the aforementioned build extension must be removed from the project. If it was included in the project the deployment would fail as Maven would report multiple versions of wagon-webdav present. With maven 2.2.0, our deployment suffered from invalid checksums reported in MNG-4235. With maven 2.2.1, we still see the invalid checksums on deployment as reported in MNG-4235. However, I've found that if you add the above build extension into the project, we don't experience this issue (of generating invalid checksums). Is this workaround an intentional change brought about by the fix of MNG-4235? -- 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: (MSHADE-83) Allow filters to work when creating the sources jar
Allow filters to work when creating the sources jar --- Key: MSHADE-83 URL: http://jira.codehaus.org/browse/MSHADE-83 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 1.3.3 Reporter: Jakob Korherr Attachments: shade-filter-sources-test.patch, shade-filter-sources.patch While using the maven-shade-plugin for Apache MyFaces I ran into this error: I use a filter to include a subset of classes from another artifact. Everything works fine for the binary artifact, but when creating the -sources.jar (createSourcesJar = true) the filter does not apply. After some digging in the code I found out that SimpleFilter gets a Set of jar files for which it should be applied. Here, however, only the binary jar file is added and not also the -sources.jar file. Thus the canFilter() check fails later when creating the -sources.jar via shader.shade(). The attached patch solves this problem by adding the -sources.jar to the Set of jar files if createSourcesJar is true. I already tested it and it works just fine. Furthermore the test-patch provides a JUnit test case for this scenario. Thanks for looking at this, Jakob -- 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: (SCM-483) Update SCM Perforce Provider to use P4Java
[ http://jira.codehaus.org/browse/SCM-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Johnson updated SCM-483: -- Attachment: maven-scm-perforce-p4java.jar I have implemented an SCM Provider using the p4java APIs. Not everything is implemented but I have been able to prepare/preform releases from Continuum and the Release Plugin. Update SCM Perforce Provider to use P4Java -- Key: SCM-483 URL: http://jira.codehaus.org/browse/SCM-483 Project: Maven SCM Issue Type: Improvement Components: maven-scm-provider-perforce Affects Versions: 1.2 Reporter: Tom Rodriguez Fix For: future Attachments: maven-scm-perforce-p4java.jar Perforce has developed a new Java Native API for access to perforce called P4Java. You can access it here: ftp://ftp.perforce.com/perforce/r09.1/bin.java/p4java.zip. This completely reworked API does not require that the p4 client be installed on the system. The SCM Perforce Provider should be modified to use this new native java API to eliminate the many issues involved with depending on the p4 executable. -- 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: (SCM-483) Update SCM Perforce Provider to use P4Java
[ http://jira.codehaus.org/browse/SCM-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=229869#action_229869 ] Olivier Lamy commented on SCM-483: -- is the p4java available in central repo ? If not it will be difficult to add this in ASF code base. Thanks Update SCM Perforce Provider to use P4Java -- Key: SCM-483 URL: http://jira.codehaus.org/browse/SCM-483 Project: Maven SCM Issue Type: Improvement Components: maven-scm-provider-perforce Affects Versions: 1.2 Reporter: Tom Rodriguez Fix For: future Attachments: maven-scm-perforce-p4java.jar Perforce has developed a new Java Native API for access to perforce called P4Java. You can access it here: ftp://ftp.perforce.com/perforce/r09.1/bin.java/p4java.zip. This completely reworked API does not require that the p4 client be installed on the system. The SCM Perforce Provider should be modified to use this new native java API to eliminate the many issues involved with depending on the p4 executable. -- 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: (MANTTASKS-197) Dependency with packaging=pom shows up in the classpath
[
http://jira.codehaus.org/browse/MANTTASKS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=229874#action_229874
]
Knut Forkalsrud commented on MANTTASKS-197:
---
Well, it is {{asm-parent}} that plays the role of my common-dependency POM.
Even if I add {{packagingpom/packaging}} to my project POM (foo) it does
not change the behavior.
If you copy the code snippets above into two files in the same directory
({{pom.xml}} and {{build.xml}} respectively) and run {{ant}}, it should be
clearer.
Dependency with packaging=pom shows up in the classpath
---
Key: MANTTASKS-197
URL: http://jira.codehaus.org/browse/MANTTASKS-197
Project: Maven 2.x Ant Tasks
Issue Type: Bug
Components: dependencies task
Affects Versions: 2.1.1
Environment: Mac OSX, Ant 1.8.1
Reporter: Knut Forkalsrud
My use case is that I have a set of common dependencies that I use across
many projects.
In order to save me some typing I created a pom whose sole purpose is to
depend on all
the common dependencies, so that each of my projects can depend on only this
one pom.
The problem is that the pom file gets included in the classpath, an the junit
task shows
an annoying error because it can't make sense of it as a directory or jar
file.
A relatively simple testcase to show the issue is this pom.xml:
{code:xml}project xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
modelVersion4.0.0/modelVersion
groupIdfoo/groupId
artifactIdbar/artifactId
version1.0/version
dependencies
dependency
groupIdasm/groupId
artifactIdasm-parent/artifactId
version3.1/version
typepom/type
/dependency
/dependencies
/project
{code}
An the following build.xml in the same directory:
{code:xml}
?xml version=1.0 encoding=UTF-8?
project name=foo default=test
xmlns:artifact=antlib:org.apache.maven.artifact.ant
target name=test
artifact:pom file=${basedir}/pom.xml id=maven.project/
artifact:dependencies pathId=maven2.test.classpath
filesetId=test.fileset
pom refid=maven.project/
/artifact:dependencies
echo${toString:maven2.test.classpath}/echo
/target
/project
{code}
When I run this I expect the output from echo to list the classpath
consisting of the jars dependencies from {{asm-parent}}. That pom happens to
have no jar dependencies, so I expect the output to be empty. Instead I get
the path of the pom file.
In a more realistic example I will use this as a classpath argument to
junit and get an error like:
{noformat}
Unable to obtain resource from
/Users/knut/.m2/repository/asm/asm-parent/3.1/asm-parent-3.1.pom:
java.util.zip.ZipException: error in opening zip file
[junit] Unable to obtain resource from
/Users/knut/.m2/repository/asm/asm-parent/3.1/asm-parent-3.1.pom:
[junit] java.util.zip.ZipException: error in opening zip file
[junit] at java.util.zip.ZipFile.open(Native Method)
[junit] at java.util.zip.ZipFile.init(ZipFile.java:114)
[junit] at java.util.jar.JarFile.init(JarFile.java:135)
[junit] at java.util.jar.JarFile.init(JarFile.java:99)
[junit] at
org.apache.tools.ant.AntClassLoader.getResourceURL(AntClassLoader.java:1002)
[junit] at
org.apache.tools.ant.AntClassLoader$ResourceEnumeration.findNextResource(AntClassLoader.java:145)
[junit] at
org.apache.tools.ant.AntClassLoader$ResourceEnumeration.init(AntClassLoader.java:109)
[junit] at
org.apache.tools.ant.AntClassLoader.findResources(AntClassLoader.java:949)
[junit] at
org.apache.tools.ant.AntClassLoader.getNamedResources(AntClassLoader.java:918)
[junit] at
org.apache.tools.ant.loader.AntClassLoader5.getResources(AntClassLoader5.java:54)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.checkForkedPath(JUnitTask.java:1135)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeAsForked(JUnitTask.java:1011)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:811)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeOrQueue(JUnitTask.java:1808)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:760)
[junit] at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
[junit] at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
[junit] at
[jira] Commented: (MSHADE-83) Allow filters to work when creating the sources jar
[ http://jira.codehaus.org/browse/MSHADE-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=229875#action_229875 ] Mark Struberg commented on MSHADE-83: - The patch is imo definitely better than our current implementation which doesn't filter source jars at all. The users need be be carefully if they filter only with includes of course, because there is currently only one filter ruleset available for both class jars and source jars. Allow filters to work when creating the sources jar --- Key: MSHADE-83 URL: http://jira.codehaus.org/browse/MSHADE-83 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 1.3.3 Reporter: Jakob Korherr Assignee: Mark Struberg Attachments: shade-filter-sources-test.patch, shade-filter-sources.patch While using the maven-shade-plugin for Apache MyFaces I ran into this error: I use a filter to include a subset of classes from another artifact. Everything works fine for the binary artifact, but when creating the -sources.jar (createSourcesJar = true) the filter does not apply. After some digging in the code I found out that SimpleFilter gets a Set of jar files for which it should be applied. Here, however, only the binary jar file is added and not also the -sources.jar file. Thus the canFilter() check fails later when creating the -sources.jar via shader.shade(). The attached patch solves this problem by adding the -sources.jar to the Set of jar files if createSourcesJar is true. I already tested it and it works just fine. Furthermore the test-patch provides a JUnit test case for this scenario. Thanks for looking at this, Jakob -- 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] Work started: (MSHADE-83) Allow filters to work when creating the sources jar
[ http://jira.codehaus.org/browse/MSHADE-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MSHADE-83 started by Mark Struberg. Allow filters to work when creating the sources jar --- Key: MSHADE-83 URL: http://jira.codehaus.org/browse/MSHADE-83 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 1.3.3 Reporter: Jakob Korherr Assignee: Mark Struberg Attachments: shade-filter-sources-test.patch, shade-filter-sources.patch While using the maven-shade-plugin for Apache MyFaces I ran into this error: I use a filter to include a subset of classes from another artifact. Everything works fine for the binary artifact, but when creating the -sources.jar (createSourcesJar = true) the filter does not apply. After some digging in the code I found out that SimpleFilter gets a Set of jar files for which it should be applied. Here, however, only the binary jar file is added and not also the -sources.jar file. Thus the canFilter() check fails later when creating the -sources.jar via shader.shade(). The attached patch solves this problem by adding the -sources.jar to the Set of jar files if createSourcesJar is true. I already tested it and it works just fine. Furthermore the test-patch provides a JUnit test case for this scenario. Thanks for looking at this, Jakob -- 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] Closed: (MSHADE-83) Allow filters to work when creating the sources jar
[ http://jira.codehaus.org/browse/MSHADE-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg closed MSHADE-83. --- Resolution: Fixed Fix Version/s: 1.3.4 patch reviewed, tested and applied. Txs Jakob! Allow filters to work when creating the sources jar --- Key: MSHADE-83 URL: http://jira.codehaus.org/browse/MSHADE-83 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 1.3.3 Reporter: Jakob Korherr Assignee: Mark Struberg Fix For: 1.3.4 Attachments: shade-filter-sources-test.patch, shade-filter-sources.patch While using the maven-shade-plugin for Apache MyFaces I ran into this error: I use a filter to include a subset of classes from another artifact. Everything works fine for the binary artifact, but when creating the -sources.jar (createSourcesJar = true) the filter does not apply. After some digging in the code I found out that SimpleFilter gets a Set of jar files for which it should be applied. Here, however, only the binary jar file is added and not also the -sources.jar file. Thus the canFilter() check fails later when creating the -sources.jar via shader.shade(). The attached patch solves this problem by adding the -sources.jar to the Set of jar files if createSourcesJar is true. I already tested it and it works just fine. Furthermore the test-patch provides a JUnit test case for this scenario. Thanks for looking at this, Jakob -- 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: (MSHADE-83) Allow filters to work when creating the sources jar
[ http://jira.codehaus.org/browse/MSHADE-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=229878#action_229878 ] Jakob Korherr commented on MSHADE-83: - Big thx, Mark! Allow filters to work when creating the sources jar --- Key: MSHADE-83 URL: http://jira.codehaus.org/browse/MSHADE-83 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 1.3.3 Reporter: Jakob Korherr Assignee: Mark Struberg Fix For: 1.3.4 Attachments: shade-filter-sources-test.patch, shade-filter-sources.patch While using the maven-shade-plugin for Apache MyFaces I ran into this error: I use a filter to include a subset of classes from another artifact. Everything works fine for the binary artifact, but when creating the -sources.jar (createSourcesJar = true) the filter does not apply. After some digging in the code I found out that SimpleFilter gets a Set of jar files for which it should be applied. Here, however, only the binary jar file is added and not also the -sources.jar file. Thus the canFilter() check fails later when creating the -sources.jar via shader.shade(). The attached patch solves this problem by adding the -sources.jar to the Set of jar files if createSourcesJar is true. I already tested it and it works just fine. Furthermore the test-patch provides a JUnit test case for this scenario. Thanks for looking at this, Jakob -- 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: (MNG-4301) Invalid checksums on deploy when using webdav without extension
[ http://jira.codehaus.org/browse/MNG-4301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=229883#action_229883 ] Brian Fox commented on MNG-4301: See the trick is that maven is producing these junk checksums upon upload. Even if you fix it, until you repair the checksums in the repo, you will continue to get the checksum errors whenever someone downloads those artifacts. The workaround for this bug is to stop producing bad checksums, and then repair the ones that are broken. Stop producing bad checksums by: Not using Maven 2.2.0 or not using a wagon with httpclient against an authenticated repo unless you disable preemptive authentication. If you're using Nexus, it can repair the checksums simply by doing a Rebuild Maven Metadata on the subfolder of the repo where your busted checksums are. Invalid checksums on deploy when using webdav without extension --- Key: MNG-4301 URL: http://jira.codehaus.org/browse/MNG-4301 Project: Maven 2 3 Issue Type: Bug Components: Deployment Affects Versions: 2.2.1 Environment: n/a Reporter: Kevin Shekleton Priority: Blocker With maven 2.2.1, our deployments via webdav are producing invalid checksums, similar to the issue reported in MNG-4235. From maven 2.0.8 and previous, the following build extension was required to deploy via webdav: extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-webdav/artifactId version1.0-beta-2/version /extension /extensions Starting with maven 2.0.9 (see MNG-3418), webdav was included by default and the aforementioned build extension must be removed from the project. If it was included in the project the deployment would fail as Maven would report multiple versions of wagon-webdav present. With maven 2.2.0, our deployment suffered from invalid checksums reported in MNG-4235. With maven 2.2.1, we still see the invalid checksums on deployment as reported in MNG-4235. However, I've found that if you add the above build extension into the project, we don't experience this issue (of generating invalid checksums). Is this workaround an intentional change brought about by the fix of MNG-4235? -- 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: (MRESOURCES-128) Custom resource filters
[
http://jira.codehaus.org/browse/MRESOURCES-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=229884#action_229884
]
Olivier Lamy commented on MRESOURCES-128:
-
why not using
[http://maven.apache.org/shared/maven-filtering/apidocs/org/apache/maven/shared/filtering/MavenResourcesFiltering.html]
?
Custom resource filters
---
Key: MRESOURCES-128
URL: http://jira.codehaus.org/browse/MRESOURCES-128
Project: Maven 2.x Resources Plugin
Issue Type: New Feature
Reporter: Laurent Martelli
Assignee: Olivier Lamy
Attachments: MRESOURCES-128
It would be very nice to be able to use some custom resource filters in
addition to properties substitutions. For instance, one may want to
optimize PNG images which may contain big proprietary chunks inserted by
the editing software, which are totally useless to the running webapp, but
usefull for editing the image.
Being able to run an external program (like pngcrush in the case mentioned
above) may be an option, but for maximum portability, a Java interface would
be better (filtering PNG chunks is actually easy, and I already have a few
Java classes to do that). The interface could look like this :
public interface ResourceFilter {
void filterResource(InputStream input, OutputStream output, MavenContext
context);
}
The context (I don't know if the class exists) could be used to retrieve the
filter's configuration (some criteria specifying which chunks to include or
exclude, for instance). Or maybe Maven is able to directly configure beans
using their properties.
--
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: (MRESOURCES-128) Custom resource filters
[
http://jira.codehaus.org/browse/MRESOURCES-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MRESOURCES-128:
Attachment: MRESOURCES-128
here a patch.
If it's fine, I can push this.
Thanks.
Custom resource filters
---
Key: MRESOURCES-128
URL: http://jira.codehaus.org/browse/MRESOURCES-128
Project: Maven 2.x Resources Plugin
Issue Type: New Feature
Reporter: Laurent Martelli
Assignee: Olivier Lamy
Attachments: MRESOURCES-128
It would be very nice to be able to use some custom resource filters in
addition to properties substitutions. For instance, one may want to
optimize PNG images which may contain big proprietary chunks inserted by
the editing software, which are totally useless to the running webapp, but
usefull for editing the image.
Being able to run an external program (like pngcrush in the case mentioned
above) may be an option, but for maximum portability, a Java interface would
be better (filtering PNG chunks is actually easy, and I already have a few
Java classes to do that). The interface could look like this :
public interface ResourceFilter {
void filterResource(InputStream input, OutputStream output, MavenContext
context);
}
The context (I don't know if the class exists) could be used to retrieve the
filter's configuration (some criteria specifying which chunks to include or
exclude, for instance). Or maybe Maven is able to directly configure beans
using their properties.
--
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: (MENFORCER-102) Several minor site-bugs
Several minor site-bugs
---
Key: MENFORCER-102
URL: http://jira.codehaus.org/browse/MENFORCER-102
Project: Maven 2.x Enforcer Plugin
Issue Type: Bug
Components: Standard Rules
Affects Versions: 1.0-beta-1
Reporter: Robert Scholte
Priority: Minor
Attachments: enforces-rules_sitefix.patch
The current site contains a couple of bugs:
* When referring to the outputDirectory, the wrong expression is used: instead
of ${project.outputDirectory} people should use
\${project.build.outputDirectory} (also attention for the escaped dollar-sign)
* List items should be split by an empty row.
Fix attached
--
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
