I'm a long time Eclipse user but new to Git/Egit. Recently I've been trying to use Egit because I want to use GitHub to collaborate with a number of projects. The projects I want to work on are not Eclipse-specific projects but I'd still like to set up a workflow so that I can work on them in Eclipse.
It seems that there are a number of things that need to fit together:
The remote repository (on GitHub)
The local repository (somewhere on my filesystem)
The Git working directory
The Eclipse project that I want to work in (including stuff outside the source tree like Eclipse project files, Maven config, build folders etc.)
How do these relate to each other and what should be my workflow?
In particular:
Do I actually need a local repository or can I just work directly with the remote repository (like with SVN)?
Can the Git working directory also be the Eclipse project? Or is this a bad idea?
What should my workflow of push/pull/fetch etc. normally be?
If I use Maven for dependency management in the Eclipse project, but don't want all the Maven-specific stuff to get committed to SCM, can this work?
Guess I'm loking for some sound advice from someone who's successfully made this work!
Do I actually need a local repository or can I just work directly with the remote repository (like with SVN)?
Git is all about working on a local repository and pushing elsewhere when necessary.
Can the Git working directory also be the Eclipse project? Or is this a bad idea?
If it lines up this way, then yes. This is how I've managed my projects.
What should my workflow of push/pull/fetch etc. normally be?
You push when you feel you have made enough commits (sometimes only 1) that are worth pushing. You pull when you want to work with changes that other people have pushed.
See gitworkflows for the official doc on different types of workflows.
If I use Maven for dependency management in the Eclipse project, but don't want all the Maven-specific stuff to get committed to SCM, can this work?
Usually you just commit the pom.xml. Anything else is a user specific setting. Although, if I clone your repository and can't do a "mvn compile", then there's something wrong.
Related
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.
I have almost no experience in using netbeans and svn so please correct me gently if I am wrong. I come from using python/vim/git so workflow wise is foreign to me.
Currently, I used the Netbeans' svn plugin to checkout my project from a remote repository. The project has several components like webservices, and also a swing client and of the business logics.
Assuming that I need to work with the web services and the swing client, do I create separate projects for each, and import the project as references?
Finally, currently I'm using netbeans to test the webapp on the local glassfish server. How do I deploy on a remote test server so that my team mates can use and test the web app?
If all of the seperate components are a part of the same project in svn then, no, you should only create one project in netbeans. Check out the project from svn and once netbeans has checked out the project it should prompt you to create a netbeans project when it does select project from existing sources, follow the wizard steps and your project will be created. You will have to import any external jars needed by the project that has been checked out into the newly created project in netbeans. NOTE: Netbenas will create a build.xml file for the newly created project so be sure that you do not commit that build.xml file into the repository unless it's needed.
To setup a remote server in netbeans go to tools->servers, select add server, select the server type(glassfish, tomcat, etc) then enter the pertinent information for the server using the wizard.
First question "Assuming that I need to work with the web services and the swing client, do I create separate projects for each, and import the project as references?"
It really depends on your architecture - how coupled are those components. It's also important what packaging system do you use? For example if you use Maven you can easily modulate the project and define dependencies between the modules. Check out this for details. I am referring to maven as it's build-in in Netbeans.
Regarding your testing you basically have 2 options:
a) expose your glassfish to your buddies
b) package and deploy your project remotely - this really cannot be given straight answer - depends on your infrastructure, where's the remote server, how big the deployment package is, how the application server behaves regarding hot deployments etc.
I suggest try the first option.
SVN helps you to keep the project in several versions in the repository.
You can always checkout from repository.
once you checked out, you will be using the project from a saved directory somewhere in your local machine.
Now, you can keep on developing the project, at the same time your friends can also keep doing that, and whenever you think you have done enough changes or development then after verifying your own copy of the project, you can commit the changes to repository.
After committing the changes will be visible in the repository to everyone, and hence anyone can access this updated version of the project residing in the repository.
Note that the earlier version will not be deleted, unless you do so.
Your friend can also checkout a copy of the project from the repository and they can merge it with their existing ones, and they can also commit the changes.
and at the same time, you can ask your friend to check your developed code by checking out the project and deploying on their local server.
I hope it gives you a better picture.
EDIT: Ok... so I've gathered that SVN shouldn't really be used for this... which makes sense, I suppose (why version individual files when the version should be a separate jar?).
So we should use an internal server to host a repository management tool like Nexus (etc), and access that over http to pull down and put out dependencies. We are keeping our projects in SVN now. What is the standard for deployments? Dependencies go into Maven. Projects go into SVN. Should we ignore the dist and build folders? Where would our WAR files get deployed from?
OLD QUESTION (for posterity)
I'm brand new to Maven and don't know jack about it. I'm trying to evaluate it to see how it will do with our Java development.
I would like to have a Maven repository in our SVN server so that dependencies can be pulled down from there using NetBeans 6.7. I have not been able to find how to do this throughout many google and stackoverflow searches.
What are the best practices here? I'm thinking that we'd want to download dependencies using svn+ssh, but most things online seem to point to using http.
Fill my brain with great things!
I'd strongly recommend against doing this. Maven artifacts don't belong on an SCM server. You should consider using a repository manager like Nexus to store your artifacts. See here for a comparison of the main repository managers.
Having said that. If you are determined to use Subversion to host your artifacts. See this question on using the wagon scm to deploy to a Subversion repository.
If you want to find out more about Maven, check out Maven: the definitive guide.
There is a Maven plugin for Netbeans that will manage dependencies. This article lists some best practices for Maven and Netbeans.
Update based on your updated question. What to do with your own jars:
Maven has a deploy phase that will publish your artifacts to the remote repository. You need to configure the distributionManagement section of the pom, and provide appropriate credentials in your settings.xml to allow the deployment to happen. Typically you would set up a discrete logical repository on the server for your own artifacts to keep them isolated from third party artifacts. The Nexus book gives some good guidance on configuring repositories on Nexus. In particular see the Adopting a Repository Manager section.
If you have configured your project correctly, run mvn deploy and all phases up to and including the deploy phase will run, and your artifact will be published to the repository, available for use by the rest of your team/company.
If you need to restrict access to repositories, you can configure access controls to your repository so only authenticated users can access those artifacts (for Nexus see the Managing Security section of the book for guidance).
It's worth noting you can do largely the same things (more or less) with Artifactory or Archiva as Nexus, I've included Nexus references because I prefer it, and the documentation is really good.
Don't store them in SVN.
I would do two things to make sure you're not getting too many headaches:
Mirror a repository closer to your box someplace that you and your workmates can share. This will eliminate extra downloading and allow you to fix any problems that may come up (and they will) with the mirrored pom/jar files so your mates don't have to share in the headache. There are several repo managers out there that help with this.
Do your best to work with your machine repository and push changes/modifications to any pom files that you may make to the local shared repo.
We have several products which have a lot of shared code and which must be maintained several versions back.
To handle this we use a lot of Eclipse projects, some contain library jars, and some contain shared source code (in several projects to avoid getting a giant heap with numerous dependencies while being able to compile everything from scratch to ensure that source and binaries are consistent). We manage those with projectSet.psf's as these can directly pull all projects out from CVS and leave a fully prepared workspace. We do not do ant builds directly or use maven.
We now want to be able to put all these projects and their various versions in a Continous Integration tool - I like Hudson but this is just a matter of taste - which essentially means that we need to get an automatic way to check out the projects to a fresh workspace, and compile the source folders as described in the project-files in each project. Hudson does not provide such an approach to build a project, so I have been considering what the best way to approach this would be.
Ideas have been
Find or write an ant plugin/converter that understands projectSet.psf's and map to cvs-checkout and compile tags.
Create the build.xml files from within Eclipse and use those. I tried this, and found the result to be verbose and with absolute locations which is not good with automatic tools putting files where they want to.
Write a Hudson plugin which understands projectSet.psf's to derive a configuration and build it.
Just bite the bullet and manually create and update the CI configuration whenever stuff breaks - I don't like this :)
I'd really like to hear about other peoples experiences so I can decide how to approach this.
Edit: Another option might be using a CI which knows better about Eclipse projects and/or project sets. We are not religious - this is just a matter of getting stuff running without having to do everything ourselves. Would Cruise Control be a better option perhaps? Others?
Edit: Found that ant4eclipse has a "Team Project Set" facility. http://ant4eclipse.sourceforge.net/
Edit: Used the ant4eclipse and ant-contrib ant extensions to build a complete workspace as a sjgned runnable jar file similar to the Runnable Jar facility in Eclipse 3.5M6. I am still depending on Eclipse to create the initial empty workspace, and extract the ProjectSet, so that is the next hurdle.
Edit: Ended up with a dual configuration, namely that Hudson extracts the same set of modules as listed in the ProjectSet.pdf file from CVS (which needs to have the same tag) causing them to be located next to each other. Then ant4eclipse works well with the projectSet.psf file embedded in the main module. Caveat: Module list in Hudson must be manually updated, and it appears that a manual workspace cleanup is needed afterwards to let Hudson "discover" that there is more projects now than earlier. This has now worked well for us for a couple of months, but it was quite tedious to get everything working inside the ant file.
Edit: The "Use Team Projects" with ant4eclipse and a Ctrl-A, Ctrl-C in Project Panel with a Ctrl-V in the CVS projects in Hudson has turned out to work well enough for us to live with (for mature projects this is very rarely changed). I am awaiting the release of ant4eclipse 1.0 - http://www.ant4eclipse.org/, currently in milestone 2 - to see how much homegrown functionality can be replaced with ant4eclipse things.
Edit: ant4eclipse is as of 20100609 in M4 so the schedule at http://www.ant4eclipse.org/node?page=1 is slipping somewhat.
Edit: My conclusion after using our ant4eclipse approach for a longer period is that the build script get very gnarly and is hard to maintain. Also the Team ProjectSet facility (which ant4eclipse use to locate the projects) which works well for CVS based repositories, but not after we migrated to git (which is a big thing in itself). New projects will most likely be based on maven, as this has good support in Jenkins.
I'm not completely sure I understand the problem, but it sounds like the root issue is that you have many projects, some of which are dependent on others. Some of the projects that are closer to the "leaf" of the dependency tree need to be able to use "stable" (or previously "released") versions of the more "core" projects.
I solve exactly this problem using Hudson, ant, and ivy. I follow a pattern demonstrated by Clark in Pragmatic Project Automation (he doesn't demonstrate the dependency problems and solutions, and he uses CruiseControl rather than hudson.)
I have a hand-written ant build file (we call it "cc-build.xml", because of our CruiseControl roots.) This file is responsible for refreshing the working space for the project from the CM repository and labeling the contents for future reference. It then hands off control to another hand-written ant build file (build.xml) that is provided by each project's developers. This project is responsible for the traditional build steps (compile, packaging, etc.) It is required to spit out the installable artifacts, unit test reports, etc, to the Hudson artifacts directory. It is my experience that automatically generated build files (by Eclipse or other similar IDE's) will never get close to getting this sufficiently robust for use in a CI scenario.
Additionally, it uses ivy to resolve its own dependencies. Ivy supports precisely-specified dependency versions (e.g. "use version 1.1") and it supports "fuzzy versions" (e.g. "use version 1.1+" or "use the latest version in integration status.") Our projects typically start out specifying a very "fuzzy" version for internal projects under ongoing development, and as they get close to a release point, they "freeze" the dependency version so that stuff stops moving underneath them.
The non-leaf projects (projects that are dependents for other projects) also use ivy to publish their artifacts to our internal ivy repository. That repository keeps all past builds of the dependents, so that any project can always depend on any other previous version.
Lastly, each project in Hudson is configured to have a build trigger that causes a rebuild when any of its dependent projects successfully build. This causes them to get built again with the (possibly) new ivy dependent version.
It is worth noting that once you get this up and running, consistent automated "labeling" or "tagging" of an automated build's inputs is going to be critical for you - otherwise troubleshooting post-build problems is going to result in having to untangle a hornet's nest to find the original source.
Getting all of this setup for our environment took quite a bit of effort (primarily in setting up the ivy repository and ant build files,) but it has paid for itself many times over in saved headaches in manually managing the dependencies and decreased troubleshooting effort.
Write a Hudson plugin which
understands projectSet.psf's to derive
a configuration and build it.
That seems like the winning answer to me.
I work with CruiseControl rather than Hudson but in my experience if you can create a plugin that solves your problem it will quickly payoff. And it is generally pretty easy to write a plugin that is custom fit for your solution as opposed to one that needs to work for everyone in a similar situation.
I have tried both Cruise Control (CC) and Hudson for our CI solution. We (as a company) decided on Hudson. But for your question "Does CC support Eclipse project build" the answer is no as far as I know. CC supports many more different build tools and Source Control systems but it is a bit more difficult to configure and use. As for Hudson, it is more simple to configure and use it. We developed our custom plugins for both CC and Hudson for the parts of our build cycle that they do not provide as is. As for plugin development, if you know / use Maven, Hudson is simpler too. But if you are not familiar to Maven, first you need to learn the basic usage of maven to successfully develop a Hudson plugin. But once you understand the basic usage of maven, plugin development, test and even debug is simpler in Hudson.
For your specific problem, I can think of a solution that makes use of Eclipse plugins as well. You can develop your own Eclipse plugin that for instance gets the psf files from a (configurable) folder, and use Eclipse internals to process these psf's. I mean you can use existing Eclipse source codes that takes a psf file, check-outs it's project definitions and compile these projects. This Eclipse plugin of yours may have a preference page (which you can access by Eclipse -> Window -> Preferences) and configure which folder it will use to look for psf files. Your Eclipse plugin should also have a way to start psf processing without user interaction. For this, you can use ipc to trigger your process. I mean your Eclipse plugin can listen for a port, and you can write another java application that will connect to your plugin through this port and trigger its process. As for CI part, you can use either CC or Hudson and use their external process execution support. If you are using Windows, you can write a bat file (for Linux sh file) that first launchs Eclipse that has your plugin installed. Then it launches your java application that will communicate with your Eclipse plugin to trigger your process. From your CI tool you will need to run your bat / sh file to trigger your process.