[jira] Created: (MRELEASE-246) impossible to prepare after a dryRun
impossible to prepare after a dryRun Key: MRELEASE-246 URL: http://jira.codehaus.org/browse/MRELEASE-246 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-6 Environment: Win XP. Maven 2.0.6. Trying to release a pom artifact Reporter: Dominique Jean-Prost Priority: Minor After having done a mvn release:prepare -DdryRun=true, it's impossible to do mvn release:prepare. --> mvn release:prepare -Dresume=false : c:\root\test-pom>mvn release:prepare -Dresume=false [INFO] Scanning for projects... [INFO] NOTE: Using release-pom: c:\root\test-pom\release-pom.xml in reactor build. [INFO] Searching repository for plugin with prefix: 'release'. [INFO] [INFO] Building Fichier parent des descripteurs POM des composants [INFO]task-segment: [release:prepare] (aggregator-style) [INFO] [INFO] [release:prepare] [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] You don't have a SNAPSHOT project in the reactor projects list. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Mon Jun 11 09:40:41 CEST 2007 [INFO] Final Memory: 5M/9M [INFO] Must do a mvn release:clean before mvn release:prepare. I think we shouldn't have to. -- 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: (NMAVEN-73) NUnit output is inconsistent with maven-test-plugin output
[
http://jira.codehaus.org/browse/NMAVEN-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evan Worley updated NMAVEN-73:
--
Attachment: testPatch.txt
Tee's NUnit output to the console and to the reports file. Also adding an
integration tests for expected test execution behavior, that being console
output (verified visually) and a txt file report. This patch does not
re-format nunit-console output to be more consistent with the JUnit plugin.
> NUnit output is inconsistent with maven-test-plugin output
> --
>
> Key: NMAVEN-73
> URL: http://jira.codehaus.org/browse/NMAVEN-73
> Project: NMaven
> Issue Type: Improvement
> Environment: Maven 2.0.4 with NMaven 0.14-SNAPSHOT
>Reporter: Evan Worley
>Priority: Minor
> Attachments: testPatch.txt
>
>
> I was thinking there would be some value in doing some work on the nunit
> plugin to add some output similar to the junit plugin. Currently when nunit
> tests run, all the output is logged to file. It is not too much fun when
> your tests run for a few minutes, you see nothing. Here is a junit output vs
> nunit output comparison
> -- JUNIT --
> Running package1.TestClass1
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec
> Running package2.TestClass2
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec
> .
> .
> .
> Results :
> Tests run: 139, Failures: 0, Errors: 0, Skipped: 0
> -- NUNIT --
> NMAVEN-040-000: Executed command: Commandline = nunit-console C:\dev\project
> \main\component\target\test-assemblies\Namespace.Artifact.dll /out
> {SOME_OUTPUT_FILE} /err {SOME_OUTPUT_FILE}, Result = 0
> The nmaven test plugin should capture the stdout/stderr from nunit and format
> is similar to junit. These inconsistencies are especially noticed in
> environments where you build the same component in java and C#. Switching
> from the java to C# build seems like a whole new world, instead of simply a
> new language
--
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: (NMAVEN-73) NUnit output is inconsistent with maven-test-plugin output
[
http://jira.codehaus.org/browse/NMAVEN-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99058
]
Evan Worley edited comment on NMAVEN-73 at 6/11/07 3:16 AM:
Forgot one class, added it to patch
was:
Forgot on class, added it to patch
> NUnit output is inconsistent with maven-test-plugin output
> --
>
> Key: NMAVEN-73
> URL: http://jira.codehaus.org/browse/NMAVEN-73
> Project: NMaven
> Issue Type: Improvement
> Environment: Maven 2.0.4 with NMaven 0.14-SNAPSHOT
>Reporter: Evan Worley
>Priority: Minor
> Attachments: testPatch.txt, testPatch.txt
>
>
> I was thinking there would be some value in doing some work on the nunit
> plugin to add some output similar to the junit plugin. Currently when nunit
> tests run, all the output is logged to file. It is not too much fun when
> your tests run for a few minutes, you see nothing. Here is a junit output vs
> nunit output comparison
> -- JUNIT --
> Running package1.TestClass1
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec
> Running package2.TestClass2
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec
> .
> .
> .
> Results :
> Tests run: 139, Failures: 0, Errors: 0, Skipped: 0
> -- NUNIT --
> NMAVEN-040-000: Executed command: Commandline = nunit-console C:\dev\project
> \main\component\target\test-assemblies\Namespace.Artifact.dll /out
> {SOME_OUTPUT_FILE} /err {SOME_OUTPUT_FILE}, Result = 0
> The nmaven test plugin should capture the stdout/stderr from nunit and format
> is similar to junit. These inconsistencies are especially noticed in
> environments where you build the same component in java and C#. Switching
> from the java to C# build seems like a whole new world, instead of simply a
> new language
--
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: (NMAVEN-73) NUnit output is inconsistent with maven-test-plugin output
[
http://jira.codehaus.org/browse/NMAVEN-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evan Worley updated NMAVEN-73:
--
Attachment: testPatch.txt
Forgot on class, added it to patch
> NUnit output is inconsistent with maven-test-plugin output
> --
>
> Key: NMAVEN-73
> URL: http://jira.codehaus.org/browse/NMAVEN-73
> Project: NMaven
> Issue Type: Improvement
> Environment: Maven 2.0.4 with NMaven 0.14-SNAPSHOT
>Reporter: Evan Worley
>Priority: Minor
> Attachments: testPatch.txt, testPatch.txt
>
>
> I was thinking there would be some value in doing some work on the nunit
> plugin to add some output similar to the junit plugin. Currently when nunit
> tests run, all the output is logged to file. It is not too much fun when
> your tests run for a few minutes, you see nothing. Here is a junit output vs
> nunit output comparison
> -- JUNIT --
> Running package1.TestClass1
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec
> Running package2.TestClass2
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec
> .
> .
> .
> Results :
> Tests run: 139, Failures: 0, Errors: 0, Skipped: 0
> -- NUNIT --
> NMAVEN-040-000: Executed command: Commandline = nunit-console C:\dev\project
> \main\component\target\test-assemblies\Namespace.Artifact.dll /out
> {SOME_OUTPUT_FILE} /err {SOME_OUTPUT_FILE}, Result = 0
> The nmaven test plugin should capture the stdout/stderr from nunit and format
> is similar to junit. These inconsistencies are especially noticed in
> environments where you build the same component in java and C#. Switching
> from the java to C# build seems like a whole new world, instead of simply a
> new language
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-247) release of a pom : dependencyManagement section gets deleted
release of a pom : dependencyManagement section gets deleted Key: MRELEASE-247 URL: http://jira.codehaus.org/browse/MRELEASE-247 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-6 Environment: Win XP. Mvn 2.0.6 release of a pom artifact. Subversion Reporter: Dominique Jean-Prost The pom file that gets deployed after release:perform doesn't contain the dependencyManagement section. In my test case, the pom that get tagged is the correct one (after release:prepare), ie, it contains the correct version number, the scm section mentions the tag name in the URL, and the dependency section is there. The pom that is deployed in the repository is completly changed : the dependency section isn't there anymore. The artifacts that depend on this meet then problem as the version of plugin and artifact are not 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] Closed: (MRELEASE-247) release of a pom : dependencyManagement section gets deleted
[ http://jira.codehaus.org/browse/MRELEASE-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Jean-Prost closed MRELEASE-247. - Resolution: Duplicate duplicate of #240 > release of a pom : dependencyManagement section gets deleted > > > Key: MRELEASE-247 > URL: http://jira.codehaus.org/browse/MRELEASE-247 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 > Environment: Win XP. Mvn 2.0.6 release of a pom artifact. Subversion >Reporter: Dominique Jean-Prost > > The pom file that gets deployed after release:perform doesn't contain the > dependencyManagement section. > In my test case, the pom that get tagged is the correct one (after > release:prepare), ie, it contains the correct version number, the scm section > mentions the tag name in the URL, and the dependency section is there. > The pom that is deployed in the repository is completly changed : the > dependency section isn't there anymore. > The artifacts that depend on this meet then problem as the version of plugin > and artifact are not 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] Created: (MPMD-58) sourceEncoding honoured with pmd but not cpd
sourceEncoding honoured with pmd but not cpd Key: MPMD-58 URL: http://jira.codehaus.org/browse/MPMD-58 Project: Maven 2.x PMD Plugin Issue Type: Bug Components: CPD Affects Versions: 2.2 Environment: Linux, LC_LANG=en LC_ALL=POSIX Reporter: M. Rohrmoser If the source (*.java) contains non-Ascii Characters, e.g. in field names, pmd:check works fine but pmd:cpd-check fails with the stacktrace [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: An error has occurred in CPD Report report generation. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:898) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:734) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:505) 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: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: An error has occurred in CPD Report report generation. at org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:79) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 19 more Caused by: net.sourceforge.pmd.ast.TokenMgrError: Lexical error at line 32, column 33. Encountered: "\ufffd" (65533), after : "" at net.sourceforge.pmd.ast.JavaParserTokenManager.getNextToken(JavaParserTokenManager.java:2037) at net.sourceforge.pmd.cpd.JavaTokenizer.tokenize(JavaTokenizer.java:69) at net.sourceforge.pmd.cpd.CPD.add(CPD.java:97) at net.sourceforge.pmd.cpd.CPD.add(CPD.java:50) at org.apache.maven.plugin.pmd.CpdReport.executeReport(CpdReport.java:102) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98) at org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:73) ... 21 more The pom is: ... org.apache.maven.plugins maven-pmd-plugin true true utf-8 100 1.5 ... -- 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-1302) Build requires tests disabled
[ http://jira.codehaus.org/browse/CONTINUUM-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99063 ] Tim Pizey commented on CONTINUUM-1302: -- --- Test set: org.apache.maven.continuum.release.executors.ReleaseTaskExecutorTest --- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.232 sec <<< FAILURE! testReleases(org.apache.maven.continuum.release.executors.ReleaseTaskExecutorTest) Time elapsed: 1.201 sec <<< ERROR! java.io.FileNotFoundException: c:\continuum\continuum-release\target\test-classes\work-dir\pom.xml (The system cannot find the path specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(FileInputStream.java:106) at org.codehaus.plexus.util.FileUtils.fileRead(FileUtils.java:273) at org.apache.maven.continuum.release.executors.ReleaseTaskExecutorTest.releaseSimpleProject(ReleaseTaskExecutorTest.java:110) at org.apache.maven.continuum.release.executors.ReleaseTaskExecutorTest.testReleases(ReleaseTaskExecutorTest.java:129) > Build requires tests disabled > - > > Key: CONTINUUM-1302 > URL: http://jira.codehaus.org/browse/CONTINUUM-1302 > Project: Continuum > Issue Type: Bug > Components: Testing >Affects Versions: 1.1-alpha-2 > Environment: Cygwin/winXP/Java1.5/Maven 2.0.6 >Reporter: Tim Pizey > > Building for the first time on a machine: > build.sh and build.sh fail for Maven 2.06 and 2.0.7 with missing > ClassWorldsLauncher > Build page: > http://maven.apache.org/continuum/guides/development/guide-build-continuum.html > does not mention need to download Sun jars. > I could not understand last paragraph about assembly:assembly. > mvn install fails the test for continuum-release: > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.344 sec <<< > FAILURE! > testReleases(org.apache.maven.continuum.release.executors.ReleaseTaskExecutorTest) > Time elapsed: 1.203 sec <<< ERROR! > java.io.FileNotFoundException: > c:\continuum\continuum-release\target\test-classes\work-dir\pom.xml (The > system cannot find the path specified) > at java.io.FileInputStream.open(Native Method) > at java.io.FileInputStream.(FileInputStream.java:106) > at org.codehaus.plexus.util.FileUtils.fileRead(FileUtils.java:273) > at > org.apache.maven.continuum.release.executors.ReleaseTaskExecutorTest.releaseSimpleProject(ReleaseTaskExecutorTest.java:110) > at > org.apache.maven.continuum.release.executors.ReleaseTaskExecutorTest.testReleases(ReleaseTaskExecutorTest.java:129) > mvn -Dmaven.test.skip=true install does work !! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MINVOKER-4) Use order of invocations as specified in pomIncludes
Use order of invocations as specified in pomIncludes Key: MINVOKER-4 URL: http://jira.codehaus.org/browse/MINVOKER-4 Project: Maven 2.x Invoker Plugin Issue Type: Improvement Affects Versions: 1.0 Reporter: Wouter Hermeling Assignee: John Casey I use the invoker plugin to create a multi-multiproject build. In fact, this is like using maven as a build server. It would be nice if the invoker plugins does its invocations in the order as specied in pomIncludes, just like maven does on modules in pom projects. Now, it seems to use some kind of alphabetical order. -- 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-1594) Upload request for tatooine-gtx-0.1.0 to ibiblio
Upload request for tatooine-gtx-0.1.0 to ibiblio Key: MAVENUPLOAD-1594 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1594 Project: maven-upload-requests Issue Type: Task Reporter: tooru noda http://tatooine.sourceforge.jp/gtx/bundle/tatooine-gtx-0.1.0-bundle.jar http://tatooine.sourceforge.jp/gtx/ http://sourceforge.jp/project/memberlist.php?group_id=2520 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] Created: (MAVENUPLOAD-1595) java exchange connector (version 1.52_13)
java exchange connector (version 1.52_13) - Key: MAVENUPLOAD-1595 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1595 Project: maven-upload-requests Issue Type: Wish Reporter: eli hasson java exchange connector is a pure java api for Microsoft exchange server. for more information: [EMAIL PROTECTED] [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPRELEASE-25) release:prepare fails with Starteam 2006
release:prepare fails with Starteam 2006 Key: MPRELEASE-25 URL: http://jira.codehaus.org/browse/MPRELEASE-25 Project: Maven 1.x Release Plugin Issue Type: Bug Affects Versions: 1.5 Environment: windows xp, starteam 2006 Reporter: Giovanni Pedone when performing release:prepare and issuing the command stcmd, it fails to checkout/checkin, complaining about "Unknown status". It does not happen with stcmd shipping with Starteam 2005 R2. It happens only with Starteam 2006 stcmd. -- 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] Moved: (MRELEASE-248) release:prepare fails with Starteam 2006
[ http://jira.codehaus.org/browse/MRELEASE-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse moved MPRELEASE-25 to MRELEASE-248: Affects Version/s: (was: 1.5) 2.0-beta-6 Workflow: Maven New (was: jira) Key: MRELEASE-248 (was: MPRELEASE-25) Project: Maven 2.x Release Plugin (was: Maven 1.x Release Plugin) > release:prepare fails with Starteam 2006 > > > Key: MRELEASE-248 > URL: http://jira.codehaus.org/browse/MRELEASE-248 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 > Environment: windows xp, starteam 2006 >Reporter: Giovanni Pedone > > when performing release:prepare and issuing the command stcmd, it fails to > checkout/checkin, complaining about "Unknown status". > It does not happen with stcmd shipping with Starteam 2005 R2. > It happens only with Starteam 2006 stcmd. -- 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: (MPRELEASE-25) release:prepare fails with Starteam 2006
[ http://jira.codehaus.org/browse/MPRELEASE-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99100 ] Emmanuel Venisse commented on MPRELEASE-25: --- Can you paste the output stcmd line that generate an "Unknown Status"? I think you can get it by running mvn with -X > release:prepare fails with Starteam 2006 > > > Key: MPRELEASE-25 > URL: http://jira.codehaus.org/browse/MPRELEASE-25 > Project: Maven 1.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 > Environment: windows xp, starteam 2006 >Reporter: Giovanni Pedone > > when performing release:prepare and issuing the command stcmd, it fails to > checkout/checkin, complaining about "Unknown status". > It does not happen with stcmd shipping with Starteam 2005 R2. > It happens only with Starteam 2006 stcmd. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (NMAVEN-73) NUnit output is inconsistent with maven-test-plugin output
[
http://jira.codehaus.org/browse/NMAVEN-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99101
]
Shane Isbell commented on NMAVEN-73:
Thanks Evan! The patch looks great. A few comments: 1) The TesterMojo imports
the DefaultStreamConsumer, which is in the impl package. As a general rule, no
impl packages should exist in the Mojos, so either the the
DefaultStreamConsumer should be moved to a public package or should be gotten
from a Factory. Also we need to JavaDoc document when we use
CommandExecutor.Factory.createCommandExecutor(stdOut, stdErr); instead of
CommandExecutor.Factory.createDefaultCommandExecutor because it is not clear
from looking at the names.
The third issue, which does not need to be addressed now, but I just want to
comment on it so I don't forget. We will probably want to have multiple methods
on the DefaultStreamConsumer, such as setMavenLogger, setJdkLogger,
setPlexusLogger, etc. By setting the JDK logger, I can add a sockethandler and
get all the test results (as well as other plugin results) to the IDE. So this
patch hits a general issue as well.
> NUnit output is inconsistent with maven-test-plugin output
> --
>
> Key: NMAVEN-73
> URL: http://jira.codehaus.org/browse/NMAVEN-73
> Project: NMaven
> Issue Type: Improvement
> Environment: Maven 2.0.4 with NMaven 0.14-SNAPSHOT
>Reporter: Evan Worley
>Priority: Minor
> Attachments: testPatch.txt, testPatch.txt
>
>
> I was thinking there would be some value in doing some work on the nunit
> plugin to add some output similar to the junit plugin. Currently when nunit
> tests run, all the output is logged to file. It is not too much fun when
> your tests run for a few minutes, you see nothing. Here is a junit output vs
> nunit output comparison
> -- JUNIT --
> Running package1.TestClass1
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec
> Running package2.TestClass2
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec
> .
> .
> .
> Results :
> Tests run: 139, Failures: 0, Errors: 0, Skipped: 0
> -- NUNIT --
> NMAVEN-040-000: Executed command: Commandline = nunit-console C:\dev\project
> \main\component\target\test-assemblies\Namespace.Artifact.dll /out
> {SOME_OUTPUT_FILE} /err {SOME_OUTPUT_FILE}, Result = 0
> The nmaven test plugin should capture the stdout/stderr from nunit and format
> is similar to junit. These inconsistencies are especially noticed in
> environments where you build the same component in java and C#. Switching
> from the java to C# build seems like a whole new world, instead of simply a
> new language
--
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-414) Don't queue a request to scan a repository that is currently being scanned
[ http://jira.codehaus.org/browse/MRM-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99102 ] Joakim Erdfelt commented on MRM-414: That error/exception/stacktrace is related to MRM-369 There is detection already in place, but not only for "is it currently in the queue", not for "is it currently running". > Don't queue a request to scan a repository that is currently being scanned > -- > > Key: MRM-414 > URL: http://jira.codehaus.org/browse/MRM-414 > Project: Archiva > Issue Type: Improvement > Components: indexing >Affects Versions: 1.0-alpha-1 >Reporter: Wendy Smoak >Priority: Minor > > If a repository is currently being scanned when the 'Scan Repository Now' > button is clicked, don't queue another request to scan it. > Example: > INFO | jvm 1| 2007/06/10 21:00:09 | 728900 [SocketListener0-1] INFO > com.opensymphony.xwork.Action:schedulerAction - [ActionMessage] Your request > to have repository [central] be indexed has been queued. > INFO | jvm 1| 2007/06/10 21:00:09 | 728902 [pool-2-thread-1] INFO > org.codehaus.plexus.taskqueue.execution.TaskExecutor:repository-scanning - > Executing task from queue with job name: repository-job:central > INFO | jvm 1| 2007/06/10 21:00:09 | 728928 [pool-2-thread-1] INFO > org.apache.maven.archiva.repository.scanner.RepositoryScanner:default - Walk > Started: [central] file:/opt/central-repository/ > INFO | jvm 1| 2007/06/10 21:01:08 | 788035 [SocketListener0-1] INFO > com.opensymphony.xwork.Action:schedulerAction - [ActionMessage] Your request > to have repository [central] be indexed has been queued. -- 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-278) duplicated classpathentries
[ http://jira.codehaus.org/browse/MECLIPSE-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MECLIPSE-278. --- Assignee: Carlos Sanchez Resolution: Fixed > duplicated classpathentries > --- > > Key: MECLIPSE-278 > URL: http://jira.codehaus.org/browse/MECLIPSE-278 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Tom Spengler >Assignee: Carlos Sanchez >Priority: Critical > Fix For: 2.4 > > Attachments: MECLIPSE-278.patch > > > if artifacts with transitive dependencies contains the same dependency with > different types it will be a .classpath generated , contains duplicat enries > of the same file. > The problem occures e.g. with type ejb and jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (NMAVEN-73) NUnit output is inconsistent with maven-test-plugin output
[
http://jira.codehaus.org/browse/NMAVEN-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99105
]
Evan Worley commented on NMAVEN-73:
---
Thanks for all the feedback Shane. I will work on #1 and on JavaDoc for the
CommandExecutor factory methods. To answer briefly, you use
createCommandExecutor(stdOut, stdErr) when you want to specify the stream
consumers for stdOut/stdErr. The createDefaultCommandExecutor factory method
creates a default implementation of the two streams.
> NUnit output is inconsistent with maven-test-plugin output
> --
>
> Key: NMAVEN-73
> URL: http://jira.codehaus.org/browse/NMAVEN-73
> Project: NMaven
> Issue Type: Improvement
> Environment: Maven 2.0.4 with NMaven 0.14-SNAPSHOT
>Reporter: Evan Worley
>Priority: Minor
> Attachments: testPatch.txt, testPatch.txt
>
>
> I was thinking there would be some value in doing some work on the nunit
> plugin to add some output similar to the junit plugin. Currently when nunit
> tests run, all the output is logged to file. It is not too much fun when
> your tests run for a few minutes, you see nothing. Here is a junit output vs
> nunit output comparison
> -- JUNIT --
> Running package1.TestClass1
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec
> Running package2.TestClass2
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec
> .
> .
> .
> Results :
> Tests run: 139, Failures: 0, Errors: 0, Skipped: 0
> -- NUNIT --
> NMAVEN-040-000: Executed command: Commandline = nunit-console C:\dev\project
> \main\component\target\test-assemblies\Namespace.Artifact.dll /out
> {SOME_OUTPUT_FILE} /err {SOME_OUTPUT_FILE}, Result = 0
> The nmaven test plugin should capture the stdout/stderr from nunit and format
> is similar to junit. These inconsistencies are especially noticed in
> environments where you build the same component in java and C#. Switching
> from the java to C# build seems like a whole new world, instead of simply a
> new language
--
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-262) Maven compilation and eclipse classpath don't match with conflicting versions at same dependency depth
[ http://jira.codehaus.org/browse/MECLIPSE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99108 ] Carlos Sanchez commented on MECLIPSE-262: - Upgraded maven dependencies,will see if this solves the problem > Maven compilation and eclipse classpath don't match with conflicting versions > at same dependency depth > -- > > Key: MECLIPSE-262 > URL: http://jira.codehaus.org/browse/MECLIPSE-262 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution >Affects Versions: 2.3 > Environment: Maven 2.0.6, 2.0.4 >Reporter: Carlos Sanchez > Attachments: compile.txt, eclipse.txt, screenshot-1.jpg, testcase.zip > > > https://svn.apache.org/repos/asf/maven/components/trunk/maven-core rev# 533182 > compile uses plexus-component-api-1.0-alpha-24 (the right one) > eclipse:eclipse uses plexus-component-api-1.0-alpha-16 -- 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-3046) DefaultArtifactVersion compareTo misbehaves regarding buildNumber 0
DefaultArtifactVersion compareTo misbehaves regarding buildNumber 0
---
Key: MNG-3046
URL: http://jira.codehaus.org/browse/MNG-3046
Project: Maven 2
Issue Type: Bug
Components: Artifacts
Affects Versions: 2.0.6
Reporter: David Julian
The implementation of Comparable.compareTo(Object) is faulty regarding the
handling of version numbers where a build number is present but zero. Here's a
unit test to demonstrate:
DefaultArtifactVersion v1 = new DefaultArtifactVersion("2.0");
DefaultArtifactVersion v2 = new DefaultArtifactVersion("2.0-0");
DefaultArtifactVersion v3 = new DefaultArtifactVersion("2.0-alpha1");
// v1 and v2 are equal
assertTrue( v1.compareTo(v2) == 0 );
assertTrue( v2.compareTo(v1) == 0 );
// v1 is newer than v3
assertTrue( v1.compareTo(v3) > 0 );
assertTrue( v3.compareTo(v1) < 0 );
// ergo, v2 should also be newer than v3
assertTrue( v2.compareTo(v3) > 0 ); // FAILS!! returns 0 (equal)
assertTrue( v3.compareTo(v1) < 0 ); // succeeds
This test demonstrates this behavior violates symmetry and transitivity.
Luckily, the fix is easy. A small change to the compareTo method to consider
qualifiers before build numbers relieves this issue. I have a patch that I'll
submit as soon as I have the issue number.
--
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-3046) DefaultArtifactVersion compareTo misbehaves regarding buildNumber 0
[
http://jira.codehaus.org/browse/MNG-3046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Julian updated MNG-3046:
--
Attachment: MNG-3046-maven-artifact.patch
This patch modifies:
org.apache.maven.artifact.versioning.DefaultArtifactVersion
org.apache.maven.artifact.versioning.DefaultArtifactVersionTest
I followed the instructions on creating the patch here:
http://maven.apache.org/guides/development/guide-m2-development.html#Creating%20and%20submitting%20a%20patch
> DefaultArtifactVersion compareTo misbehaves regarding buildNumber 0
> ---
>
> Key: MNG-3046
> URL: http://jira.codehaus.org/browse/MNG-3046
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts
>Affects Versions: 2.0.6
>Reporter: David Julian
> Attachments: MNG-3046-maven-artifact.patch
>
>
> The implementation of Comparable.compareTo(Object) is faulty regarding the
> handling of version numbers where a build number is present but zero. Here's
> a unit test to demonstrate:
> DefaultArtifactVersion v1 = new DefaultArtifactVersion("2.0");
> DefaultArtifactVersion v2 = new DefaultArtifactVersion("2.0-0");
> DefaultArtifactVersion v3 = new DefaultArtifactVersion("2.0-alpha1");
>
> // v1 and v2 are equal
> assertTrue( v1.compareTo(v2) == 0 );
> assertTrue( v2.compareTo(v1) == 0 );
>
> // v1 is newer than v3
> assertTrue( v1.compareTo(v3) > 0 );
> assertTrue( v3.compareTo(v1) < 0 );
>
> // ergo, v2 should also be newer than v3
> assertTrue( v2.compareTo(v3) > 0 ); // FAILS!! returns 0 (equal)
> assertTrue( v3.compareTo(v1) < 0 ); // succeeds
> This test demonstrates this behavior violates symmetry and transitivity.
> Luckily, the fix is easy. A small change to the compareTo method to consider
> qualifiers before build numbers relieves this issue. I have a patch that
> I'll submit as soon as I have the issue number.
--
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-3010) Problem parsing version ranges
[
http://jira.codehaus.org/browse/MNG-3010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99121
]
David Julian commented on MNG-3010:
---
I'm afraid this is the expected behavior for how Maven 2.0.x treats version
numbers.
You hit on the problem at the end when you noted "versions are compared as
strings." For the versions you cite--5.0.9.0 and 5.0.10.0--maven does compare
these as strings and 5.0.9.0 is considered *newer* than 5.0.10.0. Ergo, the
range "[5.0.9.0,5.0.10.0)" is invalid for the same reason "[2,1)" would be: the
version on the left is newer than the one on the right.
Here's the ugly details. Maven recognizes versions that match the following
pattern:
A.B.C-D or
A.B.C-foo
where:
A is the Major Version,
B is the Minor Version,
C is the Incremental Version (also known as Bug Fix),
D is the Build Number, and
'foo' is the Qualifier.
A, B, C, and D, are compared numerically and the qualifier is a string compare.
A version may only have a build number or a qualifier, not both. The numbers
are considered zero if not present i.e., 1.1 is the same as 1.1.0 and 1.1-0.
Here's the important part: any version not matching this pattern is treated
entirely as a String.
Here is the relevant part of org.apache.maven.artifact.versioning.VersionRange:
if ( upperVersion != null && lowerVersion != null &&
upperVersion.compareTo( lowerVersion ) < 0 )
{
throw new InvalidVersionSpecificationException( "Range defies
version ordering: " + spec );
}
Here is a test using
org.apache.maven.artifact.versioning.DefaultArtifactVersion:
public void testMng3010()
{
String s1 = "5.0.9.0";
String s2 = "5.0.10.0";
DefaultArtifactVersion v1 = new DefaultArtifactVersion(s1);
DefaultArtifactVersion v2 = new DefaultArtifactVersion(s2);
assertTrue( s1.compareTo(s2) > 0 ); // 5.0.9.0 > 5.0.10.0 as Strings
...
assertTrue( v1.compareTo(v2) > 0 ); // ... and as maven versions
}
If you have control over how this project tracks its version, consider changing
it to a more Maven-friendly pattern. If not, you'll have to find another way
of dealing with the issue e.g., just picking one and omitting the range
entirely.
> Problem parsing version ranges
> --
>
> Key: MNG-3010
> URL: http://jira.codehaus.org/browse/MNG-3010
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories, POM
>Affects Versions: 2.0.6
> Environment: Linux FC6/ jdk 1.6.0
>Reporter: Gabriele Contini
>
> My pom includes the following dependency:
>
>
> it.unimaticaspa.unique
> unilet-core
> [5.0.9.0,5.0.10.0)
> jar
>
> When i try to build the project i get the following stacktrace:
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Unable to parse version '[5.0.9.0,5.0.10.0)' for dependency
> 'it.unimaticaspa.unique:unilet-core:jar': Range defies version ordering:
> [5.0.9.0,5.0.10.0)
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Unable to parse
> version '[5.0.9.0,5.0.10.0)' for dependency
> 'it.unimaticaspa.unique:unilet-core:jar': Range defies version ordering:
> [5.0.9.0,5.0.10.0)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:552)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> 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:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>
[jira] Closed: (MAVENUPLOAD-1595) java exchange connector (version 1.52_13)
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1595. --- Assignee: Carlos Sanchez Resolution: Fixed > java exchange connector (version 1.52_13) > - > > Key: MAVENUPLOAD-1595 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1595 > Project: maven-upload-requests > Issue Type: Wish >Reporter: eli hasson >Assignee: Carlos Sanchez > > java exchange connector is a pure java api for Microsoft exchange server. > for more information: > [EMAIL PROTECTED] > [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1588) Upload com.flagstonesoftware:transform-swf:jar:2.1.5 to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1588. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload com.flagstonesoftware:transform-swf:jar:2.1.5 to ibiblio > --- > > Key: MAVENUPLOAD-1588 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1588 > Project: maven-upload-requests > Issue Type: Task >Reporter: Craig Condit >Assignee: Carlos Sanchez > > The Transform SWF framework is a collection of classes for each of the tags > and data structures that make up the Flash (SWF) File Format Specification > from Macromedia. The classes provide a completely object-based API for > parsing, manipulating and generating Flash files. This allows Java based > applications to dynamically generate and update files that represent > animations and documents which can be easily distributed and displayed on any > platform that supports a graphical web browser. > There are no external dependencies. -- 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-1554) antlr-3.0 and antlr-runtime-3.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1554. --- Assignee: Carlos Sanchez Resolution: Fixed > antlr-3.0 and antlr-runtime-3.0 > --- > > Key: MAVENUPLOAD-1554 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1554 > Project: maven-upload-requests > Issue Type: Task >Reporter: Mark Proctor >Assignee: Carlos Sanchez > Attachments: antlr-3.0-bundle.jar, antlr-3.0-bundle.jar, > antlr-runtime-3.0.jar, antlr-runtime-3.0.jar > > > Please upload these two antlr 3.0 bundles -- 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-1590) Java Bean Library
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1590. --- Assignee: Carlos Sanchez Resolution: Fixed > Java Bean Library > - > > Key: MAVENUPLOAD-1590 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1590 > Project: maven-upload-requests > Issue Type: Task >Reporter: Hanson Char >Assignee: Carlos Sanchez > Attachments: beanlib-3.3.0beta6.jar, beanlib-hibernate-3.3.0beta6.jar > > > Java Bean Library (beanlib) is a utilities library for use with JavaBean's. > Java Bean Library for Hibernate (beanlib-hibernate) is particularly handy > when used with Hibernate. > It allows developers to easily reuse the same pojo classes for both > persistence instances and data transfer objects. -- 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-1592) Tapestry Bayeux 2.0.0 - Upload Request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1592. --- Assignee: Carlos Sanchez Resolution: Fixed > Tapestry Bayeux 2.0.0 - Upload Request > -- > > Key: MAVENUPLOAD-1592 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1592 > Project: maven-upload-requests > Issue Type: New Feature >Reporter: Jacob von Eyben >Assignee: Carlos Sanchez > > Tapestry Bayeux is a opensource component library for Tapestry 4.1.1. > The library contains various components that extends the default tapestry > component library. > For domain ownership see: > http://jira.codehaus.org/browse/MAVENUPLOAD-1568 -- 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-1593) Upload Tagsoup 1.1.3
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1593. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload Tagsoup 1.1.3 > > > Key: MAVENUPLOAD-1593 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1593 > Project: maven-upload-requests > Issue Type: Task >Reporter: Stephen Duncan Jr >Assignee: Carlos Sanchez > > I uploaded the previous version: > http://jira.codehaus.org/browse/MAVENUPLOAD-1127 -- 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-1589) Upload request for StatSCM 1.0.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1589. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload request for StatSCM 1.0.0 > > > Key: MAVENUPLOAD-1589 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1589 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Doug Culnane >Assignee: Carlos Sanchez > Attachments: rsync_Stat-SCM.sh > > > Maven 2 Mojo Plugin that generates Source Code Management Metrics Reports as > part of the mvn site command. This Plugin is a wrapper around StatCVS and > StatSVN. > Version 1.0.0 is stable and I have have had requests that I upload this to > the central repository. > I have added the public key to the access list on the SourceForge site. > Thanks in advance, > Doug Culnane -- 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-1594) Upload request for tatooine-gtx-0.1.0 to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99130 ] Carlos Sanchez commented on MAVENUPLOAD-1594: - pom has strange characters at end of line ^M > Upload request for tatooine-gtx-0.1.0 to ibiblio > > > Key: MAVENUPLOAD-1594 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1594 > Project: maven-upload-requests > Issue Type: Task >Reporter: tooru noda > > http://tatooine.sourceforge.jp/gtx/bundle/tatooine-gtx-0.1.0-bundle.jar > http://tatooine.sourceforge.jp/gtx/ > http://sourceforge.jp/project/memberlist.php?group_id=2520 > 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] Created: (MASSEMBLY-217) needs to report collision.
needs to report collision.
--
Key: MASSEMBLY-217
URL: http://jira.codehaus.org/browse/MASSEMBLY-217
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-1
Reporter: Kohsuke Kawaguchi
If maps two or more artifacts into the same name, it
needs to be reported as an error.
Maven currently just takes the last one without reporting anything, and as a
result I didn't notice that my assembly descriptor had a problem until I debug
the plugin source code.
This problem is particularly made worse by a broken jar-with-dependencies
example in [the
documentation|http://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html],
which says:
{noformat}
true
runtime
{noformat}
... which maps every dependency to ""
--
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-3047) DefaultArtifactVersion compareTo inconsistent with equals
DefaultArtifactVersion compareTo inconsistent with equals - Key: MNG-3047 URL: http://jira.codehaus.org/browse/MNG-3047 Project: Maven 2 Issue Type: Improvement Components: Artifacts Affects Versions: 2.0.6 Reporter: David Julian Priority: Minor Over the course of investigating MNG-3046, I discovered DefaultArtifactVersion's implementation of Comparable.compareTo() is inconsistent with its equals(Object). (DefaultArtifactVersion doesn't implement equals(...); it's using the instance equals it gets from Object.) The contract for Comparable.compareTo()[1] states, while it's not strictly required the behavior between compareTo and equals be consistent, breaking it should be an overt and visible decision. In the case of DefaultArtifactVersion, there's really no reason not to implement equals and hashCode. I have a fix--I'll attach a patch shortly--that implements equals and hashCode following the recipes from Bloch's "Effective Java." In fact, equals now uses a cleaned-up compareTo, ensuring consistency across these methods. Since the interface ArtifactVersion extends Comparable (as opposed to DefaultArtifactVersion implementing both ArtifactVersion and Comparable) I assume the intent is to be able to compare different ArtifactVersions regardless of implementation. Therefore, I added the equals and hashCode declaration to the interface and made the equals and compareTo implementations work with all ArtifactVersions. Note that this work obviates the patch for MNG-3046. I made that patch small and surgical to fix a major issue. This fix is less urgent--still important, imho--but I wasn't sure if the interface changes were right for the whole project, if such a big change is warranted, etc. The bottom line is: only that patch or this one need be applied, not both. [1] http://java.sun.com/javase/6/docs/api/java/lang/Comparable.html#compareTo(T) -- 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-3047) DefaultArtifactVersion compareTo inconsistent with equals
[ http://jira.codehaus.org/browse/MNG-3047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Julian updated MNG-3047: -- Attachment: MNG-3047-maven-artifact.patch Changes to org.apache.maven.artifact.versioning: ArtifactVersion DefaultArtifactVersion DefaultArtifactVersionTest > DefaultArtifactVersion compareTo inconsistent with equals > - > > Key: MNG-3047 > URL: http://jira.codehaus.org/browse/MNG-3047 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts >Affects Versions: 2.0.6 >Reporter: David Julian >Priority: Minor > Attachments: MNG-3047-maven-artifact.patch > > > Over the course of investigating MNG-3046, I discovered > DefaultArtifactVersion's implementation of Comparable.compareTo() is > inconsistent with its equals(Object). (DefaultArtifactVersion doesn't > implement equals(...); it's using the instance equals it gets from Object.) > The contract for Comparable.compareTo()[1] states, while it's not strictly > required the behavior between compareTo and equals be consistent, breaking it > should be an overt and visible decision. In the case of > DefaultArtifactVersion, there's really no reason not to implement equals and > hashCode. > I have a fix--I'll attach a patch shortly--that implements equals and > hashCode following the recipes from Bloch's "Effective Java." In fact, > equals now uses a cleaned-up compareTo, ensuring consistency across these > methods. > Since the interface ArtifactVersion extends Comparable (as opposed to > DefaultArtifactVersion implementing both ArtifactVersion and Comparable) I > assume the intent is to be able to compare different ArtifactVersions > regardless of implementation. Therefore, I added the equals and hashCode > declaration to the interface and made the equals and compareTo > implementations work with all ArtifactVersions. > Note that this work obviates the patch for MNG-3046. I made that patch small > and surgical to fix a major issue. This fix is less urgent--still important, > imho--but I wasn't sure if the interface changes were right for the whole > project, if such a big change is warranted, etc. The bottom line is: only > that patch or this one need be applied, not both. > [1] > http://java.sun.com/javase/6/docs/api/java/lang/Comparable.html#compareTo(T) -- 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-448) xmlrpc POM should include commons-codec
[ http://jira.codehaus.org/browse/MEV-448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99145 ] Henri Yandell commented on MEV-448: --- Of course, the 3.x ones do not contain jars. Gah. Looking at the two downloads, xmlrpc-2.0.jar and xmlrpc-2.0-applet.jar are replaced by xmlrpc-client-3.0.jar , xmlrpc-common-3.0.jar and xmlrpc-server-3.0.jar. > xmlrpc POM should include commons-codec > --- > > Key: MEV-448 > URL: http://jira.codehaus.org/browse/MEV-448 > Project: Maven Evangelism > Issue Type: Task > Components: Dependencies >Reporter: Brett Porter >Assignee: Henri Yandell > > this appears to be a stub POM, missing the commons-codec and other > dependencies: > http://ws.apache.org/xmlrpc/xmlrpc2/dependencies.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MEV-448) xmlrpc POM should include commons-codec
[ http://jira.codehaus.org/browse/MEV-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed MEV-448. - Resolution: Won't Fix Going with "we're not fixing this, instead get ws.apache.org to put the 3.0 jars and a better pom in the repository". > xmlrpc POM should include commons-codec > --- > > Key: MEV-448 > URL: http://jira.codehaus.org/browse/MEV-448 > Project: Maven Evangelism > Issue Type: Task > Components: Dependencies >Reporter: Brett Porter >Assignee: Henri Yandell > > this appears to be a stub POM, missing the commons-codec and other > dependencies: > http://ws.apache.org/xmlrpc/xmlrpc2/dependencies.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: (MEV-448) xmlrpc POM should include commons-codec
[ http://jira.codehaus.org/browse/MEV-448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99147 ] Henri Yandell commented on MEV-448: --- Which has been done: http://repo1.maven.org/maven2/org/apache/xmlrpc/ > xmlrpc POM should include commons-codec > --- > > Key: MEV-448 > URL: http://jira.codehaus.org/browse/MEV-448 > Project: Maven Evangelism > Issue Type: Task > Components: Dependencies >Reporter: Brett Porter >Assignee: Henri Yandell > > this appears to be a stub POM, missing the commons-codec and other > dependencies: > http://ws.apache.org/xmlrpc/xmlrpc2/dependencies.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: (MDEP-94) Add dependency:tree goal
[ http://jira.codehaus.org/browse/MDEP-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99148 ] Brian Fox commented on MDEP-94: --- I'm getting test failures: java.lang.ClassCastException: java.lang.String at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolve(DefaultRepositoryMetadataManager.java:66) at org.apache.maven.artifact.transform.AbstractVersionTransformation.resolveVersion(AbstractVersionTransformation.java:65) at org.apache.maven.artifact.transform.SnapshotTransformation.transformForResolve(SnapshotTransformation.java:63) at org.apache.maven.artifact.transform.DefaultArtifactTransformationManager.transformForResolve(DefaultArtifactTransformationManager.java:43) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:114) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:73) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:482) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:228) at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:105) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:278) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:70) at org.apache.maven.shared.dependency.tree.DefaultDependencyTreeBuilder.buildDependencyTree(DefaultDependencyTreeBuilder.java:76) at org.apache.maven.plugin.dependency.TreeMojo.execute(TreeMojo.java:143) at org.apache.maven.plugin.dependency.TestTreeMojo.testTreeTestEnvironment(TestTreeMojo.java:79) at org.apache.maven.plugin.dependency.TestTreeMojo.testTreeTestEnvironment(TestTreeMojo.java:79) 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 junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) 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.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) > Add dependency:tree goal > > > Key: MDEP-94 > URL: http://jira.codehaus.org/browse/MDEP-94 > Project: Maven 2.x Dependency Plugin > Issue Type: New Feature >Affects Versions: 2.0-alpha-5 >Reporter: Mark Hobson >Assignee: Brian Fox > Attachments: MDEP-94-test.patch, patch.txt > > > The attached patch adds the help:dependencies goal from the maven-help-plugin > to the maven-dependency-plugin as dependency:tree, as discussed on the dev > mailing list. -- 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: (MDEP-96) Allow includes and excludes to be used simultaneously in the same filter
Allow includes and excludes to be used simultaneously in the same filter Key: MDEP-96 URL: http://jira.codehaus.org/browse/MDEP-96 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: copy-dependencies, unpack-dependencies Affects Versions: 2.0-alpha-4, 2.0-alpha-3, 2.0-alpha-2, 2.0-alpha-1 Reporter: Brian Fox Assignee: Brian Fox The current filters will ignore excludes if includes are specified. Since not specifying an include is the same as include=*. it makes sense to allow the included list to be filtered prior to excluding. -- 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: (MDEP-96) Allow includes and excludes to be used simultaneously in the same filter
[ http://jira.codehaus.org/browse/MDEP-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MDEP-96. - Resolution: Fixed Fix Version/s: 2.0-alpha-5 Includes are processed before excludes now. > Allow includes and excludes to be used simultaneously in the same filter > > > Key: MDEP-96 > URL: http://jira.codehaus.org/browse/MDEP-96 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: copy-dependencies, unpack-dependencies >Affects Versions: 2.0-alpha-1, 2.0-alpha-2, 2.0-alpha-3, 2.0-alpha-4 >Reporter: Brian Fox >Assignee: Brian Fox > Fix For: 2.0-alpha-5 > > > The current filters will ignore excludes if includes are specified. Since not > specifying an include is the same as include=*. it makes sense to allow the > included list to be filtered prior to excluding. -- 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: (MDEP-94) Add dependency:tree goal
[ http://jira.codehaus.org/browse/MDEP-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MDEP-94: -- Component/s: tree > Add dependency:tree goal > > > Key: MDEP-94 > URL: http://jira.codehaus.org/browse/MDEP-94 > Project: Maven 2.x Dependency Plugin > Issue Type: New Feature > Components: tree >Affects Versions: 2.0-alpha-5 >Reporter: Mark Hobson >Assignee: Brian Fox > Attachments: MDEP-94-test.patch, patch.txt > > > The attached patch adds the help:dependencies goal from the maven-help-plugin > to the maven-dependency-plugin as dependency:tree, as discussed on the dev > mailing list. -- 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: (MDEP-92) Add support for transitive dependencies when copying an artifact
[ http://jira.codehaus.org/browse/MDEP-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MDEP-92. - Resolution: Won't Fix This would be complex to add to the copy/unpack goals as they need to resolve everything manually. You can achieve the same effect by using copy-dependencies/unpack-dependencies with includeTransitive=false and groupId=com.foo and artifactId=myartifact. > Add support for transitive dependencies when copying an artifact > > > Key: MDEP-92 > URL: http://jira.codehaus.org/browse/MDEP-92 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: copy >Reporter: Marcel May >Assignee: Brian Fox > > Add support for copying a specific artifact including all its transitive > dependencies. > - The flag should be configurable at the artifact level and default to false, > so the current behaviour stays the same. > - Probably an additional, configurable scope is required at the artifact > level so that the mojo knows which dependencies to copy -- 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: (MENFORCER-5) Add property verification to the enforcer plugin
[ http://jira.codehaus.org/browse/MENFORCER-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MENFORCER-5. - Resolution: Fixed Fix Version/s: 1.0-alpha-3 nice rule, thanks! > Add property verification to the enforcer plugin > > > Key: MENFORCER-5 > URL: http://jira.codehaus.org/browse/MENFORCER-5 > Project: Maven 2.x Enforcer Plugin > Issue Type: New Feature > Components: Standard Rules >Affects Versions: 1.0-alpha-1 > Environment: any >Reporter: Paul Gier >Assignee: Brian Fox > Fix For: 1.0-alpha-3 > > Attachments: requireproperty.patch > > > It would be helpful to have a standard rule to test for the presence of a > particular property. If this property is not set, the build should fail or > warn the user with a configurable error message. > The patch includes the new rule and a test case. And the new rule can also > test that the property value matches a given regular expression. -- 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: (MENFORCER-6) add optional message to rules
add optional message to rules - Key: MENFORCER-6 URL: http://jira.codehaus.org/browse/MENFORCER-6 Project: Maven 2.x Enforcer Plugin Issue Type: Improvement Components: Standard Rules Affects Versions: 1.0-alpha-2, 1.0-alpha-1 Reporter: Brian Fox Assignee: Brian Fox Add a parameter to allow a better message to the user. (ie WHY is this rule required, 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] Closed: (MENFORCER-6) add optional message to rules
[ http://jira.codehaus.org/browse/MENFORCER-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MENFORCER-6. - Resolution: Fixed Fix Version/s: 1.0-alpha-3 added message param to all standard rules. Also updated the error message pointing the user to look up to see individual error messages. > add optional message to rules > - > > Key: MENFORCER-6 > URL: http://jira.codehaus.org/browse/MENFORCER-6 > Project: Maven 2.x Enforcer Plugin > Issue Type: Improvement > Components: Standard Rules >Affects Versions: 1.0-alpha-1, 1.0-alpha-2 >Reporter: Brian Fox >Assignee: Brian Fox > Fix For: 1.0-alpha-3 > > > Add a parameter to allow a better message to the user. (ie WHY is this rule > required, 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-196) Project "Could not publish to server"
[ http://jira.codehaus.org/browse/MECLIPSE-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99159 ] Tim West commented on MECLIPSE-196: --- I've had this problem also and have found a workaround as described below. Seems this has to do with WTP generation of ".settings/org.eclipse.wst.common.component" and non-generation of ".settings/.component". My setup is that I'm using mvn eclipse:clean eclipse:eclipse to generate artefacts, and I have WTP 1.5 enabled in my active profile in my local settings.xml: theProfile 1.5 I have an EAR project that contains an EJB JAR and several library JARs which I'm developing in Eclipse. In this situation, immediately after running mvn eclipse:eclipse, I get the error reported in this defect. I can get around this by adding a known-good ".settings/.component" file for each project (the EAR, EJB JAR and library JARs). The contents of the .component file are "known good" from pre-Maven2. Once I do this, I can build and deploy the EAR successfully. Also, I can remove the ".settings/org.eclipse.wst.common.component" file that mvn eclipse:eclipse generates - this is apparently unneeded for these projects. > Project "Could not publish to server" > - > > Key: MECLIPSE-196 > URL: http://jira.codehaus.org/browse/MECLIPSE-196 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: WTP support >Affects Versions: 2.3 > Environment: Eclipse 3.2.1 and WTP 1.5.2, JBoss AS 4.0.4.GA, J2EE > appliaction comprized of an EJB and Web module, all bundled withing an EAR > module. >Reporter: Srepfler Srgjan > > After I modify the EAR project configuration in order to remove problems on > the EAR project (the plugin adds the Java project facet and I must modify by > hand the org.eclipse.wst.common.project.facet.core.xml file in order the > remove it,this should be a separate JIRA I think) my project can get built > (no red decorators on the projects). However, I add the server definition and > when I try to publish the project I get an error "Could not publish to the > server." with the following Exception Stack Trace: > Error > Thu Nov 23 20:56:58 CET 2006 > Could not publish to the server. > org.eclipse.emf.common.util.BasicEList$BasicIndexOutOfBoundsException: > index=0, size=0 > at org.eclipse.emf.common.util.BasicEList.get(BasicEList.java:512) > at > org.eclipse.jst.j2ee.componentcore.EnterpriseArtifactEdit.getDeploymentDescriptorRoot(EnterpriseArtifactEdit.java:154) > at > org.eclipse.jst.j2ee.componentcore.util.EARArtifactEdit.getApplication(EARArtifactEdit.java:291) > at > org.eclipse.jst.j2ee.internal.deployables.J2EEFlexProjDeployable.isNestedJ2EEModule(J2EEFlexProjDeployable.java:528) > at > org.eclipse.jst.j2ee.internal.deployables.J2EEFlexProjDeployable.shouldIncludeUtilityComponent(J2EEFlexProjDeployable.java:135) > at > org.eclipse.wst.web.internal.deployables.ComponentDeployable.addUtilMembers(ComponentDeployable.java:347) > at > org.eclipse.jst.j2ee.internal.deployables.J2EEFlexProjDeployable.members(J2EEFlexProjDeployable.java:193) > at > org.eclipse.jst.server.generic.core.internal.publishers.AbstractModuleAssembler.copyModule(AbstractModuleAssembler.java:160) > at > org.eclipse.jst.server.generic.core.internal.publishers.EarModuleAssembler.assemble(EarModuleAssembler.java:36) > at > org.eclipse.jst.server.generic.core.internal.publishers.AntPublisher.assembleModule(AntPublisher.java:124) > at > org.eclipse.jst.server.generic.core.internal.publishers.AntPublisher.publish(AntPublisher.java:109) > at > org.eclipse.jst.server.generic.core.internal.GenericServerBehaviour.publishModule(GenericServerBehaviour.java:91) > at > org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDelegate.java:676) > at > org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModules(ServerBehaviourDelegate.java:756) > at > org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:611) > at org.eclipse.wst.server.core.internal.Server.doPublish(Server.java:862) > at org.eclipse.wst.server.core.internal.Server.publish(Server.java:850) > at > org.eclipse.wst.server.core.internal.PublishServerJob.run(PublishServerJob.java:142) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) > I don't see people complaining so perhaps it's my fault. Any ideas? If more > info is needed please ask. > I can start the server with no problems and it's on a path with no spaces. > Thanks Srgjan -- 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
