OK my problem is quite simple
Im about to start working with a team of programmers, and we are using a svn repository to store our code, thy files are set up as Eclipse Project as the rest of my team all like eclipse.
However I am die hard netbeans man, I have tried eclipse Iv given it some time but we do not gel as they say.
So my question is there a combination of plugins /hacks that i can use to access a Eclipse Project from an SVN repository inside Netbeans , without corrupting the eclipse project or causing problems for the rest of my team (I would rather suffer eclipse than do this to them)
Many thanks ^_^
In NetBeans 6.8 under File > Import Project there is both Eclipse Project and Resynchronize Eclipse Projects. I'm guessing this can be used to work together with people using Eclipse.
UPDATE: How the eclipse import function works.
As NA pointed out, there is a way to import your Eclipse projects into Netbeans. However, arguably, you shouldn't be checking in IDE-specific files into your repository unless you can guarantee everybody is using the same IDE. Otherwise, I would recommend only checking in the source code, resources, and additional libraries and keep the specific files on ignore and have each individual setup their own environment.
Another alternative, is to check in the IDE-specific files in a different folder in the repository so that an individual can grab them if they need them.
Related
for someone it may seems a little weird but still I want to know if it's possible or not. We have a lot of projects which coded on eclipse so far and some of us wants to jump into intellij idea world.
Can we be able to run the projects via eclipse and intellij together at the same time? I mean for instance I'll be using intellij idea while another friend of mine will be using eclipse instead of intellij idea on the same projects, is it possible?
If it's possible, would it create any problem for version control systems such as subversion?
Subversion will have no problem at all, but I recommend you in that case that you rely your java build configuration (sources, compiler level, dependencies, etc.) on maven or gradle instead of doing it twice, once for every IDE you are using. Then both maven or gradle should be able to generate IDE-specific configuration files for each environment and you would work in the same conditions.
Actually I like the idea of working with a managed and automated build process, so if anyone is brave and bold enough to use vim... they can use it without problems, and still build their app.
Can we be able to run the projects via eclipse and intellij together at the same time?
Yes, because these IDE store their project data and configuration in different files, so they don't step on each other:
Eclipse stores its files in .project, .classpath, .settings
IntelliJ stores its files in .idea, *.iml
If it's possible, would it create any problem for version control systems such as subversion?
Not at all.
Btw I do this too sometimes: I have projects where members use different IDE: IntelliJ, Android Studio, Eclipse, with no problems.
I am trying to use Eclipse, Subversion and Maven for my projects and everyone is telling me never to check in the following files:
target/
.classpath
.project
.settings
But if I dont check them in and some other project checkouts the project from within Eclipse, Eclipse does not know what type of project it is.. Are we doing something wroung?
How do you work?
Eclipse has a plug-in for Maven; I believe it is called m2eclipse. After having it installed you can select Import from Maven project and select the pom.xml which will import your project to eclipse even if .project and .settings are not present. So there is no need for you to commit them to svn. This comes with the advantage of IDE neutrality; other members of your team may use Intellij IDEA or NetBeans without any concern.
Also Maven has a plug-in for eclipse; you can go where pom.xml is located, open a terminal and type mvn eclipse:eclipse and it will automatically generate .project and .settings.. However the first option is more recommended.
I had the same issue with eclipse, maven and git, so maybe it is helpful for you:
Try to setup your repo in svn and check it out, but don't import it.
You have to import the project over File -> Import -> Existing Maven Project into your workspace.
The last step is to share the project. Rightclick -> Team -> Share -> SVN -> and set the existing one as repo.
That's the way I handle this in Eclipse. Hope it's clear enough?
Btw you should not check in these file, because classpath and so on could be different on other machines.
I check in .classpath and .project but not very often. You do have to make sure that everyone who is working on the project has versions of eclipse that are close enough (including the particular plugins and eclipse features included). Sometimes you can get by with very different versions of eclipse if you make sure almost nobody checks those files in and everybody just mostly compares and manually updates those files from the version control when they are updated.
If you don't check them in, everybody has to create an empty project and then load the source files (and all the version control files or folders) into the project. If you are careful you can copy in those two files and then fool with the options settings to make them match.
Note that Maven helps a lot with this as it takes care of most of the content of the .classpath file.
The main reason not to check in those files are that the IDE's will very likely make changes to those files to suit your local dev environment. Which will probably cause conflicts and thus "broken" projects if everybody is committing their versions all the time.
That said, eclipse should have decent maven integration via the m2eclipse plugin (which I believe might be baked in by default these days).
Part of the idea behind Maven is exactly this - reproducible builds cross platform, cross IDE etc etc - so IDE specific files like that should not be required to build the project.
Importing the project with the m2eclipse plugin should sort things out nicely.
If you mean the other members check out the project and it doesn't work for them, they can check out the maven project separately without using eclipse and then import it into eclipse as an existing maven project using the m2eclipse plugin. This works cleanly without any problems (for me at least).
if everyone in your team is using Eclipse and it is agreed that the project will never use anything else, you may as weel check those files in. but it will make things kind of irritating if someone uses IntelliJ, Netbeans of other tooling or has his Eclipse very customized.
It depends.
Maven documentation explicitly says something like "Do not check in .project/.classpath/.settings/ because they can be regenerated from pom.xml". The later part of the sentence ("they can be regenerated") is not true, so the first part of the sentence (the advice) may or may not be OK, depending on the circunstances. Not every bit of the Eclipse configuration can be regenerated from the pom.xml, so my opinion is that the decission is based on a tradeoff between how much gain you get from it and being tied to the particular IDE.
So it depends.
For "community projects", where usually each developer will use different IDEs and different versions of the IDE, I would recommend not to check in those files. Otherwise, it would be a pain for developers not using your IDE and your version of the IDE.
For large "corporate project", IDE and IDE version are not free to be choosen by the developer but firmly dictated by the project management. So are dictated things such as compiler(1), code formatting, validating rules, warnings-and-errors configuration, custom in-house plugins configuration and many others. Many of those things cannot be set in pom.xml (nor should they because Maven is not and IDE, but a building tool). So in this case I would recomend to check in those files and blame the developer who complies, because he is trying not to follow the dictates.
(Notice that in this case I intentionally used words such as "dictate" and "blame" because the project management of a corporate project has not only the right but also de duty to "dictate" and "blame")
In the opposite side, for one-person projects, you do not have to worry about your colleages, so go check them in.
But the key is that you have to know your circunstances and the consecuences and decide yourself.
(1) No, "maven.compiler.source" is not the compiler to be used.
For a Java project (with the team of 5-10 developers) should I store my IDE project files (e.g. Eclipse or IntelliJ Idea) in version control system (currently I store only build scripts)? What's the best practice?
PS Do you aware of any tools to automatically generate project files for common Java IDEs according to some descriptor?
You might want to take a look at the answers to this question: Which eclipse files belong under Version Control. As to the second part, maven has plugins for IntelliJ and Eclipse at least.
If you care about the project file at all, then you should check it into a VCS. Really, you might not care. But if you do, VCS it...
Our team (6-8 developers) originally checked in project files, and soon found that they can cause problems when it comes to paths and build path, etc. Usually not, but when an issue did arise it could take time to ferret it out. Then we stopped doing that, and it has worked much better. We now put definitions in the VCS ignore files to make sure they don't get in. However, in our case we work with Maven, so the practice has been create an eclipse workspace and then import the Maven projects from the source. So recreating project environment is quick and predictable. From my experience, checking in can cause minor headaches.
There are different opinions. Once I was told that I shouldn't put project files in VCS, but then project files ware added to repository (not accidentally).
Many open source projects have project file in VCS. I think it could be good practice if one particular IDE is proffered in other case developers should probably take care on project files by themselves.
Maven can generate project files (at last for eclipse)
I have a project which has shared functionality between three other projects and have linked these to existing projects as I normally would using the add project functionality of the libraries folder.
This all used to work however when I started up Netbeans yesterday it just wasn't working as in the other projects won't compile even though the projects are linked. It can recognise the packages - just the actual classes themselves were not recognised... and to add to the weirdness some of the classes are getting picked up fine.
I have checked the dist folder of the shared project and the Shared.jar file exists. Also I have checked the Jar and the other classes that are not being recognises are there also.
Any suggestions?
alt text http://inverse.seednet.eu/snaps/duvc6r.png
Solution
I had to reinstall netbeans to get this solution resolved
This is most likely a bug in 6.8, as I have ran into the same problem and I only solved it by recreating the project, was a fairly fast process, only had to re-import the sources and then add the JARs on which it depends.
To confirm this case you only have to see the imports that NetBeans did not find, and then go to the included JARs and see if the class really is there, if it is, then it should be able to find it.
Do you have AbstractCrawler.class compiled to its output location as well?
I'm having a difficult time figuring out how to add a .jar/library to a Netbeans project in such a way that I can get it committed to the repository.
The typical way to add a library (per the Netbeans documents I've already gone through) ends up with it just being local to me. Anyone who checks out my project ends up missing my required library.
Inserting it manually and trying to work around Netbeans results in Netbeans hanging while trying to scan the project...
So, how can I tell Netbeans to pick up a jar as a library and include it in my project in such a way that Subversion will be able to handle it?
There are a couple ways to fix this.
A. When you define your Library, use a path to a common location. A location that's identical on everyone's machine--such as the location of a JAR installed with a third-party app into Program Files or /usr/local/ works well or a network drive.
Then, when they check-out the code, the path will still be correct and they do not have to define the Library on their Netbeans workspace.
B. Edit your project.properties file to use a relative path. Open your project.properties file and look for "libs.LIBRARY_NAME.classpath=...". That will be the "default" location used if the Library is not defined.
Change this to use a path relative to your project and store the jar files in your project. For example:
libs.Log4J.classpath=lib/log4j.jar
Keep in mind that the Library definition in your Library Manager will override this value--so make sure you keep them in-sync (i.e. append a version number to the library name!).
C. Use Vincent's suggestion of using a build-system such as Maven. The Maven build-process will take care of downloading dependencies, etc. Netbeans has plugins for several popular build systems.
There is a new feature in NetBeans 6.5 (variable-based paths in projects) which should make this easier.
See http://wiki.netbeans.org/NewAndNoteWorthyNB65#section-NewAndNoteWorthyNB65-VariableBasedPathsInJ2SEJ2EEProjects for details. Note the screenshot includes variable references in the library customizer.
Not really an answer to your question but... generally you should not include these libraries in your subversion repository. There is usually no need to have them managed. What you might want is to set up a central repository similar to what happens with maven. If you use maven, you can create a local repository of libraries on a server accessible by the team. The dependencies on these libraries are entered in the pom.xml file and this is in the subversion repository. Now, as team members check out the code from subversion they all have access to the maven repository.
[I am looking for a reference to this right now. When I find it I'll edit this answer.]
I use NetBeans IDE 6.5.1 and the best solution I've found so far is to include the needed libraries from your local host and then change their paths to relative. After that you have to remove the libraries manually from the NetBeans file explorer, and then copy them from their OS location in your computer manually to the file explorer again. That way NetBeans detects the change and you can commit it to the repository.
Note: I Highly recommend to clean and build the project again after updating.
An easy way to pack up your lib/jars into your project so that subversion "just handles it" so you can grab it out with all the attached libraries ready to compile and go is to include them all under your project directory via the "shared libraries" option by managing the libraries folder.
When creating a new project you can specify "Use Dedicated Folder for Storing Libraries" and then use the suggested relative .\lib path. If you have an existing project, you can edit it's properties, Libraries Category, and Browse for a Libraries Folder. Again a first-time run will suggest .\lib and then offer to copy existing dependencies to that folder. These graphical actions should provide similar results to James Schek's 'B' answer.
Commit the project with the newly added libs in .\lib and you should be able to checkout and build from anywhere and know you'll have the same libs (at the same version) as you had when you last built and committed.
I don't know how long this feature has been in NetBeans. For more details see:
http://netbeans.org/kb/docs/java/project-setup.html#projects-shared-libraries
I ended up just downloading my own set and putting them on my local drive for this project. I setup my Netbeans to look there and warned the other guys what I did... Eventually, we'll have to do something a bit more scalable though... :-)
OK, the working solution that I've now moved to is to extract the class files out of the jars and dump them into the Source Packages area. Then it all gets committed to the repository and also avoids having to deal with handling a separate "lib" directory in the deployment phase.
This solution does everything I'm looking for, yet I feel real dirty about doing it this way. It just seems horribly broken and wrong... :-)