Creating a notifier for Confluence
Hi, Our company uses Atlassian Confluence as a wiki. I want to try to create a notifier so that after a build, the notification is sent as a message to post on a Confluence page. Since you can post to Confluence via SOAP web services calls, I think may be straightforward to create a notifier. Where do I look to start and what are some of the requirements? Do I simply extend AbstractContinuumNotifier or what? Any direction would help. Thanks. _Mang Lau
RE: The best approach to extend ScmProvider
What is a task in this context? Torbjorn -Original Message- From: Zsolt [mailto:[EMAIL PROTECTED] Sent: 3. april 2006 19:31 To: scm-dev@maven.apache.org Subject: RE: The best approach to extend ScmProvider Thank you Carlos, I will also need a merthod: listTasks (or something like that) that returns the tasks of the version control system. Can (should) I use commit to the repository? Zsolt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Monday, April 03, 2006 6:26 PM To: scm-dev@maven.apache.org Subject: Re: The best approach to extend ScmProvider I'd create a new list method. Providers that don't support a list operation can explain in the javadocs that they don't support it or that the operation is not efficient because it requires checkout. On 4/1/06, Zsolt [EMAIL PROTECTED] wrote: From the source code: public interface ScmProvider I'm very under time pressure: We have our own (limited scm support) and have to decide until Monday whether we join to scm-maven (of course we would make all modifications available) or extend our scm implementation. For us it is a must that we can get the list of files of a directory directly from the repository and we must also support huge projects (thus an entire checkout is not an option). svn list -v does exactly what we need. For CVS we could execute: cvs checkout -l DIRECTORY into a temporary directory read the contents of CVS/* files (to get revision, modification date etc.) and remove the temporary directors. I don't know ClearCase but I guess it has also a list command. If we join to scm-maven we will very probably implement CM-Synergy because one of our customers uses only Cm-Synergy it. Please give me hints as soon as possible. Zsolt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Saturday, April 01, 2006 10:24 AM To: scm-dev@maven.apache.org Subject: Re: The best approach to extend ScmProvider Not sure if ScmProvider is an interface but if it is we better add the method to it before 1.0 and implement in the providers throwing a not implemented exception, because if not we'll need to create another interface to avoid breaking backwards compatibility in 1.x On 4/1/06, Zsolt [EMAIL PROTECTED] wrote: Hi, I need to extend ScmProvider to support a list method (like svn list). What is the best approach to do that? I need this functionally for CVS, svn and clearcase. Later we might even add CM Synergy support for maven scm. What is the best approach? Should I use the maven repository or create my own one? I work with eclipse. How should I setup the project compile everything? Zsolt -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Welcome to Torbjørn
Everyone, please welcome Torbjørn as our newest Maven-SCM committer. Torbjørn: you may already be familiar with them, but here are some resources to get you started: * How to log in, commit, etc: http://www.apache.org/dev/new-committers-guide.html * Information on Apache and how it works, and how we all play nice together: http://www.apache.org/foundation/how-it-works.html * How voting works: http://www.apache.org/foundation/voting.html * For technical resources: http://www.apache.org/dev/committers.html If you've got any questions, feel free to ask, and I look forward to working with you! Emmanuel
ClearCase SCM provider
I have a problem executing clearcase scm provider. When I run the goal scm:update the snapshot view is being updated but maven fails the build when there are any updates pulled out form the clearcase. Regardless of build result (success or error) the view is fresh with all the view files and updates. Turning the stack trace showed (just part for clarity) ... 18 more Caused by: java.lang.NullPointerException at org.apache.maven.scm.provider.clearcase.command.changelog.ClearCaseChangeLogCommand.executeChangeLogCommand(ClearCaseChangeLogCommand.java:51) at org.apache.maven.scm.command.changelog.AbstractChangeLogCommand.executeCommand(AbstractChangeLogCommand.java:63) at org.apache.maven.scm.command.update.AbstractUpdateCommand.executeCommand(AbstractUpdateCommand.java:60) at org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:55) ... 21 more My system is: Linux RedHat AS 3.5 ClearCase version 2003.06.00 Maven 2.0.2 If anyone can tell me how to get sources and debug the problem it would appreciate. I ask since I'm new to maven and have no idea how to setup the development environment for maven scm plugins. Thanks in advance Igor
Re: ClearCase SCM provider
I think i'll release it before two weeks. Emmanuel Igor Czechowski a écrit : Emmanuel, Thanks. Do you know when it will be released ? Igor On 4/4/06, Emmanuel Venisse [EMAIL PROTECTED] wrote: This problem is already fixed. If you want to try the latest snapshot of maven-scm, add this in your pom : repositories repository releases enabledfalse/enabled /releases idapache.snapshots/id nameApache Development Repository/name urlhttp://cvs.apache.org/maven-snapshot-repository/url /repository repositories The snapshot version of Maven-scm is 1.0-beta-3-SNAPSHOT that will be in few days 1.0 Emmanuel Igor Czechowski a écrit : I have a problem executing clearcase scm provider. When I run the goal scm:update the snapshot view is being updated but maven fails the build when there are any updates pulled out form the clearcase. Regardless of build result (success or error) the view is fresh with all the view files and updates. Turning the stack trace showed (just part for clarity) ... 18 more Caused by: java.lang.NullPointerException at org.apache.maven.scm.provider.clearcase.command.changelog.ClearCaseChangeLogCommand.executeChangeLogCommand(ClearCaseChangeLogCommand.java:51) at org.apache.maven.scm.command.changelog.AbstractChangeLogCommand.executeCommand(AbstractChangeLogCommand.java:63) at org.apache.maven.scm.command.update.AbstractUpdateCommand.executeCommand(AbstractUpdateCommand.java:60) at org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:55) ... 21 more My system is: Linux RedHat AS 3.5 ClearCase version 2003.06.00 Maven 2.0.2 If anyone can tell me how to get sources and debug the problem it would appreciate. I ask since I'm new to maven and have no idea how to setup the development environment for maven scm plugins. Thanks in advance Igor
RE: The best approach to extend ScmProvider
I'm not sure what you exactly mean. CM-Synergy task is created BEFORE you checkout. Zsolt -Original Message- From: Torbjorn Smorgrav [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 04, 2006 4:41 PM To: scm-dev@maven.apache.org Subject: RE: The best approach to extend ScmProvider Is it the same as a change set? A change set you can append to? Torbjorn -Original Message- From: Zsolt [mailto:[EMAIL PROTECTED] Sent: 4. april 2006 16:00 To: scm-dev@maven.apache.org Subject: RE: The best approach to extend ScmProvider In Cm-Synergy (ClearCase has that also) you can checkin with a task created and maintained by CM-Synergy, and I would like to browse the tasks created in CM-Synergy. Zsolt -Original Message- From: Torbjorn Smorgrav [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 04, 2006 9:31 AM To: scm-dev@maven.apache.org Subject: RE: The best approach to extend ScmProvider What is a task in this context? Torbjorn -Original Message- From: Zsolt [mailto:[EMAIL PROTECTED] Sent: 3. april 2006 19:31 To: scm-dev@maven.apache.org Subject: RE: The best approach to extend ScmProvider Thank you Carlos, I will also need a merthod: listTasks (or something like that) that returns the tasks of the version control system. Can (should) I use commit to the repository? Zsolt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Monday, April 03, 2006 6:26 PM To: scm-dev@maven.apache.org Subject: Re: The best approach to extend ScmProvider I'd create a new list method. Providers that don't support a list operation can explain in the javadocs that they don't support it or that the operation is not efficient because it requires checkout. On 4/1/06, Zsolt [EMAIL PROTECTED] wrote: From the source code: public interface ScmProvider I'm very under time pressure: We have our own (limited scm support) and have to decide until Monday whether we join to scm-maven (of course we would make all modifications available) or extend our scm implementation. For us it is a must that we can get the list of files of a directory directly from the repository and we must also support huge projects (thus an entire checkout is not an option). svn list -v does exactly what we need. For CVS we could execute: cvs checkout -l DIRECTORY into a temporary directory read the contents of CVS/* files (to get revision, modification date etc.) and remove the temporary directors. I don't know ClearCase but I guess it has also a list command. If we join to scm-maven we will very probably implement CM-Synergy because one of our customers uses only Cm-Synergy it. Please give me hints as soon as possible. Zsolt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Saturday, April 01, 2006 10:24 AM To: scm-dev@maven.apache.org Subject: Re: The best approach to extend ScmProvider Not sure if ScmProvider is an interface but if it is we better add the method to it before 1.0 and implement in the providers throwing a not implemented exception, because if not we'll need to create another interface to avoid breaking backwards compatibility in 1.x On 4/1/06, Zsolt [EMAIL PROTECTED] wrote: Hi, I need to extend ScmProvider to support a list method (like svn list). What is the best approach to do that? I need this functionally for CVS, svn and clearcase. Later we might even add CM Synergy support for maven scm. What is the best approach? Should I use the maven repository or create my own one? I work with eclipse. How should I setup the project compile everything? Zsolt -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
RE: configuration mappings for complex objects
Hi,
Unfortunately, Ive received no
answer so far (see my original mail below).
In Creating artifact form
Dependencies and its replies, Hermod and Brett talked about a mojo.xxx.xml
file (never read about it in Maven doc) and some
requiredDependencyResolution tag.
Should this way be followed ?
Can anyone point me to a link a some Maven
documentation stressing that point ?
Is there somewhere a documentation on developing
Maven 2 plugin more complete than the one on the Maven site ? (articles,)
Thank you for your answer(s),
Christophe
From: Christophe Grosjean
Sent: jeudi 30 mars 2006 17:38
To: dev@maven.apache.org
Subject: configuration mappings
for complex objects
Hi,
A question about the configuration mappings
Does the mapping of Maven project properties to Mojo fields also
work for any complex objects used to configure the plugin?
In other words, in the following code, will the
project field of the ComplexObject parameter be assigned ?
public class SomeMojo extends AbstractMojo {
/**
* @parameter
*/
private ComplexObject
complexObject;
}
public class ComplexObject {
/**
* The maven project.
*
* @parameter
_expression_=${project}
* @required
* @readonly
*/
private MavenProject
project;
}
Thanks for your answer,
Christophe
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release Maven Surefire Report plugin 2.0
+1 Emmanuel Brett Porter a écrit : Vote open for 72 hours, based on: maven-surefire-report-plugin 2.0-20060331.032648-2 (r390304) [ ] +1 [ ] +0 [ ] -1 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11222styleName=Htmlversion=12481 * [MSUREFIREREP-2] - test failures causes report not to be generated * [MSUREFIREREP-9] - surefire-report-maven-plugin: don't add report for non java projects * [MSUREFIREREP-11] - [surefire-report] not contains package name and testcase details * [MSUREFIREREP-13] - NPE with svn version of surefire-report-maven-plugin * [MSUREFIREREP-15] - Add integration logic that allows report to be created for junit OR testng * [MSUREFIREREP-17] - Use javascript to show/hide failure details Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release Maven WAR plugin 2.0
+1 Emmanuel Brett Porter a écrit : Vote open for 72 hours, based on: maven-war-plugin 2.0-20060331.041208-2 (r390317) [ ] +1 [ ] +0 [ ] -1 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11150styleName=Htmlversion=12160 * [MWAR-1] - war:exploded removes content of .class files * [MWAR-3] - war:war launched from parent doesn't find module web.xml * [MWAR-5] - warSourceExcludes not working properly * [MWAR-6] - dependentWarExcludes and dependentWarIncludes do not support comma-separated patterns * [MWAR-7] - Referenced projects' artifacts naming scheme behaves differently when ran from reactor * [MWAR-20] - webXML/ tag doesn't work during aggregated build. * [MWAR-26] - Do not overwrite target unless source is modified * [MWAR-11] - Add war:exploded and war:inplace goals * [MWAR-12] - Add resource filtering to war plugin * [MWAR-13] - War plugin needs better handling of multiple executions * [MWAR-19] - Make sure that there aren't two jars with the same artifactId and version * [MWAR-21] - Need a way to include limited set of webapp's dependencies * [MWAR-27] - It should be possible to exclude the META-INF/maven directory from produced WARs * [MWAR-8] - Merge contents of dependent wars into war being built * [MWAR-15] - Support separate generation of WAR's manifest.mf * [MWAR-24] - [PATCH] Add ability to specify context.xml file in plugin configuration The remaining issues are feature requests, or dependant on core fixes. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release surefire plugin 2.1.3 and surefire 1.5.3
+1 Emmanuel Carlos Sanchez a écrit : Please vote for these releases that include several bugfixes, mainly to improve the support of test forking. http://jira.codehaus.org/browse/MSUREFIRE?report=com.atlassian.jira.plugin.system.project:roadmap-panel http://jira.codehaus.org/browse/SUREFIRE?report=com.atlassian.jira.plugin.system.project:roadmap-panel -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release Maven PMD plugin 2.0
+1 Emmanuel Brett Porter a écrit : Based on: maven-pmd-plugin 2.0-20060402.035815-1 (r390774) [ ] +1 [ ] +0 [ ] -1 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11140styleName=Htmlversion=12262 * [MPMD-2] - pmd has problems with package-info.java. * [MPMD-16] - Utilise the exclusion mechanism to allow arbitrary exclusions * [MPMD-18] - set linkXRef to true by default, and only link if JXR report is included to make it automatic * [MPMD-23] - Use PMD 3.6 * [MPMD-13] - Provide pmd:check (patch attached) * [MPMD-14] - create pmd:cpd-check goal Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release Maven JXR plugin 2.0
+1 Emmanuel Brett Porter a écrit : NOTE: Please specifically look at MJXR-2 before voting, it's a major change in behaviour. Based on: maven-jxr-plugin 2.0-20060403.005039-2 (r390934) [ ] +1 [ ] +0 [ ] -1 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11194styleName=Htmlversion=12480 * [MJXR-3] - [JXR] botton doesn't include current year for license text * [MJXR-6] - Jxr breaks in projects with generated-sources directories * [MJXR-2] - don't generated summary page and include both reports in menu like m1 * [MJXR-9] - JXR Plugin Documentation and How to use APT doc * [MJXR-1] - add an aggregate option Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release Maven Help plugin 2.0.1
+1 Emmanuel Brett Porter a écrit : Based on: maven-help-plugin 2.0.1-20060403.014226-1 (r390935) [ ] +1 [ ] +0 [ ] -1 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11141styleName=Htmlversion=12534 * [MPH-10] - NPE when -Dplugin value can not find specified plugin * [MPH-11] - effective-settings shouldn't require a project Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Milos Kleint as a committer
+1 Emmanuel Jason van Zyl a écrit : Hi, Just so we have an official vote thread that can be used for reference. Sorry for the confusion. Milos would make a great addition to the team so here goes again! +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Welcome to Torbjørn
Everyone, please welcome Torbjørn as our newest Maven-SCM committer. Torbjørn: you may already be familiar with them, but here are some resources to get you started: * How to log in, commit, etc: http://www.apache.org/dev/new-committers-guide.html * Information on Apache and how it works, and how we all play nice together: http://www.apache.org/foundation/how-it-works.html * How voting works: http://www.apache.org/foundation/voting.html * For technical resources: http://www.apache.org/dev/committers.html If you've got any questions, feel free to ask, and I look forward to working with you! Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Possible regression in 2.0.4
Hi,
I've just tried the cargo build with the latest trunk versions of
2.0.4-SNAPSHOT and surefire plugin, and it seems there's some interpolation
issue (I don't know if the problem is with the surefire plugin or with maven
core).
Here's what I have:
build
pluginManagement
plugins
plugin
artifactIdmaven-surefire-plugin/artifactId
configuration
forkModepertest/forkMode
systemProperties
[...]
property
namecargo.target.dir/name
value${project.build.directory}/value
/property
[...]
It seems the ${project.build.directory} property is no longer getting
resolved as I got a directory named ${project.build.directory} created.
It used to work fine which is why I'm asking If it's a regression. It's also
possible that it's just me doing something stupid...
Thanks
-Vincent
___
Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs
exceptionnels pour appeler la France et l'international.
Téléchargez sur http://fr.messenger.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Possible regression in 2.0.4
hi, I thought I'd give 2.0.4 (from the 2.0.x branch) a test drive as well. While not sure it's related to what you've indicated, the maven-idea-plugin fails too: [EMAIL PROTECTED] a]$ mvn -e idea:idea + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'idea'. [INFO] [INFO] Building Messages [INFO]task-segment: [idea:idea] [INFO] [INFO] Preparing idea:idea [INFO] No goals needed for project - skipping [INFO] [idea:idea] Executed project: null [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Unable to build project dependencies. [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Unable to build project dependencies. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals( DefaultLifecycleExecutor.java:559) 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: Unable to build project dependencies. at org.apache.maven.plugin.idea.IdeaMojo.execute(IdeaMojo.java:188) at org.apache.maven.plugin.DefaultPluginManager.executeMojo( DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals( DefaultLifecycleExecutor.java:534) ... 16 more Caused by: java.lang.NullPointerException at org.apache.maven.plugin.idea.AbstractIdeaMojo.getProjectArtifacts (AbstractIdeaMojo.java:301) at org.apache.maven.plugin.idea.AbstractIdeaMojo.doDependencyResolution( AbstractIdeaMojo.java:257) at org.apache.maven.plugin.idea.IdeaMojo.execute(IdeaMojo.java:184) ... 18 more [INFO] [INFO] Total time: 1 second [INFO] Finished at: Tue Apr 04 13:31:19 IDT 2006 [INFO] Final Memory: 2M/5M [INFO] I used it on a small test POM: ?xml version=1.0 encoding=UTF-8? project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi= http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation= http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdo/groupId artifactIdc/artifactId nameMessages/name version0.1-SNAPSHOT/version dependencies dependency groupIdcommons-io/groupId artifactIdcommons-io/artifactId version1.0/version /dependency /dependencies /project It seems that the executedProject is not injected correctly in the AbstractIdeaMojo and remains null, hence the NPE later on... ** This pertains the maven-idea-plugin from the trunk, not a released version I figured I'd better post it before you release 2.0.4, just in case it really is another regression, so I'd save you the trouble of another patch ;-) On 4/4/06, Vincent Massol [EMAIL PROTECTED] wrote: Hi, I've just tried the cargo build with the latest trunk versions of 2.0.4-SNAPSHOT and surefire plugin, and it seems there's some interpolation issue (I don't know if the problem is with the surefire plugin or with maven core). Here's what I have: build pluginManagement plugins plugin artifactIdmaven-surefire-plugin/artifactId
Problem with compile/install goal
Hi I just started getting the following when I try build my project: Project ID: org.apache.maven.plugins:maven-resources-plugin Reason: Error getting POM for 'org.apache.maven.plugins:maven-resources-plugin' from the repository: Failed to resolve artifact, possibly due to a repository li st that is not appropriately equipped for this artifact's metadata. org.apache.maven.plugins:maven-resources-plugin:pom:2.2-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) Has there been any change to some of the compile/install plugins? Hermod * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This email with attachments is solely for the use of the individual or entity to whom it is addressed. Please also be aware that DnB NOR cannot accept any payment orders or other legally binding correspondence with customers as a part of an email. This email message has been virus checked by the virus programs used in the DnB NOR Group. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sharing code between mvn IDE plugins (eclipse and idea)
Hi Fabrizio, I think collecting all the code used for IDE work is a good idea. But I think we should try not only to collect common code for the Maven 2 plugins but also for the IDE extensions as much of the same code could be shared. For example I know that Milos and Eugene have separately added source code downloading for the Netbeans and Eclipse extensions respectively. I think it's crucial that all the Maven 2 plugins work in a similar way and that the IDE extensions also work in a similar way. I think the best approach here is create discrete plexus components for the functionality to be shared. Plexus components can easily be utilized from Mojos or from the embedder. So I think that's the technical approach in that we should make components not an abstract Mojo. As for the organizational aspects I think we need to collect all the IDE code in one place so that would mean asking the Mevenide folks if they would like to come here, or we move the plugins we have here to Mevenide. That is up for discussion but I think we need to collect code in one place if we are going to be effective with our IDE strategy. Any thoughts? Fabrizio Giustina wrote: Hi, I recently noticed a lot of duplicated effort in order to implement similar things in the eclipse and idea plugins. Downloading of source artifacts and javadocs has been reimplemented in the idea one, and I recently took off some bits of the custom artifact resolution used in the idea plugin and integrated it into the eclipse one. It will probably be possible to share most of this stuff to reduce duplicate code and to improve consistency between plugins (use similar flags for common features and so on... reducing the numbers of why the eclipse plugins does that and the idea one doesn't - or does that differently questions from users). I've just committed some major changes to the eclipse plugin to change the artifact resolution behaviour (in order to avoid the need for installed reactor projects) and in the meanwhile I deeply refactored the plugin in order to extract a base mojo that could be useful for other similar plugins. The base mojo take care of artifact resolution, source and javadocs downloading, plus some basic messages and handling of common flags (download sources, directly link referenced projects...). The result is a list of dependencies in a friendly format for IDE mojos that can direcly be used to create configuration files. Probably also the source directories processing could be handled here (but not done yet). I would like to go on adding a few more fixes to the eclipse plugin and release a new version (probably the artifact resolution change worths a release on its own), but after that I would like to split all the generic stuff (currently in the org.apache.maven.plugins.ide package) in a shared library. Could this be interesting for idea plugins developers? (Brett?, Edwin?) Anybody likes this? fabrizio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org Simplex sigillum veri. (Simplicity is the seal of truth.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r391198 - in /maven/plugins/tags/maven-surefire-plugin=2.1.3: ./ pom.xml
On Tue, 2006-04-04 at 00:28 +, [EMAIL PROTECTED] wrote: Author: carlos Date: Mon Apr 3 17:28:19 2006 New Revision: 391198 URL: http://svn.apache.org/viewcvs?rev=391198view=rev Log: [maven-scm] copy for tag maven-surefire-plugin=2.1.3 Added: maven/plugins/tags/maven-surefire-plugin=2.1.3/ - copied from r390960, maven/plugins/trunk/maven-surefire-plugin/ maven/plugins/tags/maven-surefire-plugin=2.1.3/pom.xml - copied unchanged from r391197, maven/plugins/trunk/maven-surefire-plugin/pom.xml I think you messed up the version name here Carlos. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Broken plugin links
Most of the Codehaus plugin links at the bottom of this page return a 404. http://maven.apache.org/plugins/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
