Alan Gutierrez schrieb: > Related question: > > In most of my projects I create command line tools. To get them up and > running quickly, I use Ant and all the classpath configuration that is > already defined in my build.xml. > > I've seen that you're supposed to use Profiles to switch out plugin > configurations, so I could use different profiles to change my antrun > tasks, effectively creating targets. > > But, is that the best practice? I assume that there are one of three > choices. (Because, I explored making Maven switchable without writing > plugins, and was told that profiles where it.) > > 1) Use profiles - Seemingly verbose. Does not feel as though I'm using > it as the authors intended. If my program is only tangentially part of > the build process, like a program that updates a database schema, it > seems like it should be it's own program with it's own documentation, > not a by product or variation of the build. > > 2) Keep a parallel build.xml - If I can execute the tasks using the > ant plugin, then it might not be the duplication that it appears to > be. Is there a way to inherit or export the classpath configurations > in Maven? (Similarly, part of the build, but people have grown > accustomed to supplemental Ant tasks that perform non-build tasks. > Maven conventions make supplemental actions unconventional.) > > 3) Define some standard shell script / batch file pair that > understands the Maven repository layout - Or perhaps one that conforms > to some best practice for distributing a shell script / batch file > launcher pair, the way Groovy and Ant do. > > Assume that I want to write Java command line programs to aid my > development by munging log files and the like, things that don't > belong in a web interface. == re maven and ant integration
The maven-antrun-plugin documents how to access maven classpath data. <quote> You can use these classpath references * maven.compile.classpath * maven.runtime.classpath * maven.test.classpath * maven.plugin.classpath </quote> Of course that requires that you run maven in order for it to compute these, then execute ant as a sub-process. There exists a "maven ant tasks" project that provides ant tasks that can understand a pom file, allowing ant to be run directly from the commandline and still access the data from the pom: http://maven.apache.org/ant-tasks.html It would be really nice to have this functionality from a real programming language (I'm no great fan of Ant). Maybe Groovy's Ant integration would allow access to the maven ant tasks? It does initially seem a little indirect (groovy->ant->maven) but could be worth a try.. See: http://www.ibm.com/developerworks/java/library/j-pg12144.html == re best practice The following is just my non-expert opinion. Comments/counter-arguments welcome. Ant is a procedural programming language, like a shell-scripting language, that happens to have a bunch of built-in functions that are useful for building java code, manipulating the filesystem, etc. It's a swiss-army-knife type thing that does many things. But the result of this flexibility is that (a) there are many ways to achieve the same end result (confusing) (b) it's impossible to separate "build" from "system management" type steps. Maven is based around a "project model" and a build lifecycle. As a result it is *not* a programming language, and therefore there are many things it cannot be made to do. But plugins can use the project model and lifecycle information in ways that ant tasks just cannot. And it takes only a little effort to make builds repeatable. So I would recommend keeping maven for build tasks, and doing all the other stuff that is, as you say, "only tangentially part of the build process" separate, eg shell-script, perl, or ant. If it isn't part of a build lifecycle, then shoe-horning it into Maven will always be awkward. This thread started with someone asking how to set up maven to effectively act like ant runSomeArbitraryProcessing and I think this is exactly the sort of thing that should NOT be pushed into a pom file. There is no reason why everything needs to be done via Maven. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
