[jira] Commented: (CONTINUUM-1054) IllegalStateException stack adding pom

2007-12-13 Thread Qingtian Wang (JIRA)

[ 
http://jira.codehaus.org/browse/CONTINUUM-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116770
 ] 

Qingtian Wang commented on CONTINUUM-1054:
--

Just installed 1.1 final on redhat linux. Same issue. Can't add Maven 2 project 
at all. 

> IllegalStateException stack adding pom
> --
>
> Key: CONTINUUM-1054
> URL: http://jira.codehaus.org/browse/CONTINUUM-1054
> Project: Continuum
>  Issue Type: Bug
>  Components: Web interface
>Affects Versions: 1.1-alpha-1
>Reporter: Carlos Sanchez
>Priority: Minor
> Fix For: Future
>
>
> Adding a m2 pom from a web location causes this stack trace, although seems 
> to work fine
> 2006-12-13 10:46:07,109 [SocketListener0-1] INFO  DispatcherUtils 
>- Unable to find 'webwork.multipart.saveDir' property setting. Defaulting 
> to javax.servlet.context.tempdir
> 2006-12-13 10:46:07,156 [SocketListener0-1] WARN  MultiPartRequest
>- Item is a file upload of 0 size, ignoring
> 2006-12-13 10:46:07,156 [SocketListener0-1] ERROR DispatcherUtils 
>- Error setting character encoding to 'UTF-8' - ignoring.
> java.lang.IllegalStateException: getReader() or getInputStream() called
> at 
> org.mortbay.jetty.servlet.ServletHttpRequest.setCharacterEncoding(ServletHttpRequest.java:602)
> at 
> javax.servlet.ServletRequestWrapper.setCharacterEncoding(ServletRequestWrapper.java:112)
> at 
> com.opensymphony.webwork.dispatcher.DispatcherUtils.prepare(DispatcherUtils.java:392)
> at 
> com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:160)
> at 
> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> at 
> com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:118)
> at 
> com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)
> at 
> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> at 
> com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:88)
> at 
> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> at 
> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> at 
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
> at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
> at 
> org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633)
> at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
> at org.mortbay.http.HttpServer.service(HttpServer.java:909)
> at org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
> at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982)
> at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
> at 
> org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
> at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
> at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)

-- 
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-623) find artifact self signed certificate will expire soon

2007-12-13 Thread Brett Porter (JIRA)

 [ 
http://jira.codehaus.org/browse/MRM-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brett Porter closed MRM-623.


Resolution: Fixed

> find artifact self signed certificate will expire soon
> --
>
> Key: MRM-623
> URL: http://jira.codehaus.org/browse/MRM-623
> Project: Archiva
>  Issue Type: Bug
>  Components: web application
>Affects Versions: 1.0
>Reporter: Brett Porter
>Assignee: Brett Porter
> Fix For: 1.0.1
>
>
> we need a new certificate with a longer timeframe

-- 
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-623) find artifact self signed certificate will expire soon

2007-12-13 Thread Brett Porter (JIRA)

[ 
http://jira.codehaus.org/browse/MRM-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116769
 ] 

Brett Porter commented on MRM-623:
--

regenerated with:
keytool -genkey -alias mykey -keypass password -keystore keystore -validity 
1


> find artifact self signed certificate will expire soon
> --
>
> Key: MRM-623
> URL: http://jira.codehaus.org/browse/MRM-623
> Project: Archiva
>  Issue Type: Bug
>  Components: web application
>Affects Versions: 1.0
>Reporter: Brett Porter
>Assignee: Brett Porter
> Fix For: 1.0.1
>
>
> we need a new certificate with a longer timeframe

-- 
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: (MEV-443) Several projects have maven-metadata.xml files that are missing released versions

2007-12-13 Thread Noah Levitt (JIRA)

[ 
http://jira.codehaus.org/browse/MEV-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116767
 ] 

Noah Levitt commented on MEV-443:
-

Will this issue ever be fixed? Encountered it with hibernate, c3p0, 
commons-lang, ... like half the things I've tried.

> Several projects have maven-metadata.xml files that are missing released 
> versions
> -
>
> Key: MEV-443
> URL: http://jira.codehaus.org/browse/MEV-443
> Project: Maven Evangelism
>  Issue Type: Bug
>  Components: Invalid Metadata
>Reporter: Patrick Moore
> Attachments: maven-metadata.xml
>
>
> I am trying to use the version range feature that is talked about in Better 
> builds with Maven. I am specifying the commons-httpclient dependency as
> 
>   commons-httpclient
>   commons-httpclient
>   [3.1-alpha1,)
> 
> Unfortunately, the usefulness of this feature is being sabotaged because the 
> latest version of artificat is not listed in the maven-metadata.xml. 
> Please update the maven-metadata.xml in this project and others. In 
> particular 
> hsqldb,
> commons-*,
> rhino/js
> htmlunit
> When updating those files, please do not list the versions using dates as 
> their version id as it screws up the maven feature that allows dependencies 
> to specify a version range.

-- 
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-623) find artifact self signed certificate will expire soon

2007-12-13 Thread Brett Porter (JIRA)

 [ 
http://jira.codehaus.org/browse/MRM-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brett Porter updated MRM-623:
-

 Assignee: Brett Porter
Fix Version/s: (was: 1.1)
   1.0.1

> find artifact self signed certificate will expire soon
> --
>
> Key: MRM-623
> URL: http://jira.codehaus.org/browse/MRM-623
> Project: Archiva
>  Issue Type: Bug
>  Components: web application
>Affects Versions: 1.0
>Reporter: Brett Porter
>Assignee: Brett Porter
> Fix For: 1.0.1
>
>
> we need a new certificate with a longer timeframe

-- 
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] Issue Comment Edited: (SCM-342) scm:tag should support flat project layout

2007-12-13 Thread Duncan Doyle (JIRA)

[ 
http://jira.codehaus.org/browse/SCM-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116760
 ] 

mccloud edited comment on SCM-342 at 12/13/07 6:20 PM:


I've attached a patch.

The patch provides support for tagging a flat project layout. I've disabled the 
@aggregator Maven option to process multiple modules. Furthermore. it basically 
keeps track of all the ScmFileSet basedirectories which have been processed in 
a static HashSet. Before a new fileset is tagged, it checks that the ScmFileSet 
has not already been processed. Next it checks that the current ScmFileSet is 
not a sub-directory of an already processed basedir. If that's all true, the 
fileset is tagged and its basedir is added to the static HashSet..

This solution works in both a standard Maven2 layout (i.e. not tagging 
sub-projects twice because it keeps track of already processed basedirs) and a 
flat layout (i.e. because the @aggregator option is disabled).

  was (Author: mccloud):
I've attached a patch.

The patch provides support for tagging a flat project layout. I've enabled the 
@aggregator Maven option to process multiple modules. Furthermore. it basically 
keeps track of all the ScmFileSet basedirectories which have been processed in 
a static HashSet. Before a new fileset is tagged, it checks that the ScmFileSet 
has not already been processed. Next it checks that the current ScmFileSet is 
not a sub-directory of an already processed basedir. If that's all true, the 
fileset is tagged and its basedir is added to the static HashSet..

This solution works in both a standard Maven2 layout (i.e. not tagging 
sub-projects twice because it keeps track of already processed basedirs) and a 
flat layout (i.e. because the @aggregator option is used).
  
> scm:tag should support flat project layout
> --
>
> Key: SCM-342
> URL: http://jira.codehaus.org/browse/SCM-342
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-plugin
>Affects Versions: 1.0
> Environment: Windows XP, Eclipse 3.3
>Reporter: Duncan Doyle
> Attachments: flatProjectTagPatch.txt
>
>
> I have a Maven2 Flat Project Layout as described here: 
> http://maven.apache.org/guides/mini/guide-ide-eclipse.html
> Basically my directory layout is as follows:
> /MavenRoot/pom.xml  (this is the SuperPom)
> /Module1/pom.xml
> /Module2/pom.xml
> /Module3/pom.xml
> Modules 1,2 and 3 are specified in the  section of the SuperPom 
> (e.g() ../Module1). Each POM contains its own CVS connection 
> URL.
> When I execute the scm:tag goal on the SuperPom in the MavenRoot project, 
> only the MavenRoot project gets tagged. The same behaviour can be seen with 
> the scm:update goal, which was fixed by providing a scm:update-subprojects 
> goal.
> I would like to see this behaviour fixed in the SCM plugin, while Maven2 
> advices a Flat Project Layout when working with Eclipse. At this moment I 
> can't use the tag goal at all (it should be executed automatically by 
> CruiseControl on a succesfull build).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Issue Comment Edited: (SCM-342) scm:tag should support flat project layout

