> Right.. I'm tempted to give the m2 solution which is to write a java > bean that does it and tell it to bind to @phase process-classes...
interesting > For maven1, utilising the same bean, adding a <postGoal > name="java:compile" /> probably is what you are after (probably what > you are already doing in fact).. :) >>Now this means that I need to transform all >>classes that are being generated (like a >>class file post-processor) and all the >>depending jars! > > > Can you elaborate on this? We haven't previously considered a use case > where you would actually need to process the dependencies as well. > What is it that javaflow is doing with the deps? Are you copying them > into the target directory and creating a new classpath, or bundling > them into something else? What javaflow does is basically it searches the class for javaflow specific code and instruments it. I'd like to provide three different ways of using javaflow. Currently there are two: 1. A classloader loading and transforming the classes on the fly (synchronously) 2. Integration with the Reloading- or CompilingClassLoader that does the rewriting when the class was compiled. (asynchronously) now here it comes... 3. At built time. Post-processing the compiled classes and even repackaging the jar dependencies.(the classpath stays the same) ...for both ant and maven >>Cool ...ok. An ant task was the first >>thing I thought of. > > > Just to elaborate a bit, the strategy we are aiming for is to write > such things as "mojos" - java beans that have little or later maybe no > need of the Maven API (what it uses now is a very small jar that > provides a logger and interface). mojos? Austin Powers! :-D I only know "pojos" ...but I see what you mean :-) >>From those, you can put directives to execute it in the javadoc and > Maven2 will run it, or you can generate a jelly harness (to create a > maven1 plugin), and hopefully a task adapater (to create an antlib). > The latter 2 haven't been completed or well tested, so we so far have > gone with manually writing the bindings, but keeping the code separate > from the specifics of any of the 3 is a good practice to making it > reusable across them all in future. sounds good cheers -- Torsten
signature.asc
Description: OpenPGP digital signature
