[sip-comm-dev] MacOSX package


#1

Hi Emil,

I have recently seen in sc-issues that a task is assigned to create a native izpack launcher for Sip communicator (issues 105/106/107). There are no mentions about a MACOSX izpack launcher.

What is your opinion: do you prefer to have an izpack launcher for OSX or to provide an OSX package? I think the former would be easier to maintain, whereas the later is the most common way to install softwares for OSX users.

In any case, the package is not the only feature that could be provided to MAC users. Some small improvements can be done in the GUI to fit to the MAC OS look and feel: menu bar, help box in the menu bar, some tabs or growbox that may overlap with others boxes etc. I can first focus on that, and we can then decide about the package stuff.

Regards,

···

--
Romain KUNTZ
kuntz@sfc.wide.ad.jp

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hello Romain,

We're going to use izPack for installer packages for Windows and also
Linux until we have volunteers for supporting per distro custom packages.
I entered the issues because we were discussing usage of izPack with
Damian and he agreed to do some tests with it.

In other words izPack is to remain as the default installer for Windows
and a generic replacement for operating systems that we don't have
anything else for. There were no plans in using it as _the_ exclusive
installer solution for SIP Communicator.

I of course remember that you proposed donating dmg packages and agree
that this would be the ideal option for Mac OS X.

Customizing the GUI so that it fits the Mac OS X look and feel is also a
very good idea. It might be easier for you to start with the DMG package
though as well as writing a few lines for generating it from the
build.xml file. This way you would get to know the project structure
before diving into it and besides there's not much to customize in the
GUI right now since it's in quite an early stage in the moment.

Anyways, It's up to you to pick whichever you like better.

Cheers
Emil

Romain KUNTZ wrote:

···

Hi Emil,

I have recently seen in sc-issues that a task is assigned to create a
native izpack launcher for Sip communicator (issues 105/106/107). There are no mentions about a MACOSX izpack launcher.

What is your opinion: do you prefer to have an izpack launcher for OSX or to provide an OSX package? I think the former would be easier to maintain, whereas the later is the most common way to install softwares for OSX users.

In any case, the package is not the only feature that could be provided to MAC users. Some small improvements can be done in the GUI
to fit to the MAC OS look and feel: menu bar, help box in the menu bar, some tabs or growbox that may overlap with others boxes etc. I can first focus on that, and we can then decide about the package stuff.

Regards,


#3

Hello Emil,

Thanks for those clarifications. I will then start by generating the dmg from the build.xml file and then concentrate on the GUI. I hope to get back to you soon with some news.

Cheers,
romain

Emil Ivov wrote:

···

Hello Romain,

We're going to use izPack for installer packages for Windows and also
Linux until we have volunteers for supporting per distro custom packages.
I entered the issues because we were discussing usage of izPack with
Damian and he agreed to do some tests with it.

In other words izPack is to remain as the default installer for Windows
and a generic replacement for operating systems that we don't have
anything else for. There were no plans in using it as _the_ exclusive
installer solution for SIP Communicator.

I of course remember that you proposed donating dmg packages and agree
that this would be the ideal option for Mac OS X.

Customizing the GUI so that it fits the Mac OS X look and feel is also a
very good idea. It might be easier for you to start with the DMG package
though as well as writing a few lines for generating it from the
build.xml file. This way you would get to know the project structure
before diving into it and besides there's not much to customize in the
GUI right now since it's in quite an early stage in the moment.

Anyways, It's up to you to pick whichever you like better.

Cheers
Emil

Romain KUNTZ wrote:

Hi Emil,

I have recently seen in sc-issues that a task is assigned to create a
native izpack launcher for Sip communicator (issues 105/106/107). There are no mentions about a MACOSX izpack launcher.

What is your opinion: do you prefer to have an izpack launcher for OSX or to provide an OSX package? I think the former would be easier to maintain, whereas the later is the most common way to install softwares for OSX users.

In any case, the package is not the only feature that could be provided to MAC users. Some small improvements can be done in the GUI
to fit to the MAC OS look and feel: menu bar, help box in the menu bar, some tabs or growbox that may overlap with others boxes etc. I can first focus on that, and we can then decide about the package stuff.

Regards,

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Romain KUNTZ
kuntz@sfc.wide.ad.jp

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hi Emil,

Long mail, but I have some good news! We can now generate a dmg for SIP Communicator from the build.xml file.

Here is what is needed:
- Install JarBundler for ANT:
http://informagen.com/JarBundler/
This is a small jar to add in the ant lib directory. T

- In sip-communicator-1-0-draft directory, add a macosx and macosx/utils directory. I am not sure where you plan to put the packages, maybe a "release" directory with some sub-directories for each Operating System?

- Add the sipcom.icns icon and JavaApplicationStub file in the macosx/utils directory. You will find them enclosed. BTW, could you provide me a quadrate icon for SIPCommunicator with a transparent background? It will be nicer to display for the application icon.

