Self-describing sources: the JavaC patch

[Jaroslav Tulach]

Hello Paul.

Dne Út 10. července 2012 11:50:50, Paul Sandoz napsal(a):
> > The way JavaC and other JDK tools (jmod, jar) understand the sources
> > should be driven by the file layout. Not by (extensively long) command
> > line parameters.
> So a default path for the source-info.cfg, and perhaps default paths for
> source, compilation of and jars/jmods?

Right. I would suggest:
- source-info.cfg would be expected in the working directory of the tool
- all javac build products would be created under build subdir by default
- jar or jmod would generate the result into dist directory
- sources would be expected under src directory

Of course, the actual layout may differ. But there should be defaults, imho.

> >> How would NetBeans differentiate between source and test source?
> > 
> > [1] Please don't imagine Maven,
> :
> :-)
> :
> > we don't need to go that far. In certain
> > systems "project" may not mean code+test. I've seen some systems that have
> > a special project for the sources and other project for tests. I have not
> > noticed any activity on the JDK team side to adhere to 21st century
> > testing standards. And I don't need it. Code can live without tests, in
> > spite what Maven tries to teach us...
> 
> While i had maven in mind i was also thinking more generally e.g. unit-like
> tests are run and need to pass before installing and/or releasing.

We don't need that to have self-describing sources. I don't want to ask the 
Jigsaw or JavaC team too much. But ... if the source-info.cfg is extensible, I 
can imagine testng tool could read its section(s) as well.

> >> Or
> >> differentiate between building a modular jar or a jmod file?
> > 
> > My proposal was suggesting different sections for [jar] and for [jmod]
> > inside a single configuration file. Thta would basically be it, I guess.
> > Details are TDB, first I need to convince JavaC team to even consider
> > this idea, then jar and jmod will be the next target.
> > 
> >> There needs to be an orchestrating meta-tool and configuration, and if
> >> such
> >> a meta-tool exists then is there any point in each tool processing the
> >> configuration file? since the meta-tool can tell the other tools what to
> >> do.
> > 
> > Is not that a matter of abstraction? Maven certainly defines "phases" that
> > abstract from compilation, war, jar packaging, etc. For our purposes, it
> > is
> > essential to know that is it necessary to invoke javac before invoking
> > jmod. But for that we don't need an "orchestrating meta-tool". Enough to
> > hard code it for now.
> 
> OK, just trying to work out what a larger picture might be.

Yeah, I am trying to keep phases out of the scope.

> I suspect any largish project is likely to consist of multiple modules that
> are, where possible, compiled and installed independently in a well-defined
> order. I hope the JDK modularization effort of source restructuring heads
> towards that approach but it may take a while to get there.
> > -jt
> > 
> > PS: Please keep in mind that I am investigating options what will allow
> > NetBeans to support Jigsaw without using Maven. Of course, if Jigsaw team
> > tells us: "Go use Maven", we can get all our meta-information there.
> 
> We need the likes of Jon et. al. to opine on this.

I've put this topic on NetBeans/JavaC agenda for tomorrow's conf call.

> I feel a little under qualified to espouse confidently on this area but it
> seems to me the approach of defaults and options in a source configuration
> file is low enough down in the stack to be flexibly reused by other tooling
> and quite useful for simple Java projects.

I am very pleased to hear that.
-jt