[jira] Created: (MAVENUPLOAD-1328) upload xSocket V1.0-beta-3
upload xSocket V1.0-beta-3 -- Key: MAVENUPLOAD-1328 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1328 Project: maven-upload-requests Issue Type: Task Reporter: greg xSocket is a easy to use nio-based library to build high performance, high scalable network applications -- 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-1139) pom.xml should be added by default in the "add build definition" if the project is a maven2 project
[ http://jira.codehaus.org/browse/CONTINUUM-1139?page=all ] Teodoro Cue Jr. updated CONTINUUM-1139: --- Attachment: CONTINUUM-1139-continuum-webapp.patch Attached fix for this. > pom.xml should be added by default in the "add build definition" if the > project is a maven2 project > --- > > Key: CONTINUUM-1139 > URL: http://jira.codehaus.org/browse/CONTINUUM-1139 > Project: Continuum > Issue Type: Improvement > Components: Web - UI >Reporter: Teodoro Cue Jr. > Assigned To: Teodoro Cue Jr. >Priority: Minor > Attachments: CONTINUUM-1139-continuum-webapp.patch > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1139) pom.xml should be added by default in the "add build definition" if the project is a maven2 project
pom.xml should be added by default in the "add build definition" if the project is a maven2 project --- Key: CONTINUUM-1139 URL: http://jira.codehaus.org/browse/CONTINUUM-1139 Project: Continuum Issue Type: Improvement Components: Web - UI Reporter: Teodoro Cue Jr. Priority: Minor -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-74) Added muse format to doxia-core
[ http://jira.codehaus.org/browse/DOXIA-74?page=comments#action_85215 ] Arnaud Bailly commented on DOXIA-74: I'd rather the module solution, it's what I tried at first, but I could not make it work. As noted on my comments, this is probably related to http://jira.codehaus.org/browse/DOXIA-68. If you think I can just add a new module, I would definitely adopt this solution and you could drop the patch. > Added muse format to doxia-core > --- > > Key: DOXIA-74 > URL: http://jira.codehaus.org/browse/DOXIA-74 > Project: doxia > Issue Type: New Feature > Components: Core >Affects Versions: 1.0-alpha-8 >Reporter: Arnaud Bailly >Priority: Minor > Fix For: 1.0-alpha-8 > > Attachments: patch-doxia-1.0-alpha-8, patch-doxia-1.0-alpha-8-1.0-rc3 > > > As a workaround to DOXIA-68 bug, I have m\ade a patch to > doxia-core-1.0-alpha-8 that include necessary code for generating maven sites > from muse syntax and add a dependency to muse-parser from doxia-core pom.xml. > This patch may be useful for people who wish to write their documentation > using Emacs muse mode. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-60) Use a external XML Pull parser instead of plexus one
[ http://jira.codehaus.org/browse/DOXIA-60?page=comments#action_85213 ] Carlos Sanchez commented on DOXIA-60: - i haven't touched anything, I think woodstox has been included in some parts of core maven > Use a external XML Pull parser instead of plexus one > > > Key: DOXIA-60 > URL: http://jira.codehaus.org/browse/DOXIA-60 > Project: doxia > Issue Type: Improvement > Components: Core >Reporter: Carlos Sanchez >Priority: Critical > > To avoid maintaining the plexus XMLPullParser we should move to a standard > implementation like Codehaus StaX http://stax.codehaus.org > > stax > stax > 1.2.0_rc2-dev > -- 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: (WAGON-70) Deploying using scp:// hangs when proxy configured in settings.xml
[ http://jira.codehaus.org/browse/WAGON-70?page=comments#action_85210 ]
Stephen Coy commented on WAGON-70:
--
Here is the proxy config from settings.xml:
optus
false
steve.coy
XXX
http
proxy.optus.com.au
8080
*.optus.com.au
and here is the element from distributionManagement section of the
pom.xml:
inhouse
Maven Project Web Server
scp://webdevappl005.optus.com.au/var/webdev/master/${project.version}
> Deploying using scp:// hangs when proxy configured in settings.xml
> --
>
> Key: WAGON-70
> URL: http://jira.codehaus.org/browse/WAGON-70
> Project: wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 1.0-beta-2
> Environment: Windows XP in a corporate environment that is proxied
> and firewalled to everywhere
>Reporter: Stephen Coy
>
> For some reason, wagon-ssh is attempting to connect to the proxy defined in
> settings.xml (irrespective of whether it is enabled or not) in order to
> perform an scp transfer.
> This causes goals such as site:deploy to hang for some time before proceeding
> normally.
> A thread dump taken during the hang:
> [INFO] [site:deploy]
> Full thread dump Java HotSpot(TM) Client VM (1.4.2_13-b06 mixed mode):
> "Signal Dispatcher" daemon prio=10 tid=0x009cf600 nid=0xa7c waiting on
> condition [0x..0x]
> "Finalizer" daemon prio=9 tid=0x009ccbb8 nid=0xb84 in Object.wait()
> [0x02b6f000..0x02b6fd68]
> at java.lang.Object.wait(Native Method)
> - waiting on <0x104fb160> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111)
> - locked <0x104fb160> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127)
> at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
> "Reference Handler" daemon prio=10 tid=0x009cb830 nid=0xf38 in Object.wait()
> [0x02b2f000..0x02b2fd68]
> at java.lang.Object.wait(Native Method)
> - waiting on <0x104fb1c8> (a java.lang.ref.Reference$Lock)
> at java.lang.Object.wait(Object.java:429)
> at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:115)
> - locked <0x104fb1c8> (a java.lang.ref.Reference$Lock)
> "main" prio=5 tid=0x00035b28 nid=0xe90 runnable [0x0007f000..0x0007fc38]
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:129)
> at java.net.SocketInputStream.read(SocketInputStream.java:182)
> at com.jcraft.jsch.ProxyHTTP.connect(Unknown Source)
> at
> org.apache.maven.wagon.providers.ssh.AbstractSshWagon.openConnection(AbstractSshWagon.java:181)
> at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143)
> at
> org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:149)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
--
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.atlass
[jira] Created: (WAGON-70) Deploying using scp:// hangs when proxy configured in settings.xml
Deploying using scp:// hangs when proxy configured in settings.xml -- Key: WAGON-70 URL: http://jira.codehaus.org/browse/WAGON-70 Project: wagon Issue Type: Bug Components: wagon-ssh Affects Versions: 1.0-beta-2 Environment: Windows XP in a corporate environment that is proxied and firewalled to everywhere Reporter: Stephen Coy For some reason, wagon-ssh is attempting to connect to the proxy defined in settings.xml (irrespective of whether it is enabled or not) in order to perform an scp transfer. This causes goals such as site:deploy to hang for some time before proceeding normally. A thread dump taken during the hang: [INFO] [site:deploy] Full thread dump Java HotSpot(TM) Client VM (1.4.2_13-b06 mixed mode): "Signal Dispatcher" daemon prio=10 tid=0x009cf600 nid=0xa7c waiting on condition [0x..0x] "Finalizer" daemon prio=9 tid=0x009ccbb8 nid=0xb84 in Object.wait() [0x02b6f000..0x02b6fd68] at java.lang.Object.wait(Native Method) - waiting on <0x104fb160> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111) - locked <0x104fb160> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=10 tid=0x009cb830 nid=0xf38 in Object.wait() [0x02b2f000..0x02b2fd68] at java.lang.Object.wait(Native Method) - waiting on <0x104fb1c8> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:429) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:115) - locked <0x104fb1c8> (a java.lang.ref.Reference$Lock) "main" prio=5 tid=0x00035b28 nid=0xe90 runnable [0x0007f000..0x0007fc38] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.net.SocketInputStream.read(SocketInputStream.java:182) at com.jcraft.jsch.ProxyHTTP.connect(Unknown Source) at org.apache.maven.wagon.providers.ssh.AbstractSshWagon.openConnection(AbstractSshWagon.java:181) at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) at org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:149) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- 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-56) clean up doxia api and code
[ http://jira.codehaus.org/browse/DOXIA-56?page=comments#action_85209 ] Vincent Siveton commented on DOXIA-56: -- a first step, updated the new license headers ;) > clean up doxia api and code > --- > > Key: DOXIA-56 > URL: http://jira.codehaus.org/browse/DOXIA-56 > Project: doxia > Issue Type: Task >Reporter: Brett Porter > Fix For: 1.0 > > > there is a lot of "throws Exception" and uncertainty in the API. It needs a > clean up before 1.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2709) Maven 2 doesn't resolve parent test dependencies when using JDK 6
[ http://jira.codehaus.org/browse/MNG-2709?page=comments#action_85207 ] Brett Porter commented on MNG-2709: --- not sure if this is just test dependencies. For example, surefire doesn't build from a clean repo under JDK6 (fails on plugin parent) > Maven 2 doesn't resolve parent test dependencies when using JDK 6 > - > > Key: MNG-2709 > URL: http://jira.codehaus.org/browse/MNG-2709 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.4 >Reporter: Matt Raible > > http://www.nabble.com/Maven-2-and-JDK-6-tf2841587s177.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-60) Use a external XML Pull parser instead of plexus one
[ http://jira.codehaus.org/browse/DOXIA-60?page=comments#action_85206 ] Vincent Siveton commented on DOXIA-60: -- Carlos, what is the status of this one? > Use a external XML Pull parser instead of plexus one > > > Key: DOXIA-60 > URL: http://jira.codehaus.org/browse/DOXIA-60 > Project: doxia > Issue Type: Improvement > Components: Core >Reporter: Carlos Sanchez >Priority: Critical > > To avoid maintaining the plexus XMLPullParser we should move to a standard > implementation like Codehaus StaX http://stax.codehaus.org > > stax > stax > 1.2.0_rc2-dev > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-74) Added muse format to doxia-core
[ http://jira.codehaus.org/browse/DOXIA-74?page=comments#action_85205 ] Vincent Siveton commented on DOXIA-74: -- >From maven user list: http://www.oqube.com/projects/muse-java/index.html Just curious: why dont create a doxia-modules instead of modify core? > Added muse format to doxia-core > --- > > Key: DOXIA-74 > URL: http://jira.codehaus.org/browse/DOXIA-74 > Project: doxia > Issue Type: New Feature > Components: Core >Affects Versions: 1.0-alpha-8 >Reporter: Arnaud Bailly >Priority: Minor > Fix For: 1.0-alpha-8 > > Attachments: patch-doxia-1.0-alpha-8, patch-doxia-1.0-alpha-8-1.0-rc3 > > > As a workaround to DOXIA-68 bug, I have m\ade a patch to > doxia-core-1.0-alpha-8 that include necessary code for generating maven sites > from muse syntax and add a dependency to muse-parser from doxia-core pom.xml. > This patch may be useful for people who wish to write their documentation > using Emacs muse mode. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DOXIA-79) Doxia generates different XHTML for the same xdoc code
[ http://jira.codehaus.org/browse/DOXIA-79?page=all ] Vincent Siveton closed DOXIA-79. Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 1.0 Already fixed > Doxia generates different XHTML for the same xdoc code > -- > > Key: DOXIA-79 > URL: http://jira.codehaus.org/browse/DOXIA-79 > Project: doxia > Issue Type: Bug > Components: Core >Affects Versions: 1.0-alpha-8, 1.0 >Reporter: Henning Schmiedehausen > Assigned To: Vincent Siveton > Fix For: 1.0 > > > Consider the following xdoc code: > > > p1 > > l1 > > > > p2 > > l1 > > > > This renders to the following XHTML code: > 1 > s1 > p1 > l1 > > s2 > p2 > l1 > > > Please not the missing around 'p2'. -- 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-91) Update Doxia Decoration model to actually work in reactor build.
[ http://jira.codehaus.org/browse/DOXIA-91?page=comments#action_85203 ] Vincent Siveton commented on DOXIA-91: -- I forgot to say that I tried with maven 2.0.4 and 2.0.5 > Update Doxia Decoration model to actually work in reactor build. > > > Key: DOXIA-91 > URL: http://jira.codehaus.org/browse/DOXIA-91 > Project: doxia > Issue Type: Improvement > Components: Decoration Model >Reporter: Henning Schmiedehausen > Fix For: 1.0 > > Attachments: doxia-decoration.patch, doxia-decoration.patch > > > This is a major patch to the decoration model to bring some sanity in the > link resolution when it is used under the reactor build. It generates > breadcrumbs and item links correctly in all scenarios that I have tested (the > current HEAD code does not) and passes all the unit tests that are already > there. -- 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-91) Update Doxia Decoration model to actually work in reactor build.
[ http://jira.codehaus.org/browse/DOXIA-91?page=comments#action_85202 ] Vincent Siveton commented on DOXIA-91: -- I tried your latest patch and actual tests failed. Could you provide us test cases or review these? Tx. Another way, as you know, we change license headers. > Update Doxia Decoration model to actually work in reactor build. > > > Key: DOXIA-91 > URL: http://jira.codehaus.org/browse/DOXIA-91 > Project: doxia > Issue Type: Improvement > Components: Decoration Model >Reporter: Henning Schmiedehausen > Fix For: 1.0 > > Attachments: doxia-decoration.patch, doxia-decoration.patch > > > This is a major patch to the decoration model to bring some sanity in the > link resolution when it is used under the reactor build. It generates > breadcrumbs and item links correctly in all scenarios that I have tested (the > current HEAD code does not) and passes all the unit tests that are already > there. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2730) useful developer bash functions for Maven
[ http://jira.codehaus.org/browse/MNG-2730?page=all ] Brett Porter updated MNG-2730: -- Attachment: mvn_functions_bashrc.txt updated > useful developer bash functions for Maven > - > > Key: MNG-2730 > URL: http://jira.codehaus.org/browse/MNG-2730 > Project: Maven 2 > Issue Type: New Feature > Components: Documentation: General >Reporter: Brett Porter > Attachments: mvn_functions_bashrc.txt, mvn_functions_bashrc.txt > > > useful bash functions. We could include this in the dev section of the web > 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] Updated: (ARCHETYPE-64) groupId and version redundant when executing archetype with parent
[ http://jira.codehaus.org/browse/ARCHETYPE-64?page=all ] Rod Coffin updated ARCHETYPE-64: Attachment: ARCHETYPE-64-maven-archetype-core.patch Test case and solution for issue > groupId and version redundant when executing archetype with parent > -- > > Key: ARCHETYPE-64 > URL: http://jira.codehaus.org/browse/ARCHETYPE-64 > Project: Maven Archetype > Issue Type: Improvement > Components: Archetypes >Affects Versions: 1.0-alpha-4 >Reporter: Rod Coffin > Attachments: ARCHETYPE-64-maven-archetype-core.patch > > > Running the archetype plugin in a parent project creates a sub-project > (module). Although the parent elements are properly set in the child pom, > the group id and version are repeated. These are not necessary since they > will be inherited from the parent. Ex: > > parent > com.rfc.archetypes.example > 1.0-SNAPSHOT > > 4.0.0 > com.rfc.archetypes.example > example-web > 1.0-SNAPSHOT > Having this information is two places is bad in principle because it violates > the DRY principle and in practice because they can get out of sync > accidentally and it could be confusing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (ARCHETYPE-64) groupId and version redundant when executing archetype with parent
groupId and version redundant when executing archetype with parent -- Key: ARCHETYPE-64 URL: http://jira.codehaus.org/browse/ARCHETYPE-64 Project: Maven Archetype Issue Type: Improvement Components: Archetypes Affects Versions: 1.0-alpha-4 Reporter: Rod Coffin Running the archetype plugin in a parent project creates a sub-project (module). Although the parent elements are properly set in the child pom, the group id and version are repeated. These are not necessary since they will be inherited from the parent. Ex: parent com.rfc.archetypes.example 1.0-SNAPSHOT 4.0.0 com.rfc.archetypes.example example-web 1.0-SNAPSHOT Having this information is two places is bad in principle because it violates the DRY principle and in practice because they can get out of sync accidentally and it could be confusing. -- 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: (MPSOURCE-4) Ability to change the appended string to the name
Ability to change the appended string to the name - Key: MPSOURCE-4 URL: http://jira.codehaus.org/browse/MPSOURCE-4 Project: maven-source-plugin Issue Type: New Feature Affects Versions: 1.0 Environment: All Reporter: Allan Schweitz Priority: Minor Fix For: 1.0 Currently -source is appended to the finalName of the generated jar. It would be nice if it's configurable to e.g. -src or .src, etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-48) eclipse:eclipse goal should handle includes and excludes of the maven-compiler-plugin
[ http://jira.codehaus.org/browse/MECLIPSE-48?page=comments#action_85184 ] Steffen Pingel commented on MECLIPSE-48: Looking at the corresponding commit for this issue (svn diff -r 467576:467577) excludes have been only implemented for resources but not for source directories. Could this issue be reopened so the actual issue can be addressed? > eclipse:eclipse goal should handle includes and excludes of the > maven-compiler-plugin > - > > Key: MECLIPSE-48 > URL: http://jira.codehaus.org/browse/MECLIPSE-48 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Mark Donszelmann > Assigned To: fabrizio giustina > Fix For: 2.3 > > > The maven-compiler-plugin allows a configuration such as: > > maven-compiler-plugin > > > **/idl/*Factory.java > > > > the generated .classpath file currently does not mention the excluded part: > > > which should be: >path="src/main/java"/> >path="target/generated-sources/idl"/> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-490) Invalid or problematic Spring POMS
[ http://jira.codehaus.org/browse/MEV-490?page=comments#action_85179 ]
Carlos Sanchez commented on MEV-490:
in what cases are not resolved correctly? it shouldn't be a problem
> Invalid or problematic Spring POMS
> --
>
> Key: MEV-490
> URL: http://jira.codehaus.org/browse/MEV-490
> Project: Maven Evangelism
> Issue Type: Bug
> Components: Invalid POM
>Reporter: Carsten Ziegeler
>
> The Spring poms, for example spring-beans, version 2.0.2 use the following
> dependencies:
>
> ${project.groupId}
> spring-core
> ${project.version}
>
> Which means, they are using variables in the poms. In some cases, these
> variables are resolved correctly, but in some cases however they are not,
> causing problems.
> Imho, it would be better to resolve variables for released poms to avoid any
> problems (or if variables are allowed, this is a maven bug then)
--
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: (MEV-491) org.apache.maven.plugins metadata has invalid MD5 SHA1 and PGP signature
[ http://jira.codehaus.org/browse/MEV-491?page=all ] Carlos Sanchez closed MEV-491. -- Assignee: Carlos Sanchez Resolution: Fixed > org.apache.maven.plugins metadata has invalid MD5 SHA1 and PGP signature > > > Key: MEV-491 > URL: http://jira.codehaus.org/browse/MEV-491 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Max Bowsher > Assigned To: Carlos Sanchez > > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-metadata.xml > fails MD5 SHA1 and PGP verification. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2779) Inconsistent dependency scope resolution
Inconsistent dependency scope resolution Key: MNG-2779 URL: http://jira.codehaus.org/browse/MNG-2779 Project: Maven 2 Issue Type: Bug Components: Dependencies, Reactor and workspace Affects Versions: 2.0.4 Reporter: Chris Eldredge Priority: Minor Suppose a multi-module project with modules a, b and c: module a depends on commons-lang (scope compile) module b depends on commons-lang (scope provided) module c depends on module a (scope test) module c depends on module b (scope provided) If I run mvn on the top level pom (with a moduleSet containing a, b and c) the compile of module c fails because commons-lang is included transitively with "test" scope (meaning that source code in src/main/java does not have commons-lang in the classpath). If I run mvn on module c only, commons-lang is included transitively with "provided" scope, and everything works fine. Changing module a's dependency on commons-lang to "provided" scope resolved this issue, but the inconsistency is there nonetheless. The inconsistency seems to be that in a reactor build, module dependencies are provided by MavenProject instances, whereas when the individual module is built, the module dependency is processed like any other from the pom in the repository. So I think the bug is in how module dependencies are processed. -- 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-265) Concurrent builds
[ http://jira.codehaus.org/browse/CONTINUUM-265?page=comments#action_85167 ] Yan Shapochnik commented on CONTINUUM-265: -- I believe this would extremely useful, even for shell script projects. For example, I have 4 groups of projects setup. Each group represents a platform and I need to build each group of projects concurrently, since each group is built on a separate platform. I am not using maven or ant. I am actually using continuum to build c++ code and it works quite well, except no parallel build ability appears to exist. It would be good to have the ability to define a separate build executor for each project group. > Concurrent builds > - > > Key: CONTINUUM-265 > URL: http://jira.codehaus.org/browse/CONTINUUM-265 > Project: Continuum > Issue Type: New Feature > Components: Core system >Reporter: Torsten Curdt > > Instead of processing the builds sequentially it would be great to be > able to specify how many projects are being build concurrently. -- 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-268) Archivas relocation feature should be configurable
Archivas relocation feature should be configurable -- Key: MRM-268 URL: http://jira.codehaus.org/browse/MRM-268 Project: Archiva Issue Type: Improvement Reporter: Chris Wewerka Archiva automatically delivers the new pom and jar for a relocated artifact to a maven client. The downside of this feature is that clients do not get a warning that the artifact is relocated anymore. In a "All-Maven2" environment this warning is quite good, and gives the developer a hint and a motivation (get rid of the warning ;-) ) to use the new groupId. So I think it would be a good idea to make this feature configurable, so the archiva admin can turn it off. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MEV-491) org.apache.maven.plugins metadata has invalid MD5 SHA1 and PGP signature
org.apache.maven.plugins metadata has invalid MD5 SHA1 and PGP signature Key: MEV-491 URL: http://jira.codehaus.org/browse/MEV-491 Project: Maven Evangelism Issue Type: Bug Reporter: Max Bowsher http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-metadata.xml fails MD5 SHA1 and PGP verification. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MEV-490) Invalid or problematic Spring POMS
Invalid or problematic Spring POMS
--
Key: MEV-490
URL: http://jira.codehaus.org/browse/MEV-490
Project: Maven Evangelism
Issue Type: Bug
Components: Invalid POM
Reporter: Carsten Ziegeler
The Spring poms, for example spring-beans, version 2.0.2 use the following
dependencies:
${project.groupId}
spring-core
${project.version}
Which means, they are using variables in the poms. In some cases, these
variables are resolved correctly, but in some cases however they are not,
causing problems.
Imho, it would be better to resolve variables for released poms to avoid any
problems (or if variables are allowed, this is a maven bug then)
--
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-1137) Add a link to the schecule in the schedule column of build definitions table
[ http://jira.codehaus.org/browse/CONTINUUM-1137?page=all ] Henry S. Isidro updated CONTINUUM-1137: --- Attachment: [CONTINUUM-1137]-continuum-webapp.patch-2 File Attached: [CONTINUUM-1137]-continuum-webapp.patch-2 Please disregard the first patch, this new patch adds permission checks. > Add a link to the schecule in the schedule column of build definitions table > > > Key: CONTINUUM-1137 > URL: http://jira.codehaus.org/browse/CONTINUUM-1137 > Project: Continuum > Issue Type: Improvement > Components: Web interface >Reporter: Henry S. Isidro >Priority: Minor > Attachments: [CONTINUUM-1137]-continuum-webapp.patch, > [CONTINUUM-1137]-continuum-webapp.patch-2 > > -- 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-1326) JUnit-Toolkit version 0.3 upload bundle. Please add to the repository.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1326?page=comments#action_85154 ] Rupert Smith commented on MAVENUPLOAD-1326: --- Thank you Carlos. > JUnit-Toolkit version 0.3 upload bundle. Please add to the repository. > -- > > Key: MAVENUPLOAD-1326 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1326 > Project: maven-upload-requests > Issue Type: Task >Reporter: Rupert Smith > Assigned To: Carlos Sanchez > Attachments: junit-toolkit-0.3-bundle.jar > > > http://www.thebadgerset.co.uk/junit-toolkit/junit-toolkit-0.3-bundle.jar > http://www.thebadgerset.co.uk/junit-toolkit/ > http://www.thebadgerset.co.uk/junit-toolkit/team-list.html > 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] Updated: (CONTINUUM-1138) Add posibility to choose a project group for new Ant and Shell projects
[ http://jira.codehaus.org/browse/CONTINUUM-1138?page=all ] Edwin Punzalan updated CONTINUUM-1138: -- Attachment: CONTINUUM-1138-continuum.patch Patch attached, please apply. Thanks. > Add posibility to choose a project group for new Ant and Shell projects > --- > > Key: CONTINUUM-1138 > URL: http://jira.codehaus.org/browse/CONTINUUM-1138 > Project: Continuum > Issue Type: New Feature > Components: Project Grouping >Reporter: Edwin Punzalan > Attachments: CONTINUUM-1138-continuum.patch > > > Currently, these projects go under the Default Project Group. -- 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-1138) Add posibility to choose a project group for new Ant and Shell projects
Add posibility to choose a project group for new Ant and Shell projects --- Key: CONTINUUM-1138 URL: http://jira.codehaus.org/browse/CONTINUUM-1138 Project: Continuum Issue Type: New Feature Components: Project Grouping Reporter: Edwin Punzalan Currently, these projects go under the Default Project Group. -- 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-1137) Add a link to the schecule in the schedule column of build definitions table
[ http://jira.codehaus.org/browse/CONTINUUM-1137?page=all ] Henry S. Isidro updated CONTINUUM-1137: --- Attachment: [CONTINUUM-1137]-continuum-webapp.patch File Attached: [CONTINUUM-1137]-continuum-webapp.patch > Add a link to the schecule in the schedule column of build definitions table > > > Key: CONTINUUM-1137 > URL: http://jira.codehaus.org/browse/CONTINUUM-1137 > Project: Continuum > Issue Type: Improvement > Components: Web interface >Reporter: Henry S. Isidro >Priority: Minor > Attachments: [CONTINUUM-1137]-continuum-webapp.patch > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1137) Add a link to the schecule in the schedule column of build definitions table
Add a link to the schecule in the schedule column of build definitions table Key: CONTINUUM-1137 URL: http://jira.codehaus.org/browse/CONTINUUM-1137 Project: Continuum Issue Type: Improvement Components: Web interface Reporter: Henry S. Isidro Priority: Minor -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-137) Developed RAD-6 Plugin Extention
[ http://jira.codehaus.org/browse/MECLIPSE-137?page=comments#action_85145 ] ulf a commented on MECLIPSE-137: Hi, i try to use this plugin, but i have no clue in which order i have to use the packages above. When i only use maven-rad-plugin.tar.gz then the test will fail. When i also use the MECLIPSE-137-maven-rad-plugin.zip than nothing works. Can anybody explain me how to do it in the right way? Thanx, Ulf > Developed RAD-6 Plugin Extention > > > Key: MECLIPSE-137 > URL: http://jira.codehaus.org/browse/MECLIPSE-137 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature >Reporter: Richard van Nieuwenhoven > Assigned To: John Casey > Attachments: maven-rad-plugin-WebContent.zip, > maven-rad-plugin.tar.gz, maven-rad-plugin.zip, > MECLIPSE-137-maven-eclipse-plugin.patch, MECLIPSE-137-maven-rad-plugin.zip > > > I just finisched developing a RAD-6 (IBM Rational Application Developer 6.0) > extention to the eclipse plugin. > It supports J2EE projects with the websphere development envorment, supported > are > - EJB projects > - Web projects > - EAR- projects > all these projects are recognized by rad-6 as what they. The websphere > development enviorment including hot-deployment features funktions out of the > box. > i wrote writers for: > - the ".j2ee" files > - the "application.xml" and the "modulemaps" file > - copying the extrenal libs in the ear project root > - adapting the MANIFEST.MF of the projects (nessesary for the websphere > development enviorment) > - the ".websettings" file > - the ".websiteconfig" file > - the ".project" (only alternative project natures/builders) > do you want to include it the the eclipse plugin or sould it be an extra > plugin? i should not be complicated to include it because i did the real work > in writer-classes. > should i add a tgz with the sources? or how do you want the sources? -- 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
