On Wed, Nov 12, 2014 at 8:59 PM, Mikolaj Izdebski <mizdebsk(a)redhat.com>
First, thank you for contacting with us, providing feedback and
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
Credit on our end goes to Hans (whom I left off the original CC list,
whoops) for driving it.
It's a win-win though - we want people to use Gradle, and one of the things
that they will want to do is build software that can be packaged in Fedora
/ RHEL / Centos / SL / etc. We don't want Gradle to be an impediment to
On a personal note I used Fedora (and RHL before that) as my primary
desktop for many years, so seeing Gradle as part of that ecosystem makes me
I think that packaging latest Gradle 2.x should be doable for Fedora
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.)
Honestly I reckon if you've got projects whose build scripts are designed
for Gradle 1.x, it'll be less work to update their build file to be Gradle
2.x compatible than package another version of Gradle. Some stuff was
deprecated when we moved to 2.x, but not all that much stuff for most
The non-free JSON lib is a dependency of XStream. We have reported
as XSTR-763 . 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 . Perhaps it should be explicitly excluded as
XStream upstream claims it's a test dependency only?
OK, I'll see if I can track this down.
> - 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
compatible, but not entirely, so I suppose that some third-party plugins
or build scripts would be affected by this change.
Yeah, this is non-ideal. Generally over time we try to isolate these sorts
of APIs and replace them with internal interfaces, but it's a work in
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
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.
That sounds great.
AFAIK Gradle is at Java 1.5, but any Jetty version above 6 requires
1.6 or newer. Unfortunatelly this alone makes our Jetty patch not
Gradle 2.x requires Java 1.6+ to run. We no longer require Java 1.5.
As for the patch, there have been some discussions about what to do with
the Jetty plugin. Just upgrading the Jetty version could break existing
builds, and there are external plugins that support multiple versions
anyway. You could submit the patch, but I'm honestly not sure what the
answer would be right now.
In case of Jetty 6, from technical PoV we could add it to Fedora, but
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.
Well I'd love a creative idea, but on the one hand we've got users for whom
an upgrade could break their build due to differences between Jetty 6 and 9
(his goes for any other Jetty version too), and on the other we've got
Fedora not wanting to ship and maintain ancient code. Not sure how to solve
FWIW it doesn't require a full Jetty distribution, just the jetty jars to
run it up embedded inside Gradle. It's mostly used for integration testing
web app projects. I don't know if that changes the maintenance burden
regarding security errata etc though.
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
xmvn repository was added temporarly only, until this problem is solved
the right way. (As I mentioned above, custom repository will be
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
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?
The GradleVersion class allows things such as '1.0-milestone-5a' and
'2.2-rc-2', but the allowed "stage" strings are hardcoded. I'll see
can come up with something that allows a distributor to set it to something
custom. I presume we'll want it to look like e.g. '2.2-f22-17' where 17
would be the rpm spec version. Then the vender specific part could be
adjusted to reflect the distributor, e.g. 'f22', 'el7' etc, and so a user
asking for help has their particular build unambiguously identified.
For external integration tests we have Taskotron . 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.
This is good news. Please let me know when you are ready to do this, and I
can assist with some of the test setup.
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
OK, so maybe that's not worth doing if there's an easy way built into the
tools that you're already using.
> Another idea to consider is allowing a user to add the Xmvn repo
> buildscript / build classpaths without having to patch their project
> 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.
> system property could disable all other repos - this would be
> building-rpm-mode. See
> 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"
is invoked instead. It uses Maven home at /usr/share/xmvn, which is
identical to Maven home except that it has Fedora-specific extensions
That's one way to do it. Gradle does have a method to customise things at
runtime for a whole distribution though - the init.d directory in the
gradle home dir. So you could enable your customisations by dropping a
script in there whose functions are guarded by e.g. looking for a specific
system property, and then set that property in the gradle-local script. So
a separate install dir may not be necessary. Maybe :)
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.
As above we are trying to remove various "accidental" third party APIs from
visibility over time.
I have already unshaded Maven 3 JARs (this was possible after I
Gradle not to use maven-ant-tasks). I will look into unshading all
Yeah lots and lots of the jarjars in our distribution were related to maven.
* 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.)
Where are you trying to do this from? It's certainly possible to create an
ivy repo in a build file. Do you mean that there's no non-DSL way to build
* There is no official way for providing Gradle extensions (by
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.)
Well, there are plugins, but those won't help you if you're trying to
change where plugins might be loaded from :)
What specifically do you want to do?
* gradle-launcher has "Class-Path" entry in manifest, which
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.
Can you explain or point to a page with the policy rationale here please?
I'm not sure about third party launchers... I presume the IDEs probably
construct their own classpaths.
Fedora "repository" is not a typical artifact repository at
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.
Do artifact GAVs stay the same?