Marek Potociar wrote:
> 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.
I'm all for improving project files for any IDE. This is relatively easy
to do with, say, Eclipse, because we know whatever changes we make to
.classpath and .project won't affect anything else.
But I thought doing so with NetBeans mean modifying build.xml. Hence my
concern was how much impact it will have on the build script and its
maintainability.
For example, those build scripts are used for JWSDP builds and JES
integrations, where the jar files are selectively replaced to the ones
built in the current build and so on. I think it's fair to say any
significant modification to the build script is going to have some impact.
And it's unclear what are the benefits of making this change. I thought
today's NB project files in JAX-WS works --- you can edit source files
with code completion, right? I'd rather prefer to investigate ways to
improve the NB project files in JAX-WS without modifying build.xml. It
sounded like there are things we can do here.
(I don't speak for the team, though, so they might not need as much
hand-holding as I do.)
>> 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.
There are many, including:
- people can generate files they need for their IDEs. We'll get
great support on every IDE.
- integration effort like JES/Mustang will be easier when
all components build with Maven.
>> 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.
That's encouraging. Maybe it's not as bad as I thought.
>> 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)
I think our goal is to improve the quality of the code, and enable
developers to take a bigger risk in making changes, knowing that any
regressions would be caught quickly.
It doesn't really matter what names you give to tests, and we just try
to get to better coverage within the constraints of resources.
I think the current and proposed JAX-WS test set up satisfies this need.
Tests are run fairly quickly enough after a commit is made, so we do
enjoy most of the benefits of what you describe.
It's also worth pointing out that in JAX-WS, "API" is fairly small, and
not that interesting. Most of the interesting stuff happens with
dynamically generated/composed pieces, so testing the JAX-WS RI needs
somewhat different approach than testing, say, java.io.File.
> 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.
Yep. I'm all for that. In fact I believe tests in the new harness will
be co-located with the source.
Again, the reason why old tests are in a separate place is not a
technical one, but rather legal and historical ones.
>> 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.
OK, I'll file an RFE.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com