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 -- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
