[jira] Commented: (MAVENUPLOAD-1936) Hibernate 3.2.6 ga upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125128 ] Geoffrey De Smet commented on MAVENUPLOAD-1936: --- I saw a mail on their dev list through google which said they 'll have maven support from 3.3.x (which is really good news :) and that 3.2.6 will be left out in the cold (2 bad). > Hibernate 3.2.6 ga upload > - > > Key: MAVENUPLOAD-1936 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1936 > Project: maven-upload-requests > Issue Type: Task >Reporter: Emil A. Lefkof III >Assignee: Carlos Sanchez > > Not a member of the Hibernate team but thought the new 3.2.6 ga should be > uploaded to ibiblio -- 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: (MJAR-99) Unsigned jar is installed instead of signed jar when the signature wasn't updated
Unsigned jar is installed instead of signed jar when the signature wasn't
updated
-
Key: MJAR-99
URL: http://jira.codehaus.org/browse/MJAR-99
Project: Maven 2.x Jar Plugin
Issue Type: Bug
Components: sign
Affects Versions: 2.2
Environment: Maven 2.0.8, JRE 1.5, WindowsXP
Reporter: Bryan Brouckaert
When running the first time or after an update it installes the signed jar.
[INFO] [jar:sign {execution: default}]
[INFO] [install:install]
[INFO] Installing
D:\Projects\CIN\MyCareNet\Portal\applet\target\signed\applet-0.3-SNAPSHOT.jar
to
D:\Downloads\Maven\be\cin\mycarenet\portal\applet\0.3-SNAPSHOT\applet-0.3-SNAPSHOT.jar
The second run the signing is skipped (which is ok), but the unsigned jar in
installed which isn't ok.
[INFO] [jar:sign {execution: default}]
[debug] jarsigner executable=[C:\Java\jdk1.5.0_14\jre\..\bin\jarsigner.exe]
[debug] Executing: cmd.exe /X /C '"C:\Java\jdk1.5.0_14\jre\..\bin\jarsigner.exe
-verify
D:\Projects\CIN\MyCareNet\Portal\applet\target\signed\applet-0.3-SNAPSHOT.jar"'
[info] jar verified.
[INFO] JAR
D:\Projects\CIN\MyCareNet\Portal\applet\target\signed\applet-0.3-SNAPSHOT.jar
is already signed. Skipping.
[INFO] [install:install]
[INFO] Installing
D:\Projects\CIN\MyCareNet\Portal\applet\target\applet-0.3-SNAPSHOT.jar to
D:\Downloads\Maven\be\cin\mycarenet\portal\applet\0.3-SNAPSHOT\applet-0.3-SNAPSHOT.jar
--
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: (MPA-106) Process Benjamin Bentmann
[ http://jira.codehaus.org/browse/MPA-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125137 ] Lukas Theussl commented on MPA-106: --- CLA is on file, account requested. > Process Benjamin Bentmann > - > > Key: MPA-106 > URL: http://jira.codehaus.org/browse/MPA-106 > Project: Maven Project Administration > Issue Type: Task > Components: New Committers >Affects Versions: 2008-q1 >Reporter: Lukas Theussl > > Waiting for CLA -- 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: (DOXIA-204) Add generic parameters support to Figure and Link events
[
http://jira.codehaus.org/browse/DOXIA-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125140
]
Lukas Theussl commented on DOXIA-204:
-
I think it's a matter of practicability (if that word exists in english... ;)
), and keeping the api as concise as possible. It is somewhat subjective what
you consider 'well known' attributes. For instance for the img attributes I
listed above, I would consider all but the last two as 'well known'. So
together with the base attributes that would make 13 method parameters...
Also note the example of tableCell(); where someone already added the method
tableCell( String width ); but I wouldn't consider 'align, colspan, height,
rowspan, valign' any less known than 'width'. And we are not going to add a
method for each of them...
IMO we should only keep parameters if they are required or logically necessary
for a sink event, eg:
{code}
void anchor( String name, SinkEventAttributes attributes );
void figureGraphics( String src, SinkEventAttributes attributes );
void link( String name, SinkEventAttributes attributes );
void numberedList( int numbering, SinkEventAttributes attributes );
void section( int level, SinkEventAttributes attributes );
void sectionTitle( int level, SinkEventAttributes attributes );
{code}
so SinkEventAttributes would only specify optional parameters. WDYT?
> Add generic parameters support to Figure and Link events
>
>
> Key: DOXIA-204
> URL: http://jira.codehaus.org/browse/DOXIA-204
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Sink API
>Affects Versions: 1.0-alpha-10
>Reporter: Vincent Massol
> Fix For: 1.0-beta-1
>
>
> For example XWiki has the following syntax for image macros and links:
> * image: http://code.xwiki.org/xwiki/bin/view/Macros/ImageMacro
> * links: http://platform.xwiki.org/xwiki/bin/view/Main/XWikiSyntax#HLinks
> For the image macro there are the "document" and "fromincludingdoc" which are
> specific to XWiki and thus cannot be put as standard parameters.
> Same for links.
> Thus I propose to allow parsers to pass a Map of properties (pair/values) to
> the Sink API so that sinks can be written to understand them (the XWiki sink
> would understand them for example).
--
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: (MECLIPSE-393) additionalConfig should be able to append to files.
additionalConfig should be able to append to files. --- Key: MECLIPSE-393 URL: http://jira.codehaus.org/browse/MECLIPSE-393 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Components: Core : Workspace settings Reporter: Daniel Lehmann Attachments: appendAdditionalConfig.path It would be rather useful for me, if the additionalConfig option could be configured to append to the specified file rather than overwriting it. A patch is included. -- 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: (MJAVADOC-179) Aggregate report ignores sourcepath customization of subprojects
Aggregate report ignores sourcepath customization of subprojects
Key: MJAVADOC-179
URL: http://jira.codehaus.org/browse/MJAVADOC-179
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.3
Environment: Maven 2.0.8, Java 1.5, Windows
Reporter: Fol De Rol
When using aggregate javadoc reporting with one of subproject being customized
to include java sources from alternative directories, only original source
directories are passed to javadoc executable.
For instance, I use POJO's generated by Hibernate3 from HBM files which are
documented. The generated files are placed into
${basedir}/target/hibernate3/generated-sources/ directory. My subproject's POM
contains the following definition:
{code:xml}
org.apache.maven.plugins
maven-javadoc-plugin
2.2
$\{basedir\}/src/main/java;$\{basedir]}/target/hibernate3/generated-sources
{code}
and it works correctly if running {{mvn site}} on subproject level. If run from
the parent project, as I traced, the custom directory does not passed to the
javadoc tool.
--
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: (MEV-577) com/sun/xml/rpc/jaxrpc-impl/1.1.3_01/jaxrpc-impl-1.1.3_01.pom cannot find saaj-impl 1.3
com/sun/xml/rpc/jaxrpc-impl/1.1.3_01/jaxrpc-impl-1.1.3_01.pom cannot find saaj-impl 1.3 --- Key: MEV-577 URL: http://jira.codehaus.org/browse/MEV-577 Project: Maven Evangelism Issue Type: Bug Components: Relocation Reporter: deckrider Hello, I am using... http://repo1.maven.org/maven2/com/sun/xml/rpc/jaxrpc-impl/1.1.3_01/jaxrpc-impl-1.1.3_01.pom ...which contains... javax.xml.soap saaj-impl 1.3 However... http://repo1.maven.org/maven2/javax/xml/soap/saaj-impl ...doesn't exist. I did a search and found that... http://repo1.maven.org/maven2/com/sun/xml/saaj-impl/1.3/saaj-impl-1.3.pom ...does exist, and includes relocation information. This relocation information appears to be valid, since... http://repo1.maven.org/maven2/com/sun/xml/messaging/saaj/saaj-impl/1.3/saaj-impl-1.3.pom ...exists. So to fix this, please copy... http://repo1.maven.org/maven2/com/sun/xml/saaj-impl/1.3/saaj-impl-1.3.pom ...to... http://repo1.maven.org/maven2/javax/xml/soap/saaj-impl/1.3/saaj-impl-1.3.pom Thanks. -- 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: (MJAR-99) Unsigned jar is installed instead of signed jar when the signature wasn't updated
[
http://jira.codehaus.org/browse/MJAR-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125169
]
Bryan Brouckaert commented on MJAR-99:
--
This is of couse only a problem with the following configuration:
org.apache.maven.plugins
maven-jar-plugin
sign
/code.keystore
alias
xxx
${project.build.directory}/signed/${project.build.finalName}.jar
> Unsigned jar is installed instead of signed jar when the signature wasn't
> updated
> -
>
> Key: MJAR-99
> URL: http://jira.codehaus.org/browse/MJAR-99
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
> Components: sign
>Affects Versions: 2.2
> Environment: Maven 2.0.8, JRE 1.5, WindowsXP
>Reporter: Bryan Brouckaert
>
> When running the first time or after an update it installes the signed jar.
> [INFO] [jar:sign {execution: default}]
> [INFO] [install:install]
> [INFO] Installing
> D:\Projects\CIN\MyCareNet\Portal\applet\target\signed\applet-0.3-SNAPSHOT.jar
> to
> D:\Downloads\Maven\be\cin\mycarenet\portal\applet\0.3-SNAPSHOT\applet-0.3-SNAPSHOT.jar
> The second run the signing is skipped (which is ok), but the unsigned jar in
> installed which isn't ok.
> [INFO] [jar:sign {execution: default}]
> [debug] jarsigner executable=[C:\Java\jdk1.5.0_14\jre\..\bin\jarsigner.exe]
> [debug] Executing: cmd.exe /X /C
> '"C:\Java\jdk1.5.0_14\jre\..\bin\jarsigner.exe -verify
> D:\Projects\CIN\MyCareNet\Portal\applet\target\signed\applet-0.3-SNAPSHOT.jar"'
> [info] jar verified.
> [INFO] JAR
> D:\Projects\CIN\MyCareNet\Portal\applet\target\signed\applet-0.3-SNAPSHOT.jar
> is already signed. Skipping.
> [INFO] [install:install]
> [INFO] Installing
> D:\Projects\CIN\MyCareNet\Portal\applet\target\applet-0.3-SNAPSHOT.jar to
> D:\Downloads\Maven\be\cin\mycarenet\portal\applet\0.3-SNAPSHOT\applet-0.3-SNAPSHOT.jar
--
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: (ARCHETYPE-139) cannot create archetype for existing project without pre-existing pom
cannot create archetype for existing project without pre-existing pom - Key: ARCHETYPE-139 URL: http://jira.codehaus.org/browse/ARCHETYPE-139 Project: Maven Archetype Issue Type: Bug Components: Generator Affects Versions: 2.0-alpha-2 Reporter: tom nelson Unlike 1.0, the 2.0-alpha-2 version will not allow users to create a new archetype (e.g. a new pom file) for an existing project. In DefaultFilesetArchetype.java, If the archetype is 'partial', and the project directory already exists, then the pom must already exist or an exception is thrown. If the archetype is not partial, and the project directory already exists, then a ProjectDirectoryExists exception is thrown. -- 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-126) It is not possible to package empty war.
[
http://jira.codehaus.org/browse/MWAR-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125187
]
Torsten Reinhard commented on MWAR-126:
---
I´ve been running into the same problem, here´s a part of my pom.xml:
org.apache.maven.plugins
maven-war-plugin
${typeClassifier}
true
service-remote-spring
true
...
service-local-mock
mock
...
The build without any classifier works fine,
The build with the classifier "mock" only works, when I have a target\classes
directory which may be empty !
> It is not possible to package empty war.
>
>
> Key: MWAR-126
> URL: http://jira.codehaus.org/browse/MWAR-126
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2
>Reporter: Libor Kramolis
> Attachments: war-bug.txt
>
>
> If there is no java sources and no resources (src/main/java and
> src/main/resources does not exist) it is not possible to package war
> application.
> But if I do NOT user classifier of war plugin there is no problem while
> war:war goal.
> --
> org.apache.maven.lifecycle.LifecycleExecutionException: Error installing
> artifact: File
> d:\work\tutor\development\tutorialproject-war_ws\target\classes does not exist
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
> 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: Error installing
> artifact: File
> d:\work\tutor\development\tutorialproject-war_ws\target\classes does not exist
> at
> org.apache.maven.plugin.install.InstallMojo.execute(InstallMojo.java:143)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> ... 16 more
> Caused by: org.apache.maven.artifact.installer.ArtifactInstallationException:
> Error installing artifact: File
> d:\work\tutor\development\tutorialproject-war_ws\target\classes does not exist
> at
> org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:87)
> at
> org.apache.maven.plugin.install.InstallMojo.execute(InstallMojo.java:105)
> ... 18 more
> Caused by: java.io.IOException: File
> d:\work\tutor\development\tutorialproject-war_ws\target\classes does not exist
> at
> hidden.org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:845)
>
[jira] Closed: (MNG-3071) Add a command line option to dump the contents of all the classloaders used during an invocation of Maven
[ http://jira.codehaus.org/browse/MNG-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3071. - Assignee: Brett Porter Resolution: Won't Fix Fix Version/s: (was: 2.0.9) we have dependency:tree, and a different issue for domains on -X which is probably a better way to do this. > Add a command line option to dump the contents of all the classloaders used > during an invocation of Maven > - > > Key: MNG-3071 > URL: http://jira.codehaus.org/browse/MNG-3071 > Project: Maven 2 > Issue Type: New Feature >Affects Versions: 2.0.7 >Reporter: Jason van Zyl >Assignee: Brett Porter > > It is very annoying to track down what versions of what are being used, so > add a mode to the command line to dump the contents of the class realms being > used. -- 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-2045) Maven can't compile against sibling test-jar dependency in multiproject (Test Attached)
[ http://jira.codehaus.org/browse/MNG-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2045. - Resolution: Fixed Fix Version/s: (was: 2.0.9) 2.0.8 this was fixed in 2.0.8 - sample.zip, it1021.tar.gz and the integration all test with it. Please open a new issue with more specifics if you are still seeing the problem. > Maven can't compile against sibling test-jar dependency in multiproject (Test > Attached) > --- > > Key: MNG-2045 > URL: http://jira.codehaus.org/browse/MNG-2045 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.2 > Environment: WinXP >Reporter: Brian Fox >Assignee: Brian Fox > Fix For: 2.0.8 > > Attachments: it1021.tar.gz, mng-2045-ittest.zip, > MNG-2045-maven-project-r577340.patch1, MNG-2045-maven-project-r577340.patch2, > sample.zip > > > I have 2 projects under a parent like so: > --Parent > --- sample-jar > --- sample-jar-user > sample-jar builds and installs a test-jar along with the normal jar. > sample-jar-user depends on the test-jar at compile time. When I build from > the parent folder, the build fails because it can't find the class. When I go > to sample-jar-user and build, it works fine. > In the attached test case, to reproduce: > from the root folder, run mvn clean install - See it fail. > cd sample-jar-user; mvn clean install - see it succeed. > I remember reading somewhere that in multiprojects, maven attempts to locate > the sibling classes in the source tree instead of using the jars from the > repository. I'm guessing the problem is here that it's not looking in > ../sample-jar/target/test-classes for this code, but really one should expect > this to come from the repository. -- 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-3402) MavenArtifactFilterManager needs to not filtering doxia-sink-api
[ http://jira.codehaus.org/browse/MNG-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3402: -- Fix Version/s: (was: 2.1-alpha-1) > MavenArtifactFilterManager needs to not filtering doxia-sink-api > > > Key: MNG-3402 > URL: http://jira.codehaus.org/browse/MNG-3402 > Project: Maven 2 > Issue Type: Improvement > Components: Maven Filtering >Affects Versions: 2.0.8 >Reporter: Vincent Siveton > Fix For: 2.0.9 > > Attachments: MavenArtifactFilterManager.diff > > > A plugin (like pdf-plugin) needs to use the most recent sink API and not the > API embedded in maven. -- 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-2848) Environment variables in profile activation not working
[
http://jira.codehaus.org/browse/MNG-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-2848:
--
Fix Version/s: (was: 2.1-alpha-1)
> Environment variables in profile activation not working
> ---
>
> Key: MNG-2848
> URL: http://jira.codehaus.org/browse/MNG-2848
> Project: Maven 2
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 2.0.4, 2.0.5
> Environment: Windows XP Professional, JDK 1.5
>Reporter: Muhammad Alsebaey
>Assignee: Vincent Siveton
> Fix For: 2.0.9
>
> Attachments: MNG-2848.patch
>
>
> When using an environment variable as a profile activation variable, it
> doesnt work, using either env.X or ${env.X} doesnt work.
> I found the same issue on the forums unresolved.
> http://www.nabble.com/profile-activation-based-on-environment-variables-tf2585492s177.html#a7208580
> Basically, the following doesnt work, where FOO is a windows environment
> variable (like PATH for example) :
> {code:xml}
>
> haroon-workstation
>
>
> env.FOO
> foo
>
>
> ...
>
> {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: (MNG-3419) Build continues despite OutOfMemoryError
[ http://jira.codehaus.org/browse/MNG-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-3419: Fix Version/s: 2.0.9 > Build continues despite OutOfMemoryError > > > Key: MNG-3419 > URL: http://jira.codehaus.org/browse/MNG-3419 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.7 >Reporter: Sanjeeb Sahoo > Fix For: 2.0.9 > > > [I have already sent this question to users forum twice, but no response, so > I am filing this issue] > I am seeing something very strange. We have our own plugin(it's basically an > annotation processor) that gets invoked as part of compile phase. It appears > that the JVM gets OutOfMemoryError when this plugin is executed, yet the > build continues to the next phase instead of aborting. I ran with -X option > and it shows that the plugin is invoked in process. I have looked at our > plugin code and we do not catch Throwable or Error in our code. So, it > appears to be a bug in Maven. Given below is some selected output that I > think should give an idea of what's going on... > [INFO] > > [INFO] Building Web Container for GlassFish > [INFO]task-segment: [install] > [INFO] > > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > ... > [DEBUG] Configuring mojo > 'com.sun.enterprise:hk2-maven-plugin:0.2-SNAPSHOT:hk2-compile' --> > ... > [DEBUG] (f) fork = false > ... > [INFO] [hk2:hk2-compile] > [DEBUG] Using compiler 'hk2-apt'. > [DEBUG] Source directories: > [/space/ss141213/WS/gf/v3/web/webtier/src/main/java] > [DEBUG] Classpath: [/space/ss141213/WS/gf/v3/web/webtier/target/classes... > [INFO] Compiling 660 source files to > /space/ss141213/WS/gf/v3/web/webtier/target/classes > The system is out of resources. > Consult the following stack trace for details. > java.lang.OutOfMemoryError: Java heap space >at > java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:99) >at > java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:393) >at java.lang.StringBuilder.append(StringBuilder.java:120) >at com.sun.tools.javac.jvm.ClassReader.list(ClassReader.java:1756) >at com.sun.tools.javac.jvm.ClassReader.listAll(ClassReader.java:1882) >at com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:1901) >at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:1538) >at com.sun.tools.javac.code.Symbol.complete(Symbol.java:355) >at > com.sun.tools.javac.jvm.ClassReader.completeOwners(ClassReader.java:1547) >at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:1534) >at com.sun.tools.javac.code.Symbol.complete(Symbol.java:355) >at > com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:612) >at com.sun.tools.javac.code.Symbol$ClassSymbol.flags(Symbol.java:550) >at > com.sun.tools.javac.code.Types$AsSuperFcn.visitClassType(Types.java:1440) >at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:482) >at com.sun.tools.javac.code.Types$AsSuperFcn.asSuper(Types.java:1417) >at > com.sun.tools.javac.code.Types$AsSuperFcn.visitClassType(Types.java:1434) >at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:482) >at com.sun.tools.javac.code.Types$AsSuperFcn.asSuper(Types.java:1417) >at com.sun.tools.javac.code.Types.asSuper(Types.java:1407) >at > com.sun.tools.javac.code.Types$IsSubTypeFcn.visitClassType(Types.java:429) >at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:482) >at > com.sun.tools.javac.code.Types$IsSubTypeFcn.isSubType(Types.java:353) >at com.sun.tools.javac.code.Types.isSubType(Types.java:331) >at com.sun.tools.javac.code.Types.isSubTypeUnchecked(Types.java:311) >at com.sun.tools.javac.code.Types.isConvertible(Types.java:278) >at com.sun.tools.javac.code.Types.isAssignable(Types.java:1630) >at com.sun.tools.javac.comp.Check.checkType(Check.java:325) >at com.sun.tools.javac.comp.Annotate.enterAnnotation(Annotate.java:122) >at > com.sun.tools.javac.comp.MemberEnter.enterAnnotations(MemberEnter.java:705) > Note: Some input files use or override a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > [INFO] [resources:testResources] > [INFO] Using default encoding to copy filtered resources. > ... > Thanks, > Sahoo -- This message is automatically generated by JIRA
[jira] Created: (MNG-3421) artifacts not found in any repo are continually rechecked in subsequent builds
artifacts not found in any repo are continually rechecked in subsequent builds -- Key: MNG-3421 URL: http://jira.codehaus.org/browse/MNG-3421 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.1-alpha-1 Reporter: John Casey Attachments: maven-artifact-c.diff During subsequent calls to Maven, artifacts that could not be found on any repository are continually rechecked. Need to track attempts to resolve artifacts with timestamps and make those attempts subject to updateInterval, not just found artifacts that may be stale. I'm attaching a patch sent to me by Igor Fedorenko, which I'll review and commit if appropriate. -- 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: (ARCHETYPE-139) cannot create archetype for existing project without pre-existing pom
[ http://jira.codehaus.org/browse/ARCHETYPE-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125205 ] tom nelson commented on ARCHETYPE-139: -- Thank you for your response. If this is by design, then I will have to either continue to use version 1.0, or use my modified version of your 2.0 code in order to, for example, create a project using an eclipse plugin, then have the eclipse plugin use the maven-embedder to call the archetype plugin and generate the maven pom file. I'd be happy to supply my changes as a patch, if you would be interested. > cannot create archetype for existing project without pre-existing pom > - > > Key: ARCHETYPE-139 > URL: http://jira.codehaus.org/browse/ARCHETYPE-139 > Project: Maven Archetype > Issue Type: Bug > Components: Generator >Affects Versions: 2.0-alpha-2 >Reporter: tom nelson > > Unlike 1.0, the 2.0-alpha-2 version will not allow users to create a new > archetype (e.g. a new pom file) for an existing project. In > DefaultFilesetArchetype.java, If the archetype is 'partial', and the project > directory already exists, then the pom must already exist or an exception is > thrown. If the archetype is not partial, and the project directory already > exists, then a ProjectDirectoryExists exception is thrown. -- 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: (MASSEMBLY-1) assembly jar-with-dependencies does not utilize or provide for manifest configuration
[ http://jira.codehaus.org/browse/MASSEMBLY-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125206 ] Alvin Thompson commented on MASSEMBLY-1: this is NOT fixed; the manifest properties are still only added to the default jar, not the jar with dependencies. this issue should be reopened. > assembly jar-with-dependencies does not utilize or provide for manifest > configuration > - > > Key: MASSEMBLY-1 > URL: http://jira.codehaus.org/browse/MASSEMBLY-1 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug > Environment: $ uname -a > Darwin xxx 8.2.0 Darwin Kernel Version 8.2.0: Fri Jun 24 17:46:54 PDT 2005; > root:xnu-792.2.4.obj~3/RELEASE_PPC Power Macintosh powerpc > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-72) > Java HotSpot(TM) Client VM (build 1.5.0_05-44, mixed mode, sharing) > $ mvn -version > Maven version: 2.0 > maven-assembly-plugin version 2.0 >Reporter: Michael Heuer >Assignee: Brett Porter >Priority: Minor > Attachments: mng-1380-src.tar.gz > > Original Estimate: 1 hour > Time Spent: 30 minutes > Remaining Estimate: 0 minutes > > Date: Mon, 31 Oct 2005 17:04:21 +1100 > From: Brett Porter <[EMAIL PROTECTED]> > To: Maven Users List <[EMAIL PROTECTED]> > Subject: Re: [m2] manifest for assembly jar-with-dependencies > Yes, that's an issue with the assembly plugin. If there is no > corresponding JIRA issue, please file one. > - Brett > On 10/28/05, Michael Heuer <[EMAIL PROTECTED]> wrote: > > Hello, > > > > I followed the guide at > > > > > http://maven.apache.org/guides/mini/guide-manifest.html > > > > to add entries to my MANIFEST.MF, and that works fine with > > > > $ mvn package > > > > However, it seems that the assembly plugin does not reuse the > > configuration information when building the jar-with-dependencies jar, so > > I'm left with a default manifest in that jar. > > > >michael -- 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-3421) artifacts not found in any repo are continually rechecked in subsequent builds
[ http://jira.codehaus.org/browse/MNG-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3421. --- Resolution: Fixed Fix Version/s: 2.1-alpha-1 applied, and verified that it's working > artifacts not found in any repo are continually rechecked in subsequent builds > -- > > Key: MNG-3421 > URL: http://jira.codehaus.org/browse/MNG-3421 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.1-alpha-1 >Reporter: John Casey >Assignee: John Casey > Fix For: 2.1-alpha-1 > > Attachments: maven-artifact-c.diff > > > During subsequent calls to Maven, artifacts that could not be found on any > repository are continually rechecked. > Need to track attempts to resolve artifacts with timestamps and make those > attempts subject to updateInterval, not just found artifacts that may be > stale. > I'm attaching a patch sent to me by Igor Fedorenko, which I'll review and > commit if appropriate. -- 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: (ARCHETYPE-131) behaviour appears to be different in batch mode for downloading artifacts
[ http://jira.codehaus.org/browse/ARCHETYPE-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed ARCHETYPE-131. -- Assignee: Brett Porter Resolution: Cannot Reproduce Fix Version/s: 2.0-alpha-2 same - must have been due to something not being released. > behaviour appears to be different in batch mode for downloading artifacts > - > > Key: ARCHETYPE-131 > URL: http://jira.codehaus.org/browse/ARCHETYPE-131 > Project: Maven Archetype > Issue Type: Bug > Components: Plugin >Affects Versions: 2.0-alpha-1 >Reporter: Brett Porter >Assignee: Brett Porter > Fix For: 2.0-alpha-2 > > > if you select version = "RELEASE" for an archetype, it succeeds in resolving > it to the latest release in interactive mode, but fails with an exception in > batch mode -- 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-3418) Inclusion of Wagon Webdav component in 2.0.9 distribution
[ http://jira.codehaus.org/browse/MNG-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3418. - Assignee: Brett Porter (was: Brian Fox) Resolution: Duplicate Fix Version/s: (was: 2.0.9) > Inclusion of Wagon Webdav component in 2.0.9 distribution > - > > Key: MNG-3418 > URL: http://jira.codehaus.org/browse/MNG-3418 > Project: Maven 2 > Issue Type: Wish > Components: Deployment >Affects Versions: 2.0.9 >Reporter: James William Dumay >Assignee: Brett Porter > > I propose the inclusion of Wagon Webdav component for the 2.0.9 release. > This helps by not having to have a pom when using deploy:deploy-file to load > the Wagon dav component or sourcing the correct dependencies to put in Mavens > classpath. -- 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: (SUREFIRE-340) Resource classpaths differ if project has flat structure, causing MappingExceptions and more.
[ http://jira.codehaus.org/browse/SUREFIRE-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barrett Nuzum reopened SUREFIRE-340: Still occurs for me using maven 2.0.8, and the released version of the 2.4 version of maven-surefire-plugin. Can anyone else reproduce with the attached test case while *NOT* using unreleased versions of plugins, please? > Resource classpaths differ if project has flat structure, causing > MappingExceptions and more. > - > > Key: SUREFIRE-340 > URL: http://jira.codehaus.org/browse/SUREFIRE-340 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.3 > Environment: Maven 2.0.6, > IBM 1.4.2 JDK on RHEL 4 on an HP Itanium, and also Apple 1.5.0 on Mac OSX >Reporter: Barrett Nuzum > Attachments: surefire-bug-testcases.tar.gz > > > We have heavy dependence on Spring and Hibernate. > We maintain a flat project structure as this is a great deal easier to manage > in an IDE. > We have tests that pass if you build them from a leaf-level application. > If run from the parent project, as a multimodule build, the tests fail. > Root >\- Parent Build >\- Child1 Build > The exact same project can pass a multimodule build if the project structure > is nested. > Root > \- Parent Build >\- Child1 Build > Both scenarios are included in the attached file. > The child builds correctly under both scenarios if you cd directly to it's > directory and run install or test. > Both builds display an appropriate classpath if run with -X, but the flat > structure cannot find the resource. > I believe this to be an incompatibility with Spring and it's methods for > getting a ResourceLoader. > All permutations and combinations of: > , and > also have no effect. -- 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-2664) Add native support for webdav
[ http://jira.codehaus.org/browse/MNG-2664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-2664: -- Fix Version/s: (was: 2.1) 2.0.9 > Add native support for webdav > - > > Key: MNG-2664 > URL: http://jira.codehaus.org/browse/MNG-2664 > Project: Maven 2 > Issue Type: New Feature > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: Arnaud Heritier >Assignee: Brett Porter > Fix For: 2.0.9 > > Attachments: MNG-2664.patch > > > Actually with maven 2.0.4 we can't use the deploy:deploy-file goal to add an > artifact on a remote repository with webdav. > This is really annoying for archiva which supports webdav for uploads. -- 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-2664) Add native support for webdav
[ http://jira.codehaus.org/browse/MNG-2664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter reopened MNG-2664: --- Assignee: Brett Porter (was: Jason van Zyl) it appears that this works with the changes since 2.0.5 for plugin isolation. The only problem is the injection of commons-logging which can be addressed through shading, so I'll take a look. > Add native support for webdav > - > > Key: MNG-2664 > URL: http://jira.codehaus.org/browse/MNG-2664 > Project: Maven 2 > Issue Type: New Feature > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: Arnaud Heritier >Assignee: Brett Porter > Fix For: 2.0.9 > > Attachments: MNG-2664.patch > > > Actually with maven 2.0.4 we can't use the deploy:deploy-file goal to add an > artifact on a remote repository with webdav. > This is really annoying for archiva which supports webdav for uploads. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2664) Add native support for webdav
[ http://jira.codehaus.org/browse/MNG-2664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125231 ] Arnaud Heritier commented on MNG-2664: -- I love you Brett :-) > Add native support for webdav > - > > Key: MNG-2664 > URL: http://jira.codehaus.org/browse/MNG-2664 > Project: Maven 2 > Issue Type: New Feature > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: Arnaud Heritier >Assignee: Brett Porter > Fix For: 2.0.9 > > Attachments: MNG-2664.patch > > > Actually with maven 2.0.4 we can't use the deploy:deploy-file goal to add an > artifact on a remote repository with webdav. > This is really annoying for archiva which supports webdav for uploads. -- 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-2664) Add native support for webdav
[ http://jira.codehaus.org/browse/MNG-2664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2664. - Resolution: Fixed > Add native support for webdav > - > > Key: MNG-2664 > URL: http://jira.codehaus.org/browse/MNG-2664 > Project: Maven 2 > Issue Type: New Feature > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: Arnaud Heritier >Assignee: Brett Porter > Fix For: 2.0.9 > > Attachments: MNG-2664.patch > > > Actually with maven 2.0.4 we can't use the deploy:deploy-file goal to add an > artifact on a remote repository with webdav. > This is really annoying for archiva which supports webdav for uploads. -- 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: (WAGONHTTP-17) Use standalone version of httpclient
[ http://jira.codehaus.org/browse/WAGONHTTP-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125235 ] Brett Porter commented on WAGONHTTP-17: --- this is done, but I think it's actually better to do this in Maven itself (so we can share the shaded classes with wagon-webdav) > Use standalone version of httpclient > > > Key: WAGONHTTP-17 > URL: http://jira.codehaus.org/browse/WAGONHTTP-17 > Project: wagon-http > Issue Type: Improvement >Reporter: Don Brown >Assignee: Brett Porter > Attachments: build.xml, commons-httpclient-3.1-standalone.jar, > httpclient-standalone.diff > > > The current dependency on httpclient brings in commons-logging and > commons-codec, the former of which causes all sorts of problems with plugins > when bundled in the maven uber jar as the default http wagon implementation. > I created a jarjar version of commons-httpclient 3.1, which includes the two > dependencies but renamed so they don't conflict with plugins. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3379) Parallel resolution of artifacts
[ http://jira.codehaus.org/browse/MNG-3379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125238 ] Brett Porter commented on MNG-3379: --- might want to adjust the shading mechanism and do that in the distribution rather than the wagonhttp-17 method > Parallel resolution of artifacts > > > Key: MNG-3379 > URL: http://jira.codehaus.org/browse/MNG-3379 > Project: Maven 2 > Issue Type: New Feature > Components: Artifacts and Repositories >Affects Versions: 2.0.8 >Reporter: Don Brown >Assignee: Brett Porter > Attachments: parallel-resolution-2.diff, parallel-resolution-3.diff, > parallel-resolution.diff > > > Artifacts should be resolved in parallel, grouped by group id's to get around > the lack of synchronization in the local repository. The patch does the > following: > * Use a ThreadPoolExecutor to parallelize artifact resolution, but takes care > not to resolve multiple artifacts from the same group id simultaneously. > (requires Java 5) > * Makes the http wagon the default instead of the poor performing http-client > Disadvantages: > * Requires Java 5, but the backport jars could be substituted pretty easily > * Breaks some plugins due to commons-logging being in the Maven uber jar > (required by commons-httpclient), notably the apt plugin (maybe more should > use the isolatedRealm setting?) > * Screws up the progress monitor as multiple threads are updating it > Advantages: > * Much faster when combined with the http wagon (WAGON-98). I was seeing 40% > improvement on some test builds. -- 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-2710) Consider adding id element under Contributor
[ http://jira.codehaus.org/browse/MNG-2710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2710: --- Fix Version/s: (was: 2.1-alpha-1) 2.1 > Consider adding id element under Contributor > > > Key: MNG-2710 > URL: http://jira.codehaus.org/browse/MNG-2710 > Project: Maven 2 > Issue Type: New Feature > Components: POM > Environment: >ver > Microsoft Windows XP [Version 5.1.2600] > >mvn -v > Maven version: 2.0.4 > >java -version > java version "1.6.0" > Java(TM) SE Runtime Environment (build 1.6.0-b105) > Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing) >Reporter: Reshat Sabiq >Priority: Minor > Fix For: 2.1 > > > In my case, i just don't want to put name under code i didn't write, though i > did have an ID. > Could also be an apache committer contributing to a different project, so > pretty fair idea. -- 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: (ARCHETYPE-140) archetype:generate doesn't support inserting a module into a multi-module build like :create did
archetype:generate doesn't support inserting a module into a multi-module build like :create did Key: ARCHETYPE-140 URL: http://jira.codehaus.org/browse/ARCHETYPE-140 Project: Maven Archetype Issue Type: Bug Components: Generator Affects Versions: 2.0-alpha-2 Reporter: Brett Porter eg: mvn archetype:create -DartifactId=parent -DgroupId=test cd parent mvn archetype:create -DartifactId=child this would: - add the new module - update the pom with the parent POM reference (and inherit the groupId, version by default) - update the parent POM to add the new reference for the child. :generate prompts for groupId/version -- 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-2664) Add native support for webdav
[ http://jira.codehaus.org/browse/MNG-2664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-2664: -- Attachment: MNG-2664.diff attaching an alternate solution that also works, should the slf4j inclusion prove to be problematic. It provides a pre-shaded webdav lib > Add native support for webdav > - > > Key: MNG-2664 > URL: http://jira.codehaus.org/browse/MNG-2664 > Project: Maven 2 > Issue Type: New Feature > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: Arnaud Heritier >Assignee: Brett Porter > Fix For: 2.0.9 > > Attachments: MNG-2664.diff, MNG-2664.patch > > > Actually with maven 2.0.4 we can't use the deploy:deploy-file goal to add an > artifact on a remote repository with webdav. > This is really annoying for archiva which supports webdav for uploads. -- 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-3422) [regression] deploy:deploy-file does not work
[regression] deploy:deploy-file does not work - Key: MNG-3422 URL: http://jira.codehaus.org/browse/MNG-3422 Project: Maven 2 Issue Type: Bug Affects Versions: 2.1-alpha-1 Reporter: Brett Porter mvn deploy:deploy-file -Dfile=test.sh -DrepositoryId=testing -DartifactId=artifactId -DgroupId=groupId -Dversion=1.0 -Dpackaging=jar -Durl=http://vesuvius.devzuz.com/private/devzuz/releases [INFO] Searching repository for plugin with prefix: 'deploy'. [INFO] Attempting to resolve a version for plugin: org.apache.maven.plugins:maven-deploy-plugin using meta-version: LATEST [INFO] Using version: 2.3 of plugin: org.apache.maven.plugins:maven-deploy-plugin [INFO] Scanning for projects... [INFO] [INFO] Building Maven Default Project [INFO] [INFO] Id: org.apache.maven:super-pom:jar:2.1 [INFO] task-segment: [deploy:deploy-file] (aggregator-style) [INFO] [INFO] [deploy:deploy-file] [INFO] artifact groupId:artifactId: checking for updates from testing --- constituent[0]: file:/Applications/maven/apache-maven-2.1-SNAPSHOT/lib/aspectjrt-1.5.3.jar constituent[1]: file:/Applications/maven/apache-maven-2.1-SNAPSHOT/lib/backport-util-concurrent-3.0.jar constituent[2]: file:/Applications/maven/apache-maven-2.1-SNAPSHOT/lib/commons-cli-1.0.jar constituent[3]: file:/Applications/maven/apache-maven-2.1-SNAPSHOT/lib/doxia-sink-api-1.0-alpha-9.jar constituent[4]: file:/Applications/maven/apache-maven-2.1-SNAPSHOT/lib/jsch-0.1.27.jar constituent[5]: file:/Applications/maven/apache-maven-2.1-SNAPSHOT/lib/jtidy-4aug2000r7-dev.jar constituent[6]: file:/Applications/maven/apache-maven-2.1-SNAPSHOT/lib/maven-artifact-3.0-SNAPSHOT.jar constituent[7]: file:/Applications/maven/apache-maven-2.1-SNAPSHOT/lib/maven-core-2.1-SNAPSHOT.jar constituent[8]: file:/Applications/maven/apache-maven-2.1-SNAPSHOT/lib/maven-embedder-2.1-SNAPSHOT.jar constituent[9]: file:/Applications/maven/apache-maven-2.1-SNAPSHOT/lib/maven-lifecycle-2.1-SNAPSHOT.jar constituent[10]: file:/Applications/maven/apache-maven-2.1-SNAPSHOT/lib/maven-model-2.1-SNAPSHOT.jar constituent[11]: file:/Applications/maven/apache-maven-2.1-SNAPSHOT/lib/maven-plugin-api-2.1-SNAPSHOT.jar constituent[12]: file:/Applications/maven/apache-maven-2.1-SNAPSHOT/lib/maven-profile-2.1-SNAPSHOT.jar constituent[13]: file:/Applications/maven/apache-maven-2.1-SNAPSHOT/lib/maven-project-2.1-SNAPSHOT.jar constituent[14]: file:/Applications/maven/apache-maven-2.1-SNAPSHOT/lib/maven-reporting-api-2.1-SNAPSHOT.jar constituent[15]: file:/Applications/maven/apache-maven-2.1-SNAPSHOT/lib/plexus-container-default-1.0-alpha-44.jar constituent[16]: file:/Applications/maven/apache-maven-2.1-SNAPSHOT/lib/plexus-interactivity-api-1.0-alpha-6.jar constituent[17]: file:/Applications/maven/apache-maven-2.1-SNAPSHOT/lib/plexus-utils-1.5.1.jar constituent[18]: file:/Applications/maven/apache-maven-2.1-SNAPSHOT/lib/retrotranslator-runtime-1.2.1.jar constituent[19]: file:/Applications/maven/apache-maven-2.1-SNAPSHOT/lib/wagon-file-1.0-beta-2.jar constituent[20]: file:/Applications/maven/apache-maven-2.1-SNAPSHOT/lib/wagon-http-lightweight-1.0-beta-2.jar constituent[21]: file:/Applications/maven/apache-maven-2.1-SNAPSHOT/lib/wagon-http-shared-1.0-beta-2.jar constituent[22]: file:/Applications/maven/apache-maven-2.1-SNAPSHOT/lib/wagon-provider-api-1.0-beta-2.jar constituent[23]: file:/Applications/maven/apache-maven-2.1-SNAPSHOT/lib/wagon-ssh-1.0-beta-2.jar constituent[24]: file:/Applications/maven/apache-maven-2.1-SNAPSHOT/lib/wagon-ssh-common-1.0-beta-2.jar constituent[25]: file:/Applications/maven/apache-maven-2.1-SNAPSHOT/lib/wagon-ssh-external-1.0-beta-2.jar --- java.lang.NullPointerException at org.apache.maven.artifact.repository.DefaultArtifactRepository.pathOfRemoteRepositoryMetadata(DefaultArtifactRepository.java:123) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifactMetadata(DefaultWagonManager.java:390) at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolveAlways(DefaultRepositoryMetadataManager.java:349) at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolve(DefaultRepositoryMetadataManager.java:107) at org.apache.maven.project.artifact.MavenMetadataSource.retrieveAvailableVersions(MavenMetadataSource.java:433) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.artifactHasBeenDeployed(DefaultArtifactDeployer.java:169) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:91) at org.apache.maven.plugin.deploy.DeployFile
[jira] Commented: (WAGON-99) Make webdav support automatic
[ http://jira.codehaus.org/browse/WAGON-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125253 ] Joakim Erdfelt commented on WAGON-99: - The experimental branch https://svn.apache.org/repos/asf/maven/wagon/branches/wagon-http-with-webdav has added WebDAV support to the heavyweight wagon-http provider. Hopefully this wagon-http provider can make it into the standard distribution as part of the MNG-2664 effort > Make webdav support automatic > - > > Key: WAGON-99 > URL: http://jira.codehaus.org/browse/WAGON-99 > Project: wagon > Issue Type: Improvement > Components: wagon-webdav >Reporter: Paul Gier > > It would be helpful if projects could be deployed over webdav without > requiring the build extensions. > What is the reason why the deploy plugin can't automatically use webdav? -- 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
