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]
