On 11/18/2014 06:05 AM, Tom Dunstan wrote:
On Mon, Nov 17, 2014 at 11:26 PM, Mikolaj Izdebski
> 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
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
>> '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
>> custom. I presume we'll want it to look like e.g. '2.2-f22-17' where
>> 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
>> ivy repo in a build file. Do you mean that there's no non-DSL way to
> Ivy "resolver" is not the same as Ivy "repository". Resolver API
> 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 , 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 , 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  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
- 'org.slf4j:slf4j-api:1.6.4@jar' became
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
Software Engineer, Red Hat