Spec URL: http://gil.fedorapeople.org/gradle.spec SRPM URL: http://gil.fedorapeople.org/gradle-1.0-1.fc16.src.rpm Description: Gradle is a build system written in Groovy. It uses Groovy also as the language for its build scripts. It has a powerful multi-project build support. It has a layer on top of Ivy that provides a build-by-convention integration for Ivy. It gives you always the choice between the flexibility of Ant and the convenience of a build-by-convention behavior.
Spec URL: http://gil.fedorapeople.org/gradle.spec SRPM URL: http://gil.fedorapeople.org/gradle-1.0-2.fc16.src.rpm - add changelog - built apis documentation
depend on https://bugzilla.redhat.com/show_bug.cgi?id=806680 https://bugzilla.redhat.com/show_bug.cgi?id=806670
The Release tag does not state the proper upstream tag as per https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_packages.
Spec URL: http://gil.fedorapeople.org/gradle.spec SRPM URL: http://gil.fedorapeople.org/gradle-1.0-3.fc16.rc.1.src.rpm - update to 1.0-rc-1 - fix Release tag
Spec URL: http://gil.fedorapeople.org/gradle.spec SRPM URL: http://gil.fedorapeople.org/gradle-1.0-2.fc16.rc.1.src.rpm - fix Release tag in changelog entry - applied PATCH18 remove some mvn2 references
The release tag is still incorrect. Final version should be something like: 1.0-0.1.rc1 You should not put it after %{?dist} and you should preserve update paths all the time.
Spec URL: http://gil.fedorapeople.org/gradle.spec SRPM URL: http://gil.fedorapeople.org/gradle-1.0-3.rc.1.fc16.src.rpm - edit Release tag
It was not an accident that I put release tag as: 0.1.rc1 Let's keep your release tag and see what happens: You package gradle-1.0-3.rc.1.fc16 Upstream releases final package, you package it and you would have to reset release tag since it's new upstream, so you get: gradle-1.0-1.fc16 $ rpmdev-vercmp gradle-1.0-3.rc.1.fc16 gradle-1.0-1.rc.2.fc16 gradle-1.0-3.rc.1.fc16 > gradle-1.0-1.fc16 So you break upgrade path. Instead you should have: gradle-1.0-0.1.rc1.fc16 Then with new upstream: gradle-1.0-1.fc16 In case there would be rc2: gradle-1.0-0.1.rc2.fc16 so we would have: $ rpmdev-vercmp gradle-1.0-0.1.rc1.fc16 gradle-1.0-0.1.rc2.fc16 gradle-1.0-0.1.rc1.fc16 < gradle-1.0-0.1.rc2.fc16 And everything keeps working. If the upstream would release something that would break upgrade path before releasing final 1.0, you can just raise release from 0.1.X to 0.2.X and continue. Don't forget to check with rpmdev-vercmp in between.
Spec URL: http://gil.fedorapeople.org/gradle.spec SRPM URL: http://gil.fedorapeople.org/gradle-1.0-0.3.rc.1.fc16.src.rpm - edit Release tag sorry for the incovenience
Spec URL: http://gil.fedorapeople.org/gradle.spec SRPM URL: http://gil.fedorapeople.org/gradle-1.0-0.1.rc.2.fc16.src.rpm - update to 1.0-rc-2
Spec URL: http://gil.fedorapeople.org/gradle.spec SRPM URL: http://gil.fedorapeople.org/gradle-1.0-0.2.rc.2.fc16.src.rpm - rebuilt with guava-libraries support
Spec URL: http://gil.fedorapeople.org/gradle.spec SRPM URL: http://gil.fedorapeople.org/gradle-1.0-0.3.rc.2.fc16.src.rpm - rebuilt with guava 11.0.2 support - remove guava-libraries references
Spec URL: http://gil.fedorapeople.org/gradle.spec SRPM URL: http://gil.fedorapeople.org/gradle-1.0-0.9.rc.3.fc16.src.rpm - update to 1.0-rc-3
Spec URL: http://gil.fedorapeople.org/gradle/gradle.spec SRPM URL: http://gil.fedorapeople.org/gradle/gradle-1.0-0.10.rc.3.fc16.src.rpm - Add maven 3 support patch from Marek Goldmann
Spec URL: http://gil.fedorapeople.org/gradle/release/1.0-1/gradle.spec SRPM URL: http://gil.fedorapeople.org/gradle/release/1.0-1/gradle-1.0-1.fc16.src.rpm - update to 1.0
Spec URL: http://gil.fedorapeople.org/gradle/release/1.0-2/gradle.spec SRPM URL: http://gil.fedorapeople.org/gradle/release/1.0-2/gradle-1.0-2.fc16.src.rpm - bootstrap mode - correct PATCH17 thanks to mizdebsk - correct wrapper script thanks to mgoldmann
Version 1.0-2 fails to build in mock: http://koji.fedoraproject.org/koji/taskinfo?taskID=4246613
> Version 1.0-2 fails to build in mock: http://koji.fedoraproject.org/koji/taskinfo?taskID=4246613 Spec URL: http://gil.fedorapeople.org/gradle/release/1.0-2/gradle.spec SRPM URL: http://gil.fedorapeople.org/gradle/release/1.0-2/gradle-1.0-2.fc16.src.rpm fixed see http://koji.fedoraproject.org/koji/taskinfo?taskID=4246858
Instead of adding new deps I would focus on getting this package reviewed.
New koji scratch build after making the package arch independent: http://koji.fedoraproject.org/koji/taskinfo?taskID=4365510
Spec URL: http://gil.fedorapeople.org/gradle/release/1.0-3/gradle.spec SRPM URL: http://gil.fedorapeople.org/gradle/release/1.0-3/gradle-1.0-3.fc16.src.rpm - Added some missing build/requires - Cleaned up spec file tested on: http://koji.fedoraproject.org/koji/taskinfo?taskID=4377069
Likely duplicate of bug #542222 It looks like gradle is already in Fedora: https://admin.fedoraproject.org/pkgdb/acls/name/gradle And gil is aware of that: http://lists.fedoraproject.org/pipermail/scm-commits/2012-July/833978.html
Mikolaj, It seems that the previous gradle package is a half (or even less) backed solution. It build only the open-api module, which is very confusing. Maybe that's why I missed it. Since the gradle package is already in Fedora, we need to contact lkundrak and ask him to approve co-maintaning this package. The formal review is not needed in this case, but it would be very nice if someone could do it, since this is a complete rewrite of the spec.
0009-Use-proper-system-environment-variables.patch incorrectly modifies the getUserHome() method, causing Gradle to resolve the user's home directory as null. The patch changes the call: System.getProperty("user.home") to: System.getenv("user.home") There is no such environment variable named user.home. Therefore, Gradle resolves the user's home directory as null. As a result, the .gradle directory is created inside a directory named null in the current working directory (i.e., null/.gradle) whenever you run the gradle command. This part of the patch should be reverted.
hi, you "must" set this variable with -g option -g, --gradle-user-home Specifies the gradle user home directory. $ gradle --help USAGE: gradle [option...] [task...] -?, -h, --help Shows this help message. -a, --no-rebuild Do not rebuild project dependencies. -b, --build-file Specifies the build file. -C, --cache Specifies how compiled build scripts should be cached. Possible values are: 'rebuild' and 'on'. Default value is 'on' [deprecated - Use '--rerun-tasks' or '--recompile-scripts' instead] -c, --settings-file Specifies the settings file. --continue Continues task execution after a task failure. [experimental] -D, --system-prop Set system property of the JVM (e.g. -Dmyprop=myvalue). -d, --debug Log in debug mode (includes normal stacktrace). --daemon Uses the Gradle daemon to run the build. Starts the daemon if not running. --foreground Starts the Gradle daemon in the foreground. [experimental] -g, --gradle-user-home Specifies the gradle user home directory. --gui Launches the Gradle GUI. -I, --init-script Specifies an initialization script. -i, --info Set log level to info. -m, --dry-run Runs the builds with all task actions disabled. --no-color Do not use color in the console output. --no-daemon Do not use the Gradle daemon to run the build. --no-opt Ignore any task optimization. [deprecated - Use '--rerun-tasks' instead] --offline The build should operate without accessing network resources. -P, --project-prop Set project property for the build script (e.g. -Pmyprop=myvalue). -p, --project-dir Specifies the start directory for Gradle. Defaults to current directory. --profile Profiles build execution time and generates a report in the <build_dir>/reports/profile directory. --project-cache-dir Specifies the project-specific cache directory. Defaults to .gradle in the root project directory. -q, --quiet Log errors only. --recompile-scripts Force build script recompiling. --refresh Refresh the state of resources of the type(s) specified. Currently only 'dependencies' is supported. [deprecated - Use '--refresh-dependencies' instead.] --refresh-dependencies Refresh the state of dependencies. --rerun-tasks Ignore previously cached task results. -S, --full-stacktrace Print out the full (very verbose) stacktrace for all exceptions. -s, --stacktrace Print out the stacktrace for all exceptions. --stop Stops the Gradle daemon if it is running. -u, --no-search-upward Don't search in parent folders for a settings.gradle file. -v, --version Print version info. -x, --exclude-task Specify a task to be excluded from execution.
Spec URL: http://gil.fedorapeople.org/gradle/release/1.0-3/gradle.spec SRPM URL: http://gil.fedorapeople.org/gradle/release/1.0-3/gradle-1.0-3.fc16.src.rpm(In reply to comment #24) > 0009-Use-proper-system-environment-variables.patch incorrectly modifies the > getUserHome() method, causing Gradle to resolve the user's home directory as > null. > > The patch changes the call: > > System.getProperty("user.home") > > to: > > System.getenv("user.home") > > There is no such environment variable named user.home. Therefore, Gradle > resolves the user's home directory as null. As a result, the .gradle > directory is created inside a directory named null in the current working > directory (i.e., null/.gradle) whenever you run the gradle command. > > This part of the patch should be reverted. Spec URL: http://gil.fedorapeople.org/gradle/release/1.0-3/gradle.spec SRPM URL: http://gil.fedorapeople.org/gradle/release/1.0-3/gradle-1.0-3.fc16.src.rpm done
That solves the problem, but I'm not comfortable with how the change was made. Why not just remove the first hunk from patch 0009-Use-proper-system-environment-variables.patch rather than reversing the patch in the spec file using sed? I think the use of sed inside the spec file instead of fixing the patch introduces unnecessary complexity. Is the package source available in a git repository anywhere? I think that would help move the package along if those of use using and testing it could collaborate through the source repository. One idea is to use a development branch on the existing gradle package repository (http://pkgs.fedoraproject.org/cgit/gradle.git/) until the package source is ready to merge into one of the main branches. However, I'd settle for the source code being in any git repository anywhere in the short term.
In reply to comment #25, I don't agree that the user has to specify their home directory using -g when using gradle. That would be a rather unreasonable requirement for a build tool. The reason that flag exists is likely to allow the user to specify an override, if they so desired. In the Gradle documentation it says: "-g, --gradle-user-home Specifies the Gradle user home directory. The default is the .gradle directory in the user's home directory." and also "the Gradle user home directory (defaults to USER_HOME/.gradle)"
I'm now able to reenable the Maven plugin on Fedora 18. Here's a patch containing the changes I made to to reenable it: https://gist.github.com/1efc24d4838f8b2652c0 I verified it worked after installing by copying the subprojects/docs/src/samples/java/quickstart outside the gradle source code and building it using gradle build. The Java quickstart project resolves several dependencies from Maven central.
I have pushed the patches *I converted* to Git here: https://github.com/goldmann/gradle/tree/fedora-gradle-1.0 Feel free to fork and work on it.
One more thing; you can generate the patches using this command: git format-patch --no-numbered --no-signature REL_1.0..HEAD
(In reply to comment #29) > I'm now able to reenable the Maven plugin on Fedora 18. > > Here's a patch containing the changes I made to to reenable it: > > https://gist.github.com/1efc24d4838f8b2652c0 > > I verified it worked after installing by copying the > subprojects/docs/src/samples/java/quickstart outside the gradle source code > and building it using gradle build. The Java quickstart project resolves > several dependencies from Maven central. for the moment i haven't this intentions, the maven3.x support for gradle is available in the new gradle version 1.1. the reason is: gradle use maven-ant-tasks and there are incompatible apis with mvn 3 and we intend for now use the gradle 1.0 for build the next releases
Spec URL: http://gil.fedorapeople.org/gradle/release/1.0-4/gradle.spec SRPM URL: http://gil.fedorapeople.org/gradle/release/1.0-4/gradle-1.0-4.fc16.src.rpm - used task assemble in non bootstrap mode - fixed javadoc build - fixed incorrectly modifies the getUserHome() method (RHBZ #809950#c24) - removed libicns-utils support
Thanks for creating/point me to the repo Marek. I'll connect that up to my local git repo so we can stay in sync. Also, thanks for the tip on how to create the patch correctly. gil, thanks for updating the patch and spec. I'm curious about the decision to not add the Maven plugin until Gradle 1.1.I don't see where the incompatibility is. Could you provide an example that shows where it breaks? IMO, Gradle isn't very useful w/o the Maven plugin. We can chat about it on the mailinglist if that's more appropriate.
hi Dan, see http://issues.gradle.org/browse/GRADLE-2210 and try to build maven-ant-tasks 2.1.3 with maven 3 if you use dependencies from Maven central you dont see nothing... you must use the maven JPP local repository otherwise gradle download all required libraries, even those i/you/we(fedora) do not want. such as maven 2.2.1 etc. more part of gradle maven plugin are removed with mgoldmann patches
Hi, all. Marek had asked me to review this package a couple of weeks ago. I should have time for it this week, but there's a lot of activity here, and I want to make sure I'm looking at the latest code and that there aren't more changes pending. let me know.
hi Andy, the latest package is here http://gil.fedorapeople.org/gradle/release/1.0-4/gradle-1.0-4.fc16.src.rpm thanks regards
tested on: http://koji.fedoraproject.org/koji/taskinfo?taskID=4469048
Package Review ============== Key: - = N/A x = Pass ! = Fail ? = Not evaluated ==== Generic ==== [x]: EXTRA Rpmlint is run on all installed packages. gradle.src: W: spelling-error %description -l en_US multi -> mulch, mufti gradle.noarch: E: explicit-lib-dependency aqute-bndlib gradle.noarch: E: devel-dependency java-devel gradle.noarch: W: spelling-error %description -l en_US multi -> mulch, mufti gradle.noarch: W: dangling-symlink /usr/share/gradle/lib/guava-11.0.1.jar /usr/share/java/guava.jar <many more dangling symlinks omitted here> gradle.noarch: W: no-manual-page-for-binary gradle gradle.noarch: W: class-path-in-manifest /usr/share/gradle/lib/gradle-launcher-1.0.jar [x]: EXTRA Spec file according to URL is the same as in SRPM. [x]: MUST Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [x]: MUST Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [x]: MUST %build honors applicable compiler flags or justifies otherwise. [x]: MUST All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines. [x]: MUST Buildroot is not present [!]: MUST Package contains no bundled libraries. [1] [x]: MUST Changelog in prescribed format. [x]: MUST Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) [x]: MUST Sources contain only permissible code or content. [-]: MUST Each %files section contains %defattr if rpm < 4.4 [x]: MUST Macros in Summary, %description expandable at SRPM build time. [x]: MUST Package contains desktop file if it is a GUI application. [-]: MUST Development files must be in a -devel package [x]: MUST Package requires other packages for directories it uses. [x]: MUST Package uses nothing in %doc for runtime. [x]: MUST Package is not known to require ExcludeArch. [x]: MUST Permissions on files are set properly. [x]: MUST Package does not contain duplicates in %files. [x]: MUST Package complies to the Packaging Guidelines [x]: MUST Spec file lacks Packager, Vendor, PreReq tags. [x]: MUST Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. [-]: MUST Large documentation files are in a -doc subpackage, if required. [x]: MUST If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %doc. [x]: MUST License field in the package spec file matches the actual license. [1] [x]: MUST Package consistently uses macros (instead of hard-coded directory names). [x]: MUST Package is named using only allowed ascii characters. [x]: MUST Package is named according to the Package Naming Guidelines. [x]: MUST Package does not generate any conflict. [x]: MUST Package obeys FHS, except libexecdir and /usr/target. [!]: MUST Package must own all directories that it creates. [2] [x]: MUST Package does not own files or directories owned by other packages. [x]: MUST Package installs properly. [x]: MUST Package is not relocatable. [x]: MUST Requires correct, justified where necessary. [x]: MUST Rpmlint is run on all rpms the build produces. [x]: MUST Sources used to build the package match the upstream source, as provided in the spec URL. source sha1sum: b0ba4c333e600b28daa9938f0b775ed10d42745b gradle-1.0-src.zip upstream sha1sum: b0ba4c333e600b28daa9938f0b775ed10d42745b gradle-1.0-src.zip [x]: MUST Spec file is legible and written in American English. [x]: MUST Spec file name must match the spec package %{name}, in the format %{name}.spec. [-]: MUST Package contains systemd file(s) if in need. [x]: MUST File names are valid UTF-8. [x]: SHOULD Reviewer should test that the package builds in mock. [-]: SHOULD If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [x]: SHOULD Dist tag is present. [x]: SHOULD No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: SHOULD Final provides and requires are sane (rpm -q --provides and rpm -q --requires). [x]: SHOULD Package functions as described. [!]: SHOULD Latest version is packaged. [3] [x]: SHOULD Package does not include license text files separate from upstream. [!]: SHOULD SourceX / PatchY prefixed with %{name}. [4] [x]: SHOULD SourceX is a working URL. [-]: SHOULD Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [x]: SHOULD Package should compile and build into binary rpms on all supported architectures. [-]: SHOULD %check is present and all tests pass. [x]: SHOULD Packages should try to preserve timestamps of original installed files. [x]: SHOULD Spec use %global instead of %define. ==== Java ==== [!]: MUST If source tarball includes bundled jar/class files these need to be removed prior to building [1] [x]: MUST Packages have proper BuildRequires/Requires on jpackage-utils [-]: MUST Fully versioned dependency in subpackages, if present. [x]: MUST Javadoc documentation files are generated and included in -javadoc subpackage [x]: MUST Javadoc subpackages have Requires: jpackage-utils [x]: MUST Javadocs are placed in %{_javadocdir}/%{name} (no -%{version} symlink) [x]: SHOULD Package has BuildArch: noarch (if possible) [x]: SHOULD Package uses upstream build method (ant/maven/etc.) Issues: [1] There are various bundled jars: * gradle-1.0/subprojects/docs/src/samples/webApplication/customised/lib/* * gradle-1.0/gradle/wrapper/gradle-wrapper.jar [2] There are several unowned directories: * file /usr/share/java/gradle is not owned by any package * file /usr/share/gradle/bin is not owned by any package * file /usr/share/gradle/media is not owned by any package * file /usr/share/gradle/lib is not owned by any package [3] The latest version is 1.2, but this was released just a week ago, well after this packaging work was done. I think we can hold off on 1.2 until Fedora 19. [4] Patches use names generated from git, which do not follow the Fedora guidelines. I understand the rationale for this naming pattern, but I think the guidelines require prefixes so that users of "rpmbuild" can easily clean up their SOURCES directory. Please bring it up on the packaging list if you'd like to see the guidelines change. [5] The Java guidelines require arch-independent JARs to go under %_javadir, not %_datadir. typically this is resolved by using symlinks in %_datadir (as is already done for dependency jars outside the package) Other Notes: * Is there are reason within the application that LICENSE / NOTICE / etc. are in /usr/share/gradle rather than %docdir ?
Spec URL: http://gil.fedorapeople.org/gradle/release/1.0-5/gradle.spec SRPM URL: http://gil.fedorapeople.org/gradle/release/1.0-5/gradle-1.0-5.fc16.src.rpm - Removed bundled jars - Fixed unowned directories - Used symlinks in %%_datadir/gradle [4] Patches use names generated from git, which do not follow the Fedora guidelines. - changed patches names i havent a link for see the guidelines change.... Other Notes: * Is there are reason within the application that LICENSE / NOTICE / etc. are in /usr/share/gradle rather than %docdir ? yes , are required by the gradle gui application
hi gradle dont work with symlinks in %%_datadir/gradle + mkdir -p gradlehome + gradle --debug -g /home/gil/rpmbuild/BUILD/groovy-2.0.2/gradlehome -b /home/gil/rpmbuild/BUILD/groovy-2.0.2/buildSrc/build.gradle Exception in thread "main" java.lang.NoClassDefFoundError: org/gradle/api/internal/classpath/ModuleRegistry at org.gradle.launcher.GradleMain.main(GradleMain.java:24) Caused by: java.lang.ClassNotFoundException: org.gradle.api.internal.classpath.ModuleRegistry at java.net.URLClassLoader$1.run(URLClassLoader.java:366) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:423) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) ... 1 more errore: Stato d'uscita errato da /var/tmp/rpm-tmp.0MXR4R (%build)
Spec URL: http://gil.fedorapeople.org/gradle/release/1.0-6/gradle.spec SRPM URL: http://gil.fedorapeople.org/gradle/release/1.0-6/gradle-1.0-6.fc16.src.rpm - Revert symlinks from %%_datadir/gradle to %%_javadir/gradle cause: gradle dont work with symlinks in %%_datadir/gradle if this solution isn't acceptable, (can) remove gradle symlinks in _javadir/...
It looks like /usr/share/gradle/lib/gradle-launcher-1.0.jar is special and cannot be moved, because the launcher inspects its own _dereferenced_ file path to determine where to find other jars. The others can be in javadir. A style note about your latest spec. You have a lot of %dir entries for directories where recursing them is fine. So this: %dir %{_datadir}/%{name}/lib %{_datadir}/%{name}/lib/* could simply be: %{_datadir}/%{name}/lib This is not a major thing, but would make the spec file cleaner.
Thanks Spec URL: http://gil.fedorapeople.org/gradle/release/1.0-7/gradle.spec SRPM URL: http://gil.fedorapeople.org/gradle/release/1.0-7/gradle-1.0-7.fc16.src.rpm - Revert symlinks in %%_javadir, exception for gradle-launcher
This looks okay now. APPROVED. (I don't know what the procedure for this package is from here, since it's technically already in Fedora. You have my vote to replace the existing package with this one now, though.)
Package Change Request ====================== Package Name: gradle New Branches: f17 f18 Owners: gil InitialCC: java-sig
Already exists.
hi Jon, i know but can you see this http://lists.fedoraproject.org/pipermail/java-devel/2012-September/004521.html the packagers haven't time to spend follow this new gradle release... i opened this other bug related to this problem https://bugzilla.redhat.com/show_bug.cgi?id=855336 thanks
I also asked to become co maintainer but I had no answer. until now any ideas on how should I proceed? thanks regards
gradle-1.0-7.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/gradle-1.0-7.fc18
gradle-1.0-7.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/gradle-1.0-7.fc17
Package gradle-1.0-7.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing gradle-1.0-7.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-15344/gradle-1.0-7.fc18 then log in and leave karma (feedback).
Gil, please rebuild the package without bootstrapping.
gradle-1.0-8.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/gradle-1.0-8.fc18
gradle-1.0-8.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/gradle-1.0-8.fc17
gradle-1.0-8.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.