[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:[EMAIL PROTECTED] 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, <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
