Hi Mikolaj
On Wed, Nov 12, 2014 at 8:59 PM, Mikolaj Izdebski <mizdebsk@xxxxxxxxxx> wrote:
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.
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 that.
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 happy. :)
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.)
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 builds.
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?
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
Great!
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.
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 progress :)
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.
Yeah probably.
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 Java
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.
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 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 that.
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
eventually fixed.
Great!
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").
Also great!
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?
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 if we 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 [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.
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.
Of course.
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.
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 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.
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 ported
Gradle not to use maven-ant-tasks). I will look into unshading all
remaining libraries.
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 one?
* 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.)
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 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?
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 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?
Thanks
Tom
-- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
