On 11/18/2014 06:05 AM, Tom Dunstan wrote: > On Mon, Nov 17, 2014 at 11:26 PM, Mikolaj Izdebski <mizdebsk@xxxxxxxxxx> > 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-available-libraries.patch?id=13f5b32f173c6a925d261dcb9dda82695e302adb > - '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/a50e4ad5b8b86b8280e5296d03db90877364630f [3] https://github.com/mizdebsk/xmvn/blob/master/xmvn-connector-ivy/src/main/java/org/fedoraproject/xmvn/connector/ivy/IvyResolver.java -- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
