Right Chris, spring-boot:run just runs the WebApi class which bootstraps the embedded tomcat.
Since we’re using Tomcat for both embedded and hosted, I don’t see a big concern. Obviously, testing the application on a stand alone tomcat instance can be done incrementally along the way and is not a bad idea… Note that some opt to run spring boot applications as just jars (w/o a stand alone tomcat).
Regarding driver jars, as you can see in the WebAPI oracle profile, my preference has been to include any dependencies in the project’s pom.xml. I would recommend that you set up a local maven repository or add a private repository to nexus, so that you can have a repo for all artifacts.
Dependencies can be activated for only a select profile.
Dependencies can be scope provided (i.e. available at compile time and runtime but not packaged - implies the container provides them - think servlet api). In your case, the driver jar could be of provided scope. I created the profile-specific dependency on oracle driver with compile scope so that we could use yet another form of running the app (tomcat7:run-war). This is not really necessary.
As a stop gap until you have your artifact in a maven repository, you could consider a ‘system’ scope’d dependency that contains a systemPath (i.e. absolute path to jar).
<dependency>
<artifactId>..</artifactId>
<groupId>..</groupId>
<scope>system</scope>
<systemPath>${basedir}/lib/driver.jar</systemPath>
</dependency>
On a separate note: i just pushed a change to the miredot plugin to only run during package phase. This should save ~1-2 seconds for netbeans users using spring-boot:run, and is a reasonable phase for CI servers. However, if netbeans users continue to use the default run project (which uses maven package), we may want to consider changing this to phase verify (to be performed with integration tests and still reasonable for CI servers).