2007-12-13 Thread Duncan Doyle (JIRA)

[ 
http://jira.codehaus.org/browse/SCM-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116760
 ] 

mccloud edited comment on SCM-342 at 12/13/07 6:16 PM:


Patch to support to tag flat project layouts.

This patch provides support for flat project layouts. I've enabled the 
@aggregator Maven option to process multiple modules. Furthermore. it basically 
keeps track of all the ScmFileSet basedirectories which have been processed in 
a static HashSet. Before a new fileset is tagged, it checks that the ScmFileSet 
has not already been processed. Next it checks that the current ScmFileSet is 
not a sub-directory of an already processed basedir. If that's all true, the 
fileset is tagged and its basedir is added to the static HashSet..

This solution works in both a standard Maven2 layout (i.e. not tagging 
sub-projects twice because it keeps track of already processed basedirs) and a 
flat layout (i.e. because the @aggregator option is used).

  was (Author: mccloud):
Patch to support to tag flat project layouts.
  
> scm:tag should support flat project layout
> --
>
> Key: SCM-342
> URL: http://jira.codehaus.org/browse/SCM-342
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-plugin
>Affects Versions: 1.0
> Environment: Windows XP, Eclipse 3.3
>Reporter: Duncan Doyle
> Attachments: flatProjectTagPatch.txt
>
>
> I have a Maven2 Flat Project Layout as described here: 
> http://maven.apache.org/guides/mini/guide-ide-eclipse.html
> Basically my directory layout is as follows:
> /MavenRoot/pom.xml  (this is the SuperPom)
> /Module1/pom.xml
> /Module2/pom.xml
> /Module3/pom.xml
> Modules 1,2 and 3 are specified in the  section of the SuperPom 
> (e.g() ../Module1). Each POM contains its own CVS connection 
> URL.
> When I execute the scm:tag goal on the SuperPom in the MavenRoot project, 
> only the MavenRoot project gets tagged. The same behaviour can be seen with 
> the scm:update goal, which was fixed by providing a scm:update-subprojects 
> goal.
> I would like to see this behaviour fixed in the SCM plugin, while Maven2 
> advices a Flat Project Layout when working with Eclipse. At this moment I 
> can't use the tag goal at all (it should be executed automatically by 
> CruiseControl on a succesfull build).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Issue Comment Edited: (SCM-342) scm:tag should support flat project layout

2007-12-13 Thread Duncan Doyle (JIRA)

[ 
http://jira.codehaus.org/browse/SCM-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116760
 ] 

mccloud edited comment on SCM-342 at 12/13/07 6:17 PM:


I've attached a patch.

The patch provides support for tagging a flat project layout. I've enabled the 
@aggregator Maven option to process multiple modules. Furthermore. it basically 
keeps track of all the ScmFileSet basedirectories which have been processed in 
a static HashSet. Before a new fileset is tagged, it checks that the ScmFileSet 
has not already been processed. Next it checks that the current ScmFileSet is 
not a sub-directory of an already processed basedir. If that's all true, the 
fileset is tagged and its basedir is added to the static HashSet..

This solution works in both a standard Maven2 layout (i.e. not tagging 
sub-projects twice because it keeps track of already processed basedirs) and a 
flat layout (i.e. because the @aggregator option is used).

  was (Author: mccloud):
Patch to support to tag flat project layouts.

This patch provides support for flat project layouts. I've enabled the 
@aggregator Maven option to process multiple modules. Furthermore. it basically 
keeps track of all the ScmFileSet basedirectories which have been processed in 
a static HashSet. Before a new fileset is tagged, it checks that the ScmFileSet 
has not already been processed. Next it checks that the current ScmFileSet is 
not a sub-directory of an already processed basedir. If that's all true, the 
fileset is tagged and its basedir is added to the static HashSet..

This solution works in both a standard Maven2 layout (i.e. not tagging 
sub-projects twice because it keeps track of already processed basedirs) and a 
flat layout (i.e. because the @aggregator option is used).
  
> scm:tag should support flat project layout
> --
>
> Key: SCM-342
> URL: http://jira.codehaus.org/browse/SCM-342
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-plugin
>Affects Versions: 1.0
> Environment: Windows XP, Eclipse 3.3
>Reporter: Duncan Doyle
> Attachments: flatProjectTagPatch.txt
>
>
> I have a Maven2 Flat Project Layout as described here: 
> http://maven.apache.org/guides/mini/guide-ide-eclipse.html
> Basically my directory layout is as follows:
> /MavenRoot/pom.xml  (this is the SuperPom)
> /Module1/pom.xml
> /Module2/pom.xml
> /Module3/pom.xml
> Modules 1,2 and 3 are specified in the  section of the SuperPom 
> (e.g() ../Module1). Each POM contains its own CVS connection 
> URL.
> When I execute the scm:tag goal on the SuperPom in the MavenRoot project, 
> only the MavenRoot project gets tagged. The same behaviour can be seen with 
> the scm:update goal, which was fixed by providing a scm:update-subprojects 
> goal.
> I would like to see this behaviour fixed in the SCM plugin, while Maven2 
> advices a Flat Project Layout when working with Eclipse. At this moment I 
> can't use the tag goal at all (it should be executed automatically by 
> CruiseControl on a succesfull build).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Updated: (SCM-342) scm:tag should support flat project layout

2007-12-13 Thread Duncan Doyle (JIRA)

 [ 
http://jira.codehaus.org/browse/SCM-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duncan Doyle updated SCM-342:
-

Attachment: flatProjectTagPatch.txt

Patch to support to tag flat project layouts.

> scm:tag should support flat project layout
> --
>
> Key: SCM-342
> URL: http://jira.codehaus.org/browse/SCM-342
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-plugin
>Affects Versions: 1.0
> Environment: Windows XP, Eclipse 3.3
>Reporter: Duncan Doyle
> Attachments: flatProjectTagPatch.txt
>
>
> I have a Maven2 Flat Project Layout as described here: 
> http://maven.apache.org/guides/mini/guide-ide-eclipse.html
> Basically my directory layout is as follows:
> /MavenRoot/pom.xml  (this is the SuperPom)
> /Module1/pom.xml
> /Module2/pom.xml
> /Module3/pom.xml
> Modules 1,2 and 3 are specified in the  section of the SuperPom 
> (e.g() ../Module1). Each POM contains its own CVS connection 
> URL.
> When I execute the scm:tag goal on the SuperPom in the MavenRoot project, 
> only the MavenRoot project gets tagged. The same behaviour can be seen with 
> the scm:update goal, which was fixed by providing a scm:update-subprojects 
> goal.
> I would like to see this behaviour fixed in the SCM plugin, while Maven2 
> advices a Flat Project Layout when working with Eclipse. At this moment I 
> can't use the tag goal at all (it should be executed automatically by 
> CruiseControl on a succesfull build).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Created: (MANTRUN-79) Please upgrade to ant-1.7.0 from an-1.6.5

2007-12-13 Thread Jason Chaffee (JIRA)
Please upgrade to ant-1.7.0 from an-1.6.5
-

 Key: MANTRUN-79
 URL: http://jira.codehaus.org/browse/MANTRUN-79
 Project: Maven 2.x Antrun Plugin
  Issue Type: Bug
Reporter: Jason Chaffee


We have to use ant-1.7.0  and ant-launcher-1.7.0 for some of things we do 
because 1.6.5 does not have support.  However, we have all types of classloader 
issues because anrun has a dependency on 1.6.5 for these artifacts.  