- Add in build.xml:

    <!-- MACOSX Package -->

    <!-- Put here the release directory -->
    <property name="macosx.app.dir" value="macosx"/>
    <!-- Put here the Application name -->
    <property name="macosx.app.name" value="SIPCommunicator"/>
    <!-- Put here the Application version -->
    <property name="macosx.app.ver" value="1.0"/>

    <target name="macosx" depends="compile" description=".app for MACOSX">
        <taskdef name="jarbundler"
            classname="net.sourceforge.jarbundler.JarBundler"/>

        <property name="macosx.stubfile"
            value="${macosx.app.dir}/utils/JavaApplicationStub"/>
        <condition property="macosx.stubfile"
            value=" /System/Library/Frameworks/JavaVM.framework/Resources/MacOS/JavaApplicationStub">
            <equals arg1="${os.name}"
                arg2="Mac OS X" casesensitive="false" trim="true"/>
        </condition>

        <!-- Delete the old .app if it exists -->
        <delete dir="${macosx.app.dir}/${macosx.app.name}-${macosx.app.ver}.app" quiet="yes"/>

        <!-- This creates the .app for MacOSX -->
        <jarbundler dir="${macosx.app.dir}"
            name="${macosx.app.name}-${macosx.app.ver}"
            shortname="SIP Communicator"
            signature="sipc"
            mainclass="org.ungoverned.oscar.Main"
            icon="${macosx.app.dir}/utils/sipcom.icns"
            jvmversion="1.4+"
            version="${macosx.app.ver}"
            build="draft"
            infostring="SIP Communicator"
            bundleid="org.sip-communicator"
            stubfile="${macosx.stubfile}"
            workingdirectory="$APP_PACKAGE/Contents/Resources/Java">

            <javaproperty name="apple.laf.useScreenMenuBar" value="true"/>
            <javaproperty name="apple.awt.brushMetalRounded" value="true"/>
            <javaproperty name="apple.awt.showGrowBox" value="false"/>

            <!-- Tell oscar to run sip-communicator -->
            <javaproperty name="oscar.config.properties"
                value="file:oscar.client.run.properties"/>
            <!-- Tell java.util.logging about our logging preferences -->
            <javaproperty name="java.util.logging.config.file"
                value="logging.properties"/>

            <jarfileset dir=".">
                <include name="${lib}/*.jar" />
                <include name="${lib}/bundle/*.jar" />
                <include name="${jmf.home}/*.jar" />
                <include name="${bundles.dest}/*.jar" />
            </jarfileset>
            <javafilelist dir="${lib}"
                files="logging.properties, oscar.client.run.properties" />
         </jarbundler>
    </target>

    <!-- Create the DMG - This only works on MacOSX (need hdiutil) -->
    <target name="dmg" depends="macosx" description=".dmg for MACOSX">
        <property name="macosx.dmg.name" value="${macosx.app.name}-${macosx.app.ver}.dmg"/>

        <!-- This is executed only if the OS is MacOSX -->
        <exec executable="/usr/bin/hdiutil" os="Mac OS X">
            <arg value="create"/>
            <arg value="-srcfolder"/>
            <arg value="${macosx.app.dir}/${macosx.app.name}-${macosx.app.ver}.app"/>
            <arg value="-volname"/>
            <arg value="${macosx.app.name} ${macosx.app.ver}"/>
            <arg value="-ov"/>
            <arg value="${macosx.app.dir}/${macosx.dmg.name}"/>
        </exec>
    </target>

    <!-- END MACOSX Package -->

You can now create the .app (application package for MACOSX. This is seen as an unique application file, but is in fact a directory, you can check the structure inside) with "ant macosx". I successfully tested the creation on MacOSX and Linux. I did not test on windows.
The .app is built from the sc-bundles, so maybe I need to add another dependency for the target?

The DMG (which is a compressed image, reduces the size from 20Mo to 10Mo) can be created with "ant dmg". "ant dmg" only works on MacOSX, as the image utility (hdiutil) is only available on MACOSX (dmg is a proprietary format :frowning: ). If executed on another OS, the target is simply skipped.

If I execute the .app on my MacOSX, the sip-communicator directory will be created inside the .app (actually all files created by SIP Communicator will be created inside the .app). I have some errors on the java console, I am not sure if it comes from my mistake:

java.lang.NoClassDefFoundError: javax/sound/sampled/Line$Info
[...]
java.lang.NoClassDefFoundError:com/sun/media/protocol/v4l/V4LDeviceQuery
[...]
123 SEVERE: impl.contactlist.MetaContactListServiceImpl.start() Failed loading the stored contact list.
java.lang.NullPointerException: Specified service reference cannot be null.

(for the second one, I guess this is because MACOSX does not implement V4L). If you need the complete log, I can provide it. Otherwise, the application starts and we can register the login/password as usual.

At the moment, only the .app is included in the dmg, but we can put also README, License files etc. Please let me know what is needed.
Both the .app and .dmg will are created in the macosx/ directory. Maybe we can delete the .app once the dmg is created?

For the TODOs: the help can be included as an html file that will be displayed through the special help system in MacOSX. Once you have a documentation, I can include it in the macosx package. Once the GUI is enough advanded, I will work on it to adapt it to the macos look and feel.

If you have any questions, please let me know.

Regards,
Romain

Romain KUNTZ wrote:

JavaApplicationStub (22.6 KB)

sipcom.icns (42.3 KB)

···

Hello Emil,

Thanks for those clarifications. I will then start by generating the dmg from the build.xml file and then concentrate on the GUI. I hope to get back to you soon with some news.

Cheers,
romain

