Mailinglist Archive: opensuse-project (168 mails)

< Previous Next >
Re: [opensuse-project] Including or not Java binaries in OBS
  • From: Pascal Bleser <pascal.bleser@xxxxxxxxxxxx>
  • Date: Mon, 23 Apr 2012 12:02:27 +0200
  • Message-id: <20120423100227.GA29056@hera>
On 2012-04-23 10:08:43 (+0200), Ludwig Nussel <ludwig.nussel@xxxxxxx> wrote:
Pascal Bleser wrote:
[...]
I think it would make things a lot easier in many regards if
instead of /usr/share/java/foo/foo.jar we were using the same
scheme as Maven for java library RPMs, namely something like

/usr/share/java/repository/net/sourceforge/cobertura/cobertura/1.9/cobertura-1.9.jar

instead of

/usr/share/java/cobertura/cobertura-1.9.jar

That way, using Maven or Gradle or Ivy, it would be as simple as
defining one of the repositories to be
/usr/share/java/repository instead of having to implement our
current scheme with patches and hacks in Maven.

And to add to that, that's really as simple as patching a Maven
package or adding a few words of XML in Maven's settings.xml

e.g.
<repositories>
<repository>
<id>system</id>
<name>System wide RPM repository</name>
<url>file:///usr/share/java/repository</url>
<layout>default</layout>
<snapshots>
<enabled>false</enabled>
<updatePolicy>never</updatePolicy>
</snapshots>
<releases>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
</releases>
</repository>
</repositories>

Note that we might also be able to take another approach and
keep the current scheme but implement a new <layout/> and add
that to our Maven package (which doesn't exist yet, as far as I
know) which would then map ${groupId}, ${artifactId} and
${version} (commonly referred to as "GAV") to our current
layout, something like
file:///usr/share/java/${artifactId}/${artifactId}-${version}.jar
if I remember correctly (and one can notice that the ${groupId}
information is not present in our current scheme *g*).

But then again, the names of our java packages (I don't mean
openjdk) don't necessarily reflect their de-facto official names
as defined in the central Maven repository (e.g. Google's Guava
library is groupId="com.google.guava", artifactId="guava" while
it might have been packaged as an RPM as java-google-guava or
whatever, which wouldn't match.)

That sounds like a very low hanging fruit. What's the reason for the
current scheme?

I have no idea, but I would assume not knowing about the Maven
repository layout.
I guess it stems from jpackage, which might actually be older
than Maven ^^

I really don't know, but the current layout really doesn't have
any advantages at all, none.

cheers
--
-o) Pascal Bleser
/\\ http://opensuse.org -- we haz green
_\_v http://fosdem.org -- we haz conf
< Previous Next >