commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: [JCI] GSOC status
Date Mon, 19 Jun 2006 01:40:34 GMT
Torsten Curdt wrote:
>> Is there some code we can see for these?
> Just have a browse here:

Ok, I'd missed that you'd applied those for him. Will do.

> ...especially the maven plugin.

I'm at a bit of a loss as to why we need a whole new one. I can 
understand it might be a bit harder to work it into the "live" Maven 
plugin as this is experimental, but why don't we copy the existing one 
over to JCI (as if it were a branch), and modify it there? It can be 
merged back if it works out. That way you can aim for functional 
equivalence and backwards compatibility.

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

That's a lot of work :)

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

I'll try and filter the JCI ones separately so I actually see them :)

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

Care to elaborate?

> ...forking will become interesting - probably for all compilers though.

I quite like the pattern of a little bootstrapper so that forking is the 
same code as usual, just with a bootstrapper that runs the jvm in the 

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

Yes, I think that's the right way to go about it, rather than starting 
from scratch.


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

View raw message