views:

132

answers:

2

Total Maven newbie, trying (along with the rest of a sizeable team) to convert a monstrous pile of legacy code from ant over to Maven. It's working reasonably well, but I'm having the following problem.

I have a project, let's call it Core, that at runtime needs to load some files checked in under some different projects, let's call them Resources A and B. The Core code is started in a certain working directory, let's call it core/runtime, and there's a properties file it reads in order to determine what to load from Resources A and B, complete with the relative path to the resources in question, e.g.

  resource.ham=../../resources-a/files/ham.rsrc
  resource.eggs=../../resources-b/files/eggs.rsrc

(Yes, I'm aware this is sick and wrong and we should be loading resources as resources, from a JAR via a classloader and maybe some sort of container or dependency injector or whatever. Not my idea, not my current problem, not on the table to be fixed now.)

(Seriously, please don't bother suggesting we fix the underlying problem. We know we need to fix the underlying problem. We knew we needed to fix the underlying problem before we switched to Maven, and before we switched to Maven the stupid hack actually worked. I know it makes you feel good, but it's not helpful. This is a ten-year-old codebase with tens of thousands of classes and believe me, there are plenty of more important things wrong with it.)

This relative-path hack is only an issue in Eclipse, during development; in the actual deployed application the files live somewhere completely different and are loaded in a somewhat more sensible way.

Anyhow, this all worked fine when these were vanilla Eclipse projects, so the directories in question had paths like:

  c:\workspace\core\runtime
  c:\workspace\resources-a\files
  c:\workspace\resources-b\files

However, now that these are checked out as Maven projects, the directories are now something like:

  c:\workspace\core\runtime # Inexplicably unchanged
  c:\workspace\maven.8675309\resources-a\files
  c:\workspace\maven.6345789\resources-b\files

Questions:

  • Can I make these maven.7762323 directories go away?
  • If not, is there some way in Eclipse to get the path to a project directory, and then pass that as a system property in a launch configuration, or something like that?

Any solution has to be one I can check into SVN so the other developers on my team can use it out of the box.

Update

Okay, I figured out where the maven.[number] directories come from: When you select a parent directory in the SVN repository and say "Check out as Maven project", you get a maven.[number] directory corresponding to the parent, with all the actual projects as subdirectories. It would be very convenient, if only the code was actually all in the same parent directory, or even in the same SVN repository.

A: 
  • Can I make these maven.7762323 directories go away?

Where do they come from? What do you mean exactly by checked out as Maven projects?

(EDIT: As the OP wrote in a comment, these directories come from m2eclipse that allows to check out maven projects from SVN. I don't use this feature so I dont know much about it. However, after some googling, my understanding is that these names are kind of temporary and m2eclipse should rename them at the end of the checkout. Maybe something something went wrong with eclipse during the checkout. I'm not sure actually.)

  • If not, is there some way in Eclipse to get the path to a project directory, and then pass that as a system property in a launch configuration, or something like that?

Eclipse has a {build_project} variable that could be used in the arguments of a runtime configuration. Maybe {workpsace_loc} would be more appropriate in your case. The whole list is available with a description in the Arguments tab of a runtime configuration.


(EDIT: I'm still not sure I get the real goal but I have the feeling that using svn:externals could help.)

Pascal Thivent
m2Eclipse provides a "check out as Maven project" option in the SVN repository view. I'm not sure what all this does, but I suspect it for instance creates Maven-aware .classpath and .project files if such don't already exist.
David Moles
in a real deployment there's no relative-path hackery b/c the files in question end up in a subdirectory under core/runtime. these include for instance configuration files that are edited by the user after deployment. these resources are all optional, built separately, and deployed by unpacking various zip files. it's a mess that I inherited and the plan is to replace the home-grown crap with something like OSGi, but that's not on the table for the next two months, and we have a release to get out between now and then.
David Moles
A: 

Okay, solution was to use {workspace_loc:project name} variables to set a handful of project directories as system properties, and use those to infer everything else. Now if I can just figure out how to get the ridiculous system for loading plugin JARs to work with Maven...

David Moles