Not sure what this means
Once above AIs are experimented successfully, send proposal to
dev_at_glassfish to use ANT for GlassFish Workspace.
It seems that this is backwards. Shouldn't you ask for feedback on a
proposal before
you implement all this?
Carla
Dinesh Patil wrote:
> Kohsuke Kawaguchi wrote:
>
>> Dinesh Patil wrote:
>>
>>> Thanks Kohsuke,
>>> I believe glassfish directory structure is not complex to get
>>> familiar :-) ,
>>
> I thought you said glassfish *directory* structure and not the build
> structure.. but that too is not so complex looking at the requirements
> we are trying to address from previous one..
> We already have the meetings and discussion on GlassFish workspace,
> and here is the summary of it.
> https://glassfish.dev.java.net/javaee5/build/BuildSystemStatus.html
>
> * 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.
> * We are not using Maven features and don't need to use those as
> Ant provides good build infrastructure to GlassFish.
> * So we will do dry run on using Ant for downloading binary
> dependencies, and all build commands (similar to what currently
> we are using for checkout, bootstrap, bootstrap-all, build,
> configure-runtime etc)
> * *=>This is done, i checked in the changes already.. Proxy
> settings need to be resolved..*
> * Use common "classes" directory like
> ${glassfish.root}/publish/classes to compile all the classes and
> run assemble target once from top-level module (like glassfish,
> appserv, appserv-ee) to save time on updating jar files repeatedly.
> *=>this won't happen since Kedar specified that there is issue
> with current classloader issue*
> * Try NetBeans to build GlassFish out-of-the-box.
> * Once above AIs are experimented successfully, send proposal to
> dev_at_glassfish to use ANT for GlassFish Workspace.
>
> We are open for more suggestions, and patches, and I believe you
> volunteered for one of the patches for variable substitution :-)
> for glassfish.os.name and glassfish.cvs.username, but never got it. ;-)
> thanks
> Dinesh
>
>> I've been saying this, but I'll say it again.
>>
>> Glassfish is very very hard to build. It's so hard that it takes a
>> hands-on-lab to explain. It's almost to the point that it's crazy.
>> I'm sure Glassfish is great in many ways, but its build system is not
>> one of them.
>>
>> Granted, it's probably because of historical reasons that I don't
>> know, and I certainly understand if you are saying we can't just
>> change them at this point, but I hope people still realize that it's
>> far from "not complex to get familiar with".
>>
>> I saw so many wrong things I don't know where to start, but just to
>> give you a few ideas...
>>
>> - It uses both Maven and Ant, when one would have been suffice. It
>> requires people to be familiar with both for no reason. Build
>> scripts need to bend over backward to bridge them together.
>>
>> - It uses Maven but it doesn't follow any Maven convention. For example,
>> none of the POMs list the proper dependency, not even in
>> the bootstrap module. It got all sorts of non-standard targets, and
>> none of the usual Maven goals seem to work.
>>
>> So the net result is not only do people need to be familiar with Maven
>> and Ant, but they also need to be familiar with a particular way
>> Glassfish uses them.
>>
>> If it were following Maven conventions, I didn't have to do anything
>> to push jars to the repository. All you needed to do was
>> "maven javanet:deploy-jar"
>>
>> And didn't you guys decided to stop using Maven some time back?
>>
>> - The root glassfish directory doesn't have neither build.xml nor
>> project.xml. That' the first place people look at. When there are
>> 30+ modules there, how are people supposed to know that "bootstrap"
>> is the key?
>>
>> - I never understood why it needs to download Glassfish when it's
>> supposed to be building one.
>>
>> I can go on and on ...
>>
>