Hi Markus,
Markus Fuchs wrote:
> Hi Qingqing,
>
>> Hi, Markus:
>>
>> I was under the impression that we are discussing how to make 1) and
>> 2) simpler. But it sounds like your objective is only to support
>> senario 3). Is that right?
>
>
> Not exactly. I strongly believe we will improve 1) and 2) by
> addressing 3)
1) building the glassfish image from scratch, as done in the nightly build
2) building a glassfish module against an existing glassfish image
3) building a glassfish module against it's dependencies only, for example
We have first 2 cases done very easily with current build system even if
its Maven-ant combination but its not adding any overhead other than not
using all Maven features, which we didn't need anyway (ant is doing
great job already).
But we need to address this, and currently evaluating the Maven 2
migration which we will have to create a branch and start exploring. We
will need help from all active developers and module owners for this if
we plan to go that route.
But what's the use of case 3), who will want to use this? and even if we
are able to get this, what's the use of output of this build?
Just with entity-persistence.jar or admin-core.jar, how we are going to
use these jars? we need the server image anyway to verify and test the
changes, isn't it?
>> Even with only supporting senario 3), I think you should propose
>> something more concrete first. For example, say what you want to do
>> is build entity-persistence module only. Then the steps in your mind
>> are:
>>
>> % cvs -d $JAVANET_CVSROOT checkout entity-persistences
>> % cd entity-persistence
>> % maven bootstrap build
>>
>> The "bootstrap" will pull blah blah binary and "build" will do so and
>> so....
>
>
> This would be done by defining dependencies in maven, so no extra
> bootstrap necessary.
But for that you will have to build those dependent modules anyway,
consider building appserv-core with your step 3, you will have to build
almost all modules before to get this module build. Command will look
like below:
% mvn -Dmodules=activation,mail,*-api,admin* install
This will create say appserv-rt.jar along with couple of other jars,
which need to be copied into glassfish server image to test.
>> I was expecting to see something like the above. In addition, it
>> would be good to take into the account the limitations you are
>> willing (or not willing) to live with. For example, should building
>> of entity-persistence be consistent with the rest of the appserver
>> modules?
>
>
>
>> Is it even part of the appserver build? Does it have the concern of
>> deliverying binaries to different products?
>
>
> Thew answer to all three questions is definitely yes. I chose
> entity-persistence as an example, because I'm most familiar with this
> module.
>
>>
>> If you prefer not to follow the appserver build, then obviously you
>> will have to either do something on your own in the
>> entity-persistence or you will have to modify the appserver build
>> itself, at which point this discussion could turn into a whole other
>> beast.
>
>
>>
>> Again, what exactly is it that you would like to achieve? What is
>> the main goal?
>>
> My incentive is to simplify our build process, and I believe the best
> way doing this would be:
>
> * migrating to m2
we need to weigh this looking at the time/effort with correct build
system, so will have answer to this soon.
> * not building huge jars like appserv-rt.jar
yes we have discussed this earlier along with JF's proposal, so we need
to address this first to make module dependencies clear. We can start
working on this with the current build structure on a separate branch as
above.
> * migrating from CVS to subversion
> *And*: The situation we have is a already a great improvement compared
> to the previous build structure using gmake, using common libraries
> from an NFS share! :)
ok thanks for feedback, so its getting better :-) .
We need to identify and resolves most critical issues that is affecting
everyone, so Developers feedback will be really helpful to know.
thanks
Dinesh
> Thanks,
>
> -- markus.
>
>> Thanks,
>> Q^2
>>
>> Markus Fuchs wrote:
>>
>>> Hi Q^2,
>>>
>>> this is a very good point. I'm aware about the following scenarios:
>>>
>>> 1) building the glassfish image from scratch, as done in the nightly
>>> build
>>> 2) building a glassfish module against an existing glassfish image
>>> 3) building a glassfish module against it's dependencies only, for
>>> example
>>>
>>> The "entity-persistence" module has the following dependencies:
>>>
>>> - antlr, asm, javaee.jar
>>>
>>> antlr and asm are third party libraries, javaee.jar is composed from
>>> other glassfish modules.
>>>
>>> Where 1 + 2 are supported right now, I guess 3 is not, i.e. it would
>>> mean getting the third party libraries, and then building javaee.jar
>>> out of the appropriate components.
>>>
>>> As a second, maybe related point, entity-persistence compiles
>>> against javaee.jar, which is again assembles several glassfish
>>> modules. It should be compiled against exact those modules, and not
>>> using javaee.jar.
>>>
>>> Building against the glassfish image makes it impossible to build a
>>> module against it's dependencies only, as the library jar in the
>>> glassfish images often combines target and dependencies into a
>>> single jar.
>>>
>>> Hoping that I can open the discussion by this.
>>>
>>> Thanks,
>>>
>>> -- markus.
>>>
>>>
>>>
>>> Qingqing Ouyang wrote:
>>>
>>>>
>>>> Hi, Markus:
>>>>
>>>> I am all for making the glassfish build easier to use. However, I
>>>> don't think the first question should be "ant" or "maven".
>>>> Shouldn't we decide on the user senarios first?
>>>> What does it mean by "easy to build"? What exactly should the users
>>>> configure and do when they want to build glassfish? What exactly
>>>> should they do after they modify something?
>>>>
>>>> Depending on what the answers are, we could then decide if ant or
>>>> maven is better for the job. Again, it would be better if we
>>>> discuss the objectives and user senarios to begin with?
>>>>
>>>> Thanks,
>>>> Q^2
>>>>
>>>> Markus Fuchs wrote:
>>>>
>>>>> The glassfish workspace is currently build using maven 1.0.2 and
>>>>> ant 1.6.5. We are discussing how to simplify this build structure.
>>>>> There has been some discussion already, and I'm trying to
>>>>> summarize it here.
>>>>>
>>>>> To make it easier, we need to decide if we want to go with a pure
>>>>> ANT build or move to Maven 2.0 (or stay with Maven 1.x but use
>>>>> Maven as it should). Right now we aren't using Maven the way it
>>>>> should, as Maven under the hood calls Ant. The workspace is quite
>>>>> complex, and moving all build.xml to Maven might take a lot of time.
>>>>>
>>>>> Having a pure Ant or Maven build will make it easier to build. We
>>>>> just need to decide which one we want to use, not both like it is
>>>>> right now. But our workspace will always be more difficult to
>>>>> build than other workspace because Glassfish isn't shipping all
>>>>> the source code. We always need to "bootstrap" binaries, which
>>>>> complicate the process.
>>>>>
>>>>> I see following options:
>>>>>
>>>>> 1) Migrate this to m2, w/o any ant scripts. I did some
>>>>> experiments, and can build some glassfish modules with m2.
>>>>>
>>>>> m2 is entirely independent from maven 1x, it doesn't use any of
>>>>> maven 1's configuration files. So we can migrate to m2 w/o
>>>>> scarifying the working maven 1 build. I suggest following
>>>>> migration path to m2:
>>>>>
>>>>> * build all glassfish modules with m2, abstracting common
>>>>> dependencies, etc. into a "base" project, letting the modules
>>>>> inherit from that
>>>>> * assembling the appserver library out of module jars previously
>>>>> build, and then build the glassfish image.
>>>>>
>>>>> 2) If we're not using all/some of the Maven 2.0 features, like
>>>>> install/docs/build/jars etc, Ant is an easier/cleaner solution.
>>>>> This can easily be driven by Netbeans/Eclipse without any plug in
>>>>> to download.
>>>>>
>>>>> 3) Use the Maven 2.0 Ant task, which can be downloaded from:
>>>>>
>>>>> http://www.apache.org/dyn/closer.cgi/maven/binaries/maven-artifact-ant-2.0.2-dep.jar
>>>>>
>>>>>
>>>>> 4) Migrate from maven 1.0.2 to maven 1.1. Continue either with the
>>>>> current mixed maven/ant approach , or replace ant by using maven.
>>>>>
>>>>> We're eagerly looking for your input. Please supply your
>>>>> experience and suggestions!
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -- markus.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>