RE: war plugin : [maven.caller.call.compile-java] is not defined
> -Original Message- > From: Vincent Massol [mailto:[EMAIL PROTECTED] > Sent: Saturday, November 08, 2003 11:54 AM > To: 'Maven Users List' > Subject: RE: war plugin : [maven.caller.call.compile-java] is not defined > > > Ok, I think I understand what you mean now. You want to have a > distributed workflow instead of a centralized one. So you want to move > from WKG to WKP (Well-Known Plugins). > > What I don't like is that it means not all plugins will be equal, some > will be more equal than others ;-) It also means that 'other' plugins > will be tied to all WKPs. > > I think I may agree with you, if the WKP are empty shells only, unlike > what is currently the case. It means that instead of having one caller > plugin, you'll have a caller-compile, caller-test, caller-whatever > plugins... delegating to the real implementations like java:compile, > aspectj:compile, etc. > > In the end, your proposal looks like an extension to the caller plugin, > i.e. having several call plugins instead of one. It may or may not be > better. > I don't want to introduce a bunch of new plugins. In first place we can reuse existsing plugins (java, test) with some resonable defaults (e.g java:compile goal will call javac:compile). We are alredy providing skeletal workflow with well defined states ( I like names of the goals like java:compile etc.). but simply some of the states of our workflow are not customizable. > However, I do think this workflow stuff has to be in Maven core. With > the current Maven implementation, I'd say it's a tag. Actually if I find > a few hours, I'll reimplement the caller plugin as a jelly tag in Maven > core. > I am not sure what you mean by " workflow stuff has to be in Maven core". It's alredy there. Also I am not sure if we need something as fancy as "caller taglib". Take a look at "multiproject:install-callback" goal. Such logic should be sufficient for the most of the cases. Special things might be needed when we will have to load implementor plugin from the repository. But this can be handled by maven core. [..] Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: war plugin : [maven.caller.call.compile-java] is not defined
Ok, I think I understand what you mean now. You want to have a
distributed workflow instead of a centralized one. So you want to move
from WKG to WKP (Well-Known Plugins).
What I don't like is that it means not all plugins will be equal, some
will be more equal than others ;-) It also means that 'other' plugins
will be tied to all WKPs.
I think I may agree with you, if the WKP are empty shells only, unlike
what is currently the case. It means that instead of having one caller
plugin, you'll have a caller-compile, caller-test, caller-whatever
plugins... delegating to the real implementations like java:compile,
aspectj:compile, etc.
In the end, your proposal looks like an extension to the caller plugin,
i.e. having several call plugins instead of one. It may or may not be
better.
However, I do think this workflow stuff has to be in Maven core. With
the current Maven implementation, I'd say it's a tag. Actually if I find
a few hours, I'll reimplement the caller plugin as a jelly tag in Maven
core.
But do we agree that ideally the WKP must not have implementation logic?
They delegate to implementing plugins.
What do others think?
Thanks
-Vincent
> -Original Message-
> From: Michal Maczka [mailto:[EMAIL PROTECTED]
> Sent: 07 November 2003 21:39
> To: Maven Users List
> Subject: RE: war plugin : [maven.caller.call.compile-java] is not
defined
>
>
>
> > -Original Message-
> > From: Vincent Massol [mailto:[EMAIL PROTECTED]
> > Sent: Friday, November 07, 2003 9:08 PM
> > To: 'Maven Users List'
> > Subject: RE: war plugin : [maven.caller.call.compile-java] is not
> defined
> >
> >
> >
> >
> > > -Original Message-
> > > From: Michal Maczka [mailto:[EMAIL PROTECTED]
> > > Sent: 07 November 2003 19:36
> > > To: Maven Users List
> > > Subject: RE: war plugin : [maven.caller.call.compile-java] is not
> > defined
> >
> > [snip]
> >
> > > That in goal "war:init":
> > >
> > >
> > > > > description="Initialize the file system and attain any
necessary
> > > goals">
> > >
> > > > > file="${maven.war.src}"/>
> > >
> > >
> > >
> > >
> > >
> > >
> > > > > value="${pom.artifactId}.war"/>
> > >
> > >
> > >
> > > There should be no call to caller plugin
> > >
> > >
> > > just something like
> > >
> > >
> > > (e.g
> > x:compile=java:compile)
> > >
> > >
> > >
> > > and it should be up to (just an example - I am not imposing
anything)
> > > "java"
> > > plugin to handle this call (In place of WKG there will be WKG in
Well
> > Know
> > > Plugin).
> >
> > I would not like at all that the java plugin has to know about all
the
> > other plugins (like the aspectj plugin, the xdoc plugin, etc).
> >
>
> Me neither
> what I want to have (writen with caller plugin sematic)
>
>
>
>
>
>
>
>
> > If we have:
> >
> >
> > (e.g
> > x:compile=java:compile)
> >
> >
> >
> > And if there is some interception, then it is *very* misleading
because
> > the reader will think the java plugin will be called but in practice
it
> > will be some other plugin's goal.
> >
>
>
> Exactly that's the point. java plugin and java:compile plugin will be
> always called and should be always called!.
> So you can add pre&postGoals for java:compile
>
> and the do
>
> maven.caller.call.compile-java = javac:compile
> or
> maven.caller.call.compile-java = jikes:compile
>
>
> if you call
> from war plugin you have
to
> change blocks like
>
>
> do something here
> <.preGoal>
>
>
> every time you want to change a compiler.
>
> 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: war plugin : [maven.caller.call.compile-java] is not defined
> -Original Message-
> From: Vincent Massol [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 07, 2003 9:08 PM
> To: 'Maven Users List'
> Subject: RE: war plugin : [maven.caller.call.compile-java] is not defined
>
>
>
>
> > -Original Message-
> > From: Michal Maczka [mailto:[EMAIL PROTECTED]
> > Sent: 07 November 2003 19:36
> > To: Maven Users List
> > Subject: RE: war plugin : [maven.caller.call.compile-java] is not
> defined
>
> [snip]
>
> > That in goal "war:init":
> >
> >
> > > description="Initialize the file system and attain any necessary
> > goals">
> >
> > > file="${maven.war.src}"/>
> >
> >
> >
> >
> >
> >
> > > value="${pom.artifactId}.war"/>
> >
> >
> >
> > There should be no call to caller plugin
> >
> >
> > just something like
> >
> >
> > (e.g
> x:compile=java:compile)
> >
> >
> >
> > and it should be up to (just an example - I am not imposing anything)
> > "java"
> > plugin to handle this call (In place of WKG there will be WKG in Well
> Know
> > Plugin).
>
> I would not like at all that the java plugin has to know about all the
> other plugins (like the aspectj plugin, the xdoc plugin, etc).
>
Me neither
what I want to have (writen with caller plugin sematic)
> If we have:
>
>
> (e.g
> x:compile=java:compile)
>
>
>
> And if there is some interception, then it is *very* misleading because
> the reader will think the java plugin will be called but in practice it
> will be some other plugin's goal.
>
Exactly that's the point. java plugin and java:compile plugin will be
always called and should be always called!.
So you can add pre&postGoals for java:compile
and the do
maven.caller.call.compile-java = javac:compile
or
maven.caller.call.compile-java = jikes:compile
if you call
from war plugin you have to
change blocks like
do something here
<.preGoal>
every time you want to change a compiler.
Michal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: war plugin : [maven.caller.call.compile-java] is not defined
> -Original Message-
> From: Michal Maczka [mailto:[EMAIL PROTECTED]
> Sent: 07 November 2003 19:36
> To: Maven Users List
> Subject: RE: war plugin : [maven.caller.call.compile-java] is not
defined
[snip]
> That in goal "war:init":
>
>
> description="Initialize the file system and attain any necessary
> goals">
>
>file="${maven.war.src}"/>
>
>
>
>
>
>
>value="${pom.artifactId}.war"/>
>
>
>
> There should be no call to caller plugin
>
>
> just something like
>
>
> (e.g
x:compile=java:compile)
>
>
>
> and it should be up to (just an example - I am not imposing anything)
> "java"
> plugin to handle this call (In place of WKG there will be WKG in Well
Know
> Plugin).
I would not like at all that the java plugin has to know about all the
other plugins (like the aspectj plugin, the xdoc plugin, etc).
If we have:
(e.g
x:compile=java:compile)
And if there is some interception, then it is *very* misleading because
the reader will think the java plugin will be called but in practice it
will be some other plugin's goal.
I definitely prefer the notion of common interfaces (WKG). It seems
logical to me that the war plugin would use one WKG for compilation.
> It's like you are looking up "well know" service (interface) and call
it
> while with caller plugin it's like you are looking up the name of the
> service before calling it.
> (I hope that difference is clear)
No... Either I don't understand or I don't agree... :-)
>
> So as a consequnce (as I see it) war plugin should not depend on
"caller
> plugin" and we should put inside "java" plugin a logic which binds a
call
> to
> "compile"
> goal to particual executor.
-1, unless I understand what you're saying... ;-)
My internal logic tells me that it's always high in the chain that you
make choices about different implementations to use and not the other
way around.
What do others think? Am I really dumb and not understanding what our
friend Michal is saying?
Thanks
-Vincent
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: war plugin : [maven.caller.call.compile-java] is not defined
[...] > Yep, but isn't this exactly what the caller plugin does? Again, I do > agree that it would be better written in java and inside Maven core. > I've defined a "merge point" as a WKG (Well-Known Goal). > I agree. Just to explain myslef I tried to explain ( I am sick today :( so it's not going well) That in goal "war:init": There should be no call to caller plugin just something like (e.g x:compile=java:compile) and it should be up to (just an example - I am not imposing anything) "java" plugin to handle this call (In place of WKG there will be WKG in Well Know Plugin). It's like you are looking up "well know" service (interface) and call it while with caller plugin it's like you are looking up the name of the service before calling it. (I hope that difference is clear) So as a consequnce (as I see it) war plugin should not depend on "caller plugin" and we should put inside "java" plugin a logic which binds a call to "compile" goal to particual executor. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: war plugin : [maven.caller.call.compile-java] is not defined
> -Original Message- > From: Michal Maczka [mailto:[EMAIL PROTECTED] > Sent: 07 November 2003 18:01 > To: Maven Users List > Subject: RE: war plugin : [maven.caller.call.compile-java] is not defined [snip] > > I think the aspectj aspect must be completely independent of the java > > plugin. It should be possible to replace the java plugin by the aspectj > > plugin (or by any other custom implementation) seamlessly. > > > > I fact I meant that "java:compile" is a place where java source are > compiled. > If they are compiled with javac, eclipse compiler, jikes, aspectj > (could be that aspectj compiler is as fact in compiling java sources when > no > aspect are provided as any other java compiler) > is no so important to me. Yep, except that aspects not java classes. So java:compile would not fit. However aspectj:compile would... :-) > > > You can have also things like: > > jsp:compile > ejb:compile > xmlc:compile > etc aspectj:compile > > so I think that name java:compile is quite appropriate. Nope, not for me... ;-) > > but the name of the plugin/goal is in fact of second importance here. > I am just advocating against central place when goals are "wired" > together. Which is exactly why I introduced the caller plugin. It is to unwire dependencies between plugins! :-) > > As I think that usage of preGoals/postGoals should be avoided in plugins > (it's the case right now) we should possibly try to define merge points > of the build process (as the workflow) and let other plugins be > participants of this process. Yep, but isn't this exactly what the caller plugin does? Again, I do agree that it would be better written in java and inside Maven core. I've defined a "merge point" as a WKG (Well-Known Goal). > > For me the ultimate goal would be to make entire process "clickable" so > almost no scripting in "maven.xml" file is needed yep. With the caller plugin you simply need to provide a GUI for editing the WKG properties. > > So what will be nice is to let other plugins > a) do some actions before java:compile is executed (e.g. let source > generators generate java source files) For end users, sure. For plugins I'm not sure it's really needed, provided the plugins are small and focused enough. But why not. > b) modify byte code produced by java compiler. Or replace the java plugin by your own one. BTW, this is not possible to do easily with the current aspectj version as it doesn't support weaving bytecodes on a directory (only on a jar). Hence the reason for all the above... ;-) Regards, -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: war plugin : [maven.caller.call.compile-java] is not defined
> -Original Message- > From: Vincent Massol [mailto:[EMAIL PROTECTED] > Sent: Friday, November 07, 2003 3:57 PM > To: 'Maven Users List' > Subject: RE: war plugin : [maven.caller.call.compile-java] is not defined > > > > > > -Original Message- > > From: Michal Maczka [mailto:[EMAIL PROTECTED] > > Sent: 06 November 2003 11:42 > > To: Maven Users List > > Subject: Re: war plugin : [maven.caller.call.compile-java] is not > defined > > > > Vincent Massol wrote: > > > > >Hi Eric, > > > > > >No. It's because you seem not to have installed the caller plugin... > My > > >guess is that you have only taken the war plugin from HEAD without > > >taking it's dependencies. Actually, thinking about it, we should add > a > > >dependency in the war plugin on the caller plugin so that it gets > > >automatically downloaded. > > > > > >-Vincent > > > > > > > > Vincent! > > I really like your idea of Well Know Goals which is implemented in > > Caller Plugin but I think ... that this plugin should be dropped. > > > > In particular case of java:compile goal - it's java plugin which is > > badly written. > > > > I don't think we need a central point for "wiring" goals. > > > > Existence of caller plugin just shows that we need to have a well > > defined and *extendable* workflow. > > Yes. My implementation of this workflow is a poor man's implementation > but it satisfied my immediate need. Feel free to improve it provided you > keep the same feature. :-) > > > > > Lets's concentrate on java plugin: > > java:compile process can be divided into 3 steps: > > a) generation of java classes (with plugin xdoclet, jaxb, castor) > > b) compilation with e.g javac/aspectj compiler > > I don't think so. The java plugin is about java. It's NOT about aspectj, > nor is it about any extension to the java language like xdoclet or > whatever. I would not want to tie the java plugin with aspectj. > > > c) applictaion of bytecode ehancers (like kodo, ascpectj ) > > same here. > > > > > > > a) > > foreach codeGenerator in codeGenerator do: > > > > end; > > b) > > java:compile (calls javac:compile or aspectj:compile or > > eclipse-compiler:compile) > > > > c) > > foreach byteCodeEnhancer in byteCodeEnhancers do: > > > > end; > > > > > > > > IMHO the best solution will be to > > > > a) rename java:compile goal to javac:compile > > > > add java:compile which does what you have tried to do with caller > plugin. > > I had thought about this solution is course (as it is much simpler to > implement than the caller plugin). However, I don't like the coupling it > introduces. Granted the caller plugin is one coupling but the idea was > to have one coupling instead of several and actually the next step was > to transform the caller plugin in java code and put that inside Maven > core. > > I think the aspectj aspect must be completely independent of the java > plugin. It should be possible to replace the java plugin by the aspectj > plugin (or by any other custom implementation) seamlessly. > I fact I meant that "java:compile" is a place where java source are compiled. If they are compiled with javac, eclipse compiler, jikes, aspectj (could be that aspectj compiler is as fact in compiling java sources when no aspect are provided as any other java compiler) is no so important to me. You can have also things like: jsp:compile ejb:compile xmlc:compile etc so I think that name java:compile is quite appropriate. but the name of the plugin/goal is in fact of second importance here. I am just advocating against central place when goals are "wired" together. As I think that usage of preGoals/postGoals should be avoided in plugins (it's the case right now) we should possibly try to define merge points of the build process (as the workflow) and let other plugins be participants of this process. For me the ultimate goal would be to make entire process "clickable" so almost no scripting in "maven.xml" file is needed So what will be nice is to let other plugins a) do some actions before java:compile is executed (e.g. let source generators generate java source files) b) modify byte code produced by java compiler. regards Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: war plugin : [maven.caller.call.compile-java] is not defined
> -Original Message- > From: Michal Maczka [mailto:[EMAIL PROTECTED] > Sent: 06 November 2003 11:42 > To: Maven Users List > Subject: Re: war plugin : [maven.caller.call.compile-java] is not defined > > Vincent Massol wrote: > > >Hi Eric, > > > >No. It's because you seem not to have installed the caller plugin... My > >guess is that you have only taken the war plugin from HEAD without > >taking it's dependencies. Actually, thinking about it, we should add a > >dependency in the war plugin on the caller plugin so that it gets > >automatically downloaded. > > > >-Vincent > > > > > Vincent! > I really like your idea of Well Know Goals which is implemented in > Caller Plugin but I think ... that this plugin should be dropped. > > In particular case of java:compile goal - it's java plugin which is > badly written. > > I don't think we need a central point for "wiring" goals. > > Existence of caller plugin just shows that we need to have a well > defined and *extendable* workflow. Yes. My implementation of this workflow is a poor man's implementation but it satisfied my immediate need. Feel free to improve it provided you keep the same feature. :-) > > Lets's concentrate on java plugin: > java:compile process can be divided into 3 steps: > a) generation of java classes (with plugin xdoclet, jaxb, castor) > b) compilation with e.g javac/aspectj compiler I don't think so. The java plugin is about java. It's NOT about aspectj, nor is it about any extension to the java language like xdoclet or whatever. I would not want to tie the java plugin with aspectj. > c) applictaion of bytecode ehancers (like kodo, ascpectj ) same here. > > > a) > foreach codeGenerator in codeGenerator do: > > end; > b) > java:compile (calls javac:compile or aspectj:compile or > eclipse-compiler:compile) > > c) > foreach byteCodeEnhancer in byteCodeEnhancers do: > > end; > > > > IMHO the best solution will be to > > a) rename java:compile goal to javac:compile > > add java:compile which does what you have tried to do with caller plugin. I had thought about this solution is course (as it is much simpler to implement than the caller plugin). However, I don't like the coupling it introduces. Granted the caller plugin is one coupling but the idea was to have one coupling instead of several and actually the next step was to transform the caller plugin in java code and put that inside Maven core. I think the aspectj aspect must be completely independent of the java plugin. It should be possible to replace the java plugin by the aspectj plugin (or by any other custom implementation) seamlessly. Regards, -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: war plugin : [maven.caller.call.compile-java] is not defined
Vincent Massol wrote: Eric, Have you tried without -DsourcesPresent=true? It was working for me some time ago (I haven't checked recently). It works perfectly without the -D (it's obvious looking at the source code: the war plugin only calls the caller plugin when 'sourcesPresent' is true) Also, are you sure you have removed you plugin cache directory when you updated your maven plugins 3 days ago? That's always the first i do whenever something goes wrong :-) Thanks -Vincent -Original Message- From: Eric Berenguier [mailto:[EMAIL PROTECTED] Sent: 06 November 2003 14:26 To: Maven Users List Subject: Re: war plugin : [maven.caller.call.compile-java] is not defined Vincent Massol wrote: No. It's because you seem not to have installed the caller plugin... My guess is that you have only taken the war plugin from HEAD without taking it's dependencies. Actually, thinking about it, we should add a dependency in the war plugin on the caller plugin so that it gets automatically downloaded. I installed all plugins from maven and maven-plugin (including caller plugin) from CVS 3 days ago, and i saw no relevant changes in CVS since i downloaded the sources. "maven -DsourcesPresent=true war:war" leads to this error with any project. Eric war:war goal leads to: BUILD FAILED File.. file:/C:/Documents and Settings/juju/.maven/plugins/maven-caller-plugin-1.0-SNAPSHOT/ Element... ant:fail Line.. 24 Column 91 Property [maven.caller.call.compile-java] is not defined - 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: war plugin : [maven.caller.call.compile-java] is not defined
Eric, Have you tried without -DsourcesPresent=true? It was working for me some time ago (I haven't checked recently). Also, are you sure you have removed you plugin cache directory when you updated your maven plugins 3 days ago? Thanks -Vincent > -Original Message- > From: Eric Berenguier [mailto:[EMAIL PROTECTED] > Sent: 06 November 2003 14:26 > To: Maven Users List > Subject: Re: war plugin : [maven.caller.call.compile-java] is not defined > > Vincent Massol wrote: > > >No. It's because you seem not to have installed the caller plugin... My > >guess is that you have only taken the war plugin from HEAD without > >taking it's dependencies. Actually, thinking about it, we should add a > >dependency in the war plugin on the caller plugin so that it gets > >automatically downloaded. > > > > > I installed all plugins from maven and maven-plugin (including caller > plugin) from CVS 3 days ago, and i saw no relevant changes in CVS since > i downloaded the sources. > > "maven -DsourcesPresent=true war:war" leads to this error with any > project. > > Eric > > >>war:war goal leads to: > >> > >>BUILD FAILED > >>File.. file:/C:/Documents and > >>Settings/juju/.maven/plugins/maven-caller-plugin-1.0-SNAPSHOT/ > >>Element... ant:fail > >>Line.. 24 > >>Column 91 > >>Property [maven.caller.call.compile-java] is not defined > >> > >> > >> > > > > - > 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: war plugin : [maven.caller.call.compile-java] is not defined
Vincent Massol wrote: No. It's because you seem not to have installed the caller plugin... My guess is that you have only taken the war plugin from HEAD without taking it's dependencies. Actually, thinking about it, we should add a dependency in the war plugin on the caller plugin so that it gets automatically downloaded. I installed all plugins from maven and maven-plugin (including caller plugin) from CVS 3 days ago, and i saw no relevant changes in CVS since i downloaded the sources. "maven -DsourcesPresent=true war:war" leads to this error with any project. Eric war:war goal leads to: BUILD FAILED File.. file:/C:/Documents and Settings/juju/.maven/plugins/maven-caller-plugin-1.0-SNAPSHOT/ Element... ant:fail Line.. 24 Column 91 Property [maven.caller.call.compile-java] is not defined - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: war plugin : [maven.caller.call.compile-java] is not defined
Vincent Massol wrote: Hi Eric, No. It's because you seem not to have installed the caller plugin... My guess is that you have only taken the war plugin from HEAD without taking it's dependencies. Actually, thinking about it, we should add a dependency in the war plugin on the caller plugin so that it gets automatically downloaded. -Vincent Vincent! I really like your idea of Well Know Goals which is implemented in Caller Plugin but I think ... that this plugin should be dropped. In particular case of java:compile goal - it's java plugin which is badly written. I don't think we need a central point for "wiring" goals. Existence of caller plugin just shows that we need to have a well defined and *extendable* workflow. Lets's concentrate on java plugin: java:compile process can be divided into 3 steps: a) generation of java classes (with plugin xdoclet, jaxb, castor) b) compilation with e.g javac/aspectj compiler c) applictaion of bytecode ehancers (like kodo, ascpectj ) a) foreach codeGenerator in codeGenerator do: end; b) java:compile (calls javac:compile or aspectj:compile or eclipse-compiler:compile) c) foreach byteCodeEnhancer in byteCodeEnhancers do: end; IMHO the best solution will be to a) rename java:compile goal to javac:compile add java:compile which does what you have tried to do with caller plugin. regards Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: war plugin : [maven.caller.call.compile-java] is not defined
Hi Eric, No. It's because you seem not to have installed the caller plugin... My guess is that you have only taken the war plugin from HEAD without taking it's dependencies. Actually, thinking about it, we should add a dependency in the war plugin on the caller plugin so that it gets automatically downloaded. -Vincent > -Original Message- > From: Eric Berenguier [mailto:[EMAIL PROTECTED] > Sent: 06 November 2003 10:38 > To: Maven Users List > Subject: war plugin : [maven.caller.call.compile-java] is not defined > > Hi, > > War plugin from CVS version doesn't work anymore : > > war:war goal leads to: > > BUILD FAILED > File.. file:/C:/Documents and > Settings/juju/.maven/plugins/maven-caller-plugin-1.0-SNAPSHOT/ > Element... ant:fail > Line.. 24 > Column 91 > Property [maven.caller.call.compile-java] is not defined > > As a workaround i have to manually set the > 'maven.caller.call.compile-java' property. > Is it supposed to work like this ? > > Thanks > > Eric > > > > - > 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]
war plugin : [maven.caller.call.compile-java] is not defined
Hi, War plugin from CVS version doesn't work anymore : war:war goal leads to: BUILD FAILED File.. file:/C:/Documents and Settings/juju/.maven/plugins/maven-caller-plugin-1.0-SNAPSHOT/ Element... ant:fail Line.. 24 Column 91 Property [maven.caller.call.compile-java] is not defined As a workaround i have to manually set the 'maven.caller.call.compile-java' property. Is it supposed to work like this ? Thanks Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