1.7.0 has been out for a long time and it is backwards compatible.  It should 
be an easy thing to fix for the next release...which hopefully won't be in two 
years which seems like the current life cycle.

-- 
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: (MINVOKER-18) two executions of the same pom causes a prooblem with interpolated-pom.xml

2007-12-13 Thread Olivier Lamy (JIRA)

 [ 
http://jira.codehaus.org/browse/MINVOKER-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy updated MINVOKER-18:
-

 Assignee: Olivier Lamy  (was: John Casey)
Fix Version/s: 1.1

> two executions of the same pom causes a prooblem with interpolated-pom.xml
> --
>
> Key: MINVOKER-18
> URL: http://jira.codehaus.org/browse/MINVOKER-18
> Project: Maven 2.x Invoker Plugin
>  Issue Type: Bug
>Affects Versions: 1.1
> Environment: latest 1.1-SNAPSHOT Version, maven-2.0.7
>Reporter: Gerhard Langs
>Assignee: Olivier Lamy
> Fix For: 1.1
>
> Attachments: invoker-18.patch, invoker-18.patch, 
> pom-interpolation2-invoked.xml, pom-interpolation2.xml
>
>
> TestCase:
>pom-interpolated2.xml uses invoker to invoke 
> "pom-interpolated2-invoked.xml  in 2 "executions".
> invocation:
>mvn -f pom-interpolated2.xml test -e
> the second execution fails, because it is unable to create the 
> "interpolated-pom.xml".
> Proposed solution:
>- dont tag the interpolated-pom.xml as "deleteOnExit",
>- delete that file at the end of every execution.
> Will try to provide a patch
> Greetings, Gerhard
> Output:
> ...
> Caused by: org.apache.maven.plugin.MojoExecutionException: fail to create 
> file 
> D:\maven\maven-invoker-plugin\src\test\resources\unit\interpolation2\.\interpolated-pom.xml
> at 
> org.apache.maven.plugin.invoker.InvokerMojo.buildInterpolatedPomFile(InvokerMojo.java:997)
> at 
> org.apache.maven.plugin.invoker.InvokerMojo.runBuild(InvokerMojo.java:458)
> at 
> org.apache.maven.plugin.invoker.InvokerMojo.execute(InvokerMojo.java:341)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)

-- 
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-626) ClassCastException when saving proxy connector with property defined

2007-12-13 Thread Brian Jackson (JIRA)
ClassCastException when saving proxy connector with property defined


 Key: MRM-626
 URL: http://jira.codehaus.org/browse/MRM-626
 Project: Archiva
  Issue Type: Bug
  Components: build
Affects Versions: 1.0
Reporter: Brian Jackson


