[Scons-dev] SCons and Java

[William Blevins]

Team,

I have a couple points I'd like to discuss, but for the sake of
organization, I intend to split them into separate emails.

Java Part #2

There has been some discussion on making Scons more ANT-like,
http://www.scons.org/wiki/JavaSupport, and that might solve some issues
like identifying Java targets.  There is merit here assuming that Java
support stays SCons-like at the same time; otherwise, why not just use ant
or maven?

Problem(s) this will solve:
1. Determining the source -> target(s) from *.java -> *.class is painful,
possibly java version dependent, and performance intensive (possibly);
thus, we should optimize this out.
2. Java developers are plagued requiring manual cleaning of a jar far too
often with ant-like system(s) and the current scon(s) methodology.
   1. Clean could be required when deleting or moving a file since the last
build output isn't removed otherwise; avoidable in current SCons depending
on how sources are specified (not obvious and/or intuitive coming from
ant-like system(s)).
3. Simplify the SCons Java API to allow building jar file(s) without having
to interact with *.class file(s) at all.
4. Simplify the SCons Java support for resource file(s); currently, you
have to do copying by hand (if it's supported I know not where or how).
5. Reduce the amount of code required to build a jar (by a lot).

How I imagine this should work:
1. Treat class file(s) like side-effect(s) and do not include them (at all)
in the dependency tree.
    1. This means we don't have to scan the Java file(s) and determine
*.class targets.
2. Remove the Java(...) function from SCons; thus, do not interact with
*.class file(s) directly ever.  There isn't a *good* reason to do this.
3. Update the Jar function (or new name) to something like:
    1. Jar( sources = <Glob(*.java) compiled sources and ! *.java resources
to be copied>, target = <output jar name/destination>, outputDir = <the tmp
working directory>, isOutputDirRemoved = <true/false> )

*Example setup*:

1. Source tree:

src/org/example/a.java
                       /b.java
src/org/resources/x.png
                         /y.png
src/org/config/n.xml

2. SConscript

Jar( sources = 'src', target = '#jar/example.jar' ) // assume some smart
auto-generated unique outputDir name

3. Dependency tree generation expectations for the example

#jar/example.jar
|
- all *.java in 'src'
|  |
|  - javac
|  - <all item(s) in JAVACLASSPATH: should probably restrict to only
*.class and *.jar (anything else?)>
|
| - <all ! *.java in 'src' which implies resources or other>

*Use Case(s)*
*Note: each case starts in the final state of the previous use case.*

1. Build from scratch
    1. Compile *.java in sources into outputDir: 'javac -classpath *.java'
    2. Copy ! *.java in sources into outputDir: use SCons copy factory
    3. Create the jar of all contents in outputDir as target
    4. *Maybe* delete outputDir since this is a side-effect directory only

2. Build with no changes
    1. SCons builds no targets.

3. Build with changes to a file in src, new file in src, removed file in src
   1. Delete outputDir (IE. if not removed in case 1.4).
   2. Perform steps 1.X.

4. Change JAVACLASSPATH, target is removed.
   1. Perform steps 3.X.

5. Delete the outputDir (if not removed).
   1. SCons builds no targets.

6. Clean
    1. Perform steps 3.1.
    2. Remove the target.

*This is an example set; feedback wanted.*

V/R,
William


On Mon, May 26, 2014 at 1:11 PM, anatoly techtonik <techtonik at gmail.com>
wrote:

> I'd say that as long as everything discussed here ends up in pull requests,
> all such discussions are welcome. As particular Java problem, I miss an
> overview of the problems that need to be solved for this domain.
>
> On Sat, May 24, 2014 at 6:27 AM, William Blevins <wblevins001 at gmail.com>
> wrote:
> > SCons Team,
> >
> > I've been using SCons for a couple years now and I have some thoughts
> about
> > the Java toolkit.
> >
> > I know that there has been consideration for revamping the Java toolkit
> and
> > I was wondering if anyone would be open to constructive feedback.
> >
> > Firstly, I'd like to say that SCons is a fantastic toolkit, and I would
> like
> > to help bring the Java portion up to par with the support for c-like
> > languages.  I have always been underwhelmed by ANT-like builders and I
> think
> > SCons has a great start to be something better.
> >
> > Would this be an appropriate place for discussion or should I use the
> > scons-user list (or other) instead?
> >
> > V/R,
> > William
> >
> > _______________________________________________
> > Scons-dev mailing list
> > Scons-dev at scons.org
> > http://two.pairlist.net/mailman/listinfo/scons-dev
> >
>
>
>
> --
> anatoly t.
> _______________________________________________
> 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/20140529/9694004b/attachment.html>