Ryan Shoemaker - JavaSoft East wrote:
> 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.
Yes its updated.
https://glassfish.dev.java.net/public/BuildGlassFish.html#maven_goals
> 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.
most of this related to our post-bootstrap step and you can see the
contraints here.
https://glassfish.dev.java.net/javaee5/build/BuildSystemStatus.html#constraints
As i said we need this bootstrapping for standalone modules, and
resolves the compile/runtime dependency for all the modules.
> 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?
We don't have any cygwin or MKS toolkit dependency, so you can just
remove it from the PATH variable, I don't know this.
>>> 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.
this is the easy way we tried, you are welcomed to bring any smart
ideas/patches.
> Also, according to the NetBeans instructions, the glassfish image is also
> required by the project settings (which I think is wrong, see issue 8).
yes this is true to resolve all compile/runtime dependencies.
>
>>> 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....
Actually Ant is already present and required by some runtime scripts
from ${glassfish.home}/bin, and referred from asant.*, and it was always
present in sun appserver bundles, so we are just using it from there to
avoid user to set one more variable ANT_HOME or require another ant
installation.. there is no customized version 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.
>>
>>
>> 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.
GlassFish Open source: Use it, Improve it by participating.
thanks
Dinesh
>
> Thanks,
>
> --Ryan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>