[jira] (MASSEMBLY-599) Mistake in javadoc for dependencySet/includes
[
https://jira.codehaus.org/browse/MASSEMBLY-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=296546#comment-296546
]
Björn Streicher commented on MASSEMBLY-599:
---
In addition, I think the description for all include and exclude-directives at
https://maven.apache.org/plugins/maven-assembly-plugin/assembly.html is also
wrong. Please correct!
Mistake in javadoc for dependencySet/includes
-
Key: MASSEMBLY-599
URL: https://jira.codehaus.org/browse/MASSEMBLY-599
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2.2, 2.3
Reporter: Alexander Kormushin
Priority: Minor
[Here|http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_dependencySet]
it's stated that fully qualified artifact coordinates in
dependencySet/includes/include* should be in form
*groupId:artifactId:type:version[:classifier]*
But actually accepted following form
*groupId:artifactId:type[:classifier]:version*
Fragment of source calculating artifact.id for filtering:
{code:title=.m2/repository/org/apache/maven/maven-artifact/2.2.1/maven-artifact-2.2.1-sources.jar!/org/apache/maven/artifact/DefaultArtifact.java}
public String getId()
{
return getDependencyConflictId() + : + getBaseVersion();
}
public String getDependencyConflictId()
{
StringBuffer sb = new StringBuffer();
sb.append( getGroupId() );
sb.append( : );
appendArtifactTypeClassifierString( sb );
return sb.toString();
}
private void appendArtifactTypeClassifierString( StringBuffer sb )
{
sb.append( getArtifactId() );
sb.append( : );
sb.append( getType() );
if ( hasClassifier() )
{
sb.append( : );
sb.append( getClassifier() );
}
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-599) Mistake in javadoc for dependencySet/includes
[
https://jira.codehaus.org/browse/MASSEMBLY-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=296546#comment-296546
]
Björn Streicher edited comment on MASSEMBLY-599 at 4/16/12 3:27 AM:
In addition, I think the description for all include and exclude-directives at
https://maven.apache.org/plugins/maven-assembly-plugin/assembly.html is also
wrong. Please correct!
By the way, it is correctly described on
https://maven.apache.org/plugins/maven-assembly-plugin/examples/single/including-and-excluding-artifacts.html
was (Author: bstreicher):
In addition, I think the description for all include and exclude-directives
at https://maven.apache.org/plugins/maven-assembly-plugin/assembly.html is also
wrong. Please correct!
Mistake in javadoc for dependencySet/includes
-
Key: MASSEMBLY-599
URL: https://jira.codehaus.org/browse/MASSEMBLY-599
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2.2, 2.3
Reporter: Alexander Kormushin
Priority: Minor
[Here|http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_dependencySet]
it's stated that fully qualified artifact coordinates in
dependencySet/includes/include* should be in form
*groupId:artifactId:type:version[:classifier]*
But actually accepted following form
*groupId:artifactId:type[:classifier]:version*
Fragment of source calculating artifact.id for filtering:
{code:title=.m2/repository/org/apache/maven/maven-artifact/2.2.1/maven-artifact-2.2.1-sources.jar!/org/apache/maven/artifact/DefaultArtifact.java}
public String getId()
{
return getDependencyConflictId() + : + getBaseVersion();
}
public String getDependencyConflictId()
{
StringBuffer sb = new StringBuffer();
sb.append( getGroupId() );
sb.append( : );
appendArtifactTypeClassifierString( sb );
return sb.toString();
}
private void appendArtifactTypeClassifierString( StringBuffer sb )
{
sb.append( getArtifactId() );
sb.append( : );
sb.append( getType() );
if ( hasClassifier() )
{
sb.append( : );
sb.append( getClassifier() );
}
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-599) Mistake in javadoc for dependencySet/includes
[
https://jira.codehaus.org/browse/MASSEMBLY-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=296546#comment-296546
]
Björn Streicher edited comment on MASSEMBLY-599 at 4/16/12 3:27 AM:
In addition, I think the description for all include and exclude-directives at
https://maven.apache.org/plugins/maven-assembly-plugin/assembly.html is also
wrong. Please correct!
By the way, it is described correctly on
https://maven.apache.org/plugins/maven-assembly-plugin/examples/single/including-and-excluding-artifacts.html
was (Author: bstreicher):
In addition, I think the description for all include and exclude-directives
at https://maven.apache.org/plugins/maven-assembly-plugin/assembly.html is also
wrong. Please correct!
By the way, it is correctly described on
https://maven.apache.org/plugins/maven-assembly-plugin/examples/single/including-and-excluding-artifacts.html
Mistake in javadoc for dependencySet/includes
-
Key: MASSEMBLY-599
URL: https://jira.codehaus.org/browse/MASSEMBLY-599
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2.2, 2.3
Reporter: Alexander Kormushin
Priority: Minor
[Here|http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_dependencySet]
it's stated that fully qualified artifact coordinates in
dependencySet/includes/include* should be in form
*groupId:artifactId:type:version[:classifier]*
But actually accepted following form
*groupId:artifactId:type[:classifier]:version*
Fragment of source calculating artifact.id for filtering:
{code:title=.m2/repository/org/apache/maven/maven-artifact/2.2.1/maven-artifact-2.2.1-sources.jar!/org/apache/maven/artifact/DefaultArtifact.java}
public String getId()
{
return getDependencyConflictId() + : + getBaseVersion();
}
public String getDependencyConflictId()
{
StringBuffer sb = new StringBuffer();
sb.append( getGroupId() );
sb.append( : );
appendArtifactTypeClassifierString( sb );
return sb.toString();
}
private void appendArtifactTypeClassifierString( StringBuffer sb )
{
sb.append( getArtifactId() );
sb.append( : );
sb.append( getType() );
if ( hasClassifier() )
{
sb.append( : );
sb.append( getClassifier() );
}
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4391) DependencyManagement should allow replaceWith to manage use of re-named, woven, instrumented or compatible artifacts
[
https://jira.codehaus.org/browse/MNG-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=296553#comment-296553
]
Sören Chittka commented on MNG-4391:
-
+1 for having this in 3.1
I really like the syntax suggested above. It makes clear what is intended. If
this is to much 'smoke-and-mirrors' a decent IDE can make visible what is going
on.
DependencyManagement should allow replaceWith to manage use of re-named,
woven, instrumented or compatible artifacts
--
Key: MNG-4391
URL: https://jira.codehaus.org/browse/MNG-4391
Project: Maven 2 3
Issue Type: Improvement
Components: Dependencies
Affects Versions: 2.2.1
Reporter: Neale
Fix For: Issues to be reviewed for 3.x
[if only this was a later version of JIRA I'd have not lost all of what I
just typed, as I could use Mylyn instead of the web UI. here goes again...]
The challenge of using a different artifact instead of the one that is
specified in a POM that you are consuming is not an easy one.
Examples where this hits uses is:
- the artifact name and packaging changes that Spring made at 2.5.6A (which
was a big improvement)
- wanting to use SLF4J instead of Apache commons logging (i.e. use something
that provides the same API, but is an entirely different project)
- wanting to use your own derivation of a public artifact
- wanting to use a woven/instrumented version of a public artifact
The current approach to replacing, say org.springframework : spring-beans
with org.springframework : org.springframework.beans is to do ('scuse the
shorthand):
{code:xml}
dependencyManagement
dependencies
dependency
groupIdcom.sun.jersey.contribs/groupId
artifactIdjersey-spring/artifactId
exclusions
org.springframework : spring-beans
/exclusions
/dependency
... repeat for every artifact that uses spring-beans, and then add more
if adding another artifact
/dependencies
/dependencyManagement
{code}
to exclude it, and then globally include the replacement using:
{code:xml}
dependencies
dependency
groupIdorg.springframework/groupId
artifactidorg.springframework.beans/groupId
version${spring.version}/version
/dependency
/dependencies
{code}
This is error prone, and could be made far easier by an extension to
dependencies, which would remove the need to know what artifacts
(jersey-spring in the above example) use the artifact that you are replacing.
Here's how it would look:
{code:xml}
dependencyManagement
!-- this declares the version we want to use if this artifact is in use --
dependencies
dependency
groupIdorg.springframework/groupId
artifactidorg.springframework.beans/groupId
version${spring.version}/version
/dependency
!-- This deals with artifact name change --
dependency
groupIdorg.springframework/groupId
artifactidspring-beans/groupId
replaceWith !-- list of dependency elements --
dependency
groupIdorg.springframework/groupId
artifactidorg.springframework.beans/groupId
/dependency
!-- more dependency elements could be added here if an artifact
has been split --
/replaceWith
/dependency
/dependencies
{code}
NOTE:
- Nothing is specified in dependencies so no artifacts are globally added
where they may not be needed. This means we can develop a project wide
parent pom.xml.
- Artifacts can have been split and merged
- Derived artifacts, such as instrumented ones can easily be substituted, and
could be selectively substituted using profiles.
--
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] (MRELEASE-555) update versions does not update intermodule dependencies
[ https://jira.codehaus.org/browse/MRELEASE-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=296558#comment-296558 ] Rautureau commented on MRELEASE-555: The problem still there with version 2.2.1 and 2.2.2 of the plugin update versions does not update intermodule dependencies Key: MRELEASE-555 URL: https://jira.codehaus.org/browse/MRELEASE-555 Project: Maven 2.x Release Plugin Issue Type: Bug Components: update-versions Affects Versions: 2.0 Environment: Maven 2.2.1, JDK 6, XP SP3 Reporter: Michael Osipov I recently tried the update-versions goal which is really nice and worked well. I cleaned my local repo today and reran mvn package on a multi-module project. It failed due tue a depenceny error. My project was previously on version 2.6.1-SNAPSHOT. Module war depends on module jar with the same version. When doing a release:prepare, the plugin perfectly bumps this intermodule dependency. The release:update-versions missed that dep spot. My build process failed. The goal should crawl for those deps too and update them if autoVersionSubmodules is on. (Same behavior as the prepare goal) -- 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] (SUREFIRE-827) Surefire 2.12 cannot run a single test, regression from 2.11
[ https://jira.codehaus.org/browse/SUREFIRE-827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=296561#comment-296561 ] SebbASF commented on SUREFIRE-827: -- I can confirm that the problem is *not* related to the JUnit version. SureFire 2.11 works fine with JUnit 4.7, 4.8, 4.9, 4.10 (and even 3.8.2) SureFire 2.12 does not work with any of them. For me, the -Dparallel setting makes no difference to 2.12. Surefire 2.12 cannot run a single test, regression from 2.11 Key: SUREFIRE-827 URL: https://jira.codehaus.org/browse/SUREFIRE-827 Project: Maven Surefire Issue Type: Bug Components: Junit 4.7+ (parallel) support Affects Versions: 2.12 Environment: Ubuntu 11.10 Reporter: Andrew Gaul Assignee: Kristian Rosenvold Attachments: BUG-827.zip # Surefire 2.11 $ mvn test -Dtest=DataTest#testDataServerGetNonExistentFile ... Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 # Surefire 2.12 mvn test -Dtest=DataTest#testDataServerGetNonExistentFile ... Tests run: 9, Failures: 0, Errors: 0, Skipped: 0 -- 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] (SUREFIRE-726) Test list preprocessor support for tests to be run
[ https://jira.codehaus.org/browse/SUREFIRE-726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=296564#comment-296564 ] Daniele Dellafiore commented on SUREFIRE-726: - Hi. I step into this issue lookig for a way to have a sort of global test setup, without having to deal with suites. The purpose is to have a reset of the whole database and reimport of test data at the beginning of the tests, and not pay the reset/reimport on every single test case. Maybe this is a nice way to address my problem, what do you think Test list preprocessor support for tests to be run -- Key: SUREFIRE-726 URL: https://jira.codehaus.org/browse/SUREFIRE-726 Project: Maven Surefire Issue Type: New Feature Affects Versions: 2.9 Reporter: Janmejay Singh Fix For: 3.0 Attachments: 0001-Adds-test-list-preprocessor-support-which-loads-an-o.patch, 0002-Integration-test-for-preprocessor.-2-modules-one-pro.patch, 0003-exposed-testPreprocessor-configuration-parameter-as-.patch, 0004-exposed-testPreprocessor-for-IntegrationTestMojo-as-.patch This exposes an interface(named TestListPreprocessor, which has a method named preprocessTestClasses) that can be implemented by a user and injected into surefire plugin configuration to have it used for preprocessing list of tests to be run. Given the original test list, user's preprocessing algorithm can choose to prune or reorder the list and return it back from TestListPreprocessor#preprocessTestClasses, which is then used as the list of tests to be executed. The patches attached expose a configuration element named testPreprocessor the default value of which is none. User can choose to set it to a value matching the format fully-qualified-class-name[group-id:artifact-id:version] and have the class loaded and called with list of tests to be run. The list of tests returned by the call is then considered for execution. Patch description: The feature is done in 2 patches. Description follows: 0001-Adds-test-list-preprocessor-support-which-loads-an-o.patch This patch actually adds the feature and unit tests. It adds the interface, an abstraction that encapsulates aforementioned configuration, booter serialization/deserialization, directory-scanner changes etc. The changes have effect in both forked and in-process execution mode. 0002-Integration-test-for-preprocessor.-2-modules-one-pro.patch This patch adds an integration test for preprocessor feature. The integration test uses a 2 module setup, where the first module implements the TestListPreprocessor interface which selects only even indexed test classes from the list passed in. The second module(which depends on first) uses the artifact from first and uses the following configuration: configuration testPreprocessortest.preprocessor.EvenTestOnlyPreprocessor[org.apache.maven.plugins.surefire:preprocessor-impl:1.0-SNAPSHOT]/testPreprocessor /configuration The test then asserts that only 2(0th and 2nd) of the 4 test classes the second module has are executed. The patches are created on a git-svn clone using format-patch, please use 'patch -p1 0001-Adds...'(while in the trunk directory) to apply the patches on svn repository. If using git-svn, git-am can be directly be invoked. The patches are done over http://svn.apache.org/repos/asf/maven/surefire/trunk@1091357 (trunk HEAD) so should apply cleanly on any recent enough revision. === Context: http://stackoverflow.com/questions/5124823/reducing-the-build-time-hudson http://code.google.com/p/tlb/issues/detail?id=1 http://test-load-balancer.github.com -- 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] (SUREFIRE-537) Reason for the Ignored/Skipped testcases is not reported
[
https://jira.codehaus.org/browse/SUREFIRE-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=296565#comment-296565
]
Harry Soehalim commented on SUREFIRE-537:
-
@Kristian - Thanks, that helps. I missed adding @Test after @Ignore.
Reason for the Ignored/Skipped testcases is not reported
Key: SUREFIRE-537
URL: https://jira.codehaus.org/browse/SUREFIRE-537
Project: Maven Surefire
Issue Type: New Feature
Components: Junit 4.x support, Maven Surefire Report Plugin, xml
generation
Affects Versions: 2.4.3
Environment: Windows XP, junit 4.4
Reporter: Rakesh Arora
Assignee: Kristian Rosenvold
Fix For: 2.12
Tests that are skipped with a @Ignore(Test doesn't work) annotation only
appear in the report as an increment in the Skipped column. Name of the
skipped testcases is also reported. However, the reason (i.e. Test doesn't
work) is not reported.
Quick look at the source code, it seems that it is not implemented:
In class: org.apache.maven.plugins.surefire.report.TestSuiteXmlParser
{code:java}else if ( skipped.equals( qName ) )
{
testCase.addFailure( skipped, skipped ); // TODO extract
real reasons
currentSuite.setNumberOfSkipped( 1 +
currentSuite.getNumberOfSkipped() );
}{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINVOKER-97) Add possibility to inherit settings.xml from calling process
[ https://jira.codehaus.org/browse/MINVOKER-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=296571#comment-296571 ] Olivier Lamy commented on MINVOKER-97: -- @Anders why ? I'm usually not too much bureaucratic but IMHO looks more a new feature. Add possibility to inherit settings.xml from calling process Key: MINVOKER-97 URL: https://jira.codehaus.org/browse/MINVOKER-97 Project: Maven 2.x Invoker Plugin Issue Type: New Feature Affects Versions: 1.4 Reporter: Konstantin Titorenko Assignee: Olivier Lamy Fix For: 1.6 Attachments: MINVOKER-97.patch Invoker will use default settings xml even if differetn settings xml is specified in calling maven process. It would be very usefull to add posibility to inherit settings.xml to invoker:run goal (settingsFile parameter is not enough, since it seems imposible to determine settings file from in calling maven process) -- 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