I'm having trouble configurating Archiva to proxy an instance of 
> > Proximity because I'm required to set a property on the proxy
> connector.
> > Unfortunately Archiva 1.0 bombs when I try to save a proxy connector 
> > with a property:
> >
> >
> >
> >
> > HTTP ERROR: 500
> >
> > [Ljava.lang.String; cannot be cast to java.lang.String
> >
> > RequestURI=/archiva/admin/editProxyConnector!commit.action
> >
> > Powered by Jetty:// 


> Here's the full stacktrace from the console:
>
> jvm 1| WARNING: /archiva/admin/editProxyConnector!commit.action:
> jvm 1| java.lang.ClassCastException: [Ljava.lang.String; cannot be
> cast to j
> ava.lang.String
> jvm 1|  at
> org.apache.maven.archiva.configuration.io.registry.Configurat
> ionRegistryWriter.writeProxyConnectorConfiguration(ConfigurationRegist
> ry
> Writer.j
> ava:520)
> jvm 1|  at
> org.apache.maven.archiva.configuration.io.registry.Configurat
> ionRegistryWriter.writeConfiguration(ConfigurationRegistryWriter.java:
> 96
> )
> jvm 1|  at
> org.apache.maven.archiva.configuration.io.registry.Configurat
> ionRegistryWriter.write(ConfigurationRegistryWriter.java:34)
> jvm 1|  at
> org.apache.maven.archiva.configuration.DefaultArchivaConfigur
> ation.save(DefaultArchivaConfiguration.java:445)
> jvm 1|  at
> org.apache.maven.archiva.web.action.admin.connectors.proxy.Ab
> stractProxyConnectorAction.saveConfiguration(AbstractProxyConnectorAct
> io
> n.java:1
> 21)
> jvm 1|  at
> org.apache.maven.archiva.web.action.admin.connectors.proxy.Ed
> itProxyConnectorAction.commit(EditProxyConnectorAction.java:91)
> jvm 1|  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> jvm 1|  at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces
> sorImpl.java:39)
> jvm 1|  at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet
> hodAccessorImpl.java:25)
> jvm 1|  at java.lang.reflect.Method.invoke(Method.java:597)
> jvm 1|  at
> com.opensymphony.xwork.DefaultActionInvocation.invokeAction(D
> efaultActionInvocation.java:358)
> jvm 1|  at
> com.opensymphony.xwork.DefaultActionInvocation.invokeActionOn
> ly(DefaultActionInvocation.java:218)
> jvm 1|  at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(Default
> ActionInvocation.java:192)
> jvm 1|  at
> com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor
> .doIntercept(DefaultWorkflowInterceptor.java:175)
> jvm 1|  at
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.in
> tercept(MethodFilterInterceptor.java:86)
> jvm 1|  at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(Default
> ActionInvocation.java:190)
> jvm 1|  at
> com.opensymphony.xwork.validator.ValidationInterceptor.doInte
> rcept(ValidationInterceptor.java:115)
> jvm 1|  at
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.in
> tercept(MethodFilterInterceptor.java:86)
> jvm 1|  at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(Default
> ActionInvocation.java:190)
> jvm 1|  at
> org.apache.maven.archiva.web.interceptor.ConfigurationInterce
> ptor.intercept(ConfigurationInterceptor.java:53)
> jvm 1|  at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(Default
> ActionInvocation.java:190)
> jvm 1|  at
> org.codehaus.plexus.redback.xwork.interceptor.PolicyEnforceme
> ntInterceptor.intercept(PolicyEnforcementInterceptor.java:149)
> jvm 1|  at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(Default
> ActionInvocation.java:190)
> jvm 1|  at
> org.codehaus.plexus.redback.xwork.interceptor.SecureActionInt
> erceptor.intercept(SecureActionInterceptor.java:159)
> jvm 1|  at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(Default
> ActionInvocation.java:190)
> jvm 1|  at
> com.opensymphony.xwork.interceptor.ParameterFilterInterceptor
> .intercept(ParameterFilterInterceptor.java:124)
> jvm 1|  at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(Default
> ActionInvocation.java:190)
> jvm 1|  at
> com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor
> .doIntercept(DefaultWorkflowInterceptor.java:175)
> jvm 1|  at
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.in
> tercept(MethodFilterInterceptor.java:86)
> jvm 1|  at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(Default
> ActionInvocation.java:190)
> jvm 1|  at
> com.opensymphony.xwork.validator.ValidationInterceptor.doInte
> rcept(Valid

[jira] Commented: (SCM-358) maven-scm isn't reporting updated files

2007-12-13 Thread Spencer White (JIRA)

[ 
http://jira.codehaus.org/browse/SCM-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116751
 ] 

Spencer White commented on SCM-358:
---

Any ideas or advice on this issue? Do you need more information? Is there some 
other place that I should post this?

Thanks. 

--Spencer

> maven-scm isn't reporting updated files 
> 
>
> Key: SCM-358
> URL: http://jira.codehaus.org/browse/SCM-358
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-plugin
>Affects Versions: 1.0-beta-3, 1.0
>Reporter: Spencer White
>
> BuildController does not see changes and therefore does not do a build. Here 
> is how I tested:
> 1. cd /project/dir
> 2. find ./ -type f -exec md5sum {} \; > 2.old
> 3. check in changes to perforce from another client
> 4. wait for Continuum to do run it's scheduled task to update code
> 5. Continuum: 
> 346298228 [pool-1-thread-1] INFO 
> org.apache.maven.continuum.buildcontroller.BuildController:default  - 
> "Merging SCM results 
> 346298254 [pool-1-thread-1] INFO 
> org.apache.maven.continuum.buildcontroller.BuildController:default  - The 
> project was not built because no changes were detected in sources since the 
> last build.
> 346298255 [pool-1-thread-1] INFO  
> org.apache.maven.continuum.buildcontroller.BuildController:default  -  No 
> changes, not building
> 6. find ./ -type f -exec md5sum {} \; > 2.new
> 7. diff 2.old 2.new
>
> --begin--
> 28c27
> < d408dc1aab6914b85e3bd2e1ae609368 
> ./src/main/java/com/visto/apps/client/IPhoneyClientProtocolHandler.java
> ---
> > 79dfa098c212744ffec226a8126bb3f5 
> > ./src/main/java/com/visto/apps/client/IPhoneyClientProtocolHandler.java
> --end--
> IPhoneyClientProtocolHandler.java was the file that I had changed and checked 
> into perforce. I check the file and the changes were updated in Continuum's 
> working directory. 
> Should I attach the POM.xml?
> Thanks. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (CONTINUUM-1573) not able to download files from working directory in any format other than html

2007-12-13 Thread Eric Roberts (JIRA)

[ 
http://jira.codehaus.org/browse/CONTINUUM-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116742
 ] 

Eric Roberts commented on CONTINUUM-1573:
-

any ideas as to what's going on?  

> not able to download files from working directory in any format other than 
> html
> ---
>
> Key: CONTINUUM-1573
> URL: http://jira.codehaus.org/browse/CONTINUUM-1573
> Project: Continuum
>  Issue Type: Improvement
>Affects Versions: 1.1-beta-4
> Environment: window 
>Reporter: pallavi satish
> Attachments: screenshot-1.jpg
>
>
> after building a project if it is creating any tar/war/jar file it can not be 
> downloaded from working copy in any formats other than html.

-- 
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: (MRRESOURCES-29) Remote Resources Plugin is not usuable with jdk1.4

2007-12-13 Thread Daniel Kulp (JIRA)

 [ 
http://jira.codehaus.org/browse/MRRESOURCES-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel Kulp closed MRRESOURCES-29.
--

 Assignee: Daniel Kulp
   Resolution: Fixed
Fix Version/s: 1.0-beta-2

> Remote Resources Plugin is not usuable with jdk1.4
> --
>
> Key: MRRESOURCES-29
> URL: http://jira.codehaus.org/browse/MRRESOURCES-29
> Project: Maven 2.x Remote Resources Plugin
>  Issue Type: Bug
>Affects Versions: 1.0-beta-2
>Reporter: Olivier Lamy
>Assignee: Daniel Kulp
>Priority: Blocker
> Fix For: 1.0-beta-2
>
>
> The last deployed version 1.0-beta-1 is not usuable with jdk 1.4.
> class org.apache.maven.plugin.resources.remote.RemoteResourcesClassLoader 
> overrides final method
> getResources(java.lang.String) in java.lang.ClassLoader; overridden method is 
> final
> This method was final with 1.4.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (MNG-2290) Generated URLs in POMs of child modules

2007-12-13 Thread Joerg Schaible (JIRA)

[ 
http://jira.codehaus.org/browse/MNG-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116727
 ] 

Joerg Schaible commented on MNG-2290:
-

As previously stated, the original request was created due to a lock of Maven 
knowledge. So it might have been closed long ago as INVALID.

> Generated URLs in POMs of child modules
> ---
>
> Key: MNG-2290
> URL: http://jira.codehaus.org/browse/MNG-2290
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Inheritance and Interpolation
>Affects Versions: 2.0.4
>Reporter: Joerg Schaible
> Fix For: 2.0.8
>
>
> Maven has quite some elements where a URL or a path is modified automatically 
> for child POMs (the ones I am currently aware of):
> - url
> - scm/connection
> - scm/developerConnection
> - scm/url
> - distributionManagement/site/url
> While expanding this path with "/${pom.artifactId}" sounds reasonable, this 
> approach fails badly for complex projects with more hierarchy levels. Suppose 
> we have a directory structure like:
> * project
> ** core
> *** provider
>  commons
>  impl1
> In this hierarchy all POMs for _project_, _core_ and _provider_ are of 
> package type _pom_, while _commons_ and _impl1_ is of type _jar_. The 
> "artifactId" approach now simply assumes that all POMs in the hierarchy are 
> named like the current directory. This does simply not match. Suppose those 
> jar artifacts are used in an enterprise or web app. Then every artifact is 
> located in one single directory and therefore the names have to be unique. 
> But if you decide to take an artifact name different to the directory name, 
> you have to add the definition in every POM, because the scm elements are 
> simply wrong.
> An even worse scenario are components that can be provided using different 
> technologies. We have a lot of such structures:
> * component
> ** jar
> ** war
> ** ear
> * *_jar_:* the core functionality
> * *_war_:* the core functionality integrated and eccessible with a web 
> application
> * *_ear_:* the complete component as enterprise app, if it makes sense to 
> deploy the functionality on a different app server
> _component_ has a POM of package type _pom_; _jar_, _war_ and _ear_ have POMs 
> with the according package type. All of the three POMs use the same 
> artifactId though. In this case not only the scm elements break, but also the 
> URLs for the site, since they are all the same for all three artifacts.
> All of this could have been avoided, if the expanded part is not the 
> artifactId, but the basename of the current directory. Especially for the scm 
> elements, this is IMHO the only valid assumption.
> It would already help us, if this auto-expansion could be turned off to allow 
> the definition of a single property in each POM for a correct interpolation 
> of those values, but there seems no such option ^1^. So you *have to* add 
> those elements under all circumstances into every POM.
> 1) The _tagBase_ of the release plugin does no such auto-expansion, which 
> makes it quite easy to use a property for it, that can be set individually in 
> every POM without adding any plugin configuration.

-- 
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-408) add capability to turn on only a specific provider

2007-12-13 Thread Keith Naas (JIRA)

[ 
http://jira.codehaus.org/browse/SUREFIRE-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116723
 ] 

Keith Naas commented on SUREFIRE-408:
-

BTW, this is the code in 
http://svn.apache.org/viewvc/maven/surefire/trunk/surefire-providers/surefire-testng/src/main/java/org/apache/maven/surefire/testng/TestNGDirectoryTestSuite.java?revision=598205&view=markup

Note how if there are any junitTestClasses, it sets the junit flag on the 
TestNG junitOptions.  This isn't always what we want.  

> add capability to turn on only a specific provider
> --
>
> Key: SUREFIRE-408
> URL: http://jira.codehaus.org/browse/SUREFIRE-408
> Project: Maven Surefire
>  Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Keith Naas
>Priority: Minor
>
> It would be nice if you could force the maven surefire plugin to only use a 
> specific provider.  
> Currently, it checks if a test extends junit.framework.Test.  If it is, it 
> assumes its a junit test case.  This is not always the case.  It could still 
> be a testng test.
> if (junit.framework.Test.class.isAssignableFrom( c )) {
> junitTestClasses.add( c );
> } else {
> testNgTestClasses.add( c );
> }

-- 
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-2290) Generated URLs in POMs of child modules

2007-12-13 Thread David Roussel (JIRA)

[ 
http://jira.codehaus.org/browse/MNG-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116722
 ] 

David Roussel commented on MNG-2290:


This issue is marked as fix verion = Maven 2.0.8, and so it show's up in the 
Maven 2.0.8 release notes, but actually it's just superceeded by MNG-3244, 
which is just a documentation update in 2.0.9 since the real fix was deemed not 
backward compatible.  So not only is this not fixed, but it's not in 2.0.8.

