[sip-comm-dev] Ant targets... external or internal


#1

If you run "ant -projecthelp" you get a listing of our "external" ant targets within the
project.

The ant mechanism in this area isn't very elegant. In the ideal world, <target> would
have an extra attribute such as targetType=internal/external. However, at the moment
the way to make this distinction is via the description attribute - if it exists, the target is
externally visible... otherwise it is not.

Of course, there is nothing to prevent you running ant against an internal target. I'm only
talking about those targets which appear when you run -projecthelp.

I have reviewed my own new targets and categorised them... external targets have a
description attribute and internal targets have an XML comment instead of a
description.

I have the impression that we have too many external targets and would like to make a
few changes. However, I am not familiar enough with their functionality and usefulness
to be sure of the right decisions. Can anyone help?

1. Probably should be internal :- bundle-sip, bundle-slick-runner, bundle-slickless,
resource.

2. OK as external now :- clean, make, rebuild, test.

3. Perhaps better to be internal :- compile, extractnativejmf, package.

4. Perhaps better to be external :- cc-buildloop

Emil will have spotted my discomfort with the cc-buildloop and rebuild targets... they
don't do the same thing. I'm also unsure whether it is helpful to update the javadoc
every time. Obviously, our CruiseControl target needs to be our "safety net" by
recreating the project from scratch. I realise developers might find a quicker "rebuild"
target useful, but I'm confused myself and wonder if others might feel the same as me. If
"rebuild" doesn't rebuild everything, perhaps it has the wrong name? If cc-buildloop is
really a "rebuild", why don't we call it rebuild?
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

Compilation error
   
  Hi ,
   
  Missing jar that contains XILCapture , OPICapture etc
   
   Error XILCapture in public class SunVideoAuto {

   Error com.sun.media.protocol.sunvideoplus SunVideoPlusAuto
   
  Dennis Lazreg
  Dolphin Software AS
  www.dolphin.no
   
  Regards
  Dennis

···

---------------------------------
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
T�l�chargez le ici !


#3

Brian Burch wrote:

I have the impression that we have too many external targets and would like to make few changes. However, I am not familiar enough with their functionality and usefulness to be sure of the right decisions. Can anyone help?

1. Probably should be internal :- bundle-sip, bundle-slick-runner, bundle-slickless, resource.

Provided that we keep internal targets executable from the command line
(i.e. we don't prefix them with a dash), then yes we should put all
bundle-xxx targets outside the project help since generally no developer
would be needing to execute more than a small subset of targets herself
and she would generally know these by heart.

2. OK as external now :- clean, make, rebuild, test.

I guess we should add the sc-bundles target here too. It would be
impossible to neither run nor test the application if the bundles
haven't been built, so I guess this is enough of a qualifier to send it
to the project help list.

This makes me wonder, however, whether it wouldn't be a better idea to
simply add it to rebuild's dependencies.

3. Perhaps better to be internal :- compile, extractnativejmf, package.

Agreed.

4. Perhaps better to be external :- cc-buildloop

Absolutely!

Emil will have spotted my discomfort with the cc-buildloop and rebuild targets... they don't do the same thing. Obviously, our CruiseControl target needs to be our "safety net" by recreating the project from scratch. I realise developers might find a quicker "rebuild" target useful, but I'm confused myself and wonder if others
might feel the same as me. If "rebuild" doesn't rebuild everything,
perhaps it has the wrong name? If cc-buildloop is really a
"rebuild", why don't we call it rebuild?

Simply put
rebuild - cleans and builds
cc-buildloop - rebuilds and tests

The exact set of dependencies for those two may however differ in the
future and in order to make sure that they run exactly the same test
suites as cruisecontrol, developers should use the same target. Until
they get to testing however, they will probably be rebuild-ing many
times without needing to do the testing so yes - rebuild should also
remain public.

I'm also unsure whether it is helpful to update the javadoc every time.

You are right, it is not. At least not in rebuild. We do need to have it
for cruisecontrol though since I am planning (as Vlado advised) to make
the cruisecontrol generated documentation accessible over the net. I
guess adding it to the depends attribute of cc-buildloop would be the
way to go.

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


#4

Brian Burch wrote:

1. Probably should be internal :- bundle-sip, bundle-slick-runner,
bundle-slickless, resource.

Provided that we keep internal targets executable from the command line
(i.e. we don't prefix them with a dash), then yes we should put all
bundle-xxx targets outside the project help since generally no developer
would be needing to execute more than a small subset of targets herself
and she would generally know these by heart.

Done.

2. OK as external now :- clean, make, rebuild, test.

I guess we should add the sc-bundles target here too. It would be
impossible to neither run nor test the application if the bundles
haven't been built, so I guess this is enough of a qualifier to send it
to the project help list.

4. Perhaps better to be external :- cc-buildloop

Absolutely!

Emil will have spotted my discomfort with the cc-buildloop and
rebuild targets... they don't do the same thing. Obviously, our
CruiseControl target needs to be our "safety net" by recreating the
project from scratch. I realise developers might find a quicker
"rebuild" target useful, but I'm confused myself and wonder if others
might feel the same as me. If "rebuild" doesn't rebuild everything,
perhaps it has the wrong name? If cc-buildloop is really a
"rebuild", why don't we call it rebuild?

I checked the existing dependencies and decided it was best to make the
cc-buildloop target visible to projectHelp. cc-buildloop depends on the
bundles target (and dependents). I've added a description tag that should
be self-explanatory. I've also added a note to the rebuild target, saying it
does not do bundles or tests.

3. Perhaps better to be internal :- compile, extractnativejmf,
package.

Agreed.

Done.

I've also tidied the descriptions of the remaining external targets so they are
each brief enough to fit on a single line, yet are as helpful as possible. If
anyone thinks of a way to improve them, please go ahead.
Regards,

Brian Burch
[http://www.PingToo.com/]

···

On Thu, 15 Dec 2005 02:27:37 +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