[ajug-members] Java EE default project layout

Chinmay Nagarkar chinmay.nagarkar at gmail.com
Sun Feb 5 12:35:32 EST 2006


Les,

I'm not an expert on Maven, but from what I've seen, I agree with you about
Maven's perceived weaknesses. We use a modular build structure similar to
what you described (our readme.txt reads much like your article). It's
intuitive to developers who have worked with ant extensively, and it's easy
to delegate modules in the CVS tree to different teams without conflict.

But then it's also true that you can't teach an old dog new tricks. :)



-----Original Message-----
From: ajug-members-bounces at ajug.org [mailto:ajug-members-bounces at ajug.org]
On Behalf Of Les A. Hazlewood
Sent: Sunday, February 05, 2006 12:11 PM
To: ajug-members at ajug.org
Subject: Re: [ajug-members] Java EE default project layout


The following is in no way discrediting Maven as a viable build
solution.  I think its best to use the build solution that you feel
works best for you.

My .02:

I've wanted to use Maven since it was born.  Unfortunately, my article
was actually a *response* to why Maven doesn't suit my needs.  

I actually think the Maven guys are doing a great thing, but it
seriously rubs me the wrong way in a couple of areas.  I've revisited
Maven often over its lifetime to see if has fixed these issues, and it
hasn't.  Here are my 2 major gripes:

1.  Its very cumbersome to do things in your build environment if you
don't do things the Maven Way.  Every project has custom quirks, and
maven actually makes it more difficult to implement those things
yourself.  Ant doesn't limit me. (maybe thats better in Maven 2.0, but
I've yet to see it)

2.  The maven directory structure, really the core of this entire
thread, drives me crazy ;)  I want my build environment to have a
modular structure, where the directory tree itself reflects the
modularity of the software.  I cover that a lot in the article, but
here's why I really like my alternative environment:

A build module, and the software module it represents, is a wholly
self-contained unit with everything it needs.  If you want to delete a
module, just delete the ${project root}/${module name} directory.  No
fishing or searching through multiple etc, src and test trees to clean
up your environment.  Even if you don't delete a module, its very
intuitive to know that everything a ${project root}/${module name}
module needs is in that directory or below it.

This also reads much cleaner to me:

> cd $PROJECT_ROOT
> ant create-web-module

rather than

> cd $PROJECT_ROOT
> mvn archetype:create -DarchetypeArtifactId=maven-archetype-webapp

Also, if you want to build a module or submodule, just change into that
directory:

> cd $PROJECT_ROOT/<modulename>
> ant

Thats really, really easy and intuitive.

Its those little things, compounded numerous times, that really make an
environment feel clean and useful.

I've received a lot of responses from people who have used Maven and
then tried the build environment I describe, and they tell me that there
is some inherent intuitiveness about what I describe versus what Maven
does.  It just "feels cleaner" to most.

I guess ultimately, if Maven used the directory structure I really
require, I'd use it in a heartbeat.  But it doesn't, so I created
something that, imo, is cleaner, more intuitive, and ultra-light in
comparison.

To avoid the possibility of a flame war which would be pointless and
counter-productive, I won't say anything else related to comparing the
two. ;)

Cheers,

Les


On Sun, 5 Feb 2006 09:57:43 -0500, "Gunnar Hillert" <gunnar at hillert.com>
said:
> Hi,
> 
>  
> 
> I agree with the previous posts - I started using Maven2 late last year
> and I really like working with their project layouts, which are generated
> for you through Maven's archetypes. It takes away most of the burden when
> dealing with your project's basic "plumbing" - not just for your
> project's file structure but also for your whole build and deploy
> process. Additionally, for my class structure I try to adapt to what the
> Equinox/Appfuse OSS projects are using. I would also recommend looking at
> those 2 projects if you are required to go with Ant.
> (https://appfuse.dev.java.net/ and https://equinox.dev.java.net/).
> 
>  
> 
> Regards,
> 
>  
> 
> Gunnar 
> 
> 
> 
> 
> 
> 
> ----- Original Message ----- 
>   From: davewible 
>   To: General AJUG membership forum (100-200 messages/month) 
>   Sent: Sunday, February 05, 2006 8:34 AM
>   Subject: Re: [ajug-members] Java EE default project layout
> 
> 
>   I think what you are asking is what maven's trying to solve.  In the
>   Msft world you create a new project(exe or dll) for example and then
>   tell VS to make.  It's done and you don't worry about the structure if
>   I remember correctly.  
> 
>   Your question about the project structure is simplifying the overall
>   problem b/c you are not writing this EAR in isolation, my guess.
> 
>   1 Maven has the idea of an archetype (jar, war, ear). mvn
>   archetype:create -DarchetypeArtifactId=maven-archetype-webapp 
>   2 From this you get a project structure, dirs
>   src/main/java|resoureces|etc and a test dir as well
>   3 You also have to work through dependencies - transitive or
>   intraproject
>   4 How do you share or publish your work?  A repository is maven's
>   solution.
>   5 from #4, what do you share meaning each build is unique so you have
>   the concept of a "snapshot".
>   6 continuous integration of your code with others - Green light.
> 
>   All this stuff is built on b/c just getting a structure and compiling
>   is not enough, right?
> 
>   This is not a commercial for Maven but telling you what I think the
>   maven guys are trying to do.  I've worked maven 1.0.2 and it's hell,
>   powerful and undocumented for the most part.  m2 seems better and I'm
>   sure m3 will be better on top of that.  Otherwise if you use Ant then
>   you tell ant where the project home is and relative to that where it
>   can find everything and put the compiled classes or to use weblogic's
>   ejbgen, etc.  Or use Les' suggestion.
> 
>   david
>     ----- Original Message ----- 
>     From: Burr Sutter 
>     To: ajug-members at ajug.org 
>     Sent: Saturday, February 04, 2006 11:41 PM
>     Subject: [ajug-members] Java EE default project layout
> 
> 
>     Hello AJUGers,
> 
>     I have a question and I'm hoping that ya'll either have some answers
>     or can at least validate my thinking.   
> 
>     Let's say that I am new to Java EE development and I've been looking
>     at books and tutorials and they have instructed me on how to build
>     the EAR and WAR directory.   What is the proper way to layout the
>     project directory structure (src, bin, WEB-INF, webcontent/docroot,
>     classes, lib, etc.) and are there any default Ant scripts for
>     managing my WARs and EARs?  
> 
>     I've looked at a number of different documents, tutorials, etc. over
>     the last  week and almost all of them have a unique approach. I'm
>     looking for "the way" to setup my project so that my source files
>     don't live in the same directory as my class files and that a
>     deployable WAR structure (and EAR) can easily be created. 
> 
>     What do you think?
> 
>     And should this be something addressed by a JSR within the JCP? 
>     Would it be nice to a default project/build environment for training
>     new developers or if you move from project to project have the same
>     basic "layout"? 
> 
> 
>     Burr
> 
> 
>
----------------------------------------------------------------------------
> 
> 
>     _______________________________________________
>     ajug-members mailing list
>     ajug-members at ajug.org
>     http://www.ajug.org/mailman/listinfo/ajug-members
> 
> 
> 
>
----------------------------------------------------------------------------
--
> 
> 
>   _______________________________________________
>   ajug-members mailing list
>   ajug-members at ajug.org
>   http://www.ajug.org/mailman/listinfo/ajug-members
_______________________________________________
ajug-members mailing list
ajug-members at ajug.org
http://www.ajug.org/mailman/listinfo/ajug-members




More information about the ajug-members mailing list