commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Torsten Curdt" <>
Subject Re: [JCI] GSOC status
Date Mon, 19 Jun 2006 01:29:33 GMT
> Is there a description of what you are working on that has any more
> details than: I
> couldn't find anything else.

Hm... for some reason the application is not linked at

...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:

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

anyway. It should be good enough for at least how we use javassist at
the moment and we will have that dependency to "dependency" ;-)

> 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! :)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message