[jira] Created: (MRM-118) code review and clean up
code review and clean up Key: MRM-118 URL: http://jira.codehaus.org/browse/MRM-118 Project: Maven Repository Manager Type: Bug Components: design Versions: 1.0-beta-1 Reporter: Brett Porter -- 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: (MRM-118) code review and clean up
[ http://jira.codehaus.org/browse/MRM-118?page=all ] Brett Porter updated MRM-118: - Assign To: Brett Porter Fix Version: 1.0-beta-1 Remaining Estimate: 8 hours Original Estimate: 8 hours > code review and clean up > > > Key: MRM-118 > URL: http://jira.codehaus.org/browse/MRM-118 > Project: Maven Repository Manager > Type: Bug > Components: design > Versions: 1.0-beta-1 > Reporter: Brett Porter > Assignee: Brett Porter > Fix For: 1.0-beta-1 > > Original Estimate: 8 hours > Remaining: 8 hours > -- 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: (DOXIA-62) Error Transferring File for doxia-sink-api
Error Transferring File for doxia-sink-api -- Key: DOXIA-62 URL: http://jira.codehaus.org/browse/DOXIA-62 Project: doxia Type: Bug Components: Site Renderer Versions: 1.0-alpha-8 Reporter: ol Priority: Critical Trying to do a "mvn site", I receive this error : [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Error transferring file org.apache.maven.doxia:doxia-sink-api:jar:1.0-alpha-8 ... at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:140) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:63) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:233) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:211) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:182) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1117) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:366) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 16 more Caused by: org.apache.maven.wagon.TransferFailedException: Error transferring file at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:99) at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:68) at org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:369) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:282) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:244) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:124) ... 23 more Caused by: java.io.IOException: Server returned HTTP response code: 500 for URL: http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-sink-api/1.0-alpha-8/doxia-sink-api-1.0-alpha-8.jar at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:791) at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:85) ... 28 more [INFO] [INFO] Total time: 55 seconds [INFO] Finished at: Wed Jun 07 08:43:32 CEST 2006 [INFO] Final Memory: 10M/18M [INFO] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MEAR-29) EAR:generate-application-xml : Ability to deactivate generation to be compliant with portlet deployment
[ http://jira.codehaus.org/browse/MEAR-29?page=all ] Stephane Nicoll updated MEAR-29: Description: I embed a WAR portlet module inside an EAR module I configure the EAR module as follows org.apache.maven.plugins maven-ear-plugin 2.1 Portlet JBOSS portlet myApp JBPortlet1-war The maven-EAR-module generates an application.xml of the following form: Thierry Portlet JBOSS portlet JBPortlet1-war-1.0.war /portlet<<< I would like to remove automatically this line The problem is: In case of a portlet deployment, the element must be omitted, or the application server reject the EAR package. There is no way today to disable generation in application.xml If i comment / remove the line in the POM file , it takes the WAR filename as context-root in the application.xml I would like to remove automatically the line. what could be the strategy? =>a tag added to the ear plugin config tutorials JBPortlet1-war =>a way to specify that application-xml has to be generated regarding portlet constraints? ( property) tutorials JBPortlet1-war true was: I embed a WAR portlet module inside an EAR module I configure the EAR module as follows org.apache.maven.plugins maven-ear-plugin 2.1 Portlet JBOSS portlet myApp JBPortlet1-war The maven-EAR-module generates an application.xml of the following form: Thierry Portlet JBOSS portlet JBPortlet1-war-1.0.war /portlet<<< I would like to remove automatically this line The problem is: In case of a portlet deployment, the element must be omitted, or the application server reject the EAR package. There is no way today to disable generation in application.xml If i comment / remove the line in the POM file , it takes the WAR filename as context-root in the application.xml I would like to remove automatically the line. what could be the strategy? =>a tag added to the ear plugin config tutorials JBPortlet1-war =>a way to specify that application-xml has to be generated regarding portlet constraints? ( property) tutorials JBPortlet1-war true Fix Version: 2.3 > EAR:generate-application-xml : Ability to deactivate > generation to be compliant with portlet deployment > -- > > Key: MEAR-29 > URL: http://jira.codehaus.org/browse/MEAR-29 > Project: Maven 2.x Ear Plugin > Type: Improvement > Versions: 2.1 > Environment: OS: WIN2K (likely any platform) > Application Server: JBOSS 4.0.3 (likely not relevant) > Reporter: Thierry Barnier > Assignee: Stephane Nicoll > Fix For: 2.3 > Attachments: no-context-root for Maven-EARplugin.patch > > > I embed a WAR portlet module inside an EAR module > I configure the EAR module as follows > > org.apache.maven.plugins > maven-ear-plugin > 2.1 > > Portlet > JBOSS portlet > > > myApp > JBPortlet1-war > > > > > > The maven-EAR-module generates an application.xml of the following form: > > Thierry Portlet > JBOSS portlet > > >JBPortlet1-war-1.0.war > /portlet<<< I would like to > remove automatically this line > > > > The problem is: > In case of a portlet deployment, the element must be omitted, > or the application server reject the EAR package. > There is no way today to disable generation in application.xml > If i comment / remove the line in the POM file , it takes the > WAR filename as context-root in the application.xml > I would like to remove automatically the line. > what could be the strategy? > =>a tag added to the ear plugin config > > tutorials > JBPortlet1-war > > > =>a way to spe
[jira] Created: (CONTINUUM-720) Build summary page doesn't work correctly when navigated to using the link in the Email
Build summary page doesn't work correctly when navigated to using the link in
the Email
---
Key: CONTINUUM-720
URL: http://jira.codehaus.org/browse/CONTINUUM-720
Project: Continuum
Type: Bug
Components: Mail Notifier
Versions: 1.0.3
Environment: Don't think it's relevant, but WinXP, Java 1.4.2
Reporter: James Shute
Priority: Minor
If you navigate to the build summary page via the link in the email, e.g.
http://lofidw83722:8085/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/7/buildId/39
Then the page displays ok, but the Download As Text link on that page doesn't
work - it hasn't resolved the variables, so tries to link to
http://lofidw83722:8085/continuum/servlet/browse?file=$requestUtil.getParameter('id')/${requestUtil.getParameter('buildId')}.log.txt
If you navigate to the build summary via the web interface Project -> Builds
then the form of link that uses:
http://lofidw83722:8085/continuum/servlet/continuum/target/ProjectBuild.vm?view=ProjectBuild&buildId=39&id=7
works just fine.
--
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: (CONTINUUM-721) JDO Deadlock stack whilst removing a POM
JDO Deadlock stack whilst removing a POM
Key: CONTINUUM-721
URL: http://jira.codehaus.org/browse/CONTINUUM-721
Project: Continuum
Type: Bug
Versions: 1.0.3
Environment: linux amd64
Reporter: Andy Brook
ognl.MethodFailedException: Method "removeProject" failed for object [EMAIL
PROTECTED] [javax.jdo.JDODataStoreException: Update request failed: UPDATE
PROJECT SET CHECKOUT_RESULT_SCMRESULT_ID_OID=? WHERE ID=?
NestedThrowables:
SQL Exception: A lock could not be obtained due to a deadlock, cycle of locks
and waiters is:
Lock : ROW, PROJECT, (3,17)
Waiting XID : {64696941, X} , SA, UPDATE PROJECT SET
CHECKOUT_RESULT_SCMRESULT_ID_OID=? WHERE ID=?
Granted XID : {64696933, X}
Lock : ROW, BUILDDEFINITION, (3,28)
Waiting XID : {64696933, X} , SA, INSERT INTO BUILDDEFINITION
(SCHEDULE_ID_OID,LATEST_BUILD_ID,MODEL_ENCODING,BUILD_FILE,GOALS,DEFAULT_FOR_PROJECT,PROFILE_ID_OID,ARGUMENTS,ID)
VALUES (?,?,?,?,?,?,?,?,?)
Granted XID : {64696941, X}
. The selected victim is XID : 64696941.]
at ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:796)
at ognl.ObjectMethodAccessor.callMethod(ObjectMethodAccessor.java:61)
at ognl.OgnlRuntime.callMethod(OgnlRuntime.java:819)
at ognl.ASTMethod.getValueBody(ASTMethod.java:75)
at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170)
at ognl.SimpleNode.getValue(SimpleNode.java:210)
at ognl.Ognl.getValue(Ognl.java:333)
at ognl.Ognl.getValue(Ognl.java:378)
at ognl.Ognl.getValue(Ognl.java:357)
at
org.codehaus.plexus.formica.action.DeleteEntity.uponSuccessfulValidation(DeleteEntity.java:57)
at
org.codehaus.plexus.formica.action.DeleteEntity.execute(DeleteEntity.java:47)
at
org.codehaus.plexus.summit.pipeline.valve.ActionValve.invoke(ActionValve.java:68)
at
org.codehaus.plexus.summit.pipeline.AbstractPipeline.invoke(AbstractPipeline.java:70)
at org.codehaus.plexus.summit.Summit.doGet(Summit.java:54)
at org.codehaus.plexus.summit.Summit.doPost(Summit.java:108)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:615)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1807)
at
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1757)
at org.mortbay.http.HttpServer.service(HttpServer.java:879)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:789)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:960)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:806)
at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:218)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:331)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:520)
/-- Encapsulated exception \
javax.jdo.JDODataStoreException: Update request failed: UPDATE PROJECT SET
CHECKOUT_RESULT_SCMRESULT_ID_OID=? WHERE ID=?
at
org.jpox.store.rdbms.request.UpdateRequest.execute(UpdateRequest.java:267)
at org.jpox.store.rdbms.table.ClassTable.update(ClassTable.java:2200)
at org.jpox.store.StoreManager.update(StoreManager.java:786)
at org.jpox.state.StateManagerImpl.flush(StateManagerImpl.java:4596)
at
org.jpox.AbstractPersistenceManager.flush(AbstractPersistenceManager.java:3167)
at
org.jpox.NonmanagedTransaction.getConnection(NonmanagedTransaction.java:235)
at
org.jpox.NonmanagedTransaction.getConnection(NonmanagedTransaction.java:204)
at
org.jpox.AbstractPersistenceManager.getConnection(AbstractPersistenceManager.java:370)
at
org.jpox.store.rdbms.scostore.InverseListStore.clear(InverseListStore.java:986)
at
org.jpox.store.mapping.CollectionMapping.preDelete(CollectionMapping.java:304)
at
org.jpox.store.mapping.CollectionMapping.deleteDependent(CollectionMapping.java:332)
at
org.jpox.store.rdbms.table.ClassTable.deleteDependent(ClassTable.java:2280)
at org.jpox.store.StoreManager.deleteDependent(StoreManager.java:838)
at
org.jpox.state.StateManagerImpl.deletePersistent(StateManagerImpl.java:4049)
at
org.jpox.AbstractPersistenceManager.internalDeletePersistent(AbstractPersistenceManager.java:1391)
at
org.jpox.AbstractPersistenceManager.deletePersistent(AbstractPersistenceManager.java:1402)
at
org.jpox.store.rdbms.table.ClassTable.deleteDependent(ClassTab
[jira] Closed: (DOXIA-62) Error Transferring File for doxia-sink-api
[ http://jira.codehaus.org/browse/DOXIA-62?page=all ] ol closed DOXIA-62: --- Resolution: Won't Fix Sorry... this is not a bug ... this is a problem with my configuration. Sorry for the inconvenience. > Error Transferring File for doxia-sink-api > -- > > Key: DOXIA-62 > URL: http://jira.codehaus.org/browse/DOXIA-62 > Project: doxia > Type: Bug > Components: Site Renderer > Versions: 1.0-alpha-8 > Reporter: ol > Priority: Critical > > > Trying to do a "mvn site", I receive this error : > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > Error transferring file > org.apache.maven.doxia:doxia-sink-api:jar:1.0-alpha-8 > ... > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:140) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:63) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:233) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:211) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:182) > at > org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1117) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:366) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > ... 16 more > Caused by: org.apache.maven.wagon.TransferFailedException: Error transferring > file > at > org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:99) > at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:68) > at > org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:369) > at > org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:282) > at > org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:244) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:124) > ... 23 more > Caused by: java.io.IOException: Server returned HTTP response code: 500 for > URL: > http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-sink-api/1.0-alpha-8/doxia-sink-api-1.0-alpha-8.jar > at > sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:791) > at > org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:85) > ... 28 more > [INFO] > > [INFO] Total time: 55 seconds > [INFO] Finished at: Wed Jun 07 08:43:32 CEST 2006 > [INFO] Final Memory: 10M/18M > [INFO] > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-78) Add an option for google adsense
[ http://jira.codehaus.org/browse/MSITE-78?page=comments#action_66790 ] Tim Pizey commented on MSITE-78: This would be really nice, it was the absence of this feature that made me do my own skin. > Add an option for google adsense > > > Key: MSITE-78 > URL: http://jira.codehaus.org/browse/MSITE-78 > Project: Maven 2.x Site Plugin > Type: New Feature > Reporter: Jason van Zyl > > > Would need to support the account id and channel id for adsense. We could > utilize the new custom element for the additional information. -- 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: (MSITE-146) Version not printing in strapline
Version not printing in strapline - Key: MSITE-146 URL: http://jira.codehaus.org/browse/MSITE-146 Project: Maven 2.x Site Plugin Type: Bug Versions: 2.0-beta-4 Environment: linux and XP Reporter: Tim Pizey The maven-site.vm has a missing #else, such that the publishDate macro fails to print the version. #if ( $version ) #if ( $version.position ) #set ( $versionPosition = $version.position ) #else #set ( $versionPosition = "left" ) #end #end could become: #if ( $version ) #if ( $version.position ) #set ( $versionPosition = $version.position ) #else #set ( $versionPosition = "left" ) #end #else #set ( $version = "unset version" ) #set ( $versionPosition = "left" ) #end which fixes for me. -- 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-36) class Foo is public, should be declared in a file named Foo.java
class Foo is public, should be declared in a file named Foo.java Key: MCOMPILER-36 URL: http://jira.codehaus.org/browse/MCOMPILER-36 Project: Maven 2.x Compiler Plugin Type: Bug Versions: 2.0.1 Reporter: Per Olesen Priority: Minor When adding a depency to a jar which contains source code like this: com.nordija nordija-midtier snapshot sources test where I'm using the "classifier", the "compiler:testCompile" goal fails with the error: Failure executing javac, but could not parse the error: /home/tomcat/.m2/repository/com/nordija/nordija-midtier/snapshot/nordija-midtier-snapshot-sources.jar(com/nordija/midtier/util/NestingException.java):42: class NestingException is public, should be declared in a file named NestingException.java (source unavailable) 1 error Now, my first thought is of course that the jar is corrupt or packaged wrongly or something like that. But it seems to be okay, and my IDEA can browse it and does not show error-marks for the source file in question. And, the same dependency is used in another module in the same build, where it is no problem!!! I solved the problem by going back to v2.0 of the compiler plugin, where everything works. -- 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: (MSITE-147) Date format defaults to US
Date format defaults to US --- Key: MSITE-147 URL: http://jira.codehaus.org/browse/MSITE-147 Project: Maven 2.x Site Plugin Type: Improvement Versions: 2.0-beta-4, 2.0-beta-5 Environment: All Reporter: Tim Pizey Priority: Trivial Date format in maven-site.vm defaults to US format, not international, suggest dd-MMM-yy -- 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-2347) MavenExecutionRequest.getBaseDirectory() should be propagated to the ${basedir} expression
MavenExecutionRequest.getBaseDirectory() should be propagated to the ${basedir}
expression
--
Key: MNG-2347
URL: http://jira.codehaus.org/browse/MNG-2347
Project: Maven 2
Type: Bug
Components: General
Versions: 2.1
Environment: Maven 2.1-SNAPSHOT
Reporter: Ovidio Mallo
When executing a goal given by a MavenExecutionRequest (e.g. on the
MavenEmbedder) which has no POM file set (e.g. archetype:create), the
MavenExecutionRequest.getBaseDirectory() is not propagated to the expression
${basedir} for the plugins to be used.
Currently, the ${basedir} is set to the directory where the POM file resides,
if any is specified. Otherwise, it is simply set to the current working
directory. I guess that when no POM file is given, ${basedir} should be set to
the base directory set on the MavenExecutionRequest.
--
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: (CONTINUUM-722) Project should be built again if svn command fails
Project should be built again if svn command fails -- Key: CONTINUUM-722 URL: http://jira.codehaus.org/browse/CONTINUUM-722 Project: Continuum Type: Wish Components: Core system Versions: 1.0.3 Reporter: Laszlo Hornyak Kocka If the subversion server goes down, continuum sends a build error message, which is good, but it wont try to build it again after the subversion server goes online again, so one needs to rebuild the failed projects manualy. -- 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-2347) MavenExecutionRequest.getBaseDirectory() should be propagated to the ${basedir} expression
[ http://jira.codehaus.org/browse/MNG-2347?page=all ]
Ovidio Mallo updated MNG-2347:
--
Attachment: MNG-2347-maven-core.patch
> MavenExecutionRequest.getBaseDirectory() should be propagated to the
> ${basedir} expression
> --
>
> Key: MNG-2347
> URL: http://jira.codehaus.org/browse/MNG-2347
> Project: Maven 2
> Type: Bug
> Components: General
> Versions: 2.1
> Environment: Maven 2.1-SNAPSHOT
> Reporter: Ovidio Mallo
> Attachments: MNG-2347-maven-core.patch
>
>
> When executing a goal given by a MavenExecutionRequest (e.g. on the
> MavenEmbedder) which has no POM file set (e.g. archetype:create), the
> MavenExecutionRequest.getBaseDirectory() is not propagated to the expression
> ${basedir} for the plugins to be used.
> Currently, the ${basedir} is set to the directory where the POM file resides,
> if any is specified. Otherwise, it is simply set to the current working
> directory. I guess that when no POM file is given, ${basedir} should be set
> to the base directory set on the MavenExecutionRequest.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (MSUREFIRE-129) argLine with -Xmx option has no effect
argLine with -Xmx option has no effect -- Key: MSUREFIRE-129 URL: http://jira.codehaus.org/browse/MSUREFIRE-129 Project: Maven 2.x Surefire Plugin Type: Bug Versions: 2.2 Reporter: Per Olesen Priority: Minor In v2.1.3 of surefire plugin, this worked fine: org.apache.maven.plugins maven-surefire-plugin pertest -Xmx1024M But after doing a "mvn -U" and getting a v2.2 of the plugin, my tests starts failing with OutOfMemoryException again. Doing a "mvn -X" shows me, that it actually has read the option: [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-surefire-plugin:2.2:test' --> [DEBUG] (f) argLine = -Xmx1024M But maybe it is not applying the argline? Forcing it to run with v2.1.3 makes everyting work again. -- 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-2347) MavenExecutionRequest.getBaseDirectory() should be propagated to the ${basedir} expression
[ http://jira.codehaus.org/browse/MNG-2347?page=comments#action_66795 ]
Hermod Opstvedt commented on MNG-2347:
--
Your patch worked great :).
Hermod
> MavenExecutionRequest.getBaseDirectory() should be propagated to the
> ${basedir} expression
> --
>
> Key: MNG-2347
> URL: http://jira.codehaus.org/browse/MNG-2347
> Project: Maven 2
> Type: Bug
> Components: General
> Versions: 2.1
> Environment: Maven 2.1-SNAPSHOT
> Reporter: Ovidio Mallo
> Attachments: MNG-2347-maven-core.patch
>
>
> When executing a goal given by a MavenExecutionRequest (e.g. on the
> MavenEmbedder) which has no POM file set (e.g. archetype:create), the
> MavenExecutionRequest.getBaseDirectory() is not propagated to the expression
> ${basedir} for the plugins to be used.
> Currently, the ${basedir} is set to the directory where the POM file resides,
> if any is specified. Otherwise, it is simply set to the current working
> directory. I guess that when no POM file is given, ${basedir} should be set
> to the base directory set on the MavenExecutionRequest.
--
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: (CONTINUUM-723) strange trouble on solaris
strange trouble on solaris --- Key: CONTINUUM-723 URL: http://jira.codehaus.org/browse/CONTINUUM-723 Project: Continuum Type: Bug Versions: 1.0.3 Environment: solaris Reporter: Olivier Lamy Priority: Critical Hi, I have a junit test with contains the following code : SimpleDateFormat simpleDateFormat = new SimpleDateFormat( "-MM-dd", Locale.FRANCE ); // harcoded date due to xmlunit comparaison Date timeStamp = simpleDateFormat.parse( "2001-05-28" ); return DateTools.setNoonHour( timeStamp ); FastDateFormat.getInstance( "-MM-dd'T'HH:mm:ss.SSSZZ" ).format(date); On windows+cygwin : 2001-05-28T12:00:00.000+02:00 On solaris with same user who start continuum exec junit with cli : 2001-05-28T12:00:00.000+02:00 The same junit with continuum says : 2001-05-28T12:00:00.000+00:00 Error says : Expected attribute value '2001-05-28T12:00:00.000+02:00' but was '2001-05-28T12:00:00.000+00:00' - comparing at /OTA_HotelAvailRS[1]/@TimeStamp to at /OTA_HotelAvailRS[1]/@TimeStamp I start continuum with $CONTINUUM_HOME/bin/plexus.sh > /dev/null & The .profile contains : ... LANG=en_US.ISO8859-15 export LANG ##opts maven MAVEN_OPTS="-Xmx512m -Xms512m -Dfile.encoding=ISO-8859-1" export MAVEN_OPTS ... I don't change anything on plexus.sh script. Any ideas ?? Thanks, -- Olivier -- 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: (CONTINUUM-723) strange trouble on solaris
[ http://jira.codehaus.org/browse/CONTINUUM-723?page=all ] Olivier Lamy updated CONTINUUM-723: --- Attachment: CONTINUUM-723.tar.gz > strange trouble on solaris > --- > > Key: CONTINUUM-723 > URL: http://jira.codehaus.org/browse/CONTINUUM-723 > Project: Continuum > Type: Bug > Versions: 1.0.3 > Environment: solaris > Reporter: Olivier Lamy > Priority: Critical > Attachments: CONTINUUM-723.tar.gz > > > Hi, > I have a junit test with contains the following code : > SimpleDateFormat simpleDateFormat = new SimpleDateFormat( "-MM-dd", > Locale.FRANCE ); > // harcoded date due to xmlunit comparaison > Date timeStamp = simpleDateFormat.parse( "2001-05-28" ); > return DateTools.setNoonHour( timeStamp ); > FastDateFormat.getInstance( "-MM-dd'T'HH:mm:ss.SSSZZ" > ).format(date); > On windows+cygwin : 2001-05-28T12:00:00.000+02:00 > On solaris with same user who start continuum exec junit with cli : > 2001-05-28T12:00:00.000+02:00 > The same junit with continuum says : 2001-05-28T12:00:00.000+00:00 > Error says : > Expected attribute value '2001-05-28T12:00:00.000+02:00' but was > '2001-05-28T12:00:00.000+00:00' - comparing at > /OTA_HotelAvailRS[1]/@TimeStamp to at /OTA_HotelAvailRS[1]/@TimeStamp > I start continuum with $CONTINUUM_HOME/bin/plexus.sh > /dev/null & > The .profile contains : > ... > LANG=en_US.ISO8859-15 > export LANG > ##opts maven > MAVEN_OPTS="-Xmx512m -Xms512m -Dfile.encoding=ISO-8859-1" > export MAVEN_OPTS > ... > I don't change anything on plexus.sh script. > Any ideas ?? > Thanks, > -- > Olivier -- 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: (MRM-94) report on duplicate jars in different parts of the repository
[ http://jira.codehaus.org/browse/MRM-94?page=comments#action_66803 ] Edwin Punzalan commented on MRM-94: --- Fix committed in SVN. I'm leaving the issue open for the remaining todo's inside the new Reporter class > report on duplicate jars in different parts of the repository > - > > Key: MRM-94 > URL: http://jira.codehaus.org/browse/MRM-94 > Project: Maven Repository Manager > Type: Improvement > Components: reporting > Reporter: Brett Porter > Assignee: Edwin Punzalan > > Original Estimate: 4 hours > Remaining: 4 hours > > maybe this should be a pre-condition to adding. I want to check that nobody > adds a known JAR under their own group ID. > btw, I'm not sure how the indexing will cope with this in terms of checksums > if it is allowed to be added twice. > Might also try to detect some other similarities when the jars don't match > exactly but are out of place. -- 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: (CONTINUUM-625) Value of "Group" column depends on how you added the project
[ http://jira.codehaus.org/browse/CONTINUUM-625?page=comments#action_66806 ] Adrian commented on CONTINUUM-625: -- Yeah, this is working completely incorrectly for my projects. I get group names that are nothing to do with the project I have just added! > Value of "Group" column depends on how you added the project > > > Key: CONTINUUM-625 > URL: http://jira.codehaus.org/browse/CONTINUUM-625 > Project: Continuum > Type: Bug > Components: Web interface > Versions: 1.0.2 > Reporter: Matthew Beermann > Priority: Minor > Fix For: 1.1-alpha-1 > > > The text that appears in the "Group" column of the project listing seems, > counterintuitively, to depend on how exactly you added the project. > * If I add Maven 2 projects en masse through a master POM that has > , the name of that master POM is used. This may be related to an > (incorrect) assumption that if A has B as a , then B has A as a > , which is not true for me. > * If I add the projects one-by-one, the results appear to be somewhat random. > Looking over the list in my Continuum instance, I see projects that have > their own name as their Group, and some that are displaying the name of > sibling projects. > I'm not quite sure what /should/ be displayed, but whatever it is, it ought > to be consistent... -- 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: (CONTINUUM-724) Make the group name update itself when the build runs.
Make the group name update itself when the build runs. -- Key: CONTINUUM-724 URL: http://jira.codehaus.org/browse/CONTINUUM-724 Project: Continuum Type: Sub-task Versions: 1.0.3 Reporter: Adrian Fix For: 1.1-alpha-1 The group name never updates itself throughout the projects life, even if I change the name in the pom.xml -- 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: (MNGECLIPSE-133) Update Source Folders changes project JDK incorrectly when using Java 6.
Update Source Folders changes project JDK incorrectly when using Java 6. Key: MNGECLIPSE-133 URL: http://jira.codehaus.org/browse/MNGECLIPSE-133 Project: Maven 2.x Extension for Eclipse Type: Bug Components: Dependency Resolver Versions: 0.0.9 Environment: Windows XP SP2; JDK 1.6.0-beta2-b86; Eclipse 3.1.2; Reporter: Mark Soderquist Assigned to: Eugene Kuleshov Priority: Minor I believe this is something that Sun has done to you just recently with JDK 1.6 build 85 or 86 (I'm not sure which since I jumped from 84 to 86.) According to the javac documentation(http://download.java.net/jdk6/docs/technotes/tools/windows/javac.html#source) the -source values of 1.6 and 6 are not valid since no language changes occurred in Java 6. Changing the JDK in the Eclipse project based on the source value in the POM file may not work from now on. According to the documentation the target flag still allows the 1.6 value but running javac with -source 1.5 and -target 1.6 give an "invalid target release: 1.6" error. -- 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: (MNGECLIPSE-133) Update Source Folders changes project JDK incorrectly when using Java 6.
[ http://jira.codehaus.org/browse/MNGECLIPSE-133?page=all ] Eugene Kuleshov closed MNGECLIPSE-133: -- Resolution: Won't Fix How does "invalid target release: 1.6" error in javac justify for issue in this plugin? Besides -target 1.6 said allowed in the documentation link you reffered to, so it is sounds like a bug in javac. In any case plugin is configuring JDT options and more over takes anythithing that is declared in pom.xml. There are no plans to ensure correctness of the options. > Update Source Folders changes project JDK incorrectly when using Java 6. > > > Key: MNGECLIPSE-133 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-133 > Project: Maven 2.x Extension for Eclipse > Type: Bug > Components: Dependency Resolver > Versions: 0.0.9 > Environment: Windows XP SP2; JDK 1.6.0-beta2-b86; Eclipse 3.1.2; > Reporter: Mark Soderquist > Assignee: Eugene Kuleshov > Priority: Minor > > > I believe this is something that Sun has done to you just recently with JDK > 1.6 build 85 or 86 (I'm not sure which since I jumped from 84 to 86.) > According to the javac > documentation(http://download.java.net/jdk6/docs/technotes/tools/windows/javac.html#source) > the -source values of 1.6 and 6 are not valid since no language changes > occurred in Java 6. Changing the JDK in the Eclipse project based on the > source value in the POM file may not work from now on. According to the > documentation the target flag still allows the 1.6 value but running javac > with -source 1.5 and -target 1.6 give an "invalid target release: 1.6" error. -- 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-40) Duplicate code in portlet archetype
Duplicate code in portlet archetype --- Key: ARCHETYPE-40 URL: http://jira.codehaus.org/browse/ARCHETYPE-40 Project: Maven Archetype Type: Bug Components: Archetypes Reporter: Craig Doremus The maven portlet archetype (maven-archetype-portlet under maven-archetype-bundles) in source control contains duplicate code in all files except the root pom.xml. The code for a file appears to be copied into the file multiple times in every source file in each directory, rendering the archetype to be unusable. The fix is pretty evident when one looks at the source code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-908) Intellij 5.1 redistribution jars
[ http://jira.codehaus.org/browse/MAVENUPLOAD-908?page=comments#action_66815 ] Jerome Lacoste commented on MAVENUPLOAD-908: Out of curiosity, is there something blocking this issue? Should I ask jetbrains to 'bless' this issue? > Intellij 5.1 redistribution jars > > > Key: MAVENUPLOAD-908 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-908 > Project: maven-upload-requests > Type: Task > Reporter: Jerome Lacoste > Attachments: annotations-5.1-bundle.jar, annotations-5.1-bundle.jar, > annotations-5.1-bundle.jar, forms_rt-5.1-bundle.jar, forms_rt-5.1-bundle.jar, > forms_rt-5.1-bundle.jar, javac2-5.1-bundle.jar, javac2-5.1-bundle.jar, > javac2-5.1-bundle.jar > > > Intellij 5.0 jars are already distributed on ibiblio: > http://www.ibiblio.org/maven2/com/intellij/ > These jars do not include the javac2 ant tasks which is required for the idea > ui designer plugin (mojo sandbox) > Notes: I asked jetbrains and they don't have a public URL where to fetch the > jars from. So I took them from my local IDEA install. > I've made the poms so that I could compile the distributed sources. So > compared to the poms for 5.0, they also contain the dependencies. > [EMAIL PROTECTED]> md5sum ~/local/lib/idea/idea/redist/* > dcf471d13e032fdc7fb6872c12a01b06 > /home/jerome/local/lib/idea/idea/redist/annotations.jar > e457e70bc383322c0e297880e6be5ebc > /home/jerome/local/lib/idea/idea/redist/forms_rt.jar > ab8f1d2c49347f65a6ca26c54cb9b83e > /home/jerome/local/lib/idea/idea/redist/javac2.jar > [EMAIL PROTECTED]> md5sum ~/local/lib/idea/idea/redist/src/* > 251d1939107e2ce2bb98055b40addd8d > /home/jerome/local/lib/idea/idea/redist/src/src_annotations.zip > 325987e7cd85c455095ff2b5568ca4f7 > /home/jerome/local/lib/idea/idea/redist/src/src_forms_rt.zip > 08403362ff77b9e79af7178d7dd9cf01 > /home/jerome/local/lib/idea/idea/redist/src/src_javac2.zip > Note that javac2 and forms_rt are very similar in content. But that's how > Jetbrains distribute them. > One can get IDEA from http://www.jetbrains.com/idea/download -- 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-45) add config prop to specify webapp classes should be zipped and placed into WEB-INF/lib/xxx.jar instead of placed in WEB-INF/classes/
[ http://jira.codehaus.org/browse/MWAR-45?page=comments#action_66816 ] David Jencks commented on MWAR-45: -- I think adding this capability is a very good idea. IIUC the only argument against it is that it is possible to get the same effect by putting the classes into a separate project. I think this ignores the different effects and affect of having 2 projects: 1. Having 2 projects forces you to maintain what you are likely to be thinking of as one project in two places: e.g. even without jsps, the web.xml is going to be far away in the file system and IDE from the classes it is the descriptor for. I think breaking the way people think about their project in this way is inadvisable. 2. If you have jsps, you cannot precompile them and include them in the project classes jar without moving them into the classes project. What should be a packaging option requires major svn changes to your project. 3. With 2 projects you are forced to publish the classes jar. You may not want to pollute your repo with this artifact that you may regard as unnecessary. Also, you are apt to want to name both projects with the same name. 4. If you want 2 profiles, one to pack classes into a jar and the other to leave them in WEB-INF/classes, you are forced to unpack the jar if the jar is from a separate project. This is going to be a bit slower than not creating the jar in the first place. I'm sure there are more, this is just what came to mind during a moments consideration. war files are a pretty strange and perhaps inadvisable construction, but I think it is better for maven to try to adapt to what they are and how they are used rather than trying to force everyone to essentially use something else. > add config prop to specify webapp classes should be zipped and placed into > WEB-INF/lib/xxx.jar instead of placed in WEB-INF/classes/ > - > > Key: MWAR-45 > URL: http://jira.codehaus.org/browse/MWAR-45 > Project: Maven 2.x War Plugin > Type: New Feature > Versions: 2.0 > Reporter: Ian Springer > Attachments: mwar-45.patch > > > I think this is a common enough practice that there should be an option > provided for 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: (WAGONHTTP-8) wagon-http does not MKCOL for missing parent resources during deploy
[ http://jira.codehaus.org/browse/WAGONHTTP-8?page=comments#action_66817 ]
darren hartford commented on WAGONHTTP-8:
-
This is where someone else needs to speak up - can the http PUT method be used
to create directory/collections? Or can POST support something like that?
If not, required to call a WebDAV method MKCOL. If that is the case, you can
use this snippet to get things moving forward. All it does is make a
MkColMethod instead of the PutMethod for use with httpclient.
/* apache licensed, distribute at will
@author dhartford
*/
String[] parts = resourceName.split("/");
for (int i = 0; i < (parts.length - 1); i++) {
url = url + "/" + parts[i];
System.out.println(url);
EntityEnclosingMethod mkcol = new
EntityEnclosingMethod(url){
public String getName() {
// TODO Auto-generated method stub
return "MKCOL";
}
};
try {
client.executeMethod(mkcol);
} catch (HttpException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
> wagon-http does not MKCOL for missing parent resources during deploy
>
>
> Key: WAGONHTTP-8
> URL: http://jira.codehaus.org/browse/WAGONHTTP-8
> Project: wagon-http
> Type: Bug
> Versions: 1.0-alpha-6
> Environment: Linux/x86_64, FC4, jdk 1.5.0_06-b05, mvn 2.0.2, against
> Apache/2.0.54 (Fedora) DAV/2
> Reporter: Matthew Daniel
> Priority: Blocker
>
>
> Please see MNG-1580 and
> When trying to deploy using wagon-http, it does not understand the concept of
> parent directories and just issues a blind PUT with the resource URI. Further
> to the user's confusion, it does not report a helpful message but "Access
> denided" which is 100% not true.
> {quote}
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying
> artifactat
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
> 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 deploying
> artifact
> at
> org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:160)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531)
> ... 16 more
> Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException:
> Error deploying artifact: Authorization failed: Access denided to:
> http://servername/path/to/a/non-existant/1.5-SNAPSHOT/artifactid-1.5-20060209.202937-1.jar
> at
> org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:91)
> at
> org.apache.maven.plugin.dep
[jira] Commented: (CONTINUUM-665) exceptions during startup and shutdown
[ http://jira.codehaus.org/browse/CONTINUUM-665?page=comments#action_66818 ] Mathias Brökelmann commented on CONTINUUM-665: -- I get these exeptions too. I did some research and found in a derby.log the following entry: 2006-06-07 15:54:02.079 GMT Thread[main,5,main] Wrote class org.apache.derby.exe.ace8afc026x010bxaf33x28fcx006b6 to file ace8afc026x010bxaf33x28fcx006b6.class. Please provide support with the file and the following exception information: java.lang.VerifyError: verification failed at PC 2007 in org.apache.derby.exe.ace8afc026x010bxaf33x28fcx006b6:e23(()Ljava.lang.Object;): incompatible type on stack I will attach the generated file to this issue. > exceptions during startup and shutdown > -- > > Key: CONTINUUM-665 > URL: http://jira.codehaus.org/browse/CONTINUUM-665 > Project: Continuum > Type: Bug > Versions: 1.0.3 > Environment: cocoon.zones.apache.org > Reporter: Jorg Heymans > > > during first startup of a freshly unpacked continuum i get following > exception : > 2006-04-26 19:08:32,426 [main] WARN RDBMS - Error > initialising derby schema : Schema 'SA' does not exist > ERROR 42Y07: Schema 'SA' does not exist > at org.apache.derby.iapi.error.StandardException.newException(Unknown > Source) > at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getSchemaDescriptor(Unknown > Source) > at > org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(Unknown > Source) > at > org.apache.derby.impl.sql.compile.DDLStatementNode.getSchemaDescriptor(Unknown > Source) > at org.apache.derby.impl.sql.compile.DropAliasNode.bind(Unknown > Source) > at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown > Source) > at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source) > at > org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) > at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) > at > org.jpox.store.rdbms.adapter.CloudscapeAdapter.initialiseDatastore(CloudscapeAdapter.java:115) > at > org.jpox.store.rdbms.RDBMSManager.initialiseSchema(RDBMSManager.java:453) > at org.jpox.store.rdbms.RDBMSManager.(RDBMSManager.java:242) > at > org.jpox.store.rdbms.RDBMSManagerFactory.getStoreManager(RDBMSManagerFactory.java:59) > at > org.jpox.AbstractPersistenceManager.(AbstractPersistenceManager.java:222) > at > org.jpox.PersistenceManagerImpl.(PersistenceManagerImpl.java:34) > at > org.jpox.PersistenceManagerFactoryImpl.getPersistenceManager(PersistenceManagerFactoryImpl.java:916) > at > org.jpox.PersistenceManagerFactoryImpl.getPersistenceManager(PersistenceManagerFactoryImpl.java:891) > at > org.apache.maven.continuum.store.JdoContinuumStore.getPersistenceManager(JdoContinuumStore.java:1295) > at > org.apache.maven.continuum.store.JdoContinuumStore.getAllObjectsDetached(JdoContinuumStore.java:984) > at > org.apache.maven.continuum.store.JdoContinuumStore.getAllProjectsByNameWithBuildDetails(JdoContinuumStore.java:623) > at > org.apache.maven.continuum.DefaultContinuum.initialize(DefaultContinuum.java:1927) > at > org.codehaus.plexus.personality.plexus.lifecycle.phase.InitializePhase.execute(InitializePhase.java:16) > at > org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:101) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:105) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:95) > at > org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:92) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) > at > org.codehaus.plexus.DefaultPlexusContainer.loadComponentsOnStart(DefaultPlexusContainer.java:894) > at > org.codehaus.plexus.DefaultPlexusContainer.start(DefaultPlexusContainer.java:781) > at > org.codehaus.plexus.application.deploy.DefaultApplicationDeployer.deployApplicationDirectory(DefaultApplicationDeployer.java:366) > at > org.codehaus.plexus.application.deploy.DefaultApplicationDeployer.deployJar(DefaultApplicationDeployer.java:212) > at > org.codehaus.plexus.application.deploy.DefaultApplicationDeployer.deploy(DefaultApplicationDeployer.java:136) > at > org.codehaus.plexus.application.deploy.DefaultApplicationDeployer.deploy(DefaultApplicationDeploy
[jira] Updated: (CONTINUUM-665) exceptions during startup and shutdown
[ http://jira.codehaus.org/browse/CONTINUUM-665?page=all ] Mathias Brökelmann updated CONTINUUM-665: - Attachment: ace8afc026x010bxaf33x28fcx006b6.class > exceptions during startup and shutdown > -- > > Key: CONTINUUM-665 > URL: http://jira.codehaus.org/browse/CONTINUUM-665 > Project: Continuum > Type: Bug > Versions: 1.0.3 > Environment: cocoon.zones.apache.org > Reporter: Jorg Heymans > Attachments: ace8afc026x010bxaf33x28fcx006b6.class > > > during first startup of a freshly unpacked continuum i get following > exception : > 2006-04-26 19:08:32,426 [main] WARN RDBMS - Error > initialising derby schema : Schema 'SA' does not exist > ERROR 42Y07: Schema 'SA' does not exist > at org.apache.derby.iapi.error.StandardException.newException(Unknown > Source) > at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getSchemaDescriptor(Unknown > Source) > at > org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(Unknown > Source) > at > org.apache.derby.impl.sql.compile.DDLStatementNode.getSchemaDescriptor(Unknown > Source) > at org.apache.derby.impl.sql.compile.DropAliasNode.bind(Unknown > Source) > at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown > Source) > at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source) > at > org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) > at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) > at > org.jpox.store.rdbms.adapter.CloudscapeAdapter.initialiseDatastore(CloudscapeAdapter.java:115) > at > org.jpox.store.rdbms.RDBMSManager.initialiseSchema(RDBMSManager.java:453) > at org.jpox.store.rdbms.RDBMSManager.(RDBMSManager.java:242) > at > org.jpox.store.rdbms.RDBMSManagerFactory.getStoreManager(RDBMSManagerFactory.java:59) > at > org.jpox.AbstractPersistenceManager.(AbstractPersistenceManager.java:222) > at > org.jpox.PersistenceManagerImpl.(PersistenceManagerImpl.java:34) > at > org.jpox.PersistenceManagerFactoryImpl.getPersistenceManager(PersistenceManagerFactoryImpl.java:916) > at > org.jpox.PersistenceManagerFactoryImpl.getPersistenceManager(PersistenceManagerFactoryImpl.java:891) > at > org.apache.maven.continuum.store.JdoContinuumStore.getPersistenceManager(JdoContinuumStore.java:1295) > at > org.apache.maven.continuum.store.JdoContinuumStore.getAllObjectsDetached(JdoContinuumStore.java:984) > at > org.apache.maven.continuum.store.JdoContinuumStore.getAllProjectsByNameWithBuildDetails(JdoContinuumStore.java:623) > at > org.apache.maven.continuum.DefaultContinuum.initialize(DefaultContinuum.java:1927) > at > org.codehaus.plexus.personality.plexus.lifecycle.phase.InitializePhase.execute(InitializePhase.java:16) > at > org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:101) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:105) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:95) > at > org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:92) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) > at > org.codehaus.plexus.DefaultPlexusContainer.loadComponentsOnStart(DefaultPlexusContainer.java:894) > at > org.codehaus.plexus.DefaultPlexusContainer.start(DefaultPlexusContainer.java:781) > at > org.codehaus.plexus.application.deploy.DefaultApplicationDeployer.deployApplicationDirectory(DefaultApplicationDeployer.java:366) > at > org.codehaus.plexus.application.deploy.DefaultApplicationDeployer.deployJar(DefaultApplicationDeployer.java:212) > at > org.codehaus.plexus.application.deploy.DefaultApplicationDeployer.deploy(DefaultApplicationDeployer.java:136) > at > org.codehaus.plexus.application.deploy.DefaultApplicationDeployer.deploy(DefaultApplicationDeployer.java:116) > at > org.codehaus.plexus.application.DefaultApplicationServer$2.onJarDiscovered(DefaultApplicationServer.java:117) > at > org.codehaus.plexus.application.supervisor.DefaultSupervisor.scanDirectory(DefaultSupervisor.java:89) > at > org.codehaus.plexus.application.supervisor.DefaultSupervisor.scan(DefaultSupervisor.java:68) > at > org.codehaus.plexus.application.DefaultApplicationServer.start(DefaultApplicationServer.java:146) >
[jira] Commented: (CONTINUUM-723) strange trouble on solaris
[ http://jira.codehaus.org/browse/CONTINUUM-723?page=comments#action_66821 ] Olivier Lamy commented on CONTINUUM-723: I have found a workaroud in setup in my tests. With forcing timeZone : TimeZone.setDefault( TimeZone.getTimeZone( "MET" ) ); But what I don't understand is why when you using same user same machine same jvm. log.debug( "TimeZone.getDefault().getID() : " + TimeZone.getDefault().getID() ); display different values with running test with maven in cli and running the same test in continuum ?? Thanks for light, -- Olivier > strange trouble on solaris > --- > > Key: CONTINUUM-723 > URL: http://jira.codehaus.org/browse/CONTINUUM-723 > Project: Continuum > Type: Bug > Versions: 1.0.3 > Environment: solaris > Reporter: Olivier Lamy > Priority: Critical > Attachments: CONTINUUM-723.tar.gz > > > Hi, > I have a junit test with contains the following code : > SimpleDateFormat simpleDateFormat = new SimpleDateFormat( "-MM-dd", > Locale.FRANCE ); > // harcoded date due to xmlunit comparaison > Date timeStamp = simpleDateFormat.parse( "2001-05-28" ); > return DateTools.setNoonHour( timeStamp ); > FastDateFormat.getInstance( "-MM-dd'T'HH:mm:ss.SSSZZ" > ).format(date); > On windows+cygwin : 2001-05-28T12:00:00.000+02:00 > On solaris with same user who start continuum exec junit with cli : > 2001-05-28T12:00:00.000+02:00 > The same junit with continuum says : 2001-05-28T12:00:00.000+00:00 > Error says : > Expected attribute value '2001-05-28T12:00:00.000+02:00' but was > '2001-05-28T12:00:00.000+00:00' - comparing at > /OTA_HotelAvailRS[1]/@TimeStamp to at /OTA_HotelAvailRS[1]/@TimeStamp > I start continuum with $CONTINUUM_HOME/bin/plexus.sh > /dev/null & > The .profile contains : > ... > LANG=en_US.ISO8859-15 > export LANG > ##opts maven > MAVEN_OPTS="-Xmx512m -Xms512m -Dfile.encoding=ISO-8859-1" > export MAVEN_OPTS > ... > I don't change anything on plexus.sh script. > Any ideas ?? > Thanks, > -- > Olivier -- 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: (MDEP-5) [dependency-maven-plugin] dependency:copy-dependencies should copy compile+runtime dependencies by default
[ http://jira.codehaus.org/browse/MDEP-5?page=comments#action_66822 ] Romain GUINOT commented on MDEP-5: -- I totally agree . In order to make this work , you have to force runtime dependencies to "compile" , which sucks . Because of that , you cannot have proper generated site reports . > [dependency-maven-plugin] dependency:copy-dependencies should copy > compile+runtime dependencies by default > -- > > Key: MDEP-5 > URL: http://jira.codehaus.org/browse/MDEP-5 > Project: Maven 2.x Dependency Plugin > Type: Improvement > Reporter: Stephen Duncan Jr > Assignee: Brian Fox > > > The default should be to copy the compile & runtime dependencies, so that all > runtime-required dependencies are copied. Currently only compile-scope > dependencies are copied. -- 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-2348) add a simple command line alias for -Dmaven.test.skip=true as I find myself typing it very very often
add a simple command line alias for -Dmaven.test.skip=true as I find myself typing it very very often - Key: MNG-2348 URL: http://jira.codehaus.org/browse/MNG-2348 Project: Maven 2 Type: Improvement Components: Command Line Versions: 2.0.4 Reporter: james strachan Could we have some simple alias on the command line to disable unit tests just like we have maven -o for offline. Don't much mind what it is - how about... -nt --no-testsDisables the junit tests in this build so to do a build without unit tests mvn -nt install -- 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] Resolved: (MPWAR-49) war:war-resources should add overwrite=true (or configurable) flag to ant:copy task
[ http://jira.codehaus.org/browse/MPWAR-49?page=all ]
Stephane Nicoll resolved MPWAR-49:
--
Resolution: Fixed
Added property {{maven.war.resources.overwrite}} to control is resources
overwrites the ones in the generated webapp directory.
Default to true.
> war:war-resources should add overwrite=true (or configurable) flag to
> ant:copy task
> ---
>
> Key: MPWAR-49
> URL: http://jira.codehaus.org/browse/MPWAR-49
> Project: maven-war-plugin
> Type: Improvement
> Versions: 1.6
> Reporter: Steven Dehandtschutter
> Assignee: Stephane Nicoll
> Fix For: 1.6.2
>
>
> The default behavior of ant:copy is to *not* overwrite files if an newer file
> exists. However, when war dependencies are included and merged (see
> MPWAR-41), this means that resources of this project might be overriden by
> resources from an included war file (which is counterintuitive: project
> resources should override all included files if they overlap)
> The line to change is
>overwrite="true">
>
--
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] Resolved: (MPWAR-43) Directory possibility for manifest Class-Path entries
[ http://jira.codehaus.org/browse/MPWAR-43?page=all ]
Stephane Nicoll resolved MPWAR-43:
--
Resolution: Fixed
Removed the line resetting the maven.war.classpath property to be consistent
with other plugins.
> Directory possibility for manifest Class-Path entries
> -
>
> Key: MPWAR-43
> URL: http://jira.codehaus.org/browse/MPWAR-43
> Project: maven-war-plugin
> Type: New Feature
> Reporter: Pavel Jetensky
> Assignee: Stephane Nicoll
> Fix For: 1.6.2
>
>
> Hi. I have a problem with generating of Classpath in manifest related to this
> bug and discussion.
> I need to use classpath starting with 'lib/' for each dependency in WAR
> manifest file preffixes (f.e. Class-Path: lib/CSU-DMS-0.1.jar).
> I have had similar problem with EJB, where I have solved it with preGoal:
>
>
>
> value="${maven.ejb.classpath}
> ${dep.getProperty('corpus.manifest.folder')}${dep.artifact}"/>
>
>
>
> , but for WAR it is not possible (because of cleaning the value to "" in
> version 1.6.1, jelly.xml, line 37):
> .
> Behaviour is in that different from ejb:plugin.
> There can see two ways that can help to solve this issue:
> --
> a) to remove reseting value of maven.war.classpath to "" (to achieve similar
> behaviour as in f.e. ejb plugin)
> b) to enable Dependency property (like war.manifest.classpath.dir) that would
> be applied before artifact name in manifest classpath entry (I would set it
> to /lib in my POM)
--
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-129) Release fails on EAR project with EJB module reference
Release fails on EAR project with EJB module reference
--
Key: MRELEASE-129
URL: http://jira.codehaus.org/browse/MRELEASE-129
Project: Maven 2.x Release Plugin
Type: Bug
Versions: 2.0-beta-4
Reporter: Mike Perham
Fix For: 2.0
{code:xml}
com.webify.fabric
fabric-pm-mdb
1.2.1
ejb
{code}
During release:prepare, it transforms the POMs to the release version (as
above) and then runs the full build. The EAR build fails because the EJB
artifact is not installed to the local repo so it can't package that dependent
module by pulling it from the local repo.
[INFO] Failed to resolve artifact.
Missing:
--
1) com.webify.fabric:fabric-pm-mdb:ejb:1.2.1
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=com.webify.fabric
-DartifactId=fabric-pm-mdb \
-Dversion=1.2.1 -Dpackaging=ejb -Dfile=/path/to/file
Path to dependency:
1) com.webify.fabric:fabric-tools-ear:ear:4.1.1
2) com.webify.fabric:fabric-pm-mdb:ejb:1.2.1
The workaround is to let it fail, run the build by hand to populate the local
repo and run the prepare goal again so it can find the binary.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (MSUREFIRE-130) Setting forkMode changes user.dir for multimodule projects
Setting forkMode changes user.dir for multimodule projects -- Key: MSUREFIRE-130 URL: http://jira.codehaus.org/browse/MSUREFIRE-130 Project: Maven 2.x Surefire Plugin Type: Bug Versions: 2.2 Reporter: Richard van der Hoff Priority: Minor The working directory of tests on a submodule in a multimodule project is different dependeng on whether forkMode is enabled or not. When forkMode==never, the working directory is that of the top-level module; otherwise, it is set to the directory of the submodule. I know this is defined behaviour - but it has been suggested that it is unintuitive. -- 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-2349) dependency management, report-plugins and deploy-site
dependency management, report-plugins and deploy-site - Key: MNG-2349 URL: http://jira.codehaus.org/browse/MNG-2349 Project: Maven 2 Type: Bug Versions: 2.0.4 Environment: jdk 1.4.2_11, windows 2000 Reporter: Thiago Gozzi Prado Attachments: myproject.zip When I run mvn -e clean site site-deploy for the root pom, maven throws a NullPointerException. If I remove the javadoc report plugin declaration, the site is deployed. Or if I keep the javadoc report plugin declaration, but remove the dependency management declaration, the site is deployed. This happens for some report plugins, not all. Checkstyle, for instance, works fine. myproject.zip contains the project structure and the project definition. -- 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: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_66828 ] Drew Farris commented on MNGECLIPSE-59: --- I've hacked together a solution that seems to work for now and only touches the Maven2Plugin class. I've generated the attached patch against version 111 of Maven2Plugin and attached it as mngeclipse-59-drew-hack.txt The drawback of this solution is that it builds a list of projects in the local workspace that could potentially be used to resolve dependencies once, the first time resolveClasspathEntries is called. Ideally, I'd somehow hook into workspace change events and rebuild the list as necessary, but I really don't know the Eclipse API that well. Furthermore, it only looks at the group id and an artifact id -- version is ignored completely for now. As I said, this is a hack -- it seems to solve the issue for me -- maybe this will be useful to someone else. > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Type: New Feature > Components: Dependency Resolver > Versions: 0.0.4 > Reporter: Leonardo Quijano Vincenzi > Assignee: Eugene Kuleshov > Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59 > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- 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: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=all ] Drew Farris updated MNGECLIPSE-59: -- Attachment: mngeclipse-59-drew-hack.txt > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Type: New Feature > Components: Dependency Resolver > Versions: 0.0.4 > Reporter: Leonardo Quijano Vincenzi > Assignee: Eugene Kuleshov > Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59, > mngeclipse-59-drew-hack.txt > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- 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: (MPWAR-58) War plugin generate incorrect manifest file
War plugin generate incorrect manifest file --- Key: MPWAR-58 URL: http://jira.codehaus.org/browse/MPWAR-58 Project: maven-war-plugin Type: Bug Versions: 1.6.1 Reporter: Stephane Nicoll Assigned to: Stephane Nicoll Fix For: 1.6.2 See MPJAR-36 for details as they are also applicable to the War plugin. -- 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] Resolved: (MPWAR-47) Manifest - Attributes Specification-Title, Specification... in wrong Section
[ http://jira.codehaus.org/browse/MPWAR-47?page=all ]
Stephane Nicoll resolved MPWAR-47:
--
Resolution: Duplicate
We will generate the section properly. See linked issue.
> Manifest - Attributes Specification-Title, Specification... in wrong Section
>
>
> Key: MPWAR-47
> URL: http://jira.codehaus.org/browse/MPWAR-47
> Project: maven-war-plugin
> Type: Bug
> Versions: 1.6
> Reporter: Sascha Groß
> Assignee: Stephane Nicoll
> Priority: Minor
> Fix For: 1.6.2
> Attachments: fixed.plugin.jelly
>
>
> The following Mainfest-Attributes
> Specification-Title, Specification-Version, Specification-Vendor,
> Implementation-Title, Implementation-Version, Implementation-Vendor
> are currently generated in a section/"Per-Entry Attributes" with name
> "${pom.package}".
> The attributes should be part of the "Main Attributes" in the manifest and
> not part of a section/"Per-Entry Attributes"
> see:
> http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Manifest%20Specification
> The bug is in the file "plugin.jelly", a version with the fix is attacted
> ("fixed.plugin.jelly").
--
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-8) wagon-http does not MKCOL for missing parent resources during deploy
[ http://jira.codehaus.org/browse/WAGONHTTP-8?page=comments#action_66836 ]
Matthew Daniel commented on WAGONHTTP-8:
{quote}
Confirm lack of MKCOL issue, tested on Fedora Core 5/Apache2.2 DAV w/ wagon
1.0-alpha-6.
{quote}
Oh, sorry, I saw "lack of issue" and thought you were confirming that I was
crazy. :-)
That code snippet (at least at a cursory glance) looks like it would do the
job, but it can't do that with an existing URI (at least according to section
8.3.1 of RFC 2518). There is one school of thought that says try to PUT the
artifact, and *check the damn response code*. If it needs a MKCOL, try the
whole URI and *check the damn response code* for 409 and the walk the URI like
you suggested. Oh, and while walking the URI, maybe the code should check the
response code from time to time.
That part about "access denided" really raises my blood pressure because it's
not just wrong, it's misleading.
> wagon-http does not MKCOL for missing parent resources during deploy
>
>
> Key: WAGONHTTP-8
> URL: http://jira.codehaus.org/browse/WAGONHTTP-8
> Project: wagon-http
> Type: Bug
> Versions: 1.0-alpha-6
> Environment: Linux/x86_64, FC4, jdk 1.5.0_06-b05, mvn 2.0.2, against
> Apache/2.0.54 (Fedora) DAV/2
> Reporter: Matthew Daniel
> Priority: Blocker
>
>
> Please see MNG-1580 and
> When trying to deploy using wagon-http, it does not understand the concept of
> parent directories and just issues a blind PUT with the resource URI. Further
> to the user's confusion, it does not report a helpful message but "Access
> denided" which is 100% not true.
> {quote}
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying
> artifactat
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
> 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 deploying
> artifact
> at
> org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:160)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531)
> ... 16 more
> Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException:
> Error deploying artifact: Authorization failed: Access denided to:
> http://servername/path/to/a/non-existant/1.5-SNAPSHOT/artifactid-1.5-20060209.202937-1.jar
> at
> org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:91)
> at
> org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:148)
> ... 18 more
> Caused by: org.apache.maven.wagon.TransferFailedException: Authorization
> failed: Access denided to:
> http://servername/path/to/a/non-existant/1.5-SNAPSHOT/artifactid-1.5-20060209.202937-1.jar
> at
> org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:215)
> at
> org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:109)
> at
> org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:77)
> ... 19 more
> Caused by: org.apache.maven.wagon.authorization.AuthorizationException:
> Access denided to:
> http://server
[jira] Updated: (MPWAR-58) War plugin generates incorrect manifest file
[ http://jira.codehaus.org/browse/MPWAR-58?page=all ] Stephane Nicoll updated MPWAR-58: - Summary: War plugin generates incorrect manifest file (was: War plugin generate incorrect manifest file) > War plugin generates incorrect manifest file > > > Key: MPWAR-58 > URL: http://jira.codehaus.org/browse/MPWAR-58 > Project: maven-war-plugin > Type: Bug > Versions: 1.6.1 > Reporter: Stephane Nicoll > Assignee: Stephane Nicoll > Fix For: 1.6.2 > > > See MPJAR-36 for details as they are also applicable to the War plugin. -- 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] Resolved: (MPWAR-58) War plugin generates incorrect manifest file
[ http://jira.codehaus.org/browse/MPWAR-58?page=all ] Stephane Nicoll resolved MPWAR-58: -- Resolution: Fixed Applied fix from the Jar plugin to make things consistent. > War plugin generates incorrect manifest file > > > Key: MPWAR-58 > URL: http://jira.codehaus.org/browse/MPWAR-58 > Project: maven-war-plugin > Type: Bug > Versions: 1.6.1 > Reporter: Stephane Nicoll > Assignee: Stephane Nicoll > Fix For: 1.6.2 > > > See MPJAR-36 for details as they are also applicable to the War plugin. -- 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-2350) tag is ignored for plugins in the section of the POM
tag is ignored for plugins in the section of the POM -- Key: MNG-2350 URL: http://jira.codehaus.org/browse/MNG-2350 Project: Maven 2 Type: Bug Components: Sites & Reporting Versions: 2.0.4 Environment: Windows XP Reporter: Gunther Popp A version defined for a plugin in the section of the POM is ignored. For example, I would expect that the following definition in a POM forces the usage of version 2.0-beta-4 of the site-plugin: ... org.apache.maven.plugins maven-site-plugin 2.0-beta-4 ... However, Maven always uses the newer version 2.0-beta-5: >mvn site -X + Error stacktraces are turned on. Maven version: 2.0.4 ... [INFO] artifact org.apache.maven.plugins:maven-site-plugin: checking for updates from central [DEBUG] maven-site-plugin: resolved to version 2.0-beta-5 from repository central [DEBUG] Trying repository central Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-beta-5/maven-site-plugin-2.0-beta-5.pom 2/2K 2K downloaded [DEBUG] Artifact resolved [DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins::1 for project: null:maven-site-plugin:maven-plugin:2.0-beta-5 from the repository. [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::1 for project: org.apache.maven.plugins:maven-plugins:pom:1 from the repository. [DEBUG] Retrieving parent-POM: org.apache:apache::1 for project: org.apache.maven:maven-parent:pom:1 from the repository. [DEBUG] Trying repository central Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-beta-5/maven-site-plugin-2.0-beta-5.jar 52K downloaded [DEBUG] Artifact resolved ... It doesn´t matter, if the plugin already exists in the local repostitory or not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (MPWAR-34) parameterise overwrite of web.xml in war:war-resources
[ http://jira.codehaus.org/browse/MPWAR-34?page=all ]
Stephane Nicoll resolved MPWAR-34:
--
Resolution: Duplicate
Duplicate and fixed in 1.6.2
> parameterise overwrite of web.xml in war:war-resources
> --
>
> Key: MPWAR-34
> URL: http://jira.codehaus.org/browse/MPWAR-34
> Project: maven-war-plugin
> Type: Improvement
> Versions: 1.0
> Reporter: Nathan Coast
> Priority: Minor
>
> Original Estimate: 5 minutes
> Remaining: 5 minutes
>
> We have a plugin that modifies the web.xml, as an optimisation we don't have
> to perform this modification on every build. However, the war:war-resources
> forces the copy of the web.xml file, so our plugin has to modify the web.xml
> every time.
>
>tofile="${webapp.build.webinf}/web.xml"
> overwrite="true" />
>
> how about parameterise? with default true.
>
>tofile="${webapp.build.webinf}/web.xml"
> overwrite="${war.web.xml.overwrite}" />
>
> I can make patches if needed. [EMAIL PROTECTED]
--
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: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_66840 ] Dimitry Voytenko commented on MNGECLIPSE-59: Drew, what is this fix for exactly? > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Type: New Feature > Components: Dependency Resolver > Versions: 0.0.4 > Reporter: Leonardo Quijano Vincenzi > Assignee: Eugene Kuleshov > Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59, > mngeclipse-59-drew-hack.txt > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- 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-2350) tag is ignored for plugins in the section of the POM
[ http://jira.codehaus.org/browse/MNG-2350?page=all ] Mike Perham closed MNG-2350: Resolution: Cannot Reproduce site is a build plugin. It runs the plugins in the reporting section but is not a report plugin itself. > tag is ignored for plugins in the section of the POM > -- > > Key: MNG-2350 > URL: http://jira.codehaus.org/browse/MNG-2350 > Project: Maven 2 > Type: Bug > Components: Sites & Reporting > Versions: 2.0.4 > Environment: Windows XP > Reporter: Gunther Popp > > > A version defined for a plugin in the section of the POM is > ignored. For example, I would expect that the following definition in a POM > forces the usage of version 2.0-beta-4 of the site-plugin: > > ... > > > > org.apache.maven.plugins > maven-site-plugin > 2.0-beta-4 > > ... > However, Maven always uses the newer version 2.0-beta-5: > >mvn site -X > + Error stacktraces are turned on. > Maven version: 2.0.4 > ... > [INFO] artifact org.apache.maven.plugins:maven-site-plugin: checking for > updates from central > [DEBUG] maven-site-plugin: resolved to version 2.0-beta-5 from repository > central > [DEBUG] Trying repository central > Downloading: > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-beta-5/maven-site-plugin-2.0-beta-5.pom > 2/2K > 2K downloaded > [DEBUG] Artifact resolved > [DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins::1 for > project: null:maven-site-plugin:maven-plugin:2.0-beta-5 from the repository. > [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::1 for project: > org.apache.maven.plugins:maven-plugins:pom:1 from the repository. > [DEBUG] Retrieving parent-POM: org.apache:apache::1 for project: > org.apache.maven:maven-parent:pom:1 from the repository. > [DEBUG] Trying repository central > Downloading: > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-beta-5/maven-site-plugin-2.0-beta-5.jar > 52K downloaded > [DEBUG] Artifact resolved > ... > It doesn´t matter, if the plugin already exists in the local repostitory or > not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGONHTTP-8) wagon-http does not MKCOL for missing parent resources during deploy
[ http://jira.codehaus.org/browse/WAGONHTTP-8?page=comments#action_66842 ]
darren hartford commented on WAGONHTTP-8:
-
I tried testing with PUT first while watching the response codes, but at least
with Apache 2.2, the PUT will only put file, not a directory (I plead ignorance
to the PUT method).
So when trying to walk:
/mygroupid/artifactid/version/actual-file
mygroupid is always PUT as a file, and can't seem to figure a way to force it
to a directory/collection structure. I swapped gears and using the
wagon-webdav directly now instead of messing with the http-wagon (I had some
issues earlier with figuring out HOW to use wagon-webdav, aka
dav:http://server/repo).
I think someone needs to identify if the wagon-http and wagon-httplightweight
should be designed for PUT, or are only get-style transports -- and then some
(even poor) documentation is definately needed to balance user-expectations
with code-functionality.
-D
> wagon-http does not MKCOL for missing parent resources during deploy
>
>
> Key: WAGONHTTP-8
> URL: http://jira.codehaus.org/browse/WAGONHTTP-8
> Project: wagon-http
> Type: Bug
> Versions: 1.0-alpha-6
> Environment: Linux/x86_64, FC4, jdk 1.5.0_06-b05, mvn 2.0.2, against
> Apache/2.0.54 (Fedora) DAV/2
> Reporter: Matthew Daniel
> Priority: Blocker
>
>
> Please see MNG-1580 and
> When trying to deploy using wagon-http, it does not understand the concept of
> parent directories and just issues a blind PUT with the resource URI. Further
> to the user's confusion, it does not report a helpful message but "Access
> denided" which is 100% not true.
> {quote}
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying
> artifactat
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
> 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 deploying
> artifact
> at
> org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:160)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531)
> ... 16 more
> Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException:
> Error deploying artifact: Authorization failed: Access denided to:
> http://servername/path/to/a/non-existant/1.5-SNAPSHOT/artifactid-1.5-20060209.202937-1.jar
> at
> org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:91)
> at
> org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:148)
> ... 18 more
> Caused by: org.apache.maven.wagon.TransferFailedException: Authorization
> failed: Access denided to:
> http://servername/path/to/a/non-existant/1.5-SNAPSHOT/artifactid-1.5-20060209.202937-1.jar
> at
> org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:215)
> at
> org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:109)
> at
> org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:77)
> ... 19 more
> Caused by: org.apache.maven.wagon.authorization.AuthorizationException:
> Access denided t
[jira] Created: (MASSEMBLY-113) ModuleSet does not support classifier
ModuleSet does not support classifier - Key: MASSEMBLY-113 URL: http://jira.codehaus.org/browse/MASSEMBLY-113 Project: Maven 2.x Assembly Plugin Type: Bug Versions: 2.1 Reporter: Matt Brozowski I am trying to define a toplevel assembly using the docs here: http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html I have two submodules that create a sub-assembly from dependencies and a war file. The sub-assembly is creating using assembly:attached bound to the 'package' phase. When trying to reference the sub-assembly using a moduleSet there is no way to specify the classifier for the subassembly. -- 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: (SUREFIRE-46) Proper escape of classpath entries esp. in windows
[ http://jira.codehaus.org/browse/SUREFIRE-46?page=comments#action_66843 ] Carlos Sanchez commented on SUREFIRE-46: What's your problem? It works for me mvn -X test Forking command line: java -classpath "C:\Documents and Settings\csanchez\.m2\repository\org\apache\maven\surefire\surefire-api\2.0\surefire-api-2.0.jar;C:\Documents and Settings\csanchez\.m2\repository\org\codehaus\plexus\plexus-utils\1.1\plexus-utils-1.1.jar;C:\Documents and Settings\csanchez\.m2\repository\org\apache\maven\surefire\surefire-booter\2.0\surefire-booter-2.0.jar" org.apache.maven.surefire.booter.SurefireBooter c:\DOCUME~1\csanchez\LOCALS~1\Temp\surefire7726tmp c:\DOCUME~1\csanchez\LOCALS~1\Temp\surefire7727tmp > Proper escape of classpath entries esp. in windows > -- > > Key: SUREFIRE-46 > URL: http://jira.codehaus.org/browse/SUREFIRE-46 > Project: surefire > Type: Bug > Versions: 2.0 > Environment: Windows > Reporter: Balaji Ravi > Attachments: surefire-booter.patch > > > When a classpath entry has a directory with spaces, surefire booter class > doesn't properly create the URL. i.e. it doesn't escape the url's added. > I have attached a patch that would fix this problem. -- 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-8) wagon-http does not MKCOL for missing parent resources during deploy
[ http://jira.codehaus.org/browse/WAGONHTTP-8?page=comments#action_66844 ]
Matthew Daniel commented on WAGONHTTP-8:
I encourage you (or whoever is working on the actual code) to read RFC 2518
(available from webdav.org). It's short and to the point, if one is already
familiar with HTTP/1.1.
There in an issue surrounding webdav-wagon being a 2nd-class citizen in M2 that
I filed as MNG-1580. It seems that I am the only person using DAV as my
transport mechanism, and thus, it gets pushed back every release. :-(
Thank you for looking into this.
> wagon-http does not MKCOL for missing parent resources during deploy
>
>
> Key: WAGONHTTP-8
> URL: http://jira.codehaus.org/browse/WAGONHTTP-8
> Project: wagon-http
> Type: Bug
> Versions: 1.0-alpha-6
> Environment: Linux/x86_64, FC4, jdk 1.5.0_06-b05, mvn 2.0.2, against
> Apache/2.0.54 (Fedora) DAV/2
> Reporter: Matthew Daniel
> Priority: Blocker
>
>
> Please see MNG-1580 and
> When trying to deploy using wagon-http, it does not understand the concept of
> parent directories and just issues a blind PUT with the resource URI. Further
> to the user's confusion, it does not report a helpful message but "Access
> denided" which is 100% not true.
> {quote}
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying
> artifactat
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
> 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 deploying
> artifact
> at
> org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:160)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531)
> ... 16 more
> Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException:
> Error deploying artifact: Authorization failed: Access denided to:
> http://servername/path/to/a/non-existant/1.5-SNAPSHOT/artifactid-1.5-20060209.202937-1.jar
> at
> org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:91)
> at
> org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:148)
> ... 18 more
> Caused by: org.apache.maven.wagon.TransferFailedException: Authorization
> failed: Access denided to:
> http://servername/path/to/a/non-existant/1.5-SNAPSHOT/artifactid-1.5-20060209.202937-1.jar
> at
> org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:215)
> at
> org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:109)
> at
> org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:77)
> ... 19 more
> Caused by: org.apache.maven.wagon.authorization.AuthorizationException:
> Access denided to:
> http://servername/path/to/a/non-existant/1.5-SNAPSHOT/artifactid-1.5-20060209.202937-1.jar
> at
> org.apache.maven.wagon.providers.http.HttpWagon.put(HttpWagon.java:202)
> at
> org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:180)
> ... 21 more
> {quote}
--
This message is automatically generated by JIRA.
-
If yo
[jira] Created: (MNG-2351) mvn -X doesn't enable debugging
mvn -X doesn't enable debugging
---
Key: MNG-2351
URL: http://jira.codehaus.org/browse/MNG-2351
Project: Maven 2
Type: Bug
Components: Embedding
Versions: 2.1
Reporter: Jerome Lacoste
mvn -X doesn't enable debugging
If I add the following code to DefaultMaven.execute(...)
public void execute( MavenExecutionRequest request )
throws MavenExecutionException
[...]
loggerManager.setThreshold( request.getLoggingLevel() );
// ADDED
loggerManager.getLoggerForComponent( Maven.ROLE ).info( "XXX logging
level " + request.getLoggingLevel());
loggerManager.getLoggerForComponent( Maven.ROLE ).debug( "XXX logging
level " + request.getLoggingLevel());
System.err.println("XXX logging level " + request.getLoggingLevel());
System.err.println("XXX show errors " + request.isShowErrors());
System.err.println("XXX logger threshold " +
loggerManager.getLoggerForComponent( Maven.ROLE ).getThreshold());
// end of ADDED
I get:
[INFO] XXX logging level 0
XXX logging level 0
XXX show errors true
XXX logger threshold 1
Looks like something is wrong with regard to thresholds in the Maven.ROLE
component.
--
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: (SUREFIRE-46) Proper escape of classpath entries esp. in windows
[ http://jira.codehaus.org/browse/SUREFIRE-46?page=comments#action_66845 ] Balaji Ravi commented on SUREFIRE-46: - The problem is when the RMI class loader is actually using the url's obtained from the surefire classloader. The surefire booter creates the url using the file.toURL() call and it doesn't escape the url's which contains spaces... > Proper escape of classpath entries esp. in windows > -- > > Key: SUREFIRE-46 > URL: http://jira.codehaus.org/browse/SUREFIRE-46 > Project: surefire > Type: Bug > Versions: 2.0 > Environment: Windows > Reporter: Balaji Ravi > Attachments: surefire-booter.patch > > > When a classpath entry has a directory with spaces, surefire booter class > doesn't properly create the URL. i.e. it doesn't escape the url's added. > I have attached a patch that would fix this problem. -- 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: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_66846 ] Drew Farris commented on MNGECLIPSE-59: --- Dimitry, It's an attempt to get the eclipse plugin to resolve artifact dependencies by looking at workspace projects instead of looking for artifacts (jars) in the local repository. It does this by cataloging the projects in the local workspace that are maven projects. In the resolveClasspathEntries() method, it checks these for group and artifact id's that match the artifact that is being searched for. If found, it adds a project reference to the Maven2 Dependencies library instead of a jar reference. > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Type: New Feature > Components: Dependency Resolver > Versions: 0.0.4 > Reporter: Leonardo Quijano Vincenzi > Assignee: Eugene Kuleshov > Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59, > mngeclipse-59-drew-hack.txt > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- 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: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_66847 ] Dimitry Voytenko commented on MNGECLIPSE-59: I believe this is what Mark J. Sinke's original patch does and it does it in a rather elegant way. I had it running on our workstation for quite a while now and works well. As far as I understand Kenney Westerhof (see above) adjusted the patch for the current trunk. Does your patch do the same? > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Type: New Feature > Components: Dependency Resolver > Versions: 0.0.4 > Reporter: Leonardo Quijano Vincenzi > Assignee: Eugene Kuleshov > Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59, > mngeclipse-59-drew-hack.txt > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- 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: (SUREFIRE-46) Proper escape of classpath entries esp. in windows
[ http://jira.codehaus.org/browse/SUREFIRE-46?page=comments#action_66848 ] Daniel Kulp commented on SUREFIRE-46: - This is a critical issue for the Apache Yoko project. There is an associated bug logged there: http://issues.apache.org/jira/browse/YOKO-48 > Proper escape of classpath entries esp. in windows > -- > > Key: SUREFIRE-46 > URL: http://jira.codehaus.org/browse/SUREFIRE-46 > Project: surefire > Type: Bug > Versions: 2.0 > Environment: Windows > Reporter: Balaji Ravi > Attachments: surefire-booter.patch > > > When a classpath entry has a directory with spaces, surefire booter class > doesn't properly create the URL. i.e. it doesn't escape the url's added. > I have attached a patch that would fix this problem. -- 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-2351) mvn -X doesn't enable debugging
[ http://jira.codehaus.org/browse/MNG-2351?page=comments#action_66849 ]
Jerome Lacoste commented on MNG-2351:
-
Given that LoggerManager API says that
/**
* Sets the threshold for all new loggers. It will NOT affect the existing
loggers.
* This is usually only set once while the logger manager is configured.
* @param threshold The new threshold.
*/
void setThreshold( int threshold );
I thought that the Maven.ROLE logger must have already existed. I tried to
force its theshold to DEBUG using LoggerManager.setThreshold(Maven.ROLE, 0) but
that didn't work.
> mvn -X doesn't enable debugging
> ---
>
> Key: MNG-2351
> URL: http://jira.codehaus.org/browse/MNG-2351
> Project: Maven 2
> Type: Bug
> Components: Embedding
> Versions: 2.1
> Reporter: Jerome Lacoste
>
>
> mvn -X doesn't enable debugging
> If I add the following code to DefaultMaven.execute(...)
> public void execute( MavenExecutionRequest request )
> throws MavenExecutionException
> [...]
>
> loggerManager.setThreshold( request.getLoggingLevel() );
> // ADDED
> loggerManager.getLoggerForComponent( Maven.ROLE ).info( "XXX logging
> level " + request.getLoggingLevel());
> loggerManager.getLoggerForComponent( Maven.ROLE ).debug( "XXX logging
> level " + request.getLoggingLevel());
> System.err.println("XXX logging level " + request.getLoggingLevel());
> System.err.println("XXX show errors " + request.isShowErrors());
> System.err.println("XXX logger threshold " +
> loggerManager.getLoggerForComponent( Maven.ROLE ).getThreshold());
> // end of ADDED
> I get:
> [INFO] XXX logging level 0
> XXX logging level 0
> XXX show errors true
> XXX logger threshold 1
> Looks like something is wrong with regard to thresholds in the Maven.ROLE
> component.
--
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: (MSITE-147) Date format defaults to US
[ http://jira.codehaus.org/browse/MSITE-147?page=comments#action_66851 ] Dennis Lundberg commented on MSITE-147: --- If we want to change the default format of the date we should go with the ISO 8601 format: -MM-dd This is also the recommended practice by the W3C: http://www.w3.org/QA/Tips/iso-date > Date format defaults to US > --- > > Key: MSITE-147 > URL: http://jira.codehaus.org/browse/MSITE-147 > Project: Maven 2.x Site Plugin > Type: Improvement > Versions: 2.0-beta-4, 2.0-beta-5 > Environment: All > Reporter: Tim Pizey > Priority: Trivial > > > Date format in maven-site.vm defaults to US format, not international, > suggest dd-MMM-yy -- 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-2351) mvn -X doesn't enable debugging
[ http://jira.codehaus.org/browse/MNG-2351?page=comments#action_66852 ]
Jerome Lacoste commented on MNG-2351:
-
* I also tried using setThreshold(Maven.ROLE, "default", 0) instead, but that
doesn't work better. The first version (without "default") manages to get my
test line
loggerManager.getLoggerForComponent( Maven.ROLE ).debug( "XXX logging level
" + request.getLoggingLevel());
printed, but nothing else. I guess another logger is used...
* I also wondered why the DefaultMaven class referes to the Mojo.ROLE,
Logger logger = loggerManager.getLoggerForComponent( Mojo.ROLE );
But trying to change that didn't affect anything.
* the only way I was able to achieve some kinds of results was by changing the
MavenCli class:
mavenEmbedder.setClassWorld( classWorld );
// added
mavenEmbedder.setLogger( new MavenEmbedderConsoleLogger() );
// end of added
mavenEmbedder.start();
there by specifying the threshold of the MavenEmbedderConsoleLogger, I manage
to get DEBUG messages, but they are prefixed by:
[ maven embedder INFO]
[ maven embedder INFO] Total time: 3 seconds
[ maven embedder INFO] Finished at: Wed Jun 07 22:10:10 CEST 2006
[ maven embedder INFO] Final Memory: 2M/5M
[ maven embedder INFO]
:(
* I suspect that the logger threshold must be set before starting the plexus
embedder, but I don't see any way of programatically achieving this result.
Note: in MavenEmbedder.start(), the following debug prints out *null* for the
logger field:
embedder = new Embedder();
System.err.println("XXX logger " + logger);
if ( logger != null )
{
embedder.setLoggerManager( new MavenEmbedderLoggerManager( new
PlexusLoggerAdapter( logger ) ) );
}
Not sure if that helps...
* relevant IRC exchange
(22:09:01) lacoste1: jdcasey: if I do setThreshold(Maven.ROLE, DEBUG) then I
see that the logger works with debug() later on, but as no other DEBUG message
is printed, I guess that a different logger is used from within the
application. I think that the logger threshold has to be initialized before the
embedder is started, and that means changing the MavenCli. Will try that...
(22:09:21) jdcasey: yup, I think you're right
(22:09:36) jdcasey: actually, before the Plexus embedder is started...
(22:09:50) jdcasey: if the MavenEmbedder exists outside of the plexus embedder,
it should be in the maven embedder
(22:09:53) jdcasey: not the CLI
(22:09:59) jdcasey: that way, it's reusable for embedded apps
> mvn -X doesn't enable debugging
> ---
>
> Key: MNG-2351
> URL: http://jira.codehaus.org/browse/MNG-2351
> Project: Maven 2
> Type: Bug
> Components: Embedding
> Versions: 2.1
> Reporter: Jerome Lacoste
>
>
> mvn -X doesn't enable debugging
> If I add the following code to DefaultMaven.execute(...)
> public void execute( MavenExecutionRequest request )
> throws MavenExecutionException
> [...]
>
> loggerManager.setThreshold( request.getLoggingLevel() );
> // ADDED
> loggerManager.getLoggerForComponent( Maven.ROLE ).info( "XXX logging
> level " + request.getLoggingLevel());
> loggerManager.getLoggerForComponent( Maven.ROLE ).debug( "XXX logging
> level " + request.getLoggingLevel());
> System.err.println("XXX logging level " + request.getLoggingLevel());
> System.err.println("XXX show errors " + request.isShowErrors());
> System.err.println("XXX logger threshold " +
> loggerManager.getLoggerForComponent( Maven.ROLE ).getThreshold());
> // end of ADDED
> I get:
> [INFO] XXX logging level 0
> XXX logging level 0
> XXX show errors true
> XXX logger threshold 1
> Looks like something is wrong with regard to thresholds in the Maven.ROLE
> component.
--
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-8) wagon-http does not MKCOL for missing parent resources during deploy
[ http://jira.codehaus.org/browse/WAGONHTTP-8?page=comments#action_66853 ]
Carlos Sanchez commented on WAGONHTTP-8:
I think you are mixing things here.
Try wagon-webdav
http://maven.apache.org/wagon/wagon-providers/wagon-webdav/index.html
> wagon-http does not MKCOL for missing parent resources during deploy
>
>
> Key: WAGONHTTP-8
> URL: http://jira.codehaus.org/browse/WAGONHTTP-8
> Project: wagon-http
> Type: Bug
> Versions: 1.0-alpha-6
> Environment: Linux/x86_64, FC4, jdk 1.5.0_06-b05, mvn 2.0.2, against
> Apache/2.0.54 (Fedora) DAV/2
> Reporter: Matthew Daniel
> Priority: Blocker
>
>
> Please see MNG-1580 and
> When trying to deploy using wagon-http, it does not understand the concept of
> parent directories and just issues a blind PUT with the resource URI. Further
> to the user's confusion, it does not report a helpful message but "Access
> denided" which is 100% not true.
> {quote}
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying
> artifactat
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
> 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 deploying
> artifact
> at
> org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:160)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531)
> ... 16 more
> Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException:
> Error deploying artifact: Authorization failed: Access denided to:
> http://servername/path/to/a/non-existant/1.5-SNAPSHOT/artifactid-1.5-20060209.202937-1.jar
> at
> org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:91)
> at
> org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:148)
> ... 18 more
> Caused by: org.apache.maven.wagon.TransferFailedException: Authorization
> failed: Access denided to:
> http://servername/path/to/a/non-existant/1.5-SNAPSHOT/artifactid-1.5-20060209.202937-1.jar
> at
> org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:215)
> at
> org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:109)
> at
> org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:77)
> ... 19 more
> Caused by: org.apache.maven.wagon.authorization.AuthorizationException:
> Access denided to:
> http://servername/path/to/a/non-existant/1.5-SNAPSHOT/artifactid-1.5-20060209.202937-1.jar
> at
> org.apache.maven.wagon.providers.http.HttpWagon.put(HttpWagon.java:202)
> at
> org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:180)
> ... 21 more
> {quote}
--
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: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_66854 ] Drew Farris commented on MNGECLIPSE-59: --- There's no need to patch or rebuild the embedder with the approach I contributed -- which may be useful for people without the time or patience to do so until Mary/Kenney's patch gets rolled into a release. The patch I contributed works although I won't comment on how elegant it may or may not be. Perhaps someone else will find it useful. > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Type: New Feature > Components: Dependency Resolver > Versions: 0.0.4 > Reporter: Leonardo Quijano Vincenzi > Assignee: Eugene Kuleshov > Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59, > mngeclipse-59-drew-hack.txt > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- 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-1580) Unable to enable http-wagon instead of http-wagon-lightweight using
[ http://jira.codehaus.org/browse/MNG-1580?page=comments#action_66855 ] Carlos Sanchez commented on MNG-1580: - You sould try wagon-webdav http://maven.apache.org/wagon/wagon-providers/wagon-webdav/index.html > Unable to enable http-wagon instead of http-wagon-lightweight using > > --- > > Key: MNG-1580 > URL: http://jira.codehaus.org/browse/MNG-1580 > Project: Maven 2 > Type: Bug > Versions: 2.0 > Environment: CentOS release 4.1 (Final) > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05) > Reporter: David Rice > > > I am attempting to deploy using http and in order to use the http-wagon > plugin I had to remove the wagon-http-lightweight-1.0-alpha-5.jar jar from > the lib directory and put in the wagon-http-1.0-alpha-5.jar. > I attempted to refer to the wagon-http in the section. > It downloaded the plugin, but continued to get the error "PUT operation is > not supported by Light Weight HTTP wagon". Only removing the lightweight > jar fixed this. -- 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-8) wagon-http does not MKCOL for missing parent resources during deploy
[ http://jira.codehaus.org/browse/WAGONHTTP-8?page=comments#action_66858 ]
darren hartford commented on WAGONHTTP-8:
-
Unfortunately, not mixing those two - HTTP server does not mean WebDAV, and the
Wagon-HTTP transports do *not* have a way to create directories/collections
right now (similar to MKCOL in WebDAV).
*Either find a way to create directory/collection through standard HTTP REST
methods.
or
*Document that the wagon-HTTP/http-lightweight is for GET-style transport only,
not PUT/POSTing artifacts and sites.
my two coppers,
-D
> wagon-http does not MKCOL for missing parent resources during deploy
>
>
> Key: WAGONHTTP-8
> URL: http://jira.codehaus.org/browse/WAGONHTTP-8
> Project: wagon-http
> Type: Bug
> Versions: 1.0-alpha-6
> Environment: Linux/x86_64, FC4, jdk 1.5.0_06-b05, mvn 2.0.2, against
> Apache/2.0.54 (Fedora) DAV/2
> Reporter: Matthew Daniel
> Priority: Blocker
>
>
> Please see MNG-1580 and
> When trying to deploy using wagon-http, it does not understand the concept of
> parent directories and just issues a blind PUT with the resource URI. Further
> to the user's confusion, it does not report a helpful message but "Access
> denided" which is 100% not true.
> {quote}
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying
> artifactat
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
> 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 deploying
> artifact
> at
> org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:160)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531)
> ... 16 more
> Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException:
> Error deploying artifact: Authorization failed: Access denided to:
> http://servername/path/to/a/non-existant/1.5-SNAPSHOT/artifactid-1.5-20060209.202937-1.jar
> at
> org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:91)
> at
> org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:148)
> ... 18 more
> Caused by: org.apache.maven.wagon.TransferFailedException: Authorization
> failed: Access denided to:
> http://servername/path/to/a/non-existant/1.5-SNAPSHOT/artifactid-1.5-20060209.202937-1.jar
> at
> org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:215)
> at
> org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:109)
> at
> org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:77)
> ... 19 more
> Caused by: org.apache.maven.wagon.authorization.AuthorizationException:
> Access denided to:
> http://servername/path/to/a/non-existant/1.5-SNAPSHOT/artifactid-1.5-20060209.202937-1.jar
> at
> org.apache.maven.wagon.providers.http.HttpWagon.put(HttpWagon.java:202)
> at
> org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:180)
> ... 21 more
> {quote}
--
This message is automatically generated by JIRA.
-
If you thin
[jira] Created: (MSUREFIRE-131) Surefire-JUnit does not recognize "suite"-methods
Surefire-JUnit does not recognize "suite"-methods
-
Key: MSUREFIRE-131
URL: http://jira.codehaus.org/browse/MSUREFIRE-131
Project: Maven 2.x Surefire Plugin
Type: Bug
Versions: 2.2
Reporter: Philip Gerlach
Attachments: maven-surefire-junit-trunk-412516.patch
Since Surefire-JUnit doesn't support JUnit4 yet, i tried to use a
"suite"-method like
--
public static junit.framework.Test suite() {
return new junit.framework.JUnit4TestAdapter(Foo.class);
}
-
to run it, but Surefire-JUnit did not recognize these methods and treated them
like PojoTests what obviously lead to TestFailures.
So I fetched the source code from the repository and searched for the problem.
I found two if-conditons in JUnitTestSet and JUnitDirectoryTestSuite that did
not test for the "suite"-mechanism, so I wrote a new static method to test for
this situation and integrated it in the if-conditions.
Now the "suite"-methods work for my JUnit4 Tests and should do also for others
;-)
The patch is attached.
P.S. Since this it is the first time, I'm trying to bugfix something for an
open source-project, please just let me know, if I have done something wrong
with this process.
--
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-2293) maven-plugin-descriptor: Not possible to define a default implementation for a field defined by its interface
[ http://jira.codehaus.org/browse/MNG-2293?page=all ] Jerome Lacoste updated MNG-2293: Attachment: MNG-2293-plugins.diff dependency-mistery.log MNG-2293.diff > maven-plugin-descriptor: Not possible to define a default implementation for > a field defined by its interface > - > > Key: MNG-2293 > URL: http://jira.codehaus.org/browse/MNG-2293 > Project: Maven 2 > Type: New Feature > Components: Plugin Creation Tools > Versions: 2.0.4 > Reporter: Jerome Lacoste > Priority: Critical > Attachments: MNG-2293-plugins.diff, MNG-2293.diff, dependency-mistery.log, > it0106.tar.bz2, patch-MNG-2293-source2.tar.bz2, patch-MNG-2293.diff > > > MOJO-393 is about letting the user define an alternate configuration element, > thus changing the way the webstart plugin works. > For that the idea was to make the mojo field an interface, provide a default > implementation in the plugin and let the user use plexus to instanciate a new > implemenation. > so for most users we would have: > > > > > and for some: > > > > > Unfortunately, today I am forced to specify the implementation in both cases. > There's no way to inform the plugin to use the default implementation. > The plugin.xml contains: > > bla > ...BlaInterface >... > > I tried to use > /[EMAIL PROTECTED] implementation="...BlaImplementation"*/ > BlaInterface bla; > but that fails as well. > Marking critical because it doesn't allow me add new features to the plugin > without breaking the config.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSUREFIRE-129) argLine with -Xmx option has no effect
[ http://jira.codehaus.org/browse/MSUREFIRE-129?page=comments#action_66862 ] Carlos Sanchez commented on MSUREFIRE-129: -- you should get a line with the java command being run "java ..." > argLine with -Xmx option has no effect > -- > > Key: MSUREFIRE-129 > URL: http://jira.codehaus.org/browse/MSUREFIRE-129 > Project: Maven 2.x Surefire Plugin > Type: Bug > Versions: 2.2 > Reporter: Per Olesen > Priority: Minor > > > In v2.1.3 of surefire plugin, this worked fine: > > org.apache.maven.plugins > maven-surefire-plugin > > pertest > -Xmx1024M > > > > But after doing a "mvn -U" and getting a v2.2 of the plugin, my tests starts > failing with OutOfMemoryException again. Doing a "mvn -X" shows me, that it > actually has read the option: > > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-surefire-plugin:2.2:test' --> > [DEBUG] (f) argLine = -Xmx1024M > > But maybe it is not applying the argline? > Forcing it to run with v2.1.3 makes everyting work again. -- 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-2349) dependency management, report-plugins and deploy-site
[ http://jira.codehaus.org/browse/MNG-2349?page=comments#action_66863 ] Carlos Sanchez commented on MNG-2349: - Please post the output of mvn -e to see the stack trace > dependency management, report-plugins and deploy-site > - > > Key: MNG-2349 > URL: http://jira.codehaus.org/browse/MNG-2349 > Project: Maven 2 > Type: Bug > Versions: 2.0.4 > Environment: jdk 1.4.2_11, windows 2000 > Reporter: Thiago Gozzi Prado > Attachments: myproject.zip > > > When I run > mvn -e clean site site-deploy > for the root pom, maven throws a NullPointerException. > If I remove the javadoc report plugin declaration, the site is deployed. > Or if I keep the javadoc report plugin declaration, but remove the dependency > management declaration, the site is deployed. > This happens for some report plugins, not all. Checkstyle, for instance, > works fine. > myproject.zip contains the project structure and the project definition. -- 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: (MPMULTIPROJECT-64) goal multiproject:create-nav seems to have lost pom.id
[ http://jira.codehaus.org/browse/MPMULTIPROJECT-64?page=all ]
Lukas Theussl closed MPMULTIPROJECT-64:
---
Assign To: Lukas Theussl
Resolution: Cannot Reproduce
Closing as I still can't reproduce it and there is no user feedback anymore.
Please re-open with a reproducible test case if you still have troubles.
> goal multiproject:create-nav seems to have lost pom.id
> --
>
> Key: MPMULTIPROJECT-64
> URL: http://jira.codehaus.org/browse/MPMULTIPROJECT-64
> Project: maven-multiproject-plugin
> Type: Bug
> Versions: 1.4.1
> Environment: maven 1.0.2 but with a couple of plugins upgraded to latest
> HEAD.
> Reporter: Benoit Xhenseval
> Assignee: Lukas Theussl
>
>
> Today I have upgraded the checkstyle plugin to 3.0 from 2.6
> This seems to have downloaded a couple of libraries and I now have a strange
> behaviour for multiproject.
> I have also upgraded PMD to 1.8-SNAPSHOT but the following issue appeared
> before:
> When I run "maven multiproject:site", the reactor goes through all
> sub-projects ok BUT when it reaches the call to name="multiproject:create-nav"/>, it seems to lose the pom.id and declares
> that I must exclude the (the top level project" (see line 140 in th
> eplugin.jelly).
> , which is the pom.id, is replaced by the LAST project contained in the
> variable ${multiprojects}.
> the pom.id seems to have changed between the line just BEFORE the call to
> multiproject:create-nav and the FIRST line inside create-nav.
> If I modify the code to add some log:
> POM.id before calling create-nav ${pom.id}
>
> ...
>
>prereqs="multiproject:site-init">
>
> POM.id INSIDE create-nav ${pom.id} and multi ${multiprojects}
>
> POM.id INSIDE LOOP create-nav ${pom.id} and current
> ${reactorProject.id}
>
>
>
>
>
> The pom.id has changed between the first 2 echos. it then matches the last
> reactorProject.id and th ewhole process fails.
> I do not understand why the pom.id is changed somewhere in
> multiproject:site-init...
> My current workaround is to change the process can finish (but it does not generate a proper navigation.xml)
> There is obviously something wrong introduced by the latest download of a
> couple of plugin, I still have maven 1.0.2
> Is there a way I could list all plugins and version? I would post it here...
> Thanks for looking into it.
> Benoit
--
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: (MNGECLIPSE-130) Extending the Maven Plugin to allow reuse from other plugins
[ http://jira.codehaus.org/browse/MNGECLIPSE-130?page=comments#action_66866 ] Eugene Kuleshov commented on MNGECLIPSE-130: Philip, if you actually interested in need executing archetypes it would make sense to talk to Jason and make sure that embedder have an API to resolve artifacts. Then we can provide generic wizard that would be able to handle any kind of artifacts. In case if artifacts would require some kind of complex UI it would make sense to expose extension point in the plugin, so you will be able to contribute your own panels or wizard pages up there. All in all, I don't think that calling some methods in plugin is really good idea. If you want to execute something nothing actually stops you from using your oen embedder instance. Actually that can be made even easier to you if embedder would be an OSGi bundle (essentially few attributes in manifest), so you can bug Jason and the rest of Maven folks about it. > Extending the Maven Plugin to allow reuse from other plugins > > > Key: MNGECLIPSE-130 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-130 > Project: Maven 2.x Extension for Eclipse > Type: New Feature > Versions: 0.0.9 > Environment: Eclipse 3.1 > Reporter: Philip Dodds > Assignee: Eugene Kuleshov > Attachments: newMethod.patch > > > I am currently working to build out some tooling around the ServiceMix/FUSE > platform and I have been successful at integrating the Maven2 Eclipse Plugin > to allow the re-use of the archetype plugin in Eclipse (ie. a wizard using > the archetype under the hood) and also the working with using the JBI plugins > to enable integration with publishing to servers. > In order to maximise reuse I wanted to leverage the Maven 2 Eclipse Plugin to > provide access to the MavenEmbedded infrastructure, however it required some > changes to the plugin to provide access from other plugins and to give a > clean simple interface. > Can you review the attached patch for the Maven 2 plugin that offers the > required functionality > 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] Updated: (MNG-1832) built-in property containing current timestamp
[ http://jira.codehaus.org/browse/MNG-1832?page=all ] Sharmarke Aden updated MNG-1832: Attachment: maven-core_defaultExpressions.patch > built-in property containing current timestamp > -- > > Key: MNG-1832 > URL: http://jira.codehaus.org/browse/MNG-1832 > Project: Maven 2 > Type: New Feature > Versions: 2.0.1 > Reporter: Michal Stochmialek > Attachments: maven-archiver_pomDelete.patch, > maven-core_defaultExpressions.patch > > > Current timestamp (time or date) is often used while filtering resources or > creating manifest in ant builds. There is no equivalent 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] Closed: (MSUREFIRE-130) Setting forkMode changes user.dir for multimodule projects
[ http://jira.codehaus.org/browse/MSUREFIRE-130?page=all ] Brett Porter closed MSUREFIRE-130: -- Resolution: Won't Fix see MSUREFIRE-2 if we were to do this, then the tests would behave differently based on whether it were in a multi-module or run from the individual project. The way it is, the individual project is always consistent, it's only the fork modes which aren't. Both are unintuitive depending on your perspective, but unfortunately only one can be used :) > Setting forkMode changes user.dir for multimodule projects > -- > > Key: MSUREFIRE-130 > URL: http://jira.codehaus.org/browse/MSUREFIRE-130 > Project: Maven 2.x Surefire Plugin > Type: Bug > Versions: 2.2 > Reporter: Richard van der Hoff > Priority: Minor > > > The working directory of tests on a submodule in a multimodule project is > different dependeng on whether forkMode is enabled or not. > When forkMode==never, the working directory is that of the top-level module; > otherwise, it is set to the directory of the submodule. > I know this is defined behaviour - but it has been suggested that it is > unintuitive. -- 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: (MAVENUPLOAD-937) Upload MySQL Connector/MXJ 1.1.6
Upload MySQL Connector/MXJ 1.1.6 Key: MAVENUPLOAD-937 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-937 Project: maven-upload-requests Type: Bug Reporter: Vincent Siveton MySQL Connector/MXJ is a Java Utility package for deploying and managing a MySQL database. 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] Created: (MAVENUPLOAD-938) Upload MySQL Connector/MXJ 5.0.2 beta
Upload MySQL Connector/MXJ 5.0.2 beta - Key: MAVENUPLOAD-938 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-938 Project: maven-upload-requests Type: Bug Reporter: Vincent Siveton MySQL Connector/MXJ is a Java Utility package for deploying and managing a MySQL database. 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] Closed: (MNG-2115) Anchors Broken on Getting Started Guide
[ http://jira.codehaus.org/browse/MNG-2115?page=all ] Stephen Duncan Jr closed MNG-2115: -- Resolution: Fixed This problem no longer appears on the site. > Anchors Broken on Getting Started Guide > --- > > Key: MNG-2115 > URL: http://jira.codehaus.org/browse/MNG-2115 > Project: Maven 2 > Type: Bug > Components: Documentation: Guides > Versions: documentation > Reporter: Stephen Duncan Jr > Priority: Minor > > > On the Maven Getting Started Guide: > http://maven.apache.org/guides/getting-started/index.html the links don't > link to the sections properly. The anchors for the section have an extra "#" > character. -- 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: (MRM-118) code review and clean up
[ http://jira.codehaus.org/browse/MRM-118?page=all ] Brett Porter closed MRM-118: Resolution: Fixed > code review and clean up > > > Key: MRM-118 > URL: http://jira.codehaus.org/browse/MRM-118 > Project: Maven Repository Manager > Type: Bug > Components: design > Versions: 1.0-beta-1 > Reporter: Brett Porter > Assignee: Brett Porter > Fix For: 1.0-beta-1 > > Original Estimate: 8 hours >Time Spent: 10 hours, 30 minutes > Remaining: 0 minutes > -- 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: (MRM-119) Downloadable incremental repository indexes and common embedder API
Downloadable incremental repository indexes and common embedder API --- Key: MRM-119 URL: http://jira.codehaus.org/browse/MRM-119 Project: Maven Repository Manager Type: New Feature Components: indexing Reporter: Eugene Kuleshov Priority: Critical Index I build for ibiblio is nearly 12Mb (with class names) and it is not really good idea to download whole index on every update. We discussed this with jason and agreed on the following structure. -- since lucene index is actually a folder it would make sense to have zip it -- we need some metadata in a common repository place. That metadata will enumerate all existing index zips, their type (full or incremental) and also specify date interval for incremental indexes -- full index for those who don't have anything yet -- incremental indexes for last N months, M last weeks and K last days. We also need this stuff exposed trough Embedder API, e.g. get index updates for given repository and put them into given location (or perhaps somewhere under local repository) and probably merge incremental chunks into the local index copy This is quite critical since there is no direct access to centrl repository and local indexer can't be 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: (MNGECLIPSE-19) version can not be supplied in parent pom
[ http://jira.codehaus.org/browse/MNGECLIPSE-19?page=all ] Eugene Kuleshov closed MNGECLIPSE-19: - Resolution: Fixed Fix Version: 0.0.10 Fixed in trunk > version can not be supplied in parent pom > - > > Key: MNGECLIPSE-19 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-19 > Project: Maven 2.x Extension for Eclipse > Type: Bug > Versions: 0.0.3 > Reporter: Lee Meador > Assignee: Eugene Kuleshov > Fix For: 0.0.10 > Attachments: MNGECLIPSE-19.jpg, test-projects-MNGECLIPSE-19.zip > > > If I don't have a tag in the POM, I get an eclipse error with its > little red spot on the top line of the POM. The maven dependencies all > disappear (and, of course, most everything won't compile any more). > The version should be gotten from the parent POM but doesn't seem to be. > Interestingly enough, the first dependency with no version (jmock) seems to > be ok. The message on the red spot on the pom does not mention jmock. It does > mention all three of the spring dependencies that follow 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] Closed: (MNGECLIPSE-20) using ${version} for subproject dependencies doesn't work (maven uses 2.4.1 version instead)
[ http://jira.codehaus.org/browse/MNGECLIPSE-20?page=all ]
Eugene Kuleshov closed MNGECLIPSE-20:
-
Resolution: Fixed
Fix Version: 0.0.10
Veified against trunk version. Probably been working in earlier versions too.
> using ${version} for subproject dependencies doesn't work (maven uses 2.4.1
> version instead)
>
>
> Key: MNGECLIPSE-20
> URL: http://jira.codehaus.org/browse/MNGECLIPSE-20
> Project: Maven 2.x Extension for Eclipse
> Type: Bug
> Versions: 0.0.3
> Environment: win xp, maven 2.0.1, eclipse plugin 0.0.3, eclipse 3.1
> Reporter: Michal Stochmialek
> Assignee: Eugene Kuleshov
> Fix For: 0.0.10
> Attachments: mvn-multiproject.zip
>
>
> My project is a ear multiproject. It has 5 modules, that have internal
> dependencies. For example web module needs app and type modules.
> I usually use following declaration for this kind of dependencies. Note that
> I'm using ${version} in dependency. In result I'm requesting foo-type jar of
> the same version as current project.
>
> 4.0.0
>
> foo
> foo
> 0.0.1-SNAPSHOT
>
> foo-app
>
>
> foo
> foo-type
> ${version}
>
>
>
> This works from commandline, but doesn't work in eclipse plugin. I get
> following message:
> "Unable to download the artifact from any repository foo:foo-type-2.4.1.jar"
> Maven (or maven plugin) tries to download foo-type module in very strange
> version (instead 0.0.1-SNAPSHOT)!
> I've attached simple multimodule project.
--
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: (MNGECLIPSE-26) Handling system dependencies
[ http://jira.codehaus.org/browse/MNGECLIPSE-26?page=all ] Eugene Kuleshov closed MNGECLIPSE-26: - Resolution: Fixed Fix Version: 0.0.10 It should be possible to use Maven's profiles mechanism and system dependencies to declare specific system jars. See: http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html http://maven.apache.org/guides/introduction/introduction-to-profiles.html That should cover dependency resolution for build Maven classpatch container. Compiler source and target is picked from pom.xml and set for project settings when "Update Source Folders" action is invoked. Maven launcher allows to select JDK used to launch Maven. I guess that cover everything. Feel free to reopen if I missed something, but attach project that would allow to reproduce issue. > Handling system dependencies > > > Key: MNGECLIPSE-26 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-26 > Project: Maven 2.x Extension for Eclipse > Type: New Feature > Versions: 0.0.3 > Environment: Eclipse 3.1, MyEclipse, Java 5.0 > Reporter: Leonardo Quijano Vincenzi > Assignee: Eugene Kuleshov > Fix For: 0.0.10 > > > The Maven plugin uses the JRE/JDK used to launch Eclipse. It would be useful > to include a dialog that allows people to change that default JDK (mostly due > to problems when specifying system jars in pom files), probably just > selecting the appropiate Eclipse-configured JDK. > At least the plugin could use the default Eclipse JDK. -- 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: (MNGECLIPSE-29) Plug-In is not using settings.xml
[ http://jira.codehaus.org/browse/MNGECLIPSE-29?page=comments#action_66892 ] Eugene Kuleshov commented on MNGECLIPSE-29: --- Version in a trunk should use proxy configurations and other stuff from settings.xml when launching maven. It it those settings are still can't be used when resolving dependencies and downloading jars from maven classpath container. So, MavenEmbedder.readProjectWithDependencies() call is not using settings.xml > Plug-In is not using settings.xml > - > > Key: MNGECLIPSE-29 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-29 > Project: Maven 2.x Extension for Eclipse > Type: Bug > Versions: 0.0.3 > Environment: Windows (probably ANY behind a Proxy or Firewall) > Reporter: Werner Keil > Assignee: Dmitri Maximovich > Priority: Minor > Attachments: pom.xml > > Time Spent: 30 minutes >Remaining: 0 minutes > > While Maven 2 on its own runs the same goal (test) from the command line > without errors the Plug-in for Eclipse fails trying to update itself or some > other dependency: > [DEBUG] Found 0 components to load on start > [DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and > Settings\username\.m2\plugin-registry.xml' > [DEBUG] Building Maven global-level settings from: 'C:\Documents and > Settings\username\workspace\32\mtest\conf\settings.xml' > [DEBUG] Building Maven user-level settings from: 'C:\Documents and > Settings\username\.m2\settings.xml' > [DEBUG] mtest:mtest:jar:1.0.1-SNAPSHOT (selected for null) > [DEBUG] junit:junit:jar:3.8.1 (selected for compile) > [INFO] > > [INFO] Building mtest > [INFO]task-segment: [test] > [INFO] > > [DEBUG] maven-resources-plugin: resolved to version 2.1 from repository > central > [DEBUG] Found 0 components to load on start > [DEBUG] maven-compiler-plugin: resolved to version 2.0 from repository central > [DEBUG] Found 0 components to load on start > [DEBUG] maven-surefire-plugin: resolved to version 2.0 from repository central > [DEBUG] Found 0 components to load on start > [DEBUG] org.apache.maven.plugins:maven-resources-plugin:maven-plugin:2.1 > (selected for runtime) > [DEBUG] commons-io:commons-io:jar:1.0 (selected for runtime) > [DEBUG] junit:junit:jar:3.8.1 (selected for runtime) > [DEBUG] Skipping disabled repository snapshots > [DEBUG] Trying repository central > org.apache.maven.plugin.MojoExecutionException: Error configuring plugin for > execution of 'resources:resources'. > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:399) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:554) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:508) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:494) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:307)>> > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:439) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:383) > at org.maven.ide.eclipse.Maven2Executor.main(Maven2Executor.java:71) > Caused by: org.apache.maven.plugin.PluginConfigurationException: Error > configuring: org.apache.maven.plugins:maven-resources-plugin. Reason: Cannot > resolve plugin dependencies > at > org.apache.maven.plugin.DefaultPluginManager.ensurePluginContainerIsComplete(DefaultPluginManager.java:650) > at > org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:541) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:394) > ... 8 more > Caused by: org.apache.maven.artifact.resolver.ArtifactResolutionException: > Error transferring file > org.apache.maven:maven-model:2.0:jar > from the specified remote repositories: > snapshots (http://snapshots.maven.codehaus.org/maven2), > central (http://repo1.maven.org/maven2) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:150) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:64) > at > org.apache.maven.plugin.DefaultPluginManager.resolveCoreArtifacts(DefaultPluginManager.java:682) > at > org.apache.maven.plugin.DefaultPluginManager.ensurePluginContainerIsComplete(DefaultPluginManager.java:639) >
[jira] Closed: (MNGECLIPSE-30) Maven plugin keeps looking for non-existent apacheds-*-2.4.1 dependency
[ http://jira.codehaus.org/browse/MNGECLIPSE-30?page=all ]
Eugene Kuleshov closed MNGECLIPSE-30:
-
Resolution: Fixed
Fix Version: 0.0.10
Tested this with trunk build and dont see this anymore. If it still happens
with 0.0.10 or trunk build, please reopen and attach complete Eclipse project
with pom.xml to reproduce.
> Maven plugin keeps looking for non-existent apacheds-*-2.4.1 dependency
> ---
>
> Key: MNGECLIPSE-30
> URL: http://jira.codehaus.org/browse/MNGECLIPSE-30
> Project: Maven 2.x Extension for Eclipse
> Type: Bug
> Versions: 0.0.3
> Environment: Mac OS X, Eclipse 3.1.1, Plugin v0.0.3
> Reporter: Federico Sauter
> Assignee: Eugene Kuleshov
> Fix For: 0.0.10
> Attachments: MNGECLIPSE-30.launcher.log, mvn_test-output.txt,
> plugin-test.zip, pom.xml
>
>
> When using the plugin in the mentioned environment it is impossible to build
> the project. The error message states that there was a dependency the plugin
> was not able to find in any repository, namely apacheds-shared or
> apacheds-core, version 2.4.1. Of course there is no such library in the
> respository and there is no pom file referencing it.
> Having read http://jira.codehaus.org/browse/MNGECLIPSE-20 I tried to
> eliminate all version references from ${pom.version} to an actual versino
> number, but the error persisted. I am posting this as a bug, since I do not
> understand what is going wrong and where the plugin got that version number
> (2.4.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] Commented: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_66895 ] Marek Bieganski commented on MNGECLIPSE-59: --- In my opinion main goal of this functionality is to have only one version of .classpath and pom for each project. It should be versioned with projects in CVS or SVN. If somebody wants to work on single projects only, he checks out only this project. Correct dependencies are downloaded from m2 repository. If sombody decide to work on other projects connected with dependencies, the only thing he has to do is to check out correct versions of these projects. No changes in pom nor in .classpath are needed. There will be no reqiured projects declarations in "java build path". I thing it will be a huge improvement for people working on complicated project sets, to allow them to work only on projects that they are interested in without forcing them to change anything in build path or to check out everything. > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Type: New Feature > Components: Dependency Resolver > Versions: 0.0.4 > Reporter: Leonardo Quijano Vincenzi > Assignee: Eugene Kuleshov > Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59, > mngeclipse-59-drew-hack.txt > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- 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: (MNGECLIPSE-46) Repository search dialog not handling "-" properly
[ http://jira.codehaus.org/browse/MNGECLIPSE-46?page=all ] Eugene Kuleshov closed MNGECLIPSE-46: - Resolution: Fixed Fix Version: 0.0.10 Both "commons-lang" and "javax.portlet" now return correct results. Though "commons-" and "commons-lan" and even "commons-la*" return empty results. But "*lang" return "commons-lang". > Repository search dialog not handling "-" properly > -- > > Key: MNGECLIPSE-46 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-46 > Project: Maven 2.x Extension for Eclipse > Type: Improvement > Components: Repository Management > Versions: 0.0.4 > Reporter: Dmitri Maximovich > Assignee: Eugene Kuleshov > Priority: Minor > Fix For: 0.0.10 > > > If user types "commons-lang" search result would be empty, even so > commons-lang is listed in repository index. > Most likely dash is treated as token separator. -- 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: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_66896 ] Eugene Kuleshov commented on MNGECLIPSE-59: --- Kenney, can you please merge your code with trunk changes and recreate patch afte that? I can't apply this one. > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Type: New Feature > Components: Dependency Resolver > Versions: 0.0.4 > Reporter: Leonardo Quijano Vincenzi > Assignee: Eugene Kuleshov > Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59, > mngeclipse-59-drew-hack.txt > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- 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
