[sip-comm] Support running Sipcommunicator


#1

Hej Brian,

I have as a second option the ( www.mjsip.org ), however I would really like to run the SipCommunicator but I think that I have no problem with the source or build.xml file

For instance IntelliJ IDEA has a very nice of debugging and running and the ant file has no problems or anything like that.

I do believe that there must be something else. Have you done any change besides the files… any file that you have look at and uncomment or comment anything else because I have just tried for a whole day but this is not the set up of a difficult task, it should be very simple :slight_smile:

Looking forward to hear from you!

···

Alan Raúl Ramos

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


#2

I downloaded the source tree for several different nights builds last week and found there seems to be a dependency problem in the makefiles. The only way I could get it to run was to manually do the bundles. I think it should happen automatically, but it is not being done by default..

Cheers
Dave

Brian Long wrote:

···

Alan,

unfortunately I deleted the original configuration of sip-comm that I was using after moving to mjsip, but I have just downloaded the sip-communicator-1.0-src.zip again, unzipped it, moved it into my eclipse workspace, ran the ant task "bundles", then the ant task "run" and it launches successfully. If you could do something similar, I'm sure you can get sip-comm to work.

The mistake I made the first time was going in and editing code and configuration files before checking to see whether the application ran with it's default settings. Hence the problems I had with Oscar etc.

/Brian.

