Hi,
Thanks for the answer. It's a bit more clear now.
May be, it would be nice to update online documentation
http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
I googled a lot to get such information without any success even if i found
this question a lot of times.
Jean-Louis
Chris Helck wrote:
>
> Here's my understanding...
>
> In maven1, files in 'config' were packaged into the jar file. At some
> point it was decided that 'resources' was a better name than 'config',
> so now 'config' is just another directory that Maven doesn't do anything
> with.
>
> In general Maven doesn't know how you're going to deploy your package,
> so it doesn't know what to do with directories like: config, etc, bin,
> and so on. So you need to figure this out and come up with your own
> convention. Plugin's like assemble (assembly?) can help a lot. I often
> use it to create a tar ball that unpacks into a directory something
> like:
>
> app/
> bin # all files have execute
> etc # User configurable files
> jars# all dependencies
> logs# where app writes logs.
>
> Basically my bin and etc directories under src/main get copied into the
> tar ball.
>
> Hope this helps.
> C. Helck
>
>
>
>
>
> -Original Message-
> From: Jean-Louis MONTEIRO [mailto:jean-louis.monte...@atosorigin.com]
> Sent: Wednesday, September 16, 2009 12:06 PM
> To: users@maven.apache.org
> Subject: Re: Porpuse of src/main/config
>
>
>
>
> Geoffrey Wiseman wrote:
>>
>> On Fri, Aug 1, 2008 at 11:00 AM, DOMINGUEZ Felipe <
>> felipe.doming...@eurocontrol.int> wrote:
>>
>>> I am new to Maven, and I am a bit confuse about the porpuse of
>>> directory src/main/config porpuse
>>>
>>> I have been looking for information about it but it does not seems to
>
>>> be much.
>>>
>>> I initially thought that in directory src/main/resources I could put
>>> any static resource used by the jar file and in src/main/config I
>>> could put any configuration file that needs to be customised before
>>> the jar file is used. For example in the config file I would add the
>>> hibernate.cfg.xml file, since the DB connection information needs to
>>> be modify by the person who will use the jar file.
>>>
>>> placing hibernage.cfg.xml in the resources files is not good, since
>>> this file will be added to the jar file, so the person who will use
>>> the jar file will have to extract it to be able to modify its
>>> properties. So initially I thought that src/main/config was for this
>
>>> porpuse, but all files that I put in congif directory are ignored.
>>>
>>> Can any body clarify the usage of src/main/config and what is maven
>>> approach for using configuration files such as hibernate.cfg.xml or
>>> other config files that need to be modified on the live environment?
>>>
>>
>> What about this?
>> http://maven.apache.org/guides/introduction/introduction-to-the-standa
>> rd-directory-layout.html
>>
>> --
>> Geoffrey Wiseman
>>
>>
> Hi Geoffrey,
>
> it's not clear at all.
> Can you please explicitly give us the difference between
> src/main/resources and src/main/config ?
> I guess src/main/resources goes to target package (jar, war, ...). And
> from my understanding, src/main/config is not part of the classpath and
> is used only for build (configuration files used to build, ...).
>
> Thanks for your help.
> Regards,
> Jean-Louis
> --
> View this message in context:
> http://www.nabble.com/Porpuse-of-src-main-config-tp18776348p25475583.htm
> l
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
> **
> This communication and all information (including, but not limited to,
> market prices/levels and data) contained therein (the "Information") is
> for informational purposes only, is confidential, may be legally
> privileged and is the intellectual property of ICAP plc and its
> affiliates
> ("ICAP") or third parties. No confidentiality or privilege is waived or
> lost by any mistransmission. The Information is not, and should not
> be construed as, an offer,
