[jira] Commented: (MECLIPSE-548) MECLIPSE-442 should be reverted. Classpath container entries should come before 3rd party jars in .classpath
[ http://jira.codehaus.org/browse/MECLIPSE-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=172863#action_172863 ] Ben Caradoc-Davies commented on MECLIPSE-548: - I second the rating of this bug as critical. This bug breaks Eclipse integration for GeoTools, because maven-eclipse-plugin does not honour exclusions of transitive dependencies, and GeoTools Eclipse integration relies on xml-apis provided by the JRE being compatible with xerces 2.7 and being earlier on the classpath. Yes, this sucks, but it works. To reproduce with Maven 2.0.10 (use a Java 5 JDK): (1) svn co http://svn.osgeo.org/geotools/trunk geotools-trunk (2) cd geotools-trunk (3) mvn -Dmaven.test.skip install eclipse:eclipse (4) import into Eclipse, and see modules fail to compile > MECLIPSE-442 should be reverted. Classpath container entries should come > before 3rd party jars in .classpath > > > Key: MECLIPSE-548 > URL: http://jira.codehaus.org/browse/MECLIPSE-548 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Dependencies resolution and build path > (.classpath) >Affects Versions: 2.6 > Environment: all >Reporter: Joe Freeman >Priority: Critical > > A patch was accepted into maven 2.6 as part of jiraMECLIPSE-442 that > configures eclipse to compile with a different order than the jre will load > with. This patch moved the container classpaths to the end of the classpath > in eclipse. This behavior is incorrect. The JRE's jar files should come > before any 3rd party libraries on the classpath because those classes will be > loaded before any of the 3rd party jars and because the JRE's classes cannot > be overridden by classes in a 3rd party jar. > I understand why MECLIPSE-442 wanted to reverse the order so they could pick > up the properties files. The best way to do this was to create properties > files in the indvidual projects if he needed at run time or in the > test/resources directory if it was only needed for unit testing. project > resources come before everything in eclipse > With this patch added to maven 2.6, we have a situation where eclipse tells > us we have compiler error when maven command line compilations do 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] Closed: (DOXIA-264) XhtmlBaseSink and sub classes should create a valid XHTML
[ http://jira.codehaus.org/browse/DOXIA-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-264. --- Assignee: Lukas Theussl (was: Vincent Siveton) Resolution: Fixed Fix Version/s: (was: 1.2) 1.1 All output is valid now, please open a new jira for specific issues. > XhtmlBaseSink and sub classes should create a valid XHTML > - > > Key: DOXIA-264 > URL: http://jira.codehaus.org/browse/DOXIA-264 > Project: Maven Doxia > Issue Type: Improvement > Components: Module - Xhtml >Affects Versions: 1.0-alpha-11 >Reporter: Vincent Siveton >Assignee: Lukas Theussl > Fix For: 1.1 > > > Some tags are wrongly written and then XHTML is not valid according the DTD: > * img tag should have an alt attributes > * head tag should have a title tag inside > * p should not be write for list and verbatim -- 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: (MCOMPILER-98) -sourcepath not passed to javac
[
http://jira.codehaus.org/browse/MCOMPILER-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=172853#action_172853
]
Jesse Glick commented on MCOMPILER-98:
--
Workaround seems to be:
maven-compiler-plugin
${project.basedir}/src/main/java
> -sourcepath not passed to javac
> ---
>
> Key: MCOMPILER-98
> URL: http://jira.codehaus.org/browse/MCOMPILER-98
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2
> Environment: Ubuntu 8.10, JDK 6.
>Reporter: Jesse Glick
>Priority: Critical
> Attachments: maven-6647998-test.zip, MCOMPILER-98.diff
>
>
> JavacCompiler.java (actually in plexus-compiler-javac, but I cannot find the
> source project for this anywhere) has
> List sourceLocations = config.getSourceLocations();
> if ( sourceLocations != null && !sourceLocations.isEmpty() && (
> sourceFiles.length == 0 ) )
> {
> args.add( "-sourcepath" );
> args.add( getPathString( sourceLocations ) );
> }
> The sourceFiles.length == 0 clause should be deleted. The problem is that
> javac really does need to have -sourcepath even when you are passing an
> explicit list of *.java files; it is necessary for 269-compliant annotation
> processors:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6647998
> Following is a patch which
> 1. Fixes diagnostics to print compiler arguments even for unforked mode.
> (javac is still run with a command line when unforked, so there is no reason
> to omit this valuable diagnostic info.)
> 2. Hacks maven-compiler-plugin to work around the bug in
> plexus-compiler-javac and pass -sourcepath. Obviously a fix to p-c-j would be
> preferable.
> When applied to m-c-p 2.0.2 it allows the test case to build.
--
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: (MCOMPILER-98) -sourcepath not passed to javac
[
http://jira.codehaus.org/browse/MCOMPILER-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Glick updated MCOMPILER-98:
-
Attachment: MCOMPILER-98.diff
Patch incl. better diagnostics and hotfix.
> -sourcepath not passed to javac
> ---
>
> Key: MCOMPILER-98
> URL: http://jira.codehaus.org/browse/MCOMPILER-98
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2
> Environment: Ubuntu 8.10, JDK 6.
>Reporter: Jesse Glick
>Priority: Critical
> Attachments: maven-6647998-test.zip, MCOMPILER-98.diff
>
>
> JavacCompiler.java (actually in plexus-compiler-javac, but I cannot find the
> source project for this anywhere) has
> List sourceLocations = config.getSourceLocations();
> if ( sourceLocations != null && !sourceLocations.isEmpty() && (
> sourceFiles.length == 0 ) )
> {
> args.add( "-sourcepath" );
> args.add( getPathString( sourceLocations ) );
> }
> The sourceFiles.length == 0 clause should be deleted. The problem is that
> javac really does need to have -sourcepath even when you are passing an
> explicit list of *.java files; it is necessary for 269-compliant annotation
> processors:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6647998
> Following is a patch which
> 1. Fixes diagnostics to print compiler arguments even for unforked mode.
> (javac is still run with a command line when unforked, so there is no reason
> to omit this valuable diagnostic info.)
> 2. Hacks maven-compiler-plugin to work around the bug in
> plexus-compiler-javac and pass -sourcepath. Obviously a fix to p-c-j would be
> preferable.
> When applied to m-c-p 2.0.2 it allows the test case to build.
--
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: (MCOMPILER-98) -sourcepath not passed to javac
-sourcepath not passed to javac
---
Key: MCOMPILER-98
URL: http://jira.codehaus.org/browse/MCOMPILER-98
Project: Maven 2.x Compiler Plugin
Issue Type: Bug
Affects Versions: 2.0.2
Environment: Ubuntu 8.10, JDK 6.
Reporter: Jesse Glick
Priority: Critical
Attachments: maven-6647998-test.zip
JavacCompiler.java (actually in plexus-compiler-javac, but I cannot find the
source project for this anywhere) has
List sourceLocations = config.getSourceLocations();
if ( sourceLocations != null && !sourceLocations.isEmpty() && (
sourceFiles.length == 0 ) )
{
args.add( "-sourcepath" );
args.add( getPathString( sourceLocations ) );
}
The sourceFiles.length == 0 clause should be deleted. The problem is that javac
really does need to have -sourcepath even when you are passing an explicit list
of *.java files; it is necessary for 269-compliant annotation processors:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6647998
Following is a patch which
1. Fixes diagnostics to print compiler arguments even for unforked mode. (javac
is still run with a command line when unforked, so there is no reason to omit
this valuable diagnostic info.)
2. Hacks maven-compiler-plugin to work around the bug in plexus-compiler-javac
and pass -sourcepath. Obviously a fix to p-c-j would be preferable.
When applied to m-c-p 2.0.2 it allows the test case to build.
--
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: (MCOMPILER-97) META-INF/services/javax.annotation.processing.Processor copied before compilation and causes error
META-INF/services/javax.annotation.processing.Processor copied before compilation and causes error -- Key: MCOMPILER-97 URL: http://jira.codehaus.org/browse/MCOMPILER-97 Project: Maven 2.x Compiler Plugin Issue Type: Bug Affects Versions: 2.0.2 Environment: Ubuntu 8.10, JDK 6. Reporter: Jesse Glick Attachments: maven-6647998-test.zip It is tricky to compile a Maven module which defines a (269-compliant) annotation processor. If you write the code for the processor in src/main/java and register it in src/main/resources, META-INF/services/javax.annotation.processing.Processor is copied to target/classes first, and then javac is run. But javac is given target/classes in -classpath, so it tries to load the processor, which of course has not been compiled yet - a chicken-and-egg problem. The most straightforward workaround is to specify -proc:none in your POM. This will only work, however, if the module does not use any annotation processors defined in dependencies. If it does, there may be some other trick involving -processorpath and Maven variable substitution to insert the dependency classpath. Switching the order of resources:resources and compiler:compile would help - at least a clean build would work - though it could still cause problems in incremental builds. Better would be for the compiler plugin to pass -processorpath based on the dependency classpath (i.e. -classpath minus target/classes) when using -source 1.6 or higher. -- 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: (MCOMPILER-66) Compiler swallows messages from annotation processors
[
http://jira.codehaus.org/browse/MCOMPILER-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=172842#action_172842
]
Jesse Glick commented on MCOMPILER-66:
--
Possible cause in JavacCompiler.java:
else if ( buffer.length() == 0 && line.startsWith( "Note: " ) )
{
// skip this one - it is JDK 1.5 telling us that the
interface is deprecated.
}
> Compiler swallows messages from annotation processors
> -
>
> Key: MCOMPILER-66
> URL: http://jira.codehaus.org/browse/MCOMPILER-66
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Reporter: Evan Cowden
> Attachments: AnnotationProcessorMessagerBug.zip
>
>
> When using the annotation processor API to print messages through the
> javax.annotation.processing.Messager object, only messagesspecified by levels
> javax.tools.Diagnostic.Kind.ERROR and
> javax.tools.Diagnostic.Kind.MANDATORY_WARNING are displayed (and cause the
> build to fail). All other messages are swallowed.
> Note that while the attached JUnit test case is necessary to help expose the
> problem, passing it will not imply that the bug is fixed. The only way to
> confirm the fix (that I know of) is to examine console output.
--
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-100) deploy:deploy-file fails from windows powershell
deploy:deploy-file fails from windows powershell Key: MDEPLOY-100 URL: http://jira.codehaus.org/browse/MDEPLOY-100 Project: Maven 2.x Deploy Plugin Issue Type: Bug Components: deploy:deploy-file Environment: windows powershell Reporter: nambi sankaran mvn deploy:deploy-file fails with authentication error when tried from windows powershell. The same command works from fine from normal windows command shell -- 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-4131) MavenXpp3Writer.write( writer, model ) does not write the for sections under when the "groupId" is "org.apache.maven.plugins"
MavenXpp3Writer.write( writer, model ) does not write the for
sections under when the "groupId" is
"org.apache.maven.plugins"
---
Key: MNG-4131
URL: http://jira.codehaus.org/browse/MNG-4131
Project: Maven 2
Issue Type: Bug
Components: Embedding
Affects Versions: 3.0-alpha-1, 2.0.9
Reporter: nambi sankaran
I need to update the some sections of a super pom file for every release.
Instead of writing a script, I am using maven-model library to read the Model
of the pom.xml and update my stuff.
then I am simply writing the file back into disk
Following is the code.
BufferedReader in = new BufferedReader( new
FileReader(pomFilePath) );
MavenXpp3Reader reader = new MavenXpp3Reader();
Model model = reader.read(in);
in.close();
DistributionManagement dMgmt =
model.getDistributionManagement();
DeploymentRepository repository = dMgmt.getRepository();
repository.setUrl(repositoryUrl);
// write the pom file
BufferedWriter out = new BufferedWriter(new FileWriter(
pomFilePath ));
MavenXpp3Writer writer = new MavenXpp3Writer();
writer.write(out, model);
MavenXpp3Writer.write( writer, model ) does not write the for
sections under when the "groupId" is
"org.apache.maven.plugins"
Following is the code that does the work
private void writePlugin(Plugin plugin, String tagName, XmlSerializer
serializer)
throws java.io.IOException
{
if ( plugin != null )
{
serializer.startTag( NAMESPACE, tagName );
if ( plugin.getGroupId() != null && !plugin.getGroupId().equals(
"org.apache.maven.plugins" ) )
{
serializer.startTag( NAMESPACE, "groupId" ).text(
plugin.getGroupId() ).endTag( NAMESPACE, "groupId" );
}
As you see, the writePlugin method does not write the "groupId" , when the
groupId is null or "org.apache.maven.plugins"
Is this intended or a bug?
--
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: (MRELEASE-439) Maven perform checks out all other projects in the parent directory, this wasn't happening with 2.0-beta-8 or beta-7
Maven perform checks out all other projects in the parent directory, this wasn't happening with 2.0-beta-8 or beta-7 Key: MRELEASE-439 URL: http://jira.codehaus.org/browse/MRELEASE-439 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-9 Environment: Windows XP Reporter: jack Here is my POM file: http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4.0.0 com..test test1 test project 0.0.139-SNAPSHOT pom xx http://www.xxx.com org.apache.maven.plugins maven-compiler-plugin 1.6 1.6 org.apache.maven.plugins maven-release-plugin 2.0-beta-9 http://xxx..com/svn/md.svn/TRUNK/com.xx/tags false true false true true x xx org.apache.maven.plugins maven-jar-plugin /home/md/lib/java/overrides true true true true true false false lib org.apache.maven.plugins maven-source-plugin attach-sources verify jar
[jira] Updated: (DOXIA-141) Add missing references for FML XDOC
[ http://jira.codehaus.org/browse/DOXIA-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated DOXIA-141: Assignee: Vincent Siveton Fix Version/s: (was: 1.3) 1.1 > Add missing references for FML XDOC > --- > > Key: DOXIA-141 > URL: http://jira.codehaus.org/browse/DOXIA-141 > Project: Maven Doxia > Issue Type: Sub-task > Components: Documentation >Affects Versions: 1.0-alpha-9 >Reporter: Vincent Siveton >Assignee: Vincent Siveton > Fix For: 1.1 > > -- 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: (DOXIA-105) review error handling
[ http://jira.codehaus.org/browse/DOXIA-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated DOXIA-105: Fix Version/s: (was: 1.3) 1.2 > review error handling > - > > Key: DOXIA-105 > URL: http://jira.codehaus.org/browse/DOXIA-105 > Project: Maven Doxia > Issue Type: Improvement > Components: Core >Reporter: Brett Porter > Fix For: 1.2 > > Attachments: DOXIA-105_1.diff > > > Issue to revise how errors are handled through Doxia as there seem to be > occasional stack traces shown for non-fatal errors, and some errors being > swallowed. -- 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: (DOXIA-239) Handle non-ASCII characters in anchors and id's
[ http://jira.codehaus.org/browse/DOXIA-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-239. --- Assignee: Lukas Theussl Resolution: Fixed Fix Version/s: 1.1.1 Fixed in r764589. > Handle non-ASCII characters in anchors and id's > --- > > Key: DOXIA-239 > URL: http://jira.codehaus.org/browse/DOXIA-239 > Project: Maven Doxia > Issue Type: Bug > Components: Core, Documentation, Modules, Sink API >Reporter: Lukas Theussl >Assignee: Lukas Theussl > Fix For: 1.1.1 > > > From DOXIA-236: > The javadoc for the method HtmlTools.encodeId() mentions the pattern > [A-Za-z][A-Za-z0-9:_.-]* for its output. To me, this looks like the term > "letter" in meant to refer to ASCII characters in this context. However, the > employed method Character.isLetter() will classify characters according to > the Unicode data file. For instance, the characters "ä" and "ß" are letters > in the Unicode sense. encodeId() will pass these through to its output, > violating the ASCII-only pattern stated in its javadoc. -- 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-49) Some array types are not properly shaded...
[ http://jira.codehaus.org/browse/MSHADE-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp closed MSHADE-49. - Assignee: Daniel Kulp Resolution: Fixed Fix Version/s: 1.3 > Some array types are not properly shaded... > --- > > Key: MSHADE-49 > URL: http://jira.codehaus.org/browse/MSHADE-49 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Affects Versions: 1.2 >Reporter: Daniel Kulp >Assignee: Daniel Kulp > Fix For: 1.3 > > > In SOME cases, classes that are referenced via an array are not being > properly shaded. A string like "[Lcom.blah.Foo;" is being sent into the > mapper thing, but that's not being shaded. -- 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-49) Some array types are not properly shaded...
Some array types are not properly shaded... --- Key: MSHADE-49 URL: http://jira.codehaus.org/browse/MSHADE-49 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 1.2 Reporter: Daniel Kulp In SOME cases, classes that are referenced via an array are not being properly shaded. A string like "[Lcom.blah.Foo;" is being sent into the mapper thing, but that's not being shaded. -- 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: (DOXIA-272) TOC macro: allow to specify from/toDepth for *all* sections
[ http://jira.codehaus.org/browse/DOXIA-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated DOXIA-272: Fix Version/s: 1.2 > TOC macro: allow to specify from/toDepth for *all* sections > --- > > Key: DOXIA-272 > URL: http://jira.codehaus.org/browse/DOXIA-272 > Project: Maven Doxia > Issue Type: Improvement > Components: Core >Affects Versions: 1.0-alpha-11 >Reporter: Lukas Theussl >Priority: Minor > Fix For: 1.2 > > > The description of the section parameter in the TOC macro currently reads: > bq. Display the specificated section number or all sections if 0 (in this > case, other parameters are ignored). > I don't see any reason for this restriction, eg I would like to get a TOC > showing subsections up to a certain depth for *all* sections, which is > currently not possible. -- 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: (DOXIA-224) Add source name in parser
[ http://jira.codehaus.org/browse/DOXIA-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated DOXIA-224: Fix Version/s: 1.2 > Add source name in parser > - > > Key: DOXIA-224 > URL: http://jira.codehaus.org/browse/DOXIA-224 > Project: Maven Doxia > Issue Type: New Feature > Components: Core >Affects Versions: 1.0-alpha-10 >Reporter: Vincent Siveton > Fix For: 1.2 > > > Should be useful when warn log are call -- 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: (DOXIA-281) Add macro support in FML
[ http://jira.codehaus.org/browse/DOXIA-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated DOXIA-281: Fix Version/s: 1.2 We'll need a new xsd as the current one does not know the macro tag. > Add macro support in FML > > > Key: DOXIA-281 > URL: http://jira.codehaus.org/browse/DOXIA-281 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Fml >Affects Versions: 1.1 >Reporter: Vincent Siveton > Fix For: 1.2 > > > Add macro support in fml files -- 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: (MNG-3834) Improve error message when dependency with classifier is missing version
[
http://jira.codehaus.org/browse/MNG-3834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier closed MNG-3834.
--
Resolution: Fixed
This is fixed.
> Improve error message when dependency with classifier is missing version
>
>
> Key: MNG-3834
> URL: http://jira.codehaus.org/browse/MNG-3834
> Project: Maven 2
> Issue Type: Improvement
> Components: Errors
>Reporter: Paul Gier
>Assignee: Paul Gier
>Priority: Minor
> Fix For: 2.0.11, 2.1.1, 3.0-alpha-3
>
> Attachments: MNG-3834-maven-project.patch, pom.xml
>
>
> Currently, if I have two dependencies on the same groupId:artifactId, one
> with a classifier and one without, the missing version error message does not
> distinguish which dependency is missing a version. For example, the
> following pom is missing a version number for one of the dependencies.
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> org.apache.maven
> missing-version-error
> jar
> Missing version error
> 1.0.0-SNAPSHOT
>
>
>
> org.apache.maven
> myartifact1
> 1.0-SNAPSHOT
>
>
> org.apache.maven
> myartifact1
> test
>
>
>
> {code}
> The error message prints the following:
> {code}
> Validation Messages:
> [0] 'dependencies.dependency.version' is missing for
> org.apache.maven:myartifact1
> {code}
> The error message should include information about the dependency's
> classifier.
--
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: (MWAR-192) Conflict with workspace resoutlion in m2eclipse
[ http://jira.codehaus.org/browse/MWAR-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=172796#action_172796 ] Olivier Lamy commented on MWAR-192: --- So is it really a war plugin issue ? Does it works when invoking maven with cli ? > Conflict with workspace resoutlion in m2eclipse > --- > > Key: MWAR-192 > URL: http://jira.codehaus.org/browse/MWAR-192 > Project: Maven 2.x WAR Plugin > Issue Type: Bug >Affects Versions: 2.1-alpha-2 > Environment: windows vista >Reporter: Max Powers > > While building my webapp in eclipse using a launch configuration (goals clean > install) and having 'Resolve Workspace Artifacts' checked, the war plugin > cant assemble the war file properly. Note that disabled 'Resolve Workspace > Artifacts' and the war is assembled fine > [DEBUG] Processing: nexus-lvo-plugin-1.3.3-SNAPSHOT.jar > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to copy file for > artifact[org.sonatype.nexus.plugins:nexus-lvo-plugin:jar:1.3.3-SNAPSHOT:compile] > > Embedded error: > C:\Development\Code\nexus-1.3.x\nexus-core-plugins\nexus-lvo-plugin\target\classes > (Access is denied) > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to copy file > for > artifact[org.sonatype.nexus.plugins:nexus-lvo-plugin:jar:1.3.3-SNAPSHOT:compile] > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:356) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to copy > file for > artifact[org.sonatype.nexus.plugins:nexus-lvo-plugin:jar:1.3.3-SNAPSHOT:compile] > at > org.apache.maven.plugin.war.packaging.ArtifactsPackagingTask.performPackaging(ArtifactsPackagingTask.java:125) > at > org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.handleArtifacts(WarProjectPackagingTask.java:183) > at > org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.performPackaging(WarProjectPackagingTask.java:103) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:439) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:375) > at > org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:181) > at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:143) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) > ... 16 more > Caused by: java.io.FileNotFoundException: > C:\Development\Code\nexus-1.3.x\nexus-core-plugins\nexus-lvo-plugin\target\classes > (Access is denied) > at java.io.FileInputStream.open(Native Method) > at java.io.FileInputStream.(FileInputStream.java:106) > at > org.codehaus.plexus.util.io.FileInputStreamFacade.getInputStream(FileInputStreamFacade.java:78) > at > org.codehaus.plexus.util.FileUtils.copyStreamToFile(FileUtils.java:1057) > at org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:965) > at > org.apache
[jira] Updated: (MNG-3834) Improve error message when dependency with classifier is missing version
[
http://jira.codehaus.org/browse/MNG-3834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier updated MNG-3834:
---
Priority: Minor (was: Major)
Fix Version/s: 3.0-alpha-3
2.1.1
> Improve error message when dependency with classifier is missing version
>
>
> Key: MNG-3834
> URL: http://jira.codehaus.org/browse/MNG-3834
> Project: Maven 2
> Issue Type: Improvement
> Components: Errors
>Reporter: Paul Gier
>Assignee: Paul Gier
>Priority: Minor
> Fix For: 2.0.11, 2.1.1, 3.0-alpha-3
>
> Attachments: MNG-3834-maven-project.patch, pom.xml
>
>
> Currently, if I have two dependencies on the same groupId:artifactId, one
> with a classifier and one without, the missing version error message does not
> distinguish which dependency is missing a version. For example, the
> following pom is missing a version number for one of the dependencies.
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> org.apache.maven
> missing-version-error
> jar
> Missing version error
> 1.0.0-SNAPSHOT
>
>
>
> org.apache.maven
> myartifact1
> 1.0-SNAPSHOT
>
>
> org.apache.maven
> myartifact1
> test
>
>
>
> {code}
> The error message prints the following:
> {code}
> Validation Messages:
> [0] 'dependencies.dependency.version' is missing for
> org.apache.maven:myartifact1
> {code}
> The error message should include information about the dependency's
> classifier.
--
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] Reopened: (MNG-4089) Allow LATEST and RELEASE to peg major version similar to SNAPSHOT
[
http://jira.codehaus.org/browse/MNG-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gin-Ting Chen reopened MNG-4089:
This is not a duplicate of the linked issue. It's a completely different
(simpler) mechanism and allows locking to a feature stream.
> Allow LATEST and RELEASE to peg major version similar to SNAPSHOT
> -
>
> Key: MNG-4089
> URL: http://jira.codehaus.org/browse/MNG-4089
> Project: Maven 2
> Issue Type: Bug
>Reporter: Gin-Ting Chen
>Assignee: Brett Porter
>
> If we could do 25-RELEASE/25-LATEST it would provide a huge functionality
> boost over the current implementation of these 2 keywords.
> Currently if I use a value range to try to simulate 25-RELEASE (LATEST)
> I would do:
> {code}
> [25,26)
> {code}
> This doesn't work very well as SNAPSHOT would be included for 26 even if no
> 26 released versions are.
> Doing:
> {code}
> [RELEASE,25-SNAPSHOT)
> {code}
> Works slightly better until you release a release version greater than 25
> then it again breaks since it doesn't look at (and can't really be expected
> to) the numerical comparison of 25 vs anything higher than it.
> Deploying w. alpha names in versioning will break both these approaches.
> For example: alpha-1.1, beta-1.2, etc
--
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-444) Git provider does 'git push' during 'mvn release:prepare' which causes unwanted problems
[
http://jira.codehaus.org/browse/SCM-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=172780#action_172780
]
Mark Struberg commented on SCM-444:
---
good point! Although this is obvious I have never thought that way.
But this mindset would require to redefine the way the release process
currently works - or at least get a different common understanding of it.
Currently releasing an artifact means that it gets tested, tagged and then
(with mvn release:perform)a *clean checkout* happens into target/checkout! How
should we do the clean checkout if we do not push the tag into the upstream
repo? In the pom.xml there is only a section which points to upstream, so
there is no 'easy' way to do a local checkout from ${basedir}.
Any ideas any1? We first need a fully fledged and consistent user story of the
whole picture before we touch the code!
> Git provider does 'git push' during 'mvn release:prepare' which causes
> unwanted problems
>
>
> Key: SCM-444
> URL: http://jira.codehaus.org/browse/SCM-444
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-git
>Affects Versions: 1.1
>Reporter: Petter Måhlén
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 1.3
>
>
> When doing 'mvn release:prepare' with a Git provider, a 'git push' command is
> executed. This is not ideal because the push command can fail or push things
> from the local repository that are not needed/wanted in the remote
> repository. Some examples are:
> 1. The local repository has two branches: master (tracking origin/master) and
> dummy (tracking origin/dummy). The release is being made on the master
> branch, and the dummy and origin/dummy branches have diverged. Running
> 'release:prepare' causes a 'git push', which will succeed for the master
> branch (assuming that the release preparation has been made correctly) and
> fail for the dummy branch (the two branches have diverged and need to be
> merged or rebased). The release preparation aborts and the directory is left
> in a somewhat inconsistent state where manual cleaning up is needed (removing
> pom.xml.next files, changing versions to -SNAPSHOT, etc.)
> 2. The local repository has two branches: master (tracking origin/master) and
> localtest (not in the origin repository). The localtest branch shouldn't be
> published because it is just used for some temporary testing and doesn't even
> work. It will be pushed during 'release:prepare'.
> Suggested behaviour: use 'git push origin :',
> or even better, query for which remote repository to push to (found in
> .git/config) and which branch to push from and to. For me, it would be great
> to have a 'confirm push' before doing it so as to keep things clean, but
> maybe that is quite complex.
--
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: (MWAR-192) Conflict with workspace resoutlion in m2eclipse
[ http://jira.codehaus.org/browse/MWAR-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=172778#action_172778 ] Max Powers commented on MWAR-192: - note, using m2eclipse (probably handy info) :) > Conflict with workspace resoutlion in m2eclipse > --- > > Key: MWAR-192 > URL: http://jira.codehaus.org/browse/MWAR-192 > Project: Maven 2.x WAR Plugin > Issue Type: Bug >Affects Versions: 2.1-alpha-2 > Environment: windows vista >Reporter: Max Powers > > While building my webapp in eclipse using a launch configuration (goals clean > install) and having 'Resolve Workspace Artifacts' checked, the war plugin > cant assemble the war file properly. Note that disabled 'Resolve Workspace > Artifacts' and the war is assembled fine > [DEBUG] Processing: nexus-lvo-plugin-1.3.3-SNAPSHOT.jar > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to copy file for > artifact[org.sonatype.nexus.plugins:nexus-lvo-plugin:jar:1.3.3-SNAPSHOT:compile] > > Embedded error: > C:\Development\Code\nexus-1.3.x\nexus-core-plugins\nexus-lvo-plugin\target\classes > (Access is denied) > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to copy file > for > artifact[org.sonatype.nexus.plugins:nexus-lvo-plugin:jar:1.3.3-SNAPSHOT:compile] > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:356) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to copy > file for > artifact[org.sonatype.nexus.plugins:nexus-lvo-plugin:jar:1.3.3-SNAPSHOT:compile] > at > org.apache.maven.plugin.war.packaging.ArtifactsPackagingTask.performPackaging(ArtifactsPackagingTask.java:125) > at > org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.handleArtifacts(WarProjectPackagingTask.java:183) > at > org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.performPackaging(WarProjectPackagingTask.java:103) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:439) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:375) > at > org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:181) > at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:143) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) > ... 16 more > Caused by: java.io.FileNotFoundException: > C:\Development\Code\nexus-1.3.x\nexus-core-plugins\nexus-lvo-plugin\target\classes > (Access is denied) > at java.io.FileInputStream.open(Native Method) > at java.io.FileInputStream.(FileInputStream.java:106) > at > org.codehaus.plexus.util.io.FileInputStreamFacade.getInputStream(FileInputStreamFacade.java:78) > at > org.codehaus.plexus.util.FileUtils.copyStreamToFile(FileUtils.java:1057) > at org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:965) > at > org.apache.maven.plugin.war.packaging.AbstractWarP
[jira] Updated: (DOXIA-170) Confluence module should do something with non-doxia formatting
[ http://jira.codehaus.org/browse/DOXIA-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated DOXIA-170: Assignee: Lukas Theussl Fix Version/s: (was: 2.0) 1.1.1 > Confluence module should do something with non-doxia formatting > --- > > Key: DOXIA-170 > URL: http://jira.codehaus.org/browse/DOXIA-170 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.0-alpha-8 >Reporter: Dave Syer >Assignee: Lukas Theussl > Fix For: 1.1.1 > > > These wiki formats are not recognised ??citation?? -strikethrough- > +underlined+ ^superscript^ ~subscript~ -- 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: (MWAR-192) Conflict with workspace resoutlion in m2eclipse
Conflict with workspace resoutlion in m2eclipse --- Key: MWAR-192 URL: http://jira.codehaus.org/browse/MWAR-192 Project: Maven 2.x WAR Plugin Issue Type: Bug Affects Versions: 2.1-alpha-2 Environment: windows vista Reporter: Max Powers While building my webapp in eclipse using a launch configuration (goals clean install) and having 'Resolve Workspace Artifacts' checked, the war plugin cant assemble the war file properly. Note that disabled 'Resolve Workspace Artifacts' and the war is assembled fine [DEBUG] Processing: nexus-lvo-plugin-1.3.3-SNAPSHOT.jar [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to copy file for artifact[org.sonatype.nexus.plugins:nexus-lvo-plugin:jar:1.3.3-SNAPSHOT:compile] Embedded error: C:\Development\Code\nexus-1.3.x\nexus-core-plugins\nexus-lvo-plugin\target\classes (Access is denied) [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Failed to copy file for artifact[org.sonatype.nexus.plugins:nexus-lvo-plugin:jar:1.3.3-SNAPSHOT:compile] at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) at org.apache.maven.cli.MavenCli.main(MavenCli.java:356) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to copy file for artifact[org.sonatype.nexus.plugins:nexus-lvo-plugin:jar:1.3.3-SNAPSHOT:compile] at org.apache.maven.plugin.war.packaging.ArtifactsPackagingTask.performPackaging(ArtifactsPackagingTask.java:125) at org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.handleArtifacts(WarProjectPackagingTask.java:183) at org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.performPackaging(WarProjectPackagingTask.java:103) at org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:439) at org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:375) at org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:181) at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:143) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) ... 16 more Caused by: java.io.FileNotFoundException: C:\Development\Code\nexus-1.3.x\nexus-core-plugins\nexus-lvo-plugin\target\classes (Access is denied) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(FileInputStream.java:106) at org.codehaus.plexus.util.io.FileInputStreamFacade.getInputStream(FileInputStreamFacade.java:78) at org.codehaus.plexus.util.FileUtils.copyStreamToFile(FileUtils.java:1057) at org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:965) at org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFile(AbstractWarPackagingTask.java:293) at org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask$1.registered(AbstractWarPackagingTask.java:150) at org.apache.maven.plugin.war.util.WebappStructure.registerFile(WebappStructure.java:176) at org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFile(AbstractWarPackagingTask
[jira] Updated: (DOXIA-174) Add something to the head() so a page can be identified
[ http://jira.codehaus.org/browse/DOXIA-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated DOXIA-174: Fix Version/s: (was: 2.0) > Add something to the head() so a page can be identified > --- > > Key: DOXIA-174 > URL: http://jira.codehaus.org/browse/DOXIA-174 > Project: Maven Doxia > Issue Type: New Feature > Components: Module - Confluence >Affects Versions: 1.0-alpha-8 >Reporter: Dave Syer >Assignee: Lukas Theussl > > Add something to the head() so a page can be identified. Confluence doesn't > really have the notion of special markup for title and author, as far as I > know. If it does great - we need to support it in the Doxia parser. Even if > it doesn't, the generated HTML needs to identify itself to a browser - could > use the name of the Source for instance. Also the Doxia Book model likes to > have some header meta data for a book. In the APT case it gets it from the > header of the first 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] Closed: (DOXIA-174) Add something to the head() so a page can be identified
[ http://jira.codehaus.org/browse/DOXIA-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-174. --- Assignee: Lukas Theussl Resolution: Duplicate > Add something to the head() so a page can be identified > --- > > Key: DOXIA-174 > URL: http://jira.codehaus.org/browse/DOXIA-174 > Project: Maven Doxia > Issue Type: New Feature > Components: Module - Confluence >Affects Versions: 1.0-alpha-8 >Reporter: Dave Syer >Assignee: Lukas Theussl > Fix For: 2.0 > > > Add something to the head() so a page can be identified. Confluence doesn't > really have the notion of special markup for title and author, as far as I > know. If it does great - we need to support it in the Doxia parser. Even if > it doesn't, the generated HTML needs to identify itself to a browser - could > use the name of the Source for instance. Also the Doxia Book model likes to > have some header meta data for a book. In the APT case it gets it from the > header of the first 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] Closed: (DOXIA-43) Can't put text in front of figure block
[ http://jira.codehaus.org/browse/DOXIA-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-43. -- Assignee: Lukas Theussl Resolution: Won't Fix Fix Version/s: (was: 2.0) Apt doesn't support in-line images. > Can't put text in front of figure block > --- > > Key: DOXIA-43 > URL: http://jira.codehaus.org/browse/DOXIA-43 > Project: Maven Doxia > Issue Type: Improvement > Components: Module - Apt >Reporter: Hugo Palma >Assignee: Lukas Theussl >Priority: Minor > > It would be great if i could put some text in front of a figure block. Right > now i can't place any text in the same line as the image. > It would also be great if i could indent the figure block. For instance, if i > want to create list items that display an image in front of each item. -- 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-444) Git provider does 'git push' during 'mvn release:prepare' which causes unwanted problems
[ http://jira.codehaus.org/browse/SCM-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=172771#action_172771 ] Matthew McCullough commented on SCM-444: I'd be more inclined for the quick-and-easy solution of having the plugin read a parameter/flag that just disables the push entirely. Then, the release plugin user can turn it off for branches he/she does not want to push, and can push at their leisure later. In fact, I find not pushing to be much more in line with the idea of git to "Play local until confident, push only when ready". After all, we worked so hard to get an SCM system that finally doesn't require us to have connectivity to any remote servers, and having the release plugin PUSH kind of interrupts that achievement. A simple do-no-push flag seems like a quick solution. > Git provider does 'git push' during 'mvn release:prepare' which causes > unwanted problems > > > Key: SCM-444 > URL: http://jira.codehaus.org/browse/SCM-444 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.1 >Reporter: Petter Måhlén >Assignee: Olivier Lamy >Priority: Minor > Fix For: 1.3 > > > When doing 'mvn release:prepare' with a Git provider, a 'git push' command is > executed. This is not ideal because the push command can fail or push things > from the local repository that are not needed/wanted in the remote > repository. Some examples are: > 1. The local repository has two branches: master (tracking origin/master) and > dummy (tracking origin/dummy). The release is being made on the master > branch, and the dummy and origin/dummy branches have diverged. Running > 'release:prepare' causes a 'git push', which will succeed for the master > branch (assuming that the release preparation has been made correctly) and > fail for the dummy branch (the two branches have diverged and need to be > merged or rebased). The release preparation aborts and the directory is left > in a somewhat inconsistent state where manual cleaning up is needed (removing > pom.xml.next files, changing versions to -SNAPSHOT, etc.) > 2. The local repository has two branches: master (tracking origin/master) and > localtest (not in the origin repository). The localtest branch shouldn't be > published because it is just used for some temporary testing and doesn't even > work. It will be pushed during 'release:prepare'. > Suggested behaviour: use 'git push origin :', > or even better, query for which remote repository to push to (found in > .git/config) and which branch to push from and to. For me, it would be great > to have a 'confirm push' before doing it so as to keep things clean, but > maybe that is quite complex. -- 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: (DOXIA-307) Tests fail when run with Java 1.4
[ http://jira.codehaus.org/browse/DOXIA-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed DOXIA-307. - Assignee: Vincent Siveton Resolution: Fixed Fixed in [r764465|http://svn.apache.org/viewvc?rev=764465&view=rev] > Tests fail when run with Java 1.4 > - > > Key: DOXIA-307 > URL: http://jira.codehaus.org/browse/DOXIA-307 > Project: Maven Doxia > Issue Type: Bug > Components: Core >Affects Versions: 1.1 >Reporter: Benjamin Bentmann >Assignee: Vincent Siveton > Fix For: 1.1.1 > > Attachments: org.apache.maven.doxia.ConverterTest.txt, > TEST-org.apache.maven.doxia.ConverterTest.xml > > > See attached Surefire reports. There's probably a XML dependency missing for > Java 1.4. -- 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: (MANT-47) ant:clean should not delete build.xml
[
http://jira.codehaus.org/browse/MANT-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=172768#action_172768
]
Benjamin Bentmann commented on MANT-47:
---
Revised in [r764446|http://svn.eu.apache.org/viewvc?view=rev&revision=764446].
We now have a new parameter {{deleteCustomFiles}} which defaults to false.
> ant:clean should not delete build.xml
> -
>
> Key: MANT-47
> URL: http://jira.codehaus.org/browse/MANT-47
> Project: Maven 2.x Ant Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Vincent Siveton
>Assignee: Vincent Siveton
> Fix For: 2.2
>
>
> Running mvn ant:ant will generate Ant files:
> {noformat}
> build.xml => custom targets
> maven-build.xml => generic targets
> maven-build.properties => Maven properties
> {noformat}
> So, the build.xml should not be deleted when calling mvn ant:clean.
> Nevertheless, the clean mojo could ask the user to force delete 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] Updated: (SCM-459) Add tag() and status() methods to local scm provider to enable use with release:prepare goal
[ http://jira.codehaus.org/browse/SCM-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated SCM-459: - Fix Version/s: 1.3 > Add tag() and status() methods to local scm provider to enable use with > release:prepare goal > > > Key: SCM-459 > URL: http://jira.codehaus.org/browse/SCM-459 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-local >Affects Versions: 1.2 >Reporter: Matthew McCullough >Priority: Critical > Fix For: 1.3 > > Attachments: add-status-and-tag-commands.patch > > > The local scm provider is missing implementations (even no-op ones) for the > tag and status operations. Missing these prevents using the local scm > provider with the release:prepare plugin goal. I spoke with Trygve Laugstøl > on IRC about adding these two methods, and he thought it would be an > acceptable change. -- 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: (MSOURCES-41) Generate source jars supporting Eclipse Source Bundle format.
[ http://jira.codehaus.org/browse/MSOURCES-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=172767#action_172767 ] Don Laidlaw commented on MSOURCES-41: - MSOURCES-42 seems to have great potential for this. I will play with it and see if I can get it to meet the needs of an Eclipse source bundle. If not, I will provide a patch. Thanks! > Generate source jars supporting Eclipse Source Bundle format. > - > > Key: MSOURCES-41 > URL: http://jira.codehaus.org/browse/MSOURCES-41 > Project: Maven 2.x Source Plugin > Issue Type: New Feature >Affects Versions: 2.0.4 > Environment: Eclipse 3.3+ >Reporter: Don Laidlaw > > When developing eclipse plugins, or any OSGi bundle, it is desirable to > create the source attachments for a project as Eclipse Source Bundles. See > http://wiki.eclipse.org/Source_Bundles > A source bundle appears in the target platform (the bundles in the runtime) > and allows the user to step into the source in debug, view the source, and > see the javadoc from the source. All without having to download the source > project. Source bundles differ from source attachments in non OSGi projects > in that they are part of the target platform, which is resolved dynamically > at runtime, not at compile time with the classpath. > It is very easy to extend the maven source plugin to create these source > bundles. They are identical to the currently generated jar, with the addition > of a few entries in the META-INF/MANIFEST.MF file. So source jars usable as > source bundles are also 100% compatible with what is currently generated. > I have already done the work and would be happy to contribute this back if > there is any interest. -- 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: (SCM-459) Add tag() and status() methods to local scm provider to enable use with release:prepare goal
Add tag() and status() methods to local scm provider to enable use with release:prepare goal Key: SCM-459 URL: http://jira.codehaus.org/browse/SCM-459 Project: Maven SCM Issue Type: Improvement Components: maven-scm-provider-local Affects Versions: 1.2 Reporter: Matthew McCullough Priority: Critical Attachments: add-status-and-tag-commands.patch The local scm provider is missing implementations (even no-op ones) for the tag and status operations. Missing these prevents using the local scm provider with the release:prepare plugin goal. I spoke with Trygve Laugstøl on IRC about adding these two methods, and he thought it would be an acceptable change. -- 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: (DOXIA-307) Tests fail when run with Java 1.4
[ http://jira.codehaus.org/browse/DOXIA-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated DOXIA-307: Fix Version/s: 1.1.1 Component/s: Core The same problem with DefaultPdfRendererTest in doxia-doc-renderer. I think it's caused by the core, dependeny-analyze shows that xerces is unused but xml-apis is missing. However, I haven't found a combination yet that works for all cases. > Tests fail when run with Java 1.4 > - > > Key: DOXIA-307 > URL: http://jira.codehaus.org/browse/DOXIA-307 > Project: Maven Doxia > Issue Type: Bug > Components: Core >Affects Versions: 1.1 >Reporter: Benjamin Bentmann > Fix For: 1.1.1 > > Attachments: org.apache.maven.doxia.ConverterTest.txt, > TEST-org.apache.maven.doxia.ConverterTest.xml > > > See attached Surefire reports. There's probably a XML dependency missing for > Java 1.4. -- 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: (DOXIASITETOOLS-19) SiteRendererSink ignores meta info in head
[ http://jira.codehaus.org/browse/DOXIASITETOOLS-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIASITETOOLS-19. --- Assignee: Lukas Theussl Resolution: Fixed Fixed in r764409. > SiteRendererSink ignores meta info in head > -- > > Key: DOXIASITETOOLS-19 > URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-19 > Project: Maven Doxia Sitetools > Issue Type: Bug > Components: Site renderer >Affects Versions: 1.1 >Reporter: Lukas Theussl >Assignee: Lukas Theussl > Fix For: 1.1.1 > > > The current SiteRendererSink only filters a list of authors and the date from > whatever is inside a head block. The rest is added to the body (retrieved > with getBody() by the DefaultSiteRenderer). This causes MSITE-194. -- 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-458) GitChangeLogCommand always reports over the whole git repo - also for child modules
[
http://jira.codehaus.org/browse/SCM-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated SCM-458:
-
Assignee: Olivier Lamy
Fix Version/s: 1.3
> GitChangeLogCommand always reports over the whole git repo - also for child
> modules
> ---
>
> Key: SCM-458
> URL: http://jira.codehaus.org/browse/SCM-458
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-git
>Affects Versions: 1.1
>Reporter: Mark Struberg
>Assignee: Olivier Lamy
> Fix For: 1.3
>
> Attachments: SCM-458.patch
>
>
> The current git changelog implementation always reports the changelog of the
> full repo.
> This doesn't make sense for multi-module projects since reporting the
> changelog only for a single child artifact is not possible yet.
> This can be changed if we always apply a '-- ${basedir} for each
> git-whatchanged invocation.
--
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: (MANT-47) ant:clean should not delete build.xml
[
http://jira.codehaus.org/browse/MANT-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton closed MANT-47.
---
Assignee: Vincent Siveton
Resolution: Fixed
fixed in [r764400|http://svn.apache.org/viewvc?rev=764400&view=rev]
> ant:clean should not delete build.xml
> -
>
> Key: MANT-47
> URL: http://jira.codehaus.org/browse/MANT-47
> Project: Maven 2.x Ant Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Vincent Siveton
>Assignee: Vincent Siveton
> Fix For: 2.1.1
>
>
> Running mvn ant:ant will generate Ant files:
> {noformat}
> build.xml => custom targets
> maven-build.xml => generic targets
> maven-build.properties => Maven properties
> {noformat}
> So, the build.xml should not be deleted when calling mvn ant:clean.
> Nevertheless, the clean mojo could ask the user to force delete 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] Updated: (MNG-4129) Execution's inherited is not working as expected.
[
http://jira.codehaus.org/browse/MNG-4129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-4129:
---
Fix Version/s: (was: 2.1.0)
(was: 2.0.10)
(was: Documentation Deficit)
> Execution's inherited is not working as expected.
> -
>
> Key: MNG-4129
> URL: http://jira.codehaus.org/browse/MNG-4129
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.1.0
>Reporter: Imran M Yousuf
>Priority: Critical
> Attachments: pom.xml
>
>
> I have following mentioned in my POM, but 'assemble-static-gh-pages' gets
> executed in the child POMs anyway. I see that its supposed to working as of -
> MNG-3286 but it ain't so. The build process in my project
> (http://github.com/imyousuf/smart-dao/tree) is incomplete just because of it.
> {code:xml}
>
> org.apache.maven.plugins
> maven-assembly-plugin
> ${assembly.version}
> false
>
>
>
> assemble-static-gh-pages
> compile
> false
>
> single
>
>
>
>
> src/main/assembly/assemble-gh-pages.xml
>
>
>
>
>
> assemble-readme
> process-resources
> true
>
> single
>
>
>
>
> src/main/assembly/assemble-readme.xml
>
>
>
>
>
> {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] Reopened: (MNG-4129) Execution's inherited is not working as expected.
[
http://jira.codehaus.org/browse/MNG-4129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann reopened MNG-4129:
My current understanding is that this is really more than a documentation
deficit...
> Execution's inherited is not working as expected.
> -
>
> Key: MNG-4129
> URL: http://jira.codehaus.org/browse/MNG-4129
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.1.0
>Reporter: Imran M Yousuf
>Priority: Critical
> Fix For: 2.0.10, 2.1.0, Documentation Deficit
>
> Attachments: pom.xml
>
>
> I have following mentioned in my POM, but 'assemble-static-gh-pages' gets
> executed in the child POMs anyway. I see that its supposed to working as of -
> MNG-3286 but it ain't so. The build process in my project
> (http://github.com/imyousuf/smart-dao/tree) is incomplete just because of it.
> {code:xml}
>
> org.apache.maven.plugins
> maven-assembly-plugin
> ${assembly.version}
> false
>
>
>
> assemble-static-gh-pages
> compile
> false
>
> single
>
>
>
>
> src/main/assembly/assemble-gh-pages.xml
>
>
>
>
>
> assemble-readme
> process-resources
> true
>
> single
>
>
>
>
> src/main/assembly/assemble-readme.xml
>
>
>
>
>
> {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] Closed: (MNG-4129) Execution's inherited is not working as expected.
[
http://jira.codehaus.org/browse/MNG-4129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Imran M Yousuf closed MNG-4129.
---
Resolution: Not A Bug
Fix Version/s: 2.0.10
2.1.0
Documentation Deficit
Thanks Benjamin, that actually got the inherited to work as it is, but
unfortunately its not documented anywhere, if it was that would have saved me a
lot of time :).
FYI, I set false as I could not get it to work and after
that I copy pasted it, sorry for the inconvenience.
Thanks once again.
> Execution's inherited is not working as expected.
> -
>
> Key: MNG-4129
> URL: http://jira.codehaus.org/browse/MNG-4129
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.1.0
>Reporter: Imran M Yousuf
>Priority: Critical
> Fix For: Documentation Deficit, 2.1.0, 2.0.10
>
> Attachments: pom.xml
>
>
> I have following mentioned in my POM, but 'assemble-static-gh-pages' gets
> executed in the child POMs anyway. I see that its supposed to working as of -
> MNG-3286 but it ain't so. The build process in my project
> (http://github.com/imyousuf/smart-dao/tree) is incomplete just because of it.
> {code:xml}
>
> org.apache.maven.plugins
> maven-assembly-plugin
> ${assembly.version}
> false
>
>
>
> assemble-static-gh-pages
> compile
> false
>
> single
>
>
>
>
> src/main/assembly/assemble-gh-pages.xml
>
>
>
>
>
> assemble-readme
> process-resources
> true
>
> single
>
>
>
>
> src/main/assembly/assemble-readme.xml
>
>
>
>
>
> {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] Updated: (MANT-47) ant:clean should not delete build.xml
[
http://jira.codehaus.org/browse/MANT-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton updated MANT-47:
Fix Version/s: 2.1.1
> ant:clean should not delete build.xml
> -
>
> Key: MANT-47
> URL: http://jira.codehaus.org/browse/MANT-47
> Project: Maven 2.x Ant Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Vincent Siveton
> Fix For: 2.1.1
>
>
> Running mvn ant:ant will generate Ant files:
> {noformat}
> build.xml => custom targets
> maven-build.xml => generic targets
> maven-build.properties => Maven properties
> {noformat}
> So, the build.xml should not be deleted when calling mvn ant:clean.
> Nevertheless, the clean mojo could ask the user to force delete 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: (SCM-458) GitChangeLogCommand always reports over the whole git repo - also for child modules
[
http://jira.codehaus.org/browse/SCM-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=172754#action_172754
]
Imran M Yousuf commented on SCM-458:
The patch looks fine to me.
> GitChangeLogCommand always reports over the whole git repo - also for child
> modules
> ---
>
> Key: SCM-458
> URL: http://jira.codehaus.org/browse/SCM-458
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-git
>Affects Versions: 1.1
>Reporter: Mark Struberg
> Attachments: SCM-458.patch
>
>
> The current git changelog implementation always reports the changelog of the
> full repo.
> This doesn't make sense for multi-module projects since reporting the
> changelog only for a single child artifact is not possible yet.
> This can be changed if we always apply a '-- ${basedir} for each
> git-whatchanged invocation.
--
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: (MANT-47) ant:clean should not delete build.xml
ant:clean should not delete build.xml
-
Key: MANT-47
URL: http://jira.codehaus.org/browse/MANT-47
Project: Maven 2.x Ant Plugin
Issue Type: Bug
Affects Versions: 2.1
Reporter: Vincent Siveton
Running mvn ant:ant will generate Ant files:
{noformat}
build.xml => custom targets
maven-build.xml => generic targets
maven-build.properties => Maven properties
{noformat}
So, the build.xml should not be deleted when calling mvn ant:clean.
Nevertheless, the clean mojo could ask the user to force delete 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] Updated: (SCM-458) GitChangeLogCommand always reports over the whole git repo - also for child modules
[
http://jira.codehaus.org/browse/SCM-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg updated SCM-458:
--
Attachment: SCM-458.patch
> GitChangeLogCommand always reports over the whole git repo - also for child
> modules
> ---
>
> Key: SCM-458
> URL: http://jira.codehaus.org/browse/SCM-458
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-git
>Affects Versions: 1.1
>Reporter: Mark Struberg
> Attachments: SCM-458.patch
>
>
> The current git changelog implementation always reports the changelog of the
> full repo.
> This doesn't make sense for multi-module projects since reporting the
> changelog only for a single child artifact is not possible yet.
> This can be changed if we always apply a '-- ${basedir} for each
> git-whatchanged invocation.
--
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: (SCM-458) GitChangeLogCommand always reports over the whole git repo - also for child modules
GitChangeLogCommand always reports over the whole git repo - also for child
modules
---
Key: SCM-458
URL: http://jira.codehaus.org/browse/SCM-458
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-git
Affects Versions: 1.1
Reporter: Mark Struberg
The current git changelog implementation always reports the changelog of the
full repo.
This doesn't make sense for multi-module projects since reporting the changelog
only for a single child artifact is not possible yet.
This can be changed if we always apply a '-- ${basedir} for each
git-whatchanged invocation.
--
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: (MWAR-191) CannotResolveClassException when switching to tomcat deployment with context.xml
[
http://jira.codehaus.org/browse/MWAR-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephane Nicoll closed MWAR-191.
Assignee: Stephane Nicoll
Resolution: Duplicate
> CannotResolveClassException when switching to tomcat deployment with
> context.xml
>
>
> Key: MWAR-191
> URL: http://jira.codehaus.org/browse/MWAR-191
> Project: Maven 2.x WAR Plugin
> Issue Type: Bug
> Environment: linux, java 1.4.2
>Reporter: Trenton
>Assignee: Stephane Nicoll
>
> I have the following profile in my pom, which when enabled, seems to cause
> this. I first compile and deploy my project to tomcat, without this profile
> enabled. Then, when I enable it, if I do not first do "mvn clean", I get the
> exception that follows...
>
> local
>
>
>
> org.codehaus.mojo
> tomcat-maven-plugin
>
> context
>
>
>
> org.apache.maven.plugins
> maven-war-plugin
> 2.1-alpha-1
>
>
>
> src/main/
>
> META-INF
>
> true
>
> context.xml
>
>
>
>
>
>
>
>
> tre...@reuben /MyDocuments/java/oros/oros-gcap $ mvn
> -Ddebug.package=ca.montage.banner.server.RemoteProgram
> -Plocal-aucm,inproc,local package tomcat:deploy
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO] oros
> [INFO] oros rmi component
> [INFO] oros web component
> [INFO] Searching repository for plugin with prefix: 'tomcat'.
> [INFO]
>
> [INFO] Building oros
> [INFO]task-segment: [package, tomcat:deploy]
> [INFO]
>
> [INFO] [site:attach-descriptor]
> [INFO] Preparing tomcat:deploy
> [INFO] [site:attach-descriptor]
> [INFO] [tomcat:deploy]
> [INFO] Skipping non-war project
> [INFO]
>
> [INFO] Building oros rmi component
> [INFO]task-segment: [package, tomcat:deploy]
> [INFO]
>
> [INFO] [resources:resources]
> [WARNING] File encoding has not been set, using platform encoding
> ANSI_X3.4-1968, i.e. build is platform dependent!
> [WARNING] Using platform encoding (ANSI_X3.4-1968 actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] Copying 5 resources
> [INFO] [compiler:compile]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [rmic:rmic {execution: rmi compilation}]
> [INFO] No out of date rmi classes to process.
> [INFO] [resources:testResources]
> [WARNING] Using platform encoding (ANSI_X3.4-1968 actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] skip non existing resourceDirectory
> /data/MyDocuments/java/oros/oros-gcap/rmi/src/test/resources
> [INFO] [compiler:testCompile]
> [INFO] Not compiling test sources
> [INFO] [surefire:test]
> [INFO] Tests are skipped.
> [INFO] [jar:jar]
> [INFO] Building jar:
> /data/MyDocuments/java/oros/oros-gcap/rmi/target/oros-rmi.jar
> [INFO] [rmic:package {execution: rmi package}]
> [INFO] Building RMI stub jar:
> /data/MyDocuments/java/oros/oros-gcap/rmi/target/oros-rmi-client.jar
> [INFO] Building jar:
> /data/MyDocuments/java/oros/oros-gcap/rmi/target/oros-rmi-client.jar
> [INFO] Preparing tomcat:deploy
> [INFO] [resources:resources]
> [WARNING] File encoding has not been set, using platform encoding
> ANSI_X3.4-1968, i.e. build is platform dependent!
> [WARNING] Using platform encoding (ANSI_X3.4-1968 actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] Copying 5 resources
> [INFO] [compiler:compile]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [rmic:rmic {execution: rmi compilation}]
> [INFO] No out of date rmi classes to process.
> [INFO] [resources:testResources]
> [WARNING] Using platform encoding (ANSI_X3.4-1968 actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] skip non existing resourceDirectory
> /data/MyDocuments/java/oros/oros-gcap/rmi/src/test/resources
> [INFO] [compiler:testCompile]
> [INFO] Not compiling test sources
> [INFO] [surefire:test]
> [INFO] Tests are skipped.
> [INFO] [jar:jar]
> [INFO] Building jar:
> /data/MyDocuments/java/oros/oros-gcap/rmi/target/oros-rmi.jar
> [INFO] [rmic:package {execution: rmi package}]
> [INFO] Building RMI stub jar:
> /data/MyDocuments/ja
[jira] Commented: (MSITE-397) Artifact ###### has no file error.
[ http://jira.codehaus.org/browse/MSITE-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=172753#action_172753 ] Dennis Lundberg commented on MSITE-397: --- Like I said before, we need the *full* output of the log to be able to determine where the error is. > Artifact ## has no file error. > -- > > Key: MSITE-397 > URL: http://jira.codehaus.org/browse/MSITE-397 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0 > Environment: Windows xp, tomcat 5.5 server >Reporter: Damian Sinczak >Priority: Minor > > During 'mvn site' command on project i receive some strange errors. Their are > no critical, but they are still errors. > Console dump: > [ERROR] Artifact: org.apache.abdera:abdera-core:jar:0.4.0-incubating has no > file > . > [ERROR] Artifact: > org.apache.abdera:abdera-extensions-json:jar:0.4.0-incubating > has no file. > [ERROR] Artifact: > org.apache.abdera:abdera-extensions-main:jar:0.4.0-incubating > has no file. > [ERROR] Artifact: org.apache.abdera:abdera-i18n:jar:0.4.0-incubating has no > file > . > [ERROR] Artifact: org.apache.abdera:abdera-parser:jar:0.4.0-incubating has no > fi > le. > [ERROR] Artifact: org.apache.cxf:cxf-api:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-common-schemas:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-common-utilities:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-rt-bindings-soap:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-rt-bindings-xml:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-rt-core:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-rt-databinding-jaxb:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-rt-frontend-simple:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-rt-ws-addr:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-tools-common:jar:2.2 has no file. > [ERROR] Artifact: > org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0 > .2 has no file. > [ERROR] Artifact: > org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1 > .1 has no file. > [ERROR] Artifact: > org.apache.geronimo.specs:geronimo-javamail_1.4_spec:jar:1.5 h > as no file. > [ERROR] Artifact: org.apache.geronimo.specs:geronimo-jaxws_2.1_spec:jar:1.0 > has > no file. > [ERROR] Artifact: org.apache.geronimo.specs:geronimo-servlet_2.5_spec:jar:1.2 > ha > s no file. > [ERROR] Artifact: > org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1 > has no file. > [ERROR] Artifact: > org.apache.geronimo.specs:geronimo-ws-metadata_2.0_spec:jar:1. > 1.2 has no file. > [ERROR] Artifact: org.apache.neethi:neethi:jar:2.0.4 has no file. > [ERROR] Artifact: org.apache.ws.commons.axiom:axiom-api:jar:1.2.7 has no file. > [ERROR] Artifact: org.apache.ws.commons.axiom:axiom-impl:jar:1.2.7 has no > file. > [ERROR] Artifact: org.apache.ws.commons.schema:XmlSchema:jar:1.4.4 has no > file. > [ERROR] Artifact: org.apache.xmlbeans:xmlbeans:jar:2.3.0 has no file. > [ERROR] Artifact: org.codehaus.jettison:jettison:jar:1.0.1 has no file. > [ERROR] Artifact: org.codehaus.woodstox:wstx-asl:jar:3.2.6 has no file. > [ERROR] Artifact: org.hibernate:ejb3-persistence:jar:1.0.1.GA has no file. > [ERROR] Artifact: org.hibernate:hibernate-commons-annotations:jar:3.0.0.ga > has n > o file. > [ERROR] Artifact: org.mortbay.jetty:jetty:jar:6.1.15 has no file. > [ERROR] Artifact: org.mortbay.jetty:jetty-util:jar:6.1.15 has no file. > [ERROR] Artifact: org.slf4j:slf4j-api:jar:1.3.1 has no file. > [ERROR] Artifact: org.slf4j:slf4j-jdk14:jar:1.3.1 has no file. > [ERROR] Artifact: org.springframework:spring-beans:jar:2.5.5 has no file. > [ERROR] Artifact: org.springframework:spring-context:jar:2.5.5 has no file. > [ERROR] Artifact: org.springframework:spring-core:jar:2.5.5 has no file. > [ERROR] Artifact: org.springframework:spring-web:jar:2.5.5 has no file. > [ERROR] Artifact: wsdl4j:wsdl4j:jar:1.6.2 has no file. > [ERROR] Artifact: xalan:xalan:jar:2.6.0 has no file. > [ERROR] Artifact: xerces:xercesImpl:jar:2.6.2 has no file. > [ERROR] Artifact: xerces:xmlParserAPIs:jar:2.6.2 has no file. > [ERROR] Artifact: xml-apis:xml-apis:jar:1.3.02 has no file. > [ERROR] Artifact: xml-resolver:xml-resolver:jar:1.2 has no file. > [ERROR] Artifact: xom:xom:jar:1.0 has no file. > [INFO] Generating "Project Team" report. > [INFO] Generating "Project License" report. > [INFO] Generating "Project Plugins" report. > [INFO] Generating "Maven Surefire Report" report. > [INFO] Generating "FindBugs Report" report. > [INFO] Using source root: > [INFO] C:\edys_workspace\edystok\target\classes > [INFO] Using test source root: > [INFO] C:\edys_workspace\edystok\target\test-classes > [INFO] No effort provided, using default effort. > [INFO] Adding Source Director
