Dinesh,
I have my own personal computer that I never do any AS stuff on. I am
going to become a guinea pig -- pretend I know nothing (not hard!) --
and build glassfish using the instructions at the website. I'll report
back on my experiences.
Abhijit - I'm counting this as part of the 20%
Dinesh Patil wrote:
> 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 here.
> https://glassfish.dev.java.net/public/BuildGlassFish.html#maven_goals
>
>>>> 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.
>>>
>> 4. The entire idea of the bootstrapping step seems to complicate the
>>
>> 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
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>