I want to stop egit from updating the repository with modifications I make to an app, which I downloaded from git. I found out that I have to update .gitignore file. I did that. But then I read that I have to clear the git cache also. But all the procedures I find are for the linux setup of Eclipse. I don't find any information on how to do this in the Windows environment. On Linux setup, you can issue "git rm -r --cached [filename]", and that stops git from updating the repository with changes to the file. But I can not find the git or egit executable in my setup. I am running Eclipse from the Android bundle setup. This is a zip file that you can download from Android developer site, and it has Eclipse along with Android Development Environment. I am running this on a Windows 7 machine. I think egit is the Eclipse addon for git? Is that right?
I found this link: Eclipse Git Tutorial But it did not help me.
Related
I have a cmake project that uses vcpkg (I added vcpkg as a submodule under my repo and configured CMAKE_TOOLCHAIN_FILE to point to the vcpkg.cmake).
Now I configured CLion to connect over ssh and build remotely on a different machine, but I am not sure how I can go about telling it to sync my vcpkg folder which is outside of the CMAKE_SOURCE_DIR.
I tried also to put the vcpkg submodule in CMAKE_SOURCE_DIR (even though I would like to keep it separate) and this works, it gets synced.
I was thinking also if there is some way to control where CLion does the sync on the remote machine and I could just put vcpkg there myself (relative to the sync path) and install the needed packages, but I did not find this option either.
OK, I found how to set the remote for my ssh connection path:
File | Settings | Build, Execution, Deployment | Deployment
So I can go myself on the remote machine, clone vcpkg relatively to the Deployment path and install all packages.
This works well enough, I just need to make remember to install any new packages in both places.
EDIT:
I found also a completely automated solution:
From the same CLion Deployment settings, I can actually add multiple mappings so I can add an extra folder sync for my out of source vcpkg.
At the end, I am thinking that it will be a waste for CLion to keep the whole vcpkg with all the installed packages automatically in sync when I can just sync it myself once in a blue moon when I install a new package.
I am not sure how expensive it would be for CLion to monitor such a big folder.
I can't install practically macro on eclipse.`
Error:
Communication with repository at
http://puremvcnotificationviewer.googlecode.com/svn/trunk/PracticallyMacroGoogleUpdateSite
failed.
Read Timeout
Tried to install from here https://marketplace.eclipse.org/content/practically-macro-0 dragging and dropping
And tried to install it from eclipse marketplace, both said the same thing.
I have eclipse luna 4.4.1.
I want to be able to do key shortcut for run cofiguration. Apperently i need this plug-in but can't install it.
Go to https://sourceforge.net/projects/practicalmacro/?source=typ_redirect and download PracticallyMacro_x.x.x.jar.
Then create a directory "PracticallyMarco" inside the eclipse/plugins directory.
Extract all files from PracticallyMacro_x.x.x.jar into eclipse/plugins/PracticallyMarco.
Restart eclipse. (Maybe you should restart eclipse with the -clean option.)
Then you can use the PracticallyMacro from the main toolbar:
See also the file eclipse/plugins/PracticallyMarco/Instructions.txt for more details.
There is a GitHub fork that seems to work:
https://github.com/EmteZogaf/practicalmacro-site/
If you browse the repo you can find the following update site:
https://github.com/EmteZogaf/practicalmacro-site/raw/master
I tested it on latest eclipse PHOTON and it seems to work.
I followed the youtube video http://www.youtube.com/watch?v=cFczTgsxktQ, what I have installed right now are Eclipse 4.3 classic and maven 3 and scala m2e and scala.
I took the source code from GitHub.
I have used the following commands.
rm -rf ~/.m2/repository/org/neo4j
git clone git://github.com/neo4j/neo4j.git
cd neo4j
git pull origin master
mvn clean install -Dmaven.test.skip=true
cd ..
Both the Eclipse and the neo4j folder are at the desktop (Linux system)
When I tried to import the existing maven project in the folder neo4j/community, it always has so many errors.
Errors are in the this picture:
However, I can run unit test of each source file. Is this normal?
Try cleaning your projects Menu->Project->Clean...
Sometimes the Maven and Eclipse build dont work perfectly together.
I have multiple projects in netbeans. Some of these projects are version controlled using cvs and others using git. When I change something in the project that is using git, a .cvsignore file is created automatically. But I don't want the project to use git.
Secondly, I created the project in netbeans and then went to terminal and did a git init. There is no term/version control decoration on the project but when I do a team -> git -> initialize, netbeans says that "Selected file is already part of a Git repository.". Is this a bug?
It's not a bug. That means someone already added your project to Git. (At least tried).
If you want to get rid and add your project to your own Git repo , search for .git files inside the project and delete them.
After that start the process again.
My team uses an internal team maven repo that is shared from a development server using Apache. We also run the Continuum CI server on the same machine. Maven builds in Continuum are run with the "install" goal, which copies the final artifact directly into the shared directory.
The question is, what is the difference between adding files to the shared repo using mvn install and using the deploy goal (mvn-deploy plugin)?
It seems to me that using mvn deploy creates additional configuration hassles, but I have read somewhere that installing files into a shared repo is a bad idea for some reason related to the internal workings of maven.
update: I get the functional differences between deploy and install; I am actually more interested in the low level details in terms of what files are created in the maven repo.
Ken, good question. I should be more explicit in the The Definitive Guide about the difference. "install" and "deploy" serve two different purposes in a build. "install" refers to the process of installing an artifact in your local repository. "deploy" refers to the process of deploying an artifact to a remote repository.
Example:
When I run a large multi-module project on a my machine, I'm going to usually run "mvn install". This is going to install all of the generated binary software artifacts (usually JARs) in my local repository. Then when I build individual modules in the build, Maven is going to retrieve the dependencies from the local repository.
When it comes time to deploy snapshots or releases, I'm going to run "mvn deploy". Running this is going to attempt to deploy the files to a remote repository or server. Usually I'm going to be deploying to a repository manager such as Nexus
It is true that running "deploy" is going to require some extra configuration, you are going to have to supply a distributionManagement section in your POM.
From the Maven docs, sounds like it's just a difference in which repository you install the package into:
install - install the package into the local repository, for use as a dependency in other projects locally
deploy - done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.
Maybe there is some confusion in that "install" to the CI server installs it to it's local repository, which then you as a user are sharing?
"matt b" has it right, but to be specific, the "install" goal copies your built target to the local repository on your file system; useful for small changes across projects not currently meant for the full group.
The "deploy" goal uploads it to your shared repository for when your work is finished, and then can be shared by other people who require it for their project.
In your case, it seems that "install" is used to make the management of the deployment easier since CI's local repo is the shared repo. If CI was on another box, it would have to use the "deploy" goal.