Message-ID: <1804644213.2111.1369281725640.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_2110_754299827.1369281725640" ------=_Part_2110_754299827.1369281725640 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
I would like to advocate a perhaps philosophical approach to the general= best practices of maven2 projects.
There are basically two approaches that we have available to us in givin= g meaning to project layout that can be used in some combi= nation.
1) nesting into directories
2) naming directories
IMO, one of the strongest themes that maven2 presents is the small discr= etely compiled/prepared artifacts centralized through various repositories.= Whereas other build systems like make and ant leverage directory structur= e in the organizing of source and compiled dependencies, and then backu= p a directory and bundle the subdirectories into some new shared libra= ry/jar/j2ee artifact, maven2 treats all of these artifacts as logical equal= s, all woven together via the repository.
With the existing rule of thumb that one project produces one artifact, = all we would really be accomplishing by formalizing some specific j2ee proj= ect structure is choosing a layout where independent artifact generating su= bprojects would be mounted...and what does doing that exercise really give = us?
If I could crawl into the minds of Jason, Brett and folks I think I woul= d see that this idea of nesting directories to give an implied meaning/purp= ose to subprojects was a factor in the layout.
The layout of maven-components is very flat, the maven-project, maven-mo= del, maven-plugin-api, maven-profile projects are all given implict equal s= tanding by existing at the same top lvl directory. Even though things like= maven-profile could logically be nested inside of maven-project, it is rea= lly only a artifact dependency to maven-project so it doesn't need to be ne= sted below maven-project..just as a dependency.
So that leaves me with the following as a general rule of thumb when org= anizing a maven2 based project.
For a simple project like this, there is no need to venture into lots of= convoluted subdirectories.
However, if you have 5 or more servlets, nest them in a servlets directo= ry.
and the same thing would hold for the ejbs, wars, ears, whatever...the o= nly exception being artifacts that compile to be jars...then would all exis= t at the root of the project directory unless it really makes sense to nest= components that have maybe 5 or more of a particular thing.
Following an approach like this there is no need to really dig into spec= ialized archetypes for meta level project layouts. The archetype system we= currently have in place is for project layouts based around the type of ar= tifact that will be generated. They give people a template to work off o= f for making an artifact work with their build.
Instead of trying to identify some meta project layout that weaves these= artifacts together, we can continue fleshing out artifacts based around di= fferent types of plugins, even mojo plugins, like the wsdl2java and sablecc= plugins. All of these archetypes are basically used at the root of projec= t and we just follow the bulleted rules above for naming conventions and ne= sting.------=_Part_2110_754299827.1369281725640--