Skip to main content

ant test-single target for non-netbeans users

5 replies [Last post]
dhall
Offline
Joined: 2006-02-17

This is a random note for anyone else that wants to work on swing-labs without being a netbeans user. This is what I figured out on the fly -- it is not necessarily definitive: it's just a breadcrumb that seems to work so far.

The 'test-single' target in the build.xml file is a useful idea, but its implementation is dependant on the IDE setting two particular properties: javac.includes and test.includes. It appears that they both want an ant-style 'includes' declaration containing the source-code files that you're working with.

You can set these properties manually by editing the

./nbproject/private/private.properties file

When I started, my file included one line:

<br />
user.properties.file=/home/dave/.netbeans/4.1/build.properties<br />

In order to work with the tests for PatternModel, I added these two lines:
<br />
test.includes=**/PatternModelTest.java<br />
javac.includes=**/PatternModelTest.java<br />

To test this, I inserted the following code in PatternModelTest:
<br />
    public void testFailure() {<br />
        fail ("Found test class correctly");<br />
    }<br />

and ran 'ant test-single' from a command line, and also ran the test case from Emacs JDE via 'C-C C-V C-B test-single'. In both cases, the PatternModelTest.java file is compiled and executed, and fails exactly as expected.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
rbair
Offline
Joined: 2003-07-08

Hey Dave,

> When I started, my file included one line:
> [code]
> user.properties.file=/home/dave/.netbeans/4.1/build.pr
> operties
> [/code]
> In order to work with the tests for PatternModel, I
> added these two lines:
> [code]
> test.includes=**/PatternModelTest.java
> javac.includes=**/PatternModelTest.java
> [/code]

I wonder if this has to be in private.properties, or could it be in project.properties? I wonder because the "official" word from NB is that we shouldn't have to include the private directory in CVS. Indeed, the NB IDE will blow away the contents of this directory anyway. I'm just wondering if we could put it in another file and commit to CVS so folks not using NB don't have to twiddle to get it to build.

Richard

dhall
Offline
Joined: 2006-02-17

The file clearly should not exist in CVS -- it's too environment specific for anyone to really be able to use anyone else's version. I've already run into a couple of cases where the original note is not the best solution (but I don't have a better one, yet) (oops, maybe I do - see below).

Non-NB users will probably always have to twiddle, though -- it appears that NB' ant file references some properties files that the NB UI munges in response to user interaction (in this case, it appears that NB sets these properties as the user highlights files in a file browser). Anyone who isn't using the NB UI has to arrange somehow for these properties to be set correctly in order to use that particular ant target.

Funny how talking (ok, writing) about a problem sometimes brings other solutions to mind. I could configure emacs to prompt for ant command line arguments, and define those two properties using the -D flag. Once they've been typed once in a particular emacs session, you can always pull them from history.

Dave

Richard Bair

>Non-NB users will probably always have to twiddle, though -- it appears
>that NB' ant file references some properties files that the NB UI munges in
>response to user interaction (in this case, it appears that NB sets these
>properties as the user highlights files in a file browser). Anyone who
>isn't using the NB UI has to arrange somehow for these properties to be set
>correctly in order to use that particular ant target.
>
>Funny how talking (ok, writing) about a problem sometimes brings other
>solutions to mind. I could configure emacs to prompt for ant command line
>arguments, and define those two properties using the -D flag. Once they've
>been typed once in a particular emacs session, you can always pull them
>from history.

When going with the NB ant files, I was hoping to get two benefits: people
using the NB ide would be able to open and build the projects easily, and
the ant files would be there for anybody building from the command line. In
another thread Mark is bringing up build issues he's having with the
projects (ostensibly using emacs). It'd be good if we could make the
build/test process from the command line easier. NB does let you extend the
build system by modifing one of the xml files... we should be able to add
targets that do what we want.

Richard

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

Patrick Wright

> When going with the NB ant files, I was hoping to get two benefits: people
> using the NB ide would be able to open and build the projects easily, and
> the ant files would be there for anybody building from the command line. In
> another thread Mark is bringing up build issues he's having with the
> projects (ostensibly using emacs). It'd be good if we could make the
> build/test process from the command line easier. NB does let you extend the
> build system by modifing one of the xml files... we should be able to add
> targets that do what we want.

For my part, I've generally been very successful at using the
NB-generated Ant build files from the command line. I suspect what we
need is to find a document from NetBeans.org that clarifies which
files are used only by the IDE and which are not...though we could dig
this out as well. The larger goal (probably obvious) is that people
can download the source + build files, twiddle one properties file,
and be compiling and running right away--and without twiddling, have
reasonable defaults.

Patrick

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

dhall
Offline
Joined: 2006-02-17

I think that its [i]mostly[/i] there. NetBeans appears to implement some functionality by manipulating properties, and the structure of a NetBeans ant file is not necessarily what you would write if you were working solely from the command line (although (as Patrick can testify) I'm not really one to talk about having a squeaky clean buildfile at all times).

This is a case where netbeans works by manipulating a couple of magic properties, and the rest of us just need to know what those properties are and the various ways we can manipulate them, be they command line options, external properties files, or extra included build files. There's a few of those around, and some of them are commented upon in the default build.properties file. I was mostly suprised in this instance that there were two such properties necessary to get the test-single target working.

I think a first step toward the larger goal will be to simply make sure that all of the main projects have a common structure -- I think there may be discrepencies, although I'm not sure at this point. I'm a little leary of doing much in the ant files outside of netbeans that might affect the netbeans build process.