(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
-- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
