OK,
Everything is applied now!
Thank you for your work.
Emil
Romain KUNTZ wrote:
> 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:
>> 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.c
om/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 :( ). 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/V4
LDeviceQuery
>>>>>
>>>>> [...]
>>>> 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-helpsip-communicator.dev.java.net
>>
>
>
>
------------------------------------------------------------
------------
>
> ---
sip-communicator-1-0-draft.orig/build.xml 2006-07-28
22:49:05.000000000 +0900
> +++ sip-communicator-1-0-draft/build.xml 2006-07-31
16:48:57.000000000 +0900
> -24,6 +24,8
>
> <!-- Put here the release directory -->
> <property name="macosx.app.dir"
value="$/macosx"/>
> + <!-- Put here the resource directory -->
> + <property name="macosx.resrc.dir"
value="${inst.resrc}/macosx"/>
> <!-- Put here the Application name -->
> <property name="macosx.app.name"
value="SIP Communicator"/>
> <!-- Put here the Application version -->
> -249,8 +251,10
> <taskdef name="jarbundler"
>
classname="net.sourceforge.jarbundler.JarBundler"
;/>
>
> + <mkdir
dir="${macosx.app.dir}"/>
> +
> <property name="macosx.stubfile"
> -
value="${macosx.app.dir}/utils/JavaApplicationStub&qu
ot;/>
> +
value="${macosx.resrc.dir}/JavaApplicationStub"/
>
> <condition
property="macosx.stubfile"
>
value="/System/Library/Frameworks/JavaVM.framework/Res
ources/MacOS/JavaApplicationStub">
> <equals arg1="${os.name}"
> -269,7 +273,7
> shortname="SIP
Communicator"
> signature="sipc"
>
mainclass="org.ungoverned.oscar.Main"
> -
icon="${macosx.app.dir}/utils/sipcom.icns"
> +
icon="src/net/java/sip/communicator/impl/gui/resources
/common/logo/sc_logo_128x128.icns"
> jvmversion="1.4+"
>
version="${macosx.app.ver}"
> build="draft"
>
>
>
>
------------------------------------------------------------
------------
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
|