On 11/30/2011 07:13 AM, Pascal Bleser wrote:
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.
Good :-)
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 :)
Lets agree on something: Use in general java() and the artifactId full id. Use/add mvn() to interoperate with Fedora maven packages when the package includes the respective fragment and jpp depmap. Sounds reasonable? I would like to start adding java() provides to some stuff in Java:base
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 ?
Doesn't each pom file (and therefore each spec generated) contains always one jar?
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 :)
Ok. Another proposal is to keep both the original name of the jar: /usr/share/java/foobar.jar and make /usr/share/java/org.barfoo.foobar.jar a symlink (or the inverse), this is mostly because build system, especially ant based, tend to look for the original jars and they use build-classpath to replace dependencies.
- 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
Do you plan to add the mentioned features, or should we start with a ruby rewrite? <evil laugh> :-) -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org