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?
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....
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?
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?
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
>