[Scons-dev] Java Development

[William Blevins]

>
> 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'))".


The JavaDirBuilder already handles this really, but having a recursive Glob
could be a very powerful tool in general.  You can build Java like Java(
'build', 'someDirTree' ) and javac with be invoked with all *.java files in
the directory tree.  I think this builder is in SCons/Tools/__init__.py.
 I'm not sure how it works, but you may find that useful.

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


I am actually trying to overhaul how the emitter for Java behaves.  I think
that a new Node class similar to the Dir node will be required.  The plan
is to make this Node a "container" of sorts and have the builder populate
the container on success.  So now the container.up_to_date (real method
name here) will be able to handle this based on its contents.  I realize
that the DAG will be technically incomplete prior to the first build, but
afterwards, it will be complete and rerunning would not necessarily require
a rebuild.  This would also fix recursive dependency problems with the java
tools and reduce class group dependencies from O( n * m ) to O( 1 ) in
cases where class blob A depends on class blob B.  I might not be able to
get it to work.  I don't know if the current SCons builder framework can
support this notion, but hopefully, we can humor the thought long enough to
find out.

V/R,
William


On Sat, Aug 2, 2014 at 4:45 AM, Dirk Bächle <tshortik at gmx.de> wrote:

> 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
>
>
>
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> http://two.pairlist.net/mailman/listinfo/scons-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20140802/556ee146/attachment.html>