On 11/14/2014 08:43 AM, Tom Dunstan wrote:
> I think that packaging latest Gradle 2.x should be doable for
> 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
I heard that some build scripts may use features which were removed in
Gradle 2.x. The focus is on latest 2.x version first and then we'll see
if 1.x will be packaged too or not. (I would like to keep only the
latest version in Fedora if possible.)
> AFAIK Gradle is at Java 1.5, but any Jetty version above 6
> 1.6 or newer. Unfortunatelly this alone makes our Jetty patch not
> upstreamable :(
Gradle 2.x requires Java 1.6+ to run. We no longer require Java 1.5.
Great. This will make it possible to use never versions of some
dependencies (like latest Maven 3.2.x).
As for the patch, there have been some discussions about what to do
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 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.
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.
We'll see what to do with Jetty. I brought this problem on our meeting
we decided against packaging packaging Jetty 6. Short term we'll keep
the patch porting to Jetty 9 and print a warning when Jetty plugin is
used. Long-term solution is yet to be decided.
> 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
asking for help has their particular build unambiguously identified.
I believe that versioning should be entirely up to upstream and I will
respect upstream decision in this matter. I will bring this up with
upstream and until I get response I will use standard versioning.
> * Ivy resolvers can't be used in Gradle 2.x any longer (and
> 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
Ivy "resolver" is not the same as Ivy "repository". Resolver API is
pluggable interface for resolving artifacts while repository API barely
defines storage for artifacts.
ArtifactRepositoryContainer of Gradle 1.x provides methods for adding
resolvers (org.apache.ivy.plugins.resolver.DependencyResolver), but they
are marked as @Deprecated. Gradle 2.x doesn't support Ivy resolvers at
all (and AFAIK there is no other API for providing custom code for
> * 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?
In general, I want to override some Gradle code or run some hooks at
given points, without having to patch Gradle code or modify build scripts.
I will give one specific example. Gradle checks if resolved artifact
version matches requested dependency version. Fedora we very often
resolve different version than requested, so this consistency check
needs to be relaxed, but only in gradle-local, standard gradle
installation should remain unaffected.
I've been looking how to achieve such thing in Gradle nicely (without
hacks like injecting private fields with reflection, or patching Gradle
code), but I haven't found anything so far.
In contrast, Maven makes such extensions very easy to write. All I need
to do is to extend class implementing Plexus component which behavior I
want to adjust, override particular method, provide Plexus metadata for
my class and drop JAR in Mavens lib/ext/ directory. Ext directory is on
classpath before standard Maven JARs, so my custom component is used by
Maven instead of standard implementation.
> * 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.
Can you explain or point to a page with the policy rationale here please?
The policy is at:
For rationale see:
> 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.
Do artifact GAVs stay the same?
I don't know what you meant here.
Software Engineer, Red Hat