[jira] Updated: (MECLIPSE-94) Allow eclipse:eclipse to work on pom (and other) projects
[ http://jira.codehaus.org/browse/MECLIPSE-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Cornelis updated MECLIPSE-94: --- Attachment: MECLIPSE-94.patch The patch MECLIPSE-94 allows for POM files to yield Eclipse project files in case the Maven project has no child projects itself. > Allow eclipse:eclipse to work on pom (and other) projects > - > > Key: MECLIPSE-94 > URL: http://jira.codehaus.org/browse/MECLIPSE-94 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Felipe Leme > Attachments: MECLIPSE-94.patch > > > I'm creating a Java EE project based on the m2book (which I was reviewing; > it's not available yet...) and one of the projects is a pom-packaging project > used for integration tests. According to Vincent, currently this project must > be a pom (in fact, I tried to set it as jar, but then the test phase would be > run anyway, which would cause the tests to fail), as it doesn't produces a > jar. But as it has java files (on the src/main/it/java directory), I tried to > call eclipse:eclipse but it fails, saying that "Not running eclipse plugin > goal for pom project". > For these scenarios, I think a propery would be enough. At first I thought > something about a 'force' or 'forceGeneration' property, would enough, which > the code change being from: > if ( "pom".equals( packaging ) && eclipseProjectDir == null ) > to: > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !forceGeneration ) > Then I realized there is other place where the pom nature is checked: > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !forceGeneration ) > So, I think a better name for the property would be 'javaProject' and the > change would be: > final boolean isJavaProjectProperty = // read property; defaults to false... > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !isJavaProjectProperty ) > isJavaProject = isJavaProjectProperty || !"ear".equals( packaging ) && > !"pom".equals( packaging ); > If nobody objects and someone is willing to apply the changes, I can provide > such patch (with the proper test cases). > -- Felipe > PS: I'm assigning it to Vincent for now, as he 'dreamed' that such features > already existed :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (CONTINUUM-1487) should not be allowed to delete a build result that is still executing
[ http://jira.codehaus.org/browse/CONTINUUM-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse reopened CONTINUUM-1487: - I'm not sure this issue is totally fixed. I think we need to not allow to delete a build result that is is running > should not be allowed to delete a build result that is still executing > -- > > Key: CONTINUUM-1487 > URL: http://jira.codehaus.org/browse/CONTINUUM-1487 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-3 >Reporter: Brett Porter >Assignee: Olivier Lamy > Fix For: 1.1-beta-4 > > > note that deleting the build result from on the build result page also seems > to skip confirmation. All I did was hit the space bar... -- 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-1509) always build option doesn't work with scheduler --> log = No files updated, not building
[ http://jira.codehaus.org/browse/CONTINUUM-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated CONTINUUM-1509: Fix Version/s: 1.1-beta-4 > always build option doesn't work with scheduler --> log = No files updated, > not building > - > > Key: CONTINUUM-1509 > URL: http://jira.codehaus.org/browse/CONTINUUM-1509 > Project: Continuum > Issue Type: Bug > Components: Core system >Affects Versions: 1.1-beta-3 > Environment: windows xp sp2 - maven 2.0.7 - continuum 1.1 beta 3 > -subversion 1.4.2 >Reporter: patrick roussel > Fix For: 1.1-beta-4 > > > when always build option is checked, scheduler doesn't work correctly --> No > files updated, not building > 4799733 [pool-1-thread-1] INFO > org.apache.maven.continuum.buildcontroller.BuildController:default - Merging > SCM results > 4800186 [pool-1-thread-1] INFO > org.apache.maven.continuum.buildcontroller.BuildController:default - > AlwaysBuild configured, building > 4800186 [pool-1-thread-1] INFO > org.apache.maven.continuum.buildcontroller.BuildController:default - > Performing action update-project-from-working-directory > 4800217 [pool-1-thread-1] INFO > org.codehaus.plexus.action.Action:update-project-from-working-directory - > Updating project 'Maven xxx Maintenance' from checkout. > 4803279 [pool-1-thread-1] INFO > org.apache.maven.continuum.buildcontroller.BuildController:default - > Performing action execute-builder > 4803279 [pool-1-thread-1] INFO > org.codehaus.plexus.action.Action:execute-builder - No files updated, not > building. Project id '1'. > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1509) always build option doesn't work with scheduler --> log = No files updated, not building
always build option doesn't work with scheduler --> log = No files updated, not building - Key: CONTINUUM-1509 URL: http://jira.codehaus.org/browse/CONTINUUM-1509 Project: Continuum Issue Type: Bug Components: Core system Affects Versions: 1.1-beta-3 Environment: windows xp sp2 - maven 2.0.7 - continuum 1.1 beta 3 -subversion 1.4.2 Reporter: patrick roussel when always build option is checked, scheduler doesn't work correctly --> No files updated, not building 4799733 [pool-1-thread-1] INFO org.apache.maven.continuum.buildcontroller.BuildController:default - Merging SCM results 4800186 [pool-1-thread-1] INFO org.apache.maven.continuum.buildcontroller.BuildController:default - AlwaysBuild configured, building 4800186 [pool-1-thread-1] INFO org.apache.maven.continuum.buildcontroller.BuildController:default - Performing action update-project-from-working-directory 4800217 [pool-1-thread-1] INFO org.codehaus.plexus.action.Action:update-project-from-working-directory - Updating project 'Maven xxx Maintenance' from checkout. 4803279 [pool-1-thread-1] INFO org.apache.maven.continuum.buildcontroller.BuildController:default - Performing action execute-builder 4803279 [pool-1-thread-1] INFO org.codehaus.plexus.action.Action:execute-builder - No files updated, not building. Project id '1'. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-1508) NullPointerException when adding an empty installation to a profile
[
http://jira.codehaus.org/browse/CONTINUUM-1508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated CONTINUUM-1508:
Fix Version/s: 1.1-beta-4
> NullPointerException when adding an empty installation to a profile
> ---
>
> Key: CONTINUUM-1508
> URL: http://jira.codehaus.org/browse/CONTINUUM-1508
> Project: Continuum
> Issue Type: Bug
> Components: Web interface
>Affects Versions: 1.1-beta-3
>Reporter: George Gastaldi
>Priority: Minor
> Fix For: 1.1-beta-4
>
>
> Steps to reproduce the problem:
> 1) Install Continuum;
> 2) Go to "Profiles"
> 3) Create a new profile
> 4) Click the "Add" button (is empty, no installation defined).
> BTW, Profiles must be enabled only when an installation exist
> StackTrace:
> {code}
> java.lang.NullPointerException
> at
> org.apache.maven.continuum.profile.DefaultProfileService.addInstallationInProfile(DefaultProfileService.java:180)
> at
> org.apache.maven.continuum.web.action.admin.ProfileAction.addInstallation(ProfileAction.java:155)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:358)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:218)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:192)
> at
> org.codehaus.plexus.xwork.interceptor.PlexusReleaseComponentInterceptor.intercept(PlexusReleaseComponentInterceptor.java:69)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:175)
> at
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115)
> at
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> org.apache.maven.continuum.web.interceptor.ForceContinuumConfigurationInterceptor.intercept(ForceContinuumConfigurationInterceptor.java:72)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> org.codehaus.plexus.redback.xwork.interceptor.PolicyEnforcementInterceptor.intercept(PolicyEnforcementInterceptor.java:118)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> org.codehaus.plexus.redback.xwork.interceptor.SecureActionInterceptor.intercept(SecureActionInterceptor.java:159)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> org.codehaus.plexus.xwork.interceptor.ExceptionMappingInterceptor.intercept(ExceptionMappingInterceptor.java:58)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:175)
> at
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115)
> at
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation
[jira] Commented: (MPEAR-46) Unknown artifact type[java-source]
[ http://jira.codehaus.org/browse/MPEAR-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108986 ] Lukas Theussl commented on MPEAR-46: This issue was opened for the Maven 1 EAR plugin, please copy it over to http://jira.codehaus.org/browse/MEAR if you see the same in m2. > Unknown artifact type[java-source] > --- > > Key: MPEAR-46 > URL: http://jira.codehaus.org/browse/MPEAR-46 > Project: Maven 1.x Ear Plugin > Issue Type: Bug > Environment: Windows > Eclipse 3.1 >Reporter: Tom Bollwitt >Priority: Trivial > Fix For: 1.9.1 > > > When a POM (parent or dependency) includes java source jar dependencies they > are not ignored and an error is thrown. > > mygroup > artifact2 > 1.0 > java-source > > When running 'package' or ear:ear I am getting the following error: > [INFO] [ear:generate-application-xml] > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to initialize ear modules > Embedded error: Unknown artifact type[java-source] > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to initialize > ear modules > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) > 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:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to > initialize ear modules > at > org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:151) > at > org.apache.maven.plugin.ear.GenerateApplicationXmlMojo.execute(GenerateApplicationXmlMojo.java:110) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > ... 16 more > Caused by: org.apache.maven.plugin.ear.UnknownArtifactTypeException: Unknown > artifact type[java-source] > at > org.apache.maven.plugin.ear.ArtifactTypeMappingService.getStandardType(ArtifactTypeMappingService.java:153) > at > org.apache.maven.plugin.ear.EarModuleFactory.newEarModule(EarModuleFactory.java:60) > at > org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:144) > ... 19 more > [INFO] > > [INFO] Total time: 2 seconds > [INFO] Finished at: Wed Aug 30 11:49:59 CDT 2006 > [INFO] Final Memory: 4M/7M > I added test to the java-source dependency and was able to > work around this issue. The scope is missleading and therefore the desired > behavior would be to not require scoping the java-source dependency. -- 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-1322) Attempt to store value with more than 256 chars
[ http://jira.codehaus.org/browse/CONTINUUM-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108992 ] Emmanuel Venisse commented on CONTINUUM-1322: - I think the patch is included in this war. How do you test it? with a fresh database or an old one? > Attempt to store value with more than 256 chars > --- > > Key: CONTINUUM-1322 > URL: http://jira.codehaus.org/browse/CONTINUUM-1322 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-1 >Reporter: Pavel Halas >Assignee: Emmanuel Venisse > > Using latest snapshot (continuum-20070621.01.war) I get this exception > causing the project build not processed at all -- red X on the project page, > no build statistics to be found. > 690292 [Thread-2] ERROR > org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor:build-project - > Error executing task > edu.emory.mathcs.backport.java.util.concurrent.ExecutionException: > javax.jdo.JDOFatalUserException: Attempt to store value > "/soseco/dev/tahoe/applications/rcp/rcpmanager/src/main/java/biz/wss/rcp/rcpmanager/core/bundle/ManagerPartDelegateConfig.java > (from > /soseco/dev/tahoe/applications/rcp/rcpmanager/src/main/java/biz/wss/rcp/rcpmanager/parts/ManagerPartDelegateConfig.java:12912)" > in column ""NAME"" that has maximum length of 256. Please correct your data! > at > edu.emory.mathcs.backport.java.util.concurrent.FutureTask.getResult(FutureTask.java:299) > at > edu.emory.mathcs.backport.java.util.concurrent.FutureTask.get(FutureTask.java:128) > at > org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.waitForTask(ThreadedTaskQueueExecutor.java:165) > at > org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:127) > Caused by: javax.jdo.JDOFatalUserException: Attempt to store value > "/soseco/dev/tahoe/applications/rcp/rcpmanager/src/main/java/biz/wss/rcp/rcpmanager/core/bundle/ManagerPartDelegateConfig.java > (from > /soseco/dev/tahoe/applications/rcp/rcpmanager/src/main/java/biz/wss/rcp/rcpmanager/parts/ManagerPartDelegateConfig.java:12912)" > in column ""NAME"" that has maximum length of 256. Please correct your data! > at > org.jpox.store.rdbms.mapping.CharRDBMSMapping.setString(CharRDBMSMapping.java:214) > at > org.jpox.store.mapping.SingleFieldMapping.setString(SingleFieldMapping.java:203) > at > org.jpox.store.rdbms.fieldmanager.ParameterSetter.storeStringField(ParameterSetter.java:122) > at > org.jpox.state.StateManagerImpl.providedStringField(StateManagerImpl.java:2757) > at > org.apache.maven.continuum.model.scm.ChangeFile.jdoProvideField(ChangeFile.java) > at > org.apache.maven.continuum.model.scm.ChangeFile.jdoProvideFields(ChangeFile.java) > at > org.jpox.state.StateManagerImpl.provideFields(StateManagerImpl.java:3115) > at > org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:252) > at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2519) > at org.jpox.store.StoreManager.insert(StoreManager.java:920) > at > org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3667) > at > org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:3646) > at > org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1198) > at > org.jpox.AbstractPersistenceManager.makePersistentInternal(AbstractPersistenceManager.java:1243) > at > org.jpox.store.rdbms.scostore.FKListStore.validateElementForWriting(FKListStore.java:1231) > at > org.jpox.store.rdbms.scostore.FKListStore.internalAdd(FKListStore.java:772) > at > org.jpox.store.rdbms.scostore.AbstractListStore.addAll(AbstractListStore.java:386) > at > org.jpox.store.mapping.CollectionMapping.postInsert(CollectionMapping.java:209) > at > org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:464) > at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2519) > at org.jpox.store.StoreManager.insert(StoreManager.java:920) > at > org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3667) > at > org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:3646) > at > org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1198) > at > org.jpox.AbstractPersistenceManager.makePersistentInternal(AbstractPersistenceManager.java:1243) > at > org.jpox.store.rdbms.scostore.FKListStore.validateElementForWriting(FKListStore.java:1231) > at > org.jpox.store.rdbms.scostore.FKListStore.internalAd
[jira] Reopened: (CONTINUUM-1322) Attempt to store value with more than 256 chars
[
http://jira.codehaus.org/browse/CONTINUUM-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Halas reopened CONTINUUM-1322:
I cannot verify the the bug is fixed. On the latest version
{{continuum-20071002.110002.war}} the issue remains.
{noformat}
4569627 [Thread-3] ERROR
org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor:build-project -
Error executing task
edu.emory.mathcs.backport.java.util.concurrent.ExecutionException:
javax.jdo.JDOFatalUserException: Attempt to store value
"/soseco/dev/nirvana/java/programs/pricing/src/main/java/biz/wss/rcp/pricing/entity/quotes/ComparableMarketQuote.java
(from
/soseco/7.2/7.2.0/dev/nirvana/java/programs/pricing/src/main/java/biz/wss/rcp/pricing/entity/quotes/ComparableMarketQuote.java:21428)"
in column ""NAME"" that has maximum length of 255. Please correct your data!
at
edu.emory.mathcs.backport.java.util.concurrent.FutureTask.getResult(FutureTask.java:299)
at
edu.emory.mathcs.backport.java.util.concurrent.FutureTask.get(FutureTask.java:128)
at
org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.waitForTask(ThreadedTaskQueueExecutor.java:165)
at
org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:127)
Caused by: javax.jdo.JDOFatalUserException: Attempt to store value
"/soseco/dev/nirvana/java/programs/pricing/src/main/java/biz/wss/rcp/pricing/entity/quotes/ComparableMarketQuote.java
(from
/soseco/7.2/7.2.0/dev/nirvana/java/programs/pricing/src/main/java/biz/wss/rcp/pricing/entity/quotes/ComparableMarketQuote.java:21428)"
in column ""NAME"" that has maximum length of 255. Please correct your data!
at
org.jpox.store.rdbms.mapping.CharRDBMSMapping.setString(CharRDBMSMapping.java:214)
at
org.jpox.store.mapping.SingleFieldMapping.setString(SingleFieldMapping.java:203)
at
org.jpox.store.rdbms.fieldmanager.ParameterSetter.storeStringField(ParameterSetter.java:122)
at
org.jpox.state.StateManagerImpl.providedStringField(StateManagerImpl.java:2757)
at
org.apache.maven.continuum.model.scm.ChangeFile.jdoProvideField(ChangeFile.java)
at
org.apache.maven.continuum.model.scm.ChangeFile.jdoProvideFields(ChangeFile.java)
at
org.jpox.state.StateManagerImpl.provideFields(StateManagerImpl.java:3115)
at
org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:252)
at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2519)
at org.jpox.store.StoreManager.insert(StoreManager.java:920)
at
org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3667)
at
org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:3646)
at
org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1198)
at
org.jpox.AbstractPersistenceManager.makePersistentInternal(AbstractPersistenceManager.java:1243)
{noformat}
> Attempt to store value with more than 256 chars
> ---
>
> Key: CONTINUUM-1322
> URL: http://jira.codehaus.org/browse/CONTINUUM-1322
> Project: Continuum
> Issue Type: Bug
>Affects Versions: 1.1-beta-1
>Reporter: Pavel Halas
>Assignee: Emmanuel Venisse
>
> Using latest snapshot (continuum-20070621.01.war) I get this exception
> causing the project build not processed at all -- red X on the project page,
> no build statistics to be found.
> 690292 [Thread-2] ERROR
> org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor:build-project -
> Error executing task
> edu.emory.mathcs.backport.java.util.concurrent.ExecutionException:
> javax.jdo.JDOFatalUserException: Attempt to store value
> "/soseco/dev/tahoe/applications/rcp/rcpmanager/src/main/java/biz/wss/rcp/rcpmanager/core/bundle/ManagerPartDelegateConfig.java
> (from
> /soseco/dev/tahoe/applications/rcp/rcpmanager/src/main/java/biz/wss/rcp/rcpmanager/parts/ManagerPartDelegateConfig.java:12912)"
> in column ""NAME"" that has maximum length of 256. Please correct your data!
> at
> edu.emory.mathcs.backport.java.util.concurrent.FutureTask.getResult(FutureTask.java:299)
> at
> edu.emory.mathcs.backport.java.util.concurrent.FutureTask.get(FutureTask.java:128)
> at
> org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.waitForTask(ThreadedTaskQueueExecutor.java:165)
> at
> org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:127)
> Caused by: javax.jdo.JDOFatalUserException: Attempt to store value
> "/soseco/dev/tahoe/applications/rcp/rcpmanager/src/main/java/biz/wss/rcp/rcpmanager/core/bundle/ManagerPartDelegateConfig.java
> (from
> /soseco/dev/tahoe/
[jira] Updated: (DOXIA-136) Create an FML DTD or XSD
[ http://jira.codehaus.org/browse/DOXIA-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated DOXIA-136: Attachment: DOXIA-136.diff I just fixed MODELLO-49 With the patch provided, 3 problems are away: - XML attributes - flat list - namespace There is still one problem to validate existing test.fml: answers contain HTML code not enclosed with , which is not supported by the simple xs:string type generated. I have to find a way to support that. Any thoughts? > Create an FML DTD or XSD > > > Key: DOXIA-136 > URL: http://jira.codehaus.org/browse/DOXIA-136 > Project: Maven Doxia > Issue Type: Task > Components: Module - Fml >Reporter: Vincent Siveton >Assignee: Vincent Siveton > Fix For: 1.0-beta-1 > > Attachments: DOXIA-136.diff > > > Review the M1 FAQ schema is certainly a good start. > http://maven.apache.org/maven-1.x/plugins/faq/faq.xsd -- 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-1509) always build option doesn't work with scheduler --> log = No files updated, not building
[ http://jira.codehaus.org/browse/CONTINUUM-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1509. --- Assignee: Emmanuel Venisse Resolution: Fixed Fixed. > always build option doesn't work with scheduler --> log = No files updated, > not building > - > > Key: CONTINUUM-1509 > URL: http://jira.codehaus.org/browse/CONTINUUM-1509 > Project: Continuum > Issue Type: Bug > Components: Core system >Affects Versions: 1.1-beta-3 > Environment: windows xp sp2 - maven 2.0.7 - continuum 1.1 beta 3 > -subversion 1.4.2 >Reporter: patrick roussel >Assignee: Emmanuel Venisse > Fix For: 1.1-beta-4 > > > when always build option is checked, scheduler doesn't work correctly --> No > files updated, not building > 4799733 [pool-1-thread-1] INFO > org.apache.maven.continuum.buildcontroller.BuildController:default - Merging > SCM results > 4800186 [pool-1-thread-1] INFO > org.apache.maven.continuum.buildcontroller.BuildController:default - > AlwaysBuild configured, building > 4800186 [pool-1-thread-1] INFO > org.apache.maven.continuum.buildcontroller.BuildController:default - > Performing action update-project-from-working-directory > 4800217 [pool-1-thread-1] INFO > org.codehaus.plexus.action.Action:update-project-from-working-directory - > Updating project 'Maven xxx Maintenance' from checkout. > 4803279 [pool-1-thread-1] INFO > org.apache.maven.continuum.buildcontroller.BuildController:default - > Performing action execute-builder > 4803279 [pool-1-thread-1] INFO > org.codehaus.plexus.action.Action:execute-builder - No files updated, not > building. Project id '1'. > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MJAVADOC-149) Newline in ${project.organization.name} makes javadoc fail
[
http://jira.codehaus.org/browse/MJAVADOC-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton closed MJAVADOC-149.
Assignee: Vincent Siveton
Resolution: Fixed
Fix Version/s: 2.4
Patch applied without the newlineFreeArgument() method: removed all newlines
directly in quotedArgument() method. Thanks.
> Newline in ${project.organization.name} makes javadoc fail
> --
>
> Key: MJAVADOC-149
> URL: http://jira.codehaus.org/browse/MJAVADOC-149
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.3
> Environment: Maven 2.0.7, JDK 1.5.0_12, Win
>Reporter: Benjamin Bentmann
>Assignee: Vincent Siveton
> Fix For: 2.4
>
> Attachments: remove-newlines.patch
>
>
> Consider the following POM snippet:
> {code}
>
> My company,
> my department
>
> {code}
> The Javadoc plugin outputs the following to the options file, using its
> default configuration:
> {code}-bottom
> 'Copyright © 2007 My company,
> my department. All Rights Reserved.'{code}
> This actually makes javadoc fail with the following errors:{code}javadoc:
> error - Illegal package name: "department."
> javadoc: error - Illegal package name: "Reserved."
> javadoc: error - Illegal package name: ""
> javadoc: warning - No source files for package my
> javadoc: warning - No source files for package All
> javadoc: warning - No source files for package Rights{code}
> Since line terminators are used as separators within the arg files, the
> Javadoc plugin should replace line terminators (in all fashions) with spaces
> before writing out any POM value so that the formatting of the XML contents
> does not matter.
--
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-157) Doxia Book doesn't work with xdoc source files
[ http://jira.codehaus.org/browse/DOXIA-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108995 ] David Roussel commented on DOXIA-157: - Lukas, There is no mention of using an xml declaration in http://maven.apache.org/doxia/references/xdoc-format.html, and also an xml declaration is optional according to the W3C XML 1.0 Recommendation. David > Doxia Book doesn't work with xdoc source files > -- > > Key: DOXIA-157 > URL: http://jira.codehaus.org/browse/DOXIA-157 > Project: Maven Doxia > Issue Type: Bug > Components: Book >Affects Versions: 1.0-alpha-9 >Reporter: Lukas Theussl > Fix For: 1.0-beta-1 > > Attachments: gioMaven.rar > > > Files with xml extension are parsed by the docbook parser. Doxia book doesn't > recognize the standard Maven site structure to determine the site module. -- 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-136) Create an FML DTD or XSD
[
http://jira.codehaus.org/browse/DOXIA-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108997
]
David Roussel commented on DOXIA-136:
-
Herve,
You can use the XML Schema any tag to define a wildcard
See: http://www.xml.com/pub/a/2002/11/20/schemas.html?page=4#wildcards
Given that most people won't be using namespaces with their XML, then you
should allow any namespace in the any tag.
e.g.
{code:xml}
{code}
> Create an FML DTD or XSD
>
>
> Key: DOXIA-136
> URL: http://jira.codehaus.org/browse/DOXIA-136
> Project: Maven Doxia
> Issue Type: Task
> Components: Module - Fml
>Reporter: Vincent Siveton
>Assignee: Vincent Siveton
> Fix For: 1.0-beta-1
>
> Attachments: DOXIA-136.diff
>
>
> Review the M1 FAQ schema is certainly a good start.
> http://maven.apache.org/maven-1.x/plugins/faq/faq.xsd
--
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-138) Review and clarify the APT guide
[ http://jira.codehaus.org/browse/DOXIA-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108998 ] David Roussel commented on DOXIA-138: - In Trac (the python based wiki http://trac.edgewall.org/) section heading produce anchors. This works well because: * the CSS shows an link to the anchor when a reader hovers of the heading, this makes it easy to discover an anchor, and copy the link to email to someone * duplicate headings are disabiguated The first time I was this in Trac I was really impressed. I'd never really seen anchors as a useful feature before in HTML. They had always been used inconsistently by document authors. And they were only for use by document authors, since it was easy for a user to discover them. The Trac model of anchors means the author doesn't need to think about anchors (and most authors don't anyway) but the user is able use them easily. Plus if you are writing a new page and want to refer to the section in another page, you don't have to go to the other page and add the anchor first, it's just there to be used. Try using the anchors in Trac and see what I mean. It just works. > Review and clarify the APT guide > > > Key: DOXIA-138 > URL: http://jira.codehaus.org/browse/DOXIA-138 > Project: Maven Doxia > Issue Type: Task > Components: Documentation, Module - Apt >Affects Versions: 1.0-alpha-8 >Reporter: Lukas Theussl > Fix For: 1.0 > > > Our current apt guide is a copy of > http://www.xmlmind.com/_aptconvert/docs/userguide2.html, but there are > several issues that need clarification, eg > * case sensitivity and white space handling in anchors > * anchors for section titles > * figure handling, esp extensions > * tables: is the first line always a header row? > Some of these depend on how things are going to be implemented. > We also decided to remove the apt guide at > http://maven.apache.org/guides/mini/guide-apt-format.html and only keep the > one on the doxia site. -- 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: (DOXIA-138) Review and clarify the APT guide
[ http://jira.codehaus.org/browse/DOXIA-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108998 ] David Roussel edited comment on DOXIA-138 at 10/4/07 6:14 AM: -- In Trac (the python based wiki http://trac.edgewall.org/) section headings are automatically anchors. This works well because: * the CSS shows an link to the anchor when a reader hovers of the heading, this makes it easy to discover an anchor, and copy the link to email to someone * duplicate headings are disambiguated The first time I was this in Trac I was really impressed. I'd never really seen anchors as a useful feature before in HTML. They had always been used inconsistently by document authors. And they were only for use by document authors, since it was easy for a user to discover them. The Trac model of anchors means the author doesn't need to think about anchors (and most authors don't anyway) but the user is able use them easily. Plus if you are writing a new page and want to refer to the section in another page, you don't have to go to the other page and add the anchor first, it's just there to be used. Try using the anchors in Trac and see what I mean. It just works. was: In Trac (the python based wiki http://trac.edgewall.org/) section heading produce anchors. This works well because: * the CSS shows an link to the anchor when a reader hovers of the heading, this makes it easy to discover an anchor, and copy the link to email to someone * duplicate headings are disambiguated The first time I was this in Trac I was really impressed. I'd never really seen anchors as a useful feature before in HTML. They had always been used inconsistently by document authors. And they were only for use by document authors, since it was easy for a user to discover them. The Trac model of anchors means the author doesn't need to think about anchors (and most authors don't anyway) but the user is able use them easily. Plus if you are writing a new page and want to refer to the section in another page, you don't have to go to the other page and add the anchor first, it's just there to be used. Try using the anchors in Trac and see what I mean. It just works. > Review and clarify the APT guide > > > Key: DOXIA-138 > URL: http://jira.codehaus.org/browse/DOXIA-138 > Project: Maven Doxia > Issue Type: Task > Components: Documentation, Module - Apt >Affects Versions: 1.0-alpha-8 >Reporter: Lukas Theussl > Fix For: 1.0 > > > Our current apt guide is a copy of > http://www.xmlmind.com/_aptconvert/docs/userguide2.html, but there are > several issues that need clarification, eg > * case sensitivity and white space handling in anchors > * anchors for section titles > * figure handling, esp extensions > * tables: is the first line always a header row? > Some of these depend on how things are going to be implemented. > We also decided to remove the apt guide at > http://maven.apache.org/guides/mini/guide-apt-format.html and only keep the > one on the doxia site. -- 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: (DOXIA-138) Review and clarify the APT guide
[ http://jira.codehaus.org/browse/DOXIA-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108998 ] David Roussel edited comment on DOXIA-138 at 10/4/07 6:14 AM: -- In Trac (the python based wiki http://trac.edgewall.org/) section heading produce anchors. This works well because: * the CSS shows an link to the anchor when a reader hovers of the heading, this makes it easy to discover an anchor, and copy the link to email to someone * duplicate headings are disambiguated The first time I was this in Trac I was really impressed. I'd never really seen anchors as a useful feature before in HTML. They had always been used inconsistently by document authors. And they were only for use by document authors, since it was easy for a user to discover them. The Trac model of anchors means the author doesn't need to think about anchors (and most authors don't anyway) but the user is able use them easily. Plus if you are writing a new page and want to refer to the section in another page, you don't have to go to the other page and add the anchor first, it's just there to be used. Try using the anchors in Trac and see what I mean. It just works. was: In Trac (the python based wiki http://trac.edgewall.org/) section heading produce anchors. This works well because: * the CSS shows an link to the anchor when a reader hovers of the heading, this makes it easy to discover an anchor, and copy the link to email to someone * duplicate headings are disabiguated The first time I was this in Trac I was really impressed. I'd never really seen anchors as a useful feature before in HTML. They had always been used inconsistently by document authors. And they were only for use by document authors, since it was easy for a user to discover them. The Trac model of anchors means the author doesn't need to think about anchors (and most authors don't anyway) but the user is able use them easily. Plus if you are writing a new page and want to refer to the section in another page, you don't have to go to the other page and add the anchor first, it's just there to be used. Try using the anchors in Trac and see what I mean. It just works. > Review and clarify the APT guide > > > Key: DOXIA-138 > URL: http://jira.codehaus.org/browse/DOXIA-138 > Project: Maven Doxia > Issue Type: Task > Components: Documentation, Module - Apt >Affects Versions: 1.0-alpha-8 >Reporter: Lukas Theussl > Fix For: 1.0 > > > Our current apt guide is a copy of > http://www.xmlmind.com/_aptconvert/docs/userguide2.html, but there are > several issues that need clarification, eg > * case sensitivity and white space handling in anchors > * anchors for section titles > * figure handling, esp extensions > * tables: is the first line always a header row? > Some of these depend on how things are going to be implemented. > We also decided to remove the apt guide at > http://maven.apache.org/guides/mini/guide-apt-format.html and only keep the > one on the doxia site. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSHADE-3) Add plugin site documentation
[ http://jira.codehaus.org/browse/MSHADE-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi closed MSHADE-3. - Resolution: Fixed > Add plugin site documentation > - > > Key: MSHADE-3 > URL: http://jira.codehaus.org/browse/MSHADE-3 > Project: Maven 2.x Shade Plugin > Issue Type: Task >Reporter: Mauro Talevi > > Plugin is missing site docs. > Document major features and test cases - taking ITs as example and deploy > site. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJAVADOC-153) Generate the OfflineLink class with Modello
Generate the OfflineLink class with Modello --- Key: MJAVADOC-153 URL: http://jira.codehaus.org/browse/MJAVADOC-153 Project: Maven 2.x Javadoc Plugin Issue Type: Improvement Affects Versions: 2.3 Reporter: Vincent Siveton -- 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-63) Add CSS style class to XHTML tags
[
http://jira.codehaus.org/browse/DOXIA-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109001
]
David Roussel commented on DOXIA-63:
It could be made more generic by changeing this:
{code}
if ( StringUtils.isNotEmpty( styleClass ) )
{
write( "" );
}
else
{
write( "" );
}
{code}
into this:
{code}
writeTag( "li", styleClass);
{code}
or even:
{code}
Map attributes = ... ;
writeTag( "li", attributes);
{code}
> Add CSS style class to XHTML tags
> -
>
> Key: DOXIA-63
> URL: http://jira.codehaus.org/browse/DOXIA-63
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Core
>Affects Versions: 1.0-alpha-8
>Reporter: Vance Karimi
>Priority: Minor
> Fix For: 1.0-beta-1
>
> Attachments: doxia-1.0-alpha-8-core-patch.txt,
> doxia-1.0-alpha-8-sink-api-patch.txt
>
>
> Add support for CSS style formatting with a class property on tags.
> Previously filed http://jira.codehaus.org/browse/MNG-545.
> Patches for core and sink-api for doxia-1.0-alpha-8 attached.
> It provides the following fixes:
> 1. class property on list and numbered list tag
> 2. class property on paragraph tag
> 3. class property on link tag
> 4. target property on link tag
> 5. class property on table cells
> 6. class property on table header cells
> 7. class property on anchors
> Is this an acceptable request or have people achieved CSS style differently
> when generating XHTML using Doxia?
> 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: (DOXIA-38) Independent row parsing
[ http://jira.codehaus.org/browse/DOXIA-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109002 ] David Roussel commented on DOXIA-38: This example appears messed up by JIRA formatting issues. > Independent row parsing > --- > > Key: DOXIA-38 > URL: http://jira.codehaus.org/browse/DOXIA-38 > Project: Maven Doxia > Issue Type: Improvement > Components: Core >Reporter: Anuerin Diaz >Priority: Minor > Fix For: 1.0-beta-1 > > > Currently the table rendered formats each column depending on the definition > of the first row. This is a problem when the text justification of the header > row is different from the rest of the table (e.g. the header row is centered, > but the rest of the table rows are left-aligned). Take this example fo > instance: > *---*--* > |<> |<> > | > *---+--+ > |generate-sources |generate any source code for inclusion in compilation. >| > *---+--+ > |generate-resources |generate resources for inclusion in the package. >| > *---+--+ > |compile |compile the source code of the project. > | > *---+--+ > |test |run tests using a suitable unit testing framework. > These tests| > | |should not require the code be packaged or deployed. > | > *---+--+ > |package |take the compiled code and package it in its > distributable format,| > | |such as JAR. > | > *---+--+ > |install |install the package into the local repository, for use > as a | > | |dependency in other projects locally. > | > *---+--+ > -- 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-1745) Upload bndlib 0.0.199 to central repository
Upload bndlib 0.0.199 to central repository --- Key: MAVENUPLOAD-1745 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1745 Project: maven-upload-requests Issue Type: Task Reporter: Stuart McCulloch Version 0.0.199 of the Bnd tool is needed to fix the following issue: https://issues.apache.org/jira/browse/FELIX-390 Thanks in advance! (perhaps Peter should start syncing his repository with central?) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DOXIA-38) Independent row parsing
[
http://jira.codehaus.org/browse/DOXIA-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Venisse updated DOXIA-38:
--
Description:
Currently the table rendered formats each column depending on the definition of
the first row. This is a problem when the text justification of the header row
is different from the rest of the table (e.g. the header row is centered, but
the rest of the table rows are left-aligned). Take this example fo instance:
{noformat}
*---*--*
|<> |<>
|
*---+--+
|generate-sources |generate any source code for inclusion in compilation.
|
*---+--+
|generate-resources |generate resources for inclusion in the package.
|
*---+--+
|compile |compile the source code of the project.
|
*---+--+
|test |run tests using a suitable unit testing framework.
These tests|
| |should not require the code be packaged or deployed.
|
*---+--+
|package|take the compiled code and package it in its
distributable format,|
| |such as JAR.
|
*---+--+
|install|install the package into the local repository, for use
as a |
| |dependency in other projects locally.
|
*---+--+
{noformat}
was:
Currently the table rendered formats each column depending on the definition of
the first row. This is a problem when the text justification of the header row
is different from the rest of the table (e.g. the header row is centered, but
the rest of the table rows are left-aligned). Take this example fo instance:
*---*--*
|<> |<>
|
*---+--+
|generate-sources |generate any source code for inclusion in compilation.
|
*---+--+
|generate-resources |generate resources for inclusion in the package.
|
*---+--+
|compile |compile the source code of the project.
|
*---+--+
|test |run tests using a suitable unit testing framework.
These tests|
| |should not require the code be packaged or deployed.
|
*---+--+
|package|take the compiled code and package it in its
distributable format,|
| |such as JAR.
|
*---+--+
|install|install the package into the local repository, for use
as a |
| |dependency in other projects locally.
|
*---+--+
> Independent row parsing
> ---
>
> Key: DOXIA-38
> URL: http://jira.codehaus.org/browse/DOXIA-38
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Core
>Reporter: Anuerin Diaz
>Priority: Minor
> Fix For: 1.0-beta-1
>
>
> Currently the table rendered formats each column depending on the definition
> of the first row. This is a problem when the text justification of the header
> row is different from the rest of the table (e.g. the header row is centered,
> but the rest of the table rows are left-aligned). Take this example fo
> instance:
> {noformat}
> *---*--*
> |
[jira] Created: (MAVENUPLOAD-1747) Junit Toolkit version 0.6
Junit Toolkit version 0.6 - Key: MAVENUPLOAD-1747 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1747 Project: maven-upload-requests Issue Type: Task Reporter: Rupert Smith JUnit Toolkit enhances JUnit with performance testing, asymptotic behaviour analysis, and concurrency testing. -- 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-1746) Synchronization script for ch.hortis.sonar
Synchronization script for ch.hortis.sonar -- Key: MAVENUPLOAD-1746 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1746 Project: maven-upload-requests Issue Type: Task Reporter: Simon Brandhof Attachments: ch.hortis.sonar.sh Please find the synchronization script with bundles published by sonar.hortis.ch in the attachments to this request. Please let me know if you encounter any problems. -- 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: (MJAVADOC-153) Generate the OfflineLink class with Modello
[ http://jira.codehaus.org/browse/MJAVADOC-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MJAVADOC-153. Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.4 Fixed with r581889 > Generate the OfflineLink class with Modello > --- > > Key: MJAVADOC-153 > URL: http://jira.codehaus.org/browse/MJAVADOC-153 > Project: Maven 2.x Javadoc Plugin > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Vincent Siveton >Assignee: Vincent Siveton > Fix For: 2.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: (MRM-525) Typos on the hacking page
[
http://jira.codehaus.org/browse/MRM-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109010
]
ajbanck commented on MRM-525:
-
Hi,
This issue is marked as fixed, but in trunk I still see the incorrect xml. I
also cant find a checkin of this patch. Was it really fixed?
> Typos on the hacking page
> -
>
> Key: MRM-525
> URL: http://jira.codehaus.org/browse/MRM-525
> Project: Archiva
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 1.0-beta-2
>Reporter: Alex Mayorga Adame
>Assignee: Alex Mayorga Adame
>Priority: Trivial
> Fix For: 1.0-beta-3
>
> Attachments: MRM-525.patch
>
>
> Julien Graglia reported the following typos on the [mailing list |
> http://www.nabble.com/forum/ViewPost.jtp?post=12896988]
> {quote}
> Hi,
> I'am not sure it's the correct place but there are 2 little mistakes in
> http://maven.apache.org/archiva/hacking/index.html
> in section "Building Archiva"
> 1/the links to dl the connector and jta are broken : they include the
> corrects url but with a "download from..." prefix
> 2/the install command of jta is broken : a '-' is missing before
> Dversion=1.0.1B
> mvn install:install-file -DgroupId=javax.transaction -DartifactId=jta
> -Dversion=1.0.1B -Dpackaging=jar -Dfile=jta-1_0_1B-classes.zip
> thats no real pbs, because if you start building archiva, you surely
> found (and correct) easyly those problems!
> --
> Julien Graglia
> {quote}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-259) Bump to new release of jetty
Bump to new release of jetty Key: MSITE-259 URL: http://jira.codehaus.org/browse/MSITE-259 Project: Maven 2.x Site Plugin Issue Type: Improvement Components: site:run Affects Versions: 2.0-beta-5 Reporter: Vincent Siveton site plugin uses a RC version of jetty. Should better to have 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] Created: (MAVENUPLOAD-1748) JUnit Toolkit 0.6 Maven Plugin
JUnit Toolkit 0.6 Maven Plugin -- Key: MAVENUPLOAD-1748 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1748 Project: maven-upload-requests Issue Type: Task Reporter: Rupert Smith Maven plugin for JUnit Toolkit 0.6, to generate test scripts, or to run tests directly as part of the 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: (MECLIPSE-266) plugin applies java facet to ear project
[ http://jira.codehaus.org/browse/MECLIPSE-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tionan Lim updated MECLIPSE-266: Attachment: MECLIPSE-266.patch > plugin applies java facet to ear project > > > Key: MECLIPSE-266 > URL: http://jira.codehaus.org/browse/MECLIPSE-266 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: WTP support >Affects Versions: 2.3 > Environment: Windows XP >Reporter: Srepfler Srgjan > Attachments: MECLIPSE-266.patch > > > In .settings/org.eclipse.wst.common.project.facet.core.xml of the EAR module > I'm getting this: > > > > > > > This is a wrong facet on a EAR module and I can't compile if I don't edit > this file manually (I can't do it from the project properties - facets dialog) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MRM-525) Typos on the hacking page
[
http://jira.codehaus.org/browse/MRM-525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joakim Erdfelt reopened MRM-525:
Assignee: Joakim Erdfelt (was: Alex Mayorga Adame)
Reopened at request of ajbanck.
> Typos on the hacking page
> -
>
> Key: MRM-525
> URL: http://jira.codehaus.org/browse/MRM-525
> Project: Archiva
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 1.0-beta-2
>Reporter: Alex Mayorga Adame
>Assignee: Joakim Erdfelt
>Priority: Trivial
> Fix For: 1.0-beta-3
>
> Attachments: MRM-525.patch
>
>
> Julien Graglia reported the following typos on the [mailing list |
> http://www.nabble.com/forum/ViewPost.jtp?post=12896988]
> {quote}
> Hi,
> I'am not sure it's the correct place but there are 2 little mistakes in
> http://maven.apache.org/archiva/hacking/index.html
> in section "Building Archiva"
> 1/the links to dl the connector and jta are broken : they include the
> corrects url but with a "download from..." prefix
> 2/the install command of jta is broken : a '-' is missing before
> Dversion=1.0.1B
> mvn install:install-file -DgroupId=javax.transaction -DartifactId=jta
> -Dversion=1.0.1B -Dpackaging=jar -Dfile=jta-1_0_1B-classes.zip
> thats no real pbs, because if you start building archiva, you surely
> found (and correct) easyly those problems!
> --
> Julien Graglia
> {quote}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-259) Bump to new release of jetty
[ http://jira.codehaus.org/browse/MSITE-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated MSITE-259: -- Affects Version/s: (was: 2.0-beta-5) 2.0-beta-6 Try to do it for beta-6 > Bump to new release of jetty > > > Key: MSITE-259 > URL: http://jira.codehaus.org/browse/MSITE-259 > Project: Maven 2.x Site Plugin > Issue Type: Improvement > Components: site:run >Affects Versions: 2.0-beta-6 >Reporter: Vincent Siveton > > site plugin uses a RC version of jetty. Should better to have 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: (DOXIA-38) Independent row parsing
[
http://jira.codehaus.org/browse/DOXIA-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109012
]
Lukas Theussl commented on DOXIA-38:
It appears fine to me. The problem is that the whole table is formatted
according to the first line (*---*---*) and the format for the following lines
(*---+---+) is ignored. Note that I have proposed a more general solution
already: http://docs.codehaus.org/display/DOXIA/Proposed+Changes+to+the+Sink+API
> Independent row parsing
> ---
>
> Key: DOXIA-38
> URL: http://jira.codehaus.org/browse/DOXIA-38
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Core
>Reporter: Anuerin Diaz
>Priority: Minor
> Fix For: 1.0-beta-1
>
>
> Currently the table rendered formats each column depending on the definition
> of the first row. This is a problem when the text justification of the header
> row is different from the rest of the table (e.g. the header row is centered,
> but the rest of the table rows are left-aligned). Take this example fo
> instance:
> {noformat}
> *---*--*
> |<> |<>
> |
> *---+--+
> |generate-sources |generate any source code for inclusion in compilation.
>|
> *---+--+
> |generate-resources |generate resources for inclusion in the package.
>|
> *---+--+
> |compile |compile the source code of the project.
> |
> *---+--+
> |test |run tests using a suitable unit testing framework.
> These tests|
> | |should not require the code be packaged or deployed.
> |
> *---+--+
> |package |take the compiled code and package it in its
> distributable format,|
> | |such as JAR.
> |
> *---+--+
> |install |install the package into the local repository, for use
> as a |
> | |dependency in other projects locally.
> |
> *---+--+
> {noformat}
>
--
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: (DOXIA-38) Independent row parsing
[
http://jira.codehaus.org/browse/DOXIA-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109012
]
Lukas Theussl edited comment on DOXIA-38 at 10/4/07 9:13 AM:
-
It appears fine to me. The problem is that the whole table is formatted
according to the first line {noformat} ( *---*---* ) {noformat} and the
format for the following lines {noformat}( *---+---+ ) {noformat} is ignored.
Note that I have proposed a more general solution already:
http://docs.codehaus.org/display/DOXIA/Proposed+Changes+to+the+Sink+API
was:
It appears fine to me. The problem is that the whole table is formatted
according to the first line (*---*---*) and the format for the following lines
(*---+---+) is ignored. Note that I have proposed a more general solution
already: http://docs.codehaus.org/display/DOXIA/Proposed+Changes+to+the+Sink+API
> Independent row parsing
> ---
>
> Key: DOXIA-38
> URL: http://jira.codehaus.org/browse/DOXIA-38
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Core
>Reporter: Anuerin Diaz
>Priority: Minor
> Fix For: 1.0-beta-1
>
>
> Currently the table rendered formats each column depending on the definition
> of the first row. This is a problem when the text justification of the header
> row is different from the rest of the table (e.g. the header row is centered,
> but the rest of the table rows are left-aligned). Take this example fo
> instance:
> {noformat}
> *---*--*
> |<> |<>
> |
> *---+--+
> |generate-sources |generate any source code for inclusion in compilation.
>|
> *---+--+
> |generate-resources |generate resources for inclusion in the package.
>|
> *---+--+
> |compile |compile the source code of the project.
> |
> *---+--+
> |test |run tests using a suitable unit testing framework.
> These tests|
> | |should not require the code be packaged or deployed.
> |
> *---+--+
> |package |take the compiled code and package it in its
> distributable format,|
> | |such as JAR.
> |
> *---+--+
> |install |install the package into the local repository, for use
> as a |
> | |dependency in other projects locally.
> |
> *---+--+
> {noformat}
>
--
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-525) Typos on the hacking page
[
http://jira.codehaus.org/browse/MRM-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109019
]
Alex Mayorga Adame commented on MRM-525:
My goof up, sorry. I don't have commit rights yet.
> Typos on the hacking page
> -
>
> Key: MRM-525
> URL: http://jira.codehaus.org/browse/MRM-525
> Project: Archiva
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 1.0-beta-2
>Reporter: Alex Mayorga Adame
>Assignee: Joakim Erdfelt
>Priority: Trivial
> Fix For: 1.0-beta-3
>
> Attachments: MRM-525.patch
>
>
> Julien Graglia reported the following typos on the [mailing list |
> http://www.nabble.com/forum/ViewPost.jtp?post=12896988]
> {quote}
> Hi,
> I'am not sure it's the correct place but there are 2 little mistakes in
> http://maven.apache.org/archiva/hacking/index.html
> in section "Building Archiva"
> 1/the links to dl the connector and jta are broken : they include the
> corrects url but with a "download from..." prefix
> 2/the install command of jta is broken : a '-' is missing before
> Dversion=1.0.1B
> mvn install:install-file -DgroupId=javax.transaction -DartifactId=jta
> -Dversion=1.0.1B -Dpackaging=jar -Dfile=jta-1_0_1B-classes.zip
> thats no real pbs, because if you start building archiva, you surely
> found (and correct) easyly those problems!
> --
> Julien Graglia
> {quote}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-138) Review and clarify the APT guide
[ http://jira.codehaus.org/browse/DOXIA-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109021 ] David Roussel commented on DOXIA-138: - Lukas, I agree it's an output level concern. David > Review and clarify the APT guide > > > Key: DOXIA-138 > URL: http://jira.codehaus.org/browse/DOXIA-138 > Project: Maven Doxia > Issue Type: Task > Components: Documentation, Module - Apt >Affects Versions: 1.0-alpha-8 >Reporter: Lukas Theussl > Fix For: 1.0 > > > Our current apt guide is a copy of > http://www.xmlmind.com/_aptconvert/docs/userguide2.html, but there are > several issues that need clarification, eg > * case sensitivity and white space handling in anchors > * anchors for section titles > * figure handling, esp extensions > * tables: is the first line always a header row? > Some of these depend on how things are going to be implemented. > We also decided to remove the apt guide at > http://maven.apache.org/guides/mini/guide-apt-format.html and only keep the > one on the doxia site. -- 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-138) Review and clarify the APT guide
[ http://jira.codehaus.org/browse/DOXIA-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109016 ] Lukas Theussl commented on DOXIA-138: - I don't deny that it's a useful feature, I used it a lot myself during my m1 days. The problem is that Doxia is a multi-format document processing engine, and while section anchors are usually fine for xhtml output, it simply won't work with other formats. Eg the example given at MPPDF-40 will make the fop pdf renderer bomb. My point of view is that such sink-dependent features should be implemented by a specialised, low-level sink, (ie the part of doxia that produces the end-user output), eg the SiteRendererSink in the site plugin, where you know that the output will always go to html. No parser should emit any event that was not there in the original document. This issue is about the apt format, if the apt parser emits anchors for section titles (before you know which kind of sink is going to consume the event), then there's going to be trouble. > Review and clarify the APT guide > > > Key: DOXIA-138 > URL: http://jira.codehaus.org/browse/DOXIA-138 > Project: Maven Doxia > Issue Type: Task > Components: Documentation, Module - Apt >Affects Versions: 1.0-alpha-8 >Reporter: Lukas Theussl > Fix For: 1.0 > > > Our current apt guide is a copy of > http://www.xmlmind.com/_aptconvert/docs/userguide2.html, but there are > several issues that need clarification, eg > * case sensitivity and white space handling in anchors > * anchors for section titles > * figure handling, esp extensions > * tables: is the first line always a header row? > Some of these depend on how things are going to be implemented. > We also decided to remove the apt guide at > http://maven.apache.org/guides/mini/guide-apt-format.html and only keep the > one on the doxia site. -- 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-157) Doxia Book doesn't work with xdoc source files
[ http://jira.codehaus.org/browse/DOXIA-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109017 ] Lukas Theussl commented on DOXIA-157: - You're right, the xml declaration is not absolutely necessary, but SHOULD be included always [1] :) We should update our docs, just for the sake of being pedantic. ;) [1] http://www.w3.org/TR/2006/REC-xml-20060816/#sec-prolog-dtd > Doxia Book doesn't work with xdoc source files > -- > > Key: DOXIA-157 > URL: http://jira.codehaus.org/browse/DOXIA-157 > Project: Maven Doxia > Issue Type: Bug > Components: Book >Affects Versions: 1.0-alpha-9 >Reporter: Lukas Theussl > Fix For: 1.0-beta-1 > > Attachments: gioMaven.rar > > > Files with xml extension are parsed by the docbook parser. Doxia book doesn't > recognize the standard Maven site structure to determine the site module. -- 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-1749) QuickServer v1.4.7
QuickServer v1.4.7 -- Key: MAVENUPLOAD-1749 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1749 Project: maven-upload-requests Issue Type: New Feature Reporter: Akshathkumar Shetty http://www.quickserver.org/maven_upload/QuickServer1.4.7-bundle.jar http://www.quickserver.org http://www.quickserver.org/team.html QuickServer is an open source Java library/framework for quick creation of robust multi-client TCP server applications. Please upload! -- 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: (MWAR-114) Different builds for ejb-client optional with parent
[ http://jira.codehaus.org/browse/MWAR-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Reilly updated MWAR-114: Attachment: MWAR114-maven-war-plugin-2.0.2.patch Patch provides solution for version 2.0.2 of plugin. > Different builds for ejb-client optional with parent > > > Key: MWAR-114 > URL: http://jira.codehaus.org/browse/MWAR-114 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Tim Reilly > Attachments: MWAR114-maven-war-plugin-2.0.2.patch, mytime.zip > > > When trying to package a j2ee project's ejb-client artifact in the ear /lib > directory the war plugin's optional attribute is ignored if building from the > parent app project. If you build from the parent project you get the > ejb-client packaged in the web-inf/lib directory. If you build the ejb, war, > and ear independently you get the ejb-client packaged in the ear /lib > directory. It seems when run from the parent project the dependency/artifact > doesn't have the optional attribute set. > Perhaps this is b/c the artifact is a project artifact that was attached from > the ejb plugin it is not resolved as optional when the dependency is resolved > from the war project. > Attaching Geronimo's mytime sample with modifications to reproduce the > behavior. -- 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-1750) jTDS version 1.2.2
jTDS version 1.2.2 -- Key: MAVENUPLOAD-1750 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1750 Project: maven-upload-requests Issue Type: Wish Reporter: Danilo Ghirardelli http://repository.openmindonline.it/_bundle-upload/jtds-1.2.2-bundle.jar http://jtds.sourceforge.net/index.html New version of jTDS. -- 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-1744) jTDS 1.2.2 Upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109032 ] Danilo Ghirardelli commented on MAVENUPLOAD-1744: - This bundle has no source code attached. If you prefer, mine has source code attached, in issue MAVENUPLOAD-1750. > jTDS 1.2.2 Upload > - > > Key: MAVENUPLOAD-1744 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1744 > Project: maven-upload-requests > Issue Type: Bug >Reporter: Dan Tran > > Latest JDBC Driver for SQL Server and Sybase Database Server from > http://jtds.sourceforge.net -- 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-136) Create an FML DTD or XSD
[
http://jira.codehaus.org/browse/DOXIA-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109035
]
Herve Boutemy commented on DOXIA-136:
-
Thanks David
Maven 1 faq.xsd contains:
{code:xml}
{code}
How does it compare to your proposal?
Then the other question is: how to represent it in fml.mdo?
Actually, answer is coded as:
{code:xml}
answer
String
...
{code}
Should it be transformed to:
{code:xml}
answer
XML
...
{code}
or
{code:xml}
answer
String
...
{code}
or ... ?
> Create an FML DTD or XSD
>
>
> Key: DOXIA-136
> URL: http://jira.codehaus.org/browse/DOXIA-136
> Project: Maven Doxia
> Issue Type: Task
> Components: Module - Fml
>Reporter: Vincent Siveton
>Assignee: Vincent Siveton
> Fix For: 1.0-beta-1
>
> Attachments: DOXIA-136.diff
>
>
> Review the M1 FAQ schema is certainly a good start.
> http://maven.apache.org/maven-1.x/plugins/faq/faq.xsd
--
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-1744) jTDS 1.2.2 Upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran closed MAVENUPLOAD-1744. - Resolution: Duplicate Please use MAVENUPLOAD-1750 instead > jTDS 1.2.2 Upload > - > > Key: MAVENUPLOAD-1744 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1744 > Project: maven-upload-requests > Issue Type: Bug >Reporter: Dan Tran > > Latest JDBC Driver for SQL Server and Sybase Database Server from > http://jtds.sourceforge.net -- 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: (MJAVADOC-135) Error parsing javadoc version when used with IBM jdk 1.4.2
[ http://jira.codehaus.org/browse/MJAVADOC-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MJAVADOC-135: --- Attachment: javadoc-version.patch As the existing patch most likely does not solve MJAVADOC-143, I would like to propose another approach. To my knowledge, the target platform for the plugin is Java 1.4, allowing the usage of regular expressions. Therefore, this patch tries to find the (first occurrence of the) pattern "#.#(.#)", leaving most of the parsing to the regex engine. Besides, the patch falls back to the output from stdout, if stderr is empty. I did not find any spec that guarantees that the version output will be on stderr, so I felt this would help robustness. Furthermore, a unit test is added to check the proper parsing of the various version outputs mentioned in this issue so far. As far as I got from the commit logs, the source of this whole problem (i.e. the additions made to support MJAVADOC-98) just exists to support another but exceptional use case. Having robustness in mind, the exceptional cases should have as less impact on the default case as possible. Therefore, the patch completely avoids calling getJavadocVersion() if the javadoc executable is not specified in the POM, i.e when the default javadoc for the currently running JVM is used as in previous versions of the plugin always the case. NOTE: The patch includes one TODO that somebody should deal with. It's rather a philosophical concern that the project leader should decide. > Error parsing javadoc version when used with IBM jdk 1.4.2 > -- > > Key: MJAVADOC-135 > URL: http://jira.codehaus.org/browse/MJAVADOC-135 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: IBM JDK 1.4.2 >Reporter: Manuel Santillán > Attachments: AbstractJavadocMojo.java.patch, javadoc-version.patch > > > Error parsing javadocVersion in plugin 2.3 when using IBM JDK. Plugin works > fine in version 2.2. > java.lang.NumberFormatException: For input string: "J2R" > at > java.lang.NumberFormatException.forInputString(NumberFormatException.java:63) > at > java.lang.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1230) > at java.lang.Float.parseFloat(Float.java:246) > at > org.apache.maven.plugin.javadoc.AbstractJavadocMojo.getJavadocVersion(AbstractJavadocMojo.java:2966) > at > org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeReport(AbstractJavadocMojo.java:1085) > at > org.apache.maven.plugin.javadoc.JavadocJar.execute(JavadocJar.java:108) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > 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:224) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60) > at java.lang.reflect.Method.invoke(Method.java:391) > 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) > [INFO] > > [INFO] Total time: 18 seconds > [INFO] Finished at: Mon Jul 23 10:57:16 CEST 2007 > [INFO] Final Memory: 12M/512M > [INFO] > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrator
[jira] Updated: (MWAR-114) Different builds for ejb-client optional with parent
[ http://jira.codehaus.org/browse/MWAR-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Reilly updated MWAR-114: Attachment: MWAR114-maven-war-plugin-2.1-alpha-1.patch Candidate patch for 2.1-alpha-1 > Different builds for ejb-client optional with parent > > > Key: MWAR-114 > URL: http://jira.codehaus.org/browse/MWAR-114 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Tim Reilly > Attachments: MWAR114-maven-war-plugin-2.0.2.patch, > MWAR114-maven-war-plugin-2.0.2.patch, > MWAR114-maven-war-plugin-2.1-alpha-1.patch, mytime.zip > > > When trying to package a j2ee project's ejb-client artifact in the ear /lib > directory the war plugin's optional attribute is ignored if building from the > parent app project. If you build from the parent project you get the > ejb-client packaged in the web-inf/lib directory. If you build the ejb, war, > and ear independently you get the ejb-client packaged in the ear /lib > directory. It seems when run from the parent project the dependency/artifact > doesn't have the optional attribute set. > Perhaps this is b/c the artifact is a project artifact that was attached from > the ejb plugin it is not resolved as optional when the dependency is resolved > from the war project. > Attaching Geronimo's mytime sample with modifications to reproduce the > behavior. -- 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: (MWAR-114) Different builds for ejb-client optional with parent
[ http://jira.codehaus.org/browse/MWAR-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Reilly updated MWAR-114: Attachment: MWAR114-maven-war-plugin-2.0.2.patch Fixed the the relative path in the previous patch file - Index: maven-war-plugin-2.0.2/src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java + Index: src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java > Different builds for ejb-client optional with parent > > > Key: MWAR-114 > URL: http://jira.codehaus.org/browse/MWAR-114 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Tim Reilly > Attachments: MWAR114-maven-war-plugin-2.0.2.patch, > MWAR114-maven-war-plugin-2.0.2.patch, mytime.zip > > > When trying to package a j2ee project's ejb-client artifact in the ear /lib > directory the war plugin's optional attribute is ignored if building from the > parent app project. If you build from the parent project you get the > ejb-client packaged in the web-inf/lib directory. If you build the ejb, war, > and ear independently you get the ejb-client packaged in the ear /lib > directory. It seems when run from the parent project the dependency/artifact > doesn't have the optional attribute set. > Perhaps this is b/c the artifact is a project artifact that was attached from > the ejb plugin it is not resolved as optional when the dependency is resolved > from the war project. > Attaching Geronimo's mytime sample with modifications to reproduce the > behavior. -- 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: (MJAVADOC-144) Cannot generate Javadoc on Mac OS X if path contains space characters
[
http://jira.codehaus.org/browse/MJAVADOC-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109042
]
Benjamin Bentmann commented on MJAVADOC-144:
bq. Caused by: org.apache.maven.reporting.MavenReportException: Exit code: 1 -
javadoc: error - cannot read options (No such file or directory)
I do not believe that the options or packages file are the trouble makers.
bq. Command line was:"cd /Users/clabu/Documents/workarea/Elk
API/target/site/apidocs &&
/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc"
@options @packages
To me, it seems rather like a problem with Plexus' CommandLineUtils and related
classes. From MJAVADOC-127 I noticed that the shell in question for the Mac
environment here might be the org.codehaus.plexus.util.cli.shell.BourneShell.
Now, look at its source:{code}public String getExecutable()
{
File wd = getWorkingDirectory();
if ( wd != null )
{
String path = getWorkingDirectory().getAbsolutePath();
String exe = super.getExecutable();
return "cd " + handleQuote( path ) + " && " + handleQuote( exe );
}
else
{
return super.getExecutable();
}
}{code}
They do not seem to care about spaces in the pathes. I am not sure, but it
could result in the effective command working directory
"/Users/clabu/Documents/workarea/Elk", where no options or package files exist.
> Cannot generate Javadoc on Mac OS X if path contains space characters
> -
>
> Key: MJAVADOC-144
> URL: http://jira.codehaus.org/browse/MJAVADOC-144
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.3
> Environment: Maven version: 2.0.7
> Java version: 1.5.0_07
> OS name: "mac os x" version: "10.4.10" arch: "i386"
>Reporter: Claes Buckwalter
>
> Running 'mvn javadoc:javadoc' fails if the path to the current directory
> contains a space character. It works with the 2.0 version of the plugin. It
> also works if I rename the directory so that it does not contain a space
> character.
> presley:~/Documents/workarea/Elk API clabu$ mvn -e javadoc:javadoc
> + Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'javadoc'.
> [INFO]
>
> [INFO] Building The Elk Framework
> [INFO]task-segment: [javadoc:javadoc] (aggregator-style)
> [INFO]
>
> [INFO] Preparing javadoc:javadoc
> [INFO]
>
> [INFO] Building The Elk Framework
> [INFO]
>
> [INFO] No goals needed for project - skipping
> [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.properties
> [INFO] Default ResourceManager initializing. (class
> org.apache.velocity.runtime.resource.ResourceManagerImpl)
> [INFO] Resource Loader Instantiated:
> org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader
> [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 'VM_global_library.vm'
> [INFO]
[jira] Issue Comment Edited: (MJAVADOC-144) Cannot generate Javadoc on Mac OS X if path contains space characters
[
http://jira.codehaus.org/browse/MJAVADOC-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109042
]
Benjamin Bentmann edited comment on MJAVADOC-144 at 10/4/07 12:04 PM:
--
bq. Caused by: org.apache.maven.reporting.MavenReportException: Exit code: 1 -
javadoc: error - cannot read options (No such file or directory)
I do not believe that the options file is the trouble maker, it is not found by
javadoc.
bq. Command line was:"cd /Users/clabu/Documents/workarea/Elk
API/target/site/apidocs && ..." @options @packages
To me, it seems rather like a problem with Plexus' CommandLineUtils and related
classes. From MJAVADOC-127 I noticed that the shell in question for the Mac
environment here might be the org.codehaus.plexus.util.cli.shell.BourneShell.
Now, look at its source:{code}public String getExecutable()
{
File wd = getWorkingDirectory();
if ( wd != null )
{
String path = getWorkingDirectory().getAbsolutePath();
String exe = super.getExecutable();
return "cd " + handleQuote( path ) + " && " + handleQuote( exe );
}
else
{
return super.getExecutable();
}
}{code}
They do not seem to care about spaces in the pathes. I am not sure, but it
could result in the effective command working directory
"/Users/clabu/Documents/workarea/Elk", where no options or package files exist.
was:
bq. Caused by: org.apache.maven.reporting.MavenReportException: Exit code: 1 -
javadoc: error - cannot read options (No such file or directory)
I do not believe that the options or packages file are the trouble makers.
bq. Command line was:"cd /Users/clabu/Documents/workarea/Elk
API/target/site/apidocs &&
/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc"
@options @packages
To me, it seems rather like a problem with Plexus' CommandLineUtils and related
classes. From MJAVADOC-127 I noticed that the shell in question for the Mac
environment here might be the org.codehaus.plexus.util.cli.shell.BourneShell.
Now, look at its source:{code}public String getExecutable()
{
File wd = getWorkingDirectory();
if ( wd != null )
{
String path = getWorkingDirectory().getAbsolutePath();
String exe = super.getExecutable();
return "cd " + handleQuote( path ) + " && " + handleQuote( exe );
}
else
{
return super.getExecutable();
}
}{code}
They do not seem to care about spaces in the pathes. I am not sure, but it
could result in the effective command working directory
"/Users/clabu/Documents/workarea/Elk", where no options or package files exist.
> Cannot generate Javadoc on Mac OS X if path contains space characters
> -
>
> Key: MJAVADOC-144
> URL: http://jira.codehaus.org/browse/MJAVADOC-144
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.3
> Environment: Maven version: 2.0.7
> Java version: 1.5.0_07
> OS name: "mac os x" version: "10.4.10" arch: "i386"
>Reporter: Claes Buckwalter
>
> Running 'mvn javadoc:javadoc' fails if the path to the current directory
> contains a space character. It works with the 2.0 version of the plugin. It
> also works if I rename the directory so that it does not contain a space
> character.
> presley:~/Documents/workarea/Elk API clabu$ mvn -e javadoc:javadoc
> + Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'javadoc'.
> [INFO]
>
> [INFO] Building The Elk Framework
> [INFO]task-segment: [javadoc:javadoc] (aggregator-style)
> [INFO]
>
> [INFO] Preparing javadoc:javadoc
> [INFO]
>
> [INFO] Building The Elk Framework
> [INFO]
>
> [INFO] No goals needed for project - skipping
> [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.properties
> [INFO] Default ResourceManager initializing. (class
> org
[jira] Created: (MENFORCER-18) Bean shell enforcer swallows message
Bean shell enforcer swallows message
Key: MENFORCER-18
URL: http://jira.codehaus.org/browse/MENFORCER-18
Project: Maven 2.x Enforcer Plugin
Issue Type: Improvement
Components: Standard Rules
Affects Versions: 1.0-alpha-3
Reporter: David Dossot
Assignee: Brian Fox
The message does not display in the console, because the original
EnforcerRuleException is wrapped into another one:
throw new EnforcerRuleException( this.message );
}
}
catch ( Exception e )
{
throw new EnforcerRuleException( "Unable to lookup a component", e
);
}
and the console does not display root causes (even with -e, the root cause does
not show), living us with "Unable to lookup a component" as an explanation of
the rule violation:
[INFO] Scanning for projects...
[INFO]
[INFO] Building xxx
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory xxx
[INFO] [enforcer:enforce {execution: enforce-beanshell}]
[WARNING] Rule 0: org.apache.maven.plugin.enforcer.EvaluateBeanshell failed
with message: Unable to lookup a component
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Some Enforcer rules have failed. Look above for specific messages
explaining why the rule failed.
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 2 seconds
[INFO] Finished at: Thu Oct 04 12:00:25 PDT 2007
[INFO] Final Memory: 6M/12M
[INFO]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-1508) NullPointerException when adding an empty installation to a profile
[
http://jira.codehaus.org/browse/CONTINUUM-1508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed CONTINUUM-1508.
---
Resolution: Fixed
fix svn rev 581997
> NullPointerException when adding an empty installation to a profile
> ---
>
> Key: CONTINUUM-1508
> URL: http://jira.codehaus.org/browse/CONTINUUM-1508
> Project: Continuum
> Issue Type: Bug
> Components: Web interface
>Affects Versions: 1.1-beta-3
>Reporter: George Gastaldi
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 1.1-beta-4
>
>
> Steps to reproduce the problem:
> 1) Install Continuum;
> 2) Go to "Profiles"
> 3) Create a new profile
> 4) Click the "Add" button (is empty, no installation defined).
> BTW, Profiles must be enabled only when an installation exist
> StackTrace:
> {code}
> java.lang.NullPointerException
> at
> org.apache.maven.continuum.profile.DefaultProfileService.addInstallationInProfile(DefaultProfileService.java:180)
> at
> org.apache.maven.continuum.web.action.admin.ProfileAction.addInstallation(ProfileAction.java:155)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:358)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:218)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:192)
> at
> org.codehaus.plexus.xwork.interceptor.PlexusReleaseComponentInterceptor.intercept(PlexusReleaseComponentInterceptor.java:69)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:175)
> at
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115)
> at
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> org.apache.maven.continuum.web.interceptor.ForceContinuumConfigurationInterceptor.intercept(ForceContinuumConfigurationInterceptor.java:72)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> org.codehaus.plexus.redback.xwork.interceptor.PolicyEnforcementInterceptor.intercept(PolicyEnforcementInterceptor.java:118)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> org.codehaus.plexus.redback.xwork.interceptor.SecureActionInterceptor.intercept(SecureActionInterceptor.java:159)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> org.codehaus.plexus.xwork.interceptor.ExceptionMappingInterceptor.intercept(ExceptionMappingInterceptor.java:58)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:175)
> at
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115)
> at
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31)
> at
> com.opensymphony.xwork.DefaultA
[jira] Created: (MRM-532) Unable to specify the location of the index files through the web ui
Unable to specify the location of the index files through the web ui Key: MRM-532 URL: http://jira.codehaus.org/browse/MRM-532 Project: Archiva Issue Type: Bug Components: web application Affects Versions: 1.0-beta-2 Reporter: Wendy Smoak Priority: Minor There is currently no way to configure the location of the Lucene index files through the web ui. Workaround: edit archiva.xml and provide ... /path/to/index-dir -- 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-158) doxia book with APT verbatim text not monospaced in PDF
doxia book with APT verbatim text not monospaced in PDF --- Key: DOXIA-158 URL: http://jira.codehaus.org/browse/DOXIA-158 Project: Maven Doxia Issue Type: Bug Components: Module - Itext Affects Versions: 1.0-alpha-9 Environment: Java 5 on WinXP Reporter: David Roussel I'm using doxia-maven-plugin 1.0-alpha-9 with APT as an imput source. When I generate xhtml then the verbatim text comes out fine as a pre tag. When I generate PDF the verbatim text is rendered with a variable width font, thus my code examples are all over the place. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-1487) should not be allowed to delete a build result that is still executing
[ http://jira.codehaus.org/browse/CONTINUUM-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated CONTINUUM-1487: Ok I see the point. We can check buildResult.state != ContinuumProjectState.BUILDING. This will work except when the build has been cancelled. In this case, I'm not sure we can know that and we must be able to delete this buildResult. Idea ? > should not be allowed to delete a build result that is still executing > -- > > Key: CONTINUUM-1487 > URL: http://jira.codehaus.org/browse/CONTINUUM-1487 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-3 >Reporter: Brett Porter >Assignee: Olivier Lamy > Fix For: 1.1-beta-4 > > > note that deleting the build result from on the build result page also seems > to skip confirmation. All I did was hit the space bar... -- 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-477) Missing ability to manage proxy order.
[ http://jira.codehaus.org/browse/MRM-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-477. -- Resolution: Fixed Fixed in archiva/trunk revision 582020. > Missing ability to manage proxy order. > -- > > Key: MRM-477 > URL: http://jira.codehaus.org/browse/MRM-477 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Affects Versions: 1.0-beta-1 >Reporter: Joakim Erdfelt >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-3 > > > Dan Tran brought up a good point about Proxy Connectors and search order. > Reference: http://www.nabble.com/The-order-to-proxy-connectors-p12138354.html > --(snip)-- > Hello, I would like to setup archiva to search for java.net first then > repo1.maven.org. And archive user interface does not seem to support this > option. > Can some one confirm? > this is a work around for http://jira.codehaus.org/browse/MEV-498 > Thanks > --(snip)-- -- 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-482) Saving a proxy connector after adding a new property results to HTTP 500 error
[ http://jira.codehaus.org/browse/MRM-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-482. -- Resolution: Fixed Fixed in archiva/trunk revision 582020. > Saving a proxy connector after adding a new property results to HTTP 500 error > -- > > Key: MRM-482 > URL: http://jira.codehaus.org/browse/MRM-482 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-beta-1 >Reporter: Maria Odea Ching >Assignee: Joakim Erdfelt >Priority: Critical > Fix For: 1.0-beta-3 > > > This was the stack trace: > HTTP ERROR: 500 > [Ljava.lang.String; cannot be cast to java.lang.String > RequestURI=/admin/saveProxyConnector.action > Caused by: > java.lang.ClassCastException: [Ljava.lang.String; cannot be cast to > java.lang.String > at > org.apache.maven.archiva.configuration.io.registry.ConfigurationRegistryWriter.writeProxyConnectorConfiguration(ConfigurationRegistryWriter.java:326) > at > org.apache.maven.archiva.configuration.io.registry.ConfigurationRegistryWriter.writeConfiguration(ConfigurationRegistryWriter.java:67) > at > org.apache.maven.archiva.configuration.io.registry.ConfigurationRegistryWriter.write(ConfigurationRegistryWriter.java:31) > at > org.apache.maven.archiva.configuration.DefaultArchivaConfiguration.save(DefaultArchivaConfiguration.java:183) > at > org.apache.maven.archiva.web.action.admin.connectors.proxy.ConfigureProxyConnectorAction.saveConfiguration(ConfigureProxyConnectorAction.java:600) > at > org.apache.maven.archiva.web.action.admin.connectors.proxy.ConfigureProxyConnectorAction.save(ConfigureProxyConnectorAction.java:480) > 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 > com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:364) > at > com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:216) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:168) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > org.apache.maven.archiva.web.interceptor.ConfigurationInterceptor.intercept(ConfigurationInterceptor.java:81) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > org.codehaus.plexus.redback.xwork.interceptor.PolicyEnforcementInterceptor.intercept(PolicyEnforcementInterceptor.java:103) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > org.codehaus.plexus.redback.xwork.interceptor.SecureActionInterceptor.intercept(SecureActionInterceptor.java:159) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.interceptor.ParameterFilterInterceptor.intercept(ParameterFilterInterceptor.java:122) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:168) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.inv
[jira] Closed: (MRM-437) admin editing of proxy connectors fails in multiple instances
[ http://jira.codehaus.org/browse/MRM-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-437. -- Resolution: Fixed Fixed in archiva/trunk revision 582020. > admin editing of proxy connectors fails in multiple instances > - > > Key: MRM-437 > URL: http://jira.codehaus.org/browse/MRM-437 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-beta-1 >Reporter: Brett Porter >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-3 > > > I've seen the following: > - edit first one and save (order changes) > - edit new first one and save (end up with the same connector for both, eg > the blacklist is duplicated) > - in other circumstances, I'd seen editing the proxy connector produce a > second one > - removing the corresponding remote repository doesn't remove the associated > network proxy. > I believe this entire set of actions needs a review. -- 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-1499) Translate to Brazilian Portuguese
[ http://jira.codehaus.org/browse/CONTINUUM-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109071 ] Olivier Lamy commented on CONTINUUM-1499: - Submiited in rev 582021. (adding missing license in some) Can you try it ? Some files are missing in directories (can you provide it ?) : - continuum-webapp/src/main/resources/org/apache/maven/continuum/web/action/admin/ - continuum-webapp/src/main/resources/org/apache/maven/continuum/web/action/notifier/ Thanks. > Translate to Brazilian Portuguese > - > > Key: CONTINUUM-1499 > URL: http://jira.codehaus.org/browse/CONTINUUM-1499 > Project: Continuum > Issue Type: Sub-task > Components: Web - UI >Reporter: George Gastaldi >Assignee: Olivier Lamy >Priority: Minor > Fix For: 1.1-beta-4 > > Attachments: CONTINUUM-1499-gastaldi.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] Updated: (CONTINUUM-1499) Translate to Brazilian Portuguese
[ http://jira.codehaus.org/browse/CONTINUUM-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated CONTINUUM-1499: Fix Version/s: (was: To Sort) 1.1-beta-4 > Translate to Brazilian Portuguese > - > > Key: CONTINUUM-1499 > URL: http://jira.codehaus.org/browse/CONTINUUM-1499 > Project: Continuum > Issue Type: Sub-task > Components: Web - UI >Reporter: George Gastaldi >Assignee: Olivier Lamy >Priority: Minor > Fix For: 1.1-beta-4 > > Attachments: CONTINUUM-1499-gastaldi.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] Closed: (MRM-517) Some maven 2 requests are treated as maven 1 requests
[ http://jira.codehaus.org/browse/MRM-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-517. -- Resolution: Fixed Patch applied to archiva/trunk revision 582024. Thank you nicolas! > Some maven 2 requests are treated as maven 1 requests > - > > Key: MRM-517 > URL: http://jira.codehaus.org/browse/MRM-517 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-beta-2, 1.0-beta-3 >Reporter: James William Dumay >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-3 > > Attachments: error.txt, MRM-517.patch > > > We requested the following artifact's from our public Archiva instance which > resulted in the attached error.txt > fop:fop:trunk-534713-atlassian - > https://maven.atlassian.com/repository/public/fop/fop/trunk-534713-atlassian/fop-trunk-534713-atlass > org.hibernate:jtidy:r8-21122004 - > https://maven.atlassian.com/repository/public/org/hibernate/jtidy/r8-21122004/jtidy-r8-21122004.jar > Brett looked at this and said that Archiva is interpreting both of these urls > as maven1 requests and breaking. -- 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-242) RAD goal: missing lib-modules in .websettings
[ http://jira.codehaus.org/browse/MECLIPSE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MECLIPSE-242. -- Assignee: Brian Fox Resolution: Fixed Patch is merged and deployed > RAD goal: missing lib-modules in .websettings > - > > Key: MECLIPSE-242 > URL: http://jira.codehaus.org/browse/MECLIPSE-242 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: RAD support >Affects Versions: 2.3, 2.4 > Environment: IBM Rational Application Developer 6.0.x >Reporter: Klaus Brunner >Assignee: Brian Fox > Attachments: addedTestFiles.patch, addedTestFiles.tgz, > MECLIPSE-242-for-2.5-SNAPSHOT.patch, RadWebSettingsWriter.java > > > The eclipse:rad goal does not currently write the lib-modules element of the > .websettings file. When developing with RAD and WAS, this results in > dependent projects' code not being packaged and deployed as part of the WAR > by the RAD build and deploy process. This applies to project dependencies > only. > Adapted version of RadWebSettingsWriter.java is 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: (MRM-533) Checksum files (sha1/md5) are not kept up to date on maven-metadata.xml files.
Checksum files (sha1/md5) are not kept up to date on maven-metadata.xml files. -- Key: MRM-533 URL: http://jira.codehaus.org/browse/MRM-533 Project: Archiva Issue Type: Bug Components: repository scanning Affects Versions: 1.0-beta-2 Reporter: Joakim Erdfelt When the maven-metadata.xml files are updated, the associated sha1 and md5 checksums are not updated with it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-1499) Translate to Brazilian Portuguese
[ http://jira.codehaus.org/browse/CONTINUUM-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Gastaldi updated CONTINUUM-1499: --- Attachment: CONTINUUM-1499-gastaldi-2.patch Here comes the patch !! Some strings were corrected on Continuum_pt_BR.properties too > Translate to Brazilian Portuguese > - > > Key: CONTINUUM-1499 > URL: http://jira.codehaus.org/browse/CONTINUUM-1499 > Project: Continuum > Issue Type: Sub-task > Components: Web - UI >Reporter: George Gastaldi >Assignee: Olivier Lamy >Priority: Minor > Fix For: 1.1-beta-4 > > Attachments: CONTINUUM-1499-gastaldi-2.patch, > CONTINUUM-1499-gastaldi.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] Commented: (CONTINUUM-1130) can't delete default project group
[ http://jira.codehaus.org/browse/CONTINUUM-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109076 ] George Gastaldi commented on CONTINUUM-1130: It is still a problem in version 1.1-beta-3. > can't delete default project group > -- > > Key: CONTINUUM-1130 > URL: http://jira.codehaus.org/browse/CONTINUUM-1130 > Project: Continuum > Issue Type: Bug > Components: Core system, Database >Affects Versions: 1.1-alpha-1 >Reporter: Brett Porter > Fix For: Future > > > I don't really want/need this - but after deleting it, it keeps coming back -- 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-514) Archiva cannot compile and pass tests on JDK 1.6
[ http://jira.codehaus.org/browse/MRM-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dietrich Schulten updated MRM-514: -- Attachment: TEST-org.apache.maven.archiva.policies.ChecksumPolicyTest.zip Build failed with test error > Archiva cannot compile and pass tests on JDK 1.6 > > > Key: MRM-514 > URL: http://jira.codehaus.org/browse/MRM-514 > Project: Archiva > Issue Type: Bug > Components: system >Affects Versions: 1.0-beta-2 >Reporter: Joakim Erdfelt >Priority: Minor > Fix For: 1.x > > Attachments: > TEST-org.apache.maven.archiva.policies.ChecksumPolicyTest.zip > > > When using JDK 1.6, Archiva cannot compile and pass all of its unit tests. -- 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