> Generated URLs in POMs of child modules
> ---
>
> Key: MNG-2290
> URL: http://jira.codehaus.org/browse/MNG-2290
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Inheritance and Interpolation
>Affects Versions: 2.0.4
>Reporter: Joerg Schaible
> Fix For: 2.0.8
>
>
> Maven has quite some elements where a URL or a path is modified automatically 
> for child POMs (the ones I am currently aware of):
> - url
> - scm/connection
> - scm/developerConnection
> - scm/url
> - distributionManagement/site/url
> While expanding this path with "/${pom.artifactId}" sounds reasonable, this 
> approach fails badly for complex projects with more hierarchy levels. Suppose 
> we have a directory structure like:
> * project
> ** core
> *** provider
>  commons
>  impl1
> In this hierarchy all POMs for _project_, _core_ and _provider_ are of 
> package type _pom_, while _commons_ and _impl1_ is of type _jar_. The 
> "artifactId" approach now simply assumes that all POMs in the hierarchy are 
> named like the current directory. This does simply not match. Suppose those 
> jar artifacts are used in an enterprise or web app. Then every artifact is 
> located in one single directory and therefore the names have to be unique. 
> But if you decide to take an artifact name different to the directory name, 
> you have to add the definition in every POM, because the scm elements are 
> simply wrong.
> An even worse scenario are components that can be provided using different 
> technologies. We have a lot of such structures:
> * component
> ** jar
> ** war
> ** ear
> * *_jar_:* the core functionality
> * *_war_:* the core functionality integrated and eccessible with a web 
> application
> * *_ear_:* the complete component as enterprise app, if it makes sense to 
> deploy the functionality on a different app server
> _component_ has a POM of package type _pom_; _jar_, _war_ and _ear_ have POMs 
> with the according package type. All of the three POMs use the same 
> artifactId though. In this case not only the scm elements break, but also the 
> URLs for the site, since they are all the same for all three artifacts.
> All of this could have been avoided, if the expanded part is not the 
> artifactId, but the basename of the current directory. Especially for the scm 
> elements, this is IMHO the only valid assumption.
> It would already help us, if this auto-expansion could be turned off to allow 
> the definition of a single property in each POM for a correct interpolation 
> of those values, but there seems no such option ^1^. So you *have to* add 
> those elements under all circumstances into every POM.
> 1) The _tagBase_ of the release plugin does no such auto-expansion, which 
> makes it quite easy to use a property for it, that can be set individually in 
> every POM without adding any plugin configuration.

-- 
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: (SUREFIRE-408) add capability to turn on only a specific provider

2007-12-13 Thread Keith Naas (JIRA)
add capability to turn on only a specific provider
--

 Key: SUREFIRE-408
 URL: http://jira.codehaus.org/browse/SUREFIRE-408
 Project: Maven Surefire
  Issue Type: Improvement
Affects Versions: 2.4
Reporter: Keith Naas
Priority: Minor


It would be nice if you could force the maven surefire plugin to only use a 
specific provider.  

Currently, it checks if a test extends junit.framework.Test.  If it is, it 
assumes its a junit test case.  This is not always the case.  It could still be 
a testng test.

if (junit.framework.Test.class.isAssignableFrom( c )) {
junitTestClasses.add( c );
} else {
testNgTestClasses.add( c );
}


-- 
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] Issue Comment Edited: (ARCHETYPE-107) maven archetype missing dependency versions breaks archetype:create

2007-12-13 Thread Kris Beaumont (JIRA)

[ 
http://jira.codehaus.org/browse/ARCHETYPE-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116700
 ] 

beaumkr edited comment on ARCHETYPE-107 at 12/13/07 8:54 AM:
---

[edit]
tried upgrading, same result: environment:

D:\struts2\multimoduletest\MyProject>mvn -version
Maven version: 2.0.8
Java version: 1.6.0_03
OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
[/edit]


I think he can't handle the SNAPSHOT default value in some archetypes.
He first says he's ignoring the value and then he says it missing and therefor 
fails to validate the POM.


below is the output on my screen (and my maven version).


[INFO] Searching repository for plugin with prefix: 'archetype'.
[WARNING] POM for 
'org.apache.maven.plugins:maven-archetype-plugin:pom:1.0-SNAPSHOT' is invalid. 
It will be ig
nored for artifact resolution. Reason: Failed to validate POM
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Error building POM (may not be this project's POM).


Project ID: org.apache.maven.plugins:maven-archetype-plugin
POM Location: Artifact 
[org.apache.maven.plugins:maven-archetype-plugin:pom:1.0-SNAPSHOT]
Validation Messages:

[0]  'dependencies.dependency.version' is missing for 
org.apache.maven.archetype:maven-archetype-creator


Reason: Failed to validate POM


[INFO] 
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Unable to build project 
information for plugin 'org.ap
ache.maven.plugins:maven-archetype-plugin': Failed to validate POM
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1274
)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java
:1522)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListByAggregationNeeds(DefaultLifecy
cleExecutor.java:386)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:138)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
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:597)
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.InvalidPluginException: Unable to build 
project information for plugin 'org
.apache.maven.plugins:maven-archetype-plugin': Failed to validate POM
at 
org.apache.maven.plugin.version.DefaultPluginVersionManager.resolveMetaVersion(DefaultPluginVersion
Manager.java:704)
at 
org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePluginVersion(DefaultPluginVersi
onManager.java:186)
at 
org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePluginVersion(DefaultPluginVersi
onManager.java:90)
at 
org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:166)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1257
)
... 14 more
Caused by: org.apache.maven.project.InvalidProjectModelException: Failed to 
validate POM
at 
org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.
java:1005)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:8
08)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.
java:236)
at 
org.apache.maven.plugin.version.DefaultPluginVersionManager.resolveMetaVersion(DefaultPluginVersion
Manager.java:698)
... 18 more
[INFO] 
[INFO] Total time: < 1 second
[INFO] Finished at: Thu Dec 13 14:55:30 CET 2007
[INFO] Final Memory: 1M/4M
[INFO] 

D:\struts2\multimoduletest\myProject>mvn -version
Maven version: 2.0.6





  was (Author: beaumkr):
I think he can't handle the SNAPSHOT default value in some archetypes.
He first says he's ignoring the 

[jira] Created: (MAVENUPLOAD-1853) Upload OpenOffice.org Java/Uno 2.3.1

2007-12-13 Thread Mirko Nasato (JIRA)
Upload OpenOffice.org Java/Uno 2.3.1


 Key: MAVENUPLOAD-1853
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1853
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Mirko Nasato


OpenOffice.org includes some JARs that can be used in a standalone Java app to 
connect to a running OpenOffice.org instance.

Please find the bundles here:

http://artofsolving.com/files/m2/juh-2.3.1-bundle.jar
http://artofsolving.com/files/m2/jurt-2.3.1-bundle.jar
http://artofsolving.com/files/m2/ridl-2.3.1-bundle.jar
http://artofsolving.com/files/m2/unoil-2.3.1-bundle.jar

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Issue Comment Edited: (MINVOKER-18) two executions of the same pom causes a prooblem with interpolated-pom.xml

2007-12-13 Thread Gerhard Langs (JIRA)

[ 
http://jira.codehaus.org/browse/MINVOKER-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116702
 ] 

gerhard6 edited comment on MINVOKER-18 at 12/13/07 8:40 AM:
-

...

  was (Author: gerhard6):
Provided a patch, which deletes the pom in the finally section

Aslo updated one of the existing tests, as the pom is not automatically 
deleted, when you only invoke buildInterpolationFromFile

Didn't add an automatic test for my testcase (=two attached pom's)
  