On 4/19/06, *Alan Ramos - alra03* <alra03@student.bth.se > <mailto:alra03@student.bth.se>> wrote:

    Hej Brian,
         I have as a second option the ( www.mjsip.org
    <http://www.mjsip.org/>), however I would really like to run the
    SipCommunicator but I think that I have no problem with the source
    or build.xml file
    For instance IntelliJ IDEA has a very nice of debugging and
    running and the ant file has no problems or anything like that.
         I do believe that there must be something else. Have you done any
    change besides the files... any file that you have look at and
    uncomment or comment anything else because I have just tried for a
    whole day but this is not the set up of a difficult task, it
    should be very simple :slight_smile:
         Looking forward to hear from you!
         ----
    Alan Ra�l Ramos
    ---------------------------------------------------------------------
    To unsubscribe, e-mail:
    users-unsubscribe@sip-communicator.dev.java.net
    <mailto:users-unsubscribe@sip-communicator.dev.java.net> For
    additional commands, e-mail:
    users-help@sip-communicator.dev.java.net
    <mailto:users-help@sip-communicator.dev.java.net>

--
David Trollope BSc(Hons) MIAP
Lucent Technologies
Tel/Fax: (630)713-9110
Email: trollope@lucent.com
         
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#3

Alan,

unfortunately I deleted the original configuration of sip-comm that I was
using after moving to mjsip, but I have just downloaded the
sip-communicator-1.0-src.zip again, unzipped it, moved it into my eclipse
workspace, ran the ant task "bundles", then the ant task "run" and it
launches successfully. If you could do something similar, I'm sure you can
get sip-comm to work.

The mistake I made the first time was going in and editing code and
configuration files before checking to see whether the application ran with
it's default settings. Hence the problems I had with Oscar etc.

/Brian.

···

On 4/19/06, Alan Ramos - alra03 <alra03@student.bth.se> wrote:

Hej Brian,

I have as a second option the ( www.mjsip.org ), however I would really
like to run the SipCommunicator but I think that I have no problem with the
source or build.xml file
For instance IntelliJ IDEA has a very nice of debugging and running and
the ant file has no problems or anything like that.

I do believe that there must be something else. Have you done any change
besides the files... any file that you have look at and uncomment or comment
anything else because I have just tried for a whole day but this is not the
set up of a difficult task, it should be very simple :slight_smile:

Looking forward to hear from you!

----
Alan Raúl Ramos
--------------------------------------------------------------------- To
unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net For
additional commands, e-mail: users-help@sip-communicator.dev.java.net


#4

Hi Dave,

The only way I could get it to run was to manually do the bundles.

Indeed you need to execute the bundles target before actually running
the project as that's where code gets compiled and the jars created.
The run target does not include a dependency to bundles as it is often
necessary to run the project more than once before having to rebuild again.

This is not the first time we're having this kind of reports though. I
suppose that the confusion is due to the non common name of the bundles
target. Right now, the bundles target includes a dependency on the
rebuild target. The purpose was to let a possibility for recompiling the
code without losing the time to build the bundle jars. I am now thinking
though that this is really quite unnecessary and it might be a better
idea to include the bundles target as a dependency to rebuild. (Is this
what you were suggesting?)

Emil

Dave Trollope wrote:

···

I downloaded the source tree for several different nights builds last
week and found there seems to be a dependency problem in the
makefiles. The only way I could get it to run was to manually do the
bundles. I think it should happen automatically, but it is not being
done by default..

Cheers Dave

Brian Long wrote:

Alan,

unfortunately I deleted the original configuration of sip-comm that
I was using after moving to mjsip, but I have just downloaded the sip-communicator-1.0-src.zip again, unzipped it, moved it into my eclipse workspace, ran the ant task "bundles", then the ant task
"run" and it launches successfully. If you could do something
similar, I'm sure you can get sip-comm to work.

The mistake I made the first time was going in and editing code and
configuration files before checking to see whether the application
ran with it's default settings. Hence the problems I had with Oscar
etc.

/Brian.

On 4/19/06, *Alan Ramos - alra03* <alra03@student.bth.se >> <mailto:alra03@student.bth.se>> wrote:

Hej Brian,

I have as a second option the ( www.mjsip.org <http://www.mjsip.org/>), however I would really like to run the SipCommunicator but I think that I have no problem with the source or build.xml file For instance IntelliJ IDEA has a very nice of
debugging and running and the ant file has no problems or anything
like that.

I do believe that there must be something else. Have you done any change besides the files... any file that you have look at and uncomment or comment anything else because I have just tried for a whole day but this is not the set up of a difficult task, it should
be very simple :slight_smile:

Looking forward to hear from you!

---- Alan Ra�l Ramos ---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net <mailto:users-unsubscribe@sip-communicator.dev.java.net> For additional commands, e-mail: users-help@sip-communicator.dev.java.net <mailto:users-help@sip-communicator.dev.java.net>


#5

Hi Emil,

I was expecting "ant make" then "ant run" to work. My expectations may be wrong.

Perhaps this is a stupid user mistake on my part since this is the first time I've worked with ant. Is this how ant projects normally work or is the bundles step specific to sip-communicator?

I was caught out by the need to run ant bundles in between the make and run commands.

I'm not sure that the run should invoke a rebuild since as a developer its not unusual for me to edit code and then rerun something to verify its behaviour as I finish coding....

Hope that helps - and thanks for following up so quickly.

Cheers
Dave

Emil Ivov wrote:

···

Hi Dave,

The only way I could get it to run was to manually do the bundles.

Indeed you need to execute the bundles target before actually running
the project as that's where code gets compiled and the jars created.
The run target does not include a dependency to bundles as it is often
necessary to run the project more than once before having to rebuild again.

This is not the first time we're having this kind of reports though. I
suppose that the confusion is due to the non common name of the bundles
target. Right now, the bundles target includes a dependency on the
rebuild target. The purpose was to let a possibility for recompiling the
code without losing the time to build the bundle jars. I am now thinking
though that this is really quite unnecessary and it might be a better
idea to include the bundles target as a dependency to rebuild. (Is this
what you were suggesting?)

Emil

Dave Trollope wrote:

I downloaded the source tree for several different nights builds last
week and found there seems to be a dependency problem in the
makefiles. The only way I could get it to run was to manually do the
bundles. I think it should happen automatically, but it is not being
done by default..

Cheers Dave

Brian Long wrote:

Alan,

unfortunately I deleted the original configuration of sip-comm that
I was using after moving to mjsip, but I have just downloaded the sip-communicator-1.0-src.zip again, unzipped it, moved it into my eclipse workspace, ran the ant task "bundles", then the ant task
"run" and it launches successfully. If you could do something
similar, I'm sure you can get sip-comm to work.

The mistake I made the first time was going in and editing code and
configuration files before checking to see whether the application
ran with it's default settings. Hence the problems I had with Oscar
etc.

/Brian.

On 4/19/06, *Alan Ramos - alra03* <alra03@student.bth.se >>> <mailto:alra03@student.bth.se>> wrote:

Hej Brian,

I have as a second option the ( www.mjsip.org <http://www.mjsip.org/>), however I would really like to run the SipCommunicator but I think that I have no problem with the source or build.xml file For instance IntelliJ IDEA has a very nice of
debugging and running and the ant file has no problems or anything
like that.

I do believe that there must be something else. Have you done any change besides the files... any file that you have look at and uncomment or comment anything else because I have just tried for a whole day but this is not the set up of a difficult task, it should
be very simple :slight_smile:

Looking forward to hear from you!

---- Alan Ra�l Ramos ---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net <mailto:users-unsubscribe@sip-communicator.dev.java.net> For additional commands, e-mail: users-help@sip-communicator.dev.java.net <mailto:users-help@sip-communicator.dev.java.net>

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

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


#6

Hi, Emil...

I was preparing for a trip away and was checking through our old correspondence. I found one where you asked me about improving the description of the cc-buildloop target so "ant -projecthelp" became
self-explanatory. At the same time, I was downloading the latest source from CVS into a clean sandbox and needed to run that target. I was thinking about the issue when I saw this thread.

The cc-buildloop target is specifically designed as a paranoid project distribution mechanism because it begins with the clean target, which removes all the output folders. As such, it is ideal for someone who has
just checked out the source and so does not have the bundles prepared already, but is a bad idea as a routine activity.

On the other hand, the rebuild target specifically excludes the bundles target.

I think we have missed a key point that is part of the ant philosophy (and other make systems), which is "incremental building". Of course, there will be project dependencies that cannot always be properly
expressed in the build dependencies, which is why we need targets such as cc-buildloop (and any others that depend on the clean target). However, project developers will often want a fast-path build that isn't
100% reliable, but is as quick as possible. This fast-path should specifically NOT depend on clean, relying on ant to detect those targets that are needed to "replenish" objects that are out of date.

In particular, the bundles are unlikely to change, so we ought to be letting ant decide that they usually don't need building. However, each of the many bundle-xxx targets individually runs the ant jar task, which is
incremental but rather inefficient.

Such an "incremental build" target should be called something self-evident, such as "build" (yes, I know we already have one). Incidentally, we document the "make" target as incremental, but it doesn't depend on
bundles. In all, it is quite confusing for me... let alone for someone new to the project.

To summarise...

1. we have some (wiki) project documentation that tells users to run cc-buildloop to initialise a new sandbox. Unfortunately, the many posts to this forum show us there are very many new users who don't rtfm and so
immediately get into trouble using the run target.

2. we follow modern ant paractice by having the no-op target called "usage" as our default. This is intended to help new users by preventing them from blundering into a failed build by accident.

3. I have just committed 2 minor changes to build.xml that should help matters immediately... the usage target now puts cc-buildloop at the top of the list. I've also slightly reworded the description of the cc-buildloop
target to make it sound more important when viewed with "ant -projecthelp".

I am concerned about making the mainstream targets dependent on the bundles target. You are correct about the wasteful processing overheads for active developers. I think there isn't a simple solution, otherwise
we would have thought of it before!!

However, I'll take a look while I am away to see whether I can find a useful compromise... perhaps a new target called "test-fast" that could be used by developers who understand the risks, while making the
"obvious" tasks such as run and test depend on bundles to make them perfectly safe? (I don't think using a new, externally defined, property would be acceptable). I'm not sure of the details yet, because the build is
very complex (especially jmf preparation, netbeans debugging and javadoc targets).

I probably won't collect any follow-up posts for more than a week, but I will not commit any more changes until I've seen your response after I've returned.
Regards,

Brian

···

On Thu, 20 Apr 2006 02:08:56 +0200, Emil Ivov wrote:

Hi Dave,

The only way I could get it to run was to manually do the bundles.

Indeed you need to execute the bundles target before actually running
the project as that's where code gets compiled and the jars created.
The run target does not include a dependency to bundles as it is often
necessary to run the project more than once before having to rebuild again.

This is not the first time we're having this kind of reports though. I
suppose that the confusion is due to the non common name of the bundles
target. Right now, the bundles target includes a dependency on the
rebuild target. The purpose was to let a possibility for recompiling the
code without losing the time to build the bundle jars. I am now thinking
though that this is really quite unnecessary and it might be a better
idea to include the bundles target as a dependency to rebuild. (Is this
what you were suggesting?)

Emil

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


#7

Brian,

You make some very good points, and I agree with you about the main developers needing a fast path build that doesn't depend on a clean.

I have to take issue with the following comment:

1) we have some (wiki) project documentation that tells users to run cc-buildloop to initialise a new sandbox. Unfortunately, the many posts to this forum show us there are very many new users who don't rtfm and so immediately get into trouble using the run target.

As anew user to both ant and sip-sommunicator I spent several hours trying to find the relevant documentation. I do not intend to be a mainstream developer of this product - just a user.

Unfortunately, the "User documentation" on the web page page just says "Coming Soon" and the Developer documentation subject on Ant targets doesn't document bundles.

cc-buildloop is listed as an "internal target" so as a user I would avoid it like the plague.

We could help this situation greatly if the wiki documenation you reference was linked from the User documentation and if the ant target developer documentation could be updated to be clearer and guide new users how to do a complete build to get the product built and running.

Then I think that no updates to the source are really required.

Cheers
Dave
Brian Burch wrote:

···

On Thu, 20 Apr 2006 02:08:56 +0200, Emil Ivov wrote:

Hi Dave,

The only way I could get it to run was to manually do the bundles.
      

Indeed you need to execute the bundles target before actually running
the project as that's where code gets compiled and the jars created.
The run target does not include a dependency to bundles as it is often
necessary to run the project more than once before having to rebuild again.

This is not the first time we're having this kind of reports though. I
suppose that the confusion is due to the non common name of the bundles
target. Right now, the bundles target includes a dependency on the
rebuild target. The purpose was to let a possibility for recompiling the
code without losing the time to build the bundle jars. I am now thinking
though that this is really quite unnecessary and it might be a better
idea to include the bundles target as a dependency to rebuild. (Is this
what you were suggesting?)

Emil

Hi, Emil...

I was preparing for a trip away and was checking through our old correspondence. I found one where you asked me about improving the description of the cc-buildloop target so "ant -projecthelp" became self-explanatory. At the same time, I was downloading the latest source from CVS into a clean sandbox and needed to run that target. I was thinking about the issue when I saw this thread.

The cc-buildloop target is specifically designed as a paranoid project distribution mechanism because it begins with the clean target, which removes all the output folders. As such, it is ideal for someone who has just checked out the source and so does not have the bundles prepared already, but is a bad idea as a routine activity.

On the other hand, the rebuild target specifically excludes the bundles target.

I think we have missed a key point that is part of the ant philosophy (and other make systems), which is "incremental building". Of course, there will be project dependencies that cannot always be properly expressed in the build dependencies, which is why we need targets such as cc-buildloop (and any others that depend on the clean target). However, project developers will often want a fast-path build that isn't 100% reliable, but is as quick as possible. This fast-path should specifically NOT depend on clean, relying on ant to detect those targets that are needed to "replenish" objects that are out of date.

In particular, the bundles are unlikely to change, so we ought to be letting ant decide that they usually don't need building. However, each of the many bundle-xxx targets individually runs the ant jar task, which is incremental but rather inefficient.

Such an "incremental build" target should be called something self-evident, such as "build" (yes, I know we already have one). Incidentally, we document the "make" target as incremental, but it doesn't depend on bundles. In all, it is quite confusing for me... let alone for someone new to the project.

To summarise...

1. we have some (wiki) project documentation that tells users to run cc-buildloop to initialise a new sandbox. Unfortunately, the many posts to this forum show us there are very many new users who don't rtfm and so immediately get into trouble using the run target.

2. we follow modern ant paractice by having the no-op target called "usage" as our default. This is intended to help new users by preventing them from blundering into a failed build by accident.

3. I have just committed 2 minor changes to build.xml that should help matters immediately... the usage target now puts cc-buildloop at the top of the list. I've also slightly reworded the description of the cc-buildloop target to make it sound more important when viewed with "ant -projecthelp".

I am concerned about making the mainstream targets dependent on the bundles target. You are correct about the wasteful processing overheads for active developers. I think there isn't a simple solution, otherwise we would have thought of it before!!

However, I'll take a look while I am away to see whether I can find a useful compromise... perhaps a new target called "test-fast" that could be used by developers who understand the risks, while making the "obvious" tasks such as run and test depend on bundles to make them perfectly safe? (I don't think using a new, externally defined, property would be acceptable). I'm not sure of the details yet, because the build is very complex (especially jmf preparation, netbeans debugging and javadoc targets).

I probably won't collect any follow-up posts for more than a week, but I will not commit any more changes until I've seen your response after I've returned.
Regards,

Brian

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

--
David Trollope BSc(Hons) MIAP
Lucent Technologies
Tel/Fax: (630)713-9110
Email: trollope@lucent.com
         
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#8

Hi guys,

I'd like to straighten something out. The cc-buildloop target is not
supposed to be run by users. Not even when initializing the sandbox. I
guess that the confusion is coming from that fact that this has long
been the only target that was doing anything meaningful - running the
automated tests. However, this is something that users won't normally
need to do. The _only_ target that needs to be run in order to
initialize the sandbox is the bundles target. This would clean, and
compile, create bundle jars. In other words:

  rebuild = clean + compile
  bundles = rebuild + create all jars
  cc-buildloop = bundles + test
  run = runs the project

I agree that this does not really make sense, not to mention that it is
far from being intuitive. I therefore propose the following configuration:

  clean = remains as is
  comile = remains as is
  make = compile + bundles
  rebuild = clean + make
  cc-buildloop = rebuild + test
  run = remains as is.

This way we'll end up having a configuration which would only require

  ant make run

for users dealing with a new sandbox and would keep the ant cc-buildloop
target for developers.

Does this make sense?

Emil

Dave Trollope wrote:

···

Brian,

You make some very good points, and I agree with you about the main developers needing a fast path build that doesn't depend on a clean.

I have to take issue with the following comment:

1) we have some (wiki) project documentation that tells users to run
cc-buildloop to initialise a new sandbox. Unfortunately, the many
posts to this forum show us there are very many new users who don't
rtfm and so immediately get into trouble using the run target.

As anew user to both ant and sip-sommunicator I spent several hours trying to find the relevant documentation. I do not intend to be a mainstream developer of this product - just a user.

Unfortunately, the "User documentation" on the web page page just
says "Coming Soon" and the Developer documentation subject on Ant
targets doesn't document bundles.

cc-buildloop is listed as an "internal target" so as a user I would avoid it like the plague.

We could help this situation greatly if the wiki documenation you reference was linked from the User documentation and if the ant
target developer documentation could be updated to be clearer and
guide new users how to do a complete build to get the product built
and running.

Then I think that no updates to the source are really required.

Cheers Dave Brian Burch wrote:

On Thu, 20 Apr 2006 02:08:56 +0200, Emil Ivov wrote:

Hi Dave,

The only way I could get it to run was to manually do the
bundles.

Indeed you need to execute the bundles target before actually
running the project as that's where code gets compiled and the
jars created. The run target does not include a dependency to
bundles as it is often necessary to run the project more than
once before having to rebuild again.

This is not the first time we're having this kind of reports
though. I suppose that the confusion is due to the non common
name of the bundles target. Right now, the bundles target
includes a dependency on the rebuild target. The purpose was to
let a possibility for recompiling the code without losing the
time to build the bundle jars. I am now thinking though that this
is really quite unnecessary and it might be a better idea to
include the bundles target as a dependency to rebuild. (Is this what you were suggesting?)

Emil

Hi, Emil...

I was preparing for a trip away and was checking through our old
correspondence. I found one where you asked me about improving the
description of the cc-buildloop target so "ant -projecthelp" became
self-explanatory. At the same time, I was downloading the latest
source from CVS into a clean sandbox and needed to run that target.
I was thinking about the issue when I saw this thread.

The cc-buildloop target is specifically designed as a paranoid
project distribution mechanism because it begins with the clean
target, which removes all the output folders. As such, it is ideal
for someone who has just checked out the source and so does not
have the bundles prepared already, but is a bad idea as a routine
activity.

On the other hand, the rebuild target specifically excludes the
bundles target.

I think we have missed a key point that is part of the ant
philosophy (and other make systems), which is "incremental
building". Of course, there will be project dependencies that
cannot always be properly expressed in the build dependencies,
which is why we need targets such as cc-buildloop (and any others
that depend on the clean target). However, project developers will
often want a fast-path build that isn't 100% reliable, but is as
quick as possible. This fast-path should specifically NOT depend on
clean, relying on ant to detect those targets that are needed to
"replenish" objects that are out of date.

In particular, the bundles are unlikely to change, so we ought to
be letting ant decide that they usually don't need building.
However, each of the many bundle-xxx targets individually runs the
ant jar task, which is incremental but rather inefficient.

Such an "incremental build" target should be called something
self-evident, such as "build" (yes, I know we already have one).
Incidentally, we document the "make" target as incremental, but it
doesn't depend on bundles. In all, it is quite confusing for me...
let alone for someone new to the project.

To summarise...

1. we have some (wiki) project documentation that tells users to
run cc-buildloop to initialise a new sandbox. Unfortunately, the
many posts to this forum show us there are very many new users who
don't rtfm and so immediately get into trouble using the run
target.

2. we follow modern ant paractice by having the no-op target called
"usage" as our default. This is intended to help new users by
preventing them from blundering into a failed build by accident.

3. I have just committed 2 minor changes to build.xml that should
help matters immediately... the usage target now puts cc-buildloop
at the top of the list. I've also slightly reworded the description
of the cc-buildloop target to make it sound more important when
viewed with "ant -projecthelp".

I am concerned about making the mainstream targets dependent on the
bundles target. You are correct about the wasteful processing
overheads for active developers. I think there isn't a simple
solution, otherwise we would have thought of it before!!

However, I'll take a look while I am away to see whether I can find
a useful compromise... perhaps a new target called "test-fast" that
could be used by developers who understand the risks, while making
the "obvious" tasks such as run and test depend on bundles to make
them perfectly safe? (I don't think using a new, externally
defined, property would be acceptable). I'm not sure of the details
yet, because the build is very complex (especially jmf preparation,
netbeans debugging and javadoc targets).

I probably won't collect any follow-up posts for more than a week,
but I will not commit any more changes until I've seen your
response after I've returned. Regards,

Brian

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