<div class="gmail_quote">On Tue, Jan 5, 2010 at 11:58 AM, Pete Muir <span dir="ltr"><<a href="mailto:pmuir@redhat.com">pmuir@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
On 28 Dec 2009, at 20:35, Steven Boscarine wrote:<br>
<br>
> I like your suggestion of making it a POM option. I'd advocate that it only be started via a specific non-default profile.<br>
><br>
> For our projects, we usually define projects with non-Maven dependencies, like a partner web service or SMTP server, in a specific TestNG group which is excluded in the default profile.<br>
><br>
> Sorry if this is repetitive, but...<br>
> The big and central concern that I want to express to people is that you can unintentionally trigger code that doesn't belong to your project using commands that are typically assumed to be innocuous, like "mvn install."<br>
><br>
> This is a classic scenario where you're giving the developer a really, really, really sharp tool. Individuals obviously need to take responsibility for their projects and decide what's appropriate.<br>
><br>
> For my team (at CHB...my day job), I'd obviously have to make sure that they don't put anything where mvn test can run any code that's not part of its project. I'd have no issues with a team member starting an embedded container because they would only be running their own code, defined in their project, but if someone started up an installed container from mvn test, I'd have no choice but to put a stop to it.<br>
<br>
</div>This is an interesting point, and one I guess that isn't really an issue in places I've worked. I can see that it would make sense to ensure that this runs in the "correct" (often a clean) container.<br>
<br>
The exact way you would specify that you want to use a particular "installed" container is to enable the container in your POM, by adding a dependency to the connector, and then specifying the path to the container in the connectors properties. This seems pretty explicit to me - but is it enough?<br>
</blockquote><div><br>I still say that as long as the behavior is easily tuned (enabled, disabled, proper instance location) and sufficiently documented, we should offer the flexibility for the remote container to be started automatically.<br>
<br>-Dan<br clear="all"></div></div><br>-- <br>Dan Allen<br>Senior Software Engineer, Red Hat | Author of Seam in Action<br>Registered Linux User #231597<br><br><a href="http://mojavelinux.com">http://mojavelinux.com</a><br>
<a href="http://mojavelinux.com/seaminaction">http://mojavelinux.com/seaminaction</a><br><a href="http://www.google.com/profiles/dan.j.allen">http://www.google.com/profiles/dan.j.allen</a><br>