> two executions of the same pom causes a prooblem with interpolated-pom.xml
> --
>
> Key: MINVOKER-18
> URL: http://jira.codehaus.org/browse/MINVOKER-18
> Project: Maven 2.x Invoker Plugin
>  Issue Type: Bug
>Affects Versions: 1.1
> Environment: latest 1.1-SNAPSHOT Version, maven-2.0.7
>Reporter: Gerhard Langs
>Assignee: John Casey
> Attachments: invoker-18.patch, invoker-18.patch, 
> pom-interpolation2-invoked.xml, pom-interpolation2.xml
>
>
> TestCase:
>pom-interpolated2.xml uses invoker to invoke 
> "pom-interpolated2-invoked.xml  in 2 "executions".
> invocation:
>mvn -f pom-interpolated2.xml test -e
> the second execution fails, because it is unable to create the 
> "interpolated-pom.xml".
> Proposed solution:
>- dont tag the interpolated-pom.xml as "deleteOnExit",
>- delete that file at the end of every execution.
> Will try to provide a patch
> Greetings, Gerhard
> Output:
> ...
> Caused by: org.apache.maven.plugin.MojoExecutionException: fail to create 
> file 
> D:\maven\maven-invoker-plugin\src\test\resources\unit\interpolation2\.\interpolated-pom.xml
> at 
> org.apache.maven.plugin.invoker.InvokerMojo.buildInterpolatedPomFile(InvokerMojo.java:997)
> at 
> org.apache.maven.plugin.invoker.InvokerMojo.runBuild(InvokerMojo.java:458)
> at 
> org.apache.maven.plugin.invoker.InvokerMojo.execute(InvokerMojo.java:341)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)

-- 
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: (MINVOKER-18) two executions of the same pom causes a prooblem with interpolated-pom.xml

2007-12-13 Thread Gerhard Langs (JIRA)

 [ 
http://jira.codehaus.org/browse/MINVOKER-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Langs updated MINVOKER-18:
--

Attachment: invoker-18.patch

Provided a patch, which deletes the pom in the finally section

Aslo updated one of the existing tests, as the pom is not automatically 
deleted, when you only invoke buildInterpolationFromFile

Didn't add an automatic test for my testcase (=two attached pom's)

> two executions of the same pom causes a prooblem with interpolated-pom.xml
> --
>
> Key: MINVOKER-18
> URL: http://jira.codehaus.org/browse/MINVOKER-18
> Project: Maven 2.x Invoker Plugin
>  Issue Type: Bug
>Affects Versions: 1.1
> Environment: latest 1.1-SNAPSHOT Version, maven-2.0.7
>Reporter: Gerhard Langs
>Assignee: John Casey
> Attachments: invoker-18.patch, invoker-18.patch, 
> pom-interpolation2-invoked.xml, pom-interpolation2.xml
>
>
> TestCase:
>pom-interpolated2.xml uses invoker to invoke 
> "pom-interpolated2-invoked.xml  in 2 "executions".
> invocation:
>mvn -f pom-interpolated2.xml test -e
> the second execution fails, because it is unable to create the 
> "interpolated-pom.xml".
> Proposed solution:
>- dont tag the interpolated-pom.xml as "deleteOnExit",
>- delete that file at the end of every execution.
> Will try to provide a patch
> Greetings, Gerhard
> Output:
> ...
> Caused by: org.apache.maven.plugin.MojoExecutionException: fail to create 
> file 
> D:\maven\maven-invoker-plugin\src\test\resources\unit\interpolation2\.\interpolated-pom.xml
> at 
> org.apache.maven.plugin.invoker.InvokerMojo.buildInterpolatedPomFile(InvokerMojo.java:997)
> at 
> org.apache.maven.plugin.invoker.InvokerMojo.runBuild(InvokerMojo.java:458)
> at 
> org.apache.maven.plugin.invoker.InvokerMojo.execute(InvokerMojo.java:341)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)

-- 
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: (MINVOKER-18) two executions of the same pom causes a prooblem with interpolated-pom.xml

2007-12-13 Thread Gerhard Langs (JIRA)

 [ 
http://jira.codehaus.org/browse/MINVOKER-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Langs updated MINVOKER-18:
--

Attachment: invoker-18.patch

Provided a patch, which deletes the pom in the finally section

Aslo updated one of the existing tests, as the pom is not automatically 
deleted, when you only invoke buildInterpolationFromFile

Didn't add an automatic test for my testcase (=two attached pom's)

> two executions of the same pom causes a prooblem with interpolated-pom.xml
> --
>
> Key: MINVOKER-18
> URL: http://jira.codehaus.org/browse/MINVOKER-18
> Project: Maven 2.x Invoker Plugin
>  Issue Type: Bug
>Affects Versions: 1.1
> Environment: latest 1.1-SNAPSHOT Version, maven-2.0.7
>Reporter: Gerhard Langs
>Assignee: John Casey
> Attachments: invoker-18.patch, invoker-18.patch, 
> pom-interpolation2-invoked.xml, pom-interpolation2.xml
>
>
> TestCase:
>pom-interpolated2.xml uses invoker to invoke 
> "pom-interpolated2-invoked.xml  in 2 "executions".
> invocation:
>mvn -f pom-interpolated2.xml test -e
> the second execution fails, because it is unable to create the 
> "interpolated-pom.xml".
> Proposed solution:
>- dont tag the interpolated-pom.xml as "deleteOnExit",
>- delete that file at the end of every execution.
> Will try to provide a patch
> Greetings, Gerhard
> Output:
> ...
> Caused by: org.apache.maven.plugin.MojoExecutionException: fail to create 
> file 
> D:\maven\maven-invoker-plugin\src\test\resources\unit\interpolation2\.\interpolated-pom.xml
> at 
> org.apache.maven.plugin.invoker.InvokerMojo.buildInterpolatedPomFile(InvokerMojo.java:997)
> at 
> org.apache.maven.plugin.invoker.InvokerMojo.runBuild(InvokerMojo.java:458)
> at 
> org.apache.maven.plugin.invoker.InvokerMojo.execute(InvokerMojo.java:341)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (ARCHETYPE-107) maven archetype missing dependency versions breaks archetype:create

2007-12-13 Thread Kris Beaumont (JIRA)

[ 
http://jira.codehaus.org/browse/ARCHETYPE-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116700
 ] 

Kris Beaumont commented on ARCHETYPE-107:
-

I think he can't handle the SNAPSHOT default value in some archetypes.
He first says he's ignoring the value and then he says it missing and therefor 
fails to validate the POM.


below is the output on my screen (and my maven version).


[INFO] Searching repository for plugin with prefix: 'archetype'.
[WARNING] POM for 
'org.apache.maven.plugins:maven-archetype-plugin:pom:1.0-SNAPSHOT' is invalid. 
It will be ig
nored for artifact resolution. Reason: Failed to validate POM
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Error building POM (may not be this project's POM).


Project ID: org.apache.maven.plugins:maven-archetype-plugin
POM Location: Artifact 
[org.apache.maven.plugins:maven-archetype-plugin:pom:1.0-SNAPSHOT]
Validation Messages:

[0]  'dependencies.dependency.version' is missing for 
org.apache.maven.archetype:maven-archetype-creator


Reason: Failed to validate POM


[INFO] 
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Unable to build project 
information for plugin 'org.ap
ache.maven.plugins:maven-archetype-plugin': Failed to validate POM
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1274
)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java
:1522)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListByAggregationNeeds(DefaultLifecy
cleExecutor.java:386)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:138)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
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:597)
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.InvalidPluginException: Unable to build 
project information for plugin 'org
.apache.maven.plugins:maven-archetype-plugin': Failed to validate POM
at 
org.apache.maven.plugin.version.DefaultPluginVersionManager.resolveMetaVersion(DefaultPluginVersion
Manager.java:704)
at 
org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePluginVersion(DefaultPluginVersi
onManager.java:186)
at 
org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePluginVersion(DefaultPluginVersi
onManager.java:90)
at 
org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:166)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1257
)
... 14 more
Caused by: org.apache.maven.project.InvalidProjectModelException: Failed to 
validate POM
at 
org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.
java:1005)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:8
08)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.
java:236)
at 
org.apache.maven.plugin.version.DefaultPluginVersionManager.resolveMetaVersion(DefaultPluginVersion
Manager.java:698)
... 18 more
[INFO] 
[INFO] Total time: < 1 second
[INFO] Finished at: Thu Dec 13 14:55:30 CET 2007
[INFO] Final Memory: 1M/4M
[INFO] 

D:\struts2\multimoduletest\myProject>mvn -version
Maven version: 2.0.6





> maven archetype missing dependency versions breaks archetype:create 
> 
>
> Key: ARCHETYPE-107
> URL: http://jira.codehaus.org/browse/ARCHETYPE-107
> Project: Maven Archetype
>  Issue Type: Bug
>  Components: Archetypes
> Environment: linux 2.6 (Xubuntu)
> 

