Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Curtis Rueden
    @ctrueden
    A word of warning: our previous Debian expert left the community a few years ago. He is one of the best programmers I have ever known, but the Debian packaging of Fiji was still too much for him, time-wise (and maybe bureaucracy/legal-wise).
    Richard Domander
    @rimadoma
    Hi all, I'm getting a java.lang.UnsatisfiedLinkError: Can't load library: <project path>//libgluegen-rt.so exception when trying to call Java 3D stuff from my code (new CustomTriangleMesh()). I guess I need JOGL to solve this. How do I add it via Maven? I tried adding a runtime dependency to net.java.jogl, but that didn't help.
    Richard Domander
    @rimadoma
    Specifically I tried adding:
            <dependency>
                <groupId>org.jogamp.jogl</groupId>
                <artifactId>jogl-all</artifactId>
                <version>2.3.2</version>
                <scope>runtime</scope>
            </dependency>
    Mark Hiner
    @hinerm
    @rimadoma there's a SciJava java3d fork. The 3D viewer imports may help here
    Richard Domander
    @rimadoma
    @hinerm I have these imports in my project already
    Mark Hiner
    @hinerm
    ah :(
    Richard Domander
    @rimadoma
    @hinerm Actually I encountered these issues when running the unit tests in the mavenized version of BoneJ1
    @hinerm In test classes StructureModelIndexTest and VolumeFractionTest
    Richard Domander
    @rimadoma
    Okay, I managed to solve my own problem. The correct dependencies are:
            <!-- JOGL dependencies  -->
            <dependency>
                <groupId>org.jogamp.gluegen</groupId>
                <artifactId>gluegen-rt-main</artifactId>
                <version>2.3.2</version>
                <scope>runtime</scope>
            </dependency>
            <dependency>
                <groupId>org.jogamp.jogl</groupId>
                <artifactId>jogl-all-main</artifactId>
                <version>2.3.2</version>
                <scope>runtime</scope>
            </dependency>
    Richard Domander
    @rimadoma
    Where can I document this for others to find?
    Curtis Rueden
    @ctrueden
    @rimadoma I'm not sure where would be best to document. But we had to do the same thing in the Fiji project:
    Sorry that it is has been long enough now, where I can't remember why I did things that way. But there was a good reason.
    Oh. Because your platform might be different.
    Richard Domander
    @rimadoma
    I'm trying to mvn package BoneJ from the terminal, and I get the following error:
    [INFO] Failed to configure plugin parameters for: org.apache.maven.plugins:maven-enforcer-plugin:1.4.1
    
    Cause: Class 'org.apache.maven.enforcer.rule.api.EnforcerRule' cannot be instantiated
    running with option -e gives the following trace:
    org.apache.maven.lifecycle.LifecycleExecutionException: Error configuring: org.apache.maven.plugins:maven-enforcer-plugin. Reason: Unable to parse the created DOM for plugin configuration
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:723)
    ...
    Any ideas what this could be about? At first I thought that I could solve this by stating the enforcer version in my POM, but that didn't solve it. I get the same error with 1.4.1 than 1.3.1
    Curtis Rueden
    @ctrueden
    @rimadoma Whoa, that's a new one on me!
    Richard Domander
    @rimadoma
    Still, that clearly changed something, because maven downloaded the new enforcer when run for the first time after changing the POM
    Curtis Rueden
    @ctrueden
    Why are you on 1.4.1? Our pom-scijava is on 1.3.1.
    Richard Domander
    @rimadoma
    It's not a huge issue, since building the artefacts goes OK from IntelliJ
    Curtis Rueden
    @ctrueden
    It is a huge issue, because you cannot automate with Jenkins.
    Richard Domander
    @rimadoma
    @ctrueden I changed to 1.4.1 just to see if that would fix the issue. It didn't
    Curtis Rueden
    @ctrueden
    Ah, OK, I see.
    Richard Domander
    @rimadoma
    Maybe it's a problem in my environment? Maybe the build will succeed on the Jenkins server?
    wait, let me just fix that...
    Richard Domander
    @rimadoma
    @ctrueden there, latest changes pushed to the POM
    Curtis Rueden
    @ctrueden
    I do not get your error when I build, but instead a legitimate enforcer failure.
    [INFO] Restricted to JDK 1.6 yet org.scijava:j3dcore:jar:1.6.0-scijava-2:compile contains org/scijava/java3d/DecalGroupRetained.class targeted to JDK 1.7
    [INFO] Restricted to JDK 1.6 yet org.scijava:j3dutils:jar:1.6.0-scijava-2:compile contains org/scijava/java3d/internal/FloatBufferWrapper.class targeted to JDK 1.7
    [WARNING] Rule 5: org.apache.maven.plugins.enforcer.EnforceBytecodeVersion failed with message:
    Found Banned Dependency: org.scijava:j3dcore:jar:1.6.0-scijava-2
    Found Banned Dependency: org.scijava:j3dutils:jar:1.6.0-scijava-2
    The following patch makes the whole build succeed on my system:
    diff --git a/Legacy/bonej/pom.xml b/Legacy/bonej/pom.xml
    index 2cde652..372ecdd 100644
    --- a/Legacy/bonej/pom.xml
    +++ b/Legacy/bonej/pom.xml
    @@ -88,6 +88,10 @@
             </repository>
         </repositories>
    
    +    <properties>
    +      <scijava.jvm.version>1.7</scijava.jvm.version>
    +    </properties>
    +
         <dependencies>
             <!-- BoneJ dependencies -->
             <dependency>
    Richard Domander
    @rimadoma
    @ctrueden Cool, I think that'll be ok even if we want to keep legacy BoneJ1 at Java 6. I will move to jdk 1.8 with BoneJ2 though
    Curtis Rueden
    @ctrueden
    It depends on how this BoneJ artifact will be used.
    It will definitely be built at Java 7 level then, which means Java 6 will throw an exception if you try to use it.
    @rimadoma BTW:
    $ mvn -v
    Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T10:41:47-06:00)
    Maven home: /usr/local/Cellar/maven/3.3.9/libexec
    Java version: 1.8.0_73, vendor: Oracle Corporation
    Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_73.jdk/Contents/Home/jre
    Default locale: en_US, platform encoding: UTF-8
    OS name: "mac os x", version: "10.11.4", arch: "x86_64", family: "mac"
    You could try a different Maven core version to see if that makes a difference with your local enforcer error.
    Richard Domander
    @rimadoma
    @ctrueden Ah, well I guess it's again related to the problems with legacy code, Java3d, Java 8, that forum thread (http://forum.imagej.net/t/java3d-issue-bonej-with-latest-fiji-version-problem-solved/1151/29). I made a post there earlier today, so let's take that jvm version discussion there, shall we?
    @ctrueden Sure, I'll try a different core version, and report back later
    Richard Domander
    @rimadoma
    @ctrueden Okay, I installed maven 3.3.9 which removed that exception. Maven now runs to that enforcer error on my comp too :+1:
    @ctrueden Interestingly the newest maven from apt-get was 3.0.5, so I had to add a repo (https://launchpad.net/~andrei-pozolotin/+archive/ubuntu/maven3) to apt-get to install 3.3.9
    @ctrueden Also when I googled for the exception I was getting I ran into this old conversation: https://groups.google.com/forum/#!topic/fiji-devel/k_6X3DY_cPY
    Curtis Rueden
    @ctrueden
    @rimadoma Which version of Ubuntu do you run?
    Richard Domander
    @rimadoma
    @ctrueden 14.04 Kylin
    Curtis Rueden
    @ctrueden
    Probably, newer versions ship a newer Maven, as well.
    If 3.0.5 really does not work, we should update the minimum requirement in pom-scijava accordingly.
    Stefan Helfrich
    @stelfrich
    @ctrueden ImageJ doesn’t currently run on 32-bit Windows 10 due to the 3/4 of available memory approximation for maximum heap space. This evaluates to 1.5G (=3/4*2G) on two different systems, which leads to the JVM telling me Could not reserve enough space for 1572864KB object heap.. Can anyone confirm that issue? Also fails for 32-bit ImageJ/Fiji on a 64-bit Windows 10..
    Curtis Rueden
    @ctrueden
    @stelfrich It is a known issue but AFAIK does not happen on every system. Feel free to patch the imagej-launcher code to fix, if you have time.
    I have Win systems where 32-bit Java cannot start with as little as 1.1g. And others where it will start fine with 1.4g.
    Stefan Helfrich
    @stelfrich
    @ctrueden is that specific to Win10?
    Curtis Rueden
    @ctrueden
    I should clarify that I have tested fewer Win10 systems. I do not know for a fact that Win10 32-bit works with any system.