Re: Simple properties question...
I faced similar fustrations, so created a wiki page to document findings. http://wiki.codehaus.org/maven/WritingMavenXml Perhaps you could add to this ;-) Stephen From: Brian Topping [EMAIL PROTECTED] Q1: Is there some hidden cache of knowledge that I could have learned that from? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Can not generate 'Developer activity report'
Hello, When I generate the site using maven,all the data in the reports are generated except the data in the developer activity report. Do I need to add something else in the project.xml ? Thank you. Ranjan [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simple properties question...
Incze Lajos wrote: In the long run and in the new Maven code I won't be promoting Jelly for plugins at all, but will be promoting the use of beanshell. I'm sure XML programming will remain wildly popular and if that is the case I will be reimplementing Jelly taking it down to the bare metal with xpp3 and using OGNL for expressions. I am no longer a fan of Jelly. I know people seem to love XML programming but I think it's the single biggest mistake I've made with Maven and it has cost us all dearly. I won't be making any similiar mistakes in the future. I would consider using groovy in the long run. It is a real scripting language has all the structures (designed in) that were important in jelly scripting (ant builder, xml builder, can emit xml sax events, etc.) has excellent structures which could be important in workflows (closures are, in fact, 1st class object code snippets that could be called on worflow stages), can be interpreted AND compiled to bytecode, the same way easy bean integration as in the jelly scripting, etc. And last but not least: the syntax is not XML, but real programming language with pretty good collection interfaces (which seems to be one of the most important factors in project builders). Seemingly, the current codebase can be 'mechanically' transported from jelly to groovy. I agree that Jelly is a bit rough and that Groovy looks awesome. I've used Beanshell a bit, and it's OK, but something just seems to be missing. Jason, do you have any thoughts on using something like BSF for the plugins? That way, if I'm understanding things correctly, the actual plugin implementations could be written in a scripting language of choice. But, maybe that would just cause more headaches. The important part seems to be making the POM data accessible in a nice generic way -- no matter what the language. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can not generate 'Developer activity report'
id declare for developers in your project.xml and id present in the changelog output must match. Emmanuel - Original Message - From: Ranjan Chakrabrty [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: ranjan-yahoo [EMAIL PROTECTED] Sent: Saturday, January 10, 2004 3:20 AM Subject: Can not generate 'Developer activity report' Hello, When I generate the site using maven,all the data in the reports are generated except the data in the developer activity report. Do I need to add something else in the project.xml ? Thank you. Ranjan [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - 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: Simple properties question...
On Sat, 2004-01-10 at 07:36, Stephen Colebourne wrote: From: Jason van Zyl [EMAIL PROTECTED] It's all good on paper, but beanshell 2.0 in my mind is the option I'm leaning toward right now simply because it's gone though an iteration or two. But who knows in time. At this point in time I'm not jumping in head first into Groovy. I can understand the reluctance about Groovy both on a technical and personality level. I haven't used either, yet Groovy has the greatest mindshare for me. But why do you think that is? Things like Beanshell and OGNL just work. I have never had a single problem with OGNL which is simply just awesome for dealing with expressions. And I've rarely had any problems with Beanshell. There aren't many blog entries about either. Groovy may eventually be good if it outlasts the hype. The ideas behind Groovy are awesome, I'll wait to see if the implementation is equally so. This is a decision not to be taken lightly, as maven can't afford to get it wrong a second time! Well, I'm not too worried about it. Right now I'll take the tool where it's not a crap shoot what comes out the other end. I've spent an ungodly number of hours trying to figure out why Jelly contexts that seem to have popped into existence with no ryhme or reason, why some classloading mechanism is used, and simply been baffled at what comes out of Jexl. These things just don't happen with Beanshell and OGNL. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simple properties question...
On Fri, 2004-01-09 at 21:23, __matthewHawthorne wrote: I agree that Jelly is a bit rough and that Groovy looks awesome. I've used Beanshell a bit, and it's OK, but something just seems to be missing. Jason, do you have any thoughts on using something like BSF for the plugins? You be able to eventually write plugins in anything plexus allows a component to be written in so if someone wants to make something for BSF then it will be an option. Currently you can do Java, Beanshell and Jython. But I'm am not a huge fan of BSF either. That way, if I'm understanding things correctly, the actual plugin implementations could be written in a scripting language of choice. But, maybe that would just cause more headaches. Yah, I find BSF a big crufty hack. If I'm going to embed a scripting language I now just do it directly. The important part seems to be making the POM data accessible in a nice generic way -- no matter what the language. Right, I think every scripting language of interest to me can easily extend a Java class. So a nice base class for a plugin and you can do all the hard work for users so they can focus on the plugin concern. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Good Karma
Howdy, I'll be heading out to San Jose for the 20th of January to participate in an advanced AspectJ patterns workshop being put on by Wes Isberg who is gracious enough to volunteer his time for AspectJ users. So in an effort maintain the balance if anyone is even vaguely interested in knowing anything about Maven and you live around San Jose I would be happy to volunteer to do a little workshop on Maven on advanced topics if there is any interest. Just mail me privately if you want to set something up. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Scripting [was Simple properties question...]
I know little about these tools mentioned recently like Beanshell, OGNL, Groovy, etc. Although I recently downloaded Beanshell and it appears to be a brillant application. It's like writing shell scripts in Java. Anyway, if Maven moves away from Jelly and into Beanshell (or whatever other scripting language) are plugins still use Ant constructs? Tha is, will javac/ compile source or will it be replaced with some completely other way of compiling? -Original Message- From: Stephen Colebourne To: Maven Users List Sent: 1/10/2004 8:17 AM Subject: Re: Scripting [was Simple properties question...] I suspect we would all like to dump jelly ASAP. I've come to realise that my initial problems, and thus opposition, to maven are due to jelly in a large part. And I do find ant fustrating too. What I want to use is a proper java-like (so I don't have to learn anything new) scripting language (so it doesn't need precompiling). I want eclipse/ide integration such that it offers completions just like other coding (so I don't need to go to the website all the time). And I want it to work the way I expect it to first time (as I don't have time to waste) Of course wish lists are easy, and I suspect you wouldn't disagree with the above. As I said, I have no experience with any of the script tools, so I have to leave the judgement to others :-) Stephen maven.javadoc.destdir=target/apidocs maven.javadoc.sourcedir=src/java maven.javadoc.private=true maven.javadoc.generate() maven.artifact.deploy-snapshot(maven.javadoc) From: Jason van Zyl [EMAIL PROTECTED] Things like Beanshell and OGNL just work. I have never had a single problem with OGNL which is simply just awesome for dealing with expressions. And I've rarely had any problems with Beanshell. There aren't many blog entries about either. Groovy may eventually be good if it outlasts the hype. The ideas behind Groovy are awesome, I'll wait to see if the implementation is equally so. This is a decision not to be taken lightly, as maven can't afford to get it wrong a second time! Well, I'm not too worried about it. Right now I'll take the tool where it's not a crap shoot what comes out the other end. I've spent an ungodly number of hours trying to figure out why Jelly contexts that seem to have popped into existence with no ryhme or reason, why some classloading mechanism is used, and simply been baffled at what comes out of Jexl. These things just don't happen with Beanshell and OGNL. - 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: Scripting [was Simple properties question...]
On Sat, 2004-01-10 at 12:55, Steve Garcia wrote: I know little about these tools mentioned recently like Beanshell, OGNL, Groovy, etc. Although I recently downloaded Beanshell and it appears to be a brillant application. It's like writing shell scripts in Java. Yes, very similiar to what groovy promises. Anyway, if Maven moves away from Jelly Jelly will always be supported, just won't be encouraged. and into Beanshell (or whatever other scripting language) are plugins still use Ant constructs? Tasks yes, other constructs I want to eliminate. Using two XML programming paradigms is just a recipe for disaster. What I would like to do is actually fully support Ant build files so if you want to do Ant then you do Ant. I would just like to construct a nice interface so that you can properly feed in properties to an Ant build and get out any values produced by running the Ant build file. This way if you choose to do Ant things you can entirely because we'll just use Ant to run them, otherwise you do things Maven's way. So users can have what they want but you just won't be able to mix constructs because it is a serious pain in the ass to support Ant properly within Jelly. The behaviour has never really been comprehensible and users are often baffled. When the scripting is available I don't think many will really want to do XML programming anymore. Tha is, will javac/ compile source or will it be replaced with some completely other way of compiling? The current plugin will always be available but I would like to replace the core plugins with pure Java equivalents so that maven core with basic functionality for compiling, testing and packaging will ring in at under 300k. I am stripping things to the bare metal, the bloat will steadily get excised. I'm also trying to get Jelly to work with xpp3 which means that we can dump xerces and its ilk for a dep that's 20k. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Dependency issues for junit tests [brain dump]
The type and kind elements are really doing the same function which is really providing attribute information of a sort. I honestly don't think you would gain more with several kind elements over several type elements. What has happened though is the type has come to represent part of the path to the artifact but to my mind there really wouldn't be much distinction to a first time onlooker between type and kind to me they mean essentially the same thing. Many who participated in this thread want to specify the following properties for a dependency: .jar, .war, .ejb, .class, .zip, .ear and anything else that is a legal CLASSPATH element in Java. Whether this is called a type or kind or extension is just a matter of doing it. It doesn't really matter. You're right that type has manifested itself as part of the artifact file name. Maybe it isn't needed? How often are dependency elements differentiated only on type? Like commons-lang-1.0.jar and commons-lang-1.0.zip. I really don't know. My example is silly but I don't do much EJB stuff where maybe one would differentiate artifacts by .ejb or .jar. To me this is simply a conveinent way of specifying the path entries in the CLASSPATH. This says absolutely nothing about how the CLASSPATH is created (besides the obvious that there is a dependency element.) To me if you you look at that block above someone might guess the type really refers to the packaging and the path in the repository. What we are essentially after is that the handler for a particular type deal with the how that type is packaged, how it can be found, how it is processed and how it is integrated into the build. With the single type element a particular handler should know what to do. Might a dependency need more than one type of attribute? I honestly don't think so. With the type = test we are making the assumption that the packaging and path refers to a JAR and that it shouldn't be part of the standard classpath. This is the issue - why is that a valid assumption? A CLASSPATH can contain any number of valid entries. It can contain a .zip, .class, .jar, .ear, even a directory! (well that can't fit in the artifact model). For a developer who wants to add the Oracle classes12.zip artifact only to his unit tests, I don't know how that would look. dependency groupIdoracle/groupId artifactIdclasses12/artifactId typetest/type dependency Under your model Maven would try to find the classes12.jar file and that doesn't exist. One could also build, for example, test EJB implementations different than production EJB implementations (for instance that don't have to do round trips to the server.) So doing something like dependency groupIdcompany.com/groupId artifactIdtest-ejb/artifactId typetest/type dependency Again would try to find test-ejb.jar and NOT test-ejb.ejb which is not the desired effect. If there is another requirement for a particular artifact for testing then you simply make another handler that deals with that type. What's not OK with adding dependecies to unitTest block? First of all I think that there could be more then two kind of dependecies. I see at least three kinds: compile-time, runtime, test There could be an unlimited number of types of dependencies as people may decide to arbitrarily handle those in specifiec ways with a specific handler but these dependencies but I think having them within the unitTest element (at some point in the future just test/ might be more appropriate) I think it's very clear what they are for. I honestly don't think compile-time and runtime are things that we will need to differentiate. For a period of time I felt the same way as you did but there was opposition at my work about this and they did bring up a legitimate point. We use commons.log for our logging package and our commons-log implementor is log4j. So log4j is a runtime dependency but not a compile-time dependency. That is, we want developers only to write Java code with commons.log. If they put log4j logging statements in the code we should get a compile error indicating that the log4j package cannot be resolved. So it is necessary in this case to specify that an artifact is compile-time or runtime. This actually brings up another point about the discussion of handlers mentioned. Log4j is a legitimate compile-time and runtime dependency. There might be other projects that only want to use log4j. In that case it's a compile-time dependency. So an artifact can play more than one role. In that case you have to preserve the attribute information (groupId, versionId, artifactId so you can find it in the repository) and then use an additional property to indicate when it is supposed to be added to the CLASSPATH. Currently most of the time people add runtime requirements or testing which the transitive dependency mechanism should handle. Really, all you want
Re: Dependency issues for junit tests [brain dump]
Steve Garcia wrote: See note at the end The type and kind elements are really doing the same function which is really providing attribute information of a sort. I honestly don't think you would gain more with several kind elements over several type elements. What has happened though is the type has come to represent part of the path to the artifact but to my mind there really wouldn't be much distinction to a first time onlooker between type and kind to me they mean essentially the same thing. Many who participated in this thread want to specify the following properties for a dependency: .jar, .war, .ejb, .class, .zip, .ear and anything else that is a legal CLASSPATH element in Java. Whether this is called a type or kind or extension is just a matter of doing it. It doesn't really matter. You're right that type has manifested itself as part of the artifact file name. Maybe it isn't needed? How often are dependency elements differentiated only on type? Like commons-lang-1.0.jar and commons-lang-1.0.zip. I really don't know. My example is silly but I don't do much EJB stuff where maybe one would differentiate artifacts by .ejb or .jar. To me this is simply a conveinent way of specifying the path entries in the CLASSPATH. This says absolutely nothing about how the CLASSPATH is created (besides the obvious that there is a dependency element.) To me if you you look at that block above someone might guess the type really refers to the packaging and the path in the repository. What we are essentially after is that the handler for a particular type deal with the how that type is packaged, how it can be found, how it is processed and how it is integrated into the build. With the single type element a particular handler should know what to do. Might a dependency need more than one type of attribute? I honestly don't think so. With the type = test we are making the assumption that the packaging and path refers to a JAR and that it shouldn't be part of the standard classpath. This is the issue - why is that a valid assumption? A CLASSPATH can contain any number of valid entries. It can contain a .zip, .class, .jar, .ear, even a directory! (well that can't fit in the artifact model). For a developer who wants to add the Oracle classes12.zip artifact only to his unit tests, I don't know how that would look. dependency groupIdoracle/groupId artifactIdclasses12/artifactId typetest/type dependency Under your model Maven would try to find the classes12.jar file and that doesn't exist. One could also build, for example, test EJB implementations different than production EJB implementations (for instance that don't have to do round trips to the server.) So doing something like dependency groupIdcompany.com/groupId artifactIdtest-ejb/artifactId typetest/type dependency Again would try to find test-ejb.jar and NOT test-ejb.ejb which is not the desired effect. If there is another requirement for a particular artifact for testing then you simply make another handler that deals with that type. What's not OK with adding dependecies to unitTest block? First of all I think that there could be more then two kind of dependecies. I see at least three kinds: compile-time, runtime, test There could be an unlimited number of types of dependencies as people may decide to arbitrarily handle those in specifiec ways with a specific handler but these dependencies but I think having them within the unitTest element (at some point in the future just test/ might be more appropriate) I think it's very clear what they are for. I honestly don't think compile-time and runtime are things that we will need to differentiate. For a period of time I felt the same way as you did but there was opposition at my work about this and they did bring up a legitimate point. We use commons.log for our logging package and our commons-log implementor is log4j. So log4j is a runtime dependency but not a compile-time dependency. That is, we want developers only to write Java code with commons.log. If they put log4j logging statements in the code we should get a compile error indicating that the log4j package cannot be resolved. So it is necessary in this case to specify that an artifact is compile-time or runtime. This actually brings up another point about the discussion of handlers mentioned. Log4j is a legitimate compile-time and runtime dependency. There might be other projects that only want to use log4j. In that case it's a compile-time dependency. So an artifact can play more than one role. In that case you have to preserve the attribute information (groupId, versionId, artifactId so you can find it in the repository) and then use an additional property to indicate when it is supposed to be added to the CLASSPATH. Currently most of the time people add runtime requirements or testing which the transitive dependency mechanism should handle. Really, all you want are compile time
RE: Mutliple source directories in project.xml
It seems to me that the POM is the wrong place to put anything related
to artifacts created during maven execution. I'd even go so far as to
say that the list of reports to be generated doesn't belong in here. To
me, it makes sense to have the POM describe the project itself, in pure
terms, without making assumptions about what artifacts will be
generated.
To that end, configuring things like the generated source directory
should take place in project.properties instead of the POM. Obviously,
it's not acceptable to try to configure the list of reports via
project.properties, but somehow this information should also be excluded
from the POM.
In general, operational information used in maven execution but not
having any use outside of maven SHOULD NOT be in the POM. This will
leave open the opportunity for the POM to outlive maven's current
incarnation. Accomplishing this will make the POM much more stable, and
will mean that users won't be penalized by having to rewrite POMs for
each update to a maven plugin. It should also reduce the requirements
involved in providing backwards compatibility.
-john
On Fri, 2004-01-09 at 15:19, Michal Maczka wrote:
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Friday, January 09, 2004 6:28 PM
To: Maven Users List
Subject: RE: Mutliple source directories in project.xml
On Fri, 2004-01-09 at 11:33, Maczka Michal wrote:
Because it is not necessary to have this aspect configurable
How do you know this for certain? The answer is you can't without
feedback from users over time.
Sure I cannot
I just looked at antlr, castor and xdoclet plugin.
Myself I have written jaxb and javacc plugins.
But the point is that is easier to make something configurable then
lock it after.
So we can always add an extra property. But it's generally harder to make it
other way around.
Most of the code generators provides a possibility to customize output
directory.
There is many plugin which are generating reports and which
have hardcoded
the well known location: {maven.build.dir}/generated-xdocs
Sure, but ultimately I think this should come from the POM. An inherited
POM for all projects so that specification of all these things is as
easy as using the properties files are currrently, but in the POM
nonetheless.
Example: (taken from SIMIAN plugin)
ant:simian output=${maven.build.dir}/generated-xdocs/simian.log
lineCount=${maven.simian.linecount}
failOnDuplication=${maven.simian.failonduplication}
And report generators are extremely plugable and they just works.
Sure, this is because people generally copy one report to make another
and get ${maven.build.dir}/generated-xdocs. Do you not think it would be
better to have a standard element that could be used like:
${pom.generatedDocmentDirectory}
I am all for strongly typed way of expressing things (If I can I prefer to
stay away from jelly :))!
But maybe some of the properties may be read-only?
I am simply afraid that this will be misused.
That's the major problem with jelly properties. It's easier to remember
/target/generated-xdocs
then ${maven.build.dir}/{i_even_dont_know_what_stands_for_generated-xdocs}
Our use of properties on one hand and ${pom} elements in other cases is
rather arbitrary and if we are going to move toward one mechanism I
would be for the ${pom}. Providing a parent with all the defaults so we
still have the convenience we do now with some added consistency.
But my thought would be that a parent POM would have a
generateSourceDirectory/ that is the default that would be inherited.
If we are right in that nobody cares then we will never see that element
show up in POMs. Once we start getting POMs into the repo then at least
for the population of OSS projects uploading things we could actually
tell for certain within that population of projects what is being done.
Sure. Learing from experience and touching the reality is probably the best
option.
(After all we have always a possiblity of doing things as we maven
developers want, not as crowd of users wants.)
[...]
Michal
-
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: Simple properties question...
Thanks! I added something there. -b -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Saturday, January 10, 2004 7:33 AM To: Maven Users List Subject: Re: Simple properties question... I faced similar fustrations, so created a wiki page to document findings. http://wiki.codehaus.org/maven/WritingMavenXml Perhaps you could add to this ;-) Stephen From: Brian Topping [EMAIL PROTECTED] Q1: Is there some hidden cache of knowledge that I could have learned that from? - 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]
Stupid Q's #2: What is an Action Definition?
Hi all, Just wondering if anyone can explain what an action definition is? I've got a subproject that simply provides a jar for a source generation step. I would have rather had an exploded JAR sitting around and have the directory available to the generator, but I couldn't figure that out, so decided to put the jar subproject in instead. But when I do a build now, I get: BUILD FAILED File.. file:/C:/dev/bill2/generator-jar Element... attainGoal Line.. 4 Column 37 Goal [test:test] has no action definition. Total time: 3 seconds Finished at: Sat Jan 10 22:55:48 EST 2004 I presume that is because the generator jar really has no tests yet, and in fact I cannot think of a situation that I would ever waste time on the generator tests. (I like the idea of TDD, I'm just not bleeding seven colors yet...) Anyway, I added maven.test.skip = true to project.properties to no avail. So as before, one problem and two questions: 1) what is the solution to this? 2) how could I find this myself? (this question has been asked on the lists but never answered that I can tell...) I'll ask the a more general question in a followup to this. Thanks again! -b - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Stupid Q's #2: What is an Action Definition?
On Sat, 2004-01-10 at 23:35, Brian Topping wrote: Hi all, Just wondering if anyone can explain what an action definition is? This is the unit of work in Werkz. Within the context of Maven, the body of a goal is the action. It is a blob of Jelly which is stored until the goal chain is calculated at which time the action associated with each goal is executed. I've got a subproject that simply provides a jar for a source generation step. I would have rather had an exploded JAR sitting around and have the directory available to the generator, but I couldn't figure that out, so decided to put the jar subproject in instead. But when I do a build now, I get: BUILD FAILED File.. file:/C:/dev/bill2/generator-jar Element... attainGoal Line.. 4 Column 37 Goal [test:test] has no action definition. Total time: 3 seconds Finished at: Sat Jan 10 22:55:48 EST 2004 Some times the cache gets whacked if you interrupt a build and the pointers among goals get corrupted and if the pointer can't be found you will get this message. Go into your ~/.maven/plugins directory and erase the *.cache files and try again. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Stupid Q's #2: What is an Action Definition?
-Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Subject: Re: Stupid Q's #2: What is an Action Definition? BUILD FAILED ... Goal [test:test] has no action definition. Some times the cache gets whacked if you interrupt a build and the pointers among goals get corrupted and if the pointer can't be found you will get this message. Go into your ~/.maven/plugins directory and erase the *.cache files and try again. Worked great! I'll put that on my things to do before posting list. Thanks a ton, Jason! -b - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
