First, thank you for contacting with us, providing feedback and sharing
ideas. I'm glad you wrote - it's quite uncommon for Java upstreams to
see value in having their projects available in Fedora or other
GNU/Linux distributions.
I think that packaging latest Gradle 2.x should be doable for Fedora 22.
I will prepare an official Fedora change for Gadle in Fedora 22.
We also considered packaging 1.x line (as compat package "gradle1"), but
for now my focus was mainly on 2.1. (I will uptade to 2.2 soon.)
The non-free JSON lib is a dependency of XStream. We have reported this
as XSTR-763 [1]. This lib seems to be used during Gradle 2.1 build -
building Gradle pulls it into cache at $HOME/.gradle. This lib is also
hosted in Gradle repo [2]. Perhaps it should be explicitly excluded as
XStream upstream claims it's a test dependency only?
> - Porting to aether-ant-tasks
I have the patch mostly ready. I am definitely going to open a pull
request in future (I've already signed CLA), but the patch needs some
polishing and extra testing first
Gradle exposes maven-model in API. maven-model 2.x and 3.x are mostly
compatible, but not entirely, so I suppose that some third-party plugins
or build scripts would be affected by this change.
Second smaller issue: some internal fields of maven-ant-tasks (like
authentication info) can be injected from DSL. I found out that one
field was renamed from "userName" to "username". I think this should be
solvable without breaking build scripts.
The utlimate goal is to have two installations of Gradle. First
upstream-like, for standard use by Fedora users and second, with some
necessary Fedora-specific extensions enabled. The second installation
would have local repository (xmvn) enabled by default so that we don't
have to patch build scripts of every software we want to build for
Fedora using Gradle.
AFAIK Gradle is at Java 1.5, but any Jetty version above 6 requires Java
1.6 or newer. Unfortunatelly this alone makes our Jetty patch not
upstreamable :(
In case of Jetty 6, from technical PoV we could add it to Fedora, but it
would be against our goals (for many reasons Fedora doesn't want to ship
legacy, unmaintained software). Current solution (porting to Jetty 9) is
definitely not ideal either and I'll try to think of some better way of
solving the problem.
The goal is to enable all stardard plugins. As of now all plugins are
enabled. Only Scala Zinc compiler is disabled, but this should be
eventually fixed.
xmvn repository was added temporarly only, until this problem is solved
the right way. (As I mentioned above, custom repository will be enabled
only in local mode, used only during package build and activated by
running Gradle with a different command, like "gradle-local").
I already tried adding Fedora version suffix, but GradleVersion class
implements strict version checking which rejected my first attempts to
use customized version. But I'll find a way to do this properly.
Do you have any recommendation how the version should look like to
satisfy Gradle versioning rules?
For external integration tests we have Taskotron [1]. It is still in
development and not ready for general use, but once it's ready we can
think of adding Gradle IT suite there. Test dependencies don't have to
be packaged in Fedora. Tasktron tests are ran after in testing phase
(after package is built, but before shipped) or on demand. Failing tests
don't prevent package from being shipped.
In short: with time we'll try to enable as many tests as possible, but
for now we may skip tests to speed up development.
There is xmvn-subst utility, which can be used to replace JAR with a
symlink, assuming that the JAR is coming from Fedora and has Maven
metadata installed.
> Another idea to consider is allowing a user to add the Xmvn repo to their
> buildscript / build classpaths without having to patch their project build
> file. This could be achieved by dropping a file into $GRADLE_HOME/init.d
> which adds the Xmvn repo when a particular system property is set. Another
> system property could disable all other repos - this would be
> building-rpm-mode. See
> http://www.gradle.org/docs/current/userguide/init_scripts.html for an
> example of how to do this.
As explained above, this is the goal, but I don't know yet how it will
be implemented. Most likely a separate Gradle home (sharing all or most
of JARs by symlinking them), with some extensions added.
Maven is a good example of such separation. We ship vanilla Maven (yes,
all our patches have been upstreamed!) in /usr/share/maven. This is used
when you invoke "mvn" command. But during package build "xmvn" command
is invoked instead. It uses Maven home at /usr/share/xmvn, which is
identical to Maven home except that it has Fedora-specific extensions
enabled.
Shading is indeed a big problem, in general. I believe that shading
sould be done only as last resort and that there are better techniques
(like class loaders) to prevent conflicts of different library versions
or leaking of implementation classes through APIs.
I have already unshaded Maven 3 JARs (this was possible after I ported
Gradle not to use maven-ant-tasks). I will look into unshading all
remaining libraries.
* Ivy resolvers can't be used in Gradle 2.x any longer (and are
deprecated in 1.x). There is no public API for defining custom
repository. (My temporary solution: use internal repository APIs.)
* There is no official way for providing Gradle extensions (by extension
I mean addon that modifies Gradle behavior). Long term I think it would
be great if Gradle could use some IoC thechniques to inject
implementation classes, allowing extensions to easily override some
standard Gradle components. (My temporary solution: patch Gradle code.)
* gradle-launcher has "Class-Path" entry in manifest, which is not
allowed in Fedora. I had to patch Gradle launchers to work without this
entry, but I am affraid that there may be third-party launchers that
assume Gradle can be ran with "java -jar gradle-launcher.jar", which
won't work in Fedora. It would be nice if this could somehow be solved
with upstream cooperation.
Fedora "repository" is not a typical artifact repository at all. It
doesn't have a strict layout (artifacts can have arbitrary file names
and be placed at arbitrary locations in the file system). XMvn knows
where to find them by reading special metadada files stored in
/usr/share/maven-metadata/. Besides that we use custom version
resolution scheme, meaning that POMs from Fedora can't be directly used
by Gradle or Maven as they are. Some artifacts don't have POMs at all -
we have to generate effective POM from metadata on demand.