Seems reasonable. So we could have src/conf/checkstyle, src/conf/xdoclet, src/conf/cactus, etc.?
How can we have this approach (or any suggested alternatives) considered for inclusion in the Maven conventions/best practices? On 5/22/05, Jeff Jensen <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
