We as a development team were always happy with subversion and eclipse, we checked in everything and everything was fine. Until we had a new hire who's using anything but eclipse (RAD ). his RAD checkins are currently polluting the svn repo withholding our eclipse checkouts to finish building.
One solution may be to force eclipse in the new hirer's throat, another more subtle and probably more suitable approach is to make our project ide agnostic.
Instead of removing the files by trial and error I hope to learn a quick and reliable solution.
I already learned that i should
remove files and add them to the svn
global ignore. I'm wondering is there
a way to make this project wide
instead of having everybody fixing
their own svn config? Something to add to your root .svn directory?
I'm also
looking for a list or even script to
remove the eclipse files and
directories from the svn repo
(.project .settings .classpath??
.externalToolBuilders .springBeans)
without running the risk of
completely ruining the workspace.
I'm
also intested in finding the quickest
way of restoring the workspace, as
we're using maven for software
project management I can do mvn
eclipse:eclipse in the root of
workspace but how do I find what the
proper WST settings are, and what is the quickest way or restoring your path settings in eclipse ?
I thought that many people would have been faced with the same use case, and consequently had the same questions but I haven't found anything on Google yet. Hopefully somebody here can point me in the right direction.
If you want to have a language-agnostic code repository the question is less about which files to exclude that about which files to include. Meaning, in a language-agnostic repo there should really only be the files necessary for the project:
source files, libraries, property files, .xml config, ...
built stuff, i.e. .class files, archives, ...
You should certainly exclude:
.project - this is project specific config by eclipse
.settings folder - this is project specific config by eclipse
.classpath - also eclipse specific
In Eclipse there is a 'global' ignore list for files which are shared to repositories via SVN, CVS, etc. You can find it here:
Window > Preferences > Team > Ignored Resources
If you're looking for something outside Eclipse, try the global-ignores config in your local subversion config. Add this to your ~/.subversion/config file.
global-ignores = build *.mode* *.pbxuser *~.nib .DS_Store *~
Mind that if excluding the Eclipse config from the repos you'll have to set up your projects after a checkout more specifically.
However, as you say you're using Maven this should not pose too many problems for you actually. If the pom.xml files of maven projects are configured correctly and completely, you can easily import a project from SVN via 'Import as Maven Project' - Eclipse will do all the right config for you on the import. (For this you need the m2Eclipse Maven Plugin, but I guess you'll be using something like that already? Anyway, here's the link: http://m2eclipse.sonatype.org/sites/m2e )
As for your question concerning a script to clean the repo: I'm not aware of such a thing right now, and I'd be very careful with this. Sounds like a lotta things could go horribly wrong. ;)
Last but not least, restoring the workspace:
In my experience, it is often the easiest thing to just delete your project locally and to a fresh checkout 'as maven project'. This way Eclipse will reconfigure all the important stuff. I have spent hours on broken Eclipse config, sometimes it tends to just get stuck and fails to be able to recover - especially if you're working with a lot of plugins which tend to do some of their own configuration magic. (And happen to be not exactly bug free...)
Related
I am creating a java project in IntelliJ (without maven or grandle). The project uses an external library, whose .jar file I’ve put into a /lib directory. After that I had to select at the /lib folder “add as library” to use it.
Now I want to push the project to GitHub, so that some people (who are using IntelliJ as well, but in different versions) can use the project.
Now my question:
Is there a way, that they do not have to do the step “add as a library” themselves?
My first idea was to push also some parts of the .idea folder to GitHub, but I am not sure which ones to push and if that could actually work (especially with different versions of IntelliJ).
Do you have any idea how to solve this issue?
If you are using only IntelliJ for building the project, then yes, you should push the .iml files from the .idea folder (or where they happen to be), since they contain the dependencies configured in IntelliJ.
Note, that projects with multiple contributors typically use a build tool like Maven or Gradle.
This is a special build requirement, which I would use Gradle for. With Gradle you can look up a given folder, like /lib and use all .jar files as dependency.
See Gradle example about exactly what you want.
IntelliJ is handy when you do something simple mostly for learning, but if you want to be a professional one day I highly suggest looking into Gradle. It has a learning curve for sure, but you can achieve such simple tasks like this in your question relatively simply. And as you seem to know, pushing .idea to the repository is really not the nicest thing one can do :)
Just a small additional note: Gradle solves the "different version" problem by including a "Gradle wrapper" inside the repository, so everyone cloning the repository will have the same copy of Gradle as well, so the same build process is guaranteed for all contributors.
Also, when I started programming I downloaded the dependencies and used them as jars. But if you learn at least Maven, and your dependency is uploaded to a repository like Maven Central, you can just paste a line of code into your pom.xml (Maven) or build.gradle (Gradle) and you are good to go :)
I'm following this tutorial: http://spring.io/guides/tutorials/rest/ to get familiar with spring/REST. However, the git repo (git clone https://github.com/spring-guides/tut-rest.git) has many individual java projects each with their own gradle build. I'd like to edit the code in Eclipse, as that's the whole point, but this hasn't proved trivial.
So far, I've created a general project for the git repo, and then separate java projects for each of the folders from the repo, linking the source in my java projects to the source/test folders in the repo. This has worked great except that I don't have the spring jars in my dependencies for the java projects, I get a ton of errors as well as lose the nice autocomplete of function names, etc.
What is the correct way to fix this? It seems like there isn't a good way to install the jars for spring in each java project without using maven or some other build tool, which seems redundant and inefficient since I can build the source from the repo project. If this is the case, should I make a build for each separate project even though the idea for the tutorial is that they each come with gradle?
Thanks for your help, and please excuse the slight open endedness of it--I'm not sure I'm on the right track.
I work with a partner in java programming, I use intellij and he uses Eclipse.
Is there a way that we can somehow mutually share our code with each other so we could work on the same code each in our own time?
Thanks
There is that possibility using GIT or another Code repository. Look at https://github.com/
or https://bitbucket.org/. There is also very helpfull article.
To be also independant you can simply integrate your code with Maven, both incellij and eclipse can import project based only on pom.xml file created in maven setup.
In this your should use repository when there are more than one programmer on a single project whether you are using even same IDE. SVN will be one of the choices for repository
Given that you guys need to implement version control, one important aspect of co-operating together is to keep your codebase IDE-agnostic.
Thankfully, with java and maven there is an easy way to do this.
Firstly, commit to building your project with a build tool such as maven. Therefore, using this example, the pom.xml is the master configuration file for your project.
In contrast, your "project" files (either your .idea folder for intellij or your .project, .classpath and related files for eclipse) should not be checked into version control at all.
You can then add "ignores" to your VCS so that IDE-specific configuration files are not checked in - this way you won't interfere with each other with IDE-specific things.
Then, it is relatively easy for both of you to share a maven (pom.xml) based project with each other, and to configure your IDE independently from each other (i.e.: locally).
.project files contain references to the project natures used in the project.
These project natures are dependent on the plugins installed on the local developers machine.
So, should this file be excluded from SVN?
Will nautures unknown to other developers cause problems?
Thanks
It depends on your situation.
Indications for putting them under version control:
you are talking about a team in a company context. You should be able to enforce a common developer environment, unless you also have an organizational issue.
everyone is using Eclipse
you want to make it more easy for newbies to just check out the project as such from SVN (without recreating it as a new project)
Indications for not putting them under version control:
the people (or IDEs) working on the project are very different (like in public open source projects)
you want to also use the project on an integration server like Hudson/Jenkins. You need to use Maven or some other standardized artifact lifecycle management tool outside Eclipse then.
The best solution: Use Maven to describe your dependencies and build process completely independent of Eclipse. Afterwards use Tycho to "act as a broker" between the Maven and the Eclipse world. That way you know exactly what to put under version control and everyone will produce exactly the same builds (independent of what IDE he uses or which plugins are installed).
I never commit those (esp .project) and always vote for them to be svn:ignore'd. Maybe I'm wrong but I only commit code to SVN and then make a new project by checking out from SVN.
Every time I checked out a project which had those files commited literally BROKE my project. But then again maybe thats just my coworkers...
By breaking i mean converting these
src/com.package.name1
src/com.package.name2
src/com.pack.name1
src/com.pack.name2
to these
src/
src/com
src/com/package
src/com/package/name1
src/com/package/name2
src/pack
src/pack/name1
src/pack/name2
and other sorts of unnecessary irritations... like them not being recognized as packages anymore but as folders. One of those things that makes you have to run eclipse -clean or delete/reimport a project or waste time on eclipse stuff you don't wanna waste time on.
It is the following situation:
I currently have multiple Java projects in Eclipse. All the sources, build files etc are checked in at a repository. If a new team member joins the project he has to rebuild the complete setup (setting build path dependencies, adding special libraries).
I thought if that could be automatically done some way, e.g. using an ant file to do all the configurations of eclipse or the servers (tomcat).
Anyone ever found a solution for this?
Check in the .classpath and .project files and you should be set!
(More information about the .project file.)
I believe that you might use Maven too.
But that would require quite an adjustment, I believe.