8:05 p.m.
(resending as I wasn't properly subscribed to the list, sorry for those
getting it twice, please reply to this one to set reply headers correctly)
Hi all
After a few emails going around a couple of weeks ago, I would like to
re-kick-off a discussion about how to get a functional Gradle build into
Fedora. Given the recent Fedora 21 beta, it also seems like a good time to
try to work out what might be achievable for Fedora 22.
I've had a look at both the plan (
https://fedoraproject.org/wiki/User:Mizdebsk/PackagingGradle) and Mikolaj's
work here https://github.com/mizdebsk/gradle-packaging, which look great,
and seems like a sane path to getting Gradle into Fedora.
Feedback
---
Some feedback on the existing TODO list and work done so far:
- TODO item "report usage of non-free JSON library (org.json:json)" - we
no longer use this
- Porting to aether-ant-tasks - we would probably accept a pull request to
upstream this, as we'll need to do it at some point anyway. There may be
some work on our end to work out / around any differences between the
implementations. Has the Fedora Java team found much in the way of
incompatibility when porting between the two?
- Disabling the analytics plugin - this is disabled in Gradle 2.2, which
was just released.
- Local mode / xmvn integration - this looks a lot cleaner than the gradle
1.0 patches! I wonder if it would be possible to add the /usr/share/java
repo without patching gradle itself - maybe using a local init script to
add the repo when doing a Fedora build. But then the repo wouldn't be
available outside the Fedora build process.
- Upgrading Jetty. Mostly we're pointing people to use the external Gretty
plugin. See below for concerns.
One concern that we have is that any user-visible changes made to Gradle
will result in non-portable build scripts. A user using e.g. Gradle 2.2
that they installed using yum will end up using Jetty 9, which is very
different to the Jetty 6 that users of the standard Gradle distribution
will use. This may then cause issues for users using the standard
distribution to build the target project. The same goes for any plugins
that might not be enabled (there were lots of these in the earlier
Fedora-Gradle 1.0 patches), or non-standard repositories such as xmvn.
While we would obviously prefer perfect compatibility, I can certainly
understand not wanting to keep older versions of certain packages around
forever in Fedora. It would be nice if, when using different packages such
as Jetty, a warning were emitted in the build to notify the user that they
are using a different version to the normal Gradle distribution and that
the build may be non-portable.
Another thing to consider would be modifying the version string to include
"-fedora" or -"rpm" or something like that so that users with issues
turning up at forums.gradle.org can report when they're using the rpm-based
distribution. Is there a standard Fedora policy for doing such things?
Testing
---
We have a large set of tests that we run as part of our continuous
integration and release processes. These tests take some hours to complete.
It looks like at least some rpm specs in fedora have the ability to run
bundled tests. What is the policy for when these tests are run? Does the
fedora build machinery run full test suites even if they take that long? We
would really like to see the full set of tests run against the patched
Gradle to get some level of confidence that the patches applied have not
harmed build compatibility.
Opportunities / Ideas
---
One idea that came to mind was enhancing the application plugin to create
application distributions that have symlinks to the correct jar inside
/usr/share/java rather than copying the jar into the distribution - that
might make life easier for devs / packagers trying to package Gradle-built
java applications.
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.
Questions
---
Are you folks aware of particular packages that Gradle uses or other issues
that are likely to cause problems while iterating through phase 3 of the
bootstrap plan? In particular if there's anything that we can do to help
that process along, it would be good to know about it. One that leaps to
mind is "shading" dependent libraries - we do this in a few places to stop
the api available to the buildscript from being polluted.
Although I guess it's a little bit off-topic for this list, do you know if
the Xmvn repo structure is compatible with debian's /usr/share/maven-repo?
How different is the Xmvn repo from a normal maven or ivy repo on the
filesystem?
Thanks, and please let me know of your thoughts
Regards
Tom
--
Tom Dunstan
tom.dunstan(a)gradleware.com