[Scons-dev] Java Development

[Dirk Bächle]

Hi Mark,

On 02.08.2014 01:49, Mark A. Flacy wrote:
> On Friday, August 01, 2014 05:22:39 PM William Blevins wrote:
>> SCons Java doesn't need to be that fancy, but I think the root problems can
>> be solved. The SCons java tool simply doesn't get the love that some of the
>> other tools get.
> One common use case is to generate java source from the xjc tool (which
> converts XML schema to java classes) for use by other java classes.
>
> The emitter in that case would need to parse a bindings file as well as the XML
> schema(s) that the binding file uses.  However, the resulting java files should
> have no dependencies on any external libraries, so they could be compiled as a
> unit independently from anything using them.
>
> And there are Annotations, which can be used to (and *are* used to) generate
> source.  See http://deors.wordpress.com/2011/09/26/annotation-types/ for a
> discussion of how to do that.

it's okay to be concerned about "all the other possible Java use cases" 
and I understand that it would be a long road to fully support the 
toolchains you mentioned.

But this is not the scope of William's current investigations. He's 
interested in improving the support for Java in SCons for the very basic 
usage scenarios. And he has my full support, which doesn't mean a lot 
because I don't have a large Java background but only some basic knowledge.
In the background, I'm working on a recursive Glob() which fully 
supports Ant-like notation. Having this in place, we'd be able to link 
generated Java sources (like in your examples above) into a SCons build 
with commands like "env.Jar('build', Glob('*/**/*.java'))".
So one could at least schedule the generating commands for the *.java 
files to run always, and then let SCons handle the rest.

This would still be far from perfect, but it's better than what we have 
right now. And I, personally, am more interested in the latter. ;)

Just my 2 cents.

Best regards,

Dirk