testing the debian package

Hello again Martin,

I've just done my first try of SIP Communicator's debian
package and its 
generator.

Excellent work! I didn't experience any serious problem
building the 
package and was able to rapidly install and run SC! You've
really done a 
great job!

While testing the package I've added some
modifications/improvements 
that I found appropriate. Please let me know whether you are
ok with all 
of them.

The following might also be of interest to other package
maintainers.

First I've set .sip-communicator/log to be the official
logging 
directory for installed versions of sip-communicator (as
opposed to 
those run directly from the cvs sandbox). I therefore needed
to add a

     mkdir -p ~/.sip-communicator/log

line in sip-communicator.sh cause apparently the
java.util.logging 
logger does not create automatically.

I also had to add sc-bundles/util.jar to the classpath
(again in 
sip-communicator.sh) as it contains the ScLogFormatter which
is used for 
all sip-communicator logging. Without this all file logs get
printed in 
xml and console logs do not have the standard SIP
Communicator format.

I've created a new instance of the logging.properties file
and have 
added it to resources/install for use by all installers
(that's one of 
the points that other package maintainers may be interested
in). This 
instance of logging.properties has a reduced log level for
console logs 
and stores log files inside the ~/.sip-communicator/log
directory.

Again in sip-communicator.sh i've added an
"export" line for 
LD_LIBRARY_PATH in order to make sure that JMF .so's are
usable by SC.

I've removed the better part of the jars in
/usr/share/sc/lib as they 
are already included in the bundles that are using them.
This also goes 
for liblog4j and libbcprov so I've removed the dependencies
that the 
package had on them. I've therefore modified the rules
script so that it 
would only copy those libs that are necessary.

This situation is kind of unclear however. I think it would
be better to 
simply designate directories that contain shared jars and
others that 
only contain bundle specific jars so that we could avoid
having all 
package maintainers enumerate them one by one.

Anyways, a thing worth mentioning here is the fact that
removing all 
these jars has brought the package size down to  5.5M

I also had to add jmf.jar to the classpath
(sip-communicator.sh) and 
change default values for some log4j properties used in one
of the packages.

Well, I think that's all. Let me know if you find any
problems with my 
changes (I apologize if you do!).

Once you confirm they are ok, I'll add them to the
cruisecontrol build 
so that they get generated on every CC build and uploaded to
a location 
of you choice (a SC debian repo? ;) )

Thanks again for the great work Martin.

Emil

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Emil Ivov wrote:
> Again in sip-communicator.sh i've added an
"export" line for 
> LD_LIBRARY_PATH in order to make sure that JMF .so's
are usable by SC.
Is this needed in the linux and windows installations. There
I just 
change the PATH, which reflects java.library.path I think.
>
>
> I also had to add jmf.jar to the classpath
(sip-communicator.sh) and 
> change default values for some log4j properties used in
one of the 
> packages.
Why is jmf.jar included?  I think its not necessary. 

damencho

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hello Damencho,

Damian Minkov wrote:
> Emil Ivov wrote:
>> Again in sip-communicator.sh i've added an
"export" line for 
>> LD_LIBRARY_PATH in order to make sure that JMF
.so's are usable by SC.
> Is this needed in the linux and windows installations.
There I just 
> change the PATH, which reflects java.library.path I
think.

Yes that's right. Windows uses PATH for loading shared libs
(dll-s) and 
hence that's the directory that java uses for initializing 
java.library.path.

>> I also had to add jmf.jar to the classpath
(sip-communicator.sh) and 
>> change default values for some log4j properties
used in one of the 
>> packages.
> Why is jmf.jar included?  I think its not necessary. 


You are right! I've removed it.

I also noticed that I've missed out the BrowserLauncher2.jar
lib. It is 
not included in a bundle because it is used by more than one
so it needs 
to be inside lib and in the system classpath.

I've modified rules and sip-communicator.sh accordingly.

Cheers
Emil

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hi Emil,

sorry for my poor reactivity on the deb package... i was
taken by 
something else.

I agree with all your modifications, however i put some
comments inline.

Emil Ivov wrote:
> First I've set .sip-communicator/log to be the official
logging 
> directory for installed versions of sip-communicator
(as opposed to 
> those run directly from the cvs sandbox). I therefore
needed to add a
> 
>     mkdir -p ~/.sip-communicator/log
> 
> line in sip-communicator.sh cause apparently the
java.util.logging 
> logger does not create automatically.

I agree. Concerning the logs, are they incremental or they
are 
overwritten for each session of the SC? I strongly prefer
the latter 
choice.

