> -----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]
