Is there a description of what you are working on that has any more details than: http://wiki.apache.org/general/SummerOfCode2006? I couldn't find anything else.
Hm... for some reason the application is not linked at http://code.google.com/soc/asf/about.html ...but it does not provide really much more information than a roadmap with dates and information about Peter. Everything else you should be aware of ;-) Plan is to at least port/implement a javac and jikes implementation for jci and then get a maven plugin started based on the maven compiler plugin code.
Is there some code we can see for these?
Just have a browse here: http://svn.apache.org/viewvc/jakarta/commons/sandbox/jci/trunk/ ...especially the maven plugin. I have some work lined up that will include: o examples and documentation o configuation management o fixing an eclipse compiler issue o class dependency awareness ...and at some stage adding jsr199 support. Brett, is there a way to exclude modules based on jdk versions? The jsr199 implementation will only compile with mustang. We probably will have to use profiles for that, right? Can you exclude whole modules based on that?
I'd generally recommend making small, incremental changes through a series of small patches. That way you can get your work reviewed (and applied!) sooner, and if anything needs changes or it's going in the wrong direction, there's less impact.
yepp +1 ...at the moment I've asked to get a patch at least every week. But more often would be even better.
> Implementation of support file-based compilers in jci is my main task now. > To example > my approach I implicated support of javac (currently call only). I used > javasist > library to replace file-working classes with my proxis. It's seems this > approch > would work fine for every java-based java compiler. Yep, I know that > javasist is > pretty fat and slow, but it's only technological preview, and I hope > implication > would become more satisfactory in future. And of course, unavailability of > fork-call, remain main problem of this approach.
Actually we would also need to verify that it is really release under MPL version 1.1 ...otherwise we would have licensing problem. But I suggest to use http://vafer.org/projects/dependency/ anyway. It should be good enough for at least how we use javassist at the moment and we will have that dependency to "dependency" ;-) anyway.
While I think I understand what you are doing here, the original assumption was to use the code in Maven as a starting point. Was there a reason not to do this? Javac is completely implemented there.
While I agree starting from the maven source code would have been better, the maven implementation is probably not good enough as jci features in memory compilation ...which is not directly supported by javac out-of-the-box. I though we had to use a very ugly work-around but Peter found a very smart way around that. Really good! ...forking will become interesting - probably for all compilers though.
> Support of maven is my second goal. It's pretty simple, and I already > developed > main part of maven plugin. But problem of abstract configuration of > jci-compilers > isn't steal solved. As you know, now every jci-compiler has own > configuration > class, in the other hand we have only one compiler-configuration format in > plexys. So, you can see what shall we aim to.
That should be easy to implement through a factory pattern.
I'm just seeing now that the original description would have been misleading - it's not desirable to write a new compiler plugin, but instead to integrate commons-jci into the existing one (instead of the plexus compiler).
Well, maybe my fault. I thought starting of from the maven-compiler-plugin code but building it in jci as maven-jci-plugin. Once stable it should be an easy replacement and we can move the code over to the maven-compiler-plugin codebase. WDYT?
Looking forward to hearing more about your work!
Same here! :) cheers -- Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