> I've created a new instance of the logging.properties
file and have 
> added it to resources/install for use by all installers
(that's one of 
> the points that other package maintainers may be
interested in). This 
> instance of logging.properties has a reduced log level
for console logs 
> and stores log files inside the ~/.sip-communicator/log
directory.

Great. BTW, I was planning to add the control of the log
level console 
output through the script that launch the SIP Communicator.

> This situation is kind of unclear however. I think it
would be better to 
> simply designate directories that contain shared jars
and others that 
> only contain bundle specific jars so that we could
avoid having all 
> package maintainers enumerate them one by one.

I agree.
Talking about bundles, what about using the
~/.sip-communicator/plugins 
for the deployment as you suggested in another mail?

> Anyways, a thing worth mentioning here is the fact that
removing all 
> these jars has brought the package size down to  5.5M

Hey, it is generally good to loose fat before the christmas
season.

> Once you confirm they are ok, I'll add them to the
cruisecontrol build 
> so that they get generated on every CC build and
uploaded to a location 
> of you choice (a SC debian repo? ;) )

I will prepare a debian repository on download.java.net
(just like where 
the Macosx nightly build is) and we can have a fresh
development package 
of the SC every day via apt-get.

Martin

> Emil
> 

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hi Martin,

Martin André wrote:
> Hi Emil,
> 
> sorry for my poor reactivity on the deb package... i
was taken by 
> something else.
> 
> I agree with all your modifications, however i put some
comments inline.
> 
> Emil Ivov wrote:
>> First I've set .sip-communicator/log to be the
official logging 
>> directory for installed versions of
sip-communicator (as opposed to 
>> those run directly from the cvs sandbox). I
therefore needed to add a
>>
>>     mkdir -p ~/.sip-communicator/log
>>
>> line in sip-communicator.sh cause apparently the
java.util.logging 
>> logger does not create automatically.
> 
> I agree. Concerning the logs, are they incremental or
they are 
> overwritten for each session of the SC? I strongly
prefer the latter 
> choice.

Every session starts a new log. You are right, incremental
logging would 
easily produce GBs of log files.

>> I've created a new instance of the
logging.properties file and have 
>> added it to resources/install for use by all
installers (that's one of 
>> the points that other package maintainers may be
interested in). This 
>> instance of logging.properties has a reduced log
level for console logs 
>> and stores log files inside the
~/.sip-communicator/log directory.
> 
> Great. BTW, I was planning to add the control of the
log level console 
> output through the script that launch the SIP
Communicator.

Sure. That could be interesting.

>> This situation is kind of unclear however. I think
it would be better to 
>> simply designate directories that contain shared
jars and others that 
>> only contain bundle specific jars so that we could
avoid having all 
>> package maintainers enumerate them one by one.
> 
> I agree.

OK Then I guess we could have something like this:

* sip-communicator/lib - bundle specific libs (i.e. included
in the 
bundle jars)
* sip-communicator/lib/share - bundles that need to remain
in the 
classpath on runtime
* sip-communicator/lib/native/osname - native shared libs.

If you agree, could you start an issue on this please?

> Talking about bundles, what about using the
~/.sip-communicator/plugins 
> for the deployment as you suggested in another mail?

Yes. I tried this one but there seems to be no direct way of
telling 
Felix that our profile directory is in a location relative
to the user 
home. At least I didn't find any. I can see a work around
but it needs 
to be tested, especially on non-unix OSs.

The code that handles this in Felix is located in 
org.apache.felix.framework.cache.BundleCache (grep for
user.home)

> // First, determine the location of the cache
directory; it
> // can either be specified or in the default location.
> String cacheDirStr = m_cfg.get(CACHE_DIR_PROP);
> if (cacheDirStr == null)
> {
>     // Since no cache directory was specified, put it
>     // ".felix" in the user's home by
default.
>     cacheDirStr =
System.getProperty("user.home");
>     cacheDirStr = cacheDirStr.endsWith(File.separator)
>         ? cacheDirStr : cacheDirStr + File.separator;
>     cacheDirStr = cacheDirStr + CACHE_DIR_NAME;
> }


As you see the only way to make Felix use the user.home is
to not 
specify a profile directory. We could however specify 
.sip-communicator/plugins as a profile name and that should
put bundles 
where we want them. I haven't tested this yet and don't know
whether the 
slash would properly work on windows. Perhaps we should
consult the 
Felix guys before trying this. Maybe they'd agree to add
support for 
"%h" or "~" in the profile dir string.

