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.)
> 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.
> 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).
> 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.
>> * 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.