[jira] Updated: (MRESOURCES-77) Filters for copy-resources goal in plugin configuration section are ignored
[
http://jira.codehaus.org/browse/MRESOURCES-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fabian Bauschulte updated MRESOURCES-77:
Attachment: MRESOURCES-77.patch
> Filters for copy-resources goal in plugin configuration section are ignored
> ---
>
> Key: MRESOURCES-77
> URL: http://jira.codehaus.org/browse/MRESOURCES-77
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Daniel Uribe
> Attachments: filter-test.zip, MRESOURCES-77.patch
>
>
> I need to have a project where I can create multiple versions of resource
> files using different filters, I am trying to use the copy-resources goal for
> this purpose by making it part of the generate-resource phase and specifying
> the filters and resources under the plugin section of the POM.
>
>
> maven-resources-plugin
>
>
> config-a
> generate-resources
>
> copy-resources
>
>
>
>
> ${basedir}/target/generated-resources/a
>
>
> a.properties
>
>
>
>
> etc/build
>
> true
>
>
> jndi.properties
>
>
>
>
>
>
> config-b
> generate-resources
>
> copy-resources
>
>
>
>
> ${basedir}/target/generated-resources/b
>
>
> b.properties
>
>
>
>
> etc/build
>
> true
>
>
> jndi.properties
>
>
>
>
>
>
>
>
>
> After doing some debugging, the problem seems to be caused by a combination
> of things:
> - The CopyResourcesMojo doesn't define its own filters field, so it inherits
> the configuration from the ResourcesMojo. That configuration specifies that
> it uses ${project.build.filters} by default. This is part of the plugin.xml
> in the repository as
>implementation="java.util.List">${project.build.filters}
> - When the merging of the plugin.xml configuration from the repository with
> the configuration from the POM is done, it includes the filters that were
> specified in the POM, but also includes the default value and implementation
> attribute. Hence, when the plugin fields are populated (in
> DefaultPluginManager.populatePluginFields), it gets the value
> ${project.build.filters} instead of using the children from the POM
> configuration.
> I am not really sure what could be a good solution. Removing the default of
> ${project.build.filters} for the CopyResourcesMojo would make this scenario
> work, but it would make the filters required when the plugin is declared in
> the plugins section.
--
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] Kommentiert: (MCHECKSTYLE-45) It should be possible to configure checkstyle:check to fail on "warnings".
[ http://jira.codehaus.org/browse/MCHECKSTYLE-45?page=comments#action_67209 ] Fabian Bauschulte commented on MCHECKSTYLE-45: -- I want to make sure that no version with checkstyle warnings (for example missing javadoc comments) is deployed. I am using the checkstyle eclipse plugin. While developing it can sometimes very annoying to change all your rules to "error" - for example if you only want to try something out. In this case it would be very helpful to have this option. The default would be to fail "on error" - the check would only fail change the parameter. > It should be possible to configure checkstyle:check to fail on "warnings". > -- > > Key: MCHECKSTYLE-45 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-45 > Project: Maven 2.x Checkstyle Plugin > Type: New Feature > Versions: 2.1 > Reporter: Fabian Bauschulte > Attachments: MCHECKSTYLE-45-maven-checkstyle-plugin.patch > > > As mentioned in MCHECKSTYLE-38 it should be possible to configure that > "checkstyle:check" fails on warnings or not. -- 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: (MPMD-38) Add Posibility to excludes files in Cpd
Add Posibility to excludes files in Cpd --- Key: MPMD-38 URL: http://jira.codehaus.org/browse/MPMD-38 Project: Maven 2.x Pmd Plugin Issue Type: Improvement Reporter: Fabian Bauschulte Fix For: 2.2 Sometimes there are Classes, that you do not want to be checked (legacy code, generated classes). In some cases (for instance generated classes) there a lot of warnings that cannot be removed. In this case the "false" warnings are hiding the "important" warnings. -- 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: (MPMD-38) Add Posibility to excludes files in Cpd
[ http://jira.codehaus.org/browse/MPMD-38?page=all ] Fabian Bauschulte updated MPMD-38: -- Attachment: MPMD-38-maven-pmd-plugin.patch > Add Posibility to excludes files in Cpd > --- > > Key: MPMD-38 > URL: http://jira.codehaus.org/browse/MPMD-38 > Project: Maven 2.x Pmd Plugin > Issue Type: Improvement >Reporter: Fabian Bauschulte > Fix For: 2.2 > > Attachments: MPMD-38-maven-pmd-plugin.patch > > > Sometimes there are Classes, that you do not want to be checked (legacy code, > generated classes). In some cases (for instance generated classes) there a > lot of warnings that cannot be removed. In this case the "false" warnings are > hiding the "important" warnings. -- 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: (MSUREFIRE-158) Add Parameter that the output of the test to System.out only appears in the surefire logfiles
Add Parameter that the output of the test to System.out only appears in the surefire logfiles - Key: MSUREFIRE-158 URL: http://jira.codehaus.org/browse/MSUREFIRE-158 Project: Maven 2.x Surefire Plugin Issue Type: New Feature Affects Versions: 2.3 Reporter: Fabian Bauschulte Many Tests are using a logger that prints to the console. Sometimes you cannot see the summary because there a lot of logging messages. It would be very helpful to have a parameter, that this output only appears in the surefire log files. If a test fails, you have the output in the place you need it. -- 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: (MSUREFIRE-158) Add Parameter that the output of the test to System.out only appears in the surefire logfiles
[ http://jira.codehaus.org/browse/MSUREFIRE-158?page=comments#action_72235 ] Fabian Bauschulte commented on MSUREFIRE-158: - Selecting the version was a mistake - I meant to leave it unassigned because it is a new feature. Sorry for that. > Add Parameter that the output of the test to System.out only appears in the > surefire logfiles > - > > Key: MSUREFIRE-158 > URL: http://jira.codehaus.org/browse/MSUREFIRE-158 > Project: Maven 2.x Surefire Plugin > Issue Type: New Feature >Affects Versions: 2.3 >Reporter: Fabian Bauschulte > > Many Tests are using a logger that prints to the console. Sometimes you > cannot see the summary because there a lot of logging messages. It would be > very helpful to have a parameter, that this output only appears in the > surefire log files. If a test fails, you have the output in the place you > need it. -- 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: (MRELEASE-91) Updating of dependencyManagement inconsistent with updating of dependencies with regard to SNAPSHOTs
[ http://jira.codehaus.org/browse/MRELEASE-91?page=comments#action_74061 ] Fabian Bauschulte commented on MRELEASE-91: --- I had the same problem and have tried the patch. I works fine for me. > Updating of dependencyManagement inconsistent with updating of dependencies > with regard to SNAPSHOTs > > > Key: MRELEASE-91 > URL: http://jira.codehaus.org/browse/MRELEASE-91 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 > Environment: maven 2.0.4, win XP >Reporter: Marcel Schutte > Assigned To: Brett Porter > Fix For: 2.0-beta-4 > > Attachments: changes.xml, depmgnt.zip, MRELEASE-91.patch, > MRELEASE-91.patch-2, release.patch, rewriting-dev-phase.apt, > snapshots-reactor-in-dependencies.tar, > snapshots-reactor-in-dependency-management.tar > > > The mechanism in release:prepare for creating the new development version of > POM's handles snapshots that are part of the current reactor build > differently for dependencyManagement and for dependencies. > A snapshot version in a dependencies section will be updated to the next > development version whereas one in dependencyManagement won't. > The attached patch will change this behavior. It will update a snapshot > version under dependencyManagement if and only if it is part of the current > reactor build. > Note that dependencies cannot contain snapshot versions that are not part of > the current reactor, but dependencyManagement can. I suggest to forbid this > too. > A second suggestion is to introduce a parameter to control the updating of > snapshot dependencies in both dependencyManagement and dependencies sections. > Either leave them at the released version or update them to the new > development version. This touches on the discussion in MRELEASE-36 about the > developer having to knowingly choose to use a new development version. I > would be fine with using a parameter to select the behavior as obtained with > my patch. My central point is that dependencyManagement and dependencies > snapshots should behave the same. -- 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: (MANTRUN-41) Easy access to dependency jars
[
http://jira.codehaus.org/browse/MANTRUN-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fabian Bauschulte updated MANTRUN-41:
-
Attachment: MANTRUN-41-maven-antrun-plugin.patch
> Easy access to dependency jars
> --
>
> Key: MANTRUN-41
> URL: http://jira.codehaus.org/browse/MANTRUN-41
> Project: Maven 2.x Antrun Plugin
> Issue Type: New Feature
>Affects Versions: 1.1
>Reporter: Patrick Lightbody
>Assignee: Kenney Westerhof
> Fix For: 1.2
>
> Attachments: MANTRUN-41-maven-antrun-plugin.patch
>
>
> It would be nice to have an easy access to the dependency jars located in
> ~/.m2. A couple ideas tossed around in #maven were:
> ${dep.XXX.YYY.jar}, where XXX and YYY are the groupId and artifactId
> OR
> a new Ant task:
>
> Where you could then reference ${jarpath}
--
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: (MDEPLOY-45) Classifier not supported by deploy:deploy
Classifier not supported by deploy:deploy - Key: MDEPLOY-45 URL: http://jira.codehaus.org/browse/MDEPLOY-45 Project: Maven 2.x Deploy Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Fabian Bauschulte Priority: Critical I am using classifieres in some projects (jar, war, ear) and installing the artefacts works fine. I am getting an Exception during the deployment of the artifacts. -- 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: (MDEPLOY-45) Classifier not supported by deploy:deploy
[ http://jira.codehaus.org/browse/MDEPLOY-45?page=all ] Fabian Bauschulte updated MDEPLOY-45: - Attachment: MDEPLOY-45-maven-deploy-plugin.patch Fixed analog maven-install-plugin > Classifier not supported by deploy:deploy > - > > Key: MDEPLOY-45 > URL: http://jira.codehaus.org/browse/MDEPLOY-45 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Fabian Bauschulte >Priority: Critical > Attachments: MDEPLOY-45-maven-deploy-plugin.patch > > > I am using classifieres in some projects (jar, war, ear) and installing the > artefacts works fine. I am getting an Exception during the deployment of the > artifacts. -- 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-2759) Resolving transitive dependencies of artefacts with classifiers fails
Resolving transitive dependencies of artefacts with classifiers fails - Key: MNG-2759 URL: http://jira.codehaus.org/browse/MNG-2759 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4 Environment: Windows XP, Maven 2.0.4 Reporter: Fabian Bauschulte Attachments: project.zip I have the following projects with subprojects projectA, projectB and projectC. projectA depends on projectB, projectC depends on projectB. All projects use classifiers: ... projectB org.apache.maven.plugins maven-jar-plugin someclassifier test projectB 1.0.0 someclassifier When running "mvn clean install" on the the parent works fine. But running "mvn install" only in projectC fails: C:\Data\maven-test\projectC>mvn clean install [INFO] Scanning for projects... [INFO] [INFO] Building Unnamed - test:projectC:jar:1.0.0 [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory C:\Data\maven-test\projectC\target [INFO] Deleting directory C:\Data\maven-test\projectC\target\classes [INFO] Deleting directory C:\Data\maven-test\projectC\target\test-classes [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. Downloading: http://repo1.maven.org/maven2/test/projectB/1.0.0/projectB-1.0.0.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) [INFO] [compiler:compile] Compiling 1 source file to C:\Daten\maven-test\projectC\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\Data\maven-test\projectC\src\main\java\ClassC.java:[3,12] cannot find symbol symbol : class ClassA location: package test [INFO] -- 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: (MRELEASE-6) Multiproject Release: No check in
[ http://jira.codehaus.org/browse/MRELEASE-6?page=comments#action_62756 ] Fabian Bauschulte commented on MRELEASE-6: -- I am using CVS and eclipse (workspace). All my projects are CVS modules: parent and moduleA, modulesB, moduleC: \parent \moduleA \moduleB \moduleC Every project has the section "xxx" set to the correct cvs location. Refactoring of the package structure is not possible in my case (legacy system). I don´t see a way to use the multiproject release - any solution would be highly appreciated. At the moment I am forced to release all modules "my hand": \parent\mvn -N release:prepare release:perform \moduleA\mvn release:prepare release:perform \moduleB\mvn release:prepare release:perform \moduleC\mvn release:prepare release:perform Is there any chance to get this bug fixed in the next time?? > Multiproject Release: No check in > - > > Key: MRELEASE-6 > URL: http://jira.codehaus.org/browse/MRELEASE-6 > Project: Maven 2.x Release Plugin > Type: Bug > Environment: Windows XP, Eclipse Workspace > Reporter: Bernd Mau > Priority: Critical > > > I tried to release a multiproject with 5 modules (on a Branch). Well, > the POMs of all modules are changed and there are some dependencies > which have been updated correctly. But only the master has been checked > in correctly. > I'm changed the recommended layout, to fit in an eclipse workspace. I > have one master at the same level as the other modules. > The module section of the master pom.xml: > > ../hhla.library.pom > ../hhla.library.site > ../hhla.lang > ../hhla.common.log4jx > -- 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: (MPMD-25) Character "\" in Xref-Link in cpd report causes problems with some browsers
Character "\" in Xref-Link in cpd report causes problems with some browsers Key: MPMD-25 URL: http://jira.codehaus.org/browse/MPMD-25 Project: Maven 2.x Pmd Plugin Type: Bug Environment: Firefox Reporter: Fabian Bauschulte The Xref-Link (href) in the cpd-report contains the character "\". This leads to a "404 not found" with some browser which are trying to escape this character. The solution is a substitution of "\" through "/" (analog surefire-report). -- 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: (MPMD-25) Character "\" in Xref-Link in cpd report causes problems with some browsers
[ http://jira.codehaus.org/browse/MPMD-25?page=all ] Fabian Bauschulte updated MPMD-25: -- Attachment: MPMD-25-maven-pdm-plugin.patch > Character "\" in Xref-Link in cpd report causes problems with some browsers > > > Key: MPMD-25 > URL: http://jira.codehaus.org/browse/MPMD-25 > Project: Maven 2.x Pmd Plugin > Type: Bug > Environment: Firefox > Reporter: Fabian Bauschulte > Attachments: MPMD-25-maven-pdm-plugin.patch > > > The Xref-Link (href) in the cpd-report contains the character "\". This leads > to a "404 not found" with some browser which are trying to escape this > character. The solution is a substitution of "\" through "/" (analog > surefire-report). -- 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: (MDEPLOY-31) deploy-file: Custom description in generated pom
deploy-file: Custom description in generated pom Key: MDEPLOY-31 URL: http://jira.codehaus.org/browse/MDEPLOY-31 Project: Maven 2.x Deploy Plugin Type: Improvement Reporter: Fabian Bauschulte It would be very helpful during "deploy-file" to pass a custom description (in the command line) to the generated pom. If an artefact has no dependencies there is normally no need to write a pom except for the description. -- 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: (MDEPLOY-31) deploy-file: Custom description in generated pom
[ http://jira.codehaus.org/browse/MDEPLOY-31?page=all ] Fabian Bauschulte updated MDEPLOY-31: - Attachment: MDEPLOY-31-maven-deploy-plugin.patch > deploy-file: Custom description in generated pom > > > Key: MDEPLOY-31 > URL: http://jira.codehaus.org/browse/MDEPLOY-31 > Project: Maven 2.x Deploy Plugin > Type: Improvement > Reporter: Fabian Bauschulte > Attachments: MDEPLOY-31-maven-deploy-plugin.patch > > > It would be very helpful during "deploy-file" to pass a custom description > (in the command line) to the generated pom. If an artefact has no > dependencies there is normally no need to write a pom except for the > description. -- 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: (MCHECKSTYLE-40) Some checks need the compiled classes (for instance JavadocMethod)
Some checks need the compiled classes (for instance JavadocMethod) -- Key: MCHECKSTYLE-40 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-40 Project: Maven 2.x Checkstyle Plugin Type: Bug Environment: Checkstyle 4.1 Reporter: Fabian Bauschulte Priority: Minor Attachments: example-project.zip Some standard checks - for instance "JavadocMethod" need the compiled classes; overwise terminate with an internal error. The documentation of checkstyle says for "JavadocMethod": [...] "The classpath may need to be configured to locate the class information. The classpath configuration is dependent on the mechanism used to invoke Checkstyle." Checkstyle tries to analyse if a thrown exception extends RuntimeException - if this information isn´t there it causes an error. It's possible that during site generation the compiled classes don't. If there isn't a general solution it would be helpful to place a workaround or a hint in the documentation. -- 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: (MCHECKSTYLE-45) It should be possible to configure checkstyle:check to fail on "warnings".
It should be possible to configure checkstyle:check to fail on "warnings". -- Key: MCHECKSTYLE-45 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-45 Project: Maven 2.x Checkstyle Plugin Type: New Feature Versions: 2.1 Reporter: Fabian Bauschulte As mentioned in MCHECKSTYLE-38 it should be possible to configure that "checkstyle:check" fails on warnings or not. -- 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: (MCHECKSTYLE-45) It should be possible to configure checkstyle:check to fail on "warnings".
[ http://jira.codehaus.org/browse/MCHECKSTYLE-45?page=all ] Fabian Bauschulte updated MCHECKSTYLE-45: - Attachment: MCHECKSTYLE-45-maven-checkstyle-plugin.patch > It should be possible to configure checkstyle:check to fail on "warnings". > -- > > Key: MCHECKSTYLE-45 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-45 > Project: Maven 2.x Checkstyle Plugin > Type: New Feature > Versions: 2.1 > Reporter: Fabian Bauschulte > Attachments: MCHECKSTYLE-45-maven-checkstyle-plugin.patch > > > As mentioned in MCHECKSTYLE-38 it should be possible to configure that > "checkstyle:check" fails on warnings or not. -- 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
