A dist (distribution) ANT target for the main build.xml

--- Brian Burch <brianPingToo.com> wrote:

> Pavel Tankov wrote:
> > Hello Devs,
> > 
> > As I was again studying the main build.xml script
I was searching for the most common task
> that
> > bootstraps all activities. Such a task right now
is "rebuld", but since it merely depends on
> clean
> > and make, let's take a look at "make".
What make does is compile sources and package bundles.
> > 
> > However, I feel that something is missing in the
whole picture. I feel the need of a task that
> > would just copy all the files, needed for a
platform-independent distribution, into a separate
> > folder and then possibly zip them or tar.gzip
them.
> > 
> > Such a target could be named "dist"
(from "distribution"). It could even be used for
several
> types
> > of distributions - binary production distro,
binary debug distro, source distro, etc. This
> reminds
> > me of the "make install" command that
does a similar job for the C/C++ projects.
> > 
> > This is somehow related to my work on the RPM
packages. As a newcommer, I had difficulties
> > realizing what goes where after I build the
sources. I mean, it would be great to have the
> > structure in a "dist/" folder ready for
packaging (maybe that's what "release/" is all
about).
> > 
> > What do you think?
> > 
> 
> The cc-buildloop target is used by CruiseControl to
ensure we test 
> against a 100% clean build.
> 
> In my opinion, ANY/ALL distribution targets should
depend on 
> cc-buildloop, even if they are not always run as part
of cc-buildloop. 
> In other words, we should only distribute after a
perfect 
> clean/build/test cycle.
> 
> In my own projects, I try to put the distribution jars
on the classpath 
> for the unit tests. That way I am testing as close to
the distribution 
> packages as possible. We haven't gone that way yet with
sip-comm... the 
> test classpath uses the individual class files.
> 
> In my opinion, the build is very complex (mostly
necessary) and the 
> project is too volatile to risk breaking something that
is currently 
> working OK. The time to review the structure of our
build.xml is after 
> the first release has stabilised.
> 
> Regards,
> 
> Brian
> 
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
> 
> 

Hello Brian,

Thank you for the explanations. What you say about having
the first release stabilised and then
reviewing the build.xml make sense to me and I agree with
you.

Yet, I still need help with structuring the layout of the
rpm package. I reviewed the deb package
and, certainly, can take it as a model to follow, but if you
could point me to some description of
the desired layout that would help a great deal.

Thanks,
--Pavel Tankov


 
____________________________________________________________
______________________________
Check out the New Yahoo! Mail - Fire up a more powerful
email and get things done faster. 
(http://a
dvision.webevents.yahoo.com/mailbeta) 

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