Emil Ivov wrote:

Hello Romain,

We're going to use izPack for installer packages for Windows and also
Linux until we have volunteers for supporting per distro custom packages.
I entered the issues because we were discussing usage of izPack with
Damian and he agreed to do some tests with it.

In other words izPack is to remain as the default installer for Windows
and a generic replacement for operating systems that we don't have
anything else for. There were no plans in using it as _the_ exclusive
installer solution for SIP Communicator.

I of course remember that you proposed donating dmg packages and agree
that this would be the ideal option for Mac OS X.

Customizing the GUI so that it fits the Mac OS X look and feel is also a
very good idea. It might be easier for you to start with the DMG package
though as well as writing a few lines for generating it from the
build.xml file. This way you would get to know the project structure
before diving into it and besides there's not much to customize in the
GUI right now since it's in quite an early stage in the moment.

Anyways, It's up to you to pick whichever you like better.

Cheers
Emil

Romain KUNTZ wrote:

Hi Emil,

I have recently seen in sc-issues that a task is assigned to create a
native izpack launcher for Sip communicator (issues 105/106/107). There are no mentions about a MACOSX izpack launcher.

What is your opinion: do you prefer to have an izpack launcher for OSX or to provide an OSX package? I think the former would be easier to maintain, whereas the later is the most common way to install softwares for OSX users.

In any case, the package is not the only feature that could be provided to MAC users. Some small improvements can be done in the GUI
to fit to the MAC OS look and feel: menu bar, help box in the menu bar, some tabs or growbox that may overlap with others boxes etc. I can first focus on that, and we can then decide about the package stuff.

Regards,

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Romain KUNTZ
kuntz@sfc.wide.ad.jp


#5

Hello Romain,

Long mail, but I have some good news! We can now generate a dmg for SIP Communicator from the build.xml file.

Now this is some great news! I am really glad that we now have a MAC
installer! Congratulations for this great contribution :).

Here is what is needed:
- Install JarBundler for ANT:
http://informagen.com/JarBundler/
This is a small jar to add in the ant lib directory.

We can do this one of two ways:

1) We could include the jarbundler jar inside the sip-communicator itself. This would allow users to generate a package without any further installation or configuration. JarBundler's jar seems to be quite light (16K) so I don't think this would burden the project (which, when I last checked was over 30 MB). It would also avoid compatibility problems for people trying to build the mac installer with a different version of jarbundler. The problem here is that we'd need to do it the tricky way in order to include the jar bundler into ant's classpath. I guess we'll have to use the same solution as the one we have for the generation of the html test reports that need xalan.jar, or in other words, we'd have to re-instantiate ant from inside the "macosx" target and include the jar-bundler.jar in the classpath of the new ant instance. (see the test target and the way it calls the html-reports target)

2) Bet on the fact that users generating packages are proficient enough to be at ease with installing an extra ant jar and leave them do the download and copy it inside the $ANT_HOME/lib dir. We'll still have to do the detection and bail with the apropriate error message if the jarbundler jar is not detected in the classpath.

WDYT?

- In sip-communicator-1-0-draft directory, add a macosx and macosx/utils directory. I am not sure where you plan to put the packages, maybe a "release" directory with some sub-directories for each Operating System?

I've imagined the release directory to be the destination of generated packages which makes it more or less a non-persistent directory, created by ant every time a release is being made. If this is what you mean then the following tree:

SC_ROOT/release
SC_ROOT/release/macosx
SC_ROOT/release/macosx/utils

could be generated by the init target of the project build.xml and would be removed by the clean target.

- Add the sipcom.icns icon and JavaApplicationStub file in the macosx/utils directory. You will find them enclosed.

They could be copied there when the "release" target is being executed. Yet, given the volatile nature of the release directory we'd have to persistently store them somewhere and keep them under version control. Are you or anyone else aware of existing conventions that could help us with this?

How about something like an "install" dir? Other ideas?

BTW, could you provide me a quadrate icon for SIPCommunicator with a transparent background? It will be nicer to display for the application icon.

I think they are available somewhere in the source tree in an inkscape format. I don't know where though :). Yana could you point their location please?

- Add in build.xml:
[...]

I am currently in the middle of something but as soon as I am done I am going to try it out and add it to the build.xml (probably around Monday or Tuesday)

You can now create the .app (application package for MACOSX. This is seen as an unique application file, but is in fact a directory, you can check the structure inside) with "ant macosx". I successfully tested the creation on MacOSX and Linux. I did not test on windows.
The .app is built from the sc-bundles, so maybe I need to add another dependency for the target?

Yes. Replacing the "compile" dependency with "make" should be enough.

The DMG (which is a compressed image, reduces the size from 20Mo to 10Mo) can be created with "ant dmg". "ant dmg" only works on MacOSX, as the image utility (hdiutil) is only available on MACOSX (dmg is a proprietary format :frowning: ). If executed on another OS, the target is simply skipped.

OK ...Incidentally, this would mean that we'd have to find a MacOS X server to execute the nightly release builds then. This is not really urgent but do you think it would be possible for you to do this one day (provided you have such a machine of course)?

If not, anyone else?

If I execute the .app on my MacOSX, the sip-communicator directory will be created inside the .app (actually all files created by SIP Communicator will be created inside the .app). I have some errors on the java console, I am not sure if it comes from my mistake:

