RE: maven 3 inheritance
No, with maven 2 you cannot have a variable in the parent version. The string will be interpreted literally without dereferencing the variable name. Similarly, you can't have an empty version number: the parent MUST have a defined version number and it MUST be absolute and not contain any variables. variables work fine in any other version number, however. ranges, on the other hand, do not ;) Dana Lacoste -Original Message- From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com] On Behalf Of Paul Benedict Sent: Tuesday, December 08, 2009 4:37 PM To: Maven Users List Subject: Re: maven 3 inheritance ...and parent versions? Good question. You'll have to find out if the project hierarchy or dependency resolution is processed first. Report back and tell us! Paul - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: How can I execute plugin X, then plugin Y, then plugin X again ?
I can confirm this: If you specify one phase for two different actions, you do NOT have ANY control over when they will execute. If you want to manipulate the order of operations, set the phase values to successive entries from the lifecycle. http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html Dana Lacoste -Original Message- From: Nick Stolwijk [mailto:nick.stolw...@gmail.com] Sent: Tuesday, November 10, 2009 9:59 AM To: Maven Users List Subject: Re: How can I execute plugin X, then plugin Y, then plugin X again ? I don't think this is a bug, if you execute mvn help:effective-pom you will see the two plugin configurations merged. I think your best bet is to set the second execution to a phase later in the chain. Often, this also means you are trying to do to much in one module. Hth, Nick Stolwijk ~Java Developer~ IPROFS BV. Claus Sluterweg 125 2012 WS Haarlem http://www.iprofs.nl On Tue, Nov 10, 2009 at 6:51 PM, Paul Benedict pbened...@apache.org wrote: This is probably a bug since the order of plugins should be respected. Have you checked the ticket list of 2.2.2 or 3.0-alpha-3 to see if it is already fixed? And are you running 2.2.1? Paul On Tue, Nov 10, 2009 at 11:48 AM, boraldo bora...@hotbox.ru wrote: Suppose I have to execute some actions after some phase. These actions are made plugins X and Y. 1st action - executed by plugin X 2nd action - executed by plugin Y 3rd action - executed by plugin X I wrote the following pom: build plugins plugin artifactIdplugin-x/artifactId executions execution idstep-1-x/id phaseinitialize/phase goals goalgoal-x-1/goal /goals /execution /executions /plugin plugin artifactIdplugin-y/artifactId executions execution idstep-2-y/id phaseinitialize/phase goals goalgoal-y-1/goal /goals /execution /executions /plugin plugin artifactIdplugin-x/artifactId executions execution idstep-3-x/id phaseinitialize/phase goals goalgoal-x-2/goal /goals /execution /executions /plugin /plugins /build I executed: mvn initialize But the sequence of executions was wrong: 1. step-1-x 2. step-3-x 3. step-2-y This means that each plugin executes all its executions, then the next plugin starts to work. Can I corrupt such scenario ? -- View this message in context: http://old.nabble.com/How-can-I-execute-plugin-X%2C-then-plugin-Y%2C-then-plugin-X-again---tp26287350p26287350.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: order of builds in assembly plugin
Sure! two separate executions in the assembly plugin, put the configuration for each in one of the execution stanzas, and put each with a separate phase. Read http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html for more info on what phases are available, but as long as they are after your other work (compile/test I presume) then you can do them sequentially (for example, you could do phasepackage/phase for the second one and phaseprepare-package/phase for the first one.) It's not normal maven behavior, and splitting into separate modules frequently makes sense, but I do this in more than one place in my project. Note that you're bypassing Maven's dependency scheme by doing this, though. You're accessing the files directly rather than using the dependency conventions. Dana Lacoste -Original Message- From: Radim Kolar [mailto:h...@sendmail.cz] Sent: Wednesday, October 21, 2009 3:52 PM To: users@maven.apache.org Subject: order of builds in assembly plugin is there way to change order of builds in assembly plugin? i need to build jar-with-dependencies first, descriptor zip.xml second (depends on jar-with-deps). plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-assembly-plugin/artifactId configuration descriptorRefs descriptorRefjar-with-dependencies/descriptorRef /descriptorRefs descriptors descriptorzip.xml/descriptor /descriptors archive manifest mainClassdmachine/mainClass /manifest /archive /configuration executions execution idmake-assembly/id phasepackage/phase goals goalsingle/goal goaldirectory-inline/goal /goals /execution /executions /plugin -- View this message in context: http://www.nabble.com/order-of-builds-in-assembly-plugin-tp26001508p26001508.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Hosting a local repo w/out a Repo Manager?
My thoughts (we were doing something similar) 1 - Don't copy the local repo. Use the maven deploy step to deploy to a local location (file: URL), and share _that_. 2 - Once you've done this for a while, you'll use a repository manager :) Dana Lacoste -Original Message- From: Rob Slifka [mailto:r...@tintri.com] Sent: Friday, October 16, 2009 11:16 AM To: Maven Users List Subject: Hosting a local repo w/out a Repo Manager? Hi all, I'm working on wrapping my head around setting up an internal blessed repository and being assured that Maven will fail when a dependency is not found there. (1) Clear my local repo. (2) Run Maven through our lifecycle (clean, compile, package, test, etc.). (3) Take the contents of my now-populated local repo and copy them up to a shared location. Now I'm not sure what to do next. I've tried overriding both the central repo and plugin repo with my local repo in our POMs, however this consistently seems to ignore plugins that are found in my internal repo (i.e. claim they aren't there when they are). It also attempts to check for updates to plugins that aren't -SNAPSHOT versions and I'm not sure quite why. Given the trouble I'm having, I'm pretty sure I'm way off the reservation here with what and how I'm doing this. Looking inside the repo, there are central XML files that Maven is probably surprised to find inside the local repo? I'm not terribly interested in adding another piece of software to our build environment, hence my avoidance of a Repository Manager. We have a very small number of dependencies outside of our project. Maven's own dependencies dwarf ours :) Any tips are much appreciated, thanks! Rob - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Hosting a local repo w/out a Repo Manager?
I'm using artifactory to do this and do it with two sets of virtual repositories. One is used to download anything, the other is used for only blessed builds. I haven't used Nexus, but I'm sure there's something similar: basically it would mean that you have one set of settings.xml configuration for your blessed build machine, and another set for those who need internet access. Dana Lacoste -Original Message- From: Rob Slifka [mailto:r...@tintri.com] Sent: Friday, October 16, 2009 4:15 PM To: Maven Users List Subject: Re: Hosting a local repo w/out a Repo Manager? Hi everyone, Nexus went in and is working without a hitch! I'm proxying everything through the single /public group and it's working well. The only question I have now is how to lock down the proxying behaviour, with respect to the workflow I mentioned previously. Everyone points to /public although it's proxying for live, remote repos. I'd like Maven to error when something isn't found in the public repo, rather than proxy through Nexus and download a new dependency we haven't blessed. Do I just remove all repositories from the search list of the public group? Rob - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Pom Parent Version Properties
This came up not three weeks ago. What most of us do to get around this is to use something else to modify the pom.xml content before running maven. Personally, I use ant and xmltask. Why is it happening in an 'official' pom? Because almost EVERY user has a problem with this and we're all suffering, so I'm not surprised that someone 'official' ran into it as well. So I can see at least two possibilities: 1 - maven really IS expanding properties in the parent, for some version of maven as used by the derby developers 2 - the unmodified pom got published with derby, rather than the one that had been modified before maven was run. Either way, in my opinion it's definitely the single most annoying thing with maven: the version field is interpreted in different ways for every instance (sometimes it allows variables, sometimes it doesn't: sometimes it allows ranges, sometimes it doesn't, etc.) Dana Lacoste -Original Message- From: Albert Kurucz [mailto:albert.kur...@gmail.com] Sent: Thursday, September 24, 2009 9:58 AM To: Maven Users List Subject: Re: Pom Parent Version Properties Is property substitution really forbidden in /project/parent/(groupId|artifactId|version)? If yes, how is it possible to see that on this Maven Central project? http://repo2.maven.org/maven2/org/apache/derby/derby/10.5.3.0/derby-10.5.3.0.pom Is property substitution really forbidden in /project/(groupId|artifactId|version)? If yes, how is it possible to see that on this Maven Central project? http://repo2.maven.org/maven2/org/apache/derby/derby-project/10.5.3.0/derby-project-10.5.3.0.pom Project's POM files may not getting verified for this criteria by the maintainer of Maven Central? Too bad!
Question about version ranges
I'm using 2.0.10 in this instance.
I am breaking down my monolithic gigantic build into sub-components, so that I
can build client separate from server, for example.
For SNAPSHOTs this is working (well, actually, it isn't, but that's another
story :) ) but for RELEASE builds, I'm getting this:
Couldn't find a version in [7.11.093, 7.11.094] to match range [7.11,7.12)
So I have a parent pom defining my version-range to be [7.11,7.12) for this
case (this is version 7.11, so I want the latest 7.11 build only.)
If 7.11.093 is considered newer than 7.11 (according to the docs where any
modifier is considered newer than the base) then why doesn't this work?
Note that I changed it to be [7.11.000,7.12.000) and it worked fine, but that
seems like it shouldn't be necessary somehow: in that case if you ever released
1.0 and then had to do an emergency patch 1.0.1 (not 1.1, because 1.1 is being
developed for future stuff: 1.0.1 is just an emergency patch) then it wouldn't
get picked up by the maven version range properly :(
Similarly, the maven-dependency-plugin doesn't seem to support ranges specified
in this way. If you put a version tag in the dependency plugin then it
doesn't work with ranges, and if you put a dependency section in your pom
(and remove the version tag from the dependency-plugin part of the build)
then it puts a null in for the version of your artifact. I'm getting around
this by using an assembly to extract my dependency instead of the
dependency-plugin, but that just seems silly:
why can't maven handle its own version ranges
Dana Lacoste
Examples:
Sample Range that didn't find 7.11.093 :
property defined: RELEASE_VERSION_RANGE as '[7.11,712)'
Sample Range that DID find 7.11.093 :
property defined: RELEASE_VERSION_RANGE as '[7.11.000,712.000)'
pom dependency section for above:
dependency
groupIdpackage.server/groupId
artifactIdserver-distribution/artifactId
version${RELEASE_VERSION_RANGE}/version
/dependency
Sample Maven dependency-plugin section that didn't seem to work with above in
any way shape or form:
plugin
artifactIdmaven-dependency-plugin/artifactId
executions
execution
idUnpackServer/id
phaseprocess-resources/phase
goals
goalunpack/goal
/goals
configuration
artifactItems
artifactItem
groupIdpackage.server/groupId
artifactIdserver-distribution/artifactId
classifierbin/classifier
!-- version${RELEASE_VERSION_RANGE} /version --
typezip/type
/artifactItem
/artifactItems
outputDirectory
${project.build.directory}/server/
/outputDirectory
/configuration
/execution
/plugin
RE: Question about version ranges
OK, well, I figured PART of it out: using unpack-dependencies instead of unpack
allowed me to use the pom's own dependency mechanism instead of having the
dependency-plugin try to obtain the dependency itself (so the range part worked)
But that doesn't explain why ranges don't work with unpack, or why unpack and
unpack-dependencies both exist
Dana Lacoste
-Original Message-
From: Lacoste, Dana (TSG Software San Diego)
Sent: Thursday, September 10, 2009 3:29 PM
To: Maven Users List
Subject: Question about version ranges
I'm using 2.0.10 in this instance.
I am breaking down my monolithic gigantic build into sub-components, so that I
can build client separate from server, for example.
For SNAPSHOTs this is working (well, actually, it isn't, but that's another
story :) ) but for RELEASE builds, I'm getting this:
Couldn't find a version in [7.11.093, 7.11.094] to match range [7.11,7.12)
So I have a parent pom defining my version-range to be [7.11,7.12) for this
case (this is version 7.11, so I want the latest 7.11 build only.)
If 7.11.093 is considered newer than 7.11 (according to the docs where any
modifier is considered newer than the base) then why doesn't this work?
Note that I changed it to be [7.11.000,7.12.000) and it worked fine, but that
seems like it shouldn't be necessary somehow: in that case if you ever released
1.0 and then had to do an emergency patch 1.0.1 (not 1.1, because 1.1 is being
developed for future stuff: 1.0.1 is just an emergency patch) then it wouldn't
get picked up by the maven version range properly :(
Similarly, the maven-dependency-plugin doesn't seem to support ranges specified
in this way. If you put a version tag in the dependency plugin then it
doesn't work with ranges, and if you put a dependency section in your pom
(and remove the version tag from the dependency-plugin part of the build)
then it puts a null in for the version of your artifact. I'm getting around
this by using an assembly to extract my dependency instead of the
dependency-plugin, but that just seems silly:
why can't maven handle its own version ranges
Dana Lacoste
Examples:
Sample Range that didn't find 7.11.093 :
property defined: RELEASE_VERSION_RANGE as '[7.11,712)'
Sample Range that DID find 7.11.093 :
property defined: RELEASE_VERSION_RANGE as '[7.11.000,712.000)'
pom dependency section for above:
dependency
groupIdpackage.server/groupId
artifactIdserver-distribution/artifactId
version${RELEASE_VERSION_RANGE}/version
/dependency
Sample Maven dependency-plugin section that didn't seem to work with above in
any way shape or form:
plugin
artifactIdmaven-dependency-plugin/artifactId
executions
execution
idUnpackServer/id
phaseprocess-resources/phase
goals
goalunpack/goal
/goals
configuration
artifactItems
artifactItem
groupIdpackage.server/groupId
artifactIdserver-distribution/artifactId
classifierbin/classifier
!-- version${RELEASE_VERSION_RANGE} /version --
typezip/type
/artifactItem
/artifactItems
outputDirectory
${project.build.directory}/server/
/outputDirectory
/configuration
/execution
/plugin
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: inject version into source?
So, basically, you use a wrapper to get around maven? I do something similar: I use a .properties file, then run an xmltask ant script to update the maven pom.xml files. Very predictable, very manageable, and bypasses the maven-release-plugin which caused ALL KINDS of headaches because it doesn't work with perforce properly. James, that'd be my recommendation: update the maven info to fit your build before you run maven :) Dana Lacoste -Original Message- From: David C. Hicks [mailto:dhi...@i-hicks.org] Sent: Friday, August 28, 2009 11:01 AM To: Maven Users List Subject: Re: inject version into source? I have done this by setting up a properties file that gets filtered at build time. Then, I use that properties file in a Spring PlaceholderConfigurer to get the value injected where I need it. James Russo wrote: Hello, New maven user here. Really am liking it, just trying to get project back online and running after switching from ant.. Is there any standard maven way to inject maven variables (like version) into source code, prior to compile? Is this maybe were I should just leverage my existing any scripts to accomplish the task? thanks, -jr - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Order of executing plugins changed in 2.0.9 ?
But when you define an execution, you define what stage of the lifecycle it would be edited. For example, I might use antrun to get something in generate-resources, and then compile, and then use another antrun to package. there's no issue doing this in one declaration of the plugin. Contrarily, there IS an issue with declaring plugins multiply: the dependencies required for the plugin (if any) might differ in the two declarations and get mixed up (maven only instantiates a plugin once per run: it will lose the dependency information from the second call if the first one has a different dependency list.) I know this first hand: I was using jakarta-regexp (ant task) with antrun to do something in an antrun declared in a profile, and using antrun separately in the pom. the dual declarations caused a huge headache trying to figure out why it didn't work! The moral of the story is: The maven way is One plugin declaration, multiple executions Dana Lacoste -Original Message- From: Thierry Lach [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 16, 2008 2:11 PM To: Maven Users List Subject: Re: Order of executing plugins changed in 2.0.9 ? One reason might be to run something else between the two? On Wed, Apr 16, 2008 at 4:43 PM, Brian E. Fox [EMAIL PROTECTED] wrote: Why would you declare the plugin twice in the same pom? Just put multiple executions in the same definition. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple CPUs
The situation below (deploying to multiple J2EE platforms in the build) is already easily supported: you're using ant to do it, and ant supports a parallel section http://ant.apache.org/manual/CoreTasks/parallel.html So, inside a maven-antrun-plugin section you can do a parallel with no hesitation. The main issue, though, gets back to one of The Maven Way Maven was designed with a very heavy emphasis on the right way to do things, and with most projects (breaking into modules, providing single-file artifact build results, assumed src/java layout, etc.) the only parallel part that could really work would be when compiling the classes from the **/*java files. This would theoretically result in quicker java compiling, but I question if the result would be a significant gain, unless you had a SERIOUSLY large number of classes in that jar! And with a 6 minute build, you really don't :) For NON-JAVA src files, you can turn on the make flags appropriately already (in other words, if maven isn't doing the build, it's just calling ant to call make or something, then you can get the make command to parallelize) (I remember an old comparison of gcc vs. kylix in this area: gcc benefits from the make -j to such a large extent because it's really horrible at building each file: kylix, with Pascal's simpler compile rules, was so much faster they weren't even in the same league!) But that's really just the way it is : there's no real way that maven can parallelize things without causing a lot of issues. Threading output of the build, handling build failures, ensuring dependency order: it would add a LOT of complexity to the build with not a lot of benefit. And, just for the record, my maven project has 100 (wow, 100 exactly. hadn't counted before) modules and a full build of EVERYTHING takes about 330 minutes on my fastest build machine: if there was a way that I could speed this up I would GLADLY do so, but there really isn't : any speedup that's caused by a change in how maven works would result in serious usability and stability issues that would NOT be worth it, IMNSHO. Dana Lacoste -Original Message (Trimmed for content)- From: Jorg Heymans [mailto:[EMAIL PROTECTED] Sent: Thursday, April 10, 2008 8:36 AM To: Maven Users List Subject: Re: Multiple CPUs well imagine that during your integration build you have to deploy 10 EARs, and each of them to a number of application servers (weblogic, websphere etc etc). That adds up pretty quick. I don't know the effort involved, but if the ant runner for example could be made to run in a different thread for each invocation that could speed things up drastically only for this use case. Jorg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple CPUs
That's an interesting build you have there, care to tell us what the longest running tasks are (hope it's not the compiling :-P) In short, it's Compare new dataset vs. old dataset It takes a very long time because it has to take the newly built binaries and data, get them up and running (the DB load takes a while!) and then compare the new set to the old set for upgrade purposes. It's not really the area I'm working on, so I can't comment as to why it takes so long, but it's pretty much 100% outside Maven so there's not much Maven could do to speed it up :) Of the 100 Modules, only two take more than 10 minutes to mvn install : this one and the cross-platform build (maven triggers ant which triggers remote builds on multiple platforms.) so the time per module is very small (and 99.9% of our builds are isolated to a single module or family of modules) and only intermittent FULL builds take such a long time. Dana Lacoste - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple CPUs
Not sure if i agree here. Why can the building of different artifacts not be parallelized if they completely don't depend on each other? If my build contains 1 war and 5 completely independent jars that are used in the war, why can those 5 jar artifacts not be built in parallel ? Sure enough, they can have shared dependencies, but with a good artifact download manager it should be trivial to detect downloads in progress. Is there another way how completely independent artifacts can influence each other, or am i missing something ? Why can't constructing an artifact be made an atomic task provided it has all required input available ? It's that last line that I'll leave to the Maven people (I'm a user, I might even be a power user, but I'm also a perforce administrator, and the complete lack of atomicity in Maven has always bugged me :) (and Maven:SCM plugin for perforce makes me shudder :) Nigel's comment on the repo not being threadsafe is the only other thing I can think to add at the moment. - threading the build output shouldn't be hard, especially if maven were to become less verbose. I would be really OK with just reading building module ABC OK building module DEF OK etc etc I have -e turned on in Cruise Control because I find the maven error messages far too difficult to decipher without more information. We currently have a workaround preventing the threaded output you describe from our cross platform build: I can't tell (for example) if that line came from Linux or Solaris (if they're parallel building the same code at the same time, but on different systems.) So we do the builds parallel then dump the output sequentially. Ugly, Ugly, Ugly, but I don't see any way to do threaded output the way Maven works now. - I don't see how handling a build failure would cause problems here, if an artifact fails to build then the build just stops after the completion of those tasks that ran parallel to the failed task. Heck, in that way you could even see multiple artifact failures in one build, great ! Sometimes you want --fail-at-end, sometimes you don't! :) With maven parallel, you'd have it always. I can't really express why, but that bugs me for some reason :) - The dependency order should not fundamentally change with parallel artifact builds, or did you have a specific case in mind here ? In our current system (where our parallel builds are done with multiple OS combinations) we can have this: Artifact A (Solaris) depends on jar A, B, and C (all -SNAPSHOT, so they're downloaded and updated with every build) Artifact A (Linux) has same dependencies. building in parallel causes both to download at the same time and install into the same location (NFS mounted home dir) which causes the issues Nigel mentioned (the repository is NOT threadsafe) I don't know how to make this work better, but with -SNAPSHOT in particular it causes huge headaches if you're not paying attention :) Dana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Question about download.meter and maven2
OK, from the archives, I can run mvn with -Dmaven.download.meter=bootstrap (for example) and I won't get the Downloading 1/123k updating to 2/123k etc. But this doesn't appear to work in maven2 This causes issues because I'm running in a scripted environment (Cruise Control) on multiple platforms at once, and it ends up displaying the following in the log file: 1/123K2/123K3/123K4/123K etc. It's very long. One of the artifacts it's downloading is several megabytes in size and the log file ends up being several paragraphs of download notifications. I can see in maven-core/src/main/java/org/apache/maven/cli/ConsoleDownloadMonitor.java the transferProgress function call that's printing out the offensive messages, but I can't figure out (I don't know how maven's plugin hierarchy works well enough) how to disable it, short of editing the maven source myself and removing that one line. I don't want to run mvn -q because I really DO want all the other output, I just don't want that one KIND of output, much like worked in maven 1. Can anyone provide any suggestions? Googling hasn't helped (yet!) Thanks, Dana Lacoste - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Question about download.meter and maven2
Thanks! I can see why I missed it: batch just plain wasn't one of my search terms :) Dana Lacoste -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Thursday, April 03, 2008 1:43 PM To: Maven Users List Subject: RE: Question about download.meter and maven2 Use the -B option to put maven in batch mode and you won't get the download output. It will also tell plugins not to prompt you for input...if you are running from the CI system this is what you want. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
