[opensuse-packaging] pom2spec
To revive the discussion about pom2spec :-) 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. - 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? 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. - One question... how is the classpath supposed to work? I see some .classpath files put together to the jars, but empty. - 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 -- 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
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
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
On 2011-12-01 13:53:45 (+0100), Duncan Mac-Vicar P. <dmacvicar@suse.de> wrote:
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: [...] 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
Maybe my reply was unclear: I don't really care, we can have mvn(...) instead of java(...) -- I'm not religious about it :) I suppose the rationale is that a GAV (groupId:artifactId:version) is a "maven way" to refer to an artifact, and hence the "mvn(...)". [...]
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?
Yes. Well, sure, there are pretty simple heuristics we can apply in order to notice whether we should create a wrapper script because the jar file is "executable". The Main-Class attribute in META-INF/MANIFEST.MF, obviously. For other cases (e.g. where there isn't a Main-Class in META-INF, but where the jar file does have a main somewhere), we could specify it explicitly. The spec generator could scan for such (public static main methods in the resulting jar file) and give out warnings/information about it in order to have the packager have a look at it. Could use jdepend or a similar bytecode scraper for that purpose (as I did with jreqprov).
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.
Indeed. Or they have the classpath set in the Class-Path attribute in META-INF/MANIFEST.MF, using the name of the jar files as they were used as dependencies. That might be tricky when upstream isn't using maven or ivy or gradle, would require patching. Maybe we need to post-process the Class-Path in the manifest too, in order to use fully-qualified filenames to the jars, following our convention (/usr/share/java/xxx.jar).
- 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> :-)
Probably not, as I'm currently swamped by a lot of things, it was more of an idea, with a prototype implementation to prove that it can work ;) cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- we haz green _\_v http://fosdem.org -- we haz conf
participants (2)
-
Duncan Mac-Vicar P. -
Pascal Bleser