Both the errors you report are non-fatal and (as you point it yourself)
do not prevent the application from operating properly.

  > java.lang.NoClassDefFoundError: javax/sound/sampled/Line$Info

[...]
java.lang.NoClassDefFoundError:com/sun/media/protocol/v4l/V4LDeviceQuery
[...]

These two are coming from the media package which is quite unfininished
and absolutely unused by any other application module. The error may
have been caused by the packaging but we'll get down to it once the
media bundle is in a state where it's supposed to be doing something.

123 SEVERE: impl.contactlist.MetaContactListServiceImpl.start() Failed loading the stored contact list.
java.lang.NullPointerException: Specified service reference cannot be null.

That's what I am currently working on. The failure is normal and has
nothing to do with packaging.

At the moment, only the .app is included in the dmg, but we can put also README, License files etc. Please let me know what is needed.
Both the .app and .dmg will are created in the macosx/ directory. Maybe we can delete the .app once the dmg is created?

I've never had a mac so I'm afraid I couldn't provide any consistent advice on the exact behaviour of the dmg.

For the TODOs: the help can be included as an html file that will be displayed through the special help system in MacOSX. Once you have a documentation, I can include it in the macosx package.

Fine.

Once the GUI is enough advanded, I will work on it to adapt it to the macos look and feel.

Cool cool cool :).

Thanks again for your contribution Romain!

Emil

···

Romain KUNTZ wrote:

Hello Emil,

Thanks for those clarifications. I will then start by generating the dmg from the build.xml file and then concentrate on the GUI. I hope to get back to you soon with some news.

Cheers,
romain

Emil Ivov wrote:

Hello Romain,

We're going to use izPack for installer packages for Windows and also
Linux until we have volunteers for supporting per distro custom packages.
I entered the issues because we were discussing usage of izPack with
Damian and he agreed to do some tests with it.

In other words izPack is to remain as the default installer for Windows
and a generic replacement for operating systems that we don't have
anything else for. There were no plans in using it as _the_ exclusive
installer solution for SIP Communicator.

I of course remember that you proposed donating dmg packages and agree
that this would be the ideal option for Mac OS X.

Customizing the GUI so that it fits the Mac OS X look and feel is also a
very good idea. It might be easier for you to start with the DMG package
though as well as writing a few lines for generating it from the
build.xml file. This way you would get to know the project structure
before diving into it and besides there's not much to customize in the
GUI right now since it's in quite an early stage in the moment.

Anyways, It's up to you to pick whichever you like better.

Cheers
Emil

Romain KUNTZ wrote:

Hi Emil,

I have recently seen in sc-issues that a task is assigned to create a
native izpack launcher for Sip communicator (issues 105/106/107). There are no mentions about a MACOSX izpack launcher.

What is your opinion: do you prefer to have an izpack launcher for OSX or to provide an OSX package? I think the former would be easier to maintain, whereas the later is the most common way to install softwares for OSX users.

In any case, the package is not the only feature that could be provided to MAC users. Some small improvements can be done in the GUI
to fit to the MAC OS look and feel: menu bar, help box in the menu bar, some tabs or growbox that may overlap with others boxes etc. I can first focus on that, and we can then decide about the package stuff.

Regards,

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Hello Romain,

It's great what you do:)

BTW, could you provide me a quadrate icon for SIPCommunicator with a transparent background? It will be nicer to display for the application icon.

I think they are available somewhere in the source tree in an inkscape format. I don't know where though :). Yana could you point their location please?

You'll find all logo icons here:

src/net/java/sip/communicator/impl/gui/resources/common/logo

You should first make an update, because I have made some changes and I have added the logo in inkscape format.

The icon I use as an application icon is this one: sc_logo16x16.png. I have had problems in java displaying icons with transparent background in the title bar, so this one is with blue background. But you could use the inkscape file to make your own version.

Regards,
Yana

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Hi Emil,

Emil Ivov wrote:

Here is what is needed:
- Install JarBundler for ANT:
http://informagen.com/JarBundler/
This is a small jar to add in the ant lib directory.

We can do this one of two ways:

1) We could include the jarbundler jar inside the sip-communicator itself. This would allow users to generate a package without any further installation or configuration. JarBundler's jar seems to be quite light (16K) so I don't think this would burden the project (which, when I last checked was over 30 MB). It would also avoid compatibility problems for people trying to build the mac installer with a different version of jarbundler. The problem here is that we'd need to do it the tricky way in order to include the jar bundler into ant's classpath. I guess we'll have to use the same solution as the one we have for the generation of the html test reports that need xalan.jar, or in other words, we'd have to re-instantiate ant from inside the "macosx" target and include the jar-bundler.jar in the classpath of the new ant instance. (see the test target and the way it calls the html-reports target)

2) Bet on the fact that users generating packages are proficient enough to be at ease with installing an extra ant jar and leave them do the download and copy it inside the $ANT_HOME/lib dir. We'll still have to do the detection and bail with the apropriate error message if the jarbundler jar is not detected in the classpath.

WDYT?

I think 2) would be better. As we will provide nightly builds, only developers would need to build their own package, and thus should be able to deal with a new lib for ant. But if we notice some problems on the mailing list related to this lib, then we can try 1).

