Maven Shell
Folks, just a quick not that I’ve updated Maven Shell for the latest release, can be found with the latest SNAPSHOT: https://oss.sonatype.org/content/repositories/snapshots/com/planet57/maven/shell/dist/mvnsh-assembly/1.2.0-SNAPSHOT/ Locally seems to be fully functional. I’ve been updating GShell (which mvnsh is based on) as well. I’m considering augmenting the release versions of mvnsh to match the upstream versions. I’m also eventually gonna update the jline support as I think jline3 is much much improved, thanks to gnodet, but I haven’t done that yet. If there are folks that may still be using older versions of the shell, I’d like to ask them to test the latest SNAPSHOTS and report back any issues. Cheers, —jason
maven-release-plugin does not update DM deps w/scope=import
It looks like maven-release-plugin:2.0 is not properly updating dependencies in the dependencyManagement section with scope=import. Basically making it impossible to release using the plugin when using import scope to manage dependencies in a complex project. Is this easy to fix... or even on anyones radar? --jason - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-release-plugin does not update DM deps w/scope=import
It also appears that when processing child modules of a project that includes DM deps w/scope=import that it does not properly update the parent version in the child pom and inserts a new version element with the release version. :-( --jason On Sep 29, 2010, at 10:33 AM, Jason Dillon wrote: It looks like maven-release-plugin:2.0 is not properly updating dependencies in the dependencyManagement section with scope=import. Basically making it impossible to release using the plugin when using import scope to manage dependencies in a complex project. Is this easy to fix... or even on anyones radar? --jason - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
GMaven 1.0 Released
Finally got around to pushing out a 1.0, not much has changed since the last RC. JIRA and the website are still in a state of disarray as the project moves out from under the groovy umbrella to the gmaven project at the 'haus. I will work on cleaning this up soon. --jaso - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] GMaven 1.0-rc-5 released
For more details on whats included in this release please see the release notes: http://groovy.codehaus.org/GMaven+-+1.0-rc-5+Release * * * Artifacts and generated site is being published now, may take a few hours for them to be available; please be patient. Thanks, --jason - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
GMaven 1.0-rc-4 released
For more details please see the release notes: http://groovy.codehaus.org/GMaven+-+1.0-rc-4+Release --jason - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Problem with m-javadoc-p 2.5 looping
I'm at a loss, I can't figure out what is going on with site generation... really hoping someone here can shed some light on the problem. It looks like when running `mvn site` on my project (GShell) that it runs forever and loops like crazy... svn co https://svn.apache.org/repos/asf/geronimo/gshell/trunk gshell cd gshell mvn site ^^^ loops over and over GShell inherits from Genesis 2.0, which is here: https://svn.apache.org/repos/asf/geronimo/genesis/trunk Which consists of: snip [INFO] Genesis ... SUCCESS [3.037s] [INFO] Genesis Maven Plugin .. SUCCESS [9.210s] [INFO] Genesis Packaging . SUCCESS [0.041s] [INFO] Genesis Flava . SUCCESS [0.015s] [INFO] Genesis Flava :: Default .. SUCCESS [1.162s] [INFO] Genesis Flava :: Java 5 ... SUCCESS [0.029s] [INFO] Genesis Flava :: Java 1.4 . SUCCESS [0.029s] [INFO] Genesis Skin .. SUCCESS [0.006s] [INFO] Genesis Skin :: Geronimo .. SUCCESS [0.035s] /snip GShell depends on Genesis Flava :: Java 5, which is a child of Genesis Flava :: Default which is a child of Genesis. Everything short of `mvn site` muck works fine... but when it comes to building a site, it appears that the build recurses indefinitely... and I've no idea why. Also I see some very strange javadoc:test- aggregate goal executions which are never configured. Can someone please have a look... I can't use mvn to generate sites for these complex projects anymore because of this problem... its killing me. *on knees* please? --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
GMaven 1.0-rc-1 released
The latest incarnation of Groovy support for Maven, GMaven has been released! This is the first release of the code-base since it was moved from the Mojo project to the Groovy project. For more details on whats included in this release please see the release notes: http://groovy.codehaus.org/GMaven+-+1.0-rc-1+Release --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [groovy-user] GMaven 1.0-rc-1 released
Thanks, fixed. --jason On May 4, 2008, at 3:43 PM, Russel Winder wrote: On Sun, 2008-05-04 at 15:14 +0700, Jason Dillon wrote: The latest incarnation of Groovy support for Maven, GMaven has been released! This is the first release of the code-base since it was moved from the Mojo project to the Groovy project. For more details on whats included in this release please see the release notes: http://groovy.codehaus.org/GMaven+-+1.0-rc-1+Release The constructions: dependencyManagement dependency groupIdorg.codehaus.groovy.maven/groupId artifactIdgmaven-mojo/artifactId version1.0-rc-1/version /dependency dependency groupIdorg.codehaus.groovy.maven.runtime/groupId artifactIdgmaven-runtime-default/artifactId version1.0-rc-1/version /dependency /dependencyManagement appears to be malformed POM XML. Using it I just get Reason: Parse error reading POM. Reason: Unrecognised tag: 'dependency' (position: START_TAG seen ...dependencyManagement \ndependency... @142:17) If I use a dependencies tag instead of a dependencyManagement tag it seems to work better. -- Russel. Dr Russel Winder Partner Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203 41 Buckmaster Road, f: +44 8700 516 084 London SW11 1EN, UK. m: +44 7770 465 077 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Maven 2.x Selenium Plugin - Version 1.0-beta-2
Release Notes - Maven 2.x Selenium Plugin - Version 1.0-beta-2 ** Bug * [MSELENIUM-13] - Selenese goal crashes after executing a test suite * [MSELENIUM-14] - extensions misspelled extentions * [MSELENIUM-25] - selenium:xvfb sometimes fails ** Improvement * [MSELENIUM-2] - Add better validation of browser configuration when starting the server * [MSELENIUM-5] - Upgrade Selenium to 0.9.2 * [MSELENIUM-8] - Upgrade to Selenium 0.9.2-SNAPSHOT * [MSELENIUM-9] - Re-implement as a Groovy mojo * [MSELENIUM-10] - Add support to gracefully shutdown the Selenium server * [MSELENIUM-12] - Setup an Xauthority file for the Xvfb server to allow clients to connect when another X server is running * [MSELENIUM-17] - Add support for -browserSessionReuse * [MSELENIUM-18] - Add support for -forcedBrowserMode ** New Feature * [MSELENIUM-1] - Add support for headless operation on unix systems with Xvfb * [MSELENIUM-6] - Add support for multiWindow * [MSELENIUM-7] - Add support to invoke html testsuites * [MSELENIUM-15] - Add support for firefoxProfileTemplate * [MSELENIUM-16] - Add support for alwaysProxy * [MSELENIUM-21] - add 'skip' capability ** Task * [MSELENIUM-11] - Add FAQ to the site --jason
Re: [ANN] groovy-maven-plugin 1.0-beta-2
Hi folks, a little note... looks like something is wedged in the codehaus - central sync... As the artifacts have been deployed here: http://repository.codehaus.org/org/codehaus/mojo/groovy/groovy/ 1.0-beta-2/ But is been a long time now and still they haven't made it to here (where they should have been already): http://repo1.maven.org/maven2/org/codehaus/mojo/groovy/groovy/ 1.0-beta-2/ Hopefully this will be resolved soon. Sorry about that... :-\ --jason On Aug 21, 2007, at 12:15 PM, Jason Dillon wrote: Hiya folks! I gotta say I am really stoked to announce the release of the Groovy Maven Plugin (and related modules) version 1.0-beta-2! This release has some really nice goodies in it for your Maven +Groovy development enjoyment: * Support for mixed Java + Groovy compilation * New goals to run the shell, console and java2groovy tools from Maven Some updates to the site documentation will be rolling around shortly. For the full list of issues fixed for this release please see the changelog: http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=truepid=11532fixfor=13621 And as always, peep at the latest docs up here: http://mojo.codehaus.org/groovy/ Cheers, --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] groovy-maven-plugin 1.0-beta-2
Hiya folks! I gotta say I am really stoked to announce the release of the Groovy Maven Plugin (and related modules) version 1.0-beta-2! This release has some really nice goodies in it for your Maven+Groovy development enjoyment: * Support for mixed Java + Groovy compilation * New goals to run the shell, console and java2groovy tools from Maven Some updates to the site documentation will be rolling around shortly. For the full list of issues fixed for this release please see the changelog: http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=truepid=11532fixfor=13621 And as always, peep at the latest docs up here: http://mojo.codehaus.org/groovy/ Cheers, --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Confluence Maven Plugin
Hiya, just a quick note... I've started to whip up a simple plugin to interact with an Atlassian Confluence server from Maven 2. I've merged in my HokeyPokey cli tool and put it all up in the mojo-sandbox here: https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/confluence- maven-plugin I've also published the site here: http://mojo.codehaus.org/confluence-maven-plugin/index.html Though it needs a lot more help, but you can at least see the goal configuration. Right now it has very basic support to: * Add pages * Remove pages * Get pages * Add spaces * Remove spaces Will be adding more bits soon, like a nice export-space which can apply a Velocity template to pages, kinda like AutoExport, except that you can check in all of the templates and resources into svn. And probably doing to add some muck to allow src/site/wiki/**/*.wiki files to automatically publish to a Confluence server too as part of the mvn site bits. Anyways, just a heads up for folks that might be interested. (And yes, this is all implemented in Groovy of course ;-) Cheers, --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mojo-dev] Confluence Maven Plugin
Mostly because Groovy's dynamic invocation makes it relatively simply to support any API calls. And also I had already implemented it for HokeyPokey to help Hernan man months ago. But also because the Groovy code is relatively small and IMO easy to understand: https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/confluence- maven-plugin/src/main/groovy/org/codehaus/mojo/confluence/Client.groovy Right now I don't see why I'd want to pull in Swizzle for what my Client object already does... but eh, right now I'm more interested in making the plugin jump through hoops so once the circus is over I may change my mind... I dunno :-P --jason On Aug 8, 2007, at 4:47 PM, David Blevins wrote: On Aug 8, 2007, at 1:45 PM, Jason Dillon wrote: Hiya, just a quick note... I've started to whip up a simple plugin to interact with an Atlassian Confluence server from Maven 2. I've merged in my HokeyPokey cli tool and put it all up in the mojo-sandbox here: https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/ confluence-maven-plugin I've also published the site here: http://mojo.codehaus.org/confluence-maven-plugin/index.html Though it needs a lot more help, but you can at least see the goal configuration. Right now it has very basic support to: * Add pages * Remove pages * Get pages * Add spaces * Remove spaces Will be adding more bits soon, like a nice export-space which can apply a Velocity template to pages, kinda like AutoExport, except that you can check in all of the templates and resources into svn. And probably doing to add some muck to allow src/site/wiki/ **/*.wiki files to automatically publish to a Confluence server too as part of the mvn site bits. Why not just incorporate the swizzle-confluence library instead or redoing the xml-rpc part in groovy? It has the entire confluence xml-rpc api already to go: http://swizzle.codehaus.org/swizzle-confluence/org/codehaus/ swizzle/confluence/Confluence.html -David - To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mojo-dev] Confluence Maven Plugin
Aighty, well I'll have a looksy and see what I can do ;-) --jason On Aug 8, 2007, at 10:13 PM, David Blevins wrote: On Aug 8, 2007, at 4:55 PM, Jason Dillon wrote: Mostly because Groovy's dynamic invocation makes it relatively simply to support any API calls. And also I had already implemented it for HokeyPokey to help Hernan man months ago. But also because the Groovy code is relatively small and IMO easy to understand: https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/ confluence-maven-plugin/src/main/groovy/org/codehaus/mojo/ confluence/Client.groovy Definitely neat with the groovy-xml rpc stuff dynamic invocations going on. The swizzle-confluence jar is only 24k and just as simple. It'd be cool to have you banging on it. You actually fix things :) All the basic stuff works (add/remove/list, page/space) but would be cool to have someone using it who might dare to go off the beaten path. Maybe someday into getBlogEntries or getMostPopularLabels, etc. -David On Aug 8, 2007, at 4:47 PM, David Blevins wrote: On Aug 8, 2007, at 1:45 PM, Jason Dillon wrote: Hiya, just a quick note... I've started to whip up a simple plugin to interact with an Atlassian Confluence server from Maven 2. I've merged in my HokeyPokey cli tool and put it all up in the mojo-sandbox here: https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/ confluence-maven-plugin I've also published the site here: http://mojo.codehaus.org/confluence-maven-plugin/index.html Though it needs a lot more help, but you can at least see the goal configuration. Right now it has very basic support to: * Add pages * Remove pages * Get pages * Add spaces * Remove spaces Will be adding more bits soon, like a nice export-space which can apply a Velocity template to pages, kinda like AutoExport, except that you can check in all of the templates and resources into svn. And probably doing to add some muck to allow src/site/ wiki/**/*.wiki files to automatically publish to a Confluence server too as part of the mvn site bits. Why not just incorporate the swizzle-confluence library instead or redoing the xml-rpc part in groovy? It has the entire confluence xml-rpc api already to go: http://swizzle.codehaus.org/swizzle-confluence/org/codehaus/ swizzle/confluence/Confluence.html -David - To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] groovy-maven-plugin 1.0-beta-1
Hello, me again :-) I am once again pleased to announce the release of the Groovy Maven Plugin version 1.0-beta-1. * * * This release includes a few significants bits... * Uses Groovy 1.1-beta-2 (and Ant 1.7) * New goal to invoke GroovyDoc and site report support Some other minor bits, like improved support for mojo implementations and a few bugs fixed too. Site is still here: http://mojo.codehaus.org/groovy/ See the change log for the full list of stuff that was changed: http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=truepid=11532fixfor=13497 Please use, enjoy and report any issues or spontaneous happiness you run into while using it. Cheers, --jason
Re: [groovy-user] [ANN] groovy-maven-plugin 1.0-beta-1
FYI, I've started to add a list of Maven plugins which have been implemented in Groovy here: http://mojo.codehaus.org/groovy/groovy-plugins.html I am interested to know if there are any more plugins that I can add up here. I think its helpful to list them so that folks can get an idea how others are using it, maybe even see some reference code for how simply it is. If you have a plugin thats using this integration or know of one, can you please ping back the list ( [EMAIL PROTECTED] ) with a URL? I've listed the major ones I've converted as well as the 2 new example plugins that I created to show how simple it is. The examples are stripped down version of the standard maven-clean-plugin and maven-install-plugin. I didn't add all of the goals, but they are just examples anyways ;-) I may soon add a brief comparison of the source-code size between a groovy plugin and its java version just for kicks too ;-) Cheers, --jason On Jul 20, 2007, at 2:02 AM, Guillaume Laforge wrote: Congratulations Jason! Minor remark: There are perhaps some modifications to be done on the site wrt version numbers in the poms. On 7/20/07, Jason Dillon [EMAIL PROTECTED] wrote: Hello, me again :-) I am once again pleased to announce the release of the Groovy Maven Plugin version 1.0-beta-1. * * * This release includes a few significants bits... * Uses Groovy 1.1-beta-2 (and Ant 1.7) * New goal to invoke GroovyDoc and site report support Some other minor bits, like improved support for mojo implementations and a few bugs fixed too. Site is still here: http://mojo.codehaus.org/groovy/ See the change log for the full list of stuff that was changed: http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=truepid=11532fixfor=13497 Please use, enjoy and report any issues or spontaneous happiness you run into while using it. Cheers, --jason -- Guillaume Laforge Groovy Project Manager http://glaforge.free.fr/blog/groovy - To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [groovy-user] Let your Mojo's be Groovy baby!
Sorry, I never got these emails in my inbox... dunno why. So I haven't just been ignoring you ;-) Anyways, looks like a bug in the Groovy descriptor extractor. I've filled an issue here: http://jira.codehaus.org/browse/MGROOVY-40 Will try to get that fixed asap. --jason Andrew Perepelytsya wrote: In a nice tradition of answering one's own questions... ;) Jason't other thread about site goal and similar symptoms gave me another idea, which finally shaped into a solution. This could be included in the Groovy m2 plugins development guide, smth under 'Building Groovy m2 plugins in a reactor/multi-module project'. Full poms are available at the above mentioned SVN locations, I'll post snippets here only. Parent: === build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-plugin-plugin/artifactId configuration !-- *MUST* override the extractors to disable everything except java, as groovy can handle both java and groovy files. Duplicate processing chokes maven. Java is the default for plugin implementation language, overridable in individual projects. -- extractors extractorjava/extractor !-- add custom default extractors here if needed -- !-- extractorbsh/extractor -- /extractors /configuration dependencies dependency groupIdorg.codehaus.mojo/groupId artifactIdgroovy-mojo-tools/artifactId version1.0-alpha-3-SNAPSHOT/version /dependency /dependencies /plugin /plugins /build The key here is the dependency of the plugin AND extractor configuration. It's critical to not enable groovy extractor for plugins implemented in Java, as maven will try to process them with both java and groovy and fail. Child m2 plugin project implemented in groovy (the same build/plugins section): === plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-plugin-plugin/artifactId configuration extractors !-- *MUST* override the extractors to disable everything except groovy, as groovy can handle both java and groovy files. Duplicate processing chokes maven. The rest of the config is inherited. -- extractorgroovy/extractor /extractors /configuration /plugin Hope it saves much pain to others. And the best part is those settings are available in released m2 plugins, which lessens the snapshot pain. Cheers! Andrew -- View this message in context: http://www.nabble.com/-groovy-user--Let-your-Mojo%27s-be-Groovy-baby%21-tf3529339s177.html#a10689632 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Maven Enforcer Plugin 1.0-alpha-1
Yay! :-) --jason On Apr 7, 2007, at 5:20 PM, Brian Fox wrote: We are pleased to announce the first release of the maven-enforcer- plugin. The Enforcer plugin provides goals to detect and enforce certain environmental constraints such as Maven Version, JDK version, and OS family/version/architecture. Additionally, the Enforcer can execute custom rules defined by the user. See the plugin site for more information: http://maven.apache.org/plugins/maven-enforcer-plugin Jira Project: http://jira.codehaus.org/browse/MENFORCER This release also consists of a shared component, maven-enforcer-rule-api that allows the creation and execution of the custom rules. --The Maven Team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Let your Mojo's be Groovy baby!
Hi folks, I've just finished up the first draft of support to use Groovy for Maven plugin development, including Javadoc-based Mojo descriptor extraction. I have yet to update the site docs to cover the Mojo impl bits, but I will get to that soon. Until then you can peek at this integration test to see how it works right now: http://svn.codehaus.org/mojo/trunk/mojo/groovy-maven-plugin/src/ it/mojo-1/ I just published 1.0-alpha-3-SNAPSHOT which includes the Groovy Mojo descriptor extractor bits. I'm going to test this more, update the docs and finish up a few other tasks and then start a vote for the 1.0-alpha-3 release. If folks can look at this, try using it to create Maven plugins and provide feedback on success and/or problems I would appreciate it. --jason PS. No fembots were harmed in the writing of this email. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] groovy-maven-plugin 1.0-alpha-2
I've just released version 1.0-alpha-2 of the groovy-maven-plugin. This release fixes a few major issues with the groovy:compile and groovy:testCompile goals. Compilation goals now require that *all* dependencies be included on the classpath (aka added to the poms dependencies) and no longer pickup any classpath elements from the plugin's dependencies itself. This should resolve any issues where Groovy classes are dependent on other classes which are not included in the plugin's dependencies (like junit for example). Additionally, you can now run `mvn groovy:compile` and `mvn groovy:testCompile` from the command-line and they will properly resolve and pickup dependencies for the proper scope. Please be aware that if you run these goals explicitly, that you must configure your poms to use the plugins configuration element and not a plugin execution configuration. I still recommend that for normal usage that folks hook up these goals to phases and specify a phase name on the command-line (aka `mvn install`). But, if you really want you can invoke the goals themselves too ;-) Resolved issues: [MOJO-702] - The compile and testCompile goals should use @requiresDependencyResolution for the proper scope [MOJO-699] - Add extra validation for fileset configuration [MOJO-696] - groovy:testCompile fails to load junit classes when using GroovyTestCase as base-class Site/documentation: http://mojo.codehaus.org/groovy-maven-plugin/ Artifacts published here: http://repository.codehaus.org/org/codehaus/mojo/groovy-maven- plugin/1.0-alpha-2/ In a few hours these will be on central when the repo sync kicks in. * * * Please use, enjoy and provide feedback if you like :-) Unless folks inform me of significant problems or recommend major enhancements, the next release will probably be 1.0-beta-1, and then soon after we will get to 1.0. Thanks to everyone that has provided feedback so far, as well as patches! Cheers, --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] retrotranslator-maven-plugin 1.0-alpha-2
Hello everyone,
I am pleased to announce the release of the Retrotranslator Maven
Plugin version 1.0-alpha-2.
* * *
This version includes:
* Latest Retrotranslator v1.2.1 (big upgrade from last version
which was using 1.0.8)
* New goals to translate Maven projects (translate-project and
translate-war)
* Supports same fileset/jarfileset/dirset configuration as the Ant
task
Due to the last item, the configuration had to be changed again
though... :-( Basically since more than one fileset per-type can be
configured, what used to be:
8
fileset
basedir${project.build.outputDirectory}/basedir
includes
include**/*.class/include
/includes
/fileset
8
Is now:
8
filesets
fileset
directory${project.build.outputDirectory}/directory
includes
include**/*.class/include
/includes
/fileset
/filesets
8
* * *
Site docs are updated here:
http://mojo.codehaus.org/retrotranslator-maven-plugin
Release artifacts are currently here:
http://repository.codehaus.org/org/codehaus/mojo/retrotranslator-
maven-plugin/1.0-alpha-2/
Artifacts should be on the central repository in an hour or so.
--jason
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] groovy-maven-plugin 1.0-alpha-1
Hello everyone, I am pleased to announce the release of the Groovy Maven Plugin version 1.0-alpha-1. * * * This is the first release, pleased see the site documentation for features and usage: http://mojo.codehaus.org/groovy-maven-plugin/ Release artifacts are currently here: http://repository.codehaus.org/org/codehaus/mojo/groovy-maven- plugin/1.0-alpha-1/ Artifacts should be on the central repository in an hour or so. --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Re: selenium plugin?
I don't think there is really much to merge... just peeked at the source for mavenium and there isn't much there. Also appears that its trying to run tests with Selenium, which is not the point of the selenium-maven-plugin, all we do is start the server for remote access, then use the Java API to control Selenium and drive the process from surefire. I will add an example to the site docs so this is clearer. --jason dan tran wrote: looks like mavenium and selenium-maven-plugin at http://svn.codehaus.org/mojo/trunk/mojo/selenium-maven-plugin/ may want to merge. -D On 12/8/06, David [EMAIL PROTECTED] wrote: You can have a look at mavenium. It's a simple plugin that lets you use Selenium-IDE HTML tests in your maven webapp project and integrates in maven's build life cycle, stopping it whenever a test fails. Upload to the maven central repository pending. http://mavenium.sourceforge.net/ David 2006/10/24, Emmanuel Venisse [EMAIL PROTECTED]: Can you move this plugin in MOJO project? Emmanuel Prasad Kashyap a écrit : We in Geronimo 1.2 also use Selenium in our testsuite. We have created a selenium-maven-plugin to start selenium. http://geronimo.apache.org/maven/server/maven-plugins/selenium-maven-plugin/index.html We use TestNG to run the tests. Check out the following links for a basic example. http://svn.apache.org/viewvc/geronimo/server/trunk/testsuite/console-testsuite/ Remeber that this is in trunk. So this is work in progress. Cheers Prasad On 10/20/06, Mick Knutson [EMAIL PROTECTED] wrote: Is this plugin available for maven 2? -- Thanks DJ MICK http://www.djmick.com http://www.myspace.com/mickknutson - 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] -- View this message in context: http://www.nabble.com/selenium-plugin--tf2483863s177.html#a9138230 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.0.5 Released
Rejoice! --jason On Feb 14, 2007, at 1:53 PM, Jason van Zyl wrote: The Maven team would like to announce the release of Maven 2.0.5. You can find the roadmap for the release here: http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=truepid=10500fixfor=12294sorter/field=issuekeysorter/ order=DESC The release notes can be found here: http://maven.apache.org/release-notes.html And you can download it from here: http://maven.apache.org/download.html Thanks, The Maven Apache Team! - 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: How to override jar-plugin dependencies to use a custom version of maven-archiver?
Not sure that maven can calculate that 2.2-maxb-1 2.2. Try to use a more standard version... like 2.3-SNAPSHOT, and if you want maxb-1, then put that in the classifier. --jason On Sep 4, 2006, at 3:32 AM, Max Bowsher wrote: Is it possible to use POM elements to configure the standard maven- jar-plugin to use a custom version of maven-archiver? I am attempting to use: build plugins plugin artifactIdmaven-jar-plugin/artifactId dependencies dependency artifactIdmaven-archiver/artifactId groupIdorg.apache.maven/groupId version2.2-maxb-1/version scoperuntime/scope /dependency /dependencies However, this does not work. The version of maven-archiver specified directly in the jar plugin is used instead: 'mvn -X package' shows: [DEBUG] org.apache.maven.plugins:maven-jar-plugin:maven-plugin: 2.1:runtime (selected for runtime) ... [DEBUG] org.apache.maven:maven-archiver:jar:2.2:runtime (selected for runtime) ... [DEBUG] org.apache.maven:maven-archiver:jar:2.2-maxb-1:runtime (removed - nearer found: 2.2) Must I make a custom version of the jar plugin too, to convince it to use a custom maven-archiver? Thanks in advance for any insight. -- Max Bowsher [EMAIL PROTECTED] http://www.mxtelecom.com - 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: Jelly converting to Maven2
Um, for loop in a Java or Groovy mojo should work.
--jason
-Original Message-
From: cristal [EMAIL PROTECTED]
To: users@maven.apache.org users@maven.apache.org
Sent: Wed May 31 13:24:56 2006
Subject: Jelly converting to Maven2
We had some Jelly script similar to the following in our Maven1 projects. Now
we need to migrate everything into Maven2. It was suggested that we should
write some mojo/ant plugin for the equivalent constructs. Does anyone know
how we replace the jelly's forEach construct in maven2??? -- Many Thanks.
goal name=arttest
j:forEach var=lib items=${pom.artifacts}
j:set var=dep value=${lib.dependency}/
j:set var=name value=${lib.file.name}/
j:set var=parent value=${lib.file.parent}/
j:set var=artifact value=${dep.artifact}/
j:set var=id value=${dep.id}/
j:set var=group value=${dep.artifactDirectory}/
j:set var=version value=${dep.version}/
j:set var=type value=${dep.type}/
j:set var=depname value=${dep.artifactId}/
ant:echoLIB: ${lib}/ant:echo
ant:echoDEP: ${dep}/ant:echo
ant:echoNAME: ${name}/ant:echo
ant:echoPARENT: ${parent}/ant:echo
ant:echoARTIFACT: ${artifact}/ant:echo
ant:echoID: ${id}/ant:echo
ant:echoGROUP: ${group}/ant:echo
ant:echoVERSION: ${version}/ant:echo
ant:echoTYPE: ${type}/ant:echo
ant:echoDEPNAME: ${depname}/ant:echo
ant:echo/ant:echo
/j:forEach
/goal
--
View this message in context:
http://www.nabble.com/Jelly+converting+to+Maven2-t1712886.html#a4651113
Sent from the Maven - Users forum at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Perforce SCM support w/release plugin
Has anyone gotten Perforce to work with the release plugin under M2? Is there anyway to get the release plugin to just resolve SNAPSHOTs and not muck with SCM stuff? --jason This email and any attachment(s) thereto, are intended for the use of the addressee(s) named herein and may contain legally privileged and or confidential information under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email, and any attachment(s) thereto, is strictly prohibited. If you have received this communication in error, please notify the sender at 415-281-2200 or via return e-mail at [EMAIL PROTECTED] and permanently delete the original copy and any copy of any e-mail, and any printout thereof. Thank you for your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to disable clean plugin from running?
I've got a project that uses one module to generate code (using AndroMDA) into another module, but when I do something like `mvn clean install` from the top-level it will generate code from the mda module, then the other module will then delete it all when it runs clean before install. I'd really like to just turn off clean from one of these modules, and then configure the mda module to clean up for it... Any idea how I might get this done? --jason This email and any attachment(s) thereto, are intended for the use of the addressee(s) named herein and may contain legally privileged and or confidential information under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email, and any attachment(s) thereto, is strictly prohibited. If you have received this communication in error, please notify the sender at 415-281-2200 or via return e-mail at [EMAIL PROTECTED] and permanently delete the original copy and any copy of any e-mail, and any printout thereof. Thank you for your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: import statements in Eclipse and maven2
Woah... How do you enable that? --jason -Original Message- From: Kathryn Huxtable To: Maven Users List Sent: Mon Feb 27 21:05:50 2006 Subject: Re: import statements in Eclipse and maven2 That's a link to one approach. Another approach is to enable the Maven2 nature for your project, which should make it use the dependencies in your pom.xml file without needing to regenerate the .classpath file every time you add a dependency. -K -- Kathryn Huxtable Middleware Architect Core Middleware Information Technology, a division of Information Services The University of Kansas On 2/27/06 6:41 PM, KC Baltz [EMAIL PROTECTED] wrote: http://maven.apache.org/guides/mini/guide-ide-eclipse.html -Original Message- From: Ashish Srivastava [mailto:[EMAIL PROTECTED] Sent: Monday, February 27, 2006 4:24 PM To: users@maven.apache.org Subject: import statements in Eclipse and maven2 Hi, I am using maven2 plugin on Eclipse and working on a project which uses maven2. In the eclipse' Java editor all the import statements (and the classes) are underlined red as if it could not find the jars. How can I configure the project to read the pom.xml and work out all the dependencies? -Ashish __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - 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: Running Proximity
I did notice some exceptions when many repos were listed, where at least one of them did not contain any cached artifacts yet. But after getting at least one artifact from eacho repo its been workin fine. --jason -Original Message- From: Cservenak Tamas To: Maven Users List Sent: Fri Jan 27 01:32:10 2006 Subject: Re: Running Proximity Hi Michael, Yes, there are few people using Proximity already without problems (at least without known problems). This error stack trace is quite weird, i do not see anything of my Proximity class (no org.springframework, no hu.ismicro.commons) looks like the problem is Tomcat installation? tx ~t~ Michael Böckling írta: Hi there, did anyone manage to use the proximity application (https://is-micro.myip.hu/projects/ismicro-commons/proximity)? I'm getting NPEs, even though I use Tomcat 5.5 and Java 1.5. I'm posting this here because a) there is no usable official maven proxy and b) mails to the listed developers are non deliverable. I'm thankful for every hint! Regards, Michael Contents of manager.log: INFO: HTMLManager: start: Starting web application at '/px-webapp' 24.01.2006 14:40:49 org.apache.catalina.core.ApplicationContext log SCHWERWIEGEND: FEHLER - Anwendung mit Kontext Pfad /px-webapp konnte nicht gestartet werden java.lang.NullPointerException at org.apache.log4j.NDC.get(NDC.java:209) at org.apache.log4j.spi.LoggingEvent.getNDC(LoggingEvent.java:238) at org.apache.log4j.helpers.PatternParser$BasicPatternConverter.convert(PatternParser.java:401) at org.apache.log4j.helpers.PatternConverter.format(PatternConverter.java:64) at org.apache.log4j.PatternLayout.format(PatternLayout.java:503) at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:301) at org.apache.log4j.DailyRollingFileAppender.subAppend(DailyRollingFileAppender.java:358) at org.apache.log4j.WriterAppender.append(WriterAppender.java:159) at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:230) at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:65) at org.apache.log4j.Category.callAppenders(Category.java:203) at org.apache.log4j.Category.forcedLog(Category.java:388) at org.apache.log4j.Category.log(Category.java:853) at org.apache.commons.logging.impl.Log4JLogger.error(Log4JLogger.java:193) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3731) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4162) at org.apache.catalina.manager.ManagerServlet.start(ManagerServlet.java:1175) at org.apache.catalina.manager.HTMLManagerServlet.start(HTMLManagerServlet.java:527) at org.apache.catalina.manager.HTMLManagerServlet.doGet(HTMLManagerServlet.java:104) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Unknown Source) 24.01.2006 14:40:49 org.apache.catalina.core.ApplicationContext log INFO: HTMLManager: list: Listing contexts for virtual host 'localhost' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using multiple source directories to produce on artefact
This functionality should be added to the core pom IMO.
--jason
-Original Message-
From: dan tran
To: Maven Users List
Sent: Thu Jan 12 00:13:03 2006
Subject: Re: Using multiple source directories to produce on artefact
oh mine this question is getting popular ;-)
check out
build-helper-maven-plugin at http://mojo.codehaus.org
maven 2 books are comming out first quater of 2006, i heard
;-)
On 1/12/06, Andreas Zschorn [EMAIL PROTECTED] wrote:
Hi,
I have a question regarding maven 2 and the use of multiple source
directories.
I want to migrate from ant to maven and have a problem with compiling 2
source directories to one output directory.
Directory structure is the following.
./src/ -- with the main source files
./gen-src/ -- with generated ejb-source files from xdoclet.
./target/ -- target of compiled files
In the build section I can only state on source-directory.
The documentation
under
http://maven.apache.org/guides/mini/guide-using-one-source-directory.html
state there is no problem in using several source directories but they
forgot to say how.
Quote:
There should be no limitations in this approach. Maven natively supports
multiple source directories for the purposes of generated sources.:
I already tried the approach to include the directories in the
configuration
section. The result was, that maven always reported that no files have
changed.
plugins
plugin
artifactIdmaven-compiler-plugin/artifactId
configuration
includes
include${basedir}/src/include
include${basedir}/gen-src/include
/includes
/configuration
/plugin
/plugins
I already searched for a solution but the most answers were to change the
directory layout which is in my case not possible.
I really appreciate your help.
Another question regarding documentation. Perhaps I was to stupid to find
it, but is there any good documentation, or book out there for maven 2.
The
current docu on the website does not have the deep I would expect, for
example a good plugin howto or an overview which xml-configurations tags
are
available for a plugin.
Andreas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
N�zfj|��֜�g���azފ{^�ם~�z�v���笝��v�z)ڝٚ��'��\��+��� u�ݢ�(���z{bjX�~��jب���z���X�i�^��*.jaz)�zw^v��� ��zf��*.j��z���z-���u��v+,zh�jب�جب��ܢ���
��zfj|��֜�g���az���+,\���bn+^tZ���q��y�a��(�k��ƭ�뢺ey� ��b+azǧu�ڷ�y��v�M(�n�w�j)Z��,�fk拜��jwiz��'^��^���(��\֧��)ʇڟ'�j)Z�֧ʚ���.��^�� N��*.~ܢ�^��b�
Re: Experience with maven-proxy.rb
bink7xYAZMVXu.bin Description: this
Re: Experience with maven-proxy.rb
I just got Proximity setup yesterday and so far I'm happy with it. Works for m1 and m2... And is much easier to style IMO. Sorry no URL... But google for proximity maven and you'll find it. For the record I've never heard of maven-proxy.rb so I can't say how they compair. --jason -Original Message- From: Pablo Muñiz García To: Maven Users List Sent: Tue Jan 10 11:58:06 2006 Subject: Experience with maven-proxy.rb Hi all! Lately I've been trying to find an alternative to codehaus maven-proxy that work with maven 2. After some Googling maven-proxy.rb (an script wirtten in Ruby) appeared. I've followed instructions detailed in the script, but I haven't been able to get it work under Apache. Anyone has experience on working with this project? Any success story? Maybe an alternative? Thanks in advance!! Greetings, Pablo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Experience with maven-proxy.rb
FYI, I have been testing out Proximity today... And I noticed that it can get
quite slow with many repositories listed.
I also ran into some strange missing dependencies... That would go away and
come back every other build or so.
Might be better to let Maven 2 handle aggregation...
Dunno.
--jason
-Original Message-
From: Pablo Muñiz García
To: Maven Users List
Sent: Tue Jan 10 12:23:11 2006
Subject: Re: Experience with maven-proxy.rb
Thanks Jason,
Proximity was in the queue. I'll see if I can install it sucessfully.
Greetings, Pablo.
Jason Dillon wrote:
I just got Proximity setup yesterday and so far I'm happy with it. Works for
m1 and m2... And is much easier to style IMO.
Sorry no URL... But google for proximity maven and you'll find it.
For the record I've never heard of maven-proxy.rb so I can't say how they
compair.
--jason
-Original Message-
From: Pablo Muñiz García
To: Maven Users List
Sent: Tue Jan 10 11:58:06 2006
Subject: Experience with maven-proxy.rb
Hi all!
Lately I've been trying to find an alternative to codehaus
maven-proxy that work with maven 2. After some Googling maven-proxy.rb
(an script wirtten in Ruby) appeared. I've followed instructions
detailed in the script, but I haven't been able to get it work under Apache.
Anyone has experience on working with this project? Any success story?
Maybe an alternative?
Thanks in advance!!
Greetings, Pablo.
-
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]
N�zfj|��֜�g���azފ{^�ם~�z�v���笝��v�z)ڝٚ��'��\��+��� u�ݢ�(���z{bjX�~��jب���z���X�i�^��*.jaz)�zw^v��� ��zf��*.j��z���z-���u��v+,zh�jب�جب��ܢ���
��zfj|��֜�g���az���+,\���bn+^tZ���q��y�a��(�k��ƭ�뢺ey� ��b+azǧu�ڷ�y��v�M(�n�w�j)Z��,�fk拜��jwiz��'^��^���(��\֧��)ʇڟ'�j)Z�֧ʚ���.��^�� N��*.~ܢ�^��b�
Re: [m2] How to add additional path for surefire test sources?
binzOBV5rRuqa.bin Description: this
[m2] How to add additional path for surefire test sources?
Hi, I'm trying to figure out how to add an additional directory of sources for inclusion when running surefire tests. Basically I have generated some base tests classes, which need to be accessible from classes under src/test/java (an should not be accessible from src/ main/java). This was easy enough to do in Maven1, by appending to maven.test.compile.src.set, but I can't find anything similar w/Maven2. Note, those classes, just need to get picked up and compiled, they don't need to be scanned for inclusion in the testsuite (though that would be nice too), but this was not possible with Maven1's test plugin, so I generated all abstract helper classes, which concrete classes extend to enable them in the suite. Any idea on how to make this work? Thanks, --jason This email and any attachment(s) thereto, are intended for the use of the addressee(s) named herein and may contain legally privileged and or confidential information under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email, and any attachment(s) thereto, is strictly prohibited. If you have received this communication in error, please notify the sender at 415-281-2200 or via return e-mail at [EMAIL PROTECTED] and permanently delete the original copy and any copy of any e-mail, and any printout thereof. Thank you for your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] Surefire w/TestNG
Any status on support for TestNG from Surefire w/Maven2? --jason This email and any attachment(s) thereto, are intended for the use of the addressee(s) named herein and may contain legally privileged and or confidential information under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email, and any attachment(s) thereto, is strictly prohibited. If you have received this communication in error, please notify the sender at 415-281-2200 or via return e-mail at [EMAIL PROTECTED] and permanently delete the original copy and any copy of any e-mail, and any printout thereof. Thank you for your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How are SNAPSHOT dependency downloads handled?
The first repository might not have the latest snapshot... though in your case it probably would. But in general all repos have to be searched for the latest. I would personally recommend setting up Maven-Proxy to handle your local repository needs as well as for your remote repositories. As if you use SNAPSHOT internally this will speed things up dramatically since only one repo needs to be checked from the client's perspective, and the proxy will cache failures from remote repos so it doesn't keep checking each remote for an artifact that does not exist. --jason -Original Message- From: KC Baltz [mailto:[EMAIL PROTECTED] Sent: Friday, September 23, 2005 11:11 AM To: Maven Users List (E-mail) Subject: How are SNAPSHOT dependency downloads handled? [Using Maven 1.1-beta-2] I'm trying to use SNAPSHOT to get the latest version of an internally developed JAR from our in-house remote repository . It appears to work (I.e. I do end up with the latest version), but not without dumping a number of errors to the screen about how it can't find my jar at maven- plugins.sourceforge.net. I have the following in my personal build.properties: maven.repo.remote=file:///export/home/kcbaltz/testRepo,http://www.ibibli o. org/maven/,http://maven-plugins.sf.net/maven,http://www.codeczar.com/mav en I would assume that if it found the SNAPSHOT in the testRepo repository, it wouldn't search the rest. Is that a correct assumption? The error messages are below: Attempting to download copart-core-1.0-SNAPSHOT.jar. Error getting URI host org.apache.commons.httpclient.HttpException: Redirect from host maven- plugins.sf.net to maven-plugins.sourceforge.net is not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect(HttpMeth od Base.java:1237) at org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse(Htt pM ethodBase.java:1185) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded(HttpMethodBas e. java:967) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java :1 089) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:6 43 ) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:4 97 ) at org.apache.maven.wagon.providers.http.HttpWagon.get(HttpWagon.java:287) at org.apache.maven.wagon.providers.http.HttpWagon.getIfNewer(HttpWagon.jav a: 234) at org.apache.maven.verifier.DependencyVerifier.getRemoteArtifact((BDepend en cyVerifier.java:391) at org.apache.maven.verifier.DependencyVerifier.getDependencies(DependencyV er ifier.java:291) at org.apache.maven.verifier.DependencyVerifier.satisfyDependencies(Depende nc yVerifier.java:182) at org.apache.maven.verifier.DependencyVerifier.verify(DependencyVerifier.j av a:99) at org.apache.maven.project.Project.verifyDependencies(Project.java:569) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:663 ) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263) at org.apache.maven.cli.App.doMain(App.java:511) at org.apache.maven.cli.App.main(App.java:1258) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a: 39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Im pl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.werken.fore(Bhead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Invalid Redirect URI from: http://maven- plugins.sf.net:80/maven//copart/jars/copart-core-1.0-SNAPSHOT.jar to: http://maven-plugins.sourceforge.net/maven//copart/jars/copart-core-1.0- SNAPSHOT.jar Error retrieving artifact from [http://maven-plugins.sf.net/maven]: org.apache.maven.wagon.TransferFailedException: Failed to trasfer file: http://maven-plugins.sf.net/maven//copart/jars/copart-core-1.0- SNAPSHOT.jar. Return code is: 302 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How are SNAPSHOT dependency downloads handled?
The default config props are documented quite well. http://maven-proxy.codehaus.org Should be trivial to get the standalone version up and configured ;-) Then just use it as your single maven.repo.remote. Cheers, --jason -Original Message- From: KC Baltz [mailto:[EMAIL PROTECTED] Sent: Friday, September 23, 2005 11:22 AM To: Maven Users List Subject: RE: How are SNAPSHOT dependency downloads handled? I'll look into that. Is there a good pointer to documentation or a sample config you can get me started with? K.C. -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED] Sent: Friday, September 23, 2005 11:18 AM To: Maven Users List Subject: RE: How are SNAPSHOT dependency downloads handled? The first repository might not have the latest snapshot... though in your case it probably would. But in general all repos have to be searched for the latest. I would personally recommend setting up Maven-Proxy to handle your local repository needs as well as for your remote repositories. As if you use SNAPSHOT internally this will speed things up dramatically since only one repo needs to be checked from the client's perspective, and the proxy will cache failures from remote repos so it doesn't keep checking each remote for an artifact that does not exist. --jason -Original Message- From: KC Baltz [mailto:[EMAIL PROTECTED] Sent: Friday, September 23, 2005 11:11 AM To: Maven Users List (E-mail) Subject: How are SNAPSHOT dependency downloads handled? [Using Maven 1.1-beta-2] I'm trying to use SNAPSHOT to get the latest version of an internally developed JAR from our in-house remote repository . It appears to work (I.e. I do end up with the latest version), but not without dumping a number of errors to the screen about how it can't find my jar at maven- plugins.sourceforge.net. I have the following in my personal build.properties: maven.repo.remote=file:///export/home/kcbaltz/testRepo,http://www.ibibli o. org/maven/,http://maven-plugins.sf.net/maven,http://www.codeczar.com/mav en I would assume that if it found the SNAPSHOT in the testRepo repository, it wouldn't search the rest. Is that a correct assumption? The error messages are below: Attempting to download copart-core-1.0-SNAPSHOT.jar. Error getting URI host org.apache.commons.httpclient.HttpException: Redirect from host maven- plugins.sf.net to maven-plugins.sourceforge.net is not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect(HttpMeth od Base.java:1237) at org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse(Htt pM ethodBase.java:1185) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded(HttpMethodBas e. java:967) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java :1 089) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:6 43 ) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:4 97 ) at org.apache.maven.wagon.providers.http.HttpWagon.get(HttpWagon.java:287) at org.apache.maven.wagon.providers.http.HttpWagon.getIfNewer(HttpWagon.jav a: 234) at org.apache.maven.verifier.DependencyVerifier.getRemoteArtifact((BDepend en cyVerifier.java:391) at org.apache.maven.verifier.DependencyVerifier.getDependencies(DependencyV er ifier.java:291) at org.apache.maven.verifier.DependencyVerifier.satisfyDependencies(Depende nc yVerifier.java:182) at org.apache.maven.verifier.DependencyVerifier.verify(DependencyVerifier.j av a:99) at org.apache.maven.project.Project.verifyDependencies(Project.java:569) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:663 ) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263) at org.apache.maven.cli.App.doMain(App.java:511) at org.apache.maven.cli.App.main(App.java:1258) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a: 39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Im pl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.werken.fore(Bhead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Invalid Redirect URI from: http://maven- plugins.sf.net:80/maven//copart/jars/copart-core-1.0-SNAPSHOT.jar to: http://maven-plugins.sourceforge.net/maven//copart/jars/copart-core-1.0- SNAPSHOT.jar Error retrieving artifact from [http://maven-plugins.sf.net/maven]: org.apache.maven.wagon.TransferFailedException: Failed to trasfer file: http://maven
Re: How are SNAPSHOT dependency downloads handled?
Ya, I know... they should really start working on it again. Anyways, we have been using it for months with no problems. We are using the WebApp version w/JBoss 4 Apache w/mod_jk... but that is probably overkill for what you need. You can always use javaservice (er something) to run standalone as a windows service. Google for java windows service and you will find a ton of links. --jason On Sep 23, 2005, at 12:22 PM, Mike Perham wrote: Jason, maven-proxy has not be actively developed for approximately 18 months now (at least JIRA has not been touched since then). There does not appear to be a way to start maven-proxy as a windows service. It has a webapp version (so you could run tomcat/jetty as a service) but it does not support configuration?!?! I would be a little hesitant to use maven-proxy due to these issues. mike -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED] Sent: Friday, September 23, 2005 1:29 PM To: Maven Users List Subject: RE: How are SNAPSHOT dependency downloads handled? The default config props are documented quite well. http://maven-proxy.codehaus.org Should be trivial to get the standalone version up and configured ;-) Then just use it as your single maven.repo.remote. Cheers, --jason -Original Message- From: KC Baltz [mailto:[EMAIL PROTECTED] Sent: Friday, September 23, 2005 11:22 AM To: Maven Users List Subject: RE: How are SNAPSHOT dependency downloads handled? I'll look into that. Is there a good pointer to documentation or a sample config you can get me started with? K.C. -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED] Sent: Friday, September 23, 2005 11:18 AM To: Maven Users List Subject: RE: How are SNAPSHOT dependency downloads handled? The first repository might not have the latest snapshot... though in your case it probably would. But in general all repos have to be searched for the latest. I would personally recommend setting up Maven-Proxy to handle your local repository needs as well as for your remote repositories. As if you use SNAPSHOT internally this will speed things up dramatically since only one repo needs to be checked from the client's perspective, and the proxy will cache failures from remote repos so it doesn't keep checking each remote for an artifact that does not exist. --jason -Original Message- From: KC Baltz [mailto:[EMAIL PROTECTED] Sent: Friday, September 23, 2005 11:11 AM To: Maven Users List (E-mail) Subject: How are SNAPSHOT dependency downloads handled? [Using Maven 1.1-beta-2] I'm trying to use SNAPSHOT to get the latest version of an internally developed JAR from our in-house remote repository . It appears to work (I.e. I do end up with the latest version), but not without dumping a number of errors to the screen about how it can't find my jar at maven- plugins.sourceforge.net. I have the following in my personal build.properties: maven.repo.remote=file:///export/home/kcbaltz/testRepo,http:// www.ibibli o. org/maven/,http://maven-plugins.sf.net/maven,http:// www.codeczar.com/mav en I would assume that if it found the SNAPSHOT in the testRepo repository, it wouldn't search the rest. Is that a correct assumption? The error messages are below: Attempting to download copart-core-1.0-SNAPSHOT.jar. Error getting URI host org.apache.commons.httpclient.HttpException: Redirect from host maven- plugins.sf.net to maven-plugins.sourceforge.net is not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect (HttpMeth od Base.java:1237) at org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse (Htt pM ethodBase.java:1185) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded (HttpMethodBas e. java:967) at org.apache.commons.httpclient.HttpMethodBase.execute (HttpMethodBase.java :1 089) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:6 43 ) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:4 97 ) at org.apache.maven.wagon.providers.http.HttpWagon.get(HttpWagon.java: 287) at org.apache.maven.wagon.providers.http.HttpWagon.getIfNewer (HttpWagon.jav a: 234) at org.apache.maven.verifier.DependencyVerifier.getRemoteArtifact ((BDepend en cyVerifier.java:391) at org.apache.maven.verifier.DependencyVerifier.getDependencies (DependencyV er ifier.java:291) at org.apache.maven.verifier.DependencyVerifier.satisfyDependencies (Depende nc yVerifier.java:182) at org.apache.maven.verifier.DependencyVerifier.verify (DependencyVerifier.j av a:99) at org.apache.maven.project.Project.verifyDependencies(Project.java:569
RE: external dependencies for maven2
Why don't you add these files to a local shared repository, and then
renaming them to the required spec for maven to pick them up? Anf then
just use a file:${basedir}/repository or something before your global
shared repo?
--jason
-Original Message-
From: Rizwan Merchant [mailto:[EMAIL PROTECTED]
Sent: Friday, August 05, 2005 11:10 AM
To: Maven Users List
Subject: external dependencies for maven2
Hi,
I have some external jar files that do not follow the naming
conventions
desired by maven2. take for example a jar file called hapi.jar
These files are also not part of the maven repository. When I try to
compile
using maven2, I want maven to be able to see these jar files
somewhere.
How
do I do this? where do i store the jar files and how do I define the
dependency in the pom.xml file?
thanks,
-Riz.
-
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]
SQL/DDL report plugin?
Does anyone know of any SQL/DDL report plugin that will take a .sql with create statements and render a nice image suitable for displaying in a project's generated website? Or if not a plugin, anything javaish that could take some sql and render it? --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to expose expose a Java TagLibrary
Thanks for the response. I think I found the solution I was looking
for... after browsing through the define taglib sources:
Use define:bean, as in:
define:taglib uri=myplugin
define:tag name=dependency-handle/
define:bean name=mytag className=com.foo.MyTag/
define:bean name=myparenttag className=com.foo.MyParentTag/
/define:taglib
Then override MyTag's findAncestorWithClass() as:
snip
protected Tag findAncestorWithClass(Class type) {
// First try the default
Tag tag = super.findAncestorWithClass(type);
if (tag == null) {
// Then try looking for a DynamicBeanTag
tag = findDynamicBeanAncestorWithClass(getParent(), type);
}
return tag;
}
protected Tag findDynamicBeanAncestorWithClass(Tag parent, Class type) {
if (parent == null) {
return null;
}
if (parent instanceof DynamicBeanTag) {
DynamicBeanTag tag = (DynamicBeanTag)parent;
Object bean = tag.getBean();
if (type.isAssignableFrom(type)) {
return (Tag)bean;
}
}
return findDynamicBeanAncestorWithClass(parent.getParent(), type);
}
/snip
This will unwrap the DynamicBeanTag and allow MyTag to behave as
excepted when looking for an ancestor tag.
With this combination, I can from an external project do something like:
project xmlns:myplugin=myplugin
myplugin:myparenttag
!-- can talk to myparenttag via findAncestorWithClass() --
myplugin:mytag/
/myplugin:myparenttag
/project
Cheers,
--jason
===
This email and any attachment(s) thereto, are intended for the use of
the addressee(s) name herein and may contain legally privileged and or
confidential information under applicable law. If you are not the
intended recipient of this e-mail, you are hereby notified any
dissemination, distribution or copying of this email, and any attachment(s)
thereto, is strictly prohibited. If you have received this communication
in error, please notify the sender at 415-281-2200 or via return e-mail at
[EMAIL PROTECTED] and permanently delete the original copy and
any copy of any e-mail, and any printout thereof. Thank you for your
cooperation.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
How to expose expose a Java TagLibrary
Hi, I'm trying to figure out how to expose a Java TagLibrary from a plugin. Inside of my plugin, I can create a: define:taglib uri=myplugin define:tag name=dependency-handle /define:tag /define:taglib And I can access this taglib just fine from another project. Similarly in my plugin, I can define: project xmlns:local=jelly:com.whatever.jelly.MyTagLibrary local:sometag/ /project And I can now access the Java TagLibrary MyTagLibrary from inside the plugin. But, what I am trying to do is to create a plugin which provides a set of tags for use in other projects. How can I expose a Java TagLibrary as if it were a define:taglib inside of my plugin.jelly? I tried using define:jellybean, define:bean with no luck. While I was able to get the tag to attach to the taglib, it did not allow the tags to properly find their parent via findAncestorWithClass(). So far the only luck I have had with exposing Java TagLibraries externally is to have the plugin nest the tags inside of a dynamic tag created. Is this even possible with Maven 1.0.2? If so, could someone explain how I can do this. Thanks, --jason === This email and any attachment(s) thereto, are intended for the use of the addressee(s) name herein and may contain legally privileged and or confidential information under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email, and any attachment(s) thereto, is strictly prohibited. If you have received this communication in error, please notify the sender at 415-281-2200 or via return e-mail at [EMAIL PROTECTED] and permanently delete the original copy and any copy of any e-mail, and any printout thereof. Thank you for your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [REQUEST] Upload Lang 2.0 to ibiblio
I take it back, it is the SNAPSHOT which is still referring to the old version. Can we update the SNAPSHOT plz? --jason On Wednesday, September 3, 2003, at 04:02 PM, Jason Dillon wrote: Does it take time for http://ibiblio.org/maven/commons-lang/jars/ to update? Still looks like the previous version is there. --jason On Wednesday, September 3, 2003, at 09:52 AM, [EMAIL PROTECTED] wrote: Done. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Henri Yandell [EMAIL PROTECTED] wrote on 03/09/2003 12:33:45 PM: Could someone upload Lang 2.0 to ibiblio? [or copy it from the ibiblio mirror :) ] http://jakarta.apache.org/commons/lang.html Thanks, Hen - 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: [REQUEST] Upload Lang 2.0 to ibiblio
Does it take time for http://ibiblio.org/maven/commons-lang/jars/ to update? Still looks like the previous version is there. --jason On Wednesday, September 3, 2003, at 09:52 AM, [EMAIL PROTECTED] wrote: Done. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Henri Yandell [EMAIL PROTECTED] wrote on 03/09/2003 12:33:45 PM: Could someone upload Lang 2.0 to ibiblio? [or copy it from the ibiblio mirror :) ] http://jakarta.apache.org/commons/lang.html Thanks, Hen - 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: Distinguishing between runtime and compile time dependencies
You can specify properties for the dependency to indicate if it is
runtime or not, then use that information to collect your runtime
dependencies.
Example:
dependency
idcommons-logging/id
version1.0.3/version
urlhttp://jakarta.apache.org/commons/logging/url
properties
runtimetrue/runtime
/properties
/dependency
* * *
j:forEach var=artifact items=${pom.artifacts}
j:set var=dependency value=${artifact.dependency}/
j:if test=${dependency.getProperty('runtime') == 'true'}
ant:echoProcessing dependency: ${dependency.id}/ant:echo
ant:mkdir dir=${aggregate.dir}/lib/
ant:copy todir=${aggregate.dir}/lib
file=${artifact.path}/
/j:if
/j:forEach
--jason
On Wednesday, September 3, 2003, at 09:57 PM, Jason van Zyl wrote:
On Wed, 2003-09-03 at 10:07, Berin Loritsch wrote:
Is there a magic flag to identify a runtime dependency from a compile
time dependency? For example, Xerces and Xalan may be needed to
compile
some aspects of a project (some people use it to generate java source
code), but never needed at run time.
There is no facility yet. But we've talked about it for a long time and
we do have working code for it in experimental versions of Maven but
the
real crux of the problem is collecting POMs in the repositories so we
can build the necessary graphs. In this way you would only have to
state
the compile time dependencies and the runtime dependencies would be
calculated.
Not something that is going to make it into 1.0.
This will allow a number of things:
* The extensions attributes can be generated ONLY for runtime
dependencies
* The GUMP descriptor will be able to reflect that information so that
the other GUMP descriptors can propogate those dependencies for
unit tests
* I can develop my plugin to gather the dependencies into a
distributable
I personally have a need to generate a work directory like this:
/${root}
loader.jar
/lib
***.jar
/docs
***.html
***.pdf
The thing is that I want to be able to collect all of the runtime
dependencies for this special distribution format and place them in
the
lib directory. Currently, the best I can do is grab *all* the
dependencies,
regardless of runtime or compile time.
Are you trying to assemble a container runtime?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
-
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: How to depend on JavaCC?
Can we get the latest installed on ibiblio with the proper layout for dependencies? --jason On Monday, August 18, 2003, at 01:24 AM, Incze Lajos wrote: But I will still place a properly named artifact in there. Is that version 2.1 ? I think so. The 3.x series is named differently (see https://javacc.dev.java.net/servlets/ProjectDocumentList). incze - 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]
Reloading maven plugins at runtime?
Do you know if it is possible to reload maven plugins at runtime? Specifically, after invoking the plugin:install goal, can I tell maven to refresh so that I can use the new plugin (goals, tags, whatever) in the same build? --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to depend on JavaCC?
It appears that the artifact on ibiblio is named JavaCC.zip, missing version information... :-( Is there any way to get around this? Or is there a preferred method in maven to use JavaCC? --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: finding if a goal is available
Looks like you could use:
${pom.getMaven().getPluginManager().isLoaded('someplugin')}
--jason
On Saturday, August 16, 2003, at 02:53 PM, Andy Jefferson wrote:
On Friday 15 Aug 2003 15:44, Simon Matic Langford wrote:
is there anyway to find if a goal is available?
ie, I have some custom plugins, so I want to check to see if they're
installed before trying to register them.
Try
maven -g
This should list all goals (in plugin order) ... and then you can
search for
the ones you expect.
--
Andy
-
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]
project.xml is a jelly script?
Hello, the website says that project.xml form, is now processed as a Jelly script (http://maven.apache.org/reference/user-guide.html#POM%20Interpolation ) but it does not appear to be having like it is a jelly script at all. Is the user guide not valid? Is there a special property to enable this? I have looked over the source and it does not appear that any jelly fluff is done to the project.xml file. IMO I think that it would be very beneficial if it was a jelly script so that Maven in general is more flexible. I understand not wanting to put much logic into the project.xml, but it would make management of large projects much easier. Specifically I was looking for a way to define common dependencies for a large project (Apache Geronimo) so I could better manage version numbers of the dependencies. I did not wish to put all of the depends into a parent project as that would force each child project to have additional dependencies on its classpath which might not be a good thing, nor do I want each and every module to try to download SNAPSHOTS, especially if they do not even need that depend. So I thought about using properties like 'dependency.commons-logger.version=1.0.3' and then specify the property as the content for version/, which works fine if the property is defined in the child modules project.properties, or if the property is in the parent and the child is always invoked through the reactor. This is not the case with Geronimo, so this method fails. James and I were chatting about this a tad... I was under the impression that I could use jelly in project.xml (drawn conclusion from web page and some bad tests I made). He suggested using x:parse xml=../../dependencies.xml/ and then selecting out dependencies by name and then copying them into the project.xml. I think this would be very useful and shows where project.xml as a jelly script would be desirable. I think this is a good idea, but wanted to hear what you guys have to say. Also I was talking to James about the problem of versioning dependencies in general and how it would make sense if Maven supported more symbolic names (similar to SNAPSHOT) but which could point to the latest stable release. It probably makes sense to provide some sort of version alias mechanism, as it becomes problematic to effectively maintain version numbers in a large project. Take Maven for example, there are a few plugins which use different yet compatible versions of dependencies, which only results in additional overhead. If all plugins are compatible with a specific version, then it would make sense for them to all use that version. Anyways I have been up for way too long, it was light when I woke up and it is light again, so I am gonna crash now. Cheers, --jason
Any way to disable dependency checking?
Is there any way to disable dependency checking? Say a property or some flag that could be se internally? I am asking because it appears that a reactor build will fail on cleaning targets. Say that you have a project with two modules, a and b. If a depends on b, then when cleaning the project using the reactor to descend to children for cleaning, it will fail if a has not yet installed its output jar to the repository. Also a side note, it looks like maven:reactor excludes=a/*, b/* ... / will not do the right thing due to the space after the ','... perhaps includes behaves the same, I have not checked. --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
