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:
goal name=war:init
description=Initialize the file system and attain any
necessary
goals
ant:available property=webSourcesPresent type=dir
file=${maven.war.src}/
j:if test=${sourcesPresent == 'true'}
caller:call goalInterface=compile-java/
attainGoal name=test:test/
/j:if
ant:property name=maven.war.final.name
value=${pom.artifactId}.war/
/goal
There should be no call to caller plugin
just something like
j:if test=${sourcesPresent == 'true'}
atainGoal name=x:compile/ (e.g
x:compile=java:compile)
attainGoal name=test:test/
/j:if
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)
goal name=java:compile
j:if test=${sourcesPresent == 'true'}
caller:call goalInterface=compile-java/
/j:if
/goal
If we have:
j:if test=${sourcesPresent == 'true'}
atainGoal name=x:compile/ (e.g
x:compile=java:compile)
attainGoal name=test:test/
/j:if
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 prepostGoals for java:compile
and the do
maven.caller.call.compile-java = javac:compile
or
maven.caller.call.compile-java = jikes:compile
if you call
caller:call goalInterface=compile-java/ from war plugin you have
to
change blocks like
preGoal name=java:compile
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: 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
-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:
attainGoal name=${codeGenerator}:generate/
end;
b)
java:compile (calls javac:compile or aspectj:compile or
eclipse-compiler:compile)
c)
foreach byteCodeEnhancer in byteCodeEnhancers do:
attainGoal name=$byteCodeEnhancer}:enhace/
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
-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:
attainGoal name=${codeGenerator}:generate/
end;
b)
java:compile (calls javac:compile or aspectj:compile or
eclipse-compiler:compile)
c)
foreach byteCodeEnhancer in byteCodeEnhancers do:
attainGoal name=$byteCodeEnhancer}:enhace/
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: 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
[...]
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:
goal name=war:init
description=Initialize the file system and attain any necessary goals
ant:available property=webSourcesPresent type=dir
file=${maven.war.src}/
j:if test=${sourcesPresent == 'true'}
caller:call goalInterface=compile-java/
attainGoal name=test:test/
/j:if
ant:property name=maven.war.final.name
value=${pom.artifactId}.war/
/goal
There should be no call to caller plugin
just something like
j:if test=${sourcesPresent == 'true'}
atainGoal name=x:compile/ (e.g x:compile=java:compile)
attainGoal name=test:test/
/j:if
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 19:36
To: Maven Users List
Subject: RE: war plugin : [maven.caller.call.compile-java] is not
defined
[snip]
That in goal war:init:
goal name=war:init
description=Initialize the file system and attain any necessary
goals
ant:available property=webSourcesPresent type=dir
file=${maven.war.src}/
j:if test=${sourcesPresent == 'true'}
caller:call goalInterface=compile-java/
attainGoal name=test:test/
/j:if
ant:property name=maven.war.final.name
value=${pom.artifactId}.war/
/goal
There should be no call to caller plugin
just something like
j:if test=${sourcesPresent == 'true'}
atainGoal name=x:compile/ (e.g
x:compile=java:compile)
attainGoal name=test:test/
/j:if
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:
j:if test=${sourcesPresent == 'true'}
atainGoal name=x:compile/ (e.g
x:compile=java:compile)
attainGoal name=test:test/
/j:if
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
-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:
goal name=war:init
description=Initialize the file system and attain any necessary
goals
ant:available property=webSourcesPresent type=dir
file=${maven.war.src}/
j:if test=${sourcesPresent == 'true'}
caller:call goalInterface=compile-java/
attainGoal name=test:test/
/j:if
ant:property name=maven.war.final.name
value=${pom.artifactId}.war/
/goal
There should be no call to caller plugin
just something like
j:if test=${sourcesPresent == 'true'}
atainGoal name=x:compile/ (e.g
x:compile=java:compile)
attainGoal name=test:test/
/j:if
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)
goal name=java:compile
j:if test=${sourcesPresent == 'true'}
caller:call goalInterface=compile-java/
/j:if
/goal
If we have:
j:if test=${sourcesPresent == 'true'}
atainGoal name=x:compile/ (e.g
x:compile=java:compile)
attainGoal name=test:test/
/j:if
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 prepostGoals for java:compile
and the do
maven.caller.call.compile-java = javac:compile
or
maven.caller.call.compile-java = jikes:compile
if you call
caller:call goalInterface=compile-java/ from war plugin you have to
change blocks like
preGoal name=java:compile
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
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
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: 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]
