I added new config/java.m4 file with several macros that might help with 
building and packaging java applications.

http://sipxecs.sipfoundry.org/rep/sipXecs/main/config/java.m4

The most interesting one is a CHECK_JAR macro. I intended to base it on 
CHECK_LIB macro: but I only have a cursory knowledge of autoconf so if 
you see ways to make it better, let me know.

The idea is that using CHECK_JAR macro removes the necessity of:
(1) keeping jars in your private lib directory - you install them using 
platform package mechanism
(2) managing your classpath manually in your build scripts (build.xml) 
and your start-up scritps.

CHECK_JAR finds if a specific jar is installed on the system and records 
it's location in a provided output variable. Additionally it adds the 
JAR location to your build and run classpath (CLASSPATH_RUN and 
CLASSPATH_BUILD). You can also pass your own CLASSPATH like variable if 
that's not what you want.

I also defined several most used macros (and I'll be adding more):
CHECK_JUNIT
CHECK_JAIN_SIP
CHECK_LOG4J

Of course, since it's autoconf the variables are replaced in your 
Makefile and we mostly use ant for building. So sipXconfig is using sed 
to replace this variables in build.properties file: it makes them 
available in ant files and in your start-up scripts.

Check out sipXconfig/Makefile.am and the way it builds it 
build.properties. Better ideas on how to use it welcomed.

Currently CHECK_JAR is using find_jar utility provided by 
jpackage_utils. I am not sure if it's available on all platforms: 
suggestions on how to make it more portable welcomed.


Now for people who actually care about it: the way we are checking for 
jars goes against the way suggested by jpackage guidelines. If you use 
our CHECK_JAR macro your classpath is created statically during the 
build. If you use tools provided by jpackage wrapper scripts your 
classpath is dynamically created every time you run application.

I decided to go with static classpath as it seems to be more portable 
approach: but it's easy to change once some type of consensus on how to 
package java applications on Linux/BSD/Solaris etc. emerges.

D.

_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev

Reply via email to