1

Let's say I have a java file C:\workspace\project\src\packagename\foobar.java. Now, I would like to compile this file at runtime, but for that I need the corresponding .classpath file (or rather, it's entries), located at C:\workspace\project\.classpath, so that I can pass the dependencies with the -classpath argument (this approach works if I hard-code it, but that's obviously only proof-of-concept, not the goal).

How would I go about finding the .classpath file?

My idea was walking the file tree bottom up, starting at foobar.java, until I get to a level where a .classpath file exists which I can then use.

However, I'm a) not sure that this is the way to do it, and b) not sure how to walk the file tree bottom up, other than String.split-ting the file and removing the segments, starting at the end. That is super ugly, though, and I refuse to believe that there is no better option.

PixelMaster
  • 895
  • 10
  • 28

1 Answers1

1

It sounds like you are asking how to write Java code that understands the layout and structure of say eclipse project directories. To then "mimic" eclipse and compile files for you.

This is probably a really bad idea. You see, unless you are talking about very small and "reduced" projects only, sooner or later, you will encounter projects that are large, and each one a bit different than the other. You will be constantly trying to get things right, and each time you fixed a bug, another project comes along and something new shows up and your solution breaks. Because you can't get a robust "copy" of the eclipse build code unless you use that build code.

Thus my suggestion:

  • figure if there is a way to drive eclipse (or whatever IDE project files you are talking about) via command line. Use the build code that does know how to build these things. See here how to do that for eclipse.
  • see if it is possible to change such projects to have a maven/gradle build configuration. because then you can easily build that thing using maven/gradle
GhostCat
  • 137,827
  • 25
  • 176
  • 248
  • What about *ant*? What I meant, if I don't want to use maven or gradle... – zlakad Mar 08 '18 at 18:40
  • @zlakad Well, it is 2018, isn't it? *ant* is for sure an option, but one that feels more like 2005. Meaning: when you start thinking about build systems today, then picking *ant* would probably be an indication that something about the solution is fishy. – GhostCat Mar 08 '18 at 18:43
  • Yep, but I have some hard feeling that all of these tools will be obsolete when we switch to JDK 9 + – zlakad Mar 08 '18 at 18:46
  • the projects *do* have gradle build files. What I want to do is take a number of tests, apply a series of regexes that perform some basic replace operations, and then execute the changed tests again to see if any errors occured. If so, I open the failed tests in Eclipse. Anyhow, I don't really know anything about building a project with gradle at runtime, either. Do you know a good place to start? – PixelMaster Mar 08 '18 at 18:46
  • Start by opening a command shell and running gradle manually. Then take the corresponding commands have them run with java. – GhostCat Mar 08 '18 at 18:47
  • @zlakad And why should that be? Yes, java9 introduces a module system. And of course people building tools have to adapt their tools, and people **building** projects with tools have to adapt their project settings (and possibly source code) to stay in business with java9. Sometimes people put a **ton** of effort into their build setup - do you really think they will throw all of that away because the JDK comes with *some* tooling that is a bit better here or there? Sure, jlink helps putting together modules. But these modules must still be **built** before you can use jlink to link them. – GhostCat Mar 08 '18 at 18:51
  • Well ... I guess I could have come up with that myself. Dumb me ^^ – PixelMaster Mar 08 '18 at 18:52
  • @GhostCat Well, it was just my opinion - I am letting the possibility it could be wrong. Battles will go on ;) – zlakad Mar 08 '18 at 18:56
  • @PixelMaster, welcome to the club (dumb me, also). :) – zlakad Mar 08 '18 at 18:59
  • @PixelMaster Well, seriously: think simple. Try to "invent" yourself as few things as possible. Gradle is a command-line focused tool, and it is *designed* to be running within a JVM (formerly using groovy, now with Kotlin). Besides that, let me know what else I could add to get into upvote/accept areas ;-) – GhostCat Mar 08 '18 at 19:24