That's a pretty valid summary of what's going on & how to setup things My only objection would be at the risk you mention when 'customizing' the folders in the pom... i've been using m2 for 2.5-3years now and i've never been bitten by that.
In fact, the most usual problem is IDE's lack of fine-grained classpath control (though that's getting better now as ide & their plugins mature). On Thu, Dec 18, 2008 at 6:09 PM, Luther Baker <[email protected]> wrote: > For what it is worth, the directory structure you are referring to is really > dictated by Maven and not Tapestry per-se. > > Normally, Maven build commands do not copy non-Java files from > 'src/main/java' into the resulting archive. Per Maven convention, non-Java > files that should end up in the classpath should be in 'src/main/resources'. > > But for example, Eclipse was not built around nor does it have to adhere to > Maven standards. As far as Tapestry is concerned, as long as the end result > is the same (Java and *.tml files have to be collocated in the classpath or > tml files belong in the web root) everything will work just fine. > Consequently, out of error, convenience or blatant disregard :-) different > developers place these SRC files in different places and configure their IDE > to create a proper end result - but per Maven conventions, to include text > (or non-Java) files in a resulting archive classpath, they should be kept in > the 'src/main/resources' path. > > There is one additional point here. As I've alluded to, Tapestry is built to > look in TWO places for *.tml files. a) the classpath and b) the web root. > Remember, this is the RESULTING location. If you are using a Maven build > process, these equate to a) 'src/main/resources' and b) 'src/main/webapp'. > > Much of the conversation in recent posts was around the best place to place > the *.tml files - ie: in the classpath or in the web application root. To > clarify, the jumpstart example you mention below is actually using the > CLASSPATH option but it is doing so contrary to Maven conventions. Remember > Tapestry cares only about the RESULTING location ... you are actually asking > about the SRC location. So again, if you like the approach that the > jumpstart example uses, and you alter your Maven build to include text files > from the java directory, you are fine ... > > Small project with no one else on it? Do what you like and just make sure > the final build is conistent with what Tapestry requires. Larger project, > developers added and removed, long running? You may want to adhere more > tightly to a stricter, conventional Maven structure (orthogonal to Tapestry) > and keep your *.tml files in the webapp root or the resources directory. > > If you have an automated build engine ... or continuous integration and you > want to run something like 'mvn install' from the command line over your > code ... convention would dictate that your *.tml files exist either in > 'src/main/resources' (claspath) or 'src/main/webapp' (web application root). > Putting text files in the 'src/main/java' directory is a > "play-at-your-own-risk" move - very doable - but not per Maven conventions > .... That said, you can customize your Maven pom.xml file --- but again, > that is generally frowned upon - especially when it comes to redefining > directories and files kept in custom paths. It adds complexity - you just > have to decide if it works for your org. > > Hope that helps - sorry for the long-windedness. I'm a big fan of Maven - > and convention over configuration ... but if you get confused separating > your *.tml files the corresponding *.java files - by all means - optimize > your workflow. Just be aware of the tradeoffs you are making with such > customizations. Remember to distinguish the SRC locations from the RESULTING > locations in the archive. Tapestry doesn't care about the SRC location. You > can put your *.tml files in /home/tmp if you like. It is the resulting > ARCHIVE or Eclipse IDE that has to include them in either a) the classpath > or b) the webroot. > > -Luther > > > On Thu, Dec 18, 2008 at 9:34 AM, Jonathan O'Connor <[email protected]>wrote: > >> Jonathan, >> yes, I used to be a big fan of spindle when I worked in Tap3, many moons >> ago! >> I'll grab it now. >> Ciao, >> Jonathan >> >> >> On 18/12/2008 15:15, Jonathan Barker wrote: >> >>> The Loom plugin for Eclipse (see link on the T5 main page) makes that >>> jumping around painless. >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Jonathan O'Connor [mailto:[email protected]] >>>> Sent: Thursday, December 18, 2008 08:16 >>>> To: [email protected] >>>> Subject: T5: Proper project layout? >>>> >>>> Hi, >>>> I've just started working with Tapestry 5, and I have found 2 different >>>> project layouts. Howard (I presume) suggested the one found in the >>>> guide: http://tapestry.apache.org/tapestry5/guide/project-layout.html >>>> and Geoff Callender has a different one in his jumpstart project. The >>>> main difference is that Geoff keeps the tml files in the same directory >>>> as the java classes. I prefer this as I don't need to jump about in the >>>> directory structure finding the matching Java or tml file. However, the >>>> guide explicitly says: >>>> "Component templates will always be stored in the resources folder." Is >>>> this documentation up to date? >>>> >>>> Thanks, >>>> Jonathan O'Connor >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > -- Andreas Andreou - [email protected] - http://blog.andyhot.gr Tapestry / Tacos developer Open Source / JEE Consulting --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
