Kohsuke Kawaguchi wrote:
> The build script has to perform certain tasks in a certain way. A lot
> of the build step is dictated by historical reasons and various
> deliverable requirements. So personally, I'd hesitate to rework the
> build script if that's just for making NetBeans happier.
Starting from NB build script and extending it to perform any additional
tasks is not a problem. I am not sure if we fully understand each other
on this: It is not about making NetBeans happier. It is about making
Netbeans developers happier.
> If we spend time on the build, I'd rather like to see JAX-WS converted
> to Maven.
That is orthogonal to this topic, so no problem with that, unless you
place a your own 'build.xml' file into the project root which NB are not
able to understand. It would be however nice to see an executive
overview on why to use maven.
> Also, I saw build scripts that NetBeans produce, and I have to say I'm
> not a big fan of it. It's really hard to follow, and it's next to
> impossible to modify, unless you use NetBeans to edit it.
>
> But then, maybe I'm totaly missing the point and perhaps there's a way
> to create a better project layout without touching the existing build
> script?
You have to touch a 'build.xml' file in the project root if you want to
have it 'NB compliant'. But it is not impossible nor difficult. We did
it for WSIT and we had it done in less than few hours.
> Also check out http://ws-test-harness.dev.java.net/ for more modern
> test harness. I believe the team is talking about bringing the future
> unit test on this harness, right here at java.net.
Correct me if I am wrong, but the idea behind unit tests is based on
following:
1. unit tests are here to test the correct API behaviour (unit tests are
not E2E tests. they should serve developer to test the intended
behaviour of each non-private method)
2. unit tests are here to improve code quality by instant discovery of
regressions (if you break the API behaviour, single run of a unit test
round helps you to discover it before you commit your changes to a
source repository)
3. unit tests are good to be used as a bug description (you may send a
test reproducing the bug instead of hazy text description)
4. unit tests serve as a powerful source of information about how the
API should be used (you look into the test code to see what is done how)
These statements support the conclusion that unit tests should be
collocated with sources in the same source repository. It is one of the
best practices on software projects.
> I'm sorry, are you saying that this is impossible with NB regardless
> of what we do, or is it a limitation that NB has for a free-style Ant
> project (is that how it's called?)
It is a limitation of a free-style Ant project.
> If latter, sounds like an RFE is in order for NB.
Yes, why not? This is one of the things I would like to fight for in Sun
- better feedback on Sun products that comes from inside.
Marek
--
Marek Potociar
Web Technologies & Standards
Sun Microsystems Czech