Suggestion for jogl with Ivy

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Suggestion for jogl with Ivy

Mike
Jogl looks for a native jar using the naming convention:  jogl jar name + target +".jar"
eg. if I named my jogl jar "jogl-2.0.2-rc12.jar", then it would look in the same folder for jogl-2.0.2-rc12-natives-windows-amd64.jar

In the above the version is ignored by the naming convention and the effect is that it looks for:  jogl jar name + version+ target +".jar"

This doesn't work well with Ivy versions of jars so I suggest that an alternate name convention is also looked for:  
jogl jar name + target + version + ".jar"  or perhaps even make the convention configurable.

eg. for the above example, the native jar alternate name would be: jogl-natives-windows-amd64-2.0.2-rc12.jar
Reply | Threaded
Open this post in threaded view
|

Re: Suggestion for jogl with Ivy

Sven Gothel
Administrator
On 07/10/2013 09:16 AM, Mike [via jogamp] wrote:
> Jogl looks for a native jar using the naming convention:  jogl jar name +
> target +".jar"
> eg. if I named my jogl jar "jogl-2.0.2-rc12.jar", then it would look in the
> same folder for jogl-2.0.2-rc12-natives-windows-amd64.jar
>
> In the above the version is ignored by the naming convention and the effect is
> that it looks for:  jogl jar name + version+ target +".jar"

Not that I know of, the java jar URL basename is being used
and the '-natives-'os.and.arch is attached, see Wiki / JOGL Deployment docs.

>
> This doesn't work well with Ivy versions of jars so I suggest that an
> alternate name convention is also looked for:  
> jogl jar name + target + version + ".jar"  or perhaps even make the convention
> configurable.
>
> eg. for the above example, the native jar alternate name would be:
> jogl-natives-windows-amd64-2.0.2-rc12.jar

This indeed does not work, since the 'natives-*' appendix
must come last [currently].

We also do not want to query the whole world (network lookup)
for all possible permutations.

~Sven



signature.asc (911 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Suggestion for jogl with Ivy

Mike
I understand the need not to check all possible permutations of the name, but there is a need for JOGL to work with modern dependency managers. It may be a limitation in my knowledge of Ivy, but I don't know how to get round Ivy expecting the version to be just before the .jar extension.

One other very simple alternative that would work with Ivy is for natives-windows-amd64- to come first eg. natives-windows-amd64-jogl-2.0.2-rc12.jar.

Thanks,
Mike
Reply | Threaded
Open this post in threaded view
|

Re: Suggestion for jogl with Ivy

Sven Gothel
Administrator
On 07/10/2013 02:24 PM, Mike [via jogamp] wrote:
> I understand the need not to check all possible permutations of the name, but
> there is a need for JOGL to work with modern dependency managers. It may be a
> limitation in my knowledge of Ivy, but I don't know how to get round Ivy
> expecting the version to be just before the .jar extension.
>
> One other very simple alternative that would work with Ivy is for
> natives-windows-amd64- to come first eg.
> natives-windows-amd64-jogl-2.0.2-rc12.jar.

We don't change our _default_ name space for one deployment scheme.

However, you might consider offering a patch via git,
which would allow plugging in a 'native-jar-name-producer' (NJNP).

Then you could make your NJNP, capable of dealing w/ Ivy's limits.

If you provide such a patch for gluegen, it should:
  - be at least a git patch, w/ your proper author name and our 'no-name' (c)
    & license
  - have 'a few' unit tests in one unit test class

~Sven



signature.asc (911 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Suggestion for jogl with Ivy

Mike
From what I can tell the naming convention for loading is here:
http://jogamp.org/git/?p=gluegen.git;a=blob_plain;f=src/java/com/jogamp/common/os/Platform.java;hb=HEAD

And it is hard coded as:
                        nativeJarName = nativeJarBasename+"-natives-"+PlatformPropsImpl.os_and_arch+".jar";

Unfortunately, I don't have lots of platforms to test loading and I'm not sure how you'd make a plugin work since this code is in a static initializer.

I got JOGL to work by putting the dlls in my path and I got rid of the caught exceptions by defining:
-Djogamp.gluegen.UseTempJarCache=false.

Following that approach, I suggest another property -Djogamp.gluegen.UseAltNaming=true

So below:
private static final String useTempJarCachePropName = "jogamp.gluegen.UseTempJarCache";
Add:
private static final String useAltNamingPropName = "jogamp.gluegen.UseAltNaming";

Then change:
                        nativeJarName = nativeJarBasename+"-natives-"+PlatformPropsImpl.os_and_arch+".jar";
to:
                        if(Debug.getBooleanProperty(useAltNamingPropName , true, true)) {
                          nativeJarName = natives-"+PlatformPropsImpl.os_and_arch+nativeJarBasename+".jar";
                        } else {
                          nativeJarName = nativeJarBasename+"-natives-"+PlatformPropsImpl.os_and_arch+".jar";
                        }          

Cheers,
Mike

Reply | Threaded
Open this post in threaded view
|

Re: Suggestion for jogl with Ivy

jmaasing
In reply to this post by Mike
Ivy is super-flexible (compared to maven), which means that you certainly can make it understand any kind of naming-scheme.  Might not be easy, you might have to revert to an URL resolver instead of an ibiblio-resolver if that is what you are using.

In maven terms this example "-natives-windows-amd64" is a classifier. Which might takes some special magic in the ivy-xml-file if you are using an ibiblio-resolver but there are examples on the internet, search for ivy+classifier.

Basically, anything maven can resolve, ivy can resolve and then some :-)
Reply | Threaded
Open this post in threaded view
|

Re: Suggestion for jogl with Ivy

Mike
Thanks very much for this excellent tip!

Using this I was able to get it working. I changed my my Ivy retrieve pattern to:
                <ivy:retrieve symlink="${ivy.useSymlinks}"
                        pattern="${lib.dir}/[type]/[organization]/[module]/[artifact]-[revision](-[classifier]).[ext]" />

I changed the ivy.xml associated with the jogl jars:
    <artifact name="jogl" type="jar" ext="jar"/>
    <artifact name="joal" type="jar" ext="jar"/>
    <artifact name="gluegen" type="jar" ext="jar"/>
    <artifact name="jogl" type="jar" ext="jar" e:classifier="natives-windows-amd64"/>
    <artifact name="joal" type="jar" ext="jar" e:classifier="natives-windows-amd64"/>
    <artifact name="gluegen" type="jar" ext="jar" e:classifier="natives-windows-amd64"/>

This required changing the ivy-module setup to accept the e parameters:
<ivy-module version="2.0" xmlns:e="http://ant.apache.org/ivy/extra">

I changed the resolver pattern to:
        <property name="ivy.shared.roundup.jars.artifact.pattern" value="[organization]/[module]/[revision]/jars/[artifact]-[revision](-[classifier]).[ext]" />

Cheers,
Mike