I've been making small prototype programs recently, and it bothers me to have to set up the project each time. I have to import all the libraries, copy over an identical main class, then write a lot of code that I have already written before. Is there any way that I can save a project in Eclipse as a template, so that whichever programs I use the template for will have an identical classpath and original classes?
Thanks in advance.
You can copy (and paste) a project. Right click on the project (in the project navigator), and then paste. (CTRL+C then CTRL+V - or adjust if on on a mac)
I realize this is not as nice as a default, but it is a lot simpler than moving to maven.
I think you want the same logics as the maven archetypes do. So you have to create your own archetype as a template for new programs and start with it.
Have a look over here - http://maven.apache.org/guides/mini/guide-creating-archetypes.html - this is a guide how to implement this.
Maven is the most robust answer (and I'd recommend at it as well). However, a more direct approach is to maintain an Eclipse workspace as a template. You can put the workspace (.metadata) folder in same location as your template projects. Then copy that folder structure to any new projects, including the .metadata folder. Switch workspaces to work on different projects.
Related
So I took a Coursera course that had me work with external libraries. Two .jar files which most of the weekly projects depended upon.
I'm not entirely sure how eclipse compiles and runs the files, and how it links to these external libraries -- what is the proper way of organizing this? Do I put a copy of each .jar file in each project directory?
Is there another, cleaner way that I should be organizing this?
Thanks --
As a beginner programmer it is OK to put it in each project. But consider that this is ongoing work and at some time in future you want to upgrade to a new version of these external libraries. Then you would have to copy it everywhere.
Instead another option is to store them in one place and add it in classpath in each project. Now you have only one copy of it, which is always better.
Now, if and when you do get a new version then the file names might change, so you will still have to change the classpath of each project.
But I advise you to worry about these and other such problems later. For now, focus on programming related problems rather than configuration.
If you want to maintain your libraries professionally in a formal manor then you're better of using a build tool like Gradle of Maven.
I'd suggest you to use Gradle to maintain the project since it has a whole lot of useful build tools available to you to use. Eclipse has a Gradle plugin available which allows you to use Gradle projects with it. See link below.
To give you a idea of how Gradle is used professionally. Android uses it by default to maintain their projects now. So Android java projects uses the Gradle build tool to maintain its library sources, compilation processes and such.
The difference between a Gradle project and a normal java project is that a Gradle project has a list of pre-defined scripts available to you which fetches the libraries, compiles them and prepares them before exporting the final bundle (jar). So really all Gradle does in before hand is fetch the libraries and prepares the specified tools before compilation so you won't need to mess with them your self. It prepares your project directory and remotely maintains your libraries so if they're available from a repository then it'll make sure to prepare them appropriately in before hand and setup your projects directories.
So really the difference you'd physically notice is that instead of using the default Eclipse export button to create your bundle (jar) you'd instead use a button from the side menu which the Gradle plugin adds and also you'd cleanly list the libraries in a structured order in a file that gets added to your project root.
If you want to get a basic understanding of how it works and really want to start to proffesionally or formally structure your project then try to create a very basic android app in Android Studio. see link below
If this isn't what you want at all and don't want to take it to this advanced level yet then adding the library bundles into some kind of lib folder that's located in your project root is properly best practice.
If you wonder why? Well basically different projects might use different versions of the library which may add or remove support to them. So to keep the versions consistent and make sure to have the right version available to you, you have the direct source near the project it self.
Here's some useful link:
http://www.vogella.com/tutorials/EclipseGradle/article.html
http://developer.android.com/sdk/index.html
I want to start moving some of my projects onto github repos. I'm a little overwhelmed on how to organize the files on these repos. I want to make sure I do this right. The specific project I've been working on is a Java project I've been building in Eclipse. It is essentially an 'engine' of sorts, so the ideal outcome would be that people clone the repository and build onto it as their own project that uses the engine.
Here is my local project structure.
src
--com
----myName
------projectName
test
--com
----myName
------projectName
bin
config.properties
README.md
.gitignore
.classpath
.project
One of the first things I did was gitignore everything in the bin folder and all class files.
This doesn't really feel like the 'right' way of doing things. I'm just making guesses. Are there any standard conventions I can adhere to?
Also let me ask some specific questions
Is it okay that the java packages are creating many (seemingly redundant) subfolders?
Is it correct to ignore the bin folder? Or will that complicate the project if someone else was to clone it?
I want to say that the classpath and project folder should also be ignored, but they do reflect changes in files. Am I right in thinking that these should be commitable files?
Do I need to make any special changes in organization to reflect how this particular project is an 'engine' that I intended people to clone and use in their own projects?
I feel this is a simple concept I may be over complicating but I want to make sure this is done correctly the first time. Any resources that anyone can point me to regarding git repo organization would be appreciated!
Thanks in advance.
To what my understanding of things, you can do two things :
Share your sources as a Java Library wrapped in a jar file. You can avoid all this "how do i share" questions.
Or you can share the project in a software version tool, like GIT. Ideally you will have to provide to the clients two things : The code and a way to easily setup their environment for coding.
In your case
To share the code: The code is under your java source is under src and tests folders.
To allow other persons to setup quickly their environment for working : Let's see, you are using the build system that employs Eclipse, so you should study how to share a eclipse project from a machine from other. What i can tell you in advance is... i thing the bin folder is not necessary (2). But the .classpath and .project it is. That is necessary in order to open the project within the eclipse IDE... the problem is that your IDE perhaps has some particular library or classpath configuration that other Eclipse don't and problems may arise (3).
What i recommend is to share your project using an independent-ide builder. Like maven, for example. Yes.. you always depends on something.. is only a question of what is more easier, and mankind has prove that with things like maven it is more easy.
About question (1), is not bad as long it has sense.
and (4) I think not.
Using Android Studio, for some reason, I can no longer debug my program.
I tried a bunch of stuff and I made it worse.
To make a long story short I'd rather start from scratch and just copy the .java files and folder structure from the old project to a new project.
Is this practical?
I'm am familiar with modifying the manifest to add the various activities, which I can copy and paste from the old project.
Will this work?
I guess what I'm asking is: if I just have the .java files, what's the best way to make a project with them?
If you are using any IDE like Eclipse, just create a new java project, add the java files in the src folder. Put all the dependencies in the classpath. The project will run fine.
Simply ... Use maven. It provides you a good layout, community support, and support in a choice of IDE.
You can also use netbeans . it gives easy way to create desktop applications
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'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... :-)