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
    Ideally, we would have one package for ImageJ2 core, and one for Fiji, but unfortunately it seems Debian policy is that every single individual JAR file must have its own package. Maybe this is better for bandwidth anyway...
    Curtis Rueden
    @ctrueden
    Anyway, @ipatrol, if you are a Debian expert who wants to help with packaging, that would be awesome. :smile:
    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.