You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Charles Daniels <cj...@gmail.com> on 2005/05/21 01:07:54 UTC
Location of non-distributed resource files
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Location of non-distributed resource files
Posted by Jeff Jensen <je...@nospam.visi.com>.
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:cjdaniels4@gmail.com]
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 <je...@nospam.visi.com> 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:cjdaniels4@gmail.com]
> 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 <je...@nospam.visi.com> 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:nicolas.chalumeau@gmail.com]
> > 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 <br...@gmail.com> 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 <cj...@gmail.com> 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: users-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: users-help@maven.apache.org
> > > >
> > > >
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Location of non-distributed resource files
Posted by Charles Daniels <cj...@gmail.com>.
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 <je...@nospam.visi.com> 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:cjdaniels4@gmail.com]
> 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 <je...@nospam.visi.com> 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:nicolas.chalumeau@gmail.com]
> > 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 <br...@gmail.com> 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 <cj...@gmail.com> 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: users-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: users-help@maven.apache.org
> > > >
> > > >
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Location of non-distributed resource files
Posted by Jeff Jensen <je...@nospam.visi.com>.
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:cjdaniels4@gmail.com]
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 <je...@nospam.visi.com> 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:nicolas.chalumeau@gmail.com]
> 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 <br...@gmail.com> 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 <cj...@gmail.com> 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: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Location of non-distributed resource files
Posted by Charles Daniels <cj...@gmail.com>.
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 <je...@nospam.visi.com> 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:nicolas.chalumeau@gmail.com]
> 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 <br...@gmail.com> 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 <cj...@gmail.com> 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: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Location of non-distributed resource files
Posted by Jeff Jensen <je...@nospam.visi.com>.
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:nicolas.chalumeau@gmail.com]
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 <br...@gmail.com> 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 <cj...@gmail.com> 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: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Location of non-distributed resource files
Posted by Nicolas Chalumeau <ni...@gmail.com>.
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 <br...@gmail.com> 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 <cj...@gmail.com> 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: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Location of non-distributed resource files
Posted by Brett Porter <br...@gmail.com>.
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 <cj...@gmail.com> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org