Gradle in Fedora

[Tom Dunstan]

(resending as I wasn't properly subscribed to the list, sorry for those
getting it twice, please reply to this one to set reply headers correctly)

Hi all

After a few emails going around a couple of weeks ago, I would like to
re-kick-off a discussion about how to get a functional Gradle build into
Fedora. Given the recent Fedora 21 beta, it also seems like a good time to
try to work out what might be achievable for Fedora 22.

I've had a look at both the plan (
https://fedoraproject.org/wiki/User:Mizdebsk/PackagingGradle) and Mikolaj's
work here https://github.com/mizdebsk/gradle-packaging, which look great,
and seems like a sane path to getting Gradle into Fedora.

Feedback
---

Some feedback on the existing TODO list and work done so far:

 - TODO item "report usage of non-free JSON library (org.json:json)" - we
no longer use this

 - Porting to aether-ant-tasks - we would probably accept a pull request to
upstream this, as we'll need to do it at some point anyway. There may be
some work on our end to work out / around any differences between the
implementations. Has the Fedora Java team found much in the way of
incompatibility when porting between the two?

 - Disabling the analytics plugin - this is disabled in Gradle 2.2, which
was just released.

 - Local mode / xmvn integration - this looks a lot cleaner than the gradle
1.0 patches! I wonder if it would be possible to add the /usr/share/java
repo without patching gradle itself - maybe using a local init script to
add the repo when doing a Fedora build. But then the repo wouldn't be
available outside the Fedora build process.

 - Upgrading Jetty. Mostly we're pointing people to use the external Gretty
plugin. See below for concerns.

One concern that we have is that any user-visible changes made to Gradle
will result in non-portable build scripts. A user using e.g. Gradle 2.2
that they installed using yum will end up using Jetty 9, which is very
different to the Jetty 6 that users of the standard Gradle distribution
will use. This may then cause issues for users using the standard
distribution to build the target project. The same goes for any plugins
that might not be enabled (there were lots of these in the earlier
Fedora-Gradle 1.0 patches), or non-standard repositories such as xmvn.
While we would obviously prefer perfect compatibility, I can certainly
understand not wanting to keep older versions of certain packages around
forever in Fedora. It would be nice if, when using different packages such
as Jetty, a warning were emitted in the build to notify the user that they
are using a different version to the normal Gradle distribution and that
the build may be non-portable.

Another thing to consider would be modifying the version string to include
"-fedora" or -"rpm" or something like that so that users with issues
turning up at forums.gradle.org can report when they're using the rpm-based
distribution. Is there a standard Fedora policy for doing such things?

Testing
---

We have a large set of tests that we run as part of our continuous
integration and release processes. These tests take some hours to complete.
It looks like at least some rpm specs in fedora have the ability to run
bundled tests. What is the policy for when these tests are run? Does the
fedora build machinery run full test suites even if they take that long? We
would really like to see the full set of tests run against the patched
Gradle to get some level of confidence that the patches applied have not
harmed build compatibility.

Opportunities / Ideas
---
One idea that came to mind was enhancing the application plugin to create
application distributions that have symlinks to the correct jar inside
/usr/share/java rather than copying the jar into the distribution - that
might make life easier for devs / packagers trying to package Gradle-built
java applications.

Another idea to consider is allowing a user to add the Xmvn repo to their
buildscript / build classpaths without having to patch their project build
file. This could be achieved by dropping a file into $GRADLE_HOME/init.d
which adds the Xmvn repo when a particular system property is set. Another
system property could disable all other repos - this would be
building-rpm-mode. See
http://www.gradle.org/docs/current/userguide/init_scripts.html for an
example of how to do this.

Questions
---

Are you folks aware of particular packages that Gradle uses or other issues
that are likely to cause problems while iterating through phase 3 of the
bootstrap plan? In particular if there's anything that we can do to help
that process along, it would be good to know about it. One that leaps to
mind is "shading" dependent libraries - we do this in a few places to stop
the api available to the buildscript from being polluted.

Although I guess it's a little bit off-topic for this list, do you know if
the Xmvn repo structure is compatible with debian's /usr/share/maven-repo?

How different is the Xmvn repo from a normal maven or ivy repo on the
filesystem?


Thanks, and please let me know of your thoughts

Regards

Tom

--
Tom Dunstan
tom.dunstan(a)gradleware.com

[Mikolaj Izdebski]

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,
-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk


[1] http://jira.codehaus.org/browse/XSTR-763
[2]
https://repo.gradle.org/gradle/libs/org/json/json/20140107/json-20140107.pom

[Tom Dunstan]

Hi Mikolaj

On Wed, Nov 12, 2014 at 8:59 PM, Mikolaj Izdebski <mizdebsk(a)redhat.com&gt;
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

[Michal Srb]

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

[1]: http://www.gradle.org/installation

[Max Rydahl Andersen]

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. 


/max
http://about.me/maxandersen

[Tom Dunstan]

Hi Max

On Fri, Nov 14, 2014 at 8:42 PM, Max Rydahl Andersen <manderse(a)redhat.com&gt;
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

[Max Rydahl Andersen]

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(a)redhat.com&gt;
>  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 

/max
http://about.me/maxandersen

[Mikolaj Izdebski]

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.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk

[Tom Dunstan]

Hi Mikolaj

On Mon, Nov 17, 2014 at 11:26 PM, Mikolaj Izdebski <mizdebsk(a)redhat.com&gt;
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-a...
- '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

[Mikolaj Izdebski]

On 11/18/2014 06:05 AM, Tom Dunstan wrote:
>  On Mon, Nov 17, 2014 at 11:26 PM, Mikolaj Izdebski
> <mizdebsk(a)redhat.com&gt;
>  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-a...
>  - '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.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk


[1]
https://github.com/mizdebsk/gradle-packaging/blob/gradle/GradleResolver.java
[2]
https://github.com/mizdebsk/gradle-packaging/commit/a50e4ad5b8b86b8280e52...
[3]
https://github.com/mizdebsk/xmvn/blob/master/xmvn-connector-ivy/src/main/...

[Mikolaj Izdebski]

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 :)

[gil]

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.
>

[Tom Dunstan]

That's awesome!

On Thu, Nov 20, 2014 at 2:03 AM, Mikolaj Izdebski <mizdebsk(a)redhat.com&gt;
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 :)
>

[Tom Dunstan]

On Thu, Nov 20, 2014 at 2:03 AM, Mikolaj Izdebski <mizdebsk(a)redhat.com&gt;
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!

[Mikolaj Izdebski]

On 11/20/2014 02:11 AM, Tom Dunstan wrote:
>  On Thu, Nov 20, 2014 at 2:03 AM, Mikolaj Izdebski
> <mizdebsk(a)redhat.com&gt;
>  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

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk

[Max Rydahl Andersen]

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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/java-devel 

/max
http://about.me/maxandersen

[Dridi Boukelmoune]

On Wed, Nov 19, 2014 at 4:33 PM, Mikolaj Izdebski <mizdebsk(a)redhat.com&gt; 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