>> Anyways, a thing worth mentioning here is the fact
that removing all 
>> these jars has brought the package size down to 
5.5M
> 
> Hey, it is generally good to loose fat before the
christmas season.
> 
>> Once you confirm they are ok, I'll add them to the
cruisecontrol build 
>> so that they get generated on every CC build and
uploaded to a location 
>> of you choice (a SC debian repo? ;) )
> 
> I will prepare a debian repository on download.java.net
(just like where 
> the Macosx nightly build is) and we can have a fresh
development package 
> of the SC every day via apt-get.

Oh how great! I am looking very forward to this ;)

Incidentally, any idea on what it takes to have this in
debian's 
official repositories?

Emil

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hi again,

I just thought about something.

On 12/3/06, Emil Ivov <emchoemcho.com> wrote:
> > Talking about bundles, what about using the
~/.sip-communicator/plugins
> > for the deployment as you suggested in another
mail?
>
> Yes. I tried this one but there seems to be no direct
way of telling
> Felix that our profile directory is in a location
relative to the user
> home. At least I didn't find any. I can see a work
around but it needs
> to be tested, especially on non-unix OSs.
>
> The code that handles this in Felix is located in
> org.apache.felix.framework.cache.BundleCache (grep for
user.home)
>
> > // First, determine the location of the cache
directory; it
> > // can either be specified or in the default
location.
> > String cacheDirStr = m_cfg.get(CACHE_DIR_PROP);
> > if (cacheDirStr == null)
> > {
> >     // Since no cache directory was specified, put
it
> >     // ".felix" in the user's home by
default.
> >     cacheDirStr =
System.getProperty("user.home");
> >     cacheDirStr =
cacheDirStr.endsWith(File.separator)
> >         ? cacheDirStr : cacheDirStr +
File.separator;
> >     cacheDirStr = cacheDirStr + CACHE_DIR_NAME;
> > }
>
>
> As you see the only way to make Felix use the user.home
is to not
> specify a profile directory. We could however specify
> .sip-communicator/plugins as a profile name and that
should put bundles
> where we want them. I haven't tested this yet and don't
know whether the
> slash would properly work on windows. Perhaps we should
consult the
> Felix guys before trying this. Maybe they'd agree to
add support for
> "%h" or "~" in the profile dir
string.


Specifying .sip-communicator/plugins as a profile name isn't
good
enough because it would again put the repository inside
~/.felix. We
are currently chatting with Pavel and he suggested that we
should try
setting a profile_name of ../.sip-communicator/plugins. This
might
work. Pavel said he'll try and share the results on this
list.

Crossing my fingers.

Emil

P.S. We should really send a mail to the felix-dev list,
describing
the situation.

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hello Everyone,

Sorry for the late reply. Unfortunately, the idea of having
felix.cache.profile=../.sip-communicator/plugins didn't
work. Here's the output:

Welcome to Felix.
=================

Error creating bundle cache:
java.lang.IllegalArgumentException: The profile name cannot
contain the file separator character.
        at
org.apache.felix.framework.cache.BundleCache.initialize(Bund
leCache.java:305)
        at
org.apache.felix.framework.cache.BundleCache.<init>(Bu
ndleCache.java:99)
        at
org.apache.felix.framework.Felix.start(Felix.java:248)
        at org.apache.felix.main.Main.main(Main.java:208)

--Pavel Tankov

--- Emil Ivov <emchoemcho.com> wrote:

> Hi again,
> 
> I just thought about something.
> 
> On 12/3/06, Emil Ivov <emchoemcho.com> wrote:
> > > Talking about bundles, what about using the
~/.sip-communicator/plugins
> > > for the deployment as you suggested in
another mail?
> >
> > Yes. I tried this one but there seems to be no
direct way of telling
> > Felix that our profile directory is in a location
relative to the user
> > home. At least I didn't find any. I can see a work
around but it needs
> > to be tested, especially on non-unix OSs.
> >
> > The code that handles this in Felix is located in
> > org.apache.felix.framework.cache.BundleCache (grep
for user.home)
> >
> > > // First, determine the location of the cache
directory; it
> > > // can either be specified or in the default
location.
> > > String cacheDirStr =
m_cfg.get(CACHE_DIR_PROP);
> > > if (cacheDirStr == null)
> > > {
> > >     // Since no cache directory was
specified, put it
> > >     // ".felix" in the user's home
by default.
> > >     cacheDirStr =
System.getProperty("user.home");
> > >     cacheDirStr =
cacheDirStr.endsWith(File.separator)
> > >         ? cacheDirStr : cacheDirStr +
File.separator;
> > >     cacheDirStr = cacheDirStr +
CACHE_DIR_NAME;
> > > }
> >
> >
> > As you see the only way to make Felix use the
user.home is to not
> > specify a profile directory. We could however
specify
> > .sip-communicator/plugins as a profile name and
that should put bundles
> > where we want them. I haven't tested this yet and
don't know whether the
> > slash would properly work on windows. Perhaps we
should consult the
> > Felix guys before trying this. Maybe they'd agree
to add support for
> > "%h" or "~" in the profile dir
string.
> 
> 
> Specifying .sip-communicator/plugins as a profile name
isn't good
> enough because it would again put the repository inside
~/.felix. We
> are currently chatting with Pavel and he suggested that
we should try
> setting a profile_name of ../.sip-communicator/plugins.
This might
> work. Pavel said he'll try and share the results on
this list.
> 
> Crossing my fingers.
> 
> Emil
> 
> P.S. We should really send a mail to the felix-dev
list, describing
> the situation.
> 
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
> 
> 



 
____________________________________________________________
________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hi Emil,

