dev@glassfish.java.net

Re: GlassFish jars to maven repository

From: Ryan Shoemaker - JavaSoft East <Ryan.Shoemaker_at_Sun.COM>
Date: Thu, 04 May 2006 10:27:55 -0400

Dinesh Patil wrote:
> Ryan Shoemaker - JavaSoft East wrote:
>
>> 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.
>
> This is specified in the FAQ, and linked from this page. We can add
> table with brief info.
> http://wiki.java.net/bin/view/Projects/GlassFishBuildQuestions#BootStrap
>

This is helpful, but a summary in table format would be a nice addition.

>> 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?
>
> if you use default values maven.repo.local is using location from
> ./../glassfish_dependencies where this issue won't happen, but you may
> be overriding this value.. I am using 2-3 branches on same machine and
> don't have any such problem.
>

You didn't address my comment about the bootstrapping step being too
complicated. That's a different issue than the branch (I should have
listed them separately.

Bootstrapping is bad, IMO. One reason I think so is the fact that I
can have a trunk version of glassfish/bootstrap while the entire rest
of my glassfish workspace is on a different branch. I'm not sure why
you don't think that could be troublesome.

>> 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.
>
> pre-requisite says you need to have CVS Client, and there is a link to
> get the right one :
> https://glassfish.dev.java.net/servlets/ProjectSource#wincvs
>

I'm sorry, but I've been working with java.net for years (I'm a community
lead for Web and XML), so I really don't need a pointer to the cvs instructions.

My issue was allowing maven to run cvs within my cygwin environment. I've
used plenty of other maven based projects on java.net and never had these
kinds of problems. For some reason (that I haven't had time to debug), I
can not get the glassfish checkout step to work in cygwin. Are there any
other GF people using cygwin?

>> 5. Why does the build have to bootstrap itself with a glassfish image?
>
> This is to build standalone module, and not require to know or build any
> dependent modules, so if you want to build tools, you can just checkout
> tools module and run "maven bootstrap build" from the glassfish/tools
> directory.. This was one of the objectives for GlassFish workspace.
>

If the image is only required to build specific modules in a standalone
fashion, then you should make the build script smart enough to download
the image only when it is needed.

Also, according to the NetBeans instructions, the glassfish image is also
required by the project settings (which I think is wrong, see issue 8).

>> Why does the build have to download a copy of Ant?
>
> To run Ant based build.xml script for building the workspace.
>

You missed my point. Look for ANT_HOME and use it instead of forcing me
to download a few more MB that I don't need. Please tell me that you
aren't using some customized version of Ant to build GF....

>> 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.
>
> This is nothing to do with any GlassFish issue!
>
> This hands-on lab is to attract more developers since the theme of this
> years JavaOne is JavaEE 5, also this lab covers more than just a
> GlassFish Build process, it spends about 20 mins on build and 40 mins on
> how to use, manage and develope/deploy using Netbeans. See the exercise
> agenda below.

Sorry, I didn't mean to pick on the lab. I think it is a valuable thing
to offer developers.

>
>> 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.

Anyone?

>> 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
>
> What currently we have is very close to your base case to make it more
> specific and flexibile
> % cvs co glassfish/bootstrap
> % cd glassfish/bootstrap
> % maven checkout bootstrap build configure-runtime
>

In case you didn't notice, I don't like the bootstrapping step ;8-)
And your list of instructions doesn't include setting any of the build
properties.

> simple developer usecase is as below, where particular developer is more
> concerned about one or few module build than the whole workspace.
> % maven -Dmodules=admin,tools checkout bootstrap build configure-runtime
>
> And this is all open for any users, so just submit the patch if you want
> to add your use-case in it.

Sorry, I don't follow what you're saying here.

Thanks,

--Ryan