Lost many many hours to this. Stupid ass syntax error with a generic error description.
I couldn’t find where I read the info on the log4j2.xml being under the default package in the distribution jar but I know I read it and it was a one sentence blurb among the hundreds I have read. Searched bing and google and nothing now. I know I didn’t imagine it.
I am trying to understand how to get all the dependencies onto the classpath including local jars and how this line actually works.
The sdk/netbeans default script builds perfectly now so I am trying to get the simethereal task to do the same build but it is missing adding all the implementation configuration and local jars on the classpath.
I would like to read about it in the gradle docs if someone can point to the proper way to implement a solution.
I wonder if it’s lazy-resolving the transitive dependencies. Usually there would be some way to get the resolved list of dependencies. I don’t know if any of that will help your google searching.
You might be able to look into how the regular application plugin sets up its own classpath… but that might take a little digging.
The good thing about Gradle is that it evolves very quickly and almost always for the better… the bad thing about Gradle is that it evolves very quickly and sometimes “better” will break an older build if you aren’t pegging the version with gradlew.
Since I don’t know where your understand falls off… I’ll explain what I know.
‘project’ is the instance of your project. The thing instantiated for your build file. (Hopefully this one was obvious.)
‘configurations’ are the various project configurations for compile, runtime, etc… The things you attach dependencies to, basically. Everything in your “dependency” block will map back to one of these. In newer gradle, the set of available configurations changed a LOT.
‘runtime’ is then the ‘runtime’ Configuration. It’s the set of runtime dependencies… but should have methods/properties for getting just the local dependencies, resolving the transitive dependencies, etc… A long time ago, there were things like runtime.resolve or runtime.resolveTree or something and then they made it easier to work with as the configuration would provide the resolved set.