Well the problem is, the wrapper would require us to check in a jar and that’s
a no-go for an Apache release.
There seems to be long-going discussions on the maven-wrapper page about such a
no-deps update. Right now, I think the most promising solution would be to
extend the mvnw scripts to check if the jar is present and if it’s not, to
compile a single java class and run it locally. This would then download the
jar and place it where the wrapper expects it to be. In that case only sources
would be checked in and the only dependency needed would be to have a JDKs bin
directory on the systems path (Which is needed for almost everything else
anyway).
Unfortunately, I am totally at war with platform (independent) shell-scripts.
Sort of have the same love for them as for regular expressions ;-)
Volunteers to look into this?
Chris
Am 12.07.17, 14:34 schrieb "Dale LaBossiere" <dml.apa...@gmail.com>:
The wrapper sounds like a win (we currently leverage the gradle wrapper to
ease the pain).
I’m continuing to tweak the script for j7/android.
> On Jul 11, 2017, at 5:07 PM, Christofer Dutz <christofer.d...@c-ware.de>
wrote:
>
> I'm not demanding the assembly ... It was just the last missing part in
the migration to Maven. Most ASF projects provide such convenience binary
archives, but an ASF release is the source only anyway.
>
> I admit that your script would do the job.
>
> Another thing worth looking into might be the Maven wrapper, which would
eliminate the need to download Maven, as someone not wanting to use Maven would
have to install Maven in order to NOT use it afterwards ;-) ... Users using
Maven wouldn't use the script.
>
> Chris