- In sip-communicator-1-0-draft directory, add a macosx and macosx/utils directory. I am not sure where you plan to put the packages, maybe a "release" directory with some sub-directories for each Operating System?

I've imagined the release directory to be the destination of generated packages which makes it more or less a non-persistent directory, created by ant every time a release is being made. If this is what you mean then the following tree:

SC_ROOT/release
SC_ROOT/release/macosx
SC_ROOT/release/macosx/utils

could be generated by the init target of the project build.xml and would be removed by the clean target.

This is what I meant. I agree with your proposition.

- Add the sipcom.icns icon and JavaApplicationStub file in the macosx/utils directory. You will find them enclosed.

They could be copied there when the "release" target is being executed. Yet, given the volatile nature of the release directory we'd have to persistently store them somewhere and keep them under version control. Are you or anyone else aware of existing conventions that could help us with this?

How about something like an "install" dir? Other ideas?

I am not aware of any existing convention, but we would need a directory where to put all the files useful to build each OS' packages.

Maybe the SC_ROOT/release dir could be persistent, thus having something persistent like:

SC_ROOT/release
SC_ROOT/release/data

and
SC_ROOT/release/macosx
SC_ROOT/release/linux
etc.

non-persistent?

You can now create the .app (application package for MACOSX. This is seen as an unique application file, but is in fact a directory, you can check the structure inside) with "ant macosx". I successfully tested the creation on MacOSX and Linux. I did not test on windows.
The .app is built from the sc-bundles, so maybe I need to add another dependency for the target?

Yes. Replacing the "compile" dependency with "make" should be enough.

ok

The DMG (which is a compressed image, reduces the size from 20Mo to 10Mo) can be created with "ant dmg". "ant dmg" only works on MacOSX, as the image utility (hdiutil) is only available on MACOSX (dmg is a proprietary format :frowning: ). If executed on another OS, the target is simply skipped.

OK ...Incidentally, this would mean that we'd have to find a MacOS X server to execute the nightly release builds then. This is not really urgent but do you think it would be possible for you to do this one day (provided you have such a machine of course)?

I have an access to such a machine. I can use it to buid the nightly OSX package, and upload it wherever would be convenient for you.

Both the errors you report are non-fatal and (as you point it yourself)
do not prevent the application from operating properly.

> java.lang.NoClassDefFoundError: javax/sound/sampled/Line$Info

[...]
java.lang.NoClassDefFoundError:com/sun/media/protocol/v4l/V4LDeviceQuery
[...]

These two are coming from the media package which is quite unfininished
and absolutely unused by any other application module. The error may
have been caused by the packaging but we'll get down to it once the
media bundle is in a state where it's supposed to be doing something.

Ok

123 SEVERE: impl.contactlist.MetaContactListServiceImpl.start() Failed loading the stored contact list.
java.lang.NullPointerException: Specified service reference cannot be null.

That's what I am currently working on. The failure is normal and has
nothing to do with packaging.

Ok, so the package seems to be safe.

At the moment, only the .app is included in the dmg, but we can put also README, License files etc. Please let me know what is needed.
Both the .app and .dmg will are created in the macosx/ directory. Maybe we can delete the .app once the dmg is created?

I've never had a mac so I'm afraid I couldn't provide any consistent advice on the exact behaviour of the dmg.

This is just a detail, but I guess you plan to have a README, AUTHORS, LICENSE etc. files for the packages you will release for each OS? We'll just have to adjust the dmg target to include those files in the dmg.

Regards,

···

--
Romain KUNTZ
kuntz@sfc.wide.ad.jp

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

Hello Yana,

Yana Stamcheva wrote:

The icon I use as an application icon is this one: sc_logo16x16.png. I have had problems in java displaying icons with transparent background in the title bar, so this one is with blue background. But you could use the inkscape file to make your own version.

Would you accept the enclosed icon and put it in the CVS tree? It would be used as an icon for the MacOSX package. This is a 128x128 pixels transparent icon, which is displayed correctly on OSX.

I also encosed the svg file if needed.

Regards,

sc_logo_128x128.icns (29.6 KB)

···

--
Romain KUNTZ
kuntz@sfc.wide.ad.jp


#9

Hello Romain,

I've just added your contrib to the build.xml and committed (and also acked ur effort on the sc web site).

I've created a release dir where the package is to be generated (/release/macosx) and a resources dir where you could store files necessary for the generation of the package (/resources/install/macosx)

Thanks for you effort and let me know if you encounter any further problems.

Cheers
Emil

Romain KUNTZ wrote:

···

Hi Emil,

Emil Ivov wrote:

Here is what is needed:
- Install JarBundler for ANT:
http://informagen.com/JarBundler/
This is a small jar to add in the ant lib directory.

We can do this one of two ways:

1) We could include the jarbundler jar inside the sip-communicator itself. This would allow users to generate a package without any further installation or configuration. JarBundler's jar seems to be quite light (16K) so I don't think this would burden the project (which, when I last checked was over 30 MB). It would also avoid compatibility problems for people trying to build the mac installer with a different version of jarbundler. The problem here is that we'd need to do it the tricky way in order to include the jar bundler into ant's classpath. I guess we'll have to use the same solution as the one we have for the generation of the html test reports that need xalan.jar, or in other words, we'd have to re-instantiate ant from inside the "macosx" target and include the jar-bundler.jar in the classpath of the new ant instance. (see the test target and the way it calls the html-reports target)

