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