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
>