[GRADLE-340] Make sourceCompatibility and targetCompatibility optional with reasonable defaults Created: 29/Dec/08  Updated: 04/Jan/13  Resolved: 23/Mar/09

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: 0.6

Type: Improvement
Reporter: Adam Murdoch Assignee: Hans Dockter
Resolution: Fixed Votes: 3


 Comments   
Comment by Jon Cox [ 23/Jan/09 ]

A good suggestion I think, but is it a major bug?
For me, being forced to set these values too annoying
to be trivial, but given that the mommy project can set it for
all the sub-projects, it's not all that much of a hassle.

What makes it major-ly painful for you?
"It's a pet peeve" is a perfectly reasonable answer,
but I'm curious to see if there's more to it.
Perhaps your usage pattern is different somehow.

Comment by Adam Murdoch [ 23/Jan/09 ]

Nothing, major is just the default priority.

Comment by Spencer Allain [ 10/Feb/09 ]

I guess the issue might be a matter of documentation , design philosophy, and/or convenience.

Some folks would likely be extremely happy if all they had to do was lay out their files according to the directory structure, and create a build.gradle file with just

usePlugin("java")

Unfortunately, the Java Plugin section of the documentation does not provide a simple example of the minimal amount of things that need to be set to compile and build a jar for a java project. Below is all that's needed to make use of all of the targets (version isn't need until libs, and the two Compatibility ones are for compile)

usePlugin("java")
sourceCompatibility=1.6
targetCompatibility=1.6
version=""

Source and target can be inferred easily (you know the version from the JDK being used, and ant already knows it as well). Version also could be default to the empty string.

Granted this might not be the intent for larger scale development, especially since version numbers are recommended on jar files.

An alternative would simply be to ensure that there is a Java Plugin Hello World build.gradle example containing much of the information displayed above.

The important aspect is making sure that errors do not occur for the novice attempting to utilize the tool, and that's currently what's lacking. I personally really thought I could just do the simple one liner usePlugin until the errors started spitting out.

I would have been happier with a warning that told me what it was defaulting them to, so that I was encouraged to set them manually, rather than it complain that the build failed with an exception.

One or more of these changes should be enacted:
1. The documentation should be updated so that anyone attempting to use the Java Plugin has an example showing the minimum properties to set
2. The error should be changed to a warning that spits out the values it is using as defaults
3. There should be no errors or warnings and it uses defaults like I mention above.

I'm not going to presume whether 1, 1 and 2, or 1 and 3 need to be implemented, but I highly recommend at least 1.

Comment by Russel Winder [ 27/Feb/09 ]

I vote that this becomes a must for 0.6.

I think "version =" is already optional, but having to specify (source|target)Compatibility is just irritating.

Comment by Szczepan Faber [ 27/Feb/09 ]

I don't mind explicit java compatibility in my build file. The default version will deprecate at some point and we will have to specify it explicitly anyway (see maven compiler plugin - it defaults to java 1.3). I bet most build masters would prefer explicit setting.

Hmmm, last time I tried the 'version' was still mandatory - personally I like it this way. It gives better chance for the jars to be consistently named across projects. If you're about to default it I vote for meaningful '0.1' or something similar.

I think java compatibility warning may be hard to notice in the output + most people would probably ignore it anyway. Just like almost everyone ignores maven checksum warnings / relocation warnings, etc.

To me, documentation on mandatory java plugin settings is supplementary. Gradle is doing great job failing fast and telling me what things I'm missing in my build.gradle.

Anyway, it's just my 2 pence and whatever you guys implement in gradle - I'll just play along

Oh, my little suggestion on compiler settings is something like 'javaCompatibility' that combines both target & source in single entry.

Comment by Russel Winder [ 23/Mar/09 ]

Adam,

It might be worth noting here what the defaults are set to just for completeness.

Thanks.

Comment by Adam Murdoch [ 27/Mar/09 ]
  • sourceCompatibility defaults to 1.5
  • targetCompatibility defaults to sourceCompatibility
Generated at Wed Jun 30 11:27:39 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.