Gradle in Fedora
by Tom Dunstan
(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
8 years, 10 months
eclipse for EPEL7
by Orion Poplawski
Is there any interest in building eclipse for EPEL7?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
8 years, 10 months
Gradle and Groovy in Fedora 22
by Mikolaj Izdebski
(For those who may not know, Gradle is a popular build automation tool
written in Java and Groovy. Fedora used to have partial Gradle 1.0 with
several plugins disabled, but it was retired in Fedora 20.)
For the past two months I've been working on bringing Gradle back to
Fedora and today I am happy to announce that latest upstream Gradle
release (2.2) is now available in rawhide. All modules and plugins are
enabled. Local mode is implemented, which means that packages which use
Gradle as their build system can now be built easily.
Together with Gradle I have finally updated Groovy to latest upstream
version (2.3.7). There may be some incompatibilities with previously
packaged version (1.8.9), but there is groovy18 compat package available
for people that require compatibility with Groovy 1.x.
I am planning to submit Gradle as a feature for Fedora 22. It will
include packaging guidelines describing the way of building packages
using Gradle, but for now you can get in tuch with me if you want to use
Gradle to build packages.
--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
8 years, 10 months
qdox update in rawhide (#1157630)
by Mikolaj Izdebski
Next week I am going to update qdox to upstream version 2.0-M2 in
rawhide (f22). Current version in rawhide is 1.12.1.
List of packages that depend or build-depend on qdox and therefore are
possibly affected by this update follows.
annogen
fop
hamcrest
hamcrest12
jboss-logmanager
jibx
jing-trang
maven-javadoc-plugin
maven-plugin-tools
paranamer
plexus-cdc
plexus-containers
plexus-digest
xbean
--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
8 years, 10 months
Eclipse Luna on Fedora 21 and JDK 8 requirement
by Sudhir Khanger
On Fri, Oct 31, 2014 at 12:18 PM, Aleksandar Kurtakov
<akurtako(a)redhat.com> wrote:
> Besides many technical reason the biggest one is non-technical in my eyes - no one volunteered to do it. You know it's always a matter of "who will do the work?". I'm pretty sure that if someone jumps in and say "Hey, I'll maintain Java 6, fix problems/adopt Java 6 to changes in the OS if neeeded, help strengthen the switching between JREs, go through the Java projects(shipped in Fedora) and help them properly set their targets in build scripts so builds properly work on Java 6 and etc" there will be no objection to having Java 6. :)
I installed JDK 7 but Eclipse won't work with JDK 7 on F21 [1]. Why
does it require explicitly OpenJDK 8? Can we not have it search Java
on system? On Arch Linux, packages search for java-environment or
java-environment >= 7?
Do I have to build Eclipse myself if I want to use JDK 7?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1123853
--
Regards,
Sudhir Khanger,
sudhirkhanger.com,
github.com/donniezazen,
5577 8CDB A059 085D 1D60 807F 8C00 45D9 F5EF C394.
8 years, 10 months