2) Bet on the fact that users generating packages are proficient enough to be at ease with installing an extra ant jar and leave them do the download and copy it inside the $ANT_HOME/lib dir. We'll still have to do the detection and bail with the apropriate error message if the jarbundler jar is not detected in the classpath.

WDYT?

I think 2) would be better. As we will provide nightly builds, only developers would need to build their own package, and thus should be able to deal with a new lib for ant. But if we notice some problems on the mailing list related to this lib, then we can try 1).

- In sip-communicator-1-0-draft directory, add a macosx and macosx/utils directory. I am not sure where you plan to put the packages, maybe a "release" directory with some sub-directories for each Operating System?

I've imagined the release directory to be the destination of generated packages which makes it more or less a non-persistent directory, created by ant every time a release is being made. If this is what you mean then the following tree:

SC_ROOT/release
SC_ROOT/release/macosx
SC_ROOT/release/macosx/utils

could be generated by the init target of the project build.xml and would be removed by the clean target.

This is what I meant. I agree with your proposition.

- Add the sipcom.icns icon and JavaApplicationStub file in the macosx/utils directory. You will find them enclosed.

They could be copied there when the "release" target is being executed. Yet, given the volatile nature of the release directory we'd have to persistently store them somewhere and keep them under version control. Are you or anyone else aware of existing conventions that could help us with this?

How about something like an "install" dir? Other ideas?

I am not aware of any existing convention, but we would need a directory where to put all the files useful to build each OS' packages.

Maybe the SC_ROOT/release dir could be persistent, thus having something persistent like:

SC_ROOT/release
SC_ROOT/release/data

and
SC_ROOT/release/macosx
SC_ROOT/release/linux
etc.

non-persistent?

You can now create the .app (application package for MACOSX. This is seen as an unique application file, but is in fact a directory, you can check the structure inside) with "ant macosx". I successfully tested the creation on MacOSX and Linux. I did not test on windows.
The .app is built from the sc-bundles, so maybe I need to add another dependency for the target?

Yes. Replacing the "compile" dependency with "make" should be enough.

ok

The DMG (which is a compressed image, reduces the size from 20Mo to 10Mo) can be created with "ant dmg". "ant dmg" only works on MacOSX, as the image utility (hdiutil) is only available on MACOSX (dmg is a proprietary format :frowning: ). If executed on another OS, the target is simply skipped.

OK ...Incidentally, this would mean that we'd have to find a MacOS X server to execute the nightly release builds then. This is not really urgent but do you think it would be possible for you to do this one day (provided you have such a machine of course)?

I have an access to such a machine. I can use it to buid the nightly OSX package, and upload it wherever would be convenient for you.

Both the errors you report are non-fatal and (as you point it yourself)
do not prevent the application from operating properly.

> java.lang.NoClassDefFoundError: javax/sound/sampled/Line$Info

[...]
java.lang.NoClassDefFoundError:com/sun/media/protocol/v4l/V4LDeviceQuery
[...]

These two are coming from the media package which is quite unfininished
and absolutely unused by any other application module. The error may
have been caused by the packaging but we'll get down to it once the
media bundle is in a state where it's supposed to be doing something.

Ok

123 SEVERE: impl.contactlist.MetaContactListServiceImpl.start() Failed loading the stored contact list.
java.lang.NullPointerException: Specified service reference cannot be null.

That's what I am currently working on. The failure is normal and has
nothing to do with packaging.

Ok, so the package seems to be safe.

At the moment, only the .app is included in the dmg, but we can put also README, License files etc. Please let me know what is needed.
Both the .app and .dmg will are created in the macosx/ directory. Maybe we can delete the .app once the dmg is created?

I've never had a mac so I'm afraid I couldn't provide any consistent advice on the exact behaviour of the dmg.

This is just a detail, but I guess you plan to have a README, AUTHORS, LICENSE etc. files for the packages you will release for each OS? We'll just have to adjust the dmg target to include those files in the dmg.

Regards,


#10

Hi Romain,

Would you accept the enclosed icon and put it in the CVS tree?

You can find your icon here: src/net/java/sip/communicator/impl/gui/resources/common/logo/sc_logo_128x128.icns

Regards,
Yana

···

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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#11

Hello Emil,

I have setup an automatic nightly build for MacOSX DMG. DMGs are available here at the moment:
http://www.rkuntz.org/sipcosx/

If you have an official repository where you prefer to put the files, let me know. Otherwise you can advertise the link if you want.

The build.xml file needs a few changes to accomodate the new directories and files, I'll send another mail later with the changes.

Romain

Emil Ivov wrote:

···

Hello Romain,

I've just added your contrib to the build.xml and committed (and also acked ur effort on the sc web site).

I've created a release dir where the package is to be generated (/release/macosx) and a resources dir where you could store files necessary for the generation of the package (/resources/install/macosx)

Thanks for you effort and let me know if you encounter any further problems.

Cheers
Emil

Romain KUNTZ wrote:

Hi Emil,

Emil Ivov wrote:

Here is what is needed:
- Install JarBundler for ANT:
http://informagen.com/JarBundler/
This is a small jar to add in the ant lib directory.

