I am still catching up with the mail. My comments inlined below,
Kohsuke Kawaguchi wrote:
> 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.
>
Thats right and it wont be good to start modifying build.xml to make NB
easy to use. There should be some other means such as modifying NB
project files without touching the main build.xml. Agreed it has lots of
legacy stuff and I dont think we have time to clear it off for NB. If at
all we decide to overhaul jaxws build system my inclination would be to
move to maven.
> 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.)
>
+1.
>>> 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.
>
JAXWS plan to have their tests move to new test harness and will appear
as sub project of jax-ws.dev.java.net
> Again, the reason why old tests are in a separate place is not a
> technical one, but rather legal and historical ones.
>
>
yes.
-vivek.
>>> 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.
>