Carla Mott wrote:
> Not sure what this means
>
> Once above AIs are experimented successfully, send proposal to
> dev_at_glassfish to use ANT for GlassFish Workspace.
Since we have experimented Ant for GlassFish Workspace (if that doesn't
work, there is no question we need to keep things as it is), we now know
that most of the commands work with Ant also, then we can ask for
feedback and inputs that should we go back to Ant or keep maven for the
benefits its bringing to current workspace?
thanks
Dinesh
>
> 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 ...
>>>
>>
>