Copying an STS spring roo project?

[ew0kian]

My spring roo project has alot of maven dependencies that are being stored in a folder outside of my roo project I'm working with on my desktop PC. If I wanted to copy the project to dropbox or put in SVN, how will it handle those maven dependecies when I try to bring it down to my macbook? Thanks.

[krimple]

Why are you using external dependencies, is it because these JARs don't exist in Maven central, or because they are from other company projects / libraries?

Maven does have a scope of system for cases like this... but you should have it path-relative, since if you don't check in the libraries in SVN in an expected place, they won't be found.

I'd suggest looking into why you have these libraries stored outside of the Maven / Maven Repository infrastructure and try to live within it instead.

Other suggestions:

- You can do mvn dependency:install if you don't have a repository for non-public Maven dependency, then use the coordinates you set for groupId, artifactId, and version in your build. You can put the JARs in version control, then put a shell script in the same directory to run those mvn dependency:install commands on another PC or Mac when you want to set it up. (not ideal)

- You can see if your artifacts (assuming they are open source) are available to use from the Maven coordinate system (groupId, artifactId, version) using search.maven.org and replace your manual JAR locations with those (better)

- You can download a Nexus free repository server, put it online in your location, and load your non-maven artifacts into it. Companies do this so they can share artifacts. Then you can add it as a repository for your project. (better)

Ken

[ew0kian]

Wow how cool is it that one of the authors of the book I'm reading is answering my question? Great book by the way.

I should have mentioned that these maven dependencies were all created by the spring roo command line program as I was adding new functionality to the project (like adding security for example). So they are all "public" in that sense I suppose.

So now that I think about it as long as I check in all the files in my project to SVN, then when I do a fresh check out maven should be able to copy the libraries to an appropriate location on the macbook. I will give this a try today. Thanks.

Why are you using external dependencies, is it because these JARs don't exist in Maven central, or because they are from other company projects / libraries?

Maven does have a scope of system for cases like this... but you should have it path-relative, since if you don't check in the libraries in SVN in an expected place, they won't be found.

I'd suggest looking into why you have these libraries stored outside of the Maven / Maven Repository infrastructure and try to live within it instead.

Other suggestions:

- You can do mvn dependency:install if you don't have a repository for non-public Maven dependency, then use the coordinates you set for groupId, artifactId, and version in your build. You can put the JARs in version control, then put a shell script in the same directory to run those mvn dependency:install commands on another PC or Mac when you want to set it up. (not ideal)

- You can see if your artifacts (assuming they are open source) are available to use from the Maven coordinate system (groupId, artifactId, version) using search.maven.org and replace your manual JAR locations with those (better)

- You can download a Nexus free repository server, put it online in your location, and load your non-maven artifacts into it. Companies do this so they can share artifacts. Then you can add it as a repository for your project. (better)

Ken

[krimple]

Thanks, I appreciate your kind words.

I think I see what you're asking about better now. If Roo gave you these dependencies, it did so in the form of coordinates within maven (look in pom.xml, and see the section called <dependency> for details). Those dependencies are stored publicly on the internet at one of several repositories, likely "Maven Central".

Here's what you normally do in a Maven project.

1) check in the pom.xml file and src/*
2) do NOT check in target

Let all developers check out the source, and do a mvn install tomcat:run to download, build and start their applications.

When you do a 'mvn install' or build in STS, the artifacts (that's what Maven calls the libraries it downloads) are downloaded to your home directory on your OS to a location called .m2/repository. Maven shares those 'artifacts' with other builds, too, so if you've downloaded commons-io version X, the next project that asks for it gets it from the same build path.

When maven builds, it assembles a directory, 'target', which is not meant to be checked in. In fact, it is the directory where the completely built and assembled, ready-to-go war file will be. The WAR will have a WEB-INF/lib directory, properly populated with all of those open source libraries.

This is automatic, and something that makes Maven a true enterprise build platform. Continuous integration tools perform builds too, and can run more involved suites of tests (like integration and web tests, that would take too long to do on your machine while making changes). Since the CI tool (think names like Hudson, Anthill, Bamboo etc) is doing a build every time you check in, it will spot things you won't (like missing checked-in files). The best part? It uses the same target directory, the same build.

Is that closer to what you're asking? I'm thinking I misread the question early this evening.

Best,

Ken


If you explore that directory structure, you'll see a ton of resources.