Yes, exactly. To throw a curve, most of the time the tools are great with that arrangement, yet runtime config for frameworks such as Struts, Tiles, Spring, et al usually need them in the web content dir, such as WEB-INF/struts or just organizing files, like WEB-INF/tlds. Particularly, the IDE usually needs these files there to facilitate the code/test fast iterations.
So consider that in your dir arrangement too. Good question. I would like to discuss the structure and hope for changes with the Maven team, but my guess is they are quite down the M2 path already though, making that change difficult. I dislike some of the current dir arrangement for M2, but as long as we can specify the dirs in Maven configuration, the "default" structure becomes irrelevant. That said, Brett is very receptive to doc improvements. Perhaps create a page for the web docs of this info? -----Original Message----- From: Charles Daniels [mailto:[EMAIL PROTECTED] Sent: Monday, May 23, 2005 3:18 PM To: Maven Users List Subject: Re: Location of non-distributed resource files 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