Some questions for the MacOSX packages.

Emil Ivov wrote:
> First I've set .sip-communicator/log to be the official
logging 
> directory for installed versions of sip-communicator
(as opposed to 
> those run directly from the cvs sandbox). I therefore
needed to add a
> 
>     mkdir -p ~/.sip-communicator/log
> 
> line in sip-communicator.sh cause apparently the
java.util.logging 
> logger does not create automatically.

The MacOSX package has the same issue. Unfortunately, I did
not find a
way to create a specific directory when the package is
installed
(because installing a package is just a drag'n drop).

One solution could be to store the logs inside the macosx
application (a
mac application is actually a directory that you can
browse).

> I've created a new instance of the logging.properties
file and have 
> added it to resources/install for use by all installers
(that's one of 
> the points that other package maintainers may be
interested in). This 
> instance of logging.properties has a reduced log level
for console logs 
> and stores log files inside the ~/.sip-communicator/log
directory.

For the solution I proposed above, I would need a specific
logging.properties (but I guess we could store it in
resources/install/macosx)

> I've removed the better part of the jars in
/usr/share/sc/lib as they 
> are already included in the bundles that are using
them. This also goes 
> for liblog4j and libbcprov so I've removed the
dependencies that the 
> package had on them. I've therefore modified the rules
script so that it 
> would only copy those libs that are necessary.

Thanks for the hints. The patch sent in my previous mail
(about
sip-communicator.version) includes some modifications to the
build.xml
to reduce the macosx package size (the DMG is now around
8Mo)

Thanks,

-- 
Romain KUNTZ
kuntzsfc.wide.ad.jp

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hello Romain,

Romain KUNTZ wrote:
> Hi Emil,
> 
> Some questions for the MacOSX packages.
> 
> Emil Ivov wrote:
>> First I've set .sip-communicator/log to be the
official logging 
>> directory for installed versions of
sip-communicator (as opposed to 
>> those run directly from the cvs sandbox). I
therefore needed to add a
>>
>>     mkdir -p ~/.sip-communicator/log
>>
>> line in sip-communicator.sh cause apparently the
java.util.logging 
>> logger does not create automatically.
> 
> The MacOSX package has the same issue. Unfortunately, I
did not find a
> way to create a specific directory when the package is
installed
> (because installing a package is just a drag'n drop).

Well I am doing the mkdir -p on launch and not during the
installation. 
Would this work for mac?

> One solution could be to store the logs inside the
macosx application (a
> mac application is actually a directory that you can
browse).

Sure. If the default mac configuration allows non-root users
to write in 
there then this would be the simplest way to handle the
issue.

>> I've created a new instance of the
logging.properties file and have 
>> added it to resources/install for use by all
installers (that's one of 
>> the points that other package maintainers may be
interested in). This 
>> instance of logging.properties has a reduced log
level for console logs 
>> and stores log files inside the
~/.sip-communicator/log directory.
> 
> For the solution I proposed above, I would need a
specific
> logging.properties (but I guess we could store it in
> resources/install/macosx)

Sure.

>> I've removed the better part of the jars in
/usr/share/sc/lib as they 
>> are already included in the bundles that are using
them. This also goes 
>> for liblog4j and libbcprov so I've removed the
dependencies that the 
>> package had on them. I've therefore modified the
rules script so that it 
>> would only copy those libs that are necessary.
> 
> Thanks for the hints. The patch sent in my previous
mail (about
> sip-communicator.version) includes some modifications
to the build.xml
> to reduce the macosx package size (the DMG is now
around 8Mo)

Yes,  great! I've just applied it.

Cheers
Emil

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hi

I have un subscribed from this mailing list twice now
and keep getting these emails.

Please un subscribe me.

Thanks

> 
>
------------------------------------------------------------
---------
> 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