Re: [DISCUSS] Effect of direct plugin invocation on model
On Sun, Jan 10, 2010 at 2:48 PM, Brett Porter br...@apache.org wrote: What is the original use case that led to the bug? I'm wondering if it is sane and needs the runtime info, or if it actually should have just the POM as fully resolved from the repo. Cheers, Brett The code involved is at line 1797 in EclipsePlugin.javahttp://svn.apache.org/viewvc/maven/plugins/tags/maven-eclipse-plugin-2.7/src/main/java/org/apache/maven/plugin/eclipse/EclipsePlugin.java?view=markup. The issue was opened in response to http://jira.codehaus.org/browse/MECLIPSE-633 . The plugin code is kinda suspect as I'm not quite sure why the EclipseMojo just can't rely on the injected parameter it is looking for rather than parsing its Xpp3Dom directly - guessing as some previous bug work around? Still, I don't think the project model should change this drastically unless there is a good reason and it is well documented. Meanwhile Jason is pushing for a release of the eclipse plugin and until we reach a consensus on what to do then maven-eclipse-plugin will remain not passing integration tests for maven 3. -Peter
Re: Releasing maven-eclipse-plugin
On Thu, Jan 14, 2010 at 10:43 AM, Jason van Zyl ja...@sonatype.com wrote: Hi, There are some issues left in the 2.8 for the maven-eclipse-plugin but if no one is going work on it then I'll just release it. I have been trying to resolve issues using Maven 3 to build the plugin. I provided a patch for MECLIPSE-631, no one has applied it and I don't have karma. It would be nice if someone could apply that one at least before you release. Issue MECLIPSE-633 is the other one, which seems like it will take more time to sort out due to MNG-4523. -Peter
Re: [DISCUSS] Effect of direct plugin invocation on model
On Sat, Jan 9, 2010 at 7:36 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: 2010/1/9 Benjamin Bentmann benjamin.bentm...@udo.edu: Hi, in response to http://jira.codehaus.org/browse/MNG-4523, I would like to double-check that the behavior observed in Maven 2 is by design/intention and needs to be reproduced by Maven 3. It looks odd to me that the effective POM is a function of the plugin being invoked on CLI. I agree that it looks odd. IMHO, the effective pom should be invariant. It is far from invariant. I noticed in the debugger that the project model contained 4 plugins ( clean,site, install, deploy if i recall), none being the one explicitly called in Maven 3. In Maven 2, the only plugin in the model was the one being called. After that I thought I'd better share my findings... Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Junit
On Tue, Jan 5, 2010 at 7:47 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I make the occasional submissions to the junit project, and I wanted to submit a pom.xml that'd convert it into a proper maven project. My real question is what/if anything should be done to the groupId of junit. it should probably be org.junit but has since the beginning of time been just junit. I know at least surefire would need to be updated if the artifact id changed. I thought I'd put something into the pom.xml I submit to them, I'm just not sure what.. I guess you mean adding a relocation element to their 'old' pom? http://maven.apache.org/pom.html#Relocation I don't know who actually publishes junit to the repos, but 4.8 and 4.8.1 have been released. If you vote for the following junit issue we might be able to make them release 4.9 themselves; http://github.com/KentBeck/junit/issues#issue/66 Kristian
Re: Off-Topic
No :) I am not that rich either... Ha Ha. The energy detective should be here next week! On Tue, Dec 8, 2009 at 8:55 PM, Martin Gainty mgai...@hotmail.com wrote: any relation to Peter Lynch of Fidelity? why is it everytime my neighbor powers up his Panasonic Plasma 40 my lights go dim? *bienvenue en arrière* Martin __ Note de déni et de confidentialité Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Tue, 8 Dec 2009 17:41:46 -0800 Subject: Re: Offering Help From: bri...@infinity.nu To: dev@maven.apache.org Hi Peter, Welcome back. --Brian On Mon, Dec 7, 2009 at 9:49 PM, Peter Lynch pe...@peterlynch.ca wrote: Hello devs, A long time ago I was once a committer on Apache Maven. However as time passed, life happened elsewhere. Despite this I have been programming in Java for the past 10 years or so and on virtually every project of mine since Maven 1.0.2 I had the opportunity to use Maven for my build tasks. So before I go any further, thanks to those of you who have stuck around and kept Maven humming along . Now I happen to be in a position to provide some time to actually contribute more concretely in way of fixes, applying patches, writing tests or other grunt work as required. The past week I've been becoming familiar again with the Maven development process/env/docs, source repo and other such things. One thing has led to another and I've chosen to test a patch (already supplied by someone else) for MECLIPSE-601 and create some integration tests for the ToMaven mojo which would exercise this. I will attach a final patch to the issue when complete. Anyways, thought I'd drop a line to let you know of my status. I look forward to helping out as much as I can. Thanks, Peter Lynch ply...@apache.org peterlynch.ca - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org _ Windows 7: Unclutter your desktop. Learn more. http://www.microsoft.com/windows/windows-7/videos-tours.aspx?h=7secslideid=1media=aero-shake-7secondlistid=1stop=1ocid=PID24727::T:WLMTAGL:ON:WL:en-US:WWL_WIN_7secdemo:122009
Offering Help
Hello devs, A long time ago I was once a committer on Apache Maven. However as time passed, life happened elsewhere. Despite this I have been programming in Java for the past 10 years or so and on virtually every project of mine since Maven 1.0.2 I had the opportunity to use Maven for my build tasks. So before I go any further, thanks to those of you who have stuck around and kept Maven humming along . Now I happen to be in a position to provide some time to actually contribute more concretely in way of fixes, applying patches, writing tests or other grunt work as required. The past week I've been becoming familiar again with the Maven development process/env/docs, source repo and other such things. One thing has led to another and I've chosen to test a patch (already supplied by someone else) for MECLIPSE-601 and create some integration tests for the ToMaven mojo which would exercise this. I will attach a final patch to the issue when complete. Anyways, thought I'd drop a line to let you know of my status. I look forward to helping out as much as I can. Thanks, Peter Lynch ply...@apache.org peterlynch.ca
Re: Please Help
This looks like a user question to me. Try to provide more information to us...@maven.apache.org. On Tue, Dec 8, 2009 at 12:30 AM, chandrashekar.marigo...@ubs.com wrote: Hello Team, Please help me in the below problem. I am trying to build the project, while executing the command mvn clean install I am getting below error. I have attached screen shot of repository files, what I have in .m2 folder. *** *** U:\LDN_DATA_RKYC\PilWR\OLayerEJB\Pil_Wrmvn clean install [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Maven Quick Start Archetype [INFO] Unnamed - olutilities:olutilities:jar:1.0 [INFO] Unnamed - Pil_Winrunner:Pil_Winrunner:jar:1.0 [INFO] Unnamed - Pil_WinrunnerEJB:Pil_WinrunnerEJB:ejb:1.0 [INFO] Unnamed - Pil_WinrunnerEAR:Pil_WinrunnerEAR:ear:1.0 [INFO] - --- [INFO] Building Maven Quick Start Archetype [INFO]task-segment: [clean, install] [INFO] - --- [INFO] [clean:clean] [INFO] Deleting directory U:\LDN_DATA_RKYC\PilWR\OLayerEJB\Pil_Wr\target [INFO] Deleting directory U:\LDN_DATA_RKYC\PilWR\OLayerEJB\Pil_Wr\target\classes [INFO] Deleting directory U:\LDN_DATA_RKYC\PilWR\OLayerEJB\Pil_Wr\target\test-cl asses [INFO] [site:attach-descriptor] [INFO] [install:install] [INFO] Installing U:\LDN_DATA_RKYC\PilWR\OLayerEJB\Pil_Wr\pom.xml to C:\Document s and Settings\marigoch\.m2\repository\PIL_WrOL\PIL_WrOL\1.0\PIL_WrOL-1.0.pom [INFO] - --- [INFO] Building Unnamed - olutilities:olutilities:jar:1.0 [INFO]task-segment: [clean, install] [INFO] - --- [INFO] [clean:clean] [INFO] Deleting directory U:\LDN_DATA_RKYC\PilWR\OLayerEJB\Pil_Wr\olutilities\ta rget [INFO] Deleting directory U:\LDN_DATA_RKYC\PilWR\OLayerEJB\Pil_Wr\olutilities\ta rget\classes [INFO] Deleting directory U:\LDN_DATA_RKYC\PilWR\OLayerEJB\Pil_Wr\olutilities\ta rget\test-classes [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. Downloading: http://hammer.swissbank.com:5201/runtimeRepo/core/core/1.0/core-1.0 .pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: core:core Reason: Error getting POM for 'core:core' from the repository: Error transferrin g file core:core:pom:1.0 from the specified remote repositories: xtools-central (http://hammer.swissbank.com:5201/runtimeRepo), central (http://repo1.maven.org/maven2), xtools-hufs (http://hammer.swissbank.com:5201/hufsRepo) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 32 seconds [INFO] Finished at: Tue Dec 08 04:12:52 GMT 2009 [INFO] Final Memory: 7M/19M [INFO] U:\LDN_DATA_RKYC\PilWR\OLayerEJB\Pil_Wr *** *** Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mails are not encrypted and cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. UBS reserves the right to retain all messages. Messages are protected and accessed only in legally justified cases. - To unsubscribe,
Re: [m2] Database plugin
Vincent, Thanks for mentioning Octopus. I too am looking for such a plugin. My innediate need is for an m1 project though. The most I got is an m1 plugin wrapping a snapshot of ddlutils. -Peter Vincent Massol wrote: FYI, I've blogged about my need for a database plugin for m2 here: http://tinyurl.com/ctqb3 I've received some great answer. The best solution so far would seem to be to use Octopus from ObjectWeb and wrap it in a m2 plugin. I'll wait a few days more (in the hope that some other solutions are proposed) and then I'll start working on the plugin. I'd like to ensure I won't redo any work that one of you is currently doing so if you're working on something related to databases in the context in m2 please speak up! :-) If you're interested to help, please also speak up! Any feedback on Octopus would be great as I've never used it... Thanks -Vincent - 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]
[jira] Commented: (MNG-678) scp intermittently failing deploying artifact
[ http://jira.codehaus.org/browse/MNG-678?page=comments#action_49262 ] Peter Lynch commented on MNG-678: - Certain parts of this issue are similar to one I am experiencing, although the resulting error message is a little different. I successfully deployed the xmlbeans plugin to an internal maven repo that sits on a Linux Redhat9 box. It works the first time no problem. Then executing the same 'mvn deploy' command with the same configuration again, to the same repo results in the following failure : [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error deploying artifact: Did receive proper ACK: '1' [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying artifact: Did receive proper ACK: '1' at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:544) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:469) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:448) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) 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: Error deploying artifact: Did receive proper ACK: '1' at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:159) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:399) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519) ... 16 more Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException: Error deploying artifact: Did receive proper ACK: '1' at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:91) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:148) ... 18 more Caused by: org.apache.maven.wagon.TransferFailedException: Did receive proper ACK: '1' at org.apache.maven.wagon.providers.ssh.ScpWagon.checkAck(ScpWagon.java:203) at org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:140) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:180) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:109) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:77) ... 19 more [INFO] IF I go and delete the deployed artifact in the remote repo and try again it works. If I then try to redeploy it fails as above again. If the same artifact is present it will continually fail. This is using maven 2.0 final. scp intermittently failing deploying artifact - Key: MNG-678 URL: http://jira.codehaus.org/browse/MNG-678 Project: Maven 2 Type: Bug Components: maven-artifact Versions: 2.0-alpha-3 Environment: JDK 1.5, Red Hat 9 Reporter: Joe Futrelle Assignee: Brett Porter Fix For: 2.0.1 Some of the time, deploying artifacts fails during the scp transfer. The bottom of the stack trace is reproduced below. If I run the m2 deploy enough times, it succeeds; not sure why. This is not an unknown issue with Jsch; apparently client code can cause behavior like this if it doesn't dispose of connections properly. Possibly a plugin that's runs before
[jira] Created: (MAVEN-1706) maven.src.dir != pom.build.sourceDirectory
maven.src.dir != pom.build.sourceDirectory
--
Key: MAVEN-1706
URL: http://jira.codehaus.org/browse/MAVEN-1706
Project: Maven
Type: Bug
Components: documentation, core
Versions: 1.0.2
Reporter: Peter Lynch
Maven documentation states on http://maven.apache.org/reference/properties.html
maven.src.dirThe base directory for source code. DEPRECATED: Currently
unused. Instead, use the sourceDirectory element of the POM.
${basedir}/src
Problem is that maven.src.dir != pom.build.sourceDirectory in practice.
default of maven.src.dir property is ${basedir}/src. Most plugins project.xml
and their dependent Jelly plugin code expect pom.build.sourceDirectory to point
to src/java, ie. where your Java sources are located.
Try setting sourceDirectory element in your java project's POM to 'src' and
watch the various java/jar/junit plugin's croak if you have any other Java
source files in any other location than src/java because they all will try to
be compiled all at one. Another example: Grep for pom.build.sourceDirectory in
your plugin cache and look at all the code that expects it to point to
src/java, where you java sources live.
The solution for existing projects is to ignore the documentation as written
and make pom.build.sourceDirectory still point to src/java, then use
maven.src.dir when they want the real root source directory. The documentation
needs to be replaced on this front. Or replace the code in 10+ standard plugins
to not assume sourceDirectory element is pointing to Java home.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MAVEN-1450) jsl:template Property 'match' has no write method
[ http://jira.codehaus.org/browse/MAVEN-1450?page=all ] Peter Lynch reopened MAVEN-1450: Assign To: Brett Porter Sample output: $maven site __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 Plugin cache will be regenerated build:start: site: xdoc:register-reports: maven-changelog-plugin:register: maven-changes-plugin:register: maven-checkstyle-plugin:register: maven-developer-activity-plugin:register: faq:init: maven-faq-plugin:register: maven-file-activity-plugin:register: xdoc:init: maven-javadoc-plugin:register: [mkdir] Created dir: /home/build/dev/inphonic/HEAD/mvno/dspp/target/javadoc/src Tag library requested that is not present: 'simian' in plugin: 'maven-simian-plugin-1.5' maven-jdepend-plugin:register: maven-junit-report-plugin:register: maven-jxr-plugin:register: maven-license-plugin:register: maven-pmd-plugin:register: maven-tasklist-plugin:register: maven-findbugs-plugin:register: maven-simian-plugin:register: site:run-reports: [echo] Generating the Change Log... maven-changelog-plugin:report: [echo] Generating the changelog report ChangeSet between 2005-08-27 and 2005-09-27: 12 entries BUILD FAILED File.. /home/build/.maven/cache/maven-xdoc-plugin-1.8/plugin.jelly Element... j:include Line.. 130 Column 55 file:/home/build/.maven/cache/maven-changelog-plugin-1.8.2/plugin-resources/changelog.jsl:30:35: jsl:template Property 'match' has no write method Total time: 18 seconds Finished at: Mon Sep 26 09:30:50 EDT 2005 === Checklist: o make sure CLASSPATH is not set o Make sure you old cache is empty. ie. rm -rf ~/.maven/cache. CAUTION: careful you don't delete some custom installed plugin sources here without backups. o install final version of Maven 1.0.2 and update $MAVEN_HOME to point to it Test case: 1. replace $MAVEN_HOME/plugins/maven-artifact-plugin-1.4.1.jar with maven-artifact-plugin-1.5.1.jar or maven-artifact-plugin-1.5.2.jar 2. call maven goals 'site' or 'site:deploy' or (likely) any plugin that generates a report via xdoc plugin or site plugin. 3. Notice that you get an error with a message jsl:template Property 'match' has no write method WORKAROUND: open artifact plugin project.xml that was extracted to you local cache. Typically this is found here ~/.maven/cache/maven-artifact-plugin-1.5.1/project.xml comment out the commons-jelly 1.0-beta-4 dependency. Example: !-- dependency groupIdcommons-jelly/groupId artifactIdcommons-jelly/artifactId version1.0-beta-4/version /dependency -- Try your maven goal again. The problem should have been resolved. If not, then perhaps another plugin project.xml is loading commons-jelly core and overriding the one provided with core maven. FWIW: I followed the above corrective measures and then proceeded to upgrade every other plugin one by one to the latest version as of Sept 26, 2005 running on Maven 1.0.2 and could not reproduce the problem with any other plugin/goal combination. The main goals used during testing were 'site' and 'site:deploy' however. It seems the main problem plugin is the artifact plugin. I feel this is a bug in maven classloading though. One should design a plugin mechanism that avoids letting a plugin's dependencies cause other non-related plugins to fail. Also one could argue that the artifact plugin should not be depending on a common-jelly version so different from the one from maven core and that the artifact plugin has the real bug. So I will leave it up to Brett or Jason to decide if another issue should be opened to track this elesewhere. Since the erorr message provided above makes no mention of the artifact plugin, it was only though many hours of trial and error I was able to deduce the artifact plugin's specific jelly depends was at fault. The FAQ could be updated with more recent/pertinent info than just jelly version conflict. Otherwise there is no clear path to solve this problem. As a more permanent site wide/common maven home fix, I modified the artifact plugin as above, made a new jar called maven-artifact-plugin-1.5.2.MAVEN-1450.jar ( modifying the currentVersion tag in the project.xml too) and replaced maven-artifact-plugin-1.5.2.jar with it. Now if individual caches get deleted, they will pick up a fixed artifact plugin jar file to extract and use to make sure the problem does not repeat itself. jsl:template Property 'match' has no write method - Key: MAVEN-1450 URL: http://jira.codehaus.org/browse/MAVEN-1450 Project: Maven Type: Bug Reporter: Nicolas Chalumeau Assignee: Brett Porter Attachments: info.txt classpath issue. Please post this to JIRA with maven --info output. - Brett On Wed, 22 Sep 2004
Re: [VOTE] Release all changed plugins
I will do webserver as well. I don't think there are any issues there but it is worth a closer look on my part. Same timeline... -Peter Brett Porter wrote: Ok, sounds good to me. It's really good to see you owning this process because it's how its meant to be! Will you do webserver at the same time, or is it good to go? Cheers, Brett -Original Message- From: Peter Lynch [mailto:[EMAIL PROTECTED] Sent: Thursday, 13 May 2004 2:29 AM To: Maven Developers List Subject: Re: [VOTE] Release all changed plugins Hi Brett, The appserver plugin has a few issues re-opened, so before it is released, it needs to be fixed. Please hold off on releasing that for now until we get the open issues sorted out. I expect the issues will be resolved by the end of next week. But, hey don't delay releasing RC3 of maven in the meantime. +0 Thanks, -Peter Brett Porter wrote: Hi, Please vote +1 if you don't mind all changed plugins being released again. If you have a particular plugin you would like to release yourself, please just mention that in your email and say when it will be done by. I will start releasing ones I know I can (eg xdoc) today. +1 from me - Brett -- Brett Porter Team Leader, Core Systems f2 network ~ everything essential - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Peter Lynch Mission Cap Consulting Group - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Peter Lynch Mission Cap Consulting Group - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release all changed plugins
Hi Brett, The appserver plugin has a few issues re-opened, so before it is released, it needs to be fixed. Please hold off on releasing that for now until we get the open issues sorted out. I expect the issues will be resolved by the end of next week. But, hey don't delay releasing RC3 of maven in the meantime. +0 Thanks, -Peter Brett Porter wrote: Hi, Please vote +1 if you don't mind all changed plugins being released again. If you have a particular plugin you would like to release yourself, please just mention that in your email and say when it will be done by. I will start releasing ones I know I can (eg xdoc) today. +1 from me - Brett -- Brett Porter Team Leader, Core Systems f2 network ~ everything essential - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Peter Lynch Mission Cap Consulting Group - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Plugin plugin] Changing plugin:deploy
Yes, I would prefer to keep some goal that puts the expanded plugin jar into my plugin cache only. Call it what you will, but perhaps it could mention installing the plugin to cache i.e. plugin:install-to-cache or whatever. The use case is when you are sharing your local repo with other developers and you are testing a new plugin that you don't want to make available to others in the local repo. -Peter Vincent Massol wrote: Hi, I'd like to change the plugin:deploy goal so that it deploys the plugin on the remote repo instead of simply unpacking a plugin jar in the local plugin cache (if this feature is used by anyone, I can rename the goal to plugin:unpack) Ok? Thanks -Vincent - 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: [pom3/4] compatibilities element.
Vincent, Perhaps just keep it simple. Only indicate what the minimum Maven version that the plugin needs. Going beyond that will get extremely complex IMO. I wouldn't bother failing either even if the plugin is run in a maven older than that stated in the plugin POM. Maybe just give a warning to the user and let the user decide if they care. Some goals in the plugin may fail, others may work, etc... My 2 cents... -Peter Vincent Massol wrote: Here is what I said in an email: --- As requested by dIon here's a summary of the 2 proposals we have for introducing compatibility definition in the POM for plugins (i.e. what version of Maven a given plugin is compatible with). Proposal 1: * Add the following to project.xml (this is an example): compatibilities compatibility1.0-rc1/compatibility compatibility1.0-rc2/compatibility compatibility1.0-rc3-SNAPSHOT/compatibility /compatibilities Proposal 2: * Reuse the dependencies elements of project.xml (this is an example): dependency groupIdmaven/groupId artifactIdmaven/artifactId version1.0+/version typemaven/type /dependency My analysis: * First question to answer: whether we wish to support complex versioning right now. i.e. the use of +. I am personally not in favor of using that now for 2 reasons: * It is complex to implement and we could easily use a list of versions as showin in proposal 1 * It raises lots of ugly questions. Like: if I say 1.0-rc1+, how can I know that my plugin will be compatible with 1.1 when it is not even yet designed nor released? So in practice I cannot say 1.0-rc1+ but I'll have to say something like 1.0-rc1-1.0 * I like the dependency reuse but for the following points: * We will need to really tackle the type element properly and provide Resolvers for each type. We'll also need to provide better APIs for plugin developers as I believe some plugins are currently iterating over any dependency. Something like project.getDependencies(type) maybe. * How do we specify multiple versions? Using a comma-separated list seem to have been rejected by everyone (see previous posts on compatibility in archives). * Although we could reuse the dependency stuff, Maven core is something special and unlike other dependencies. Why? Because other dependencies can be downloaded whereas Maven core is installed and cannot be changed automatically. Also Maven is not an artifact. It is not composed only of a JAR. It is a complete system. That means there's no relationship between the Maven system installed on your machine and the remote repository. It happens there is a maven jar but this not the compatibility we are stating. We are stating a compatibility with the full installed Maven, not an API compatibility with the maven jar. * Are we going to also specify what version of the POM a plugin supports? Now that plugins are extracted from the core and could be provided by third parties, it may become necessary. One solution would be to link Maven versions with POM versions but I don't know if it provides enough flexibility. Thanks -Vincent - Could you comment on the 2 proposals? Thanks -Vincent -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 27 November 2003 06:53 To: [EMAIL PROTECTED] Subject: [pom3/4] compatibilities element. Where did this discussion end up. From what I can tell, I suggested we re-use the dependency element with a new type, and then discussion stalled. Is that it? -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: maven-new/fetch project.properties
How does this diff affect MAVEN-272? -Peter [EMAIL PROTECTED] wrote: bwalding2003/06/12 02:12:02 Modified:fetchproject.properties Log: Add section when there are no contributors PR: MAVEN-272 Submitted by: Peter Lynch Revision ChangesPath 1.3 +1 -1 maven-new/fetch/project.properties Index: project.properties === RCS file: /home/cvs/maven-new/fetch/project.properties,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- project.properties 25 May 2003 12:07:08 - 1.2 +++ project.properties 12 Jun 2003 09:12:02 - 1.3 @@ -1,2 +1,2 @@ maven.xdoc.poweredby.image=maven-bolt.png -maven.checkstyle.properties=metadata/checkstyle.properties +#maven.checkstyle.properties=metadata/checkstyle.properties - 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: cvs commit: maven/src/bin maven.bat
Mark H. Wilkinson wrote: Either that, or leave this file as plain text and convert it to dos line endings during the build... -Mark. Yeah I like that idea the best. Thanks, -Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
