[jira] (MSKINS-83) Table header are not highlighted enough
Christophe Lallement created MSKINS-83: -- Summary: Table header are not highlighted enough Key: MSKINS-83 URL: https://jira.codehaus.org/browse/MSKINS-83 Project: Maven Skins Issue Type: Improvement Components: Fluido Skin Affects Versions: fluido-1.3.0 Reporter: Christophe Lallement When you draw table (with xdoc for example) The row header has the same background color as other row, meaning it's very difficult to see there is a header. Trying to add bgcolor to xdoc element doesn't change anything. Regards Christophe -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4153) Profile activation based on module in development status (i.e. -SNAPSHOT)
[ https://jira.codehaus.org/browse/MNG-4153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=277268#comment-277268 ] Christophe Lallement commented on MNG-4153: --- I confirm that's an interesting feature. For example our use case is: When we deploy a *snapshot* we do not send the same email (changelog) than we deploy a *true release*. > Profile activation based on module in development status (i.e. -SNAPSHOT) > - > > Key: MNG-4153 > URL: https://jira.codehaus.org/browse/MNG-4153 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Profiles >Reporter: jieryn >Priority: Minor > Fix For: Issues to be reviewed for 3.x > > > It would be useful to have Maven profile activation, and deactivation, based > on whether the module is a development version (i.e. -SNAPSHOT), or not. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSHADE-82) Add the ability to deploy a reduced pom in place of the original
Add the ability to deploy a reduced pom in place of the original - Key: MSHADE-82 URL: http://jira.codehaus.org/browse/MSHADE-82 Project: Maven 2.x Shade Plugin Issue Type: Improvement Affects Versions: 1.3.3 Reporter: Christophe Lallement shade plugin is very useful to merge some jar into one. It can be used when we have a *terminal* pom (i mean a pom where no other pom can depend). sometime we want to have a project packaged with it's dependencies into one (for ex. because we use only a few class of a dep. or to avoid conflict) and deploy for other projects that can add dependencies on it. Shade plugin works very fine until the generation of jar and reduced pom. So at this stage *we can deploy merging jar but not the reduced pom*. I looking for other plugin / maven tricks to do this task but doesn't find anything. *Is this task can be done into the shade plugin ?* Thx Christopje -- 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: (MCHANGES-173) Failed to generate report when version is not the last schedule.
[
http://jira.codehaus.org/browse/MCHANGES-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=199654#action_199654
]
Christophe Lallement commented on MCHANGES-173:
---
Hi Dennis,
All release together we have more than 25 entries, but concerning the 1.3.0
just 2-3 issues.
So i'll do the test asap.
> Failed to generate report when version is not the last schedule.
>
>
> Key: MCHANGES-173
> URL: http://jira.codehaus.org/browse/MCHANGES-173
> Project: Maven 2.x Changes Plugin
> Issue Type: Bug
> Components: announcement, jira-report
>Affects Versions: 2.1
>Reporter: Christophe Lallement
>Priority: Critical
>
> We try to release a snapshot version (1.2.3-SNAPSHOT) but this version is not
> define as last release into JIRA version.
> into JIRA we have define version as this (by schedule order)
> * 1.3.0
> * 1.2.3
> * 1.2.2
>
> When we try to generate jira report for e version 1.2.3-SNAPSHOT we have this
> error: (i don't if it occurs during jira report or annoucement)
> PS: if i schedule 1.2.3 in first position into JIRa, it works fine.
> {code}...
> [DEBUG] Default ResourceManager initialization complete.
> [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Literal
> [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Macro
> [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Parse
> [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Include
> [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach
> [DEBUG] Created '20' parsers.
> [DEBUG] Velocimacro : initialization starting.
> [DEBUG] Velocimacro : allowInline = true : VMs can be defined inline in
> templates
> [DEBUG] Velocimacro : allowInlineToOverride = false : VMs defined inline may
> NOT replace previous VM definitions
> [DEBUG] Velocimacro : allowInlineLocal = false : VMs defined inline will be
> global in scope if allowed.
> [DEBUG] Velocimacro : autoload off : VM system will not automatically reload
> global library macros
> [DEBUG] Velocimacro : Velocimacro : initialization complete.
> [DEBUG] RuntimeInstance successfully initialized.
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-changes-plugin:2.1:announcement-generate' -->
> [DEBUG] (s) artifactId = feedapi
> [DEBUG] (f) basedir = C:\HOMEWARE\eclipse-341\workspace\feedapi
> [DEBUG] (s) developmentTeam = vol-domino-feedapi team
> [DEBUG] (s) finalName = feedapi-1.2.3-SNAPSHOT
> [DEBUG] (f) generateJiraAnnouncement = true
> [DEBUG] (s) groupId = ged.domino
> [DEBUG] (s) introduction = FeedAPI is a framework to send feed between
> component (In and Out process) with high frequency const
> aint
> [DEBUG] (f) jiraMerge = false
> [DEBUG] (f) jiraXML =
> C:\HOMEWARE\eclipse-341\workspace\feedapi\target\jira-announcement.xml
> [DEBUG] (f) maxEntries = 25
> [DEBUG] (s) outputDirectory =
> C:\HOMEWARE\eclipse-341\workspace\feedapi\target\announcement
> [DEBUG] (s) packaging = jar
> [DEBUG] (f) project = MavenProject: ged.domino:feedapi:1.2.3-SNAPSHOT @
> C:\HOMEWARE\eclipse-341\workspace\feedapi\pom.xml
> [DEBUG] (f) resolutionIds = Fixed
> [DEBUG] (f) settings = org.apache.maven.settings.setti...@1eb62b6
> [DEBUG] (f) statusIds = Closed
> [DEBUG] (f) template = feedapi-announcement.vm
> [DEBUG] (f) templateDirectory = our-announcements
> [DEBUG] (s) url = http://frontools/maven_site/domino-parent/feedapi
> [DEBUG] (s) version = 1.2.3-SNAPSHOT
> [DEBUG] (s) xmlPath =
> C:\HOMEWARE\eclipse-341\workspace\feedapi\src\changes\changes.xml
> [DEBUG] -- end configuration --
> [INFO] [changes:announcement-generate {execution: announcement-generate}]
> [DEBUG] JIRA lives at: https://jtbox.fr.world.socgen/jira
> [DEBUG] The JIRA URL https://jtbox.fr.world.socgen/jira/browse/TRAFEEDAPI
> doesn't include a pid, trying to extract it from JIRA.
> [DEBUG] Successfully reached JIRA.
> 26 ao¹t 2009 10:54:10 org.apache.commons.httpclient.HttpMethodBase
> getResponseBody
> ATTENTION: Going to buffer response body of large or unknown size. Using
> getResponseBodyAsStream instead is recommended.
> [DEBUG] Found the pid 10236 at
> https://jtbox.fr.world.socgen/jira/browse/TRAFEEDAPI
> [ERROR] maven-changes-plugin: None of the configured sortColumnNames 'null'
> are correct.
> [DEBUG] download jira issues from url
> https://jtbox.fr.world.socgen/jira/secure/IssueNavigator.jspa?view=rss&pid=10236&statusIds=
> &resolutionIds=1&tempMax=25&reset=true&decorator=none
> [INFO] Downloading from JIRA at:
> https://jtbox.fr.world.socgen/jira/secure/IssueNavigator.jspa?view=rss&pid=10236&statusIds=6&res
> lutionIds=1&tempMax=25&reset=true&decorator=none
> 26 ao¹t 2009 10:54:10 org.apache.commons.httpclient.HttpMe
[jira] Created: (MJAR-129) Already build test-jar for project which packaging is not jar
Already build test-jar for project which packaging is not jar - Key: MJAR-129 URL: http://jira.codehaus.org/browse/MJAR-129 Project: Maven 2.x Jar Plugin Issue Type: Bug Affects Versions: 2.2 Environment: java 1.6 mvn 2.2.1, mvn 2.0.9, mvn 2.1.0 Reporter: Christophe Lallement Attachments: test.zip The classic use case is when you use multi-module project. pomA (packaging pom) -> pomB (packaging jar) -> pomC (packaging jar) -> pomD (packaging pom) pomB,C,D inherit from pomA We define common plugin configuration into pomA, for example say to jar plugin to build test jar. but in some case it make not sense (for example when pom is type of 'pom') and in this case an empty jar is construct (then uploaded when we deploy) Maybe a check to detect zip file is empty could be sufficient or attache this plugin only on specific pom packaging (jar/war/ear ...) I have attached a sample, just unzip and run mvn package inside "test" directory. Regards Christophe -- 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: (MCHANGES-141) Jira Report fails to pick up issues that contain multiple fix-for elements.
[
http://jira.codehaus.org/browse/MCHANGES-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=190077#action_190077
]
Christophe Lallement commented on MCHANGES-141:
---
Hello Mark
I have the same problem (fix to more that one version produce an error on the
changes:announcement-generate.
Find below the error stacktrace.
Could you reproduce this pb ? (very simple, just edit a case and choose many
version to fix).
It's a very common case when tou fix a bug on a production version: You want to
fix on the prod branch and report them on the next dev branch.
It's really a pb because when we have to patch a production branch, report
already failed.
And i don't know why but on console you do not find release 1.2.3, but it's
really define into JIRa and have only on attached case (with 2 fixForVersion
release: 1.2.3 and 1.3.0).
{code}
[DEBUG] Downloading from JIRA was successful
[INFO] Creating announcement file from JIRA releases...
[DEBUG] Found 5 releases.
[DEBUG] The release: 1.1.0 has 1 actions.
[DEBUG] The release: 1.3.0 has 12 actions.
[DEBUG] The release: 1.2.1 has 6 actions.
[DEBUG] The release: 1.2.2 has 1 actions.
[DEBUG] The release: 1.2.0 has 4 actions.
[DEBUG] The release: 1.1.0 has 1 actions.
[DEBUG] The release: 1.3.0 has 12 actions.
[DEBUG] The release: 1.2.1 has 6 actions.
[DEBUG] The release: 1.2.2 has 1 actions.
[DEBUG] The release: 1.2.0 has 4 actions.
{code}
example of xml extract from jira:
{code}
...
Tue, 25 Aug 2009 15:01:45 +0200 (CEST)
1.0.*
1.1.0
1.2.0
1.2.1
1.2.2
1.3.0
1.2.3
1.3.0
...
{code}
{code:title=stack trace error}
org.apache.maven.lifecycle.LifecycleExecutionException: Couldn't find the
release '1.2.3' among the supplied releases.
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Couldn't find the
release '1.2.3' among the supplied releases.
at
org.apache.maven.plugin.announcement.AnnouncementMojo.getLatestRelease(AnnouncementMojo.java:460)
at
org.apache.maven.plugin.announcement.AnnouncementMojo.doGenerate(AnnouncementMojo.java:349)
at
org.apache.maven.plugin.announcement.AnnouncementMojo.doJiraGenerate(AnnouncementMojo.java:582)
at
org.apache.maven.plugin.announcement.AnnouncementMojo.execute(AnnouncementMojo.java:335)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
... 17 more
{code}
> Jira Report fails to pick up issues that contain multiple fix-for elements.
> ---
>
> Key: MCHANGES-141
> URL: http://jira.codehaus.org/browse/MCHANGES-141
> Project: Maven 2.x Changes Plugin
> Issue Type: Bug
> Components: jira-report
>Affects Versions: 2.1
>Reporter: Mark Derricutt
> Attachments: multipleFixFors.patch
>
>
> When a jira ticket is associated with multiple versions in its fix-for list,
> the report fails to corre
[jira] Created: (MCHANGES-173) Failed to generate report when version is not the last schedule.
Failed to generate report when version is not the last schedule.
Key: MCHANGES-173
URL: http://jira.codehaus.org/browse/MCHANGES-173
Project: Maven 2.x Changes Plugin
Issue Type: Bug
Components: announcement, jira-report
Affects Versions: 2.1
Reporter: Christophe Lallement
Priority: Critical
We try to release a snapshot version (1.2.3-SNAPSHOT) but this version is not
define as last release into JIRA version.
into JIRA we have define version as this (by schedule order)
* 1.3.0
* 1.2.3
* 1.2.2
When we try to generate jira report for e version 1.2.3-SNAPSHOT we have this
error: (i don't if it occurs during jira report or annoucement)
PS: if i schedule 1.2.3 in first position into JIRa, it works fine.
{code}...
[DEBUG] Default ResourceManager initialization complete.
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Literal
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Macro
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Parse
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Include
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach
[DEBUG] Created '20' parsers.
[DEBUG] Velocimacro : initialization starting.
[DEBUG] Velocimacro : allowInline = true : VMs can be defined inline in
templates
[DEBUG] Velocimacro : allowInlineToOverride = false : VMs defined inline may
NOT replace previous VM definitions
[DEBUG] Velocimacro : allowInlineLocal = false : VMs defined inline will be
global in scope if allowed.
[DEBUG] Velocimacro : autoload off : VM system will not automatically reload
global library macros
[DEBUG] Velocimacro : Velocimacro : initialization complete.
[DEBUG] RuntimeInstance successfully initialized.
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-changes-plugin:2.1:announcement-generate' -->
[DEBUG] (s) artifactId = feedapi
[DEBUG] (f) basedir = C:\HOMEWARE\eclipse-341\workspace\feedapi
[DEBUG] (s) developmentTeam = vol-domino-feedapi team
[DEBUG] (s) finalName = feedapi-1.2.3-SNAPSHOT
[DEBUG] (f) generateJiraAnnouncement = true
[DEBUG] (s) groupId = ged.domino
[DEBUG] (s) introduction = FeedAPI is a framework to send feed between
component (In and Out process) with high frequency const
aint
[DEBUG] (f) jiraMerge = false
[DEBUG] (f) jiraXML =
C:\HOMEWARE\eclipse-341\workspace\feedapi\target\jira-announcement.xml
[DEBUG] (f) maxEntries = 25
[DEBUG] (s) outputDirectory =
C:\HOMEWARE\eclipse-341\workspace\feedapi\target\announcement
[DEBUG] (s) packaging = jar
[DEBUG] (f) project = MavenProject: ged.domino:feedapi:1.2.3-SNAPSHOT @
C:\HOMEWARE\eclipse-341\workspace\feedapi\pom.xml
[DEBUG] (f) resolutionIds = Fixed
[DEBUG] (f) settings = org.apache.maven.settings.setti...@1eb62b6
[DEBUG] (f) statusIds = Closed
[DEBUG] (f) template = feedapi-announcement.vm
[DEBUG] (f) templateDirectory = our-announcements
[DEBUG] (s) url = http://frontools/maven_site/domino-parent/feedapi
[DEBUG] (s) version = 1.2.3-SNAPSHOT
[DEBUG] (s) xmlPath =
C:\HOMEWARE\eclipse-341\workspace\feedapi\src\changes\changes.xml
[DEBUG] -- end configuration --
[INFO] [changes:announcement-generate {execution: announcement-generate}]
[DEBUG] JIRA lives at: https://jtbox.fr.world.socgen/jira
[DEBUG] The JIRA URL https://jtbox.fr.world.socgen/jira/browse/TRAFEEDAPI
doesn't include a pid, trying to extract it from JIRA.
[DEBUG] Successfully reached JIRA.
26 ao¹t 2009 10:54:10 org.apache.commons.httpclient.HttpMethodBase
getResponseBody
ATTENTION: Going to buffer response body of large or unknown size. Using
getResponseBodyAsStream instead is recommended.
[DEBUG] Found the pid 10236 at
https://jtbox.fr.world.socgen/jira/browse/TRAFEEDAPI
[ERROR] maven-changes-plugin: None of the configured sortColumnNames 'null' are
correct.
[DEBUG] download jira issues from url
https://jtbox.fr.world.socgen/jira/secure/IssueNavigator.jspa?view=rss&pid=10236&statusIds=
&resolutionIds=1&tempMax=25&reset=true&decorator=none
[INFO] Downloading from JIRA at:
https://jtbox.fr.world.socgen/jira/secure/IssueNavigator.jspa?view=rss&pid=10236&statusIds=6&res
lutionIds=1&tempMax=25&reset=true&decorator=none
26 ao¹t 2009 10:54:10 org.apache.commons.httpclient.HttpMethodBase
getResponseBody
ATTENTION: Going to buffer response body of large or unknown size. Using
getResponseBodyAsStream instead is recommended.
[DEBUG] Downloading from JIRA was successful
[INFO] Creating announcement file from JIRA releases...
[DEBUG] Found 5 releases.
[DEBUG] The release: 1.1.0 has 1 actions.
[DEBUG] The release: 1.3.0 has 12 actions.
[DEBUG] The release: 1.2.1 has 6 actions.
[DEBUG] The release: 1.2.2 has 1 actions.
[DEBUG] The release: 1.2.0 has 4 actions.
[DEBUG] The release: 1.1.0 has 1 actions.
[DEBUG] The release: 1.3.0 has 12 ac
[jira] Commented: (MGPG-9) gpg plugin hangs when it should prompt for the secret key passphrase hangs
[ http://jira.codehaus.org/browse/MGPG-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=185560#action_185560 ] Christophe Lallement commented on MGPG-9: - I find a workaround: it seems that mvn:release fork the maven command and additionnal args are not passed to the new command. just add this option on commande line: > mvn -Dgpg.passphrase="xxx" -Darguments="-Dgpg.passphrase=x" > release:perform it works fine for me (same tips for mvn:perform) Regards Christophe > gpg plugin hangs when it should prompt for the secret key passphrase hangs > -- > > Key: MGPG-9 > URL: http://jira.codehaus.org/browse/MGPG-9 > Project: Maven 2.x GPG Plugin > Issue Type: Bug > Environment: Maven 2.0.6, JDK 1.5.0_11, Linux 2.6.x >Reporter: Alex Karasulu > > When used in conjunction with the release plugin the release:perform command > hangs when it should prompt for the secret key passphrase. Interestingly > enough when I put the passphrase into the settings.xml file the plugin does > not hang. I suspect the prompt is failing to show up. -- 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: (MGPG-9) gpg plugin hangs when it should prompt for the secret key passphrase hangs
[ http://jira.codehaus.org/browse/MGPG-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=185559#action_185559 ] Christophe Lallement commented on MGPG-9: - Hi, it's the same thing with mvn:prepare (passprase pass as property) but it seems gpg wait for a pass phrase without prompting. tested with maven 2.2.0. > gpg plugin hangs when it should prompt for the secret key passphrase hangs > -- > > Key: MGPG-9 > URL: http://jira.codehaus.org/browse/MGPG-9 > Project: Maven 2.x GPG Plugin > Issue Type: Bug > Environment: Maven 2.0.6, JDK 1.5.0_11, Linux 2.6.x >Reporter: Alex Karasulu > > When used in conjunction with the release plugin the release:perform command > hangs when it should prompt for the secret key passphrase. Interestingly > enough when I put the passphrase into the settings.xml file the plugin does > not hang. I suspect the prompt is failing to show up. -- 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: (MCHANGES-106) the generated jira-result.xml contains no jira-items
[ http://jira.codehaus.org/browse/MCHANGES-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162050#action_162050 ] Christophe Lallement commented on MCHANGES-106: --- I confirm we have the same problem. The JIRA url dump on the log is [INFO] Downloading from JIRA at: https:///jira/secure/IssueNavigator.jspa?view=rss&pid=10236&statusIds=6&resolutionIds=1&tempMax=25&reset=true&decorator=none this request return an empty list of release/issue. Te same think when i make this request into a browser (with authentication or not) we use JIRA Version: 3.12.1-#299 Regards > the generated jira-result.xml contains no jira-items > > > Key: MCHANGES-106 > URL: http://jira.codehaus.org/browse/MCHANGES-106 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: jira-report >Affects Versions: 2.0-beta-3 > Environment: windows maven-2.0.8 jira Professional Edition, Version: > 3.11-#288 >Reporter: Rene Boers >Priority: Critical > Attachments: jira-report.html, jira-report.log, jira-results.xml, > jira-results.xml, pom.xml, screenshot-1.jpg > > > when i run the maven site or mvn changes:jira-report the resulting > jira-reports doesnot contain jira-issues it only contains the link to the > searchrequest. > This results in an empty jira-report. > I have included the jira-reports.xml and the logging from the mvn > changes:jira report. > When open the jira-reports.xml in firefox i do have a page with the request > jira-issues available. In explorer i just get the representation of the xml > file. > Any suggestions why no jira-report is generated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2287) New opensource library (swing) to sync with central repository: JBusyComponent
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158118#action_158118 ] Christophe Lallement commented on MAVENUPLOAD-2287: --- All is all right ? Thx > New opensource library (swing) to sync with central repository: JBusyComponent > -- > > Key: MAVENUPLOAD-2287 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2287 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Christophe Lallement > > "org.divxdede","mavens...@shell.sourceforge.net:/home/users/o/ou/ouaibsky/maven/m2repo","rsync_ssh","Ouaibsky","ouaib...@free.fr",, -- 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-2287) New opensource library (swing) to sync with central repository: JBusyComponent
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=157117#action_157117 ] Christophe Lallement commented on MAVENUPLOAD-2287: --- yes, let's go for "com.google.code.jbusycomponent ","[EMAIL PROTECTED]:/home/users/o/ou/ouaibsky/maven/m2repo","rsync_ssh","Ouaibsky","[EMAIL PROTECTED]",, > New opensource library (swing) to sync with central repository: JBusyComponent > -- > > Key: MAVENUPLOAD-2287 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2287 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Christophe Lallement > > "org.divxdede","[EMAIL > PROTECTED]:/home/users/o/ou/ouaibsky/maven/m2repo","rsync_ssh","Ouaibsky","[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] Commented: (MAVENUPLOAD-2286) nez sync rule from sourceforge project
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=157116#action_157116 ] Christophe Lallement commented on MAVENUPLOAD-2286: --- Yes you'r right but when i look at https://svn.apache.org/repos/asf/maven/repository-tools/trunk/src/bin/synchronize/m2-sync/sync.csvjv i find both: some project with only root dns and other with full dns name. let's go for "net.java.dev.jvyaml","[EMAIL PROTECTED]:/home/users/o/ou/ouaibsky/maven/m2repo","rsync_ssh","Ouaibsky","[EMAIL PROTECTED]",, > nez sync rule from sourceforge project > -- > > Key: MAVENUPLOAD-2286 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2286 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Christophe Lallement > > "org.jvyaml","[EMAIL > PROTECTED]:/home/users/o/ou/ouaibsky/maven/m2repo","rsync_ssh","Ouaibsky","ouaibsky.free.fr",, -- 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-2287) New opensource library (swing) to sync with central repository: JBusyComponent
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156949#action_156949 ] Christophe Lallement commented on MAVENUPLOAD-2287: --- Hi Carlos, Is there something else that's wrong ? Regards, Christophe > New opensource library (swing) to sync with central repository: JBusyComponent > -- > > Key: MAVENUPLOAD-2287 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2287 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Christophe Lallement > > "org.divxdede","[EMAIL > PROTECTED]:/home/users/o/ou/ouaibsky/maven/m2repo","rsync_ssh","Ouaibsky","[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] Commented: (MAVENUPLOAD-2287) New opensource library (swing) to sync with central repository: JBusyComponent
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156211#action_156211 ] Christophe Lallement commented on MAVENUPLOAD-2287: --- OK, sorry for the incomprehension, find below the right groupId "com.google","[EMAIL PROTECTED]:/home/users/o/ou/ouaibsky/maven/m2repo","rsync_ssh","Ouaibsky","[EMAIL PROTECTED]",, > New opensource library (swing) to sync with central repository: JBusyComponent > -- > > Key: MAVENUPLOAD-2287 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2287 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Christophe Lallement > > "org.divxdede","[EMAIL > PROTECTED]:/home/users/o/ou/ouaibsky/maven/m2repo","rsync_ssh","Ouaibsky","[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] Commented: (MAVENUPLOAD-2286) nez sync rule from sourceforge project
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156210#action_156210 ] Christophe Lallement commented on MAVENUPLOAD-2286: --- OK, sorry for the incomprehension, find below the right groupId "net.java","[EMAIL PROTECTED]:/home/users/o/ou/ouaibsky/maven/m2repo","rsync_ssh","Ouaibsky","[EMAIL PROTECTED]",, > nez sync rule from sourceforge project > -- > > Key: MAVENUPLOAD-2286 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2286 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Christophe Lallement > > "org.jvyaml","[EMAIL > PROTECTED]:/home/users/o/ou/ouaibsky/maven/m2repo","rsync_ssh","Ouaibsky","ouaibsky.free.fr",, -- 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: (MAVENUPLOAD-2286) nez sync rule from sourceforge project
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=155811#action_155811 ] Christophe Lallement edited comment on MAVENUPLOAD-2286 at 12/1/08 3:11 AM: maybe there is an error and the hostname to sync is: "org.jvyaml","[EMAIL PROTECTED]:/home/users/o/ou/ouaibsky/maven/m2repo","rsync_ssh","Ouaibsky","[EMAIL PROTECTED]",, was (Author: christophe): maybe there is an error and the hostname to sync is: "org.jvyaml","[EMAIL PROTECTED]:/home/users/o/ou/ouaibsky/maven/m2repo","rsync_ssh","Ouaibsky","ouaibsky.free.fr",, > nez sync rule from sourceforge project > -- > > Key: MAVENUPLOAD-2286 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2286 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Christophe Lallement > > "org.jvyaml","[EMAIL > PROTECTED]:/home/users/o/ou/ouaibsky/maven/m2repo","rsync_ssh","Ouaibsky","ouaibsky.free.fr",, -- 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-2286) nez sync rule from sourceforge project
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=155811#action_155811 ] Christophe Lallement commented on MAVENUPLOAD-2286: --- maybe there is an error and the hostname to sync is: "org.jvyaml","[EMAIL PROTECTED]:/home/users/o/ou/ouaibsky/maven/m2repo","rsync_ssh","Ouaibsky","ouaibsky.free.fr",, > nez sync rule from sourceforge project > -- > > Key: MAVENUPLOAD-2286 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2286 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Christophe Lallement > > "org.jvyaml","[EMAIL > PROTECTED]:/home/users/o/ou/ouaibsky/maven/m2repo","rsync_ssh","Ouaibsky","ouaibsky.free.fr",, -- 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-2287) New opensource library (swing) to sync with central repository: JBusyComponent
New opensource library (swing) to sync with central repository: JBusyComponent -- Key: MAVENUPLOAD-2287 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2287 Project: Maven Upload Requests Issue Type: Wish Reporter: Christophe Lallement "org.divxdede","[EMAIL PROTECTED]:/home/users/o/ou/ouaibsky/maven/m2repo","rsync_ssh","Ouaibsky","[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: (MAVENUPLOAD-2286) nez sync rule from sourceforge project
nez sync rule from sourceforge project -- Key: MAVENUPLOAD-2286 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2286 Project: Maven Upload Requests Issue Type: Wish Reporter: Christophe Lallement "org.jvyaml","[EMAIL PROTECTED]:/home/users/o/ou/ouaibsky/maven/m2repo","rsync_ssh","Ouaibsky","ouaibsky.free.fr",, -- 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: (MCHANGES-107) Add http output format for mail annoucement
[ http://jira.codehaus.org/browse/MCHANGES-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131610#action_131610 ] Christophe Lallement commented on MCHANGES-107: --- To udpate my request title, understand HTML in place of Http. > Add http output format for mail annoucement > --- > > Key: MCHANGES-107 > URL: http://jira.codehaus.org/browse/MCHANGES-107 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement > Components: announcement >Reporter: Christophe Lallement > Attachments: custom-mail-content-type.patch > > > We want to use a custom annoucement template wich is a HTML template to get a > better look into our mail. > No pb to do this except the output format is hardcoded into PLAINTEXT into > plugin. > Can you add an option into the plugin configuration (after > tag for example) to specify the output type (HTMP or > PLAINTEXT). > The default should be "text/plain". > The Hardcoded feature is in file ProjectJavamailMailSender.java (svn rev > 553871) line 181. > Thx > Christophe -- 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: (MCHANGES-107) Add http output format for mail annoucement
[ http://jira.codehaus.org/browse/MCHANGES-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lallement updated MCHANGES-107: -- Attachment: custom-mail-content-type.patch This is a patch from tag "maven-changes-plugin-2.0" Patch made from root project (where pom.xml is located) Compilation is ok, no test provided. > Add http output format for mail annoucement > --- > > Key: MCHANGES-107 > URL: http://jira.codehaus.org/browse/MCHANGES-107 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement > Components: announcement >Reporter: Christophe Lallement > Attachments: custom-mail-content-type.patch > > > We want to use a custom annoucement template wich is a HTML template to get a > better look into our mail. > No pb to do this except the output format is hardcoded into PLAINTEXT into > plugin. > Can you add an option into the plugin configuration (after > tag for example) to specify the output type (HTMP or > PLAINTEXT). > The default should be "text/plain". > The Hardcoded feature is in file ProjectJavamailMailSender.java (svn rev > 553871) line 181. > Thx > Christophe -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCHANGES-107) Add http output format for mail annoucement
Add http output format for mail annoucement --- Key: MCHANGES-107 URL: http://jira.codehaus.org/browse/MCHANGES-107 Project: Maven 2.x Changes Plugin Issue Type: Improvement Components: announcement Reporter: Christophe Lallement We want to use a custom annoucement template wich is a HTML template to get a better look into our mail. No pb to do this except the output format is hardcoded into PLAINTEXT into plugin. Can you add an option into the plugin configuration (after tag for example) to specify the output type (HTMP or PLAINTEXT). The default should be "text/plain". The Hardcoded feature is in file ProjectJavamailMailSender.java (svn rev 553871) line 181. Thx Christophe -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (SCM-317) Add edit and unedit commands
[ http://jira.codehaus.org/browse/SCM-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123238 ] christophe edited comment on SCM-317 at 2/11/08 4:46 AM: --- Hello Any news for integration of this patch into an official release ? It works "like a charm" into my company since many months. Regards. was (Author: christophe): Hello Any news for integration of this path into an official release ? It work like a charm in my copany since many months. Regards. > Add edit and unedit commands > > > Key: SCM-317 > URL: http://jira.codehaus.org/browse/SCM-317 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-provider-cvs >Reporter: Emmanuel Venisse > Fix For: 1.x > > Attachments: provider-cvs-with-edit.patch > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-317) Add edit and unedit commands
[ http://jira.codehaus.org/browse/SCM-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123238 ] Christophe Lallement commented on SCM-317: -- Hello Any news for integration of this path into an official release ? It work like a charm in my copany since many months. Regards. > Add edit and unedit commands > > > Key: SCM-317 > URL: http://jira.codehaus.org/browse/SCM-317 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-provider-cvs >Reporter: Emmanuel Venisse > Fix For: 1.x > > Attachments: provider-cvs-with-edit.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] Issue Comment Edited: (SCM-317) Add edit and unedit commands
[ http://jira.codehaus.org/browse/SCM-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113325 ] christophe edited comment on SCM-317 at 2/11/08 4:44 AM: --- Hello I can see that the issue depend on MRELEASE-189 . It's not the truth, it's opposite. I have made a patch to add cvs edit feature The patch is based on the 1.0 released (svn tag). The fix impact 3 projects: * maven-scm-provider-cvs-commons * maven-scm-provider-cvsexe * maven-scm-provider-cvsjava I have tested the both mode (native and command line) with success. In fact the fix is in 2 parts: 1/ add the features into maven scm cvs plugins 2/ make a little patch because javacvs (netbeans) provide a default cvs command factory which does not include edit !!! (even the Edit command is present in the javacvs library ! ). Let me know if you plan to include this in a next release. Regards Christophe PS: it's the first time i create a svn patch, if you want i can attach the complete source. was (Author: christophe): Hello I can see that the issue depend on MRELEASE-189 . It's not the truth, it's opposite. I have made a path to add cvs edit feature The patch is based on the 1.0 released (svn tag). The fix impact 3 projects: * maven-scm-provider-cvs-commons * maven-scm-provider-cvsexe * maven-scm-provider-cvsjava I have tested the both mode (native and command line) with success. In fact the fix is in 2 parts: 1/ add the features into maven scm cvs plugins 2/ make a little patch because javacvs (netbeans) provide a default cvs command factory which does not include edit !!! (even the Edit command is present in the javacvs library ! ). Let me know if you plan to include this in a next release. Regards Christophe PS: it's the first time i create a svn patch, if you want i can attach the complete source. > Add edit and unedit commands > > > Key: SCM-317 > URL: http://jira.codehaus.org/browse/SCM-317 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-provider-cvs >Reporter: Emmanuel Venisse > Fix For: 1.x > > Attachments: provider-cvs-with-edit.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] Issue Comment Edited: (SCM-317) Add edit and unedit commands
[ http://jira.codehaus.org/browse/SCM-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113325 ] Christophe Lallement edited comment on SCM-317 at 11/13/07 5:48 AM: Hello I can see that the issue depend on MRELEASE-189 . It's not the truth, it's opposite. I have made a path to add cvs edit feature The patch is based on the 1.0 released (svn tag). The fix impact 3 projects: * maven-scm-provider-cvs-commons * maven-scm-provider-cvsexe * maven-scm-provider-cvsjava I have tested the both mode (native and command line) with success. In fact the fix is in 2 parts: 1/ add the features into maven scm cvs plugins 2/ make a little patch because javacvs (netbeans) provide a default cvs command factory which does not include edit !!! (even the Edit command is present in the javacvs library ! ). Let me know if you plan to include this in a next release. Regards Christophe PS: it's the first time i create a svn patch, if you want i can attach the complete source. was: Hello I can see that the issue depend on MRELEASE-189 . It's not the truth, it's opposite. I have made a path to add cvs edit feature The patch is based on the 1.0 released (svn tag). The fix impact 3 projects: * maven-scm-provider-cvs-commons * maven-scm-provider-cvsexe * maven-scm-provider-cvsjava I have tested the both mode (native and command line) with success. In fact the fix is in 2 parts: 1/ add the features into maven scm cvs plugins 2/ make a little patch because javacvs (netbeans) provide a default cvs command factory which does not include edit !!! (even the Edit command is present in the library. let me know if you planne ti include this in a next release. Regards Christophe PS: it's the first time i create a svn patch, if you want i can attach the complete source. > Add edit and unedit commands > > > Key: SCM-317 > URL: http://jira.codehaus.org/browse/SCM-317 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-provider-cvs >Reporter: Emmanuel Venisse > Fix For: 1.x > > Attachments: provider-cvs-with-edit.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] Issue Comment Edited: (SCM-317) Add edit and unedit commands
[ http://jira.codehaus.org/browse/SCM-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113325 ] Christophe Lallement edited comment on SCM-317 at 11/13/07 5:48 AM: Hello I can see that the issue depend on MRELEASE-189 . It's not the truth, it's opposite. I have made a path to add cvs edit feature The patch is based on the 1.0 released (svn tag). The fix impact 3 projects: * maven-scm-provider-cvs-commons * maven-scm-provider-cvsexe * maven-scm-provider-cvsjava I have tested the both mode (native and command line) with success. In fact the fix is in 2 parts: 1/ add the features into maven scm cvs plugins 2/ make a little patch because javacvs (netbeans) provide a default cvs command factory which does not include edit !!! (even the Edit command is present in the library. let me know if you planne ti include this in a next release. Regards Christophe PS: it's the first time i create a svn patch, if you want i can attach the complete source. was: Hello I can see thst the issue depend on MRELEASE-189 . It's not the truth, it's opposite. I have made a path to add cvs edit feature The patch is based on the 1.0 released (svn tag). In fix impact the 3 project: * maven-scm-provider-cvs-commons * maven-scm-provider-cvsexe * maven-scm-provider-cvsjava I have tested the both mode (native and command line) with success. In fact the fix is in 2 parts: 1/ add the features into maven scm cvs plugins 2/ make a little patch because javacvs (netbeans) provide a default cvs command factory which does not include edit !!! (even the Edit command is present in the library. let me know if you planne ti include this in a next release. Regards Christophe PS: it's the first time i create a svn patch, if you want i can attach the complete source. > Add edit and unedit commands > > > Key: SCM-317 > URL: http://jira.codehaus.org/browse/SCM-317 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-provider-cvs >Reporter: Emmanuel Venisse > Fix For: 1.x > > Attachments: provider-cvs-with-edit.patch > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-317) Add edit and unedit commands
[ http://jira.codehaus.org/browse/SCM-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113325 ] Christophe Lallement commented on SCM-317: -- Hello I can see thst the issue depend on MRELEASE-189 . It's not the truth, it's opposite. I have made a path to add cvs edit feature The patch is based on the 1.0 released (svn tag). In fix impact the 3 project: * maven-scm-provider-cvs-commons * maven-scm-provider-cvsexe * maven-scm-provider-cvsjava I have tested the both mode (native and command line) with success. In fact the fix is in 2 parts: 1/ add the features into maven scm cvs plugins 2/ make a little patch because javacvs (netbeans) provide a default cvs command factory which does not include edit !!! (even the Edit command is present in the library. let me know if you planne ti include this in a next release. Regards Christophe PS: it's the first time i create a svn patch, if you want i can attach the complete source. > Add edit and unedit commands > > > Key: SCM-317 > URL: http://jira.codehaus.org/browse/SCM-317 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-provider-cvs >Reporter: Emmanuel Venisse > Fix For: 1.x > > Attachments: provider-cvs-with-edit.patch > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-317) Add edit and unedit commands
[ http://jira.codehaus.org/browse/SCM-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lallement updated SCM-317: - Attachment: provider-cvs-with-edit.patch diff with 1.0 tag > Add edit and unedit commands > > > Key: SCM-317 > URL: http://jira.codehaus.org/browse/SCM-317 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-provider-cvs >Reporter: Emmanuel Venisse > Fix For: 1.x > > Attachments: provider-cvs-with-edit.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] Issue Comment Edited: (NMAVEN-19) Dependency resolution and Maven integration (site, deploy)
[
http://jira.codehaus.org/browse/NMAVEN-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91763
]
Christophe Lallement edited comment on NMAVEN-19 at 5/2/07 9:14 AM:
Hi Shane
I work with Alexandre but and i'm not agree with his last comment.
Actually nmaven does't work as we wish because it seems the naming convention
to build the delivery name (jar, war in java / assembly, dll in .net) is not
the same as the maven jar packaging.
To explain our pb, we can deploy (with the attached patch) but after that all
other maven plugins which are not "language dependant" and are based on the
maven naming convention (package, dependancies resolving, ...)
For example, after the deploy of an assembly with the right name in a remote
repository, we can not use this name into another projet dependancies and have
an automatic donwload to get the right version.
For me it's important that nmaven use the maven convention (in fact i don't
understand why your plugin has to manipulate direclty the name of the
delivery).
1/ The name of a delivery is build like this
=> if the finalname is not fill into the pom, this name is build with the
naming convention "${artifactId}-${version}.${packaging}" or if classifier is
given "${artifactId}-${version}-${classifier}.${packaging}"
2/ Into dependancy, we can fill the name tag which bypass the naming convention
to build the full name of dependancy.
3/ The path resolution must include the local maven repository lookup before
the GAC lookup.
4/ If we have a pb to deploy delivery (assembly) with a name non supported by
the gac, "foo-2.3.1-AAA", maybe we can adopt a second naming convention, just
for the GAC deployement (maybe is should be a specific plugin/goal: mvn
gac:deploy.
Don't remember that the way to manage delivery version is not a "java feature"
but a "maven" convention.
Thx
Christophe
was:
Hi Shane
I work with Alexandre but and i'm not agree with his last comment.
Actually nmaven does't work as we wish because it seems the naming convention
to build the delivery name (jar, war in java / assembly, dll in .net) is not
the same as the maven jar packaging.
To explain our pb, we can deploy (with the attached patch) but after that all
other maven plugins which are not "language dependant" and are based on the
maven naming convention (package, dependancies resolving, ...)
For example, after the deploy of an assembly with the right name in a remote
repository, we can not use this name into another projet dependancies and have
an automatic donwload to get the right version.
For me it's important that nmaven use the maven convention (in fact i don't
understand why your plugin has to manipulate direclty the name of the
delivery).
1/ The name of a delivery is build like this
* if the finalname is not fill into the pom, this name is build with the
naming convention "${artifactId}-${version}.${packaging}" or if classifier is
given "${artifactId}-${version}-${classifier}.${packaging}"
2/ Into dependancy, we can fill the name tag which bypass the naming convention
to build the full name of dependancy.
3/ The path resolution must include the local maven repository lookup before
the GAC lookup.
4/ If we have a pb to deploy delivery (assembly) with a name non supported by
the gac, "foo-2.3.1-AAA", maybe we can adopt a second naming convention, just
for the GAC deployement (maybe is should be a specific plugin/goal: mvn
gac:deploy.
Don't remember that the way to manage delivery version is not a "java feature"
but a "maven" convention.
Thx
Christophe
> Dependency resolution and Maven integration (site, deploy)
> --
>
> Key: NMAVEN-19
> URL: http://jira.codehaus.org/browse/NMAVEN-19
> Project: NMaven
> Issue Type: Wish
>Reporter: Alexandre Garcia
> Attachments: components.patch
>
>
> First of all Shane, we really appreciate your effort.
> We tried to complement your packaging lifecycles in order to test site and
> deploy
> The Maven plugins site and deploy use the standard Maven artefact layout:
> ArtefactId-Version.dll
> We were able to use mvn site after renaming accordingly installed artefacts
> in the local repo ($reports is not expanded though).
> We rebuilt NMaven after altering
> NMaven\plugins\maven-compile-plugin\src\main\resources\META-INF\plexus\components.xml
> to include the deploy phase in the packaging lifecycles.
> The deploy phase is successful but is once again maven style.
> Unfortunately, the deployed artefacts cannot be downloaded because NMaven
> dependency resolution doesnot include the version suffix and hence doesnot
> find the artefact on the remote repo.
> More generally, i wish NMaven could adopt default Maven style artefact layout
> or a mixed mode for GAC dependencies.
> We
[jira] Issue Comment Edited: (NMAVEN-19) Dependency resolution and Maven integration (site, deploy)
[
http://jira.codehaus.org/browse/NMAVEN-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91763
]
Christophe Lallement edited comment on NMAVEN-19 at 5/2/07 9:14 AM:
Hi Shane
I work with Alexandre but and i'm not agree with his last comment.
Actually nmaven does't work as we wish because it seems the naming convention
to build the delivery name (jar, war in java / assembly, dll in .net) is not
the same as the maven jar packaging.
To explain our pb, we can deploy (with the attached patch) but after that all
other maven plugins which are not "language dependant" and are based on the
maven naming convention (package, dependancies resolving, ...)
For example, after the deploy of an assembly with the right name in a remote
repository, we can not use this name into another projet dependancies and have
an automatic donwload to get the right version.
For me it's important that nmaven use the maven convention (in fact i don't
understand why your plugin has to manipulate direclty the name of the
delivery).
1/ The name of a delivery is build like this
* if the finalname is not fill into the pom, this name is build with the
naming convention "${artifactId}-${version}.${packaging}" or if classifier is
given "${artifactId}-${version}-${classifier}.${packaging}"
2/ Into dependancy, we can fill the name tag which bypass the naming convention
to build the full name of dependancy.
3/ The path resolution must include the local maven repository lookup before
the GAC lookup.
4/ If we have a pb to deploy delivery (assembly) with a name non supported by
the gac, "foo-2.3.1-AAA", maybe we can adopt a second naming convention, just
for the GAC deployement (maybe is should be a specific plugin/goal: mvn
gac:deploy.
Don't remember that the way to manage delivery version is not a "java feature"
but a "maven" convention.
Thx
Christophe
was:
Hi Shane
I work with Alexandre but and i'm not agree with his last comment.
Actually nmaven does't work as we wish because it seems the naming convention
to build the delivery name (jar, war in java / assembly, dll in .net) is not
the same as the maven jar packaging.
To explain our pb, we can deploy (with the attached patch) but after that all
other maven plugins which are not "language dependant" and are based on the
maven naming convention (package, dependancies resolving, ...)
For example, after the deploy of an assembly with the right name in a remote
repository, we can not use this name into another projet dependancies and have
an automatic donwload to get the right version.
For me it's important that nmaven use the maven convention (in fact i don't
understand why your plugin has to manipulate direclty the name of the
delivery).
1/ The name of a delivery is build like this
* if the finalname is not fill into the pom, this name is build with the
naming convention "${artifactId}-${version}.${packaging}" or if classifier is
given "${artifactId}-${version}-${classifier}.${packaging}"
2/ Into dependancy, we can fill the name tag which bypass the naming convention
to build the full name of dependancy.
3/ The path resolution must include the local maven repository lookup before
the GAC lookup.
4/ If we have a pb to deploy delivery (assembly) with a name non supported by
the gac, "foo-2.3.1-AAA", maybe we can adopt a second naming convention, just
for the GAC deployement (maybe is should be a specific plugin/goal: mvn
gac:deploy.
Don't remember that the way to manage delivery version is not a "java feature"
but a "maven" convention.
Thx
Christophe
> Dependency resolution and Maven integration (site, deploy)
> --
>
> Key: NMAVEN-19
> URL: http://jira.codehaus.org/browse/NMAVEN-19
> Project: NMaven
> Issue Type: Wish
>Reporter: Alexandre Garcia
> Attachments: components.patch
>
>
> First of all Shane, we really appreciate your effort.
> We tried to complement your packaging lifecycles in order to test site and
> deploy
> The Maven plugins site and deploy use the standard Maven artefact layout:
> ArtefactId-Version.dll
> We were able to use mvn site after renaming accordingly installed artefacts
> in the local repo ($reports is not expanded though).
> We rebuilt NMaven after altering
> NMaven\plugins\maven-compile-plugin\src\main\resources\META-INF\plexus\components.xml
> to include the deploy phase in the packaging lifecycles.
> The deploy phase is successful but is once again maven style.
> Unfortunately, the deployed artefacts cannot be downloaded because NMaven
> dependency resolution doesnot include the version suffix and hence doesnot
> find the artefact on the remote repo.
> More generally, i wish NMaven could adopt default Maven style artefact layout
> or a mixed mode for GAC dependencies.
> We
[jira] Issue Comment Edited: (NMAVEN-19) Dependency resolution and Maven integration (site, deploy)
[
http://jira.codehaus.org/browse/NMAVEN-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91763
]
Christophe Lallement edited comment on NMAVEN-19 at 5/2/07 9:15 AM:
Hi Shane
I work with Alexandre but and i'm not agree with his last comment.
Actually nmaven does't work as we wish because it seems the naming convention
to build the delivery name (jar, war in java / assembly, dll in .net) is not
the same as the maven jar packaging.
To explain our pb, we can deploy (with the attached patch) but after that all
other maven plugins which are not "language dependant" and are based on the
maven naming convention (package, dependancies resolving, ...)
For example, after the deploy of an assembly with the right name in a remote
repository, we can not use this name into another projet dependancies and have
an automatic donwload to get the right version.
For me it's important that nmaven use the maven convention (in fact i don't
understand why your plugin has to manipulate direclty the name of the
delivery).
* 1/ The name of a delivery is build like this
=> if the finalname is not fill into the pom, this name is build with the
naming convention "${artifactId}-${version}.${packaging}" or if classifier is
given "${artifactId}-${version}-${classifier}.${packaging}"
* 2/ Into dependancy, we can fill the name tag which bypass the naming
convention to build the full name of dependancy.
* 3/ The path resolution must include the local maven repository lookup before
the GAC lookup.
* 4/ If we have a pb to deploy delivery (assembly) with a name non supported by
the gac, "foo-2.3.1-AAA", maybe we can adopt a second naming convention, just
for the GAC deployement (maybe is should be a specific plugin/goal: mvn
gac:deploy.
Don't remember that the way to manage delivery version is not a "java feature"
but a "maven" convention.
Thx
Christophe
was:
Hi Shane
I work with Alexandre but and i'm not agree with his last comment.
Actually nmaven does't work as we wish because it seems the naming convention
to build the delivery name (jar, war in java / assembly, dll in .net) is not
the same as the maven jar packaging.
To explain our pb, we can deploy (with the attached patch) but after that all
other maven plugins which are not "language dependant" and are based on the
maven naming convention (package, dependancies resolving, ...)
For example, after the deploy of an assembly with the right name in a remote
repository, we can not use this name into another projet dependancies and have
an automatic donwload to get the right version.
For me it's important that nmaven use the maven convention (in fact i don't
understand why your plugin has to manipulate direclty the name of the
delivery).
1/ The name of a delivery is build like this
=> if the finalname is not fill into the pom, this name is build with the
naming convention "${artifactId}-${version}.${packaging}" or if classifier is
given "${artifactId}-${version}-${classifier}.${packaging}"
2/ Into dependancy, we can fill the name tag which bypass the naming convention
to build the full name of dependancy.
3/ The path resolution must include the local maven repository lookup before
the GAC lookup.
4/ If we have a pb to deploy delivery (assembly) with a name non supported by
the gac, "foo-2.3.1-AAA", maybe we can adopt a second naming convention, just
for the GAC deployement (maybe is should be a specific plugin/goal: mvn
gac:deploy.
Don't remember that the way to manage delivery version is not a "java feature"
but a "maven" convention.
Thx
Christophe
> Dependency resolution and Maven integration (site, deploy)
> --
>
> Key: NMAVEN-19
> URL: http://jira.codehaus.org/browse/NMAVEN-19
> Project: NMaven
> Issue Type: Wish
>Reporter: Alexandre Garcia
> Attachments: components.patch
>
>
> First of all Shane, we really appreciate your effort.
> We tried to complement your packaging lifecycles in order to test site and
> deploy
> The Maven plugins site and deploy use the standard Maven artefact layout:
> ArtefactId-Version.dll
> We were able to use mvn site after renaming accordingly installed artefacts
> in the local repo ($reports is not expanded though).
> We rebuilt NMaven after altering
> NMaven\plugins\maven-compile-plugin\src\main\resources\META-INF\plexus\components.xml
> to include the deploy phase in the packaging lifecycles.
> The deploy phase is successful but is once again maven style.
> Unfortunately, the deployed artefacts cannot be downloaded because NMaven
> dependency resolution doesnot include the version suffix and hence doesnot
> find the artefact on the remote repo.
> More generally, i wish NMaven could adopt default Maven style artefact layout
> or a mixed mode for GAC depende
[jira] Created: (MRELEASE-189) Release with CVS SCM failed when Checkout is read-only
Release with CVS SCM failed when Checkout is read-only -- Key: MRELEASE-189 URL: http://jira.codehaus.org/browse/MRELEASE-189 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-3 Environment: CVS 2.5.03 jdk * Reporter: Christophe Lallement Priority: Critical When we use the goal release:perform, the plugins try to update the pom.xml Bug we use CVS with checkout in read-only mode (by setting the variable CVSREAD to 1) It seems that the plugins do not try to do a "cvs edit" before updating the file. So the update file because the file is read only. Christophe -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSUREFIRE-176) Failed to load test: java.security.AccessControlException:
Failed to load test: java.security.AccessControlException: -- Key: MSUREFIRE-176 URL: http://jira.codehaus.org/browse/MSUREFIRE-176 Project: Maven 2.x Surefire Plugin Issue Type: Bug Components: classloading Affects Versions: 2.2 Environment: windows XP SP1 and linux AS 4 maven 2.0.4 jdk 1.5.0_06/09 Reporter: Christophe Lallement We try to load a testsuite with a test case wich start a RMI server and we have this error: > mvn test Running deai.tt.rhino.cache.mgr.CommonCacheManagerTest INFO: Created RMIRegistry on port: 10098 org.apache.maven.surefire.booter.SurefireExecutionException: deai.tt.rhino.cache.mgr.CommonCacheManagerTest; nested exception is java.security.AccessControlException: access denied (java.lang.RuntimePermission setIO); nested exception is org.apache.maven.surefire.testset.TestSetFailedException: deai.tt.rhino.cache.mgr.CommonCacheManagerTest; nested exception is java.security.AccessControlException: access denied (java.lang.RuntimePermission setIO) org.apache.maven.surefire.testset.TestSetFailedException: deai.tt.rhino.cache.mgr.CommonCacheManagerTest; nested exception is java.security.AccessControlException: access denied (java.lang.RuntimePermission setIO) java.security.AccessControlException: access denied (java.lang.RuntimePermission setIO) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) at java.security.AccessController.checkPermission(AccessController.java:427) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.System.checkIO(System.java:208) at java.lang.System.setOut(System.java:148) at org.apache.maven.surefire.report.ReporterManager.resetStreams(ReporterManager.java:313) at org.apache.maven.surefire.report.ReporterManager.testFailed(ReporterManager.java:291) at org.apache.maven.surefire.report.ReporterManager.testError(ReporterManager.java:276) at org.apache.maven.surefire.junit.TestListenerInvocationHandler.handleAddError(TestListenerInvocationHandler.java:163) at org.apache.maven.surefire.junit.TestListenerInvocationHandler.invoke(TestListenerInvocationHandler.java:134) at $Proxy0.addError(Unknown Source) at junit.framework.TestResult.addError(TestResult.java:36) at junit.framework.TestResult.runProtected(TestResult.java:133) 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.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.junit.JUnitTestSet.execute(JUnitTestSet.java:210) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:160) at org.apache.maven.surefire.Surefire.run(Surefire.java:81) 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:182) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:743) [INFO] I suppose it's a pb of java policy ? Any idea Thx -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSUREFIRE-172) Bug into xml report generation
Bug into xml report generation -- Key: MSUREFIRE-172 URL: http://jira.codehaus.org/browse/MSUREFIRE-172 Project: Maven 2.x Surefire Plugin Issue Type: Bug Components: xml generation Environment: release 2.0 of maven-surfire-plugin mvn 2.0.4 Reporter: Christophe Lallement Attachments: TEST-deai.ft.archi.common.debug.ThreadWarningSystemTest.xml, ThreadWarningSystem.java, ThreadWarningSystemTest.java since 2-3 weeks i have wrong information into my junit test tun (mvn test for example) In fact, the *.txt are right, but the corresponding xml file have wrong entry. i means additionnal testcase are present ninto the testcase section. you can find exmple in attachement (ThreadWarningSystemTest for example). You can see that the error number are good (because read into the attribute of the first xml tag) but in several TestSuite, we have testcase form other testsuite. I don't know if this errors comes from maven dependancies update. What i am sure is: 1/ a little bit of source modification into my project since this error appears. 2/ no new maven dependancies into my project 3/ i use only ibilio/maven2 as repository. This errors can'be shown on other projet and other not ... I have a workaround to solve this issue but with low performance: I use the option "fork per test" and the reports is right. Maybe a way to be investigate can be the temporaly file created by the command line: Forking command line: java -classpath > C:\HOMEWARE\maven-2_local\org\apache\maven\surefire\surefire-api\2.0\surefire-api-2.0.jar;C:\HOMEWARE\maven-2_local\o > rg\codehaus\plexus\plexus-utils\1.1\plexus-utils-1.1.jar;C:\HOMEWARE\maven-2_local\org\apache\maven\surefire\surefire-booter\2.0\surefire-booter-2.0.jar > or > g.apache.maven.surefire.booter.SurefireBooter C:\temp\surefire40840tmp > C:\temp\surefire40841tmp Any Idea ? Thx Christophe -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNGECLIPSE-29) Plug-In does not run behind Proxy/Firewall (where M2 itself does)
[ http://jira.codehaus.org/browse/MNGECLIPSE-29?page=comments#action_62629 ] Christophe Lallement commented on MNGECLIPSE-29: Thx Eugene As Peter, i will be happy to test any new build with a new version of maven-embedder. About the workaround, let me know if i'm wrong, but it's not possible to declare mirrors and proxy section in pom.xml (it's only available into settings.xml) (http://maven.apache.org/ref/2.0.3-SNAPSHOT/maven-model/maven.html) ? Christophe > Plug-In does not run behind Proxy/Firewall (where M2 itself does) > - > > Key: MNGECLIPSE-29 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-29 > Project: Maven 2.x Extension for Eclipse > Type: Bug > Versions: 0.0.3 > Environment: Windows (probably ANY behind a Proxy or Firewall) > Reporter: Werner Keil > Assignee: Dmitri Maximovich > Priority: Minor > Fix For: 1.0.0 > Attachments: pom.xml > > Time Spent: 30 minutes >Remaining: 0 minutes > > While Maven 2 on its own runs the same goal (test) from the command line > without errors the Plug-in for Eclipse fails trying to update itself or some > other dependency: > [DEBUG] Found 0 components to load on start > [DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and > Settings\username\.m2\plugin-registry.xml' > [DEBUG] Building Maven global-level settings from: 'C:\Documents and > Settings\username\workspace\32\mtest\conf\settings.xml' > [DEBUG] Building Maven user-level settings from: 'C:\Documents and > Settings\username\.m2\settings.xml' > [DEBUG] mtest:mtest:jar:1.0.1-SNAPSHOT (selected for null) > [DEBUG] junit:junit:jar:3.8.1 (selected for compile) > [INFO] > > [INFO] Building mtest > [INFO]task-segment: [test] > [INFO] > > [DEBUG] maven-resources-plugin: resolved to version 2.1 from repository > central > [DEBUG] Found 0 components to load on start > [DEBUG] maven-compiler-plugin: resolved to version 2.0 from repository central > [DEBUG] Found 0 components to load on start > [DEBUG] maven-surefire-plugin: resolved to version 2.0 from repository central > [DEBUG] Found 0 components to load on start > [DEBUG] org.apache.maven.plugins:maven-resources-plugin:maven-plugin:2.1 > (selected for runtime) > [DEBUG] commons-io:commons-io:jar:1.0 (selected for runtime) > [DEBUG] junit:junit:jar:3.8.1 (selected for runtime) > [DEBUG] Skipping disabled repository snapshots > [DEBUG] Trying repository central > org.apache.maven.plugin.MojoExecutionException: Error configuring plugin for > execution of 'resources:resources'. > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:399) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:554) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:508) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:494) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:307)>> > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:439) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:383) > at org.maven.ide.eclipse.Maven2Executor.main(Maven2Executor.java:71) > Caused by: org.apache.maven.plugin.PluginConfigurationException: Error > configuring: org.apache.maven.plugins:maven-resources-plugin. Reason: Cannot > resolve plugin dependencies > at > org.apache.maven.plugin.DefaultPluginManager.ensurePluginContainerIsComplete(DefaultPluginManager.java:650) > at > org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:541) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:394) > ... 8 more > Caused by: org.apache.maven.artifact.resolver.ArtifactResolutionException: > Error transferring file > org.apache.maven:maven-model:2.0:jar > from the specified remote repositories: > snapshots (http://snapshots.maven.codehaus.org/maven2), > central (http://repo1.maven.org/maven2) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:150) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:64) > at > org.apache.maven.plugin.DefaultPluginManager.resolveCoreArtifacts(DefaultPluginManager.java:682) >
[jira] Created: (MRELEASE-85) cvs protocol not supported ?
cvs protocol not supported ? Key: MRELEASE-85 URL: http://jira.codehaus.org/browse/MRELEASE-85 Project: Maven 2.x Release Plugin Type: New Feature Versions: 2.0-beta-3 Reporter: Christophe Lallement I'm surprised that maven release plugin does'nt support CVS protocol within scm url ? When looking at source => helpers/ScmHelper.java CVS seems to be unsupported (method getScmRepository) So CVS is intensive used in my company and it should be fine to support this scm (so, cvs is supported into maven-scm-plugin) Thx Christophe -- 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
