I would like to have both Eclipse and Netbeans (with JUnit) installed on one system, so I can be somewhat familiar with both.
Besides GUI development (see "Using both Eclipse and Netbeans"), are there any other issues with using both IDEs on the same system, or even the same project?
We regularly use both Netbeans and Eclipse. We switch back and forth, between Vista, WinXP, and multiple versions of Fedora of the 32- and 64-bit variety, with no problems. Keeping the project files in version control makes keeping them in sync much easier. We even keep the launch files in the project directory as well. I posted a answer to another multiple IDEs question that describes what our project directory looks like.
Basically, I agree with Bill the Lizard about there being no issues, but disagree about the seamless nature and keeping the project files separate. The only thing we have to do is make sure that we update the build classpath in each project if a new library is added because Netbeans and Eclipse use different files to describe the classpath.
Using the IDE version control system integrations helps to encourage keeping the projects up to date for everyone else.
One thing that makes developing single project in NetBeans and Eclipse is using maven to keep dependencies together. Maven will generate IDE specific files that contain all classpath information, buildpaths etc.
Maven has pretty steep learning curve, but it is worth learning.
There are no issues at all with having them on the same system. However, each have their own project specific files, so using them on the same project isn't seamless. This is made a lot easier if you're using source control and keep your (non-source code) project files separate.
Maven is a very good way to keep both IDEs in sync (as suggested). In my experience though, you have to create an Ant build for any given project for the sake of developers not using IDEs. Since NetBeans's build system is based on Ant, it's pretty trivial to just base the entire NetBeans project off of that base build system. A little bit of tweaking in the project.xml ensures that the editor classpath is kept in sync with the Ant build classpath.
Netbeans 6.5 has an improved Eclipse project import which is supposed to sync changes from Netbeans back to Eclipse: http://wiki.netbeans.org/NewAndNoteWorthyNB65#section-NewAndNoteWorthyNB65-EclipseProjectImportAndSynchronization
Related
I'm new to Java and Eclipse (C# developer here). I have a requirement to take an open-source Java application (OpenFire) and modify it to suit our needs.
I downloaded Eclipse Juno, I downloaded OpenFire. But something tells me that OpenFire was written using another IDE because when I try to open it in Eclipse, it complains about the element missing in the build.xml file (I used the "Open from an existing Ant BuildFile" option, which OpenFire has).
What can be the best way to approach this type of situation knowing that open-source can be written using so many tools out there? The goal is not to have to change much of the files just to get it into an IDE.
Any help or direction would help.
The IDE does not make a difference to the project unless there are IDE-specific artifacts like .classpath in the project tree. The build.xml file format is set by Ant, not by any one IDE, so it is extremely unlikely that the IDE is the source of your difficulty.
However, IDE-specific files have no place in the source repository.
Rather than chase down a red herring, look at the error in the build.xml and fix that.
Also, to diagnose if your IDE is mismanaging Ant, use ant from the command line to build your project. You should never depend on the IDE to build your project for you, and never use the IDE to build the project for someone else to use. Always use standard build tools like Ant or Maven or Gradle, and always run them from command line or script to get "official" builds.
If you can run your build that way, you are guaranteed independence of IDE irregularities.
What can be the best way to approach this type of situation knowing that open-source can be written using so many tools out there?
This problem has been already solved by IDE and platform independent build tools which are tightly integrated with most of the popular IDEs
Maven, Gradle are examples of such tools
These build tools also has standard configuration and directory structure which is understandable by popular IDEs
We are using Eclipse for our projects and we would like to revision control the JDK we use. (Different projects need to use different JDKs). Instead of configuring everyone's system to have the same JDK with the same names in Eclipse, we would like to include the JDK as part of our project in our source control tool and have the project point to the JDK that is part of the project.
We can't figure out how to tell Eclipse to use the JDK that is found in the project. It keeps wanting an absolute path to the JDK. Is it possible to use the JDK that is part of a project and use a path that is relative to the project?
Is it possible to use the JDK that is part of a project and use a path
that is relative to the project?
Straight answer: NO
You're asking to go around the basic abstraction that Eclipse provides between installed runtime environments (which are defined at the workspace level) and the project's compiler configuration (which is defined at the project level). If you want to use all the JDT features in Eclipse, you just have to live with configuring the installed JREs on each workspace of each of your developers.
However, I can think of a probably not-so-standard-way (I see the -1's coming for saying this, which is crazy!) to achieve what you want: to distribute the .metadata folder of a pre-configured workspace you've already set up with all your JRE's so you don't have to go on each machine and do the installation. This would also include committing the .settings folder and the .project .classpath files of each project. Want to include the JDKs? Well, you could put each of them in the SCM as individual projects and ask each developer to import and configure them. If you did this on your template workspace before distributing it, then it will have not only the JDK's but also the .metadata pointing to them.
What could go wrong with this? probably everything.
How do the pro's do it? Maven and the maven-compiler-plugin (and not committing any IDE specific files). This leaves developers free to choose any IDE they want, and most of them support automatic project configuration from POM files: target JDK, dependencies, etc.
This may not be the approach you are looking for, but one option is to use a drive letter using SUBST for the root directory of your project.
Having the same path to project on all development machines has many advantages. This strategy is most useful for developers working on a single codeline but I have successfully used it even with multiple codelines on my machine, changing the subst as necessary.
You can configure the JDK version in Eclipse. Right click your project, select properties, goto Java Compiler and there you can select a project specific version of Java for your project.
One approach would be to install all the JDKs on all the machines and use JAVA_HOME/PATH variables to point the appropriate JDK installation as required. You can write a simple batch file to take care of environment variable setting by just a simple double click.
No, that is not possible.
Either use Maven to just declare all your dependencies, including the SDK to be used. Or use Yoxos or Secure Delivery Center to centrally define Eclipse configurations, which are then deployed to your developers desk on starting Eclipse.
You're checking in the entire JDK? That seems likely to slow down your SCM quite a bit as it has to try and track a lot of large binaries, which won't diff well. Why not use a tool like Maven that declaratively states what JRE version to use?
This is in regards to building a Java Project.
So I'm a bit confused on my options here.
My requirements (it's a small project):
Needs to compile Java project with specific/custom compiler arguments
Project has native libs that need to be included
need to compile javascript->java class via Rhino javascript compiler (https://developer.mozilla.org/en/Rhino/JavaScript_Compiler)
After the build I need to run another command: ProGuard (http://proguard.sourceforge.net/)
run javadocs
Package everything up in Jar (also including external data, ie, images, xml, ini, etc)
Build/create a .jnlp web start.
Available under both Win and Linux would be optimal.
this is a hobby project, so don't want to spend weeks learning/managing the build system. At most an 8-12 hour investment start to finish (otherwise it's just better to keep doing everything by hand).
btw, my IDE is Eclipse if it matters; a nice integrated plugin would be nice - but not required.
So far I think Ant and Maven are the main two build systems in use. It's very unclear to me though which one I should use or how they differ?
The other option would be 'make' under linux (or maybe cygwin). I've only used it once, but seemed pretty quick to get going/working. Is that a good option for Java or this project? Any downsides to make? Why don't more java developer's use it?
Other options?
In a nutshell: spend your 12 hours learning and using Ant.
Maven has a good feel out-of-the box, super-easy to get going and with the neat dependency management, but down the line tweaking the pom.xml (your project's maven build file) to fit your needs will require more fiddling with than if you used Ant.
To address some of your specific requirements:
you can use <compilerarg> elements with the <javac> task
for native libs you can add them with: <sysproperty> and key="java.library.path"
use Rhino with Ant (http://stackoverflow.com/questions/3526960/using-recent-rhino-in-ant-script)
there is a Proguard task for Ant (http://proguard.sourceforge.net/index.html#/manual/ant.html)
for javadoc Ant comes with the <javadoc> task out of the box
the <jar> Ant task is extremely easy to use to package everything up
there is a <jw:jnlpwar> task available from the [Ant Web Start Task project] at (http://ant-jnlp-war.sourceforge.net)
Ant is ubiquitous, it works for just about every major platform out there (Linux, Unix, Windows, MacOS)
with plenty of docs and examples available on the web, you'll pick-up Ant in no time, and those hours you'll spend learning it will probably "pay" themselves back within a couple of weeks of using it for your builds.
Eclipse integrates with Ant out of the box (http://help.eclipse.org/indigo/index.jsp?topic=/org.eclipse.platform.doc.user/gettingStarted/qs-81_basics.htm)
It may not do fancy dependency management out-of-the-box like Maven (although for that you can integrate Ant with Ivy) but it certainly provides you with all the flexibility you'll ever need, and you won't find yourself "fighting" the build tool configuration file as it's fairly common with Maven.
I should probably just mention the 2 new names in Java build (and CI) tools: Hudson and Jenkins. They're fairly recent and may be interesting to look at, but I would definitely not recommend them to you and your project at this early stage.
Note: apologies for the lack of real links (only allowed 2 links atm)
Maven is the best choice here as it has integration for all of these
so go for it.
Here, quick links for you to save an extra hour to spend on learning maven ;)
Maven Compiler Options
Native Maven Plugin and Projects with JNI
Use Maven Antrun Plugin to Run rhino compile ant task
Use Proguard Maven Plugin (further details)
Maven Javadocs Plugin
Maven Assembly Plugin
Webstart Maven Plugin
Its java based so supported by most OS that support java !
It depends how quickly one can learn but AFAIK 12 hrs is sufficient to get started
I developed an application in eclipse that uses many of the classes of the eclipse framework and requires eclipse to run. But now I'm being required to decouple it from eclipse and make it a standalone application. How can I do this?
You might have luck using File / Export... / Java / Runnable Jar File. This will create a standalone .jar file that should be possible to run without Eclipse. You may however need to experiment with the various settings to get it to behave exactly how you want depending on what libraries you are using.
In general however, I'd suggest using a proper build/dependency management tool such as Maven. This will take a bit of time to learn at first, but my experience is that it will make you more productive in the long run....
Start by commenting out the imports for the offending libraries. This will turn red any references to those libraries in your code. Then substitute a different library or refactor your code.
What do you mean by "decouple" it from eclipse? Do you mean you can no longer rely on any of the eclipse libraries, or that you simply don't want it running as a module in the IDE?
If it's the former, you have a lot of rewriting to do.
If it's the latter, then you'll want to basically bundle your module with an "empty" eclipse framework application. This doesn't "unbundle" eclipse, eclipse is still there, but now you don't have any of the IDE modules etc, and instead you have a stand alone ECLIPSE BASED application.
Create a standalone jar file from the Eclipse project as mentioned by Mikera, or you need to re-factor the code such that it doesn't depend on Eclipse libraries.
There is no point in creating a Java application which depends on certain IDEs or platforms. Java code should be independent (which is why it has the power to run on any platform which has JVM installed in it.
Try removing the dependency from your project to the Eclipse libraries. See if you can simulate the same thing using Standard Java libraries. If not, try to create a JAR for your project from Eclipse. If nothing works out, try looking for some 3rd party APIs.
trying to do some Android development, which means Eclipse, however, most of my experience is Microsoft tools (e.g. Visual Studio). My java experience is mostly either Blackberry dev in the JDE and some miscellaneous stuff back in the Java 1.0 days.
My question is this. In VS200x, there is a .sln (solution), .csproj(project), etc...
What are the equivalent file extensions for Eclipse? Do they even exist? I am having trouble with the basics, like how does one load a project into a workspace.
Is there a tutorial for Microsoft refugees somewhere?
Have a look here for "An introduction to Eclipse for Visual Studio users"...
Basically, for Java program (I never done any Android development) the basic Eclipse configuration files for a project are a .classpath (defining the dependencies of your project), and a .project file, that contains all specificities to your project configuration. In addition to that, a .settings directory is created, which contains some configuration files for plugins activated on your project.
Edit:
Eclipse is the most used IDE for the Java development. However, the best IDE is JetBrains IntelliJ IDEA. I see that there is a plugin for it to develop Android applications (here). If you can affort this wonderful application ($249), you will not regret it! You may eventually try the free 30 days trial...
You need to use file import and then choose Existing projects into workspace.
A .project file and a .classpath file will be created.
I find the Eclipse way of working to be incredibly frustrating having come from Delphi/JBuilder where a single project file held all your settings.
Make sure that you back up your workspace as well - there is nothing worse than recreating it when you are under pressure!
My 2 cents :
Make sure to version control your .project and .classpath. You may aslo want to use path variables to reference directory where the external dependencies (third parties libs) are located.
Are you doing it for fun or for commercial purposes? Because if money is involved, if I were you, I would really consider investing in IntelliJ, which is arguably the best IDE Java IDE out there, but unfortunately it is not exactly free. The Android SDK has some support for IntelliJ out of the box so it's not like you had to write all the makefiles yourself manually. If you liked Visual Studio, you would like IntelliJ, so why don't you download the trial version and have a look at it.
Just my 2 cents.