Dinesh Patil wrote:
> Kohsuke Kawaguchi wrote:
>
>> Dinesh Patil wrote:
>>
>>> * Workspace team thinks that current build system is far from
>>> perfect on maven usage but still very stable, and easy to build,
>>> so don't need to scrap everything for providing few missing
>>> features like IDE etc.
>>
>>
>> I think there's a large gap between the characterization done above
>> and what I've been hearing from people around me.
>>
>> [...]
>>
>> Or just ask around for people's honest opinions about their experience
>> in building Glassfish. Many Tango developers did it, and I'm sure they
>> are happy to share their experiences.
>
> Tango developers, please send me your opinions and issues you faced
> during GlassFish build, we will try to resolve it in current workspace
> if possible.
>
Here's my list of opinions about and issues with the GF build process.
Some of them have been discussed in the past, but I honestly don't
follow this alias closely, so I might be pointing out things that have
already been resolved.
1. I initially had a difficult time locating the build instructions on
java.net. Things seem a little more obvious now than they did when
I was getting started.
2. The build instructions don't clearly explain what each of the maven
goals do. How about a nice basic table that people can reference
instead of having to skim through the document. For example, I have
no idea what the difference is between the "bootstrap" and "bootstrap-all"
goals. I could go on.
3. Someone gave me a reference to the internal build instructions, which
I found confusing. This doc should really be split into AS -vs- GF
specific build info IMO.
4. The entire idea of the bootstrapping step seems to complicate the
process. I happen to be working on a branch of GF, but my bootstrap
directory is from the trunk. What if there is a parity error between
the two branches? To avoid this, I don't even run the bootstrap goal,
I just checkout/update the whole workspace in one step. This is a
documented way of building GF, but why bother? Isn't it easier to
just checkout the whole workspace?
I personally ran into a lot of trouble letting maven run the cvs
checkout for me. I couldn't get this to work under cygwin, so I have
to fall back to an MKS shell or manually check out the entire workspace.
5. Why does the build have to bootstrap itself with a glassfish image?
Why does the build have to download a copy of Ant?
6. If the GF build process is "very stable, and easy to build", why is
there an hour-long hands-on lab explaining the process? The lab docs
say "Bring your own Laptop or you can use one of the machines in the
Lab". I don't know about your laptop, but on mine the process of
checking out and building the entire thing is about 45 minutes.
7. I'm no maven expert, so I can't really comment on the way it is being
used by GF, but I think Kohsuke has given plenty of feedback on that
front.
8. Integration with NetBeans seems flawed. The instructions have you
manually run cvs and maven commands to bootstrap and grab sources.
In some cases, you actually have to build things with Maven before
you can start working in the IDE. Furthermore, the instructions only
explain how to build a single module at a time - how do I build GF
as a whole? Also, the NB project seems to use the downloaded GF image
to resolve classes loaded in the editor rather than the actual source
paths in the workspace. That sounds very bad to me. The bottom-line
is that it just looks too difficult to even bother trying IMO.
I think it is perfectly fine to have a build process that allows a great
deal of flexibility, which seems to have been one of the original goals,
but the base case has to be brain-dead simple:
% cvs co glassfish
% cd glassfish
% maven build configure-runtime
I hope you find this feedback useful.
--Ryan