[sip-comm-dev] build.xml changes for netbeans debugging


#1

Hi, everyone. I thought it polite to let you know that I've just committed some changes to
the new build.xml for support of netbeans debugging.

It is my intention that the change be transparent to non-netbeans users, but I couldn't
resist reworking the "test" target so that it would run ALL tests by default, and a single
test if the property "test.case" was defined. This involved changing an existing ant
target that already worked OK.

Obviously, I tested my change in a sandbox, but that cannot be 100% guaranteed to be
correct. If I've broken the build for anyone else, please accept my apologies and give
me the chance to forward-fix my change....

The other reason I needed to commit my change is that I now need to update the wiki,
because support for netbeans has changed a lot between sip-comm 0.x and 1.0-draft.
My wiki pages need to tell users how to checkout and configure "fresh" from CVS, but
until I can do it myself (tomorrow), I can't write the procedure!!!
Regards,

Brian

···

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


#2

Hey Brian,

Brian Burch wrote:

It is my intention that the change be transparent to non-netbeans users, but I couldn't resist reworking the "test" target so that it would run ALL tests by default, and a single test if the property "test.case" was defined. This involved changing an existing ant target that already worked OK.

Good idea!

So as a result one could now run a single test by executing

ant test -Dtest.name=./path/to/test/Test.java

is that so? That is really quite useful, thanks for adding it! We should add some help on using it though, so that users don't have to experiment much in order to find the right syntax.

Another question. The identify-test and prepare-xxx-test seem to be for internal use only. If that's the case wouldn't it be a good idea to make sure they don't appear in the project help menu? I remember discussing that with you a while ago and you proposed removing descriptions for such targets, and rather having the explanations in the form of comments. Prefixing the target name with a - (dash) might also be a good idea. What do you think?

The same is actually true for other targets such as the jmf helper target for example. Martin, do you agree, or would it be possible for a developer to need to execute that target separately?

Ah, one more thing. Bundle building targets are the one part of the build.xml that is bound to constantly grow so I suggest we leave it last. I've therefor moved the netbeans debug target above it.

Oh and by the way, Brian, I've moved you back to the active developers contributors section. Nice to have you back!

Cheers
Emil

···

Obviously, I tested my change in a sandbox, but that cannot be 100% guaranteed to be correct. If I've broken the build for anyone else, please accept my apologies and give me the chance to forward-fix my change....

The other reason I needed to commit my change is that I now need to update the wiki, because support for netbeans has changed a lot between sip-comm 0.x and 1.0-draft. My wiki pages need to tell users how to checkout and configure "fresh" from CVS, but until I can do it myself (tomorrow), I can't write the procedure!!!
Regards,

Brian

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


#3

Hey Brian,

Brian Burch wrote:

It is my intention that the change be transparent to non-netbeans users, but I couldn't resist reworking the "test" target so that it would run ALL tests by default, and a single test if the property "test.case" was defined. This involved changing an existing ant target that already worked OK.

Good idea!

So as a result one could now run a single test by executing

ant test -Dtest.name=./path/to/test/Test.java

is that so? That is really quite useful, thanks for adding it! We should add some help on using it though, so that users don't have to experiment much in order to find the right syntax.

Another question. The identify-test and prepare-xxx-test seem to be for internal use only. If that's the case wouldn't it be a good idea to make sure they don't appear in the project help menu? I remember discussing that with you a while ago and you proposed removing descriptions for such targets, and rather having the explanations in the form of comments. Prefixing the target name with a - (dash) might also be a good idea. What do you think?

The same is actually true for other targets such as the jmf helper target for example. Martin, do you agree, or would it be possible for a developer to need to execute that target separately?

Ah, one more thing. Bundle building targets are the one part of the build.xml that is bound to constantly grow so I suggest we leave it last. I've therefor moved the netbeans debug target above it.

Oh and by the way, Brian, I've moved you back to the active developers contributors section. Nice to have you back!

Cheers
Emil

···

Obviously, I tested my change in a sandbox, but that cannot be 100% guaranteed to be correct. If I've broken the build for anyone else, please accept my apologies and give me the chance to forward-fix my change....

The other reason I needed to commit my change is that I now need to update the wiki, because support for netbeans has changed a lot between sip-comm 0.x and 1.0-draft. My wiki pages need to tell users how to checkout and configure "fresh" from CVS, but until I can do it myself (tomorrow), I can't write the procedure!!!
Regards,

Brian

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


#4

It is my intention that the change be transparent to non-netbeans users, but I couldn't
resist reworking the "test" target so that it would run ALL tests by default, and a single
test if the property "test.case" was defined. This involved changing an existing ant
target that already worked OK.

Good idea!

So as a result one could now run a single test by executing

