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.
Related
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.
I inherited a Java project in the form of an Eclipse project. After changing the Tomcat configuration (from v6 to v7), Subclipse prompted me to commit the following files:
.classpath
org.eclipse.core.prefs
org.eclipse.common.project.facet.core.refs
org.eclipse.common.project.facet.core.xml
Will commiting them help my team members or will it mess with their workspace?
What is the best practice approach to this?
Generally speaking, you should check-in (and commit after changes) everything that does contribute to the build AND is not re-generateable by re-building completely AND is workstation-specific. (The implications of this statement depend on your build process/procedure, which is intended.)
This implies you should exclude everything that is re-generated upon full build etc. so it is not checked in (and not offered for check-in).
As a general rule, you should avoid committing files that contain user preferences, and project details that that Eclipse and/or your plugins can regenerate.
But in some cases things are a bit murky. For instance, the .classpath file can be the primary source of the Eclipse build path; e.g. if you have JAR files in your project tree rather than using Maven. (With Maven, the m2eclipse plugin generates the .classpath file from the dependency information in the POM file, and hence the file should not be checked in.)
Also, some of the facet stuff is borderline. For instance, in projects with JSPs and Javascripts, I have found it essential to change the facet properties to disable broken validators. And there's a good case for treating those changes as part of the project rather than as personal preferences.
Separation of group / project preferences from personal preferences is one area where (IMO) Eclipse is seriously deficient.
It is better not to commit those files as paths/settings may differ on different workstations.
You may wanna use some build tool to overcome this. (eg. Maven)
As if any of the team members are not using eclipse (using some other ide) , those files have no meaning for them.
If everyone commits different IDE settings, imagine what kind of mess it can cause.
EDIT:
More explanation;
I have worked in teams that people used NetBeans, Eclipse, IDEA...for a really long time and it is not really an option for them to change the IDE. It will only affect the productivity of that person.
When people get used to their IDEs they learn shorcuts, they know where to look for some functions (refactor/generate getter setter/implement override required methods....) so if you force them to use some other IDE it will just make things harder for them and slower for the overall process. IMHO and from my experience having a flexible codebase is always good. I am an eclipse guy and probably would not want to work with any other IDE as I know lots of shorcuts which makes thing real quicker/easier for me and those shorcuts are different on different IDEs.
All IDE files can be regenerated automatical by the IDE itself probably in just a couple of clicks.
And my current project has 3 developers, each using different IDEs eclipse(me), NetBeans, IDEA without any problems. I dont want to see IDEA or NetBeans config files which makes no sense for eclipse when I check out the source from repo. Likewise for them as well.
Yes, though do make sure that paths are relative in the workspace rather than absolute paths. Having these files in the workspace allows members of your team to work in the same environment as you are. It also makes setting up a new development environment much easier: you just check it out of source control and in Eclipse use 'Import... > Existing Projects into Workspace'
As #adamdunne mentioned, these files can contain environment specific paths. However it if you are careful to make sure paths are relative within your workspace, by using variables and by not importing external jars, i.e., by only including jars from projects in the workspace, then you should be okay. In my workspace we check in those files and have had a lot less issues setting up dev. environments since.
I work in a project where we commit the .classpath file since it is very useful that all developers use the same :) If you only use dependencies inside your workspace, this file uses relative paths and thus should be same on all machines. Even if this file might not be necessary to build (with ant e.g.) it´s very convenient to synchronize it.
In contrast the org.eclipse.core.prefs stores (afaik) project-specific, but personal preferences of developers which I would not check in.
With the facets I didn´t work yet in a real project, so I can´t tell. But in general, I think it depends on the information in the file and on the way you work.
If you are unsure, just try it. If you get conflicts in these files all day this is a hint you may not be on the perfect way.
These files can be very useful to share configurations between developers. The alternative is to either use Maven (which is a huge task for an established project) or to have constantly-outdated step-by-step instructions and new developers taking half a day until they can even build the project.
However, you should take care to ensure that these configurations are portable, i.e. contain no local paths. This can be done via the use of relative paths within the workspace, eclipse path variables and user libraries.
What we've done is ignore these files, as they may mess up the workspace of others on the project.
Ignoring them also makes your project cleaner, which I always like.
These files can contain environment specific paths so I would suggest not checking them in. On my current project we use ant scripts to create the project and do the initial checkout of all our code.
Developing with IntelliJ 9.0.2 Community Edition, on the Mac.
This is a follow-up to this post about including jar files in an artifact, which has not received any replies. I'm hoping that the reason is that somehow, in creating my artifact (or setting my project settings), I unwittingly did something which people don't tend to do, and which is causing my problem, and that by asking people here to share how they create jar artifacts and set up projects, I will discover what it is.
To recap: I have a Java project which depends on two library files. I need to package up the entire thing, with the jars inlined (such that on doing jar -tfv <filename> I see ALL the classes listed, including the ones in the two libraries), into a single jar file. I can make an artifact, I can add the library files to the Output Layout pane, but I CANNOT, no matter what I do, I cannot get the "Inline Artifact" item in the context menu to be selectable (i.e. non-grey) when I right-click on one or other library file.
The thing is, making a jar which contains library files as well as the project code is NOT an unusual situation in the Java world! So I figure there are lots of IntelliJ folks out there who have done what I need to do. And I would really like to hear from you folks.
What project settings do you use? (be specific, please :-)
And exactly how do you set up your jar artifacts? (again, as many specific details as possible, please :-)
Clearly, I'd be particularly interested to hear from folks with similar setups to mine (above) who are successfully doing what I need to do.
Grateful thanks in advance, folks.
I don't think there is much you can do from inside IntelliJ, but there are several ways to do it from outside by merging the JARs.
See here: Selective jar packaging
Total Maven newbie, trying (along with the rest of a sizeable team) to convert a monstrous pile of legacy code from ant over to Maven. It's working reasonably well, but I'm having the following problem.
I have a project, let's call it Core, that at runtime needs to load some files checked in under some different projects, let's call them Resources A and B. The Core code is started in a certain working directory, let's call it core/runtime, and there's a properties file it reads in order to determine what to load from Resources A and B, complete with the relative path to the resources in question, e.g.
resource.ham=../../resources-a/files/ham.rsrc
resource.eggs=../../resources-b/files/eggs.rsrc
(Yes, I'm aware this is sick and wrong and we should be loading resources as resources, from a JAR via a classloader and maybe some sort of container or dependency injector or whatever. Not my idea, not my current problem, not on the table to be fixed now.)
(Seriously, please don't bother suggesting we fix the underlying problem. We know we need to fix the underlying problem. We knew we needed to fix the underlying problem before we switched to Maven, and before we switched to Maven the stupid hack actually worked. I know it makes you feel good, but it's not helpful. This is a ten-year-old codebase with tens of thousands of classes and believe me, there are plenty of more important things wrong with it.)
This relative-path hack is only an issue in Eclipse, during development; in the actual deployed application the files live somewhere completely different and are loaded in a somewhat more sensible way.
Anyhow, this all worked fine when these were vanilla Eclipse projects, so the directories in question had paths like:
c:\workspace\core\runtime
c:\workspace\resources-a\files
c:\workspace\resources-b\files
However, now that these are checked out as Maven projects, the directories are now something like:
c:\workspace\core\runtime # Inexplicably unchanged
c:\workspace\maven.8675309\resources-a\files
c:\workspace\maven.6345789\resources-b\files
Questions:
Can I make these maven.7762323 directories go away?
If not, is there some way in Eclipse to get the path to a project directory, and then pass that as a system property in a launch configuration, or something like that?
Any solution has to be one I can check into SVN so the other developers on my team can use it out of the box.
Update
Okay, I figured out where the maven.[number] directories come from: When you select a parent directory in the SVN repository and say "Check out as Maven project", you get a maven.[number] directory corresponding to the parent, with all the actual projects as subdirectories. It would be very convenient, if only the code was actually all in the same parent directory, or even in the same SVN repository.
Can I make these maven.7762323 directories go away?
Where do they come from? What do you mean exactly by checked out as Maven projects?
(EDIT: As the OP wrote in a comment, these directories come from m2eclipse that allows to check out maven projects from SVN. I don't use this feature so I dont know much about it. However, after some googling, my understanding is that these names are kind of temporary and m2eclipse should rename them at the end of the checkout. Maybe something something went wrong with eclipse during the checkout. I'm not sure actually.)
If not, is there some way in Eclipse to get the path to a project directory, and then pass that as a system property in a launch configuration, or something like that?
Eclipse has a {build_project} variable that could be used in the arguments of a runtime configuration. Maybe {workpsace_loc} would be more appropriate in your case. The whole list is available with a description in the Arguments tab of a runtime configuration.
(EDIT: I'm still not sure I get the real goal but I have the feeling that using svn:externals could help.)
Okay, solution was to use {workspace_loc:project name} variables to set a handful of project directories as system properties, and use those to infer everything else. Now if I can just figure out how to get the ridiculous system for loading plugin JARs to work with Maven...
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... :-)