(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@gradleware.com
Hi Tom,
First, thank you for contacting with us, providing feedback and sharing ideas. I'm glad you wrote - it's quite uncommon for Java upstreams to see value in having their projects available in Fedora or other GNU/Linux distributions.
On 11/11/2014 03:05 AM, Tom Dunstan wrote:
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 think that packaging latest Gradle 2.x should be doable for Fedora 22. I will prepare an official Fedora change for Gadle in Fedora 22. We also considered packaging 1.x line (as compat package "gradle1"), but for now my focus was mainly on 2.1. (I will uptade to 2.2 soon.)
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
The non-free JSON lib is a dependency of XStream. We have reported this as XSTR-763 [1]. This lib seems to be used during Gradle 2.1 build - building Gradle pulls it into cache at $HOME/.gradle. This lib is also hosted in Gradle repo [2]. Perhaps it should be explicitly excluded as XStream upstream claims it's a test dependency only?
- 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?
I have the patch mostly ready. I am definitely going to open a pull request in future (I've already signed CLA), but the patch needs some polishing and extra testing first.
There are two incompatibilities I discovered so far:
Gradle exposes maven-model in API. maven-model 2.x and 3.x are mostly compatible, but not entirely, so I suppose that some third-party plugins or build scripts would be affected by this change.
Second smaller issue: some internal fields of maven-ant-tasks (like authentication info) can be injected from DSL. I found out that one field was renamed from "userName" to "username". I think this should be solvable without breaking build scripts.
- 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.
The utlimate goal is to have two installations of Gradle. First upstream-like, for standard use by Fedora users and second, with some necessary Fedora-specific extensions enabled. The second installation would have local repository (xmvn) enabled by default so that we don't have to patch build scripts of every software we want to build for Fedora using Gradle.
- Upgrading Jetty. Mostly we're pointing people to use the external Gretty
plugin. See below for concerns.
AFAIK Gradle is at Java 1.5, but any Jetty version above 6 requires Java 1.6 or newer. Unfortunatelly this alone makes our Jetty patch not upstreamable :(
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.
We are aware of that. We'll try to minimize changes we apply to Gradle (possibly by pushing patches upstream), but in some cases this may not be possible.
In case of Jetty 6, from technical PoV we could add it to Fedora, but it would be against our goals (for many reasons Fedora doesn't want to ship legacy, unmaintained software). Current solution (porting to Jetty 9) is definitely not ideal either and I'll try to think of some better way of solving the problem.
The same goes for any plugins that might not be enabled (there were lots of these in the earlier Fedora-Gradle 1.0 patches),
The goal is to enable all stardard plugins. As of now all plugins are enabled. Only Scala Zinc compiler is disabled, but this should be eventually fixed.
or non-standard repositories such as xmvn.
xmvn repository was added temporarly only, until this problem is solved the right way. (As I mentioned above, custom repository will be enabled only in local mode, used only during package build and activated by running Gradle with a different command, like "gradle-local").
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.
That's an interesting idea. We can add a warning.
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?
This is a good idea. For most packages we don't change upstream versions (but usually we don't patch code either, besides bugfixes). In some cases we add "Fedora" or "Red Hat" suffixes (for examples see "gcc --version" or "mvn -version" in RHEL).
I already tried adding Fedora version suffix, but GradleVersion class implements strict version checking which rejected my first attempts to use customized version. But I'll find a way to do this properly.
Do you have any recommendation how the version should look like to satisfy Gradle versioning rules?
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.
During RPM package build we try to run all unit and integration tests included in project sources. All test dependencies must be packaged as Fedora package. If any test fails, the build is aborted and RPMs are not created until maintainer fixes or disables failing test.
For external integration tests we have Taskotron [1]. It is still in development and not ready for general use, but once it's ready we can think of adding Gradle IT suite there. Test dependencies don't have to be packaged in Fedora. Tasktron tests are ran after in testing phase (after package is built, but before shipped) or on demand. Failing tests don't prevent package from being shipped.
So far I haven't even been running Gradle unit tests during build. One reason for that is we don't have all test dependencies packaged and some tests would have to be ported to newer dependency versions. Some cases I ported code to different Maven or Jetty versions, but left tests unchanged. This is on my TODO list, but lower priority. Another reason is that I am experimenting a bit with different patches and I don't want to spend too much time on porting or fixing tests if the patch is going to be reverted or changed anyways.
In short: with time we'll try to enable as many tests as possible, but for now we may skip tests to speed up development.
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.
That could be done.
There is xmvn-subst utility, which can be used to replace JAR with a symlink, assuming that the JAR is coming from Fedora and has Maven metadata installed.
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.
As explained above, this is the goal, but I don't know yet how it will be implemented. Most likely a separate Gradle home (sharing all or most of JARs by symlinking them), with some extensions added.
Maven is a good example of such separation. We ship vanilla Maven (yes, all our patches have been upstreamed!) in /usr/share/maven. This is used when you invoke "mvn" command. But during package build "xmvn" command is invoked instead. It uses Maven home at /usr/share/xmvn, which is identical to Maven home except that it has Fedora-specific extensions enabled.
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.
Phase 3 is already done (I forgot to update the Wiki page). All we need to do before Gradle can be pushed to Fedora is polishing packages, reviewing them and fixing a few remaining bugs.
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.
Shading is indeed a big problem, in general. I believe that shading sould be done only as last resort and that there are better techniques (like class loaders) to prevent conflicts of different library versions or leaking of implementation classes through APIs.
I have already unshaded Maven 3 JARs (this was possible after I ported Gradle not to use maven-ant-tasks). I will look into unshading all remaining libraries.
A few random problems I found working on packaging Gradle (there are more, but this email is already getting very long...):
* Ivy resolvers can't be used in Gradle 2.x any longer (and are deprecated in 1.x). There is no public API for defining custom repository. (My temporary solution: use internal repository APIs.)
* There is no official way for providing Gradle extensions (by extension I mean addon that modifies Gradle behavior). Long term I think it would be great if Gradle could use some IoC thechniques to inject implementation classes, allowing extensions to easily override some standard Gradle components. (My temporary solution: patch Gradle code.)
* Internal Gradle artifacts (such as core-impl) are not published in artifact repositories. This makes more difficult to write extensions that use internal APIs. (I assume this done intentionally to discourage from using Gradle internals. My solution: create my own repo with missing artifacts.)
* gradle-launcher has "Class-Path" entry in manifest, which is not allowed in Fedora. I had to patch Gradle launchers to work without this entry, but I am affraid that there may be third-party launchers that assume Gradle can be ran with "java -jar gradle-launcher.jar", which won't work in Fedora. It would be nice if this could somehow be solved with upstream cooperation.
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?
This is pefectly fine for java-devel list.
/usr/share/maven-repo/ in Debian is a standard Maven repository and Gradle should be able to use it out of the box (through Ivy, without any custom code).
Fedora "repository" is not a typical artifact repository at all. It doesn't have a strict layout (artifacts can have arbitrary file names and be placed at arbitrary locations in the file system). XMvn knows where to find them by reading special metadada files stored in /usr/share/maven-metadata/. Besides that we use custom version resolution scheme, meaning that POMs from Fedora can't be directly used by Gradle or Maven as they are. Some artifacts don't have POMs at all - we have to generate effective POM from metadata on demand.
Thanks,
Hi Mikolaj
On Wed, Nov 12, 2014 at 8:59 PM, Mikolaj Izdebski mizdebsk@redhat.com wrote:
First, thank you for contacting with us, providing feedback and sharing ideas. I'm glad you wrote - it's quite uncommon for Java upstreams to see value in having their projects available in Fedora or other GNU/Linux distributions.
Credit on our end goes to Hans (whom I left off the original CC list, whoops) for driving it.
It's a win-win though - we want people to use Gradle, and one of the things that they will want to do is build software that can be packaged in Fedora / RHEL / Centos / SL / etc. We don't want Gradle to be an impediment to that.
On a personal note I used Fedora (and RHL before that) as my primary desktop for many years, so seeing Gradle as part of that ecosystem makes me happy. :)
I think that packaging latest Gradle 2.x should be doable for Fedora 22. I will prepare an official Fedora change for Gadle in Fedora 22. We also considered packaging 1.x line (as compat package "gradle1"), but for now my focus was mainly on 2.1. (I will uptade to 2.2 soon.)
Honestly I reckon if you've got projects whose build scripts are designed for Gradle 1.x, it'll be less work to update their build file to be Gradle 2.x compatible than package another version of Gradle. Some stuff was deprecated when we moved to 2.x, but not all that much stuff for most builds.
The non-free JSON lib is a dependency of XStream. We have reported this as XSTR-763 [1]. This lib seems to be used during Gradle 2.1 build - building Gradle pulls it into cache at $HOME/.gradle. This lib is also hosted in Gradle repo [2]. Perhaps it should be explicitly excluded as XStream upstream claims it's a test dependency only?
OK, I'll see if I can track this down.
- Porting to aether-ant-tasks
I have the patch mostly ready. I am definitely going to open a pull request in future (I've already signed CLA), but the patch needs some polishing and extra testing first
Great!
Gradle exposes maven-model in API. maven-model 2.x and 3.x are mostly compatible, but not entirely, so I suppose that some third-party plugins or build scripts would be affected by this change.
Yeah, this is non-ideal. Generally over time we try to isolate these sorts of APIs and replace them with internal interfaces, but it's a work in progress :)
Second smaller issue: some internal fields of maven-ant-tasks (like
authentication info) can be injected from DSL. I found out that one field was renamed from "userName" to "username". I think this should be solvable without breaking build scripts.
Yeah probably.
The utlimate goal is to have two installations of Gradle. First upstream-like, for standard use by Fedora users and second, with some necessary Fedora-specific extensions enabled. The second installation would have local repository (xmvn) enabled by default so that we don't have to patch build scripts of every software we want to build for Fedora using Gradle.
That sounds great.
AFAIK Gradle is at Java 1.5, but any Jetty version above 6 requires Java 1.6 or newer. Unfortunatelly this alone makes our Jetty patch not upstreamable :(
Gradle 2.x requires Java 1.6+ to run. We no longer require Java 1.5.
As for the patch, there have been some discussions about what to do with the Jetty plugin. Just upgrading the Jetty version could break existing builds, and there are external plugins that support multiple versions anyway. You could submit the patch, but I'm honestly not sure what the answer would be right now.
In case of Jetty 6, from technical PoV we could add it to Fedora, but it would be against our goals (for many reasons Fedora doesn't want to ship legacy, unmaintained software). Current solution (porting to Jetty 9) is definitely not ideal either and I'll try to think of some better way of solving the problem.
Well I'd love a creative idea, but on the one hand we've got users for whom an upgrade could break their build due to differences between Jetty 6 and 9 (his goes for any other Jetty version too), and on the other we've got Fedora not wanting to ship and maintain ancient code. Not sure how to solve that.
FWIW it doesn't require a full Jetty distribution, just the jetty jars to run it up embedded inside Gradle. It's mostly used for integration testing web app projects. I don't know if that changes the maintenance burden regarding security errata etc though.
The goal is to enable all stardard plugins. As of now all plugins are
enabled. Only Scala Zinc compiler is disabled, but this should be eventually fixed.
Great!
xmvn repository was added temporarly only, until this problem is solved
the right way. (As I mentioned above, custom repository will be enabled only in local mode, used only during package build and activated by running Gradle with a different command, like "gradle-local").
Also great!
I already tried adding Fedora version suffix, but GradleVersion class implements strict version checking which rejected my first attempts to use customized version. But I'll find a way to do this properly.
Do you have any recommendation how the version should look like to satisfy Gradle versioning rules?
The GradleVersion class allows things such as '1.0-milestone-5a' and '2.2-rc-2', but the allowed "stage" strings are hardcoded. I'll see if we can come up with something that allows a distributor to set it to something custom. I presume we'll want it to look like e.g. '2.2-f22-17' where 17 would be the rpm spec version. Then the vender specific part could be adjusted to reflect the distributor, e.g. 'f22', 'el7' etc, and so a user asking for help has their particular build unambiguously identified.
For external integration tests we have Taskotron [1]. It is still in development and not ready for general use, but once it's ready we can think of adding Gradle IT suite there. Test dependencies don't have to be packaged in Fedora. Tasktron tests are ran after in testing phase (after package is built, but before shipped) or on demand. Failing tests don't prevent package from being shipped.
This is good news. Please let me know when you are ready to do this, and I can assist with some of the test setup.
In short: with time we'll try to enable as many tests as possible, but
for now we may skip tests to speed up development.
Of course.
There is xmvn-subst utility, which can be used to replace JAR with a symlink, assuming that the JAR is coming from Fedora and has Maven metadata installed.
OK, so maybe that's not worth doing if there's an easy way built into the tools that you're already using.
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.
As explained above, this is the goal, but I don't know yet how it will be implemented. Most likely a separate Gradle home (sharing all or most of JARs by symlinking them), with some extensions added.
Maven is a good example of such separation. We ship vanilla Maven (yes, all our patches have been upstreamed!) in /usr/share/maven. This is used when you invoke "mvn" command. But during package build "xmvn" command is invoked instead. It uses Maven home at /usr/share/xmvn, which is identical to Maven home except that it has Fedora-specific extensions enabled.
That's one way to do it. Gradle does have a method to customise things at runtime for a whole distribution though - the init.d directory in the gradle home dir. So you could enable your customisations by dropping a script in there whose functions are guarded by e.g. looking for a specific system property, and then set that property in the gradle-local script. So a separate install dir may not be necessary. Maybe :)
Shading is indeed a big problem, in general. I believe that shading sould be done only as last resort and that there are better techniques (like class loaders) to prevent conflicts of different library versions or leaking of implementation classes through APIs.
As above we are trying to remove various "accidental" third party APIs from visibility over time.
I have already unshaded Maven 3 JARs (this was possible after I ported Gradle not to use maven-ant-tasks). I will look into unshading all remaining libraries.
Yeah lots and lots of the jarjars in our distribution were related to maven.
- Ivy resolvers can't be used in Gradle 2.x any longer (and are
deprecated in 1.x). There is no public API for defining custom repository. (My temporary solution: use internal repository APIs.)
Where are you trying to do this from? It's certainly possible to create an ivy repo in a build file. Do you mean that there's no non-DSL way to build one?
- There is no official way for providing Gradle extensions (by extension
I mean addon that modifies Gradle behavior). Long term I think it would be great if Gradle could use some IoC thechniques to inject implementation classes, allowing extensions to easily override some standard Gradle components. (My temporary solution: patch Gradle code.)
Well, there are plugins, but those won't help you if you're trying to change where plugins might be loaded from :)
What specifically do you want to do?
- gradle-launcher has "Class-Path" entry in manifest, which is not
allowed in Fedora. I had to patch Gradle launchers to work without this entry, but I am affraid that there may be third-party launchers that assume Gradle can be ran with "java -jar gradle-launcher.jar", which won't work in Fedora. It would be nice if this could somehow be solved with upstream cooperation.
Can you explain or point to a page with the policy rationale here please?
I'm not sure about third party launchers... I presume the IDEs probably construct their own classpaths.
Fedora "repository" is not a typical artifact repository at all. It doesn't have a strict layout (artifacts can have arbitrary file names and be placed at arbitrary locations in the file system). XMvn knows where to find them by reading special metadada files stored in /usr/share/maven-metadata/. Besides that we use custom version resolution scheme, meaning that POMs from Fedora can't be directly used by Gradle or Maven as they are. Some artifacts don't have POMs at all - we have to generate effective POM from metadata on demand.
Do artifact GAVs stay the same?
Thanks
Tom
On 11/14/2014 08:43 AM, Tom Dunstan wrote:
Gradle 2.x requires Java 1.6+ to run. We no longer require Java 1.5.
Hi Tom,
Just FYI, [1] still mentions Java 1.5.
Regards Michal
On 14 Nov 2014, at 8:43, Tom Dunstan wrote:
In case of Jetty 6, from technical PoV we could add it to Fedora, but it
would be against our goals (for many reasons Fedora doesn't want to ship legacy, unmaintained software). Current solution (porting to Jetty 9) is definitely not ideal either and I'll try to think of some better way of solving the problem.
Well I'd love a creative idea, but on the one hand we've got users for whom an upgrade could break their build due to differences between Jetty 6 and 9 (his goes for any other Jetty version too), and on the other we've got Fedora not wanting to ship and maintain ancient code. Not sure how to solve that.
sorry for my gradle ignorance but does this mean it is not possible for the user to decide which version of jetty he wants to test against ? The version of the build tool locks down the jetty version ?
FWIW it doesn't require a full Jetty distribution, just the jetty jars to run it up embedded inside Gradle. It's mostly used for integration testing web app projects. I don't know if that changes the maintenance burden regarding security errata etc though.
Hi Max
On Fri, Nov 14, 2014 at 8:42 PM, Max Rydahl Andersen manderse@redhat.com wrote:
sorry for my gradle ignorance but does this mean it is not possible for the user to decide which version of jetty he wants to test against ? The version of the build tool locks down the jetty version ?
With the current version of the plugin, only Jetty 6 is supported. If the user is building an app with Jetty embedded then they can use whatever version they want. If they are building a war then there are other options such as the cargo plugin (to test against many container types) and the gretty plugin (which allows running and testing against various Jetty and Tomcat versions). We generally steer people towards these at the moment - the Jetty plugin is more or less in maintenance mode right now. That's why it wouldn't necessarily be the end of the world to just disable it and issue an error message rather than port to Jetty 9 - users should probably be using Gretty instead anyway.
It could go either way though - in the past I have used the jetty plugin on a couple of personal projects just to do some basic end-to-end testing in a servlet container, and it's useful to have that built in.
If there are projects that Fedora packages that need it, I think adding the Gretty plugin to the build would probably do the trick - it even uses the same task names "jettyRunWar", "jettyStop" etc. Authors would probably appreciate having the fix upstreamed :)
We may end up modernising the Jetty plugin at some point, but the general trend over time has been to add functionality like that via external plugins.
Cheers
Tom
thanks for the explantation. makes sense now.
I'm a believer in platforms need to allow bundling multiple versions and tools need to support working with them.
With Fedora's general guidelines that just gets tricky, but I hope some middleground can be found.
Hi Max
On Fri, Nov 14, 2014 at 8:42 PM, Max Rydahl Andersen manderse@redhat.com wrote:
sorry for my gradle ignorance but does this mean it is not possible for the user to decide which version of jetty he wants to test against ? The version of the build tool locks down the jetty version ?
With the current version of the plugin, only Jetty 6 is supported. If the user is building an app with Jetty embedded then they can use whatever version they want. If they are building a war then there are other options such as the cargo plugin (to test against many container types) and the gretty plugin (which allows running and testing against various Jetty and Tomcat versions). We generally steer people towards these at the moment - the Jetty plugin is more or less in maintenance mode right now. That's why it wouldn't necessarily be the end of the world to just disable it and issue an error message rather than port to Jetty 9 - users should probably be using Gretty instead anyway.
It could go either way though - in the past I have used the jetty plugin on a couple of personal projects just to do some basic end-to-end testing in a servlet container, and it's useful to have that built in.
If there are projects that Fedora packages that need it, I think adding the Gretty plugin to the build would probably do the trick - it even uses the same task names "jettyRunWar", "jettyStop" etc. Authors would probably appreciate having the fix upstreamed :)
We may end up modernising the Jetty plugin at some point, but the general trend over time has been to add functionality like that via external plugins.
Cheers
Tom
On 11/14/2014 08:43 AM, Tom Dunstan wrote:
I think that packaging latest Gradle 2.x should be doable for Fedora 22. I will prepare an official Fedora change for Gadle in Fedora 22. We also considered packaging 1.x line (as compat package "gradle1"), but for now my focus was mainly on 2.1. (I will uptade to 2.2 soon.)
Honestly I reckon if you've got projects whose build scripts are designed for Gradle 1.x, it'll be less work to update their build file to be Gradle 2.x compatible than package another version of Gradle. Some stuff was deprecated when we moved to 2.x, but not all that much stuff for most builds.
I heard that some build scripts may use features which were removed in Gradle 2.x. The focus is on latest 2.x version first and then we'll see if 1.x will be packaged too or not. (I would like to keep only the latest version in Fedora if possible.)
AFAIK Gradle is at Java 1.5, but any Jetty version above 6 requires Java 1.6 or newer. Unfortunatelly this alone makes our Jetty patch not upstreamable :(
Gradle 2.x requires Java 1.6+ to run. We no longer require Java 1.5.
Great. This will make it possible to use never versions of some dependencies (like latest Maven 3.2.x).
As for the patch, there have been some discussions about what to do with the Jetty plugin. Just upgrading the Jetty version could break existing builds, and there are external plugins that support multiple versions anyway. You could submit the patch, but I'm honestly not sure what the answer would be right now.
In case of Jetty 6, from technical PoV we could add it to Fedora, but it would be against our goals (for many reasons Fedora doesn't want to ship legacy, unmaintained software). Current solution (porting to Jetty 9) is definitely not ideal either and I'll try to think of some better way of solving the problem.
Well I'd love a creative idea, but on the one hand we've got users for whom an upgrade could break their build due to differences between Jetty 6 and 9 (his goes for any other Jetty version too), and on the other we've got Fedora not wanting to ship and maintain ancient code. Not sure how to solve that.
FWIW it doesn't require a full Jetty distribution, just the jetty jars to run it up embedded inside Gradle. It's mostly used for integration testing web app projects. I don't know if that changes the maintenance burden regarding security errata etc though.
We'll see what to do with Jetty. I brought this problem on our meeting we decided against packaging packaging Jetty 6. Short term we'll keep the patch porting to Jetty 9 and print a warning when Jetty plugin is used. Long-term solution is yet to be decided.
I already tried adding Fedora version suffix, but GradleVersion class implements strict version checking which rejected my first attempts to use customized version. But I'll find a way to do this properly.
Do you have any recommendation how the version should look like to satisfy Gradle versioning rules?
The GradleVersion class allows things such as '1.0-milestone-5a' and '2.2-rc-2', but the allowed "stage" strings are hardcoded. I'll see if we can come up with something that allows a distributor to set it to something custom. I presume we'll want it to look like e.g. '2.2-f22-17' where 17 would be the rpm spec version. Then the vender specific part could be adjusted to reflect the distributor, e.g. 'f22', 'el7' etc, and so a user asking for help has their particular build unambiguously identified.
I believe that versioning should be entirely up to upstream and I will respect upstream decision in this matter. I will bring this up with upstream and until I get response I will use standard versioning.
- Ivy resolvers can't be used in Gradle 2.x any longer (and are
deprecated in 1.x). There is no public API for defining custom repository. (My temporary solution: use internal repository APIs.)
Where are you trying to do this from? It's certainly possible to create an ivy repo in a build file. Do you mean that there's no non-DSL way to build one?
Ivy "resolver" is not the same as Ivy "repository". Resolver API is pluggable interface for resolving artifacts while repository API barely defines storage for artifacts.
ArtifactRepositoryContainer of Gradle 1.x provides methods for adding resolvers (org.apache.ivy.plugins.resolver.DependencyResolver), but they are marked as @Deprecated. Gradle 2.x doesn't support Ivy resolvers at all (and AFAIK there is no other API for providing custom code for artifact resolution).
- There is no official way for providing Gradle extensions (by extension
I mean addon that modifies Gradle behavior). Long term I think it would be great if Gradle could use some IoC thechniques to inject implementation classes, allowing extensions to easily override some standard Gradle components. (My temporary solution: patch Gradle code.)
Well, there are plugins, but those won't help you if you're trying to change where plugins might be loaded from :)
What specifically do you want to do?
In general, I want to override some Gradle code or run some hooks at given points, without having to patch Gradle code or modify build scripts.
I will give one specific example. Gradle checks if resolved artifact version matches requested dependency version. Fedora we very often resolve different version than requested, so this consistency check needs to be relaxed, but only in gradle-local, standard gradle installation should remain unaffected.
I've been looking how to achieve such thing in Gradle nicely (without hacks like injecting private fields with reflection, or patching Gradle code), but I haven't found anything so far.
In contrast, Maven makes such extensions very easy to write. All I need to do is to extend class implementing Plexus component which behavior I want to adjust, override particular method, provide Plexus metadata for my class and drop JAR in Mavens lib/ext/ directory. Ext directory is on classpath before standard Maven JARs, so my custom component is used by Maven instead of standard implementation.
- gradle-launcher has "Class-Path" entry in manifest, which is not
allowed in Fedora. I had to patch Gradle launchers to work without this entry, but I am affraid that there may be third-party launchers that assume Gradle can be ran with "java -jar gradle-launcher.jar", which won't work in Fedora. It would be nice if this could somehow be solved with upstream cooperation.
Can you explain or point to a page with the policy rationale here please?
The policy is at: http://fedoraproject.org/wiki/Packaging:Java#No_class-path_in_MANIFEST.MF
For rationale see: https://lists.fedoraproject.org/pipermail/java-devel/2013-May/004820.html
Fedora "repository" is not a typical artifact repository at all. It doesn't have a strict layout (artifacts can have arbitrary file names and be placed at arbitrary locations in the file system). XMvn knows where to find them by reading special metadada files stored in /usr/share/maven-metadata/. Besides that we use custom version resolution scheme, meaning that POMs from Fedora can't be directly used by Gradle or Maven as they are. Some artifacts don't have POMs at all - we have to generate effective POM from metadata on demand.
Do artifact GAVs stay the same?
I don't know what you meant here.
Hi Mikolaj
On Mon, Nov 17, 2014 at 11:26 PM, Mikolaj Izdebski mizdebsk@redhat.com wrote:
I heard that some build scripts may use features which were removed in Gradle 2.x. The focus is on latest 2.x version first and then we'll see if 1.x will be packaged too or not. (I would like to keep only the latest version in Fedora if possible.)
Do you have examples of which deprecated features are causing issues (other than the ivy resolver stuff mentioned below)? There may be other ways to accomplish the feature, or we may be able to reintroduce a similar feature if needed.
The GradleVersion class allows things such as '1.0-milestone-5a' and '2.2-rc-2', but the allowed "stage" strings are hardcoded. I'll see if we can come up with something that allows a distributor to set it to
something
custom. I presume we'll want it to look like e.g. '2.2-f22-17' where 17 would be the rpm spec version. Then the vender specific part could be adjusted to reflect the distributor, e.g. 'f22', 'el7' etc, and so a user asking for help has their particular build unambiguously identified.
I believe that versioning should be entirely up to upstream and I will respect upstream decision in this matter. I will bring this up with upstream and until I get response I will use standard versioning.
I'll ask internally as to what we'd like. It'll mostly be viewed from the user support perspective I suspect.
Where are you trying to do this from? It's certainly possible to create
an
ivy repo in a build file. Do you mean that there's no non-DSL way to
build
one?
Ivy "resolver" is not the same as Ivy "repository". Resolver API is pluggable interface for resolving artifacts while repository API barely defines storage for artifacts.
ArtifactRepositoryContainer of Gradle 1.x provides methods for adding resolvers (org.apache.ivy.plugins.resolver.DependencyResolver), but they are marked as @Deprecated. Gradle 2.x doesn't support Ivy resolvers at all (and AFAIK there is no other API for providing custom code for artifact resolution).
Ah, I understand. Was this an issue when adding the Xmvn repo, then?
What specifically do you want to do?
I will give one specific example. Gradle checks if resolved artifact version matches requested dependency version. Fedora we very often resolve different version than requested, so this consistency check needs to be relaxed, but only in gradle-local, standard gradle installation should remain unaffected.
Right. Two things to say on that front:
Firstly, with regard to your specific example, one thing that we definitely would like to encourage in the Java ecosystem is less hard-coding of specific versions and more use of version ranges. Traditionally many published poms referred to specific versions just because Maven really didn't handle version ranges very well in various ways. We have a way to go to get Gradle to pick optimal sets of packages based on various versions in some circumstances, but it's definitely a problem on our radar. In any case I understand that you're stuck with poms published today rather than those that might be in the future, and you need a way to make it more flexible.
Secondly, we're pretty open to making Gradle more extensible, if we can do it in a sane way. I guess the question should be what the process is. If you have a specific change that you would like such as this, feel free to suggest it on the gradle-dev google group, or ping me as Gradleware's current unofficial Fedora contact point. It doesn't have to be a totally thought out design, just a description of the problem that you're solving and a link to a patch doing it the non-extensible way as a demonstration. In fact raise it earlier rather than trying to design a full api or dsl or whatever - that way we can give feedback on the shape of the feature and the kind of PR that we'd accept as early as possible.
- gradle-launcher has "Class-Path" entry in manifest, which is not
allowed in Fedora. I had to patch Gradle launchers to work without this entry, but I am affraid that there may be third-party launchers that assume Gradle can be ran with "java -jar gradle-launcher.jar", which won't work in Fedora. It would be nice if this could somehow be solved with upstream cooperation.
Can you explain or point to a page with the policy rationale here please?
The policy is at: http://fedoraproject.org/wiki/Packaging:Java#No_class-path_in_MANIFEST.MF
For rationale see: https://lists.fedoraproject.org/pipermail/java-devel/2013-May/004820.html
Thanks. I'll ask about this. I'm not sure about how third party launchers are launching gradle at all.
Fedora "repository" is not a typical artifact repository at all. It doesn't have a strict layout (artifacts can have arbitrary file names and be placed at arbitrary locations in the file system). XMvn knows where to find them by reading special metadada files stored in /usr/share/maven-metadata/. Besides that we use custom version resolution scheme, meaning that POMs from Fedora can't be directly used by Gradle or Maven as they are. Some artifacts don't have POMs at all - we have to generate effective POM from metadata on demand.
Do artifact GAVs stay the same?
I don't know what you meant here.
Sorry - do library group, artifactId and version stay the same in your custom resolution scheme? I asked because I had seen examples of what looked like the /usr/share/java directory structure creeping into the gradle 1.0 patches - an example is here http://pkgs.fedoraproject.org/cgit/gradle.git/tree/gradle-1.0-Use-local-avai... - 'org.slf4j:slf4j-api:1.6.4@jar' became 'org.slf4j:slf4j/api:1.6.4@jar'. But I wasn't sure if that sort of munging was what you were referring to or if that preceded the current xmvn solution.
Thanks
Tom
On 11/18/2014 06:05 AM, Tom Dunstan wrote:
On Mon, Nov 17, 2014 at 11:26 PM, Mikolaj Izdebski mizdebsk@redhat.com wrote:
I heard that some build scripts may use features which were removed in Gradle 2.x. The focus is on latest 2.x version first and then we'll see if 1.x will be packaged too or not. (I would like to keep only the latest version in Fedora if possible.)
Do you have examples of which deprecated features are causing issues (other than the ivy resolver stuff mentioned below)? There may be other ways to accomplish the feature, or we may be able to reintroduce a similar feature if needed.
I don't remember (and probably I never knew exactly). Mario, could you provide some details why JavaFX won't build with Gradle 2.x?
The GradleVersion class allows things such as '1.0-milestone-5a' and '2.2-rc-2', but the allowed "stage" strings are hardcoded. I'll see if we can come up with something that allows a distributor to set it to
something
custom. I presume we'll want it to look like e.g. '2.2-f22-17' where 17 would be the rpm spec version. Then the vender specific part could be adjusted to reflect the distributor, e.g. 'f22', 'el7' etc, and so a user asking for help has their particular build unambiguously identified.
I believe that versioning should be entirely up to upstream and I will respect upstream decision in this matter. I will bring this up with upstream and until I get response I will use standard versioning.
I'll ask internally as to what we'd like. It'll mostly be viewed from the user support perspective I suspect.
Ok, thank you.
Where are you trying to do this from? It's certainly possible to create
an
ivy repo in a build file. Do you mean that there's no non-DSL way to
build
one?
Ivy "resolver" is not the same as Ivy "repository". Resolver API is pluggable interface for resolving artifacts while repository API barely defines storage for artifacts.
ArtifactRepositoryContainer of Gradle 1.x provides methods for adding resolvers (org.apache.ivy.plugins.resolver.DependencyResolver), but they are marked as @Deprecated. Gradle 2.x doesn't support Ivy resolvers at all (and AFAIK there is no other API for providing custom code for artifact resolution).
Ah, I understand. Was this an issue when adding the Xmvn repo, then?
Yes, it was. XMvn has Ivy resolver [3], which can be used from Ivy Ant tasks or from different build systems that use Ivy, like SBT or Gradle 1.x. This resolver can't be used with Gradle 2.x any longer, AFAIK.
For Gradle 2.1 I had to develop custom resolver [1], which uses Gradle classes and interfaces marked as internal and which couldn't be compiled against Gradle JARs published to Maven Central (as most of implementation JARs are not published there). When Gradle 2.2 came out I had to port [2] the resolver as many internal Gradle classes were renamed and moved around.
What specifically do you want to do?
I will give one specific example. Gradle checks if resolved artifact version matches requested dependency version. Fedora we very often resolve different version than requested, so this consistency check needs to be relaxed, but only in gradle-local, standard gradle installation should remain unaffected.
Right. Two things to say on that front:
Firstly, with regard to your specific example, one thing that we definitely would like to encourage in the Java ecosystem is less hard-coding of specific versions and more use of version ranges. Traditionally many published poms referred to specific versions just because Maven really didn't handle version ranges very well in various ways. We have a way to go to get Gradle to pick optimal sets of packages based on various versions in some circumstances, but it's definitely a problem on our radar. In any case I understand that you're stuck with poms published today rather than those that might be in the future, and you need a way to make it more flexible.
Version ranges wouldn't help much in our case (unless the range is set to very broad, like "any version"). In Fedora we try to package only the latest version of given software component. (Sometimes it's not possible and we need to ship older "compat" version, which is used only by packages that would be to difficult to port to latest version.) As a consequence our artifact resolver generally ignores dependency versions. No matter what version or version range is specified, a default system version (usually the latest one) is resolved.
Secondly, we're pretty open to making Gradle more extensible, if we can do it in a sane way. I guess the question should be what the process is. If you have a specific change that you would like such as this, feel free to suggest it on the gradle-dev google group, or ping me as Gradleware's current unofficial Fedora contact point. It doesn't have to be a totally thought out design, just a description of the problem that you're solving and a link to a patch doing it the non-extensible way as a demonstration. In fact raise it earlier rather than trying to design a full api or dsl or whatever - that way we can give feedback on the shape of the feature and the kind of PR that we'd accept as early as possible.
I am looking forward to working on improving Gradle. At this point I don't know the exact requirements, but once Gradle is in Fedora and we have a couple of packages using it I'll think if and how current solution could be improved.
Fedora "repository" is not a typical artifact repository at all. It doesn't have a strict layout (artifacts can have arbitrary file names and be placed at arbitrary locations in the file system). XMvn knows where to find them by reading special metadada files stored in /usr/share/maven-metadata/. Besides that we use custom version resolution scheme, meaning that POMs from Fedora can't be directly used by Gradle or Maven as they are. Some artifacts don't have POMs at all - we have to generate effective POM from metadata on demand.
Do artifact GAVs stay the same?
I don't know what you meant here.
Sorry - do library group, artifactId and version stay the same in your custom resolution scheme? I asked because I had seen examples of what looked like the /usr/share/java directory structure creeping into the gradle 1.0 patches - an example is here http://pkgs.fedoraproject.org/cgit/gradle.git/tree/gradle-1.0-Use-local-avai...
- 'org.slf4j:slf4j-api:1.6.4@jar' became 'org.slf4j:slf4j/api:1.6.4@jar'.
But I wasn't sure if that sort of munging was what you were referring to or if that preceded the current xmvn solution.
Yes, we keep upstream GAVs unmodified.
The patch you pointed to was necessary because at that point standard Ivy resolver was used to resolve artifacts from Fedora repository, which doesn't have strict layout. Ivy pattern-based resolver used pattern like "/usr/share/java/[module].[ext]". Since slf4j-api artifact was located at /usr/share/java/slf4j/api.jar, dependency artifactId had to be changed to "slf4j/api" to match the pattern used to locate it. Such patches are not needed any longer as now XMvn is used to locate artifact files.
I'm glad to announce that Gradle 2.2 has just landed in Fedora 22! There's still much to be done, but I think the hardest part is done. Thanks to everyone who helped this to happen!
On 11/18/2014 06:05 AM, Tom Dunstan wrote:
The GradleVersion class allows things such as '1.0-milestone-5a' and '2.2-rc-2', but the allowed "stage" strings are hardcoded. I'll see if we can come up with something that allows a distributor to set it to
something
custom. I presume we'll want it to look like e.g. '2.2-f22-17' where 17 would be the rpm spec version. Then the vender specific part could be adjusted to reflect the distributor, e.g. 'f22', 'el7' etc, and so a user asking for help has their particular build unambiguously identified.
I believe that versioning should be entirely up to upstream and I will respect upstream decision in this matter. I will bring this up with upstream and until I get response I will use standard versioning.
I'll ask internally as to what we'd like. It'll mostly be viewed from the user support perspective I suspect.
Currently gradle --version prints:
------------------------------------------------------------ Gradle 2.2-20141119142823+0000 ------------------------------------------------------------
Build time: 2014-11-19 14:28:23 UTC Build number: none Revision: <unknown>
Groovy: 2.3.7 Ant: Apache Ant(TM) version 1.9.4 compiled on August 11 2014 JVM: 1.8.0_40 (Oracle Corporation 25.40-b16) OS: Linux 3.16.7-200.fc20.x86_64 amd64
And build-receipt.properties contains:
buildNumber=none buildTimestamp=20141119142823+0000 commitId=<unknown> hostname=unknown isSnapshot=true javaVersion=1.8.0_40 osName=Linux osVersion=3.17.2-200.fc20.x86_64 project=gradle rcNumber= username=mockbuild versionBase=2.2 versionNumber=2.2-20141119142823+0000
This should definitely be improved, but I will wait for upstream input how these fields should look like in Fedora gradle RPM package.
Il 19/11/2014 16:33, Mikolaj Izdebski ha scritto:
I'm glad to announce that Gradle 2.2 has just landed in Fedora 22! There's still much to be done, but I think the hardest part is done. Thanks to everyone who helped this to happen!
Great! Thanks!
On 11/18/2014 06:05 AM, Tom Dunstan wrote:
The GradleVersion class allows things such as '1.0-milestone-5a' and '2.2-rc-2', but the allowed "stage" strings are hardcoded. I'll see if we can come up with something that allows a distributor to set it to
something
custom. I presume we'll want it to look like e.g. '2.2-f22-17' where 17 would be the rpm spec version. Then the vender specific part could be adjusted to reflect the distributor, e.g. 'f22', 'el7' etc, and so a user asking for help has their particular build unambiguously identified.
I believe that versioning should be entirely up to upstream and I will respect upstream decision in this matter. I will bring this up with upstream and until I get response I will use standard versioning.
I'll ask internally as to what we'd like. It'll mostly be viewed from the user support perspective I suspect.
Currently gradle --version prints:
Gradle 2.2-20141119142823+0000
Build time: 2014-11-19 14:28:23 UTC Build number: none Revision: <unknown>
Groovy: 2.3.7 Ant: Apache Ant(TM) version 1.9.4 compiled on August 11 2014 JVM: 1.8.0_40 (Oracle Corporation 25.40-b16) OS: Linux 3.16.7-200.fc20.x86_64 amd64
And build-receipt.properties contains:
buildNumber=none buildTimestamp=20141119142823+0000 commitId=<unknown> hostname=unknown isSnapshot=true javaVersion=1.8.0_40 osName=Linux osVersion=3.17.2-200.fc20.x86_64 project=gradle rcNumber= username=mockbuild versionBase=2.2 versionNumber=2.2-20141119142823+0000
This should definitely be improved, but I will wait for upstream input how these fields should look like in Fedora gradle RPM package.
That's awesome!
On Thu, Nov 20, 2014 at 2:03 AM, Mikolaj Izdebski mizdebsk@redhat.com wrote:
I'm glad to announce that Gradle 2.2 has just landed in Fedora 22! There's still much to be done, but I think the hardest part is done. Thanks to everyone who helped this to happen!
On 11/18/2014 06:05 AM, Tom Dunstan wrote:
The GradleVersion class allows things such as '1.0-milestone-5a' and '2.2-rc-2', but the allowed "stage" strings are hardcoded. I'll see if
we
can come up with something that allows a distributor to set it to
something
custom. I presume we'll want it to look like e.g. '2.2-f22-17' where 17 would be the rpm spec version. Then the vender specific part could be adjusted to reflect the distributor, e.g. 'f22', 'el7' etc, and so a
user
asking for help has their particular build unambiguously identified.
I believe that versioning should be entirely up to upstream and I will respect upstream decision in this matter. I will bring this up with upstream and until I get response I will use standard versioning.
I'll ask internally as to what we'd like. It'll mostly be viewed from the user support perspective I suspect.
Currently gradle --version prints:
Gradle 2.2-20141119142823+0000
Build time: 2014-11-19 14:28:23 UTC Build number: none Revision: <unknown>
Groovy: 2.3.7 Ant: Apache Ant(TM) version 1.9.4 compiled on August 11 2014 JVM: 1.8.0_40 (Oracle Corporation 25.40-b16) OS: Linux 3.16.7-200.fc20.x86_64 amd64
And build-receipt.properties contains:
buildNumber=none buildTimestamp=20141119142823+0000 commitId=<unknown> hostname=unknown isSnapshot=true javaVersion=1.8.0_40 osName=Linux osVersion=3.17.2-200.fc20.x86_64 project=gradle rcNumber= username=mockbuild versionBase=2.2 versionNumber=2.2-20141119142823+0000
This should definitely be improved, but I will wait for upstream input how these fields should look like in Fedora gradle RPM package.
-- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk
PS. Tomorrow I will send an email with more details about Gradle integration with Fedora, but I think I deserve some rest now :)
On Thu, Nov 20, 2014 at 2:03 AM, Mikolaj Izdebski mizdebsk@redhat.com wrote:
This should definitely be improved, but I will wait for upstream input
how these fields should look like in Fedora gradle RPM package.
Great work Mokilaj!
We reckon that setting the build number to something like 'fedora22-3' where 3 is the rpm spec version would probably do the trick. If someone pops up with a weird error in our forums, we'll probably ask them to run gradle --version anyway and the build number is right there at the top.
So leave the version number as whatever the release version number is and set the build number to something identifiable.
Thanks!
On 11/20/2014 02:11 AM, Tom Dunstan wrote:
On Thu, Nov 20, 2014 at 2:03 AM, Mikolaj Izdebski mizdebsk@redhat.com wrote:
This should definitely be improved, but I will wait for upstream input
how these fields should look like in Fedora gradle RPM package.
Great work Mokilaj!
We reckon that setting the build number to something like 'fedora22-3' where 3 is the rpm spec version would probably do the trick. If someone pops up with a weird error in our forums, we'll probably ask them to run gradle --version anyway and the build number is right there at the top.
So leave the version number as whatever the release version number is and set the build number to something identifiable.
I've included full Fedora package release number in Gradle build number. Now gradle --version prints:
------------------------------------------------------------ Gradle 2.2 ------------------------------------------------------------
Build time: 2014-11-20 10:38:24 UTC Build number: Fedora 2.2-2.fc22 Revision: <unknown>
Groovy: 2.3.7 Ant: Apache Ant(TM) version 1.9.4 compiled on August 11 2014 JVM: 1.8.0_40 (Oracle Corporation 25.40-b16) OS: Linux 3.16.7-200.fc20.x86_64 amd64
And build-receipt.properties contains:
buildNumber=Fedora 2.2-2.fc22 buildTimestamp=20141120103824+0000 commitId=<unknown> hostname=buildvm-07.phx2.fedoraproject.org isSnapshot=false javaVersion=1.8.0_40 osName=Linux osVersion=3.17.2-200.fc20.x86_64 project=gradle rcNumber= username=mockbuild versionBase=2.2 versionNumber=2.2
To fix host name I had to apply a patch, which I submitted as PR: https://github.com/gradle/gradle/pull/354
On 19 Nov 2014, at 16:33, Mikolaj Izdebski wrote:
I'm glad to announce that Gradle 2.2 has just landed in Fedora 22! There's still much to be done, but I think the hardest part is done. Thanks to everyone who helped this to happen!
Excellent!
On 11/18/2014 06:05 AM, Tom Dunstan wrote:
The GradleVersion class allows things such as '1.0-milestone-5a' and '2.2-rc-2', but the allowed "stage" strings are hardcoded. I'll see if we can come up with something that allows a distributor to set it to
something
custom. I presume we'll want it to look like e.g. '2.2-f22-17' where 17 would be the rpm spec version. Then the vender specific part could be adjusted to reflect the distributor, e.g. 'f22', 'el7' etc, and so a user asking for help has their particular build unambiguously identified.
I believe that versioning should be entirely up to upstream and I will respect upstream decision in this matter. I will bring this up with upstream and until I get response I will use standard versioning.
I'll ask internally as to what we'd like. It'll mostly be viewed from the user support perspective I suspect.
Currently gradle --version prints:
Gradle 2.2-20141119142823+0000
Build time: 2014-11-19 14:28:23 UTC Build number: none Revision: <unknown>
Groovy: 2.3.7 Ant: Apache Ant(TM) version 1.9.4 compiled on August 11 2014 JVM: 1.8.0_40 (Oracle Corporation 25.40-b16) OS: Linux 3.16.7-200.fc20.x86_64 amd64
And build-receipt.properties contains:
buildNumber=none buildTimestamp=20141119142823+0000 commitId=<unknown> hostname=unknown isSnapshot=true javaVersion=1.8.0_40 osName=Linux osVersion=3.17.2-200.fc20.x86_64 project=gradle rcNumber= username=mockbuild versionBase=2.2 versionNumber=2.2-20141119142823+0000
This should definitely be improved, but I will wait for upstream input how these fields should look like in Fedora gradle RPM package.
-- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk
PS. Tomorrow I will send an email with more details about Gradle integration with Fedora, but I think I deserve some rest now :) -- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
On Wed, Nov 19, 2014 at 4:33 PM, Mikolaj Izdebski mizdebsk@redhat.com wrote:
I'm glad to announce that Gradle 2.2 has just landed in Fedora 22! There's still much to be done, but I think the hardest part is done. Thanks to everyone who helped this to happen!
Hi,
I have actually spoken (in French) about this issue a couple times. And by issue I mean, both Fedora's "First" principle and packaging guidelines that do not necessary align with upstream vendors goals. I took Gradle as an example, because I had enough material to elaborate.
I am glad to see Gradleware proving me wrong over time, and impressed by Mikolaj's work!
I am already looking forward f22 thanks to you :)
Cheers, Dridi
java-devel@lists.fedoraproject.org
-
Dridi Boukelmoune -
gil -
Max Rydahl Andersen -
Michal Srb -
Mikolaj Izdebski -
Tom Dunstan