I had started to read your thread before I posted but it seemed to move
towards something to do with Docbook so I didn't read it fully. Now I've
re-read it I can see there are similarities.

I'd like to think my requirements are closer to the "Maven way" since
testing is part of Maven and the database setup is part of the profile for
testing. My requirement was simply to allow for common sections to be
collected together to enhance the maintainability of the pom. Currently the
verbose nature of the pom makes it far too easy to have subtle differences
that ruin the test.

However, what we do have is still excellent and I wouldn't want to lose that
power which Maven brings. OK there may be alternatives but Maven is pretty
much the de facto standard and it would be foolish to move away from that.

There was a post which made reference to the ability to run an ant task
within Maven but outside of the lifecycle. The may provide what we are
looking for.

Thanks for making me re-read the thread.

Eric.

On Fri, Jan 16, 2009 at 4:10 PM, Trevor Harmon <[email protected]> wrote:

> On Jan 15, 2009, at 7:09 AM, Eric Rotick wrote:
>
>  So, the first question is, is this use of profiles correct? I can see that
>> primary purpose of profiles is to set up, well profiles, of different
>> scenarios for the build. In this respect the use of profiles for specific
>> tests falls loosely into this category. However, the use of profiles to
>> perform a kind of macro or script does not seem correct.
>>
>
> This sounds like the same question I had in this thread:
>
>
> http://mail-archives.apache.org/mod_mbox/maven-users/200812.mbox/%[email protected]%3e
>
> The ideal solution is to write your own custom test plugin, "mytest" or
> whatever. You can then invoke it directly, like this:
>
>  mvn mytest:test1
>  mvn mytest:test2
>  ...
>
> Or you can bind it to a phase and have it run automatically.
>
> Of course, writing your own plugin involves extra work and maintenance, so
> as an alternative you can simply put your test invocation code into a
> profile and simply enable that profile as needed. This is not kosher, as you
> point out, but it's an acceptable workaround for test scenarios. At least,
> this is my conclusion based on the responses in the thread.
>
> Trevor
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Reply via email to