Wayne,
Thanks for the details on M2 and willingness to help on GlassFish build
structure, we earlier tried M2 with GlassFish Workspace, I have checked
in pom.xml files for activation, mail, deployment-api, transaction-api
modules, so you can try these modules. For simpler modules, this works
ok. But when the submodules or complex module structure comes, we have
to write plugins, e.g. if we have to update javaee.jar from
${glassfish.home}/lib, I couldn't find existing plugin. We have RMIC in
appserv-commons, appserv-core modules, I couldn't find the plugin..
We cannot change our current ${glassfish.home} directory structure, so
we do some post-bootstrapping in glassfish/bootstrap/glassfish.xml to
initialize and add content to the jar files, that need to be taken care.
That's the customization and complexity I am referring to. You can take
a look at the constraint section of the workspace document here:
https://glassfish.dev.java.net/javaee5/build/BuildSystemStatus.html#constraints
for more justification why we do this way.
I have checked in the changes in workspace to build using Ant tool only
for Netbeans/Eclipse IDE developer usage, this doesn't affect current
maven build system. We can work on Trunk for parallel M2 migration, as
that too will not affect the current build system. So if developers can
help us on M2 migration on some complex modules say admin, appserv-core
we can start on this right away.
We have discussed these 4 options earlier, so if you have any comments,
suggestions, please send it to us.
https://glassfish.dev.java.net/javaee5/build/BuildSystemStatus.html#objectives
* Migrate this to Maven 2, without any ant scripts.
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. Following migration path to m2:
o Build all glassfish modules with m2, abstracting common
dependencies, etc. into a "base" project, letting the
modules inherit from that
o Assembling the appserver library out of module jars
previously build, and then build the glassfish image.
* 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.
o 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
thanks
Dinesh
Wayne Fay wrote:
> More unsolicited opinions from a non-Sun guy...
>
> I'm happy to help with Maven (esp M2) efforts if you decide to go in
> that direction. I've actually already written some M2 pom.xml files
> for transaction-api and persistence-api, and contributed a b32g build
> of the glassfish-persistence-api module to the Maven2 ibiblio
> repository. If you're using Maven2, you can start using this
> dependency in your own projects by including:
>
> <dependency>
> <groupId>net.java.dev.glassfish</groupId>
> <artifactId>glassfish-persistence-api</artifactId>
> <version>b32g</version>
> </dependency>
>
> Both sources and binaries were uploaded, as you can see here
> http://www.ibiblio.org/maven2/net/java/dev/glassfish/glassfish-persistence-api/b32g/.
>
> I also created a transaction-api module but something went wrong
> during the construction of the jar and so its not currently usable.
> When I find a few free moments, I'll have to fix and upload a proper
> build. It would be ideal however if the Glassfish project would "take
> over" the creation and management of these poms, as you are in a
> better place to manage dependencies and builds etc than I am.
>
> I've been a semi-active user of M1 and very active user of M2 for some
> time now. I personally agree with Ed that "the world is a better
> place" when projects are built using Maven2, standardized directory
> layouts and consistent build structures are a joy coming from
> Ant-hell. I'm not saying Ant is a bad system, I just find that every
> project is using Ant in some custom manner, and files are haphazardly
> thrown here and there, and dependencies are either unclear or
> incomplete, etc.
>
> Not sure if you're moving TOWARDS Maven and away from Ant or vice
> versa or neither... But once you get that decided, let the rest of the
> world know and you'll probably get some help you might not have been
> expecting. ;-)
>
> Wayne
>
> On 5/3/06, Ed Burns <ed.burns_at_sun.com> wrote:
>
>> >>>>> On Wed, 03 May 2006 06:49:13 -0700, Jerome Dochez
>> <Jerome.Dochez_at_Sun.COM> said:
>>
>> JD> Dinesh Patil wrote:
>> >> 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?
>> JD> Hi Dinesh
>>
>> JD> Can you list the benefits of keeping maven over the complete ANT
>> based
>> JD> solution you experimented ?
>>
>> Here's my unsolicited opinion on this. I've been using maven 2 on the
>> jsf-extensions project and I've come to like it a lot. As Kohsuke
>> pointed out, the glassfish build system is hard to learn. The main
>> value-proposition of maven is its *standardized* directory layout and
>> build structure. When I move from one maven project to another, I
>> *know* how it works.
>>
>> The more of the world we can move to maven2 the easier it will be for
>> people to get productive when coming to a new project. That's what we
>> want for glassfish.
>>
>> Ed
>>
>> --
>> | ed.burns_at_sun.com | {home: 407 869 9587, office: 408 884 9519 OR
>> x31640}
>> | homepage: | http://purl.oclc.org/NET/edburns/
>> | aim: edburns0sunw | iim: ed.burns_at_sun.com
>> | 08 Business Days until JavaOne SF 2006
>>
>> ---------------------------------------------------------------------
>> 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
>