On 2011-11-29 15:33:31 (+0100), Duncan Mac-Vicar P. <dmacvicar@suse.de> wrote:
To revive the discussion about pom2spec :-)
Oh, good :)
I was playing with it and it is exactly the kind of pragmatism one is missing when dealing with Java. Nice work Pascal. I remember there where a few topics open when Pascal presented it in the mailing list.
- Naming
while org.apache.maven.doxia.doxia-sink-api is already long, do you think it makes sense to prefix this with java- or jar- ? (like rubygems- do). I do think the whole groupId artifactId is the better way, but I am not sure if in all cases it would be needed. May be one could specify a shorter way (java-doxia-sink-api) in the command line, when ambiguity is not likely. Requires and Provides would still work using the Provides: java(org.apache.maven.doxia:doxia-sink-api) kind of string.
Sure, we could have our way through the Provides, and use shorter names for the packages where it makes sense.
- Provides.
Right now it uses something like java(org.apache.maven.doxia:doxia-sink-api). I just want to point out that fedora is already using mvn(org.apache.maven.doxia:doxia-sink-api). Do we want to interoperate across them?
I don't see the point of "mvn()" right now, and not "java()"... but yes, if we can interop, we should. I would simply add both. "mvn(...)" seems to imply it comes from a Maven repository, or it just means it is a Maven-alike signature (groupId:artifactId[:version]). If it's the latter, then it would be pointless to have both java(...) and mvn(...). I find java(...) more natural, but mvn(...) would be interoperable, so interoperable wins :)
Other points:
- Binaries. For example:
$ mkdir org.scala-tools.sbt.sbt-launch $ cd org.scala-tools.sbt.sbt-launch $ pom2spec call again and specify the exact version, one of: - 0.7.1 - 0.7.2 $ pom2spec 0.7.2
In this case, the built rpm misses the %{_bindir}/sbt which is just a call to java -Xmx512M -jar $longdir/sbt-launch.jar "$@"
It would be a nice feature to tell pom2spec something like -bin sbt and it could create the script automatically.
Not sure that always works, or that an automatically created script would be good enough for a majority of cases. There are probably quite a few where you'd rather want to build a longer classpath (especially if the META-INF doesn't include the Class-Path attribute), or pass along some system properties with -D, etc... And how would the script know which jar file contains the static main method? Hm. Ok, we could scan for it... but wouldn't that just provide more false positives than anything else ? OTOH, sure, if we find some valid use cases and the right logic to implement in the script, the sky is the limit, we can definitely add it :)
- One question... how is the classpath supposed to work? I see some .classpath files put together to the jars, but empty.
They're only empty if there are no additional jar files to include in the classpath. The naive idea here is to exec java -cp $(cat /usr/share/java/org.scala/sbt/.classpath) \ -jar .../sbt-launch.jar "$@" and even aggregate the classpathes from different dependencies. Too naive to work though, needs some more thought (especially in order to avoid duplicates in the classpath that have different versions). But well, the information is there, so I thought I could store it, it might be useful :)
- Why an artifact like Vaadin creates 2 rpms for the binary and 2 for the sources?
Wrote: /space/packages/rpms/noarch/com.vaadin.vaadin-6.7.2-6.7.2-0.noarch.rpm Wrote: /space/packages/rpms/noarch/com.vaadin.vaadin-6.7.2-6_7_2-6.7.2-0.noarch.rpm Wrote: /space/packages/rpms/noarch/com.vaadin.vaadin-6.7.2-sources-6.7.2-0.noarch.rpm Wrote: /space/packages/rpms/noarch/com.vaadin.vaadin-6.7.2-6_7_2-sources-6.7.2-0.noarch.rpm
No idea, I'd have to check, it's been quite some time I wrote pom2spec :D cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- we haz green _\_v http://fosdem.org -- we haz conf