[jira] Created: (MINVOKER-19) two executions of the same pom causes a prooblem with interpolated-pom.xml

2007-12-13 Thread Gerhard Langs (JIRA)
two executions of the same pom causes a prooblem with interpolated-pom.xml
--

 Key: MINVOKER-19
 URL: http://jira.codehaus.org/browse/MINVOKER-19
 Project: Maven 2.x Invoker Plugin
  Issue Type: Bug
Affects Versions: 1.1
 Environment: latest 1.1-SNAPSHOT Version, maven-2.0.7
Reporter: Gerhard Langs
Assignee: John Casey
 Attachments: pom-interpolation2-invoked.xml, pom-interpolation2.xml

TestCase:
   pom-interpolated2.xml uses invoker to invoke "pom-interpolated2-invoked.xml  
in 2 "executions".

invocation:
   mvn -f pom-interpolated2.xml test -e


the second execution fails, because it is unable to create the 
"interpolated-pom.xml".


Proposed solution:
   - dont tag the interpolated-pom.xml as "deleteOnExit",
   - delete that file at the end of every execution.

Will try to provide a patch

Greetings, Gerhard


Output:
...
Caused by: org.apache.maven.plugin.MojoExecutionException: fail to create file 
D:\maven\maven-invoker-plugin\src\test\resources\unit\interpolation2\.\interpolated-pom.xml
at 
org.apache.maven.plugin.invoker.InvokerMojo.buildInterpolatedPomFile(InvokerMojo.java:997)
at 
org.apache.maven.plugin.invoker.InvokerMojo.runBuild(InvokerMojo.java:458)
at 
org.apache.maven.plugin.invoker.InvokerMojo.execute(InvokerMojo.java:341)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)

-- 
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: (MINVOKER-19) two executions of the same pom causes a prooblem with interpolated-pom.xml

2007-12-13 Thread Gerhard Langs (JIRA)

 [ 
http://jira.codehaus.org/browse/MINVOKER-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Langs closed MINVOKER-19.
-

Resolution: Duplicate

My browser still creates duplicates :-

> two executions of the same pom causes a prooblem with interpolated-pom.xml
> --
>
> Key: MINVOKER-19
> URL: http://jira.codehaus.org/browse/MINVOKER-19
> Project: Maven 2.x Invoker Plugin
>  Issue Type: Bug
>Affects Versions: 1.1
> Environment: latest 1.1-SNAPSHOT Version, maven-2.0.7
>Reporter: Gerhard Langs
>Assignee: John Casey
> Attachments: pom-interpolation2-invoked.xml, pom-interpolation2.xml
>
>
> TestCase:
>pom-interpolated2.xml uses invoker to invoke 
> "pom-interpolated2-invoked.xml  in 2 "executions".
> invocation:
>mvn -f pom-interpolated2.xml test -e
> the second execution fails, because it is unable to create the 
> "interpolated-pom.xml".
> Proposed solution:
>- dont tag the interpolated-pom.xml as "deleteOnExit",
>- delete that file at the end of every execution.
> Will try to provide a patch
> Greetings, Gerhard
> Output:
> ...
> Caused by: org.apache.maven.plugin.MojoExecutionException: fail to create 
> file 
> D:\maven\maven-invoker-plugin\src\test\resources\unit\interpolation2\.\interpolated-pom.xml
> at 
> org.apache.maven.plugin.invoker.InvokerMojo.buildInterpolatedPomFile(InvokerMojo.java:997)
> at 
> org.apache.maven.plugin.invoker.InvokerMojo.runBuild(InvokerMojo.java:458)
> at 
> org.apache.maven.plugin.invoker.InvokerMojo.execute(InvokerMojo.java:341)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)

-- 
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: (MECLIPSE-101) Replace the integration tests in eclipse plugin with the test harness

