开发者

How to determine at runtime the path to a Mavenized Eclipse project directory

开发者 https://www.devze.com 2022-12-12 05:37 出处:网络
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 prob

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, i开发者_运维问答f only the code was actually all in the same parent directory, or even in the same SVN repository.


  • 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.)


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...

0

精彩评论

暂无评论...
验证码 换一张
取 消