ant test -Dtest.name=./path/to/test/Test.java

is that so? That is really quite useful, thanks for adding it! We should
add some help on using it though, so that users don't have to experiment
much in order to find the right syntax.

Yes, that is exactly my intention...
... but I didn't have time to test it, and was happy to leave the matter hanging on the basis that it would be a bonus.

Let me know if it works and you'll save me some time. I have no reason to think it won't.

Another question. The identify-test and prepare-xxx-test seem to be for
internal use only. If that's the case wouldn't it be a good idea to make
sure they don't appear in the project help menu? I remember discussing
that with you a while ago and you proposed removing descriptions for
such targets, and rather having the explanations in the form of
comments. Prefixing the target name with a - (dash) might also be a good
idea. What do you think?

Yes, we did discuss the matter before, but I was reluctant to re-implement that aspect of the build, when you had "apparently" discarded with the new version.

The same is actually true for other targets such as the jmf helper
target for example. Martin, do you agree, or would it be possible for a
developer to need to execute that target separately?

I feel there should be a very small number of targets accessible (to anyone). I think it is useful to
a) have as many internal targets as necessary to make the build clear to someone trying to understand it.
b) have as few as possible accessible to "users" trying to run it.

netbeans expects no more than 5 "project level" targets : build; doc; clean; (clean & build is generated internally); test; run. It is hard to think why we need more than this (obviously, excluding the file-level targets
used by the ide).

I would LOVE to re-introduce the change I made in the old sip-comm.... the default target (executed when no target is explicitly selected) is "usage", which simply echos some useful ant options to the console. This
means a newbie who runs "ant" (without arguments) after a checkout can't get into trouble by deleting things best not deleted.

e.g.

  <!-- describe useful Ant-internal help options -->
    <target name="usage" >
      <!-- internal target - high-level default help for no-args invocation -->
       <echo message="execute 'ant -projecthelp' for build file help" />
       <echo message="execute 'ant -help' for Ant help" />
       <echo message="execute 'ant release' for clean/build/test operation" />
    </target>

So, it tells you exactly what to run if you want "the full monty", and also reminds you of "ant -projecthelp" to discover ONLY those targets that are meaningful.

Do you want to do it Emil, or just leave it to me?

Ah, one more thing. Bundle building targets are the one part of the
build.xml that is bound to constantly grow so I suggest we leave it
last. I've therefor moved the netbeans debug target above it.

I simply put the netbeans debug-single target at the end of the build because I thought no-one would be interested in it. If you have a strong reason to put the bundles at the end, then I'm happy.

I didn't want to get too clever with my first attempt, so you will see this target has at least 80 percent in common with your "test" target (as modified by me). I'd like to think I can extract the 80 percent into a common
internal target shared by the two minimalised external targets.

BTW... I'm now happy the build is OK, so I'll write up the wiki this weekend. I like Andre's rewrite of the eclipse stuff, so perhaps he will have a go at my new netbeans instructions once I've written them longhand?

Oh and by the way, Brian, I've moved you back to the active developers
contributors section. Nice to have you back!

I was never "away" in my own mind, only when measured by my contributions.
Regards,

Brian

···

On Wed, 30 Nov 2005 15:57:11 +0100, Emil Ivov wrote:

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


#5

Emil Ivov wrote:

Another question. The identify-test and prepare-xxx-test seem to be for internal use only. If that's the case wouldn't it be a good idea to make sure they don't appear in the project help menu? I remember discussing that with you a while ago and you proposed removing descriptions for such targets, and rather having the explanations in the form of comments. Prefixing the target name with a - (dash) might also be a good idea. What do you think?

The same is actually true for other targets such as the jmf helper target for example. Martin, do you agree, or would it be possible for a developer to need to execute that target separately?

I've no objections about doing so.

Martin

···

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


#6

Brian,

I would LOVE to re-introduce the change I made in the old
... ... ...
Do you want to do it Emil, or just leave it to me?

Please, go ahead, and thanks!

Emil

···

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


#7

Sorry to be clueless about cruise control, but can you please confirm that it runs ant
explicitly with the cc-buildloop target... (if it relies on running ant with the implicit default
target, then my change would break the cruise control process).
Regards,

Brian

···

On Thu, 01 Dec 2005 15:33:02 +0100, Emil Ivov wrote:

I would LOVE to re-introduce the change I made in the old

Please, go ahead, and thanks!

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


#8

Sorry to be clueless about cruise control, but can you please confirm that it runs ant explicitly with the cc-buildloop target... (if it relies on running ant with the implicit default target, then my change would break the cruise control process).
Regards,

Yes. That's the way it is. Cruisecontrol uses cc-buildloop.

Cheers
Emil

···

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