[sip-comm-dev] A dist (distribution) ANT target for the main build.xml


#1

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?

--Pavel Tankov

···

____________________________________________________________________________________
Low, Low, Low Rates! Check out Yahoo! Messenger's cheap PC-to-Phone call rates
(http://voice.yahoo.com)

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


#2

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-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

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

···

--- Brian Burch <brian@PingToo.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-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

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

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


#4

Pavel Tankov wrote:

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.

Sorry, Pavel, I cannot offer you any help. Although I've been a *nix user for several years, I haven't had any experience with either rpm or deb packaging. All my ant packaging work has been related to building and deploying j2ee war files, so it isn't very relevant.

However, if you need advice on how to craft your manual packaging stages into the existing build.xml, I'll try to help if everyone else is too busy working on the code. (I've been hoping Emil would have commented on this thread, but perhaps he is too busy?)

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


#5

Hey guys,

The "dist" target discussion started offline and I asked Pavel to move it to the mailing list. I personally feel it is a good idea to have such a target in the build.xml (there was one like it in the previous version). I'd like it to build a tar.gz/zip of the sources and another one for the OSCAR repository (the binaries). The latter should include run scripts that should be the same as those used in the platform specific packages.

I also think that it is important to have this package target ready before the release so that it could be a part of it. I need to debug JMF and the SIP implementation some more so this would give Pavel the time to implement the target.

Brian Burch wrote:

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.

I agree. Adding an ant dependency on cc-buildloop to the dist target might be a bit too heavy though.

Here's what I'd suggest: CruiseControl uses its own build.xml that references that of SIP Communicator. Right now it looks pretty much like this.

<target name="build">
    <Get the latest from CVS>
        <!-- Call cc-buildloop-->
    <ant antfile="build.xml" target="cc-buildloop"/>

    <!-- Generate the javadocs -->
    <ant antfile="build.xml" target="javadoc"/>
    <copy todir="public_html/sip-comm-doc">
         <fileset dir="doc/api"/>
    </copy>

    <!-- Create installation packages -->
    <ant antfile="build.xml" target="build-installation-generic" />
    <ant antfile="build.xml" target="build-installation-windows" />
    <ant antfile="build.xml" target="build-installation-linux" />

    <!-- Upload install-->
    <dirname property="lbasedir" file="\{ant\.file\}&quot;/&gt; &nbsp;&nbsp;&nbsp;&nbsp;&lt;exec dir=&quot;{lbasedir}" executable="upload-sip-communicator.sh"/>
</target>

You notice that we're already generating the izpack installers there. Since ant would stop executing when it encounters an error, these installers are only generated if cc-buildloop has gone ok. I guess we could do the same for a possble dist target.

Cheers
Emil

Brian Burch wrote:

···

Pavel Tankov wrote:

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.

Sorry, Pavel, I cannot offer you any help. Although I've been a *nix user for several years, I haven't had any experience with either rpm or deb packaging. All my ant packaging work has been related to building and deploying j2ee war files, so it isn't very relevant.

However, if you need advice on how to craft your manual packaging stages into the existing build.xml, I'll try to help if everyone else is too busy working on the code. (I've been hoping Emil would have commented on this thread, but perhaps he is too busy?)

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