[jitsi-dev] [libjitsi-commits] master: Remove jspeex from classpath (Closes #56) (fc525c7)

Archive
1

Thank you very much, Ingo!

···

2015-07-27 4:19 GMT-05:00 <ingo@jitsi.org>:

Repository : ssh://lists.jitsi.org/libjitsi

On branch : master
Link : https://github.com/jitsi/libjitsi/compare/2c1b704222cc4b5454e9ae4c4e0a28d79ac8e780...fc525c7bd57c02c0e5ff6e878a33751a7d421457

---------------------------------------------------------------

commit fc525c7bd57c02c0e5ff6e878a33751a7d421457
Author: Ingo Bauersachs <ingo@jitsi.org>
Date: Mon Jul 27 11:08:50 2015 +0200

    Remove jspeex from classpath (Closes #56)

---------------------------------------------------------------

fc525c7bd57c02c0e5ff6e878a33751a7d421457
.classpath | 1 -
1 file changed, 1 deletion(-)

diff --git a/.classpath b/.classpath
index 87fe518..57f0535 100644
--- a/.classpath
+++ b/.classpath
@@ -11,7 +11,6 @@
        <classpathentry kind="lib" path="lib/jitsi-lgpl-dependencies.jar"/>
        <classpathentry kind="lib" path="lib/jna.jar"/>
        <classpathentry kind="lib" path="lib/json-simple-1.1.1.jar"/>
- <classpathentry kind="lib" path="lib/jspeex.jar"/>
        <classpathentry kind="lib" path="lib/osgi.core.jar"/>
        <classpathentry kind="lib" path="lib/sdes4j.jar"/>
        <classpathentry kind="lib" path="lib/zrtp4j-light.jar"/>

2

Thank you very much, Ingo!

You're welcome. I was wondering though: how complete do you consider
libjitsi's pom? If 'complete' then we should remove IDE specific files from
the repository. The IDE (or a plugin therein) can generate them on the fly.

I had tons of compiler errors when importing the project like this in Eclipse.
This was because Maven defaults to Java 1.5. Adding

          <configuration>
            <source>1.7</source>
            <target>1.7</target>
          </configuration>

to the maven-compiler-plugin solved that. IMO we should add that to the
universe-pom. Not quite sure about the version though. I'd prefer 1.8, but
that would probably conflict with some Linux distributions. 1.6 seems too old
now, it's EOL over two years now [1].

Ingo

[1] http://www.oracle.com/technetwork/java/eol-135779.html

3

Hello, Ingo!

It's very nice to hear from you again!

You're welcome. I was wondering though: how complete do you consider
libjitsi's pom?

We have to talk more about the JNI binaries because there is a
division here on the subject of jar-ing them all together - we'll
effectively be shipping a single jar with binaries of 5 architectures
thus causing a huge increase in file size.

Additionally, we don't have many developers at this time who have
tried the newly-introduced Maven support.

These two above are reasons to lead me to believe that libjitsi's pom
is incomplete.

If 'complete' then we should remove IDE specific files from
the repository. The IDE (or a plugin therein) can generate them on the fly.

Even if libjitsi's pom is incomplete, I don't see why removing the
IDE-specific files should be postponed. As far as I'm concerned, we
just need someone to test the current pom in IntelliJ IDEA, Eclipse
and NetBeans and, if it works in these, I suppose we can delete the
IDE-specific files.

I had tons of compiler errors when importing the project like this in Eclipse.
This was because Maven defaults to Java 1.5. Adding

          <configuration>
            <source>1.7</source>
            <target>1.7</target>
          </configuration>

to the maven-compiler-plugin solved that. IMO we should add that to the
universe-pom. Not quite sure about the version though. I'd prefer 1.8, but
that would probably conflict with some Linux distributions. 1.6 seems too old
now, it's EOL over two years now [1].

Ingo

[1] http://www.oracle.com/technetwork/java/eol-135779.html

I tried to avoid version upgrades when developing the initial Maven
support. I see now that libjitsi's build.xml has javac source and
target at 1.6 so I could add that to libjitsi's pom as well if you
want? I'm personally OK with 1.8 as well but I'm not sure Debian will
like that.

Best regards,
Lyubo

···

2015-07-27 12:29 GMT-05:00 Ingo Bauersachs <ingo@jitsi.org>:

4

Be aware that when you specify the source and target versions in the pom,
it does NOT mean that only the targets bytecode will be in the compiled
classes. To be more clear, with an example:

1. A pom specifies 1.7 for source and target

2. JDK 8 is installed on build computer

3. Maven compiles the code and produces the package

A user has JDK 7 installed and they use the package compiled in the
previous steps. The application throws an exception due to a missing
function in the JDK. The exception looks like this:

Caused by: java.lang.NoSuchMethodError: org.red5.server.scope.
Scope$ConcurrentScopeSet.keySet()Ljava/util/concurrent/
ConcurrentHashMap$KeySetView;

To resolve this and to end up with the target you want, use MAVEN_OPTS in
your build command line or build using the target JDK installed. Here's
what I use:

MVN_OPTS="-Dmaven.test.skip=true -Dmaven.compiler.fork=true
-Dmaven.compiler.executable=/usr/lib/jvm/java-7-openjdk-amd64/bin/javac"
export MVN_OPTS

Regards,
Paul

···

On Mon, Jul 27, 2015 at 3:20 PM, Lyubomir Marinov < lyubomir.marinov@jitsi.org> wrote:

Hello, Ingo!

It's very nice to hear from you again!

2015-07-27 12:29 GMT-05:00 Ingo Bauersachs <ingo@jitsi.org>:
> You're welcome. I was wondering though: how complete do you consider
> libjitsi's pom?

We have to talk more about the JNI binaries because there is a
division here on the subject of jar-ing them all together - we'll
effectively be shipping a single jar with binaries of 5 architectures
thus causing a huge increase in file size.

Additionally, we don't have many developers at this time who have
tried the newly-introduced Maven support.

These two above are reasons to lead me to believe that libjitsi's pom
is incomplete.

> If 'complete' then we should remove IDE specific files from
> the repository. The IDE (or a plugin therein) can generate them on the
fly.

Even if libjitsi's pom is incomplete, I don't see why removing the
IDE-specific files should be postponed. As far as I'm concerned, we
just need someone to test the current pom in IntelliJ IDEA, Eclipse
and NetBeans and, if it works in these, I suppose we can delete the
IDE-specific files.

> I had tons of compiler errors when importing the project like this in
Eclipse.
> This was because Maven defaults to Java 1.5. Adding
>
> <configuration>
> <source>1.7</source>
> <target>1.7</target>
> </configuration>
>
> to the maven-compiler-plugin solved that. IMO we should add that to the
> universe-pom. Not quite sure about the version though. I'd prefer 1.8,
but
> that would probably conflict with some Linux distributions. 1.6 seems
too old
> now, it's EOL over two years now [1].
>
> Ingo
>
> [1] http://www.oracle.com/technetwork/java/eol-135779.html

I tried to avoid version upgrades when developing the initial Maven
support. I see now that libjitsi's build.xml has javac source and
target at 1.6 so I could add that to libjitsi's pom as well if you
want? I'm personally OK with 1.8 as well but I'm not sure Debian will
like that.

Best regards,
Lyubo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
http://gregoire.org/
https://github.com/Red5 <http://code.google.com/p/red5/>

5

Hi

It's very nice to hear from you again!

Thanks :slight_smile:

You're welcome. I was wondering though: how complete do you consider
libjitsi's pom?

We have to talk more about the JNI binaries because there is a
division here on the subject of jar-ing them all together - we'll
effectively be shipping a single jar with binaries of 5 architectures
thus causing a huge increase in file size.

Apart from the file size I don't see that as a bad thing. It kind of keeps up
with Java's promise of compile once.

Couldn't we generate different jars, a generic one and one for each platform
with profiles or something the like? So that e.g. the one we publish on
Sonatype/in our repo contains all platforms, but e.g. a build run for
videobridge-windows only includes win-x86.

Additionally, we don't have many developers at this time who have
tried the newly-introduced Maven support.

Well, that'll change soon - starting with me :slight_smile:
Thanks a lot for your efforts!

These two above are reasons to lead me to believe that libjitsi's pom
is incomplete.

If 'complete' then we should remove IDE specific files from
the repository. The IDE (or a plugin therein) can generate them on the fly.

Even if libjitsi's pom is incomplete, I don't see why removing the
IDE-specific files should be postponed. As far as I'm concerned, we
just need someone to test the current pom in IntelliJ IDEA, Eclipse
and NetBeans and, if it works in these, I suppose we can delete the
IDE-specific files.

Well, Eclipse does work (apart from the fact that 1.6 compiler requirement).

I had tons of compiler errors when importing the project like this in
Eclipse. This was because Maven defaults to Java 1.5. Adding

          <configuration>
            <source>1.7</source>
            <target>1.7</target>
          </configuration>
to the maven-compiler-plugin solved that. IMO we should add that to the
universe-pom. Not quite sure about the version though. I'd prefer 1.8,
but that would probably conflict with some Linux distributions. 1.6
seems too old now, it's EOL over two years now [1].

Ingo

[1] http://www.oracle.com/technetwork/java/eol-135779.html

I tried to avoid version upgrades when developing the initial Maven
support. I see now that libjitsi's build.xml has javac source and
target at 1.6 so I could add that to libjitsi's pom as well if you
want?

Yes, please do that.

I'm personally OK with 1.8 as well but I'm not sure Debian will
like that.

1.7 should probably be okay. I don't know about 1.8. It's been backported to
older releases and Jitsi itself is not even included in any release (apart
from the broken one in Ubuntu 14.04). While they may not specifically like it,
I don't see a technical reason not to do it. Maybe someone from the Linux
community can give a hint on that.

And it would give us lambdas. :slight_smile:

Best regards,
Lyubo

Thanks,
Ingo

···

2015-07-27 12:29 GMT-05:00 Ingo Bauersachs <ingo@jitsi.org>:

6

Be aware that when you specify the source and target versions in the pom, it
does NOT mean that only the targets bytecode will be in the compiled
classes.
To be more clear, with an example:

1. A pom specifies 1.7 for source and target

2. JDK 8 is installed on build computer

3. Maven compiles the code and produces the package

A user has JDK 7 installed and they use the package compiled in the previous
steps. The application throws an exception due to a missing function in the
JDK. The exception looks like this:

Caused by: java.lang.NoSuchMethodError:
org.red5.server.scope.Scope$ConcurrentScopeSet.keySet()Ljava/util/concurr
ent/ ConcurrentHashMap$KeySetView;

I'm not sure I'm following. Doesn't that only occur if you use a method from
JDK8 that doesn't exist in JDK7? Otherwise what's the point of having these
options at all?

To resolve this and to end up with the target you want, use MAVEN_OPTS in
your build command line or build using the target JDK installed. Here's what
I use:

MVN_OPTS="-Dmaven.test.skip=true -Dmaven.compiler.fork=true -
Dmaven.compiler.executable=/usr/lib/jvm/java-7-openjdk-amd64/bin/javac"
export MVN_OPTS

Or just running maven from a shell whose PATH and JDK_HOME point to a JDK7.

Regards,
Paul

Thanks for the heads-up!

Ingo