Bug 809950 - Review Request: gradle - Groovy based build system
Review Request: gradle - Groovy based build system
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Andy Grimm
Fedora Extras Quality Assurance
:
Depends On: 805487 806670 806680 817560 831228 844314 844792 845012
Blocks: 769321 852330 858121
  Show dependency treegraph
 
Reported: 2012-04-04 13:48 EDT by gil cattaneo
Modified: 2012-12-20 10:51 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-20 10:51:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
agrimm: fedora‑review+


Attachments (Terms of Use)

  None (edit)
Description gil cattaneo 2012-04-04 13:48:07 EDT
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.
Comment 1 gil cattaneo 2012-04-05 07:43:01 EDT
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
Comment 3 Carlo de Wolf 2012-04-19 08:02:51 EDT
The Release tag does not state the proper upstream tag as per https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_packages.
Comment 4 gil cattaneo 2012-04-19 08:36:19 EDT
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
Comment 5 gil cattaneo 2012-04-19 12:19:33 EDT
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
Comment 6 Stanislav Ochotnicky 2012-04-23 05:29:18 EDT
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.
Comment 7 gil cattaneo 2012-04-23 06:05:36 EDT
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
Comment 8 Stanislav Ochotnicky 2012-04-23 08:12:52 EDT
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.
Comment 9 gil cattaneo 2012-04-23 16:09:24 EDT
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
Comment 10 gil cattaneo 2012-04-27 08:48:25 EDT
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
Comment 11 gil cattaneo 2012-04-28 10:57:15 EDT
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
Comment 12 gil cattaneo 2012-05-02 06:58:34 EDT
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
Comment 13 gil cattaneo 2012-05-03 17:27:31 EDT
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
Comment 14 gil cattaneo 2012-06-01 06:49:25 EDT
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
Comment 16 gil cattaneo 2012-07-16 10:46:11 EDT
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
Comment 17 Mikolaj Izdebski 2012-07-17 10:50:38 EDT
Version 1.0-2 fails to build in mock:
http://koji.fedoraproject.org/koji/taskinfo?taskID=4246613
Comment 19 Marek Goldmann 2012-08-01 09:21:34 EDT
Instead of adding new deps I would focus on getting this package reviewed.
Comment 20 Marek Goldmann 2012-08-07 03:03:21 EDT
New koji scratch build after making the package arch independent: http://koji.fedoraproject.org/koji/taskinfo?taskID=4365510
Comment 22 Mikolaj Izdebski 2012-08-16 16:38:20 EDT
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
Comment 23 Marek Goldmann 2012-08-17 01:56:00 EDT
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.
Comment 24 Dan Allen 2012-08-26 02:19:01 EDT
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.
Comment 25 gil cattaneo 2012-08-26 05:41:50 EDT
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.
Comment 26 gil cattaneo 2012-08-26 06:23:32 EDT
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
Comment 27 Dan Allen 2012-08-27 01:29:59 EDT
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.
Comment 28 Dan Allen 2012-08-27 01:37:40 EDT
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)"
Comment 29 Dan Allen 2012-08-27 02:25:45 EDT
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.
Comment 30 Marek Goldmann 2012-08-27 02:51:35 EDT
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.
Comment 31 Marek Goldmann 2012-08-27 02:53:19 EDT
One more thing; you can generate the patches using this command:

git format-patch --no-numbered --no-signature REL_1.0..HEAD
Comment 32 gil cattaneo 2012-08-27 04:20:17 EDT
(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
Comment 33 gil cattaneo 2012-08-27 06:49:55 EDT
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
Comment 34 Dan Allen 2012-08-27 11:06:16 EDT
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.
Comment 35 gil cattaneo 2012-08-27 13:05:32 EDT
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
Comment 36 Andy Grimm 2012-09-04 11:01:19 EDT
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.
Comment 37 gil cattaneo 2012-09-04 12:30:01 EDT
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
Comment 38 gil cattaneo 2012-09-08 21:12:01 EDT
tested on: http://koji.fedoraproject.org/koji/taskinfo?taskID=4469048
Comment 39 Andy Grimm 2012-09-21 11:37:17 EDT
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 ?
Comment 40 gil cattaneo 2012-09-21 15:54:25 EDT
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
Comment 41 gil cattaneo 2012-09-21 16:15:34 EDT
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)
Comment 42 gil cattaneo 2012-09-21 16:49:21 EDT
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/...
Comment 43 Andy Grimm 2012-09-21 17:03:13 EDT
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.
Comment 44 gil cattaneo 2012-09-21 17:45:58 EDT
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
Comment 45 Andy Grimm 2012-09-21 22:33:26 EDT
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.)
Comment 46 gil cattaneo 2012-09-22 04:04:47 EDT
Package Change Request
======================
Package Name: gradle
New Branches: f17 f18
Owners: gil
InitialCC: java-sig
Comment 47 Jon Ciesla 2012-09-22 12:07:56 EDT
Already exists.
Comment 48 gil cattaneo 2012-09-22 12:21:51 EDT
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
Comment 49 gil cattaneo 2012-09-22 12:30:58 EDT
I also asked to become co maintainer but I had no answer. until now
any ideas on how should I proceed?
thanks
regards
Comment 50 Fedora Update System 2012-10-03 15:09:46 EDT
gradle-1.0-7.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/gradle-1.0-7.fc18
Comment 51 Fedora Update System 2012-10-03 15:30:34 EDT
gradle-1.0-7.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/gradle-1.0-7.fc17
Comment 52 Fedora Update System 2012-10-03 22:06:21 EDT
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).
Comment 53 Marek Goldmann 2012-10-15 06:15:45 EDT
Gil, please rebuild the package without bootstrapping.
Comment 54 Fedora Update System 2012-10-15 13:56:17 EDT
gradle-1.0-8.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/gradle-1.0-8.fc18
Comment 55 Fedora Update System 2012-10-15 14:15:47 EDT
gradle-1.0-8.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/gradle-1.0-8.fc17
Comment 56 Fedora Update System 2012-12-20 10:51:53 EST
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.

Note You need to log in before you can comment on or make changes to this bug.