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)
>
> 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.
>
> 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
* not building huge jars like appserv-rt.jar
* 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! :)
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
>