You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Wo...@AtosOrigin.com on 2008/09/05 08:46:05 UTC
from workaround to workaround 1
Hi,
here is a small story about working with Maven. In my experience of 6 months now this happened very often like this. Maven is very hard to manage, not intuitive and error messages are incomprehensible or misleading.
The problem: We have 5 Maven projects with sub projects. For test classes, the database connection should be defined only once, we put it into the user's settings.xml. Now, how accessing the db-properties in test classes?
First idea: Filtering! I created properties file in the test/resources directories and tried to filter db properties from the settings properties with
<resources>
<resource>
<directory>src/test/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
Nothing happens. Filtering seems to be possible only in main/resources. Then I ask myself why have I to define a <directory> when only one value is working? You could hard-code it. This is not intuitive!
Freundliche Grüße / Kind regards
Wolfgang Winter
System Analyst
Re: from workaround to workaround 1
Posted by Dennis Lundberg <de...@apache.org>.
Hi
Instructions on how filtering works in the Resources Plugin can be found
on this page:
http://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html
Wolfgang.Winter@AtosOrigin.com wrote:
> Hi,
>
>
>
> here is a small story about working with Maven. In my experience of 6 months now this happened very often like this. Maven is very hard to manage, not intuitive and error messages are incomprehensible or misleading.
>
>
>
> The problem: We have 5 Maven projects with sub projects. For test classes, the database connection should be defined only once, we put it into the user's settings.xml. Now, how accessing the db-properties in test classes?
>
> First idea: Filtering! I created properties file in the test/resources directories and tried to filter db properties from the settings properties with
>
>
>
> <resources>
>
> <resource>
>
> <directory>src/test/resources</directory>
>
> <filtering>true</filtering>
>
> </resource>
>
> </resources>
>
>
>
> Nothing happens. Filtering seems to be possible only in main/resources. Then I ask myself why have I to define a <directory> when only one value is working? You could hard-code it. This is not intuitive!
>
>
>
>
>
> Freundliche Grüße / Kind regards
>
>
>
> Wolfgang Winter
>
> System Analyst
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: from workaround to workaround 1
Posted by Martin Höller <ma...@xss.co.at>.
On Friday 05 September 2008 Wolfgang.Winter@atosorigin.com wrote:
> But for me the
> problem is not only documentation but also a user-friendly design. Take
> the filtering example: For main/resources you have
> <resources><directory>main/resources ... And for test/resources you have
> to say
> <testresources><directory>test/resources ...
> This is redundant information in the configuration! I am not used to have
> such redundancies. It is not what I (and probably many developers)
> expect.
I didn't test it now, but usually the defaults are quite intuitive. And
that's also what [0] says. So you don't have to specify the directory
if you use mavens default structure.
regards,
- martin
[0] http://maven.apache.org/plugins/maven-resources-plugin/examples/resource-directory.html
AW: from workaround to workaround 1
Posted by Wo...@AtosOrigin.com.
[Winter, Wolfgang] Hi all, thanks for your answers and sorry if I started this more general criticism about Maven. I am only a dumb user who just started setting up projects with Maven and it is really a great tool concerning project structuring and building. And Rainer is probably right when he states all you need is there but not easy to find.
But for me the problem is not only documentation but also a user-friendly design. Take the filtering example: For main/resources you have <resources><directory>main/resources ...
And for test/resources you have to say
<testresources><directory>test/resources ...
This is redundant information in the configuration! I am not used to have such redundancies. It is not what I (and probably many developers) expect. If you design this more obvious and intuitive lacks in documentation are much less bothering.
-----Ursprüngliche Nachricht-----
Von: Rainer Pruy [mailto:Rainer.Pruy@Acrys.COM]
Gesendet: Freitag, 5. September 2008 10:40
An: Maven Users List
Betreff: Re: from workaround to workaround 1
After all,
I consider this classical paradigm of "all you need is there, just obstructed by details all over".
"Filtering did not work" because <resource> does filtering for mainstream, but Wolfgang needed filtering for "test".
If you know what to look for, this distinction is quite obvious from the docs.
But for the hurrying user trying to overcome an immediate problem, this is easily to be overlooked.
This is (implicit) reason to a number of complaints in maven related lists.
Due to the distributed and fine-grain nature of maven and it's plugins.
Information is spread across numerous locations without much "interconnection" of semantics.
For "using" a plugin, it is always implied the (potential) user is absolutely aware of any implications of the interaction of that
plugin with the rest of the maven "runtime".
Probably we can keep that in mind when working on documentation:
- explicitly state the environment and effects of a plugin
- always encourage users/readers to "get the overall picture" first (or restate the essentials?)
May be that will improve "user experience" in the long.
As in most cases the problem is not some feature not being "available",
but some wanted feature not being discoverable easily (esp. if it has to be constructed using several existing components).
And maven has a lot of bricks to build from. but also a lot of points to get something plugged to.
And is not (always) quite obvious to the ordinary "user" what effects are possible and what needs something new.
Regards
Rainer
Asgeir S. Nilsen schrieb:
> Wolfgang,
> For test resources you should use the <testResources> element, not the
> <resources> element. The documentation is a bit shallow on this matter.
>
> Asgeir
>
> On Fri, Sep 5, 2008 at 08:46, <Wo...@atosorigin.com> wrote:
>
>> Hi,
>>
>>
>>
>> here is a small story about working with Maven. In my experience of 6
>> months now this happened very often like this. Maven is very hard to manage,
>> not intuitive and error messages are incomprehensible or misleading.
>>
>>
>>
>> The problem: We have 5 Maven projects with sub projects. For test classes,
>> the database connection should be defined only once, we put it into the
>> user's settings.xml. Now, how accessing the db-properties in test classes?
>>
>> First idea: Filtering! I created properties file in the test/resources
>> directories and tried to filter db properties from the settings properties
>> with
>>
>>
>>
>> <resources>
>>
>> <resource>
>>
>> <directory>src/test/resources</directory>
>>
>> <filtering>true</filtering>
>>
>> </resource>
>>
>> </resources>
>>
>>
>>
>> Nothing happens. Filtering seems to be possible only in main/resources.
>> Then I ask myself why have I to define a <directory> when only one value is
>> working? You could hard-code it. This is not intuitive!
>>
>>
>>
>>
>>
>> Freundliche Grüße / Kind regards
>>
>>
>>
>> Wolfgang Winter
>>
>> System Analyst
>>
>>
---------------------------------------------------------------------
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: from workaround to workaround 1
Posted by Rainer Pruy <Ra...@Acrys.COM>.
After all,
I consider this classical paradigm of "all you need is there, just obstructed by details all over".
"Filtering did not work" because <resource> does filtering for mainstream, but Wolfgang needed filtering for "test".
If you know what to look for, this distinction is quite obvious from the docs.
But for the hurrying user trying to overcome an immediate problem, this is easily to be overlooked.
This is (implicit) reason to a number of complaints in maven related lists.
Due to the distributed and fine-grain nature of maven and it's plugins.
Information is spread across numerous locations without much "interconnection" of semantics.
For "using" a plugin, it is always implied the (potential) user is absolutely aware of any implications of the interaction of that
plugin with the rest of the maven "runtime".
Probably we can keep that in mind when working on documentation:
- explicitly state the environment and effects of a plugin
- always encourage users/readers to "get the overall picture" first (or restate the essentials?)
May be that will improve "user experience" in the long.
As in most cases the problem is not some feature not being "available",
but some wanted feature not being discoverable easily (esp. if it has to be constructed using several existing components).
And maven has a lot of bricks to build from. but also a lot of points to get something plugged to.
And is not (always) quite obvious to the ordinary "user" what effects are possible and what needs something new.
Regards
Rainer
Asgeir S. Nilsen schrieb:
> Wolfgang,
> For test resources you should use the <testResources> element, not the
> <resources> element. The documentation is a bit shallow on this matter.
>
> Asgeir
>
> On Fri, Sep 5, 2008 at 08:46, <Wo...@atosorigin.com> wrote:
>
>> Hi,
>>
>>
>>
>> here is a small story about working with Maven. In my experience of 6
>> months now this happened very often like this. Maven is very hard to manage,
>> not intuitive and error messages are incomprehensible or misleading.
>>
>>
>>
>> The problem: We have 5 Maven projects with sub projects. For test classes,
>> the database connection should be defined only once, we put it into the
>> user's settings.xml. Now, how accessing the db-properties in test classes?
>>
>> First idea: Filtering! I created properties file in the test/resources
>> directories and tried to filter db properties from the settings properties
>> with
>>
>>
>>
>> <resources>
>>
>> <resource>
>>
>> <directory>src/test/resources</directory>
>>
>> <filtering>true</filtering>
>>
>> </resource>
>>
>> </resources>
>>
>>
>>
>> Nothing happens. Filtering seems to be possible only in main/resources.
>> Then I ask myself why have I to define a <directory> when only one value is
>> working? You could hard-code it. This is not intuitive!
>>
>>
>>
>>
>>
>> Freundliche Grüße / Kind regards
>>
>>
>>
>> Wolfgang Winter
>>
>> System Analyst
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: from workaround to workaround 1
Posted by "Asgeir S. Nilsen" <as...@gmail.com>.
Wolfgang,
For test resources you should use the <testResources> element, not the
<resources> element. The documentation is a bit shallow on this matter.
Asgeir
On Fri, Sep 5, 2008 at 08:46, <Wo...@atosorigin.com> wrote:
> Hi,
>
>
>
> here is a small story about working with Maven. In my experience of 6
> months now this happened very often like this. Maven is very hard to manage,
> not intuitive and error messages are incomprehensible or misleading.
>
>
>
> The problem: We have 5 Maven projects with sub projects. For test classes,
> the database connection should be defined only once, we put it into the
> user's settings.xml. Now, how accessing the db-properties in test classes?
>
> First idea: Filtering! I created properties file in the test/resources
> directories and tried to filter db properties from the settings properties
> with
>
>
>
> <resources>
>
> <resource>
>
> <directory>src/test/resources</directory>
>
> <filtering>true</filtering>
>
> </resource>
>
> </resources>
>
>
>
> Nothing happens. Filtering seems to be possible only in main/resources.
> Then I ask myself why have I to define a <directory> when only one value is
> working? You could hard-code it. This is not intuitive!
>
>
>
>
>
> Freundliche Grüße / Kind regards
>
>
>
> Wolfgang Winter
>
> System Analyst
>
>