Nice analysis. I have some further thoughts for you to consider on the build time resources, e.g. the conf dir location.
For a given product, there are the source files and the build files. Every file falls into one or the other category (can anyone disprove that assertion? :-) Source files are those files that require manual creation vs generated from a tool (e.g. compiler, xdoclet, javadoc, etc.). Also, all source files belong under source control. Therefore, make the top two directories reflect this, e.g. src and target or src and build. Under the src dir, organize the source files. Since the config files in question (both runtime and build ones) are original vs generated, the config dir(s) belong in src. Also, keeping every source file under one dir makes source control tool interactions much cleaner/easier, keeping generated files completely separate. It gives confidence to "clean". -----Original Message----- From: Charles Daniels [mailto:[EMAIL PROTECTED] Sent: Sunday, May 22, 2005 8:16 PM To: Maven Users List Subject: Re: Location of non-distributed resource files It looks like we have 2 types of resources: (a) those that are used during the build process, and (b) those that are used during runtime. Those that are used at runtime are further classified as either "main" or "test" resources. According to existing Maven conventions, it appears that the latter type (runtime) are organized within the src/main/resources and src/test/resources directories, for main and test resources, respectively. My original question refers to the former type of resources (buildtime) and there are some good suggestions for organizing them. I am leaning towards Jeff Jensen's most recent suggestion to use src/conf/<tool>, where <tool> may be the tool name, such as checkstyle or xdoclet. This goes along with Brett's original suggestion of using the tool or plugin name as the name of the subdirectory. At first glance, I preferred the use of src/main/xdoclet (as Brett suggested) over the use of src/conf/xdoclet (as Jeff suggested) since the src/conf directory has seem to have gone by the wayside. However, that may only be because the use of src/conf appears to never have been clearly defined. However, there is one problem I see with taking Brett's approach of using src/main/xdoclet. The problem is that buildtime testing resources should then be placed under src/test/<plugin> and this seems to cause at least one conflict that I can see. The particular case I have in mind here is the use of the cactus web.xml file that cactus uses to merge into a final web.xml file during the cactifywar task. According to convention (at least the convention I understand to exist and which I am following), sources for cactus tests should exist under src/test/cactus. If we also adhere to the convention implied by Brett's suggestion, my cactus-web.xml file should also exist under src/test/cactus. I would think we wouldn't want such a file at the root of our cactus test code. Rather, it would seem we might want to put cactus-web.xml under src/conf/cactus. Further, perhaps there is no need to separate "main" and "test" buildtime resources, since the use of the tool or plugin name provides the proper distinction. Since the resources are used only at buildtime, there is no need to keep parallel "main" and "test" structures. Taking this a step further, do we even need to keep such buildtime resources under the src directory? It seems to me that these resources warrant a new top-level directory, perhaps making conf top-level? If so, then we might want to consider conf/<tool> as the directory convention for buildtime resources. This might lead to directories, such as conf/checkstyle, conf/xdoclet, conf/cactus, etc. Thoughts? Cheers, Chuck On 5/21/05, Jeff Jensen <[EMAIL PROTECTED]> wrote: > I have a typical structure of a "src/conf/", with subdirectories > containing the respective area/tool's files. E.g. src/conf/checkstyle. > > This provides for clear "where are the config files", yet easy to > select the ones for distribution. And also moving to a different > location in the build as necessary. E.g. Struts wants resource bundles on the classpath. > > I consider xdocs not config info, but content. So "src/xdoc". Also > have a "src/doc" for documentation. This can include > "src/doc/javadoc" for overview.html. > > Everything that is an original file for the product goes under the src dir. > All of the src dir goes into source control. Everything else that is > a generated file goes under the target dir at build time. Usually, > project management files are not under src, but in their own > "projectdocs" dir at the same level. > > Of course, the "src/java" and "src/test" are present too. > > > I am finding I prefer much of the Maven 1 dir structure. With "src" > and "target", it was similar to all my prior Ant setups. > > Particularly, "main" has been used for a long time in release > management as the "main" codeline when using "named codelines". So > "src/main" is an inverse to me...instead following: "productname/codeline/src". E.g.: > myproduct/main/src > myproduct/1.0/src > myproduct/2.0/src > > This provides for a reproducible build of a product version that > includes the documentation - often overlooked as a versioning need too. > > > As long as tools like Maven allow property configuration of > directories, adoption of them is easier and flexible to match product organization needs. > > And I agree and like having a default "expected" product organization. > > > -----Original Message----- > From: Nicolas Chalumeau [mailto:[EMAIL PROTECTED] > Sent: Saturday, May 21, 2005 8:55 AM > To: Maven Users List > Subject: Re: Location of non-distributed resource files > > Very Interresting discution. > > In fact I'm having same problem. I think they are multiple resources > file nature (like the dependancies) : > 1/ Plugin resources (xdocs, checkstyle definition) : here they are > every thing ie ./checkstyle.xml, $HOME/.maven/..., /xdocs (I like the > m2 approach : xdocs under the src dir) 2/ Runtime resources : xdoclet > velocity redefinition for example... > 3/ Resource to include in the classpath : I use /src/resources/ojb, > /src/resources/spring... to categorise them by nature. I like this way > in M1 but I don't find how to do it in M2 (in fact I don't search) 4/ > Resource to include in a specific dir : web resource like generate > struts-config.xml, deployment files, .bat or .sh script to start an application... > 5/ And of course tests resource that can be all the type before. > > I really think there is a need of convention here. In my case I use > the /src/main/resources for the 1/ (not allways like for checkstyle), > 2/, 3/,4/... I don't like it : the resources nature is too differant > but I am probably to strict with directory layout of a project ;-) > > I'd like to have the other feelling about this... > > Nicolas > > On 5/21/05, Brett Porter <[EMAIL PROTECTED]> wrote: > > I do remember seeing it and forgetting to answer :) > > > > Personally, I would opt for "src/main/xdoclet" in this case (ie, > > src/main/plugin-name). > > > > Anyone else have any thoughts? I think this would be a good thing to > > include in the standards. > > > > - Brett > > > > On 5/21/05, Charles Daniels <[EMAIL PROTECTED]> wrote: > > > Hi All, > > > > > > I thought I posted this question to the list a couple of days ago, > > > but I haven't seen it appear anywhere, so I am resending. Please > > > forgive me if this is a duplicate posting. > > > > > > I'm following the latest conventions for project layout and I am > > > wondering if there is a convention for separating resources based > > > on whether or not they are to be distributed/deployed. > > > > > > For example, if I understand the convention correctly, files such > > > as properties files that are to be included in a jar file should > > > reside under src/main/resources (perhaps with the appropriate > > > package directory structure). > > > > > > However, what about other "resources" that are NOT to be included > > > in the distribution. Are such "resources" also supposed to be > > > placed under src/main/resources? > > > > > > For example, I am using the xdoclet plugin to generate my web.xml > > > file. The plugin allows me to specify files to be merged into the > > > resulting web.xml file. One example is servlets.xml, where I can > > > specify third-party servlets to list in web.xml in addition to the > > > servlets from my own code base. Obviously servlets.xml is used by > > > the xdoclet plugin only for generating web.xml and servlets.xml > > > will never be distributed. Therefore, would I still put > > > servlets.xml somewhere under src/main/resources (perhaps under > > > src/main/resources/xdoclet), or is there a better place for such > resources? > > > > > > Thanks, > > > Chuck > > > > > > ------------------------------------------------------------------ > > > -- > > > - 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] > > > --------------------------------------------------------------------- > 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]
