Permalink
Commits on Sep 22, 2016
  1. Merge pull request #423 from lukepalmer/master

    Load multiple native libraries
    msteinhoff committed on GitHub Sep 22, 2016
Commits on Sep 11, 2016
  1. Merge pull request #434 from GreatFruitOmsk/long-port

    Add the Socket.bindToSystemRandomPort method.
    trevorbernard committed on GitHub Sep 11, 2016
  2. Merge pull request #439 from jjbastian/master

    Fix for issue #393
    trevorbernard committed on GitHub Sep 11, 2016
Commits on Sep 9, 2016
Commits on Sep 8, 2016
  1. Fix for issue #393

    - Copied from Brandon Lee (n3wbuck)
    sjlnk committed Sep 8, 2016
Commits on Aug 31, 2016
  1. Merge pull request #437 from zzxx-husky/FixMSCVBuild

    [MSCV] Make VS solution workable
    trevorbernard committed on GitHub Aug 31, 2016
  2. [MSCV] Make VS solution workable

    Fix issue #436.
    
    1. Add release mode.
    2. Add x64 platform.
    3. Fix broken *.vcproj.
    zzxx-husky committed Aug 31, 2016
Commits on Aug 18, 2016
  1. Add the Socket.bindToSystemRandomPort method.

    Let system to pick the port and user to pick the integer type.
    E.g. with VMCI transport int is not longer valid type for port,
    since VMCI's port is internally an unsigned integer and therefore
    Java's long is needed.
    Kentzo committed Aug 18, 2016
Commits on Jul 5, 2016
  1. Merge pull request #429 from jimrthy/autogen/libtoolize

    Newer debian/ubuntu distros changed libtool
    c-rack committed on GitHub Jul 5, 2016
  2. Newer debian/ubuntu distros changed libtool

    For those, we now want libtoolize. But we still need to check for
    libtool for OSX.
    jimrthy committed Jul 5, 2016
Commits on Jun 30, 2016
  1. Merge pull request #427 from adamcavendish/patch-1

    Add instructions to install to local maven
    hintjens committed on GitHub Jun 30, 2016
Commits on Feb 18, 2016
  1. Merge pull request #420 from msteinhoff/master

    Problem: Project does not define contribution process
    trevorbernard committed Feb 18, 2016
Commits on Feb 17, 2016
  1. Problem: Project does not define contribution process

    Solution: Steal CONTRIBUTING.md from czmq project.
    msteinhoff committed Feb 17, 2016
Commits on Feb 9, 2016
  1. Merge pull request #415 from msteinhoff/master

    c-rack committed Feb 9, 2016
  2. Problem: build instructions do not consider new module structure

    Solution: Add instructions to change directory to jzmq-jni before
    compiling JNI stuff.
    msteinhoff committed Feb 9, 2016
  3. Merge pull request #414 from msteinhoff/master

    Problem: mvn package is broken
    c-rack committed Feb 9, 2016
Commits on Feb 8, 2016
  1. Problem: mvn package is broken

    Solution: Replace the usage of ${session.rootDirectory} with
    directory-maven-plugin.
    
    The plugin seems to get the correct path in all cases and mvn package
    runs cleanly on my box. I can't test mvn install because it requires
    some GPG key which I don't have.
    msteinhoff committed Feb 8, 2016
Commits on Feb 3, 2016
  1. Merge pull request #411 from msteinhoff/split-jzmq-core

    Remove all non-JNI classes from jzmq-jni
    hintjens committed Feb 3, 2016
  2. Problem: jzmq-jni module contains jni-unrelated device classes

    Solution: Move all device classes to jzmq-devices module
    msteinhoff committed Feb 3, 2016
  3. Problem: Maven surefire property forkMode is deprecated

    Solution: Use forkCount and reuseForks instead
    msteinhoff committed Feb 3, 2016
  4. Problem: jzmq-jni maven dependency does not consider java.library.path

    Hm, so this is where the fun begins.
    
    Everything compiles happily but the tests in jzmq-core fail because
    libjzmq is not available. In jzmq-jni everything works because the
    java.library.path is configured explicitly in surefire plugin (which is
    not very elegant but the only way that works).
    
    Solution: Move affected maven config back to jzmq-parent pom.xml
    
    Actually, only the native.library-path property is required for this to
    work but there are three maven profiles that set native.library-path,
    native.path and native.os and splitting this up feels unnecessary.
    
    The surefire config must be used in all modules for now so it also moves
    back.
    msteinhoff committed Feb 3, 2016
  5. Problem: jzmq-jni module contains jni-unrelated CZMQ classes

    Solution: Move all CZMQ classes to jzmq-core module
    msteinhoff committed Feb 3, 2016
  6. Merge pull request #410 from msteinhoff/multi-module-build

    Problem: I broke the build
    c-rack committed Feb 3, 2016
  7. Problem: I broke the travis build

    Solution: Fix the travis build
    msteinhoff committed Feb 3, 2016
  8. Problem: Fix for pedantic autotools error messages was incomplete

    Solution: Add missing symlink changes
    msteinhoff committed Feb 3, 2016
  9. Merge pull request #409 from msteinhoff/multi-module-build

    c-rack committed Feb 3, 2016
  10. Problem: Fix pedantic autotools error messages

    Apparently ./autogen.sh insists on having AUTHORS, NEWS, README,
    COPYING, COPYING.LESSER and ChangeLog available for some further copying
    actions.
    
    Solution: Give autogen.sh the files it demands
    msteinhoff committed Feb 3, 2016
  11. Problem: Single-module pom is not sufficient for Java ecosystem cleanup

    Solution: Create maven multi-module project while retaining compatibilty
    
    This creates a new maven project with the following structure:
    
    - jzmq-parent (meta project)
    - jzmq-core (currently empty, will provide a place for CZMQ code in the future)
    - jzmq-jni (Access to low-level Java API via JNI)
    - jzmq (compatibility project with dependencies on core and jni)
    
    The existing code is moved to the jzmq-jni project.
    
    The poms are restructured with the following goals:
    
    1) Parent pom.xml is the canonical source of versions for _all_ plugins
    and dependencies using maven's dependencyManagement resp.
    pluginManagement facility. Because the plugin and depenency versions are
    only defined in one place, version properties become redundant and are
    thus removed.
    
    2) All JNI-specific pom parts are moved to the jzmq-jni pom, while all
    generic pom parts that could also be used for other packages stay in the
    parent pom.
    msteinhoff committed Feb 3, 2016
  12. Problem: Project does not have jenv integration

    Solution: Add .java-version file for java 1.7
    
    jenv (http://www.jenv.be/) provides a convenient way to manage different
    local JDKs. When configured it sets the java version depending on the
    project's java configuration, so you don't have to remember what version
    to use or to create homegrown bash aliases, etc.
    
    This adds a .java-version file (similar to rbenv's .ruby-version or
    pyenv's .python-version) to the project, using Java 1.7 based on the
    java version from pom.xml.
    msteinhoff committed Feb 3, 2016
Commits on Feb 2, 2016
  1. Merge pull request #408 from msteinhoff/master

    Problem: pom.xml has inconsistent intendation
    c-rack committed Feb 2, 2016
  2. Problem: pom.xml has inconsistent intendation

    Sometimes tabs, sometimes spaces...
    
    Solution: Reformat XML file using only spaces.
    msteinhoff committed Feb 2, 2016
Commits on Jan 20, 2016
  1. Merge pull request #406 from snardone/last_ep_pre32fix

    Added version checks for ZMQ_LAST_ENDPOINT and getLastEndpoint() call.
    
    Fixes #405
    c-rack committed Jan 20, 2016