I have a Scala project I share via git between two (windows) machines. I have them set up using SBT and sbt-eclipse so I can edit and test within eclipse or build and test from the command-line.
Unfortunately my user name (and, therefore, the user profile directory) is different on the different machines. This means that when sbt fetches dependencies it puts them in different base directories on the two platforms. This wouldn't be a problem except that the full pathname is hardcoded into the eclipse .classpath file from sbt-eclipse. This means that I have to rerun the 'eclipse' task when I do a pull on my 'current' machine.
This must be even worse for others who do this kind of thing as a team. How is this normally handled? I would prefer to do a pull on whatever machine, even from within eclipse, and get started right away.
I would strongly recommend removing the eclipse-sbt-generated files (and all other generated files) from git. Each machine will have it's own .classpath file that is generated on that machine that is generated on that machine for that machine and can be regenerated whenever you want/need. Your build.sbt project files should be in git, so when you pull onto each machine, it will have the updated config, and you can just run sbt eclipse only when you have a dependency change.
Really, you should always avoid having generated files in source control. Have only the important stuff in your git project, and generate the rest as necessary.
Related
We have some Maven modules shared between several teams, with the mandate to share the source code even though our projects use different dependencies and resources. To accomplish this, we have our modules set up as recommended in Using Maven When You Can't Use the Conventions under "Producing Multiple Unique JARs from a Single Source Directory." Specifically, we have a shared parent module containing the src directory but whose pom declares <packaging>pom</packaging> and only builds the two submodules. Each submodule inherits from this parent and refers to the shared src directory using this:
<build>
<sourceDirectory>../src/main/java</sourceDirectory>
</build>
The two submodules have different artifact ids, allowing dependent modules and projects to specify which version and dependency set they need. It also upholds the Maven principle of "one module, one output."
This all works great in Maven-land: compilation, installation, deployments, etc. What doesn't work well is Eclipse integration. Some things work fine: building the modules, deploying to our Maven repo, pulling in dependencies to build our project. But things such as code completion and jumping to class/method definitions do not work at all. It's as though Eclipse doesn't recognize the source at all.
If we just check out a module from SVN, Eclipse doesn't know about the classes but instead uses jars from the repo. If we then import the modules as Maven modules, they show up in package explorer and the project build path. However, all references to those classes and methods are now flagged as errors by Eclipse. And we still do not have code completion or navigation.
So my questions are these: How can we get Eclipse to recognize the code and do its normal code navigation while still satisfying our varying project requirements? Am I missing some simple Eclipse configuration? Do we need to rework our Maven module structure, and if so, how?
Some additional context: The different dependencies for the projects are rather large, including different major versions for things such as Weblogic and Spring. The Weblogic versions will converge some time next year, but the other dependencies will be slower (and some resource files will likely always remain distinct). So for the near- to mid-future, we have to account for different dependencies between the projects.
We are using profiles to allow our Jenkins server to build both submodules while allowing individual developers to build only the submodule their project needs. Using profiles to manage the dependencies is problematic because we lose transitivity of dependencies.
Update (12/8/15)
I was eventually able to make Eclipse recognize the source directory by using "Link Source..." on the "Configure Build Path..." dialog. Adding a source folder would not let me reference the module's parent directory, but Link Source let me assign an arbitrary directory to use. It's not ideal, but it seems to be working.
I was eventually able to make Eclipse recognize the source directory by using "Link Source..." on the "Configure Build Path..." dialog. Adding a source folder would not let me reference the module's parent directory, which derailed me for a while. However,Link Source let me assign an arbitrary directory to use.
It's not ideal, but it seems to be working. We can now jump to definitions with F3, and errors are now highlighted correctly. It's good enough that I don't feel bad recommending it to the other team. I wish Eclipse would automatically allow a parent source directory to be referenced, but at least the manual intervention worked right.
This is my first time using SVN or for that matter any version control. So, I've been able to check out a selenium project on my local machine. This source code was working fine on the other machine(my friend's), but on my machine it throws hundreds of errors such as "BeforeClass cannot be resolved to a type, Assert cannot be resolved to a type" etc.
I do know that this error could be because the required selenium jars may not have been setup in the build path. But, I can see all these selenium jars in the "lib" folder.
So, I want to understand if I need to reconfigure the build path. By the way, don't the project settings etc come by default as the same code works perfectly on other machine, which means the build path must have been configured there.
I know its a very basic question, but I assure you that I'm a naive coder.
Thanks for your help.
Note: I'm using Eclipse IDE
Eclipse's project configuration files (eg, .project, .classpath, .settings, etc) are designed to be checked in with the rest of the project. If done so, whenever the project is checked out to a workspace Eclipse will automatically use them to properly configure the project. Check that your friend checked in those files; if not, ask him to.
It looks like you did not add Eclipse project metadata files(.project,.classpath) & .settings folder to your source control system, so Eclipse doesn't know what your build path is or whether it is even a java project.
Go back to your other computer and look for the following files in your original project root...
.project
.classpath
.settings/*
Make sure all are present in Source Control System.
How to initialize a new Scala project in sbt, Eclipse and github, so that it all plays together...
A new Scala project typically requires being set up for sbt, eclipse (if you so choose) and github such that it all works together. After investing some time on this setup, it may help to have this list for aligning these 3 tools/services, for as long as simpler ways are not available. The series of steps that works for me follows. It assumes you have the Scala IDE plugin installed in eclipse.
Create a new repo in Github.
Decide a directory location for the new project
In eclipse, use the Git Repositories View to import the Github repo into that location. Alternatively you can use command line git for that.
Locate to that same location you've chosen for the project and run sbt eclipse. This makes sure eclipse will be able to handle the sbt project structure, so that your project can be built by sbt while also being intelligible for eclipse. If sbt eclipse doesn't work, the sbt eclipse plugin is probably not installed in sbt - install it.
In eclipse, use File --> Import --> General --> Existing Projects into Workspace, selecting that same location, so that eclipse builds its project structure for the file structure having just been prepared by sbt.
Make git ignore all but the core of your new project by updating the .gitignore file to ignore eclipse and sbt files. The following seems to be currently fine.
*.class
*.log
# sbt specific
dist/*
target/
lib_managed/
src_managed/
project/boot/
project/plugins/project/
# Scala-IDE specific
.scala_dependencies
# Eclipse specific
.project
.classpath
.cache
You should now be able to run the project in eclipse, and in sbt, and commit and push code changes through git. To see the empty project run, which may very well make sense at this stage, you can add a scala class in eclipse to it, containing merely the following code. Note that scala sources should typically sit under src/main/scala. If this path doesn't exist yet, create it through e.g. mkdir -p src/main/scala on Unix.
object hello {
def main(args: Array[String]) {
println("Main starting")
}
}
Or alternatively only this code:
object app extends App {
println("Application starting")
}
It should work now.
Need to disclaim that future versions of eclipse, sbt, etc may render this outdated.
If this is dead wrong in your environment, you can add a better answer.
Previous answer/s is/are of high importance as well as the question since these tools are not self explanatory. Based on personal experience with this challenge which seemed impossible but when one acknowledges few key insurance policy reference points things will become reality:
Implementation of development environment may require radical
re-installation as new tool is adopted (if you adopt GIT after you
already had SBT in place you may need to empty SBT's working
directory as GIT require the cloning process to have empty house on
local working directory)
Keep really well updated backups especially when considering
re-setting any of this "domino" environment layers as some of the GUI
or command initiated cleansing operations truly take care of that
sometimes with surprising effectiveness and without any regard to
other tools / layers requirements
Keep really good documentation (including previous pragmatic answer) on key stages to
make things a reality (again)
I have a play framework project which run on remote server.
I'm trying to configure eclipse to work remotely on the project.
since no build is required my requirements are to be able to edit the project files from eclipse and automatically save on server, auto complete and debug.
I've installed Remote System Explorer on eclipse and setup a remote ftp connection to my server.
The play environment on my server is under
/play-2.0.2/
My project path is
/play-2.0.2/test
In RSE I clicked on /play-2.0.2/test and 'Create Remote Project'
Now in Java perspective I can browse through the project, change files and then automatically save to server.
My problem is auto completion of play framework library doesn't work well since all the reference are to /play-2.0.2/repository/...
any idea how to solve it? I tried to play with the build path but no success
Thanks!
So, I was looking into achieving the same thing myself.
The problem you are experiencing is due to the fact that the .classpath file has absolute values. While for me, besides the symlink that doesn't work between two different kinds of O.S., I thought on another two solutions:
Use sed to rewrite the classpath on the .classpath file after it's generated
Use a "classpathTransformerFactory" for the sbt eclipse command
I haven't had to deal with it (it's more of want to than whatnot) as soon as I do, I will explore the two options and post details. I just leave the answer here in case someone wants to pick up where you left.
Another thing is:
Seen that sbt picks up the libs referenced in build.sbt, downloads the jars and puts them in the ~/.ivy2 directory, if you use any of those methods to change the reference from the remote machine to the local one, you would need to make sure that the same libs are on the local ivy cache. So, just as I wrote this, another idea came to mind:
sbt eclipse or play eclipse or activator eclipse [it should be the same] on a local environment, and on the remote one, then, transfer the .project and .classpath files from the local to the remote, and see what happens (if it doesn't work, scan them for absolute and incorrect paths that might need to be changed)
Sorry for the unproved answer, still I think it's better than no answer.
Cheers
I have a bit of code for a dll that is needed by two or more projects in eclipse. Currently each project has a copy of the code and builds the DLL separately. I want to separate the dll code into a separate eclipse project so there is a common location. But I want to avoid the situation where we have to build the dll in the one project, then copy the dll back to the other projects and check the dll to each respective project. This will create a dll for each project that isn't traceable to the exact code that it was built with.
Is there a way to somehow symbolically link the dlls to another eclipse project that is using CVS as the version control system so that it is possible to tell which version of the code was used to create the dll? Am I making this too complicated or missing something obvious?
I thought about working sets in the package manager for eclipse, but I have to investigate more on how to use them with CVS to avoid making it a nightmare for the next person who checks it out and can't figure out why their project won't compile.
Thanks.
What about creating a new folder in a separate project. In the advanced section of creating a new folder there is an option to link to another location on the file system.
Or you could also create a container project that makes use of a projectset.psf file. Have the projectset file link to the different projects in your repository. When you want to check out that project, check out the container instead and right click on the projectset file and select Import Project Set...
If you are working with one workspace, you end up with three projects, each mirrored in CVS: One is the dll, the others are the projects using the dll (configured as a project dependency of these projects upon the dll project).
With three projects I wouldn't aim for working sets - they are good for managing a lot of projects within one workspace, for three projects, I'd consider them overkill. I usually tend to aim for several workspaces instead of working sets.
Regarding the next person working with these projects: You need to keep some kind of documentation about how to setup your projects. You might say that your eclipse project files do just that (as they define a project dependency upon another project) but this is for the machine - humans tend to like other communication means.
If you are worried about changes to the dll being incompatible to one project (because the person applying these changes doesn't care about the other project), aim for a build server. This will build all projects and dependent projects whenever something under version control changes, run all tests, provide a build number and package it all ready for use. This way you can be sure that - whatever is in your deliverable - can be reproduced, because the buildserver is not able to make local (uncommitted) changes to the code. Also a buildserver will signal failure (either broken API or broken tests) at the moment of the last commit (well - a few minutes later) and place the burden of repairing the damage on the one causing the damage.