add support for linked folders in Eclipse #124

Closed
wants to merge 5 commits into
from

Conversation

Projects
None yet
3 participants
Contributor

earldouglas commented Jul 21, 2012

Eclipse has support for including code from folders external to a project directory, by creating a "linked folder" and adding a classpath entry relative to that linked folder. For example, the following Eclipse configuration will allow usage of /path/to/alternate/location/sources/common/src/main/java as an Eclipse source folder:

.project:

<linkedResources>
  <link>
    <name>src-common</name>
    <type>2</type>
    <location>/path/to/alternate/location/sources/common</location>
  </link>
</linkedResources>

.classpath:

<classpathentry output="target/classes" path="src-common/main/java" kind="src"></classpathentry>

The current version of sbteclipse blows up when trying to handle external folders such as this, because they can't be relativized to the current project directory. This pull request adds support for defining linked folders, against which sbteclipse will attempt to map external source paths.

To use this feature, the new setting linkedFolders is used in conjunction with external unmanaged source paths:

EclipseKeys.linkedFolders := Seq( ("src-common", file("/") / "ext-path" / "java-common") ),
unmanagedSourceDirectories in Compile ++= Seq( file("/") / "ext-path" / "java-common" / "src" / "main" / "java" )

@hseeberger hseeberger commented on an outdated diff Jul 23, 2012

...main/scala/com/typesafe/sbteclipse/core/Eclipse.scala
classDirectory: File,
state: State): IO[EclipseClasspathEntry.Src] =
io {
if (!srcDirectory.exists()) srcDirectory.mkdirs()
EclipseClasspathEntry.Src(
- relativize(baseDirectory, srcDirectory),
+ findInLinkedFolder(srcDirectory, linkedFolders).getOrElse(relativize(baseDirectory, srcDirectory)),
@hseeberger

hseeberger Jul 23, 2012

Contributor

Please use infix notation, i.e. no dots and parens

@hseeberger hseeberger commented on an outdated diff Jul 23, 2012

.../scala/com/typesafe/sbteclipse/core/EclipseOpts.scala
@@ -22,6 +22,8 @@ private object EclipseOpts {
val ExecutionEnvironment = "execution-environment"
+ val LinkedFolders = "linked-sources"
@hseeberger

hseeberger Jul 23, 2012

Contributor

Please use consistent names: Either change the name to LinkesSources or the value to linked-folders. If I understand this Eclipse feature correctly, I think you should change the value to linked-folders

@hseeberger hseeberger commented on an outdated diff Jul 23, 2012

...main/scala/com/typesafe/sbteclipse/core/Eclipse.scala
@@ -218,6 +221,21 @@ private object Eclipse {
<natures>
{ builderAndNatures._2.map(n => <nature>{ n }</nature>) }
</natures>
+ {
+ if (!linkedFolders.isEmpty) {
+ <linkedResources>
+ {
+ linkedFolders.map { lf =>
@hseeberger

hseeberger Jul 23, 2012

Contributor

Please use infix notation. Also, please use a speaking name, i.e. instead of lf use folder or linkedFolder.

Contributor

earldouglas commented Jul 23, 2012

Thanks for the tips, Heiko! I made the changes as suggested.

earldouglas added some commits Jul 23, 2012

@earldouglas earldouglas use infix notation 2841717
@earldouglas earldouglas use consistent naming for LinkedFolders/'linked-folders' 7aa69b3
@earldouglas earldouglas fix a path-related bug on Windows
Under Windows, when Eclipse imports a project it will replace
'C:\foo\bar\baz' with 'foo/bar/baz', dropping the 'C:\' and
replacing backslashes with forward slashes.  This causes
a problem in Eclipse, because it can't resolve 'foo/bar/baz'
as being on the C drive.  This fix adds an explicit replaceAll
from backslashes to forward slashes, which prevents Eclipse
from doing it wrongly.
08d54a5
Contributor

jsuereth commented Apr 10, 2013

Hey, I had an alternative take on this I added here: #156

This one is designed to "just work" without user configuration at all. Would love to get thoughts.

Contributor

jsuereth commented Apr 10, 2013

Also, I was unaware of this PR... sorry!

Contributor

jsuereth commented Apr 11, 2013

Hey @jamesearldouglas I think we're going to opt for the fix that requries no project-specific configuration for usage (keeping the plugin usable at a user level).

Would you want to add support back for explicit configuration? If not, I'll close this in a bit.

Contributor

earldouglas commented Apr 12, 2013

Would you want to add support back for explicit configuration?

Nah. I no longer have a use case for this, so I can't say whether it's still relevant given #156. Let's go ahead and close this one.

jsuereth closed this Apr 12, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment