I started working recently on a quite big Java project divided into separate libraries. These are maintained as a Maven dependencies (not multi-module project).
How can I automatize the process of building main project and its dependencies?
The ideal case would be that the Maven build gets invoked only in the case of encountering changes in SVN code. I use Eclipse + m2e + Subclipse, as for now I need to take care of this by hand, remembering which dependencies do I need, synchronizing for SVN changes and then making build manually.
Sorry if this is a complete newbie question, but I've never been working in such environment up to this moment.
I think you could create an aggregate POM and use SVN externals to create the correct structure.
Take into account that using externals you can "link" to the latest revision in a branch or an specific revision.
Here you can see a sample project using externals in SVN and an aggregated pom.xml
Note: if you are using mvn:release and using externals, you should run indepently for each external.
Related
I work for a small company of software consultants, that does development primarily (currently: solely) for the JVM using Eclipse as our IDE of choice.
Until now, we have not been using any Project Management/Build Tools. We have used a company SVN repository for version control of our projects along with any binary dependencies (well JAR dependencies) of same. This has gotten a bit messy, and we have a lot of extraneous *.jar files in lib folders across our projects.
With our recent shift to Scala as our PL of choice, we have also looked into using SBT as build tool. We have set up a Sonatype Nexus repository, and have begun declaring SBT files for our projects
The thing is, that we have a set of utility projects that are used across a lot of projects for our customers. Until now, we have managed inter-project dependencies by having an Eclipse workspace for each customer project, with each of these having a local version of the utility projects on which it has dependencies. Keeping local versions up to date has therefore been handled solely through SVN commits and updates.
I guess that there are a couple of different ways that we could go about structuring our projects and workspaces. Using SBT to define inter-project dependencies, it would make sense to have a workspace for the utility projects alone, and then importing snapshots/releases as managed dependencies in our customer projects. However, since we often make enhancements to the utility projects during development of the customer projects, it would be nice to still be able to do this in the same workspace and as much on the fly as possible.
From: http://www.devdaily.com/scala/using-github-projects-scala-library-dependencies-sbt-sbteclipse it seems that a plugin exists for Git that grabs current versions from a Git repository, builds the source and includes them in the Eclipse classpath. This sort of setup would allow us to continue to use the revision control system as the main means of distributing project updates, though I have not been able to find something similar for SVN...
Is anyone using SBT with SVN and eclipse, and/or knows of a smart way to setup interproject dependencies without firing a lot of publish/publish-locals alongside the SVN commands?
It would be nice to somehow declare interproject dependencies using SBT, since this would allow us to dump the responsibility for transient managed dependencies on SBT...
Here is the situation. A development team has a large number (hundreds) of Eclipse projects. The code is very much in churn - new projects are being created; projects are being renamed and project dependencies are constantly changing. The external build system is ant. It is proving extremely challenging to keep the dependencies defined in the ant build files in sync with the state of the world in Eclipse. The external ant build needs constant changes to keep up. For various reasons, using ant as the default builder in Eclipse is not an option. The developers want to continue using Eclipse as the build and edit environment for local use.
Question: Is there a tool which will allow a single set of dependencies to be maintained which can be used by Eclipse as well as an external build system like ant?
I have heard of Gradle but never used it before. Would it make sense in this context? I am pretty sure Maven wouldnt work for what is needed
The typical workflow should be:
1. Developers continue working as they currently do - creating and changing Eclipse project dependencies at will and using the default Eclipse builder to compile and test locally.
2. Some mechanism exists by which these dependencies can be carried into an external build system like ant and an external continuous build triggered on every checkin.
Appreciate your feedback - thanks!
We have been quite successful at using Gradle to tackle a similar problem. Here's the outline of the setup
Each project contains a build.gradle that defines project specific dependencies and tasks (may even be empty).
A special master project contains build.gradle that sets up common dependencies and tasks for child projects, and/or injects settings pertinent to a group of child projects.
Logically master project is the parent project, but it exists as a sibling folder so that Eclipse can be more comfortable with it.
Gradle contains a built-in Eclipse plugin which allows generation of Eclipse settings files for each of the projects from the dependencies information (including inter-project dependencies). It works nicely for simple projects, and as for more complicated ones Gradle allows you to tinker with the settings files, so you can do pretty much everything. From here you have two options:
Not to store Eclipse settings file in the repository and call the generation task every time you do a fresh check-out (I prefer this option).
Tell Gradle to use custom variables to make it generate generic settings files which can be checked-in to the repository. You'll then only need to run the generation task when dependencies or other configuration changes.
(Optional) It's a little tricky, but you can make Gradle parse existing project ivy.xml files and set up dependencies from there. I had some success with this, although I would recommend converting dependencies into Gradle format for more flexibility.
Continuous build system integrate with Gradle very well (same as ant). If you are using Jenkins (Hudson) there is a Gradle plugin.
The advantage of using Gradle is that it scales pretty well, and you can support other IDEs like IntelliJ or Netbeans at the same time without much effort (unless you have lots of crazy custom settings). An advantage and a disadvantage is that Gradle is a powerful build system which requires learning Groovy and Gradle DSL which may take some time to acquire. Also the documentation is awesome.
Gradle has a very active community with the sole purpose of tackling exactly this kind of problem.
Hope this helps, and best of luck!
How about parsing the .classpath files, generate a dependency tree and start building from the root. What you need is a convention on the layout of your projects or an generic (ant-) buildfile that could be changed in each project, if needed (e.g. different project layouts). I´m not sure if Eclipse Tycho could be used for that, since it´s a maven plugin(s) to build eclipse plugins or projects. But it´s able to resolve the bundle and project dependencies against maven repositories and eclipse update sites.
We've got a multi-module project using Eclipse and Maven. The only way I could get it to work in the past was to use a flat layout for the projects, where the parent module was a peer to the other modules. This worked fine with m2eclipse and Subversion.
Now we'd like to move to Git and GitHub. I'd like to expose the entire project, along with all the modules, as a single project on GitHub. The problem is that EGit, the Eclipse/Git plugin, wants to manage projects one at a time, not groups of projects, and so if you've got a flat layout, you can't do it.
The right answer is to use a standard Maven hierarchical layout and manage the parent and all the modules as a unit. But Eclipse doesn't like that, and no amount of fiddling will get Eclipse to accept nested projects. m2Eclipse does not support hierarchies: https://issues.sonatype.org/browse/MNGECLIPSE-2291
So what do you do? Do Git from the command line and abandon the ability to see what files have changed in Eclipse? Or abandon Eclipse?
A standard Maven multi-module structure as a single git repo works perfectly fine for me in Eclipse Indigo with M2e and the git plugin that shows up in that environment. You can't ask Eclipse to do your fetching for you, but once you've pulled from command line, you use Team/Share, say 'Git!' and all is well.
I think I see what's the source: hierarchy is a problem for projects inside the workspace, not 'existing projects' that you import.
Here's a typical workflow:
use git svn clone to get a tree. it's a stock, hierarchical mvn multi-module tree
in eclipse, use import/maven/existing maven project. Point at the whole tree
select all
OK
it works fine. The nesting does not disturb eclipse one bit. I don't know what problem that bz is pointing at.
Before I used m2e I used the maven-eclipse-plugin. And it also worked in these cases, because it does not generate a .project/.classpath for <packaging>pom</packaging> aggregating projects, so Eclipse is never called upon to actually nest anything.
I'm not alone -- see the developer setup instructions as cxf.apache.org for an open source example that you can try for yourself.
Is it possible that you are working with old versions of the tool?
I have a Maven multi-module project that I work with using Eclipse 3.7 (Indigo), M2Eclipse (1.0) and EGit (1.0).
On the file system the multi-module project has a single parent directory.
In Eclipse I have separate projects for each module.
M2Eclipse does the dependency management perfectly.
There is single git repository (.git directory) at the top-level and EGit works perfectly.
You can put your modules in Git with hierarchical layout. And build those modules by Maven. If those modules are projects(whatever java, c++ or php project) recognized by Eclipse, they can be imported into workspace as flat layout in workspace.
-- the root of Git working directory
-- moudule1
-- project1(a java project)
-- .project(a project file recognized by eclipse JDT)
-- pom.xml
-- project2(a java project)
-- .project
-- pom.xml
-- module2
-- projectA(a java project)
-- .project(a project file recognized by eclipse JDT)
-- pom.xml
-- projectB(a c++ project)
-- .project(a project file recognized by CDT)
-- pom.xml
For Maven projects, multiple imports at once can be achieved via the Maven import wizard (that is accessible from Git).
In case you don't know what kind of projects you're about to import, you can use the new Easymport that will import project "as best", by deducing configurations from various files. See https://github.com/jbosstools/jbosstools-playground#easymport-easy-and-smart-openimport-of-a-project
Once you get all those projects, you can use the Nestor plugin, which will show project in a nested/hierarchical layout, mapping more correctly your Maven project: https://github.com/jbosstools/jbosstools-playground#nestor-view-nested-projects
I have some related legacy projects that are a mess and I would like to mavenize them as a multi-module project shared on subversion (first multi-module project, we've always had them separate). There are a few key parts 1) webservice, 2) various swing clients, 3) model (w/ persistence from hibernate), 4) core JSE tasks.
I've been messing around for a few days trying to correctly set it up using Eclipse (Helios), Maven (2.2.1), m2eclipse (0.10.0) and Subversion (1.6) for our team. I keep stumping myself or having random errors that force me to backtrack. I'm hoping someone can help me out with some best practices.
Here are some of the questions:
m2eclipse requires a "flat" eclipse project structure. Does that mean I should create a subversion repository for each module? If I do one repository and try to check in from the parent project I'm having a difficult time setting the svn:ignore property on the nested project target (and other) directories.
If I do a module per repository, I seem to be able to check them in ok. The question then is what is the best way to check out via subclipse? Is there a best order? Parent or child project(s) first? Do I need to checkout the parent project and modify the checkout path of the children project to be nested in the file directory that will allow me to then "clean install" from the parent project?
Or, should I abandon subclipse and m2eclipse and checkout and run my maven goals from the command line.
Or, should I just be using the SCM integration with Maven. Or, maybe just not even try to get a multi-module project setup.
What do others do? Does anyone have some documentation (I missed) or some links (Google didn't recommend)?
Thanks in advance for your feedback.
m2eclipse requires a "flat" eclipse project structure.
Hmm, m2eclipse supports nested projects AFAIK (or at least importing a nested project structure). I don't use Eclipse wizards to create my projects though so maybe I'm not aware of something.
Does that mean I should create a subversion repository for each module?
No, no, absolutely not and I wouldn't do that (this will be hard to maintain). However, depending on your projects release cycles, you might have to think about the layout of your repository (single vs multiple trunk/tags/branches), especially if you plan to use the maven release plugin. If some pieces have independent release cycles, then I'd go for several trunk/tags/branches. If you always release them all together (as a single product), then a single trunk/tags/branches should do it. I wrote several answers on the topic that may be of interest:
Migrating to maven from an unusual svn directory structure?
Maven parent pom vs modules pom
How to handle maven versions in a multi module project?
If I do one repository and try to check in from the parent project I'm having a difficult time setting the svn:ignore property on the nested project target (and other) directories.
What is the particular problem?
If I do a module per repository, I seem to be able to check them in ok. The question then is what is the best way to check out via subclipse? Is there a best order? Parent or child project(s) first? Do I need to checkout the parent project and modify the checkout path of the children project to be nested in the file directory that will allow me to then "clean install" from the parent project?
Whatever choice you'll make (multiple repositories or not, multiple trunk/tags/branches or not), it should be possible to checkout the whole project structure in one time (using svn:externals if required). At least, you should try to make it possible (and it is, see the links posted above).
But I repeat, I do not recommend using multiple repositories (unless you want independent revision numbers) and nothing forces you to do that.
Or, should I abandon subclipse and m2eclipse and checkout and run my maven goals from the command line.
I use Eclipse, m2eclipse, subclipse successfully, all well integrated (at least for the build and "check in" part). But I do the initial import and the initial checkout on the command line and then imported
Or, should I just being using the SCM integration with Maven.
I don't use it, I don't have the need for it.
Or, maybe just not even try to get a multi-module project setup.
There is no reason to forbid the use of a multi-modules project setup, multi-modules builds are one of the key part of Maven.
What do others do? Does anyone have some documentation (I missed) or some links (Google didn't recommend)?
Have a look at the links I posted :)
It is a bit tricky at first. The way I've typically seen it setup is like so:
In subversion:
- Parent Project
-- Module A
--- pom.xml (module A)
-- Module B
--- pom.xml (module B)
-- Module c
--- pom.xml (module C)
-- pom.xml (parent project)
Some things to note (you already know):
You have to have the child projects
listed as modules in your parent
project
You have to list the parent project
in your child pom's (as the parent
group, artifact, version)
When you check out the project from
svn, you need to do 'check out as
maven project' instead of the
standard 'check out' (this one can be
a gotcha)
I hope this helps.
I'm about to start working on a web-application and I'll be using Maven. I want the web-application to be an individual artifact. The web-application will end up depending on a couple of self written libraries (for example text-formatting), and each of these libraries should be an individual artifact.
What's the recommended way of achieving this separation while making it simple to code for both artifacts? I was thinking of creating one project for each artifact and import them one by one in Eclipse. However, if the pom for web-application has a dependency pointing at the self written library, I'll end up having to deploy a snapshot every time I want to see if the change I made stopped the web-application from crashing (in example).
I hope you understand what I am getting at. I'll be working with a couple more developers, and we're using Nexus to maintain our shared artifact repository.
I was thinking of creating one project for each artifact and import them one by one in Eclipse.
Yes, that's the recommended way.
However, if the pom for web-application has a dependency pointing at the self written library, I'll end up having to deploy a snapshot every time I want to see if the change I made stopped the web-application from crashing
During development, you can use "workspace resolution" i.e. configure Eclipse to resolve dependencies from the workspace. This way changes are immediately visible from the webapp. This is possible whether you are using m2eclipse or the maven eclipse plugin (and is actually the default behavior for both).
Below, an illustration for m2eclipse:
A good maven plugin for eclipse is capable of "workspace resolution", i.e. it will recognize if the dependency is also present in the workspace, and refer to the other project directly rather than adding a JAR to the build path.