We can do this one of two ways:

1) We could include the jarbundler jar inside the sip-communicator itself. This would allow users to generate a package without any further installation or configuration. JarBundler's jar seems to be quite light (16K) so I don't think this would burden the project (which, when I last checked was over 30 MB). It would also avoid compatibility problems for people trying to build the mac installer with a different version of jarbundler. The problem here is that we'd need to do it the tricky way in order to include the jar bundler into ant's classpath. I guess we'll have to use the same solution as the one we have for the generation of the html test reports that need xalan.jar, or in other words, we'd have to re-instantiate ant from inside the "macosx" target and include the jar-bundler.jar in the classpath of the new ant instance. (see the test target and the way it calls the html-reports target)

2) Bet on the fact that users generating packages are proficient enough to be at ease with installing an extra ant jar and leave them do the download and copy it inside the $ANT_HOME/lib dir. We'll still have to do the detection and bail with the apropriate error message if the jarbundler jar is not detected in the classpath.

WDYT?

I think 2) would be better. As we will provide nightly builds, only developers would need to build their own package, and thus should be able to deal with a new lib for ant. But if we notice some problems on the mailing list related to this lib, then we can try 1).

- In sip-communicator-1-0-draft directory, add a macosx and macosx/utils directory. I am not sure where you plan to put the packages, maybe a "release" directory with some sub-directories for each Operating System?

I've imagined the release directory to be the destination of generated packages which makes it more or less a non-persistent directory, created by ant every time a release is being made. If this is what you mean then the following tree:

SC_ROOT/release
SC_ROOT/release/macosx
SC_ROOT/release/macosx/utils

could be generated by the init target of the project build.xml and would be removed by the clean target.

This is what I meant. I agree with your proposition.

- Add the sipcom.icns icon and JavaApplicationStub file in the macosx/utils directory. You will find them enclosed.

They could be copied there when the "release" target is being executed. Yet, given the volatile nature of the release directory we'd have to persistently store them somewhere and keep them under version control. Are you or anyone else aware of existing conventions that could help us with this?

How about something like an "install" dir? Other ideas?

I am not aware of any existing convention, but we would need a directory where to put all the files useful to build each OS' packages.

Maybe the SC_ROOT/release dir could be persistent, thus having something persistent like:

SC_ROOT/release
SC_ROOT/release/data

and
SC_ROOT/release/macosx
SC_ROOT/release/linux
etc.

non-persistent?

You can now create the .app (application package for MACOSX. This is seen as an unique application file, but is in fact a directory, you can check the structure inside) with "ant macosx". I successfully tested the creation on MacOSX and Linux. I did not test on windows.
The .app is built from the sc-bundles, so maybe I need to add another dependency for the target?

Yes. Replacing the "compile" dependency with "make" should be enough.

ok

The DMG (which is a compressed image, reduces the size from 20Mo to 10Mo) can be created with "ant dmg". "ant dmg" only works on MacOSX, as the image utility (hdiutil) is only available on MACOSX (dmg is a proprietary format :frowning: ). If executed on another OS, the target is simply skipped.

OK ...Incidentally, this would mean that we'd have to find a MacOS X server to execute the nightly release builds then. This is not really urgent but do you think it would be possible for you to do this one day (provided you have such a machine of course)?

I have an access to such a machine. I can use it to buid the nightly OSX package, and upload it wherever would be convenient for you.

Both the errors you report are non-fatal and (as you point it yourself)
do not prevent the application from operating properly.

> java.lang.NoClassDefFoundError: javax/sound/sampled/Line$Info

[...]
java.lang.NoClassDefFoundError:com/sun/media/protocol/v4l/V4LDeviceQuery

[...]

These two are coming from the media package which is quite unfininished
and absolutely unused by any other application module. The error may
have been caused by the packaging but we'll get down to it once the
media bundle is in a state where it's supposed to be doing something.

Ok

123 SEVERE: impl.contactlist.MetaContactListServiceImpl.start() Failed loading the stored contact list.
java.lang.NullPointerException: Specified service reference cannot be null.

That's what I am currently working on. The failure is normal and has
nothing to do with packaging.

Ok, so the package seems to be safe.

At the moment, only the .app is included in the dmg, but we can put also README, License files etc. Please let me know what is needed.
Both the .app and .dmg will are created in the macosx/ directory. Maybe we can delete the .app once the dmg is created?

I've never had a mac so I'm afraid I couldn't provide any consistent advice on the exact behaviour of the dmg.

This is just a detail, but I guess you plan to have a README, AUTHORS, LICENSE etc. files for the packages you will release for each OS? We'll just have to adjust the dmg target to include those files in the dmg.

Regards,

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Romain KUNTZ
kuntz@sfc.wide.ad.jp

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#12

Hi Emil,

Find enclosed some changes to apply to the build.xml file regarding MacOSX packages:
- release/macosx is created when doing "ant macosx",
- icon path has changed,
- Stub file path has change.

Could you also create the "resources/install/macosx" directory on CVS and put the enclosed JavaApplicationStub file?

Thanks,

Romain

Emil Ivov wrote:

JavaApplicationStub (22.6 KB)

build.xml.patch (1.51 KB)

···

Hello Romain,

