[fedora-java] Gradle in Fedora

Tue Nov 18 05:05:00 UTC 2014

Hi Mikolaj

On Mon, Nov 17, 2014 at 11:26 PM, Mikolaj Izdebski <mizdebsk at redhat.com>
wrote:

> I heard that some build scripts may use features which were removed in
> Gradle 2.x.  The focus is on latest 2.x version first and then we'll see
> if 1.x will be packaged too or not. (I would like to keep only the
> latest version in Fedora if possible.)
>

Do you have examples of which deprecated features are causing issues (other
than the ivy resolver stuff mentioned below)? There may be other ways to
accomplish the feature, or we may be able to reintroduce a similar feature
if needed.

> > The GradleVersion class allows things such as '1.0-milestone-5a' and
> > '2.2-rc-2', but the allowed "stage" strings are hardcoded. I'll see if we
> > can come up with something that allows a distributor to set it to
> something
> > custom. I presume we'll want it to look like e.g. '2.2-f22-17' where 17
> > would be the rpm spec version. Then the vender specific part could be
> > adjusted to reflect the distributor, e.g. 'f22', 'el7' etc, and so a user
> > asking for help has their particular build unambiguously identified.
>
> I believe that versioning should be entirely up to upstream and I will
> respect upstream decision in this matter. I will bring this up with
> upstream and until I get response I will use standard versioning.
>

I'll ask internally as to what we'd like. It'll mostly be viewed from the
user support perspective I suspect.

> > Where are you trying to do this from? It's certainly possible to create
> an
> > ivy repo in a build file. Do you mean that there's no non-DSL way to
> build
> > one?
>
> Ivy "resolver" is not the same as Ivy "repository". Resolver API is
> pluggable interface for resolving artifacts while repository API barely
> defines storage for artifacts.
>
> ArtifactRepositoryContainer of Gradle 1.x provides methods for adding
> resolvers (org.apache.ivy.plugins.resolver.DependencyResolver), but they
> are marked as @Deprecated. Gradle 2.x doesn't support Ivy resolvers at
> all (and AFAIK there is no other API for providing custom code for
> artifact resolution).
>

Ah, I understand. Was this an issue when adding the Xmvn repo, then?

> > What specifically do you want to do?
>
> I will give one specific example. Gradle checks if resolved artifact
> version matches requested dependency version. Fedora we very often
> resolve different version than requested, so this consistency check
> needs to be relaxed, but only in gradle-local, standard gradle
> installation should remain unaffected.
>

Right. Two things to say on that front:

Firstly, with regard to your specific example, one thing that we definitely
would like to encourage in the Java ecosystem is less hard-coding of
specific versions and more use of version ranges. Traditionally many
published poms referred to specific versions just because Maven really
didn't handle version ranges very well in various ways. We have a way to go
to get Gradle to pick optimal sets of packages based on various versions in
some circumstances, but it's definitely a problem on our radar. In any case
I understand that you're stuck with poms published today rather than those
that might be in the future, and you need a way to make it more flexible.

Secondly, we're pretty open to making Gradle more extensible, if we can do
it in a sane way. I guess the question should be what the process is. If
you have a specific change that you would like such as this, feel free to
suggest it on the gradle-dev google group, or ping me as Gradleware's
current unofficial Fedora contact point. It doesn't have to be a totally
thought out design, just a description of the problem that you're solving
and a link to a patch doing it the non-extensible way as a demonstration.
In fact raise it earlier rather than trying to design a full api or dsl or
whatever - that way we can give feedback on the shape of the feature and
the kind of PR that we'd accept as early as possible.

>> * gradle-launcher has "Class-Path" entry in manifest, which is not
> >> allowed in Fedora. I had to patch Gradle launchers to work without this
> >> entry, but I am affraid that there may be third-party launchers that
> >> assume Gradle can be ran with "java -jar gradle-launcher.jar", which
> >> won't work in Fedora. It would be nice if this could somehow be solved
> >> with upstream cooperation.
> >>
> >
> > Can you explain or point to a page with the policy rationale here please?
>
> The policy is at:
> http://fedoraproject.org/wiki/Packaging:Java#No_class-path_in_MANIFEST.MF
>
> For rationale see:
> https://lists.fedoraproject.org/pipermail/java-devel/2013-May/004820.html
>

Thanks. I'll ask about this. I'm not sure about how third party launchers
are launching gradle at all.

> >> Fedora "repository" is not a typical artifact repository at all. It
> >> doesn't have a strict layout (artifacts can have arbitrary file names
> >> and be placed at arbitrary locations in the file system). XMvn knows
> >> where to find them by reading special metadada files stored in
> >> /usr/share/maven-metadata/. Besides that we use custom version
> >> resolution scheme, meaning that POMs from Fedora can't be directly used
> >> by Gradle or Maven as they are. Some artifacts don't have POMs at all -
> >> we have to generate effective POM from metadata on demand.
> >>
> >
> > Do artifact GAVs stay the same?
>
> I don't know what you meant here.
>

Sorry - do library group, artifactId and version stay the same in your
custom resolution scheme? I asked because I had seen examples of what
looked like the /usr/share/java directory structure creeping into the
gradle 1.0 patches - an example is here
http://pkgs.fedoraproject.org/cgit/gradle.git/tree/gradle-1.0-Use-local-available-libraries.patch?id=13f5b32f173c6a925d261dcb9dda82695e302adb
- 'org.slf4j:slf4j-api:1.6.4 at jar' became 'org.slf4j:slf4j/api:1.6.4 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/java-devel/attachments/20141118/a90a74d0/attachment.html>