cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Torsten Curdt" <>
Subject Re: Problems with JavaFlow
Date Wed, 31 Dec 2008 15:32:16 GMT
> 1. since Cocoon is Maven, based I sort of dislike the option of falling back
> to ant.

Can't say I'd like it ...but it would get the job done quickly.

> 2. Wouldn't this ad a dependency to JavaFlow to cocoon itself?

No - only to JCI. And that's already there.

But as it looks all that is required is already supported with the
RCL. At least from the configuration options it looks like.

> 3. At the moment I think I would like this option a lot ... even if my
> gut-feeling tells me in your next mail you're going to say "cool ... write
> it"

Yepp! :)

> ... I guess I would need more detailed information about JavaFlow for
> this

No you really don't! You need some maven knowledge on how to write a mojo.
Check out the ant task. All it does is

 foreach class in classes {
   if (matches(class)) {
     oldClassFile =
     newClassFile = transformer.transform(oldClassFile)
   } else {
     IOUtils.copy(input, output)

You could probably even leave out the matching for now.

> ... maybe you're going to drop by near Frankfurt someday ;-)

I am in Frankfurt until mid Jan.

> One thing I like about this, is that I would get pre-instrumented JavaFlow
> classes form my flows. The downside is that It might need some kind of
> Eclipse plug-in to accompany it since Eclipse would replace the instrumented
> class with a non instrumented one as soon as someone changes it ...

As said: The development/deployment approach worked very well for me
with eclipse.

> 4. Ok ... this one sounds a little more complex. In some projects I am
> currently working on, we are using the eclipse compiler instead of the
> ordinary maven-one since the default Jdk compiler seems to have some
> problems dealing with some Java 1.6 features (strange thing that suns
> compiler seems to have problems with suns features) ... this would rob me of
> this option.

Indeed it is a little more complex. But the maven jci plugin would
support all sorts of compilers.

> I would propose that a solution of 2 + 3 sounds safest from my point of
> view. Writing a plug-in for the RCL (assuming there is something like that).
> In addition creating a Maven plug-in doing the instrumentation would be
> great. Both could work together:

Actually I think all is needed is such a maven instrumentation plugin.

> The Maven could set some kind of mark in the instrumented classes to
> indicate the RCL-plug-in that this class was already instrumented. In this
> case the RCL simply relays the class. If the flag is not set it instruments
> the class.

Actually that's something that could be added to the class transformer
itself. If there already is a dependency to the javaflow runtime
classes it's not instrumented again. That would make the whole think
quite fool proof. Easy to implement as well.

> This would make development a lot easier and boost the default
> performance of production builds.

Here you lost me again :)

> Every time I say, that I would gladly contribute, Murphy comes along and
> steals all my free time, so let me say, that if the information I need sort
> of pops up in my Mail-Folder, and Murphy left over some time, I will gladly
> try to do something with this information ... even if it is only printing it
> and throwing paper balls at Murphy ;-)



View raw message