I've just added your contrib to the build.xml and committed (and also acked ur effort on the sc web site).

I've created a release dir where the package is to be generated (/release/macosx) and a resources dir where you could store files necessary for the generation of the package (/resources/install/macosx)

Thanks for you effort and let me know if you encounter any further problems.

Cheers
Emil

Romain KUNTZ wrote:

Hi Emil,

Emil Ivov wrote:

Here is what is needed:
- Install JarBundler for ANT:
http://informagen.com/JarBundler/
This is a small jar to add in the ant lib directory.

We can do this one of two ways:

1) We could include the jarbundler jar inside the sip-communicator itself. This would allow users to generate a package without any further installation or configuration. JarBundler's jar seems to be quite light (16K) so I don't think this would burden the project (which, when I last checked was over 30 MB). It would also avoid compatibility problems for people trying to build the mac installer with a different version of jarbundler. The problem here is that we'd need to do it the tricky way in order to include the jar bundler into ant's classpath. I guess we'll have to use the same solution as the one we have for the generation of the html test reports that need xalan.jar, or in other words, we'd have to re-instantiate ant from inside the "macosx" target and include the jar-bundler.jar in the classpath of the new ant instance. (see the test target and the way it calls the html-reports target)

2) Bet on the fact that users generating packages are proficient enough to be at ease with installing an extra ant jar and leave them do the download and copy it inside the $ANT_HOME/lib dir. We'll still have to do the detection and bail with the apropriate error message if the jarbundler jar is not detected in the classpath.

WDYT?

I think 2) would be better. As we will provide nightly builds, only developers would need to build their own package, and thus should be able to deal with a new lib for ant. But if we notice some problems on the mailing list related to this lib, then we can try 1).

- In sip-communicator-1-0-draft directory, add a macosx and macosx/utils directory. I am not sure where you plan to put the packages, maybe a "release" directory with some sub-directories for each Operating System?

I've imagined the release directory to be the destination of generated packages which makes it more or less a non-persistent directory, created by ant every time a release is being made. If this is what you mean then the following tree:

SC_ROOT/release
SC_ROOT/release/macosx
SC_ROOT/release/macosx/utils

could be generated by the init target of the project build.xml and would be removed by the clean target.

This is what I meant. I agree with your proposition.

- Add the sipcom.icns icon and JavaApplicationStub file in the macosx/utils directory. You will find them enclosed.

They could be copied there when the "release" target is being executed. Yet, given the volatile nature of the release directory we'd have to persistently store them somewhere and keep them under version control. Are you or anyone else aware of existing conventions that could help us with this?

How about something like an "install" dir? Other ideas?

I am not aware of any existing convention, but we would need a directory where to put all the files useful to build each OS' packages.

Maybe the SC_ROOT/release dir could be persistent, thus having something persistent like:

SC_ROOT/release
SC_ROOT/release/data

and
SC_ROOT/release/macosx
SC_ROOT/release/linux
etc.

non-persistent?

You can now create the .app (application package for MACOSX. This is seen as an unique application file, but is in fact a directory, you can check the structure inside) with "ant macosx". I successfully tested the creation on MacOSX and Linux. I did not test on windows.
The .app is built from the sc-bundles, so maybe I need to add another dependency for the target?

Yes. Replacing the "compile" dependency with "make" should be enough.

ok

The DMG (which is a compressed image, reduces the size from 20Mo to 10Mo) can be created with "ant dmg". "ant dmg" only works on MacOSX, as the image utility (hdiutil) is only available on MACOSX (dmg is a proprietary format :frowning: ). If executed on another OS, the target is simply skipped.

OK ...Incidentally, this would mean that we'd have to find a MacOS X server to execute the nightly release builds then. This is not really urgent but do you think it would be possible for you to do this one day (provided you have such a machine of course)?

I have an access to such a machine. I can use it to buid the nightly OSX package, and upload it wherever would be convenient for you.

Both the errors you report are non-fatal and (as you point it yourself)
do not prevent the application from operating properly.

> java.lang.NoClassDefFoundError: javax/sound/sampled/Line$Info

[...]
java.lang.NoClassDefFoundError:com/sun/media/protocol/v4l/V4LDeviceQuery

[...]

These two are coming from the media package which is quite unfininished
and absolutely unused by any other application module. The error may
have been caused by the packaging but we'll get down to it once the
media bundle is in a state where it's supposed to be doing something.

Ok

123 SEVERE: impl.contactlist.MetaContactListServiceImpl.start() Failed loading the stored contact list.
java.lang.NullPointerException: Specified service reference cannot be null.

That's what I am currently working on. The failure is normal and has
nothing to do with packaging.

Ok, so the package seems to be safe.

At the moment, only the .app is included in the dmg, but we can put also README, License files etc. Please let me know what is needed.
Both the .app and .dmg will are created in the macosx/ directory. Maybe we can delete the .app once the dmg is created?

I've never had a mac so I'm afraid I couldn't provide any consistent advice on the exact behaviour of the dmg.

This is just a detail, but I guess you plan to have a README, AUTHORS, LICENSE etc. files for the packages you will release for each OS? We'll just have to adjust the dmg target to include those files in the dmg.

Regards,

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Romain KUNTZ
kuntz@sfc.wide.ad.jp