[jira] Closed: (MNGECLIPSE-187) Clear maven markers when Maven nature is disabled
[ http://jira.codehaus.org/browse/MNGECLIPSE-187?page=all ] Eugene Kuleshov closed MNGECLIPSE-187. -- Resolution: Fixed Fix Version/s: 0.0.10 > Clear maven markers when Maven nature is disabled > - > > Key: MNGECLIPSE-187 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-187 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug > Components: Dependency Resolver >Affects Versions: 0.0.9 >Reporter: Eugene Kuleshov > Assigned To: Eugene Kuleshov > Fix For: 0.0.10 > > -- 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-185) bug with dependencyManagement section in a parent pom
[ http://jira.codehaus.org/browse/MNGECLIPSE-185?page=comments#action_73363 ] Eugene Kuleshov commented on MNGECLIPSE-185: Please clarify if you have single Eclipse project or multiple and provide step by step instructions what exactly you are trying to do here. Also note, that dependency management has been greatly improved in 0.0.10 (unreleased yet). So, I just need to verify your use case. > bug with dependencyManagement section in a parent pom > - > > Key: MNGECLIPSE-185 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-185 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug >Affects Versions: 0.0.9 > Environment: maven 2.0.4 on Windows with eclipse 3.1 >Reporter: Nicolas Cazottes > Assigned To: Eugene Kuleshov > Attachments: projects.zip > > > I have also an issue related to dependencyManagement section in parent pom > with m2eclipse plugin on windows. > I have attached the projects that show the problem : when a project (projectD > in my example) is defined with a dependencyManagement section in the parent > pom in order to allow other projects to define its version (projectC in my > example), the build in eclipse with a clean on the project (calling the > install goal) fails when creating the jar. > The trace is the following : > org.apache.maven.lifecycle.LifecycleExecutionException: Error assembling JAR > ... > ... 8 more > Caused by: java.lang.NullPointerException > at > org.apache.maven.artifact.ArtifactUtils.copyArtifact(ArtifactUtils.java:109) > ... -- 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-190) Unable to enable Maven2 plugin for existing not maven2 project
[ http://jira.codehaus.org/browse/MNGECLIPSE-190?page=all ] Eugene Kuleshov updated MNGECLIPSE-190: --- Affects Version/s: (was: 0.0.10) > Unable to enable Maven2 plugin for existing not maven2 project > -- > > Key: MNGECLIPSE-190 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-190 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug > Components: Wizards > Environment: WinXP, Eclipse 3.2 >Reporter: Marek Bieganski > Assigned To: Eugene Kuleshov > Fix For: 0.0.10 > > Attachments: UnableToEnable.PNG > > > Steps: > 1. Create new Java project, enter name e.g. "lib" > 2. Right click on it, select Maven2->Enable > 3. Cannot do anything on this window > In 0.0.9 it was it worked 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] Closed: (MNGECLIPSE-190) Unable to enable Maven2 plugin for existing not maven2 project
[ http://jira.codehaus.org/browse/MNGECLIPSE-190?page=all ] Eugene Kuleshov closed MNGECLIPSE-190. -- Resolution: Fixed Fix Version/s: 0.0.10 > Unable to enable Maven2 plugin for existing not maven2 project > -- > > Key: MNGECLIPSE-190 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-190 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug > Components: Wizards > Environment: WinXP, Eclipse 3.2 >Reporter: Marek Bieganski > Assigned To: Eugene Kuleshov > Fix For: 0.0.10 > > Attachments: UnableToEnable.PNG > > > Steps: > 1. Create new Java project, enter name e.g. "lib" > 2. Right click on it, select Maven2->Enable > 3. Cannot do anything on this window > In 0.0.9 it was it worked 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] Closed: (CONTINUUM-819) project.getWorkingDirectory is null
[ http://jira.codehaus.org/browse/CONTINUUM-819?page=all ] Jesse McConnell closed CONTINUUM-819. - Resolution: Fixed applied to trunk, thanks! > project.getWorkingDirectory is null > --- > > Key: CONTINUUM-819 > URL: http://jira.codehaus.org/browse/CONTINUUM-819 > Project: Continuum > Issue Type: Bug > Components: Core system >Affects Versions: 1.1 >Reporter: Edwin Punzalan > Assigned To: Jesse McConnell > Attachments: CONTINUUM-819-continuum-core.patch > > > inside an action class' execute method, > continuum.getProject().getWorkingDirectory returns null -- 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: (CONTINUUM-309) add junit results report to website, failures to email
[ http://jira.codehaus.org/browse/CONTINUUM-309?page=all ] Jesse McConnell closed CONTINUUM-309. - Resolution: Fixed applied to trunk, thanks! > add junit results report to website, failures to email > -- > > Key: CONTINUUM-309 > URL: http://jira.codehaus.org/browse/CONTINUUM-309 > Project: Continuum > Issue Type: New Feature >Reporter: Brett Porter > Assigned To: Edwin Punzalan > Fix For: 1.1 > > Attachments: CONTINUUM-309-continuum-webapp.patch, > CONTINUUM-309-sample.GIF, continuum-api.diff, continuum-core.diff, > continuum-model.diff, continuum-web.diff > > -- 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-159) should not respond with a 404 if proxying a file results in a remote error
should not respond with a 404 if proxying a file results in a remote error -- Key: MRM-159 URL: http://jira.codehaus.org/browse/MRM-159 Project: Archiva Issue Type: Bug Components: remote proxy Reporter: Brett Porter if any repository returns success, return success otherwise, if any repository returns in error, return a generic error (500), saying to check the logs. -- 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-158) automatically index proxied artifacts
automatically index proxied artifacts - Key: MRM-158 URL: http://jira.codehaus.org/browse/MRM-158 Project: Archiva Issue Type: Improvement Components: indexing, remote proxy Reporter: Brett Porter currently the proxied artifacts will only be indexed when the indexer is next run. We should automatically index them, but some care needs to be taken: - make sure the indexer is thread safe and won't regularly fail with a failed lock - find the best way to hook this up by design (need to separate proxied artifacts from proxied files as this is internal to the proxy code, and don't want the indexer into the proxy code but rather in the core). -- 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: (CONTINUUM-828) Project group error adding project
[ http://jira.codehaus.org/browse/CONTINUUM-828?page=all ] Jesse McConnell closed CONTINUUM-828. - Resolution: Fixed fixed on trunk, 437054 > Project group error adding project > -- > > Key: CONTINUUM-828 > URL: http://jira.codehaus.org/browse/CONTINUUM-828 > Project: Continuum > Issue Type: Bug > Components: Core system >Affects Versions: 1.1 > Environment: acegi branch >Reporter: Carlos Sanchez > Assigned To: Jesse McConnell > Fix For: 1.1 > > > I got this exception trying to add maven skins pom > http://svn.apache.org/viewvc/maven/skins/trunk/pom.xml?view=co > [INFO] 0 errors. > [INFO] Creating project group with the group id: 'org.apache.maven.skins'. > 16:35:13,562 WARN JPOX.RDBMS.SQL > [org.jpox.store.rdbms.request.FetchRequest] Object with id "0" not found ! > [INFO] Error ocurred during execution > org.apache.maven.continuum.ContinuumException: Unable to find the requested > project > at > org.apache.maven.continuum.DefaultContinuum.getProjectsInGroup_aroundBody196(DefaultContinuum.java:2473) > at > org.apache.maven.continuum.DefaultContinuum$AjcClosure197.run(DefaultContinuum.java:1) > at > org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect.ajc$around$org_codehaus_plexus_acegi_intercept_method_aspectj_SecurityAspect$1$6563cc0cproceed(SecurityAspect.aj) > at > org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect$1.proceedWithObject(SecurityAspect.aj:59) > at > org.acegisecurity.intercept.method.aspectj.AspectJSecurityInterceptor.invoke(AspectJSecurityInterceptor.java:67) > at > org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect.ajc$around$org_codehaus_plexus_acegi_intercept_method_aspectj_SecurityAspect$1$6563cc0c(SecurityAspect.aj:62) > at > org.apache.maven.continuum.DefaultContinuum.getProjectsInGroup(DefaultContinuum.java:1) > at > org.apache.maven.continuum.web.action.SummaryAction.execute(SummaryAction.java:55) > 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 > com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:365) > at > com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:217) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:191) > at > com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:137) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:81) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) > at > com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:81) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) > at > com.opensymphony.webwork.interceptor.FileUploadInterceptor.intercept(FileUploadInterceptor.java:171) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) >
[jira] Created: (MNGECLIPSE-191) support inplace webapp deployment
support inplace webapp deployment - Key: MNGECLIPSE-191 URL: http://jira.codehaus.org/browse/MNGECLIPSE-191 Project: Maven 2.x Extension for Eclipse Issue Type: Improvement Reporter: Mike McMahon Assigned To: Eugene Kuleshov Priority: Minor Attachments: inplace.patch Currently, maven-built webapp projects (with or without m2eclipse) are difficult to debug efficiently using Eclipse. My definition of "efficient" debugging of a webapp (using Tomcat for example) is: - HTML and JSP pages immediately seen upon edit/save then browser refresh/F5 - Java class changes are HotSwapped into the running JVM, stack is rewound - Java class changes are immediately placed into Tomcat WEB-INF/classes My recommended approach is that m2eclipse should make a .classpath which enables the Eclipse builder (org.eclipse.jdt.core.javabuilder) to fully assemble an "exploded war" deployment of the webapp. An example classpath is as follows: A more complex case (multi-module build having multiple source trees) would work by assembling ALL of the classes and resources into a single webapp location. This approach diverges from the current m2eclipse philosophy of having the Eclipse build "mirror" the maven build. I dont see much actual value in synchronizing these 2 independent builds, especially when so much productivity is gained by using the Eclipse build for inplace webapp purposes. Patch attached -- 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: (MPMULTIPROJECT-70) Multiproject plugin not using dependencies when maven.jar.override = on
Multiproject plugin not using dependencies when maven.jar.override = on --- Key: MPMULTIPROJECT-70 URL: http://jira.codehaus.org/browse/MPMULTIPROJECT-70 Project: maven-multiproject-plugin Issue Type: Bug Environment: Windows 2000 Professional. Maven 1.1. Beta 3. Reporter: Matthew Purland Attachments: jira.zip When using the multiproject plugin with a project with multiple projects, dependencies defined in projectbase.xml, and all projects that have a project.xml file extend from projectbase.xml. If maven.jar.override = on is specified and the correct overridden jar artifactId is present then when running the test goal for a project from within multiproject, dependencies are given to unit tests that are run. Please see attached zip file for more detailed information. When using attached file, please place the contents of "local_repo" into your local repository for a successful test run/workaround to provide proof of working vs. nonworking. The only workaround I've found is to take the jars that are depended upon and place them into the local repository and depend on them as regular dependencies and take out maven.jar.override. However, this doesn't necessarily solve the problem that if you have a vendor jar that you can't place in ibiblio or a remote repository without setting up a maven repository server such as proximity or continuum. I will try to provide a test in the future. -- 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-2503) mvn.bat file is not correct for 4NT 5.0 and does "endlocal" twice if error
[ http://jira.codehaus.org/browse/MNG-2503?page=comments#action_73347 ] Vincent Siveton commented on MNG-2503: -- I tried to reproduce your problem with the last version of 4nt without success, ie 4NT 7.01 (4nt.exe, 3.2Mb, build 370) [1] Try to upgrade your 4nt version. I'd like a confirmation before I close this issue. Another tips for the next time, please refer to [2], "Creating and submitting a patch" part Thanks! [1] http://jpsoft.com/download.htm [2] http://maven.apache.org/guides/development/guide-m2-development.html > mvn.bat file is not correct for 4NT 5.0 and does "endlocal" twice if error > -- > > Key: MNG-2503 > URL: http://jira.codehaus.org/browse/MNG-2503 > Project: Maven 2 > Issue Type: Bug > Components: Command Line >Affects Versions: 2.0.4 > Environment: Windows XP SP2 and 4NT 5.00U >Reporter: Mark DeLaFranier >Priority: Minor > Attachments: mvn.bat > > > 1. If not setup properly and error occurs, the script attempts to "endlocal" > twice: > [d:\] > mvn --version > Exception in thread "main" java.lang.NoClassDefFoundError: > org/codehaus/classworlds/Launcher > 4NT: D:\dev\maven2\bin\mvn.bat [145] Missing SETLOCAL > 2. Syntax wrong for adding CLASSWORLDS_JAR when under 4NT. > For #1, I updated the :error section of the mvn.bat file. > For #2, I added a new section to add the CLASSWORLDS_JAR -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSUREFIRE-159) Surefire should provide a pluggable means to specify a custom provider
Surefire should provide a pluggable means to specify a custom provider -- Key: MSUREFIRE-159 URL: http://jira.codehaus.org/browse/MSUREFIRE-159 Project: Maven 2.x Surefire Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Micah Whitacre The current way that surefire determines which provider to use is hard coded and based on a project's dependencies. I would like to write a custom surefire-provider and be able to specify to use that provider without having to patch the surefire plugin. In my case I want to write a surefire-provider that will run Eclipse PDE Junits which wouldn't neccessarily have a specific dependency listed -- 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-2520) build error while: mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-s
[ http://jira.codehaus.org/browse/MNG-2520?page=all ]
Vincent Siveton closed MNG-2520.
Assignee: Vincent Siveton
Resolution: Won't Fix
I suspect that you have already a pom.xml with jar packaging in the directory
where you called mvn.
To be clear, you had and did:
{noformat}
C:\maven-2.0.4\try\my-app>pom.xml with jar
C:\maven-2.0.4\try\my-app>mvn archetype:create ...
=> Embedded error: Unable to add module to the current project as it is not of
packaging type 'pom'
{noformat}
Feel free to reopen it if it doesn't work on a fresh directory.
> build error while: mvn archetype:create -DgroupId=com.mycompany.app
> -DartifactId=my-app -DarchetypeGroupId=org.apache.maven.archetypes
> -DarchetypeArtifactId=maven-archetype-site
> -
>
> Key: MNG-2520
> URL: http://jira.codehaus.org/browse/MNG-2520
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.4
> Environment: Getting started tutorial
> http://maven.apache.org/guides/getting-started/index.html
>Reporter: Radu Marian
> Assigned To: Vincent Siveton
>
> C:\maven-2.0.4\try\my-app>mvn archetype:create -DgroupId=com.mycompany.app
> -Dart
> ifactId=my-app -DarchetypeGroupId=org.apache.maven.archetypes
> -DarchetypeArtifac
> tId=maven-archetype-site
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'archetype'.
> [INFO]
> -
> ---
> [INFO] Building Maven Quick Start Archetype
> [INFO]task-segment: [archetype:create] (aggregator-style)
> [INFO]
> -
> ---
> [INFO] Setting property: classpath.resource.loader.class =>
> 'org.codehaus.plexus
> .velocity.ContextClassLoaderResourceLoader'.
> [INFO] Setting property: velocimacro.messages.on => 'false'.
> [INFO] Setting property: resource.loader => 'classpath'.
> [INFO] Setting property: resource.manager.logwhenfound => 'false'.
> [INFO] **
> [INFO] Starting Jakarta Velocity v1.4
> [INFO] RuntimeInstance initializing.
> [INFO] Default Properties File:
> org\apache\velocity\runtime\defaults\velocity.pr
> operties
> [INFO] Default ResourceManager initializing. (class
> org.apache.velocity.runtime.
> resource.ResourceManagerImpl)
> [INFO] Resource Loader Instantiated:
> org.codehaus.plexus.velocity.ContextClassLo
> aderResourceLoader
> [INFO] ClasspathResourceLoader : initialization starting.
> [INFO] ClasspathResourceLoader : initialization complete.
> [INFO] ResourceCache : initialized. (class
> org.apache.velocity.runtime.resource.
> ResourceCacheImpl)
> [INFO] Default ResourceManager initialization complete.
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach
> [INFO] Created: 20 parsers.
> [INFO] Velocimacro : initialization starting.
> [INFO] Velocimacro : adding VMs from VM library template :
> VM_global_library.vm
> [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in
> any
> resource loader.
> [INFO] Velocimacro : error using VM library template VM_global_library.vm :
> org
> .apache.velocity.exception.ResourceNotFoundException: Unable to find resource
> 'V
> M_global_library.vm'
> [INFO] Velocimacro : VM library template macro registration complete.
> [INFO] Velocimacro : allowInline = true : VMs can be defined inline in
> templates
> [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may
> NOT
> replace previous VM definitions
> [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be
> glob
> al in scope if allowed.
> [INFO] Velocimacro : initialization complete.
> [INFO] Velocity successfully started.
> [INFO] [archetype:create]
> [INFO] Defaulting package to group ID: com.mycompany.app
> [INFO]
> -
> ---
> [INFO] Using following parameters for creating Archetype:
> maven-archetype-site:R
> ELEASE
> [INFO]
> -
> ---
> [INFO] Parameter: groupId, Value: com.mycompany.app
> [INFO] Parameter: packageName, Value: com.mycompany.app
> [INFO] Parameter: basedir, Value: C:\maven-2.0.4\try\my-app
> [INFO] Parameter: package, Value: com.mycompany.app
> [INFO] Parameter: version, Value: 1.0-SNAPSHOT
> [INF
[jira] Commented: (SUREFIRE-31) support junit 4.0
[ http://jira.codehaus.org/browse/SUREFIRE-31?page=comments#action_73345 ] Bernd commented on SUREFIRE-31: --- Jian, as a first step, please have a look at http://maven.apache.org/guides/development/guide-m2-development.html chapter "Creating and submitting a patch" There is some information about how to apply a patch Does that help? Bernd > support junit 4.0 > - > > Key: SUREFIRE-31 > URL: http://jira.codehaus.org/browse/SUREFIRE-31 > Project: surefire > Issue Type: Improvement >Reporter: John Didion > Attachments: SUREFIRE-31-maven-surefire-plugin.patch, > SUREFIRE-31-surefire-trunk.patch, surefire-junit4.zip > > > I know this is a pretty sizable task. I just wanted to get it in the system > now that 4.0 has officially been released. Hopefully this will generate some > discussion about how 4.0 will be handled - mainly if it will require a > completely seperate implemenation of surefire (keeping the same API so it can > easily be used by the maven plugin), or if use of 4.0 will be made a > configurable option of the current surefire. > Here's some additional features I'd like to see: > 1. Ability to categorize tests. Unfortunately, 4.0 doesn't include an > @Category annotation, or make category a parameter of @Test. However, the > filtering mechanism provided by 4.0 is sufficent to support categories given > the presense of such an annotation. I recommend putting the @Category > annotation in a seperate module (surefire-annotations?) and build support for > it into surefire. Hopefully the junit guys could be convinced to incorporate > it in a later version. > 2. Similarly, support repeated tests via an @Repeated annotation. I'm not > sure how easy this would be to do external to junit. -- 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-31) support junit 4.0
[ http://jira.codehaus.org/browse/SUREFIRE-31?page=comments#action_73343 ] Jian Wu commented on SUREFIRE-31: - Hi Bernd, > You may want to test my patches? Sure. Do you mind telling me the instruction how to apply your patches? Thanks, Jian > support junit 4.0 > - > > Key: SUREFIRE-31 > URL: http://jira.codehaus.org/browse/SUREFIRE-31 > Project: surefire > Issue Type: Improvement >Reporter: John Didion > Attachments: SUREFIRE-31-maven-surefire-plugin.patch, > SUREFIRE-31-surefire-trunk.patch, surefire-junit4.zip > > > I know this is a pretty sizable task. I just wanted to get it in the system > now that 4.0 has officially been released. Hopefully this will generate some > discussion about how 4.0 will be handled - mainly if it will require a > completely seperate implemenation of surefire (keeping the same API so it can > easily be used by the maven plugin), or if use of 4.0 will be made a > configurable option of the current surefire. > Here's some additional features I'd like to see: > 1. Ability to categorize tests. Unfortunately, 4.0 doesn't include an > @Category annotation, or make category a parameter of @Test. However, the > filtering mechanism provided by 4.0 is sufficent to support categories given > the presense of such an annotation. I recommend putting the @Category > annotation in a seperate module (surefire-annotations?) and build support for > it into surefire. Hopefully the junit guys could be convinced to incorporate > it in a later version. > 2. Similarly, support repeated tests via an @Repeated annotation. I'm not > sure how easy this would be to do external to junit. -- 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-796) Disable account on login failures
[ http://jira.codehaus.org/browse/CONTINUUM-796?page=comments#action_73342 ] Carlos Sanchez commented on CONTINUUM-796: -- We need to inject an ApplicationEventPublisher into ProviderManager that will process the AuthenticationFailurePasswordEvent as said before. Actually seems that it's not AuthenticationFailurePasswordEvent but AuthenticationFailureBadCredentialsEvent. There's a long list of possible events that inherit from AbstractAuthenticationFailureEvent, http://acegisecurity.org/multiproject/acegi-security/apidocs/org/acegisecurity/event/authentication/AbstractAuthenticationFailureEvent.html > Disable account on login failures > - > > Key: CONTINUUM-796 > URL: http://jira.codehaus.org/browse/CONTINUUM-796 > Project: Continuum > Issue Type: Sub-task >Reporter: Carlos Sanchez > > We can hook into acegi authz event system to get unsuccessful logins and add > the counter. > After a definer number (eg. 3) of unsucessful consecutive logins the account > must be disabled. -- 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-796) Disable account on login failures
[ http://jira.codehaus.org/browse/CONTINUUM-796?page=comments#action_73340
]
Carlos Sanchez commented on CONTINUUM-796:
--
>From http://acegisecurity.org/faq.html
Common Problem #3: How do I disable a user after a number of failed logins?
A common user requirement is to disable / lock an account after a number of
failed login attempts. Acegi itself does not provide anything "out of the box",
however in your application you can implement and register an
org.springframework.context.ApplicationListener. Inside your application event
listener you can then check for an instanceof the particular
AuthenticationFailureEvent and then call your application user management
interface to update the user details.
For example:
public void onApplicationEvent(ApplicationEvent event) {
// check failed event
if(event instanceof AuthenticationFailurePasswordEvent){
// call user management interface to increment failed login attempts,
etc.
. . .
}
}
> Disable account on login failures
> -
>
> Key: CONTINUUM-796
> URL: http://jira.codehaus.org/browse/CONTINUUM-796
> Project: Continuum
> Issue Type: Sub-task
>Reporter: Carlos Sanchez
>
> We can hook into acegi authz event system to get unsuccessful logins and add
> the counter.
> After a definer number (eg. 3) of unsucessful consecutive logins the account
> must be disabled.
--
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-794) Password expiration
[ http://jira.codehaus.org/browse/CONTINUUM-794?page=comments#action_73335 ] Carlos Sanchez commented on CONTINUUM-794: -- we need to store only the date created. - Number of days valid is a configuration option, for now it can just be injected ffrom the xml config file, and will be shared for all users. Being number of days it must be of type int. You store the date as Date, no need to use a calendar, convert the days to milliseconds and you now if it's expired or not. - in ContinuumUserDetailsService.loadUserByUsername you can check if date created + expiration days < current date and if true set accountNotExpired to false in the returned UserDetails > Password expiration > --- > > Key: CONTINUUM-794 > URL: http://jira.codehaus.org/browse/CONTINUUM-794 > Project: Continuum > Issue Type: Sub-task >Reporter: Carlos Sanchez > Assigned To: Lester Ecarma > > In the acegi user details service, every time a user authenticates check for > date of password creation, if more than defined time set expired=true in the > database and return the user with expired=true too > I think Acegi will redirect to he page for change password, need to > investigate. -- 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-413) Jaxen has unnecessary and unexpected dependencies (which cause problems with JDK 1.5)
[ http://jira.codehaus.org/browse/MEV-413?page=comments#action_73334 ] Jimisola Laursen commented on MEV-413: -- Me again... I forgot to say that Jaxen mailing lists seems to be out of order. Archive links doesn't work from project site and looking at the Nabble archive (http://www.nabble.com/jaxen---user-f11892.html) the last post is from Jul 11 2006. So, for now moving this issue to JAXEN seems like the best chance to get some attention. > Jaxen has unnecessary and unexpected dependencies (which cause problems with > JDK 1.5) > - > > Key: MEV-413 > URL: http://jira.codehaus.org/browse/MEV-413 > Project: Maven Evangelism > Issue Type: Bug > Components: Dependencies >Reporter: Jimisola Laursen > Assigned To: Carlos Sanchez > > The pom > (http://www.ibiblio.org/maven2/jaxen/jaxen/1.1-beta-9/jaxen-1.1-beta-9.pom) > has dependencies on domj, jdom, xom, xerces:xercesImpl and > xerces:xmlParserAPIs (see below). > I can't see why any of these dependencies are necessary - especially not the > dependency on xerces. A slimmed down verson of Xerces is included with JDK > 1.5 and adding an addition Xerces in the classpath caused some major > headache. JDK 1.5 or not, I have the exclude all the dependencies that Jaxen > 1.1-beta-9 has. > > > dom4j > dom4j > 1.6.1 > > > jdom > jdom > 1.0 > > > xerces > xmlParserAPIs > 2.6.2 > > > xerces > xercesImpl > 2.6.2 > > > xom > xom > 1.0b3 > > -- 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-413) Jaxen has unnecessary and unexpected dependencies (which cause problems with JDK 1.5)
[ http://jira.codehaus.org/browse/MEV-413?page=comments#action_7 ] Jimisola Laursen commented on MEV-413: -- Thank you for the information. I'll do just that. Is it possible to move this issue to Jaxen (Jira key: JAXEN)? > Jaxen has unnecessary and unexpected dependencies (which cause problems with > JDK 1.5) > - > > Key: MEV-413 > URL: http://jira.codehaus.org/browse/MEV-413 > Project: Maven Evangelism > Issue Type: Bug > Components: Dependencies >Reporter: Jimisola Laursen > Assigned To: Carlos Sanchez > > The pom > (http://www.ibiblio.org/maven2/jaxen/jaxen/1.1-beta-9/jaxen-1.1-beta-9.pom) > has dependencies on domj, jdom, xom, xerces:xercesImpl and > xerces:xmlParserAPIs (see below). > I can't see why any of these dependencies are necessary - especially not the > dependency on xerces. A slimmed down verson of Xerces is included with JDK > 1.5 and adding an addition Xerces in the classpath caused some major > headache. JDK 1.5 or not, I have the exclude all the dependencies that Jaxen > 1.1-beta-9 has. > > > dom4j > dom4j > 1.6.1 > > > jdom > jdom > 1.0 > > > xerces > xmlParserAPIs > 2.6.2 > > > xerces > xercesImpl > 2.6.2 > > > xom > xom > 1.0b3 > > -- 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-794) Password expiration
[ http://jira.codehaus.org/browse/CONTINUUM-794?page=comments#action_73332 ] Carlos Sanchez commented on CONTINUUM-794: -- >From Lester: - when adding a user account is created, it asks for the number of days the account will be valid. The default is forever (meaning no expiration), which happens when the user leaves it unfilled. I will need input on whether we'll opt for the user to input the actual expiration date instead. I initially had it to accept decimal values as I'm not sure if 'days' would be a good unit of measure here. - when the account expires, acegi will prevent the account from being authenticated. It is handled similar to an incorrect login. > Password expiration > --- > > Key: CONTINUUM-794 > URL: http://jira.codehaus.org/browse/CONTINUUM-794 > Project: Continuum > Issue Type: Sub-task >Reporter: Carlos Sanchez > Assigned To: Lester Ecarma > > In the acegi user details service, every time a user authenticates check for > date of password creation, if more than defined time set expired=true in the > database and return the user with expired=true too > I think Acegi will redirect to he page for change password, need to > investigate. -- 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-413) Jaxen has unnecessary and unexpected dependencies (which cause problems with JDK 1.5)
[ http://jira.codehaus.org/browse/MEV-413?page=comments#action_73331 ] Joakim Erdfelt commented on MEV-413: The Jaxen pom is maintened by the jaxen software development group - http://jaxen.codehaus.org/team-list.html You could ask them to flag certain dependencies as true for the next release. In my opinion, they are the authoritative source for decisions on the jaxen pom. There are several jaxen mailing lists that could be used - http://jaxen.codehaus.org/mail-lists.html Those mailing lists would be the best place to get this change to be made, and for it to stick for all future version of jaxen too. > Jaxen has unnecessary and unexpected dependencies (which cause problems with > JDK 1.5) > - > > Key: MEV-413 > URL: http://jira.codehaus.org/browse/MEV-413 > Project: Maven Evangelism > Issue Type: Bug > Components: Dependencies >Reporter: Jimisola Laursen > Assigned To: Carlos Sanchez > > The pom > (http://www.ibiblio.org/maven2/jaxen/jaxen/1.1-beta-9/jaxen-1.1-beta-9.pom) > has dependencies on domj, jdom, xom, xerces:xercesImpl and > xerces:xmlParserAPIs (see below). > I can't see why any of these dependencies are necessary - especially not the > dependency on xerces. A slimmed down verson of Xerces is included with JDK > 1.5 and adding an addition Xerces in the classpath caused some major > headache. JDK 1.5 or not, I have the exclude all the dependencies that Jaxen > 1.1-beta-9 has. > > > dom4j > dom4j > 1.6.1 > > > jdom > jdom > 1.0 > > > xerces > xmlParserAPIs > 2.6.2 > > > xerces > xercesImpl > 2.6.2 > > > xom > xom > 1.0b3 > > -- 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-337) OJB 1.0.4 has a number of dependencies that should be optional
[ http://jira.codehaus.org/browse/MEV-337?page=comments#action_73329 ] Mike Perham commented on MEV-337: - Yeah, sorry Carlos, I didn't even realize this was MEV. I thought it was the OJB JIRA. :) > OJB 1.0.4 has a number of dependencies that should be optional > -- > > Key: MEV-337 > URL: http://jira.codehaus.org/browse/MEV-337 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Matt Raible > > Compare the 1.0.3 pom with the 1.0.4 - there seems to be a number of > dependencies that should be optional in 1.0.4. > http://www.ibiblio.org/maven2/ojb/db-ojb/1.0.3/db-ojb-1.0.3.pom > http://www.ibiblio.org/maven2/ojb/db-ojb/1.0.4/db-ojb-1.0.4.pom > For example: xjavadoc, xdoclet, velocity, torque, p6spy > It does appear that some dependencies changed with this release (which is odd > for a point release) - so you should probably get in touch with the OJB > developers and see which ones are absolutely required. -- 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-727) Allow Continuum to work with the release plugin to perform the official release
[ http://jira.codehaus.org/browse/CONTINUUM-727?page=comments#action_73328 ] Jeremy Whitlock commented on CONTINUUM-727: --- Hi All, Work on the Maven side started yesterday by creating a model to be used to hold the release descriptor. Edwin will be working on the Continuum side by creating the Web bits for this when it is ready. If you have any questions or concerns, please post it here so we can keep track of it. If you are interested in the Maven side of this, please reference MRELEASE-130 defined above as a dependency. Take care, Jeremy > Allow Continuum to work with the release plugin to perform the official > release > --- > > Key: CONTINUUM-727 > URL: http://jira.codehaus.org/browse/CONTINUUM-727 > Project: Continuum > Issue Type: New Feature > Components: Core system >Reporter: Jason van Zyl > Assigned To: Jeremy Whitlock > Fix For: 1.1 > > > This might eventually be a little tool for release management but it could > start in Continuum. So the release plugin would do a release:prepare and > store the information in a descriptor (maybe use modello to describe the > release) and the descriptor could be sent to Continuum via a Web Service and > Continuum could do the official release. -- 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: (MCHANGELOG-46) Using the dateFormat option the generate changelog report shows a wrong date
[ http://jira.codehaus.org/browse/MCHANGELOG-46?page=comments#action_73327 ] Giorgio Urto commented on MCHANGELOG-46: No whe are using svn 1.3.0 with viewvc 1.0.1 as SCM. I' am also very interested at MCHANGELOG-45, as we have found the same problem using the maven site feature over 460 svn repository. Is that issue (MCHANGELOG-45) going to be planned/assigned? Thank you. Giorgio > Using the dateFormat option the generate changelog report shows a wrong date > > --- > > Key: MCHANGELOG-46 > URL: http://jira.codehaus.org/browse/MCHANGELOG-46 > Project: Maven 2.x Changelog Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-1 >Reporter: Giorgio Urto >Priority: Minor > > Using the dateFormat option in the generated changelog report a file that was > changed the 14 december 2005 at 11.48.50 is show using this timestamp > 0020-05-27 00:00:00. > Here is my configuration for the plugin: > > org.apache.maven.plugins > maven-changelog-plugin > 2.0-SNAPSHOT > > > dual-report > > range > 365 > dd-MM- > > > changelog > file-activity > dev-activity > > > > > Without the dateFormat attribute set, the date in the report is ok. -- 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: (MRELEASE-130) Create a model for a release
[ http://jira.codehaus.org/browse/MRELEASE-130?page=comments#action_73326 ] Jeremy Whitlock commented on MRELEASE-130: -- Hi all, Work started on this yesterday. Currently I am working on creating a Modello model for a Release Descriptor that will be used by Maven instead of the ReleaseConfiguration. Once that is done I will be creating an XMLReleaseDescriptorStore to be able to persist/load a release descriptor to/from an XML document. This will make delegating the release to other tools like Continuum much easier in the long run. If you have any questions or concerns, comment on this so we can keep track of it. Take care, Jeremy > Create a model for a release > > > Key: MRELEASE-130 > URL: http://jira.codehaus.org/browse/MRELEASE-130 > Project: Maven 2.x Release Plugin > Issue Type: New Feature >Reporter: Jason van Zyl > Assigned To: Jeremy Whitlock > > Use modello to create a model for a release. Something that could be sent to > a release mechanism for an official release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-105) need better support for unpack
[ http://jira.codehaus.org/browse/MASSEMBLY-105?page=comments#action_73325 ] John Casey commented on MASSEMBLY-105: -- Can you tell me whether this is still a problem using the latest assembly plugin snapshot? You might have to configure a new pluginRepository using the url: http://people.apache.org/repo/m2-snapshot-repository ...just make sure you leave off the releases/enabled=false bit if you do! I think this has been fixed by the refactor, but I'd like confirmation before I close the issue. > need better support for unpack > -- > > Key: MASSEMBLY-105 > URL: http://jira.codehaus.org/browse/MASSEMBLY-105 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Sachin Patel > Fix For: 2.2 > > > Currently when specifiying a dependency set inside an assembly descriptor, if > one requires the unpack element to be true, then the unpacking is restricted > to the output directory. I have a scenario in which I need to use the unpack > element in conjuction with the outputFileNameMapping element. > I would like to request that the outputFileNameMapping be treated as a folder > to extract into and appended to the outputDirectory. > So given dependency "foo-1.0.jar", I need a way to extract this into > "outputDirectory/foo_1.0/", and since the outputDirectory cannot take > properties such as artifactID, and artifactVersion, need a way to plugin this > "property support", and making use of the outputFileNameMapping would provide > a nice way to handle 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: (MEV-337) OJB 1.0.4 has a number of dependencies that should be optional
[ http://jira.codehaus.org/browse/MEV-337?page=comments#action_73324 ] Carlos Sanchez commented on MEV-337: this needs to be fixed in apache OJB, we just sync from there > OJB 1.0.4 has a number of dependencies that should be optional > -- > > Key: MEV-337 > URL: http://jira.codehaus.org/browse/MEV-337 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Matt Raible > > Compare the 1.0.3 pom with the 1.0.4 - there seems to be a number of > dependencies that should be optional in 1.0.4. > http://www.ibiblio.org/maven2/ojb/db-ojb/1.0.3/db-ojb-1.0.3.pom > http://www.ibiblio.org/maven2/ojb/db-ojb/1.0.4/db-ojb-1.0.4.pom > For example: xjavadoc, xdoclet, velocity, torque, p6spy > It does appear that some dependencies changed with this release (which is odd > for a point release) - so you should probably get in touch with the OJB > developers and see which ones are absolutely required. -- 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: (MAVENUPLOAD-1091) Upload ognl:ognl:2.6.9 to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1091?page=all ] Carlos Sanchez closed MAVENUPLOAD-1091. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload ognl:ognl:2.6.9 to ibiblio > - > > Key: MAVENUPLOAD-1091 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1091 > Project: maven-upload-requests > Issue Type: Task >Reporter: Matt Whitlock > Assigned To: Carlos Sanchez > > http://www.mattwhitlock.com/ognl-2.6.9-bundle.jar > http://www.ognl.org/ > OGNL stands for Object-Graph Navigation Language; it is an expression > language for getting and setting properties of Java objects. > This bundle also contains javadoc and sources jars. -- 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: (MAVENUPLOAD-1077) Logback 0.2.5 upload request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1077?page=all ] Carlos Sanchez closed MAVENUPLOAD-1077. --- Assignee: Carlos Sanchez Resolution: Fixed > Logback 0.2.5 upload request > > > Key: MAVENUPLOAD-1077 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1077 > Project: maven-upload-requests > Issue Type: Task >Reporter: Sebastien Pennec > Assigned To: Carlos Sanchez > Attachments: logback-access-0.2.5-bundle.jar, > logback-classic-0.2.5-bundle.jar, logback-core-0.2.5-bundle.jar, > logback-parent-0.2.5.jar > > > The logback project recently released version 0.2.5 of all three modules. > Please kindly add the attached files to ibiblio's maven repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-74) Added muse format to doxia-core
[ http://jira.codehaus.org/browse/DOXIA-74?page=comments#action_73323 ] Vincent Siveton commented on DOXIA-74: -- Thanks Arnaud! Some comments about your patch: * Patch should be licensed to Apache, no BSD, GNU or other [1] * Follow our code style [2] * Provide a minimalist documentation * role-hint="doxia" needs to be renamed * role-hint="xhtml" is already used somewhere * Use logging API instead of System.err or throw Exception [1] Contributions intended for inclusion in ASF products (eg. patches, code) must be licensed to ASF under the terms of the Apache Software License [2] http://maven.apache.org/guides/development/guide-m2-development.html > Added muse format to doxia-core > --- > > Key: DOXIA-74 > URL: http://jira.codehaus.org/browse/DOXIA-74 > Project: doxia > Issue Type: New Feature > Components: Core >Affects Versions: 1.0-alpha-8 >Reporter: Arnaud Bailly >Priority: Minor > Fix For: 1.0-alpha-8 > > Attachments: patch-doxia-1.0-alpha-8 > > > As a workaround to DOXIA-68 bug, I have m\ade a patch to > doxia-core-1.0-alpha-8 that include necessary code for generating maven sites > from muse syntax and add a dependency to muse-parser from doxia-core pom.xml. > This patch may be useful for people who wish to write their documentation > using Emacs muse mode. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1089) JExcelApi 2.6 Upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1089?page=all ] Carlos Sanchez closed MAVENUPLOAD-1089. --- Assignee: Carlos Sanchez Resolution: Fixed > JExcelApi 2.6 Upload > > > Key: MAVENUPLOAD-1089 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1089 > Project: maven-upload-requests > Issue Type: Task >Reporter: Teodor Danciu > Assigned To: Carlos Sanchez > > http://jasperreports.sourceforge.net/maven/jxl-2.6-bundle.jar > http://jexcelapi.sourceforge.net/ > JasperReports relies on this version of JExcelApi, so we need it uploaded to > the Maven repositories. > This is why it is me who uploads the bundle, although I'm not a JExcelApi > developer. -- 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-1078) subethasmtp 1.0.3 bundles
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1078?page=comments#action_73322 ] Carlos Sanchez commented on MAVENUPLOAD-1078: - remove the version, having the snapshot there can cause problems > subethasmtp 1.0.3 bundles > - > > Key: MAVENUPLOAD-1078 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1078 > Project: maven-upload-requests > Issue Type: Task >Reporter: fabrizio giustina > > subethasmtp-smtp and subethasmtp-wiser bundles: contain jar, sources, javadoc > plus an additional artifact for the jdk14 compatible version with a "java14" > classifier > http://magnolia.sourceforge.net/bundles/subethasmtp-smtp-1.0.3-bundle.jar > http://magnolia.sourceforge.net/bundles/subethasmtp-wiser-1.0.3-bundle.jar > subethasmtp-parent: only contains the parent pom > http://magnolia.sourceforge.net/bundles/subethasmtp-parent-1.0.3-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] Created: (MNGECLIPSE-190) Unable to enable Maven2 plugin for existing not maven2 project
Unable to enable Maven2 plugin for existing not maven2 project -- Key: MNGECLIPSE-190 URL: http://jira.codehaus.org/browse/MNGECLIPSE-190 Project: Maven 2.x Extension for Eclipse Issue Type: Bug Components: Wizards Affects Versions: 0.0.10 Environment: WinXP, Eclipse 3.2 Reporter: Marek Bieganski Assigned To: Eugene Kuleshov Attachments: UnableToEnable.PNG Steps: 1. Create new Java project, enter name e.g. "lib" 2. Right click on it, select Maven2->Enable 3. Cannot do anything on this window In 0.0.9 it was it worked 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] Commented: (MCHANGELOG-46) Using the dateFormat option the generate changelog report shows a wrong date
[ http://jira.codehaus.org/browse/MCHANGELOG-46?page=comments#action_73320 ] Dennis Lundberg commented on MCHANGELOG-46: --- Are you using Perforce as your SCM? > Using the dateFormat option the generate changelog report shows a wrong date > > --- > > Key: MCHANGELOG-46 > URL: http://jira.codehaus.org/browse/MCHANGELOG-46 > Project: Maven 2.x Changelog Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-1 >Reporter: Giorgio Urto >Priority: Minor > > Using the dateFormat option in the generated changelog report a file that was > changed the 14 december 2005 at 11.48.50 is show using this timestamp > 0020-05-27 00:00:00. > Here is my configuration for the plugin: > > org.apache.maven.plugins > maven-changelog-plugin > 2.0-SNAPSHOT > > > dual-report > > range > 365 > dd-MM- > > > changelog > file-activity > dev-activity > > > > > Without the dateFormat attribute set, the date in the report is ok. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-99) dependencySets in a descriptor doesn't work anymore
[ http://jira.codehaus.org/browse/MASSEMBLY-99?page=comments#action_73319 ] John Casey commented on MASSEMBLY-99: - svn co http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-assembly-plugin then, go to: cd maven-assembly-plugin/src/it/dependency-sets/massembly-99 and look in: src/main/assembly/bin.xml > dependencySets in a descriptor doesn't work anymore > --- > > Key: MASSEMBLY-99 > URL: http://jira.codehaus.org/browse/MASSEMBLY-99 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: all >Reporter: Olivier Lamy > Assigned To: John Casey >Priority: Blocker > Fix For: 2.2 > > Attachments: assembly-spike-1.0.zip, descriptor.xml > > > I attached my descriptor file. > > > lib > false > runtime > > > > unzip -l on the assembly file show empty lib directory. > 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: (MEV-337) OJB 1.0.4 has a number of dependencies that should be optional
[ http://jira.codehaus.org/browse/MEV-337?page=comments#action_73318 ] Mike Perham commented on MEV-337: - Here's my take on some of the more mysterious deps in OJB. antlr-2.7.5.jar Compile/Optional commons-beanutils-1.7.0.jar Compile/Required commons-betwixt-0.8-dev.jar Remove? Runtime/Optional, no compilation or test failures without it commons-digester-1.7.jarCompile/Optional commons-pool-1.2.jarCompile/Optional commons-transaction-1.1.jar Compile/Required jakarta-regexp-1.3.jar Compile/Optional jcs.jar Compile/Optional prevayler.jar Runtime/Optional village-2.0.jar Runtime/Optional > OJB 1.0.4 has a number of dependencies that should be optional > -- > > Key: MEV-337 > URL: http://jira.codehaus.org/browse/MEV-337 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Matt Raible > > Compare the 1.0.3 pom with the 1.0.4 - there seems to be a number of > dependencies that should be optional in 1.0.4. > http://www.ibiblio.org/maven2/ojb/db-ojb/1.0.3/db-ojb-1.0.3.pom > http://www.ibiblio.org/maven2/ojb/db-ojb/1.0.4/db-ojb-1.0.4.pom > For example: xjavadoc, xdoclet, velocity, torque, p6spy > It does appear that some dependencies changed with this release (which is odd > for a point release) - so you should probably get in touch with the OJB > developers and see which ones are absolutely required. -- 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: (MPPMD-28) exclude files
[ http://jira.codehaus.org/browse/MPPMD-28?page=all ] Lukas Theussl closed MPPMD-28. -- Assignee: Lukas Theussl Resolution: Won't Fix This tracker is for the Maven 1 pmd plugin.If you meant to file this for the m2 plugin, please go to http://jira.codehaus.org/browse/MPMD. In m1, you have to use the maven.pmd.excludes property to exclude certain files, see http://maven.apache.org/maven-1.x/plugins/pmd/faq.html#disable-select-files. > exclude files > - > > Key: MPPMD-28 > URL: http://jira.codehaus.org/browse/MPPMD-28 > Project: maven-pmd-plugin > Issue Type: Wish >Reporter: Jesper Zedlitz > Assigned To: Lukas Theussl > > It would be nice if you could exclude files (generated source code) from the > PMD report. > The Cobertura plugin for examples has a configuration element > > org/example/generated/**/*.class > -- 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-74) Added muse format to doxia-core
Added muse format to doxia-core --- Key: DOXIA-74 URL: http://jira.codehaus.org/browse/DOXIA-74 Project: doxia Issue Type: New Feature Components: Core Affects Versions: 1.0-alpha-8 Reporter: Arnaud Bailly Priority: Minor Fix For: 1.0-alpha-8 Attachments: patch-doxia-1.0-alpha-8 As a workaround to DOXIA-68 bug, I have m\ade a patch to doxia-core-1.0-alpha-8 that include necessary code for generating maven sites from muse syntax and add a dependency to muse-parser from doxia-core pom.xml. This patch may be useful for people who wish to write their documentation using Emacs muse mode. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-529) Modules (child) scm connection URLs are not constructed correctly
[ http://jira.codehaus.org/browse/CONTINUUM-529?page=comments#action_73315
]
Martin van den Bemt commented on CONTINUUM-529:
---
You will run into other problems when the scm url is inherited and the location
in scm != artifactId, so better define the correct scm url in the child pom. So
if you want this fix, this defintely isn't a bug, but at most an enhancement or
request for this kind of functionality.
> Modules (child) scm connection URLs are not constructed correctly
> -
>
> Key: CONTINUUM-529
> URL: http://jira.codehaus.org/browse/CONTINUUM-529
> Project: Continuum
> Issue Type: Bug
> Components: Core system, SCM
>Affects Versions: 1.0.2
>Reporter: Grégory Joseph
> Fix For: 1.1
>
>
> It *seems* to me that, when adding a parent pom to continuum, which has
> defined, but the scm url only defined in the parent, it gets and
> parses the child poms correctly, but their scm URLs are build as
> ${parentScmUrl}/${childArtifactId} , while I think they should rather be
> ${parentScmUrl}/${modulePath}
> Maybe this is a maven inheritance issue, though ?
--
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-29) Make (sure) dependency:resolve outputs absolute filename (or at least make it configurable)
[ http://jira.codehaus.org/browse/MDEP-29?page=comments#action_73314 ] Jimisola Laursen commented on MDEP-29: -- Haven't seen any activity for this plugin lately. When will 1.1/2.0 will be released? Will it have the functionality to output dependency filenames? > Make (sure) dependency:resolve outputs absolute filename (or at least make it > configurable) > --- > > Key: MDEP-29 > URL: http://jira.codehaus.org/browse/MDEP-29 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement >Affects Versions: 1.1, 2.0 >Reporter: Jimisola Laursen > > I haven't used 1.1/2.0 yet myself, but from Brian Fox's comment > (http://jira.codehaus.org/browse/MDEP-24#action_69078) it's uncertain whether > dependency:resolve outputs the absolute filename at all times. > Being able to specify whether the output should be filename onlhy or > absolute filename would be very useful. -- 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: (MCHANGELOG-46) Using the dateFormat option the generate changelog report shows a wrong date
Using the dateFormat option the generate changelog report shows a wrong date --- Key: MCHANGELOG-46 URL: http://jira.codehaus.org/browse/MCHANGELOG-46 Project: Maven 2.x Changelog Plugin Issue Type: Bug Affects Versions: 2.0-beta-1 Reporter: Giorgio Urto Priority: Minor Using the dateFormat option in the generated changelog report a file that was changed the 14 december 2005 at 11.48.50 is show using this timestamp 0020-05-27 00:00:00. Here is my configuration for the plugin: org.apache.maven.plugins maven-changelog-plugin 2.0-SNAPSHOT dual-report range 365 dd-MM- changelog file-activity dev-activity Without the dateFormat attribute set, the date in the report is ok. -- 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: (MPPMD-28) exclude files
[ http://jira.codehaus.org/browse/MPPMD-28?page=comments#action_73310 ] Jesper Zedlitz commented on MPPMD-28: - It it just a documentation problem. It is possible to exclude files from the PMD report: maven-pmd-plugin 2.1 **/org/example/generator** The two asterixes at the beginning of the path are important! > exclude files > - > > Key: MPPMD-28 > URL: http://jira.codehaus.org/browse/MPPMD-28 > Project: maven-pmd-plugin > Issue Type: Wish >Reporter: Jesper Zedlitz > > It would be nice if you could exclude files (generated source code) from the > PMD report. > The Cobertura plugin for examples has a configuration element > > org/example/generated/**/*.class > -- 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-124) Plugin fail to initialize when default maven repository folder is not available
[ http://jira.codehaus.org/browse/MNGECLIPSE-124?page=comments#action_73302 ] Martin Goulet commented on MNGECLIPSE-124: -- The problem is not with the plugin. What you need to keep in mind is that the plugin is built on top on Maven. So you need to install Maven first and run it at least one time from the command line so that the "Documents and Settings//.m2" directory is created. Once that is done, go back in Eclipse and everything will be ok. MG > Plugin fail to initialize when default maven repository folder is not > available > --- > > Key: MNGECLIPSE-124 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-124 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug >Affects Versions: 0.0.7 > Environment: Windows XP Professional SP2 > JSE v1.5.0-06 > Eclipse 3.2RC4 >Reporter: Douglas WF Acheson > Attachments: .log > > > This is this error when I try to go to the Maven2 preferences : > Plug-in org.maven.ide.eclipse was unable to load class > org.maven.ide.eclipse.preferences.Maven2PreferencePage. > As well, I an not able to associate a project with maven2 when using the RMB > context menu for a project . I get a popup window with the following > The chosen operation is not currently available -- 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-755) Add field validations with webwork field validator
[ http://jira.codehaus.org/browse/CONTINUUM-755?page=all ] Maria Odea Ching updated CONTINUUM-755: --- Attachment: CONTINUUM-755-continuum-webapp-userValidation.patch Attached patch for validating User and UserGroup forms > Add field validations with webwork field validator > -- > > Key: CONTINUUM-755 > URL: http://jira.codehaus.org/browse/CONTINUUM-755 > Project: Continuum > Issue Type: Task > Components: Web interface >Affects Versions: 1.1 >Reporter: Emmanuel Venisse > Assigned To: Maria Odea Ching > Fix For: 1.1 > > Attachments: CONTINUUM-755-continuum-webapp-userValidation.patch, > CONTINUUM-755-continuum-webapp.patch > > Original Estimate: 1 day, 6 hours > Time Spent: 1 day, 8 hours > Remaining Estimate: 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] Commented: (MASSEMBLY-99) dependencySets in a descriptor doesn't work anymore
[ http://jira.codehaus.org/browse/MASSEMBLY-99?page=comments#action_73297 ] Norman Fomferra commented on MASSEMBLY-99: -- Dear John, If I understand correctly, the fix is, that the assembly descriptor now allows to place a child element into a parent element? That would be great. Where can I get the src/it/dependency-sets/massembly-99 example? Norman > dependencySets in a descriptor doesn't work anymore > --- > > Key: MASSEMBLY-99 > URL: http://jira.codehaus.org/browse/MASSEMBLY-99 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: all >Reporter: Olivier Lamy > Assigned To: John Casey >Priority: Blocker > Fix For: 2.2 > > Attachments: assembly-spike-1.0.zip, descriptor.xml > > > I attached my descriptor file. > > > lib > false > runtime > > > > unzip -l on the assembly file show empty lib directory. > 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: (MANTRUN-37) Antrun breaks on multi-module builds
[ http://jira.codehaus.org/browse/MANTRUN-37?page=comments#action_73296 ] Martin Heitz commented on MANTRUN-37: - Having the same problem. Seems to be related to the use of xdoclet, which is loading antrun 1.0... Extract from pom: org.apache.maven.plugins maven-antrun-plugin 1.1 ... Stack trace (which shows, that 1.0 is used, although 1.1 is configured) follows: INFO] [ERROR] BUILD ERROR [INFO] [INFO] Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run': Unable to find the mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run' in the plugin 'org.apache.maven.plugins:maven-antrun-plugin' Component descriptor cannot be found in the component repository: org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-antrun-plugin:1.0:run. [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run': Unable to find the mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run' in the plugin 'org.apache.maven.plugins:maven-antrun-plugin' at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:538) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) 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:256) 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:324) 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.PluginManagerException: Unable to find the mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run' in the plugin 'org.apache.maven.plugins:maven-antrun-plugin' at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:533) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:390) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 16 more Caused by: org.codehaus.plexus.component.repository.exception.ComponentLookupException: Component descriptor cannot be found in the component repository: org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-antrun-plugin:1.0:run. at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:323) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:312) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:440) at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:524) ... 18 more > Antrun breaks on multi-module builds > > > Key: MANTRUN-37 > URL: http://jira.codehaus.org/browse/MANTRUN-37 > Project: Maven 2.x Antrun Plugin > Issue Type: Bug >Affects Versions: 1.1 > Environment: Maven 2.0.1 >Reporter: Mike Perham >Priority: Critical > > I just updated to antrun v1.1 (which needs to be marked as released in jira > BTW) and find that my multimodule build is now breaking. Running the build > in the child module itself works fine but if I build the parent, it fails > when it gets to the child with the antrun task. Here's part of th
[jira] Commented: (MAVENUPLOAD-1089) JExcelApi 2.6 Upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1089?page=comments#action_73295 ] Teodor Danciu commented on MAVENUPLOAD-1089: Here's a second attempt to solve this issue. I have uploaded a new version of the bundle at the specified location. http://jasperreports.sourceforge.net/maven/jxl-2.6-bundle.jar I added new information into the pom.xml, except for the SCM URL, because JExcelApi does not seem to have a public source repository. I hope this is enough. There's no more info I could provide myseld. Thanks, Teodor > JExcelApi 2.6 Upload > > > Key: MAVENUPLOAD-1089 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1089 > Project: maven-upload-requests > Issue Type: Task >Reporter: Teodor Danciu > > http://jasperreports.sourceforge.net/maven/jxl-2.6-bundle.jar > http://jexcelapi.sourceforge.net/ > JasperReports relies on this version of JExcelApi, so we need it uploaded to > the Maven repositories. > This is why it is me who uploads the bundle, although I'm not a JExcelApi > developer. -- 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-1078) subethasmtp 1.0.3 bundles
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1078?page=comments#action_73291 ] fabrizio giustina commented on MAVENUPLOAD-1078: the only SNAPSHOT dependency is the retrotranslator-maven-plugin in the parent pom used during builds to produce the java-14 version of the jar: it's not a transitive dependency so it should not be a problem for people dependending on this pom. I know you can't actually release a project using the release plugin using SNAPSHOT plugins, but does this also apply to repository uploads? The retrotranslator mojo has not been released yet (although there was a release proposal just a few days ago) so if we have to remove dependency on the snapshot we could: - wait till a retrotranslator release is out - just remove the dependency version from the parent POM What do you say Carlos? > subethasmtp 1.0.3 bundles > - > > Key: MAVENUPLOAD-1078 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1078 > Project: maven-upload-requests > Issue Type: Task >Reporter: fabrizio giustina > > subethasmtp-smtp and subethasmtp-wiser bundles: contain jar, sources, javadoc > plus an additional artifact for the jdk14 compatible version with a "java14" > classifier > http://magnolia.sourceforge.net/bundles/subethasmtp-smtp-1.0.3-bundle.jar > http://magnolia.sourceforge.net/bundles/subethasmtp-wiser-1.0.3-bundle.jar > subethasmtp-parent: only contains the parent pom > http://magnolia.sourceforge.net/bundles/subethasmtp-parent-1.0.3-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] Commented: (MRESOURCES-25) Filtering of property values containing backslashes in path names still does not escape them?
[ http://jira.codehaus.org/browse/MRESOURCES-25?page=comments#action_73290
]
Holger Riegel commented on MRESOURCES-25:
-
Are you sure you are using version 2.2 of Maven resources plugin?
Look at your local Maven repository in the path
org/apache/maven/plugins/maven-resources-plugin. If there's a directory with
name "2.1" you are using the old 2.1 version of the plugin.
I had the same effect as the one you described.
But when I specified in the pom.xml the version 2.2 it worked:
maven-resources-plugin
2.2
Alternatively you may delete your local repository. Maven should then get the
latest version of the resources plugin.
> Filtering of property values containing backslashes in path names still does
> not escape them?
> -
>
> Key: MRESOURCES-25
> URL: http://jira.codehaus.org/browse/MRESOURCES-25
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Environment: Windows
>Reporter: Bryan Carpenter
>
> This was originally reported as MRESOURCES-17, and I understood from the
> comments
> there it was fixed in version 2.2 of the plugin. But I have tried using that
> version of the
> resources plugin, and I am still seeing the same problem.
> My source property file contains:
> org.apache.ws.security.crypto.merlin.file=${basedir}/keys/x509.PFX.MSFT
> After filtering it looks like this:
>
> org.apache.ws.security.crypto.merlin.file=D:\cygwin\home\dbc\cvs\omii-packaging\source\ws-wss4j/keys/x509.PFX.MSFT
> and when the this is read in by `Properties.load()' the value ends up as:
> d:cygwinhomedbccvsomii-packagingsourcews-wss4j/keys/x509.PFX.MSFT
--
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-831) Continuum Release white site pages
[ http://jira.codehaus.org/browse/CONTINUUM-831?page=comments#action_73288 ] Edwin Punzalan commented on CONTINUUM-831: -- I've been modifying the white site so the patch is outdated now... will attach the final patch when done. > Continuum Release white site pages > -- > > Key: CONTINUUM-831 > URL: http://jira.codehaus.org/browse/CONTINUUM-831 > Project: Continuum > Issue Type: Improvement > Components: Documentation >Affects Versions: 1.1 >Reporter: Edwin Punzalan > Attachments: CONTINUUM-831-continuum-uml.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