2007-12-13 Thread nicolas de loof (JIRA)

 [ 
http://jira.codehaus.org/browse/MECLIPSE-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

nicolas de loof updated MECLIPSE-101:
-

Attachment: test.patch

A proof of concept on using shitty for IT tests

> Replace the integration tests in eclipse plugin with the test harness
> -
>
> Key: MECLIPSE-101
> URL: http://jira.codehaus.org/browse/MECLIPSE-101
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Test
>Reporter: Edwin Punzalan
>Assignee: Edwin Punzalan
> Attachments: test.patch
>
>


-- 
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: (MINVOKER-18) two executions of the same pom causes a prooblem with interpolated-pom.xml

2007-12-13 Thread Gerhard Langs (JIRA)
two executions of the same pom causes a prooblem with interpolated-pom.xml
--

 Key: MINVOKER-18
 URL: http://jira.codehaus.org/browse/MINVOKER-18
 Project: Maven 2.x Invoker Plugin
  Issue Type: Bug
Affects Versions: 1.1
 Environment: latest 1.1-SNAPSHOT Version, maven-2.0.7
Reporter: Gerhard Langs
Assignee: John Casey
 Attachments: pom-interpolation2-invoked.xml, pom-interpolation2.xml

TestCase:
   pom-interpolated2.xml uses invoker to invoke "pom-interpolated2-invoked.xml  
in 2 "executions".

invocation:
   mvn -f pom-interpolated2.xml test -e


the second execution fails, because it is unable to create the 
"interpolated-pom.xml".


Proposed solution:
   - dont tag the interpolated-pom.xml as "deleteOnExit",
   - delete that file at the end of every execution.

Will try to provide a patch

Greetings, Gerhard


Output:
...
Caused by: org.apache.maven.plugin.MojoExecutionException: fail to create file 
D:\maven\maven-invoker-plugin\src\test\resources\unit\interpolation2\.\interpolated-pom.xml
at 
org.apache.maven.plugin.invoker.InvokerMojo.buildInterpolatedPomFile(InvokerMojo.java:997)
at 
org.apache.maven.plugin.invoker.InvokerMojo.runBuild(InvokerMojo.java:458)
at 
org.apache.maven.plugin.invoker.InvokerMojo.execute(InvokerMojo.java:341)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (SCM-182) git provider

2007-12-13 Thread mark struberg (JIRA)

[ 
http://jira.codehaus.org/browse/SCM-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116690
 ] 

mark struberg commented on SCM-182:
---

Hi!

Please also take a look at my implementation

web-git at http://ns1.backwork.net/git/
or
git-clone http://ns1.backwork.net/git/maven-scm-providers-git.git

It is very similar to the existing scm providers like SVN and CVS, so it is 
split in git-commons, gittest and gitexe submodules. It also can be extended by 
a gitjava module using egit very easily in the future.

It includes and successfully passes TCK tests and has been tested on Linux 
using git 1.5.3.3 and 1.5.3.4.

> git provider
> 
>
> Key: SCM-182
> URL: http://jira.codehaus.org/browse/SCM-182
> Project: Maven SCM
>  Issue Type: New Feature
>  Components: maven-scm-provider-git
> Environment: Developed on Mac OS X 10.3.9 with git 1.2.4
>Reporter: Dominik Winter
> Fix For: future
>
> Attachments: git.patch, git.tar.bz2, SCM-182.patch, update1.patch.bz2
>
>
> Please find the git provider as attachment.
> Usefulness:
> I used the git provider together with 
> [http://maven.apache.org/plugins/maven-release-plugin|maven-release-plugin], 
> it works fine for that use case.
> Open issues:
> - the JUnit tests are "proprietary", not yet TCK. I'll fix that.
> If you want to run the tests, you must have git installed and it must be in 
> your {{PATH}}.
> To run git:
> - on *Windows*: use [Cygwin|http://www.cygwin.com] and install the binutils, 
> openssh, openssl, rsync, curl
> than you are able to compile and install git
> - on Linux: there are packages somewhere
> - on Mac OS X: use the [DarwinPorts|http://www.darwinports.org/]

-- 
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: (MECLIPSE-101) Replace the integration tests in eclipse plugin with the test harness

2007-12-13 Thread nicolas de loof (JIRA)

[ 
http://jira.codehaus.org/browse/MECLIPSE-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116688
 ] 

nicolas de loof commented on MECLIPSE-101:
--

I tried to migrate project-01 test to use test-harness. Seems to be difficult 
as the plugin requires many maven components, for example a project with an 
ArtifactHandler. maven-plugin-testing-harness ArtifactStub nas no support for 
such an ArtifactHandler.

Why no use the SHITTY maven plugin 
(http://mojo.codehaus.org/shitty-maven-plugin/usage.html) ?
I myself used it on javascript-maven-tools and it is really simple to setup.

> Replace the integration tests in eclipse plugin with the test harness
> -
>
> Key: MECLIPSE-101
> URL: http://jira.codehaus.org/browse/MECLIPSE-101
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Test
>Reporter: Edwin Punzalan
>Assignee: Edwin Punzalan
>


-- 
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-594) add some minimal hook in LegacyPathParser to allow exception management in artifact resolution

2007-12-13 Thread nicolas de loof (JIRA)

 [ 
http://jira.codehaus.org/browse/MRM-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

nicolas de loof closed MRM-594.
---

  Assignee: nicolas de loof
Resolution: Fixed

New element in archivaConfiguration
PathParsers converted to plexus components, to acces the configuration
Web UI to manage custom path->artifactReference
Server-side check for consistency : path->artifactReference->path must be equals
client side scripts to avoid typos

> add some minimal hook in LegacyPathParser to allow exception management in 
> artifact resolution
> --
>
> Key: MRM-594
> URL: http://jira.codehaus.org/browse/MRM-594
> Project: Archiva
>  Issue Type: Improvement
>  Components: repository interface
>Affects Versions: 1.0-beta-4
>Reporter: nicolas de loof
>Assignee: nicolas de loof
> Fix For: 1.0.1
>
> Attachments: MRM-594-with-web-ui.patch, MRM-594.patch
>
>
> Some existing artifacts are not available to maven1. jaxen-1.0-FCS-full for 
> example (use by some core maven1 plugins) can only be obtained by specifying 
> a classifier "full". 
> The maven1 request "/jaxen/jars/jaxen-1.0-FCS-full.jar" is converted as 
> artifact [ jaxen : jaxen : 1.0-FCS-full ], that doesn't exist.
> The LegacyPathParser is allready very complex and works for many artifact, 
> but cannot handle classifiers as they can be any string.
> A solution to help archiva managers should be to use an resolution exception 
> list :
> if ( exceptions.contains( path ) )
> {
> String exception = exceptions.getProperty( path );
> String[] ref = exception.split( ":" );
> artifact.setGroupId( ref[0] );
> artifact.setArtifactId( ref[1] );
> artifact.setVersion( ref[2] );
> if ( ref.length > 3 )
> {
> artifact.setClassifier( ref[3] );
> }
> return artifact;
> }
> based on a simple properties file :
> jaxen/jars/jaxen-1.0-FCS-full.jar = jaxen:jaxen:1.0-FCS:full
> This would allow admins to quickly fix such issues and not require archiva to 
> find a way to make legacy path deterministic.

-- 
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-1852) JasperReports 2.0.3 upload

2007-12-13 Thread Teodor Danciu (JIRA)
JasperReports 2.0.3 upload
--

 Key: MAVENUPLOAD-1852
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1852
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Teodor Danciu


http://jasperreports.sf.net/maven/jasperreports-2.0.3-bundle.jar

http://sourceforge.net/projects/jasperreports
http://sourceforge.net/project/memberlist.php?group_id=36382

Open Source Reporting Engine


-- 
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: (MECLIPSE-323) eclipse:clean does NOT delete 'additionalConfig' files

2007-12-13 Thread nicolas de loof (JIRA)

 [ 
http://jira.codehaus.org/browse/MECLIPSE-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

nicolas de loof closed MECLIPSE-323.


 Assignee: nicolas de loof
   Resolution: Fixed
Fix Version/s: 2.5

> eclipse:clean does NOT delete 'additionalConfig' files
> --
>
> Key: MECLIPSE-323
> URL: http://jira.codehaus.org/browse/MECLIPSE-323
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Bug
>Reporter: Jörg Hohwiller
>Assignee: nicolas de loof
> Fix For: 2.5
>
>
> I use the eclipse-plugin to generate additional configs for eclipse-plugins:
> ...
>   
>  org.apache.maven.plugins
>  maven-eclipse-plugin
>  
>
>  
>.checkstyle
>
>  
> 
>  
>   
> The file is properly created. Anyhow eclipse:clean does NOT delete such files.
> Therefore it is NOT possible to simply reconfigure your IDE to the defaults 
> via 'mvn eclipse:clean eclipse:eclipse'.
> I would expect eclipse:clean to delete the configurations that 
> eclipse:eclipse generated.

-- 
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: (NMAVEN-98) Dotnet simple archetype does not include unit tests

2007-12-13 Thread Shane Isbell (JIRA)

[ 
http://jira.codehaus.org/browse/NMAVEN-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116676
 ] 

Shane Isbell commented on NMAVEN-98:


I missed an svn add. I just check it in.

> Dotnet simple archetype does not include unit tests
> ---
>
> Key: NMAVEN-98
> URL: http://jira.codehaus.org/browse/NMAVEN-98
> Project: NMaven
>  Issue Type: Improvement
>Reporter: Teodoro Cue Jr.
> Attachments: NMAVEN-98.patch
>
>
> Building a project created from the dotnet-simple archetype produces:
> [INFO] [compile:testCompile]
> [INFO] NMAVEN-066-013: Found Vendor = Vendor = MICROSOFT, Vendor Version = 
> 2.0.5
> 0727, Framework Version = 2.0.50727, Executable Paths = 
> [C:\WINDOWS\Microsoft.NE
> T\Framework\v2.0.50727]
> [INFO] NMAVEN-068-002: No source files to compile.
> [INFO] Mojo Execution Time = 0
> [INFO] [test:test]
> [INFO] NMAVEN-1100-001: No Unit Tests
> The dotnet-simple archetype should include an NUnit test case.

-- 
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: (MCHANGES-88) NoSuchMethodError with maven 2.0.8 when generating changes-report

2007-12-13 Thread Julien Graglia (JIRA)
NoSuchMethodError with maven 2.0.8 when generating changes-report
-

 Key: MCHANGES-88
 URL: http://jira.codehaus.org/browse/MCHANGES-88
 Project: Maven 2.x Changes Plugin
  Issue Type: Bug
  Components: changes-report
Affects Versions: 2.0-beta-3
 Environment: [EMAIL PROTECTED]:/opt/nc/workspace/test_maven$ mvn 
-version
Maven version: 2.0.8
Java version: 1.6.0_03
OS name: "linux" version: "2.6.18-5-686" arch: "i386" Family: "unix"

Reporter: Julien Graglia
 Attachments: error.log, pom.xml

I create a simple maven2 project, but when i call
mvn -X -e changes:changes-report

I get an error (full log in attachment)

java.lang.NoSuchMethodError: 
org.apache.maven.doxia.siterenderer.Renderer.createSink(Ljava/io/File;Ljava/lang/String;)Lorg/apache/maven/doxia/siterenderer/sink/SiteRendererSink;
at 
org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:63)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)


-- 
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: (MASSEMBLY-257) OutOfMemoryError when assembling large binary file

2007-12-13 Thread Jelte van der Hoek (JIRA)
OutOfMemoryError when assembling large binary file
--

 Key: MASSEMBLY-257
 URL: http://jira.codehaus.org/browse/MASSEMBLY-257
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-1
Reporter: Jelte van der Hoek
 Attachments: fileitem-oome.patch

The assembly phase reads all files into a single String, irrespective of 
whether they need filtering or not.
This makes it unable to handle large binary files in an assembly.

The quick fix for this is to not read the file at all if there is no 
'lineEnding' nor 'filtered' option set.
(The long fix would be to not read the file that way)

Patch against 2.2-beta-1 attached (most of the patch changes .

-- 
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