If I add linked resources to my eclipse project like this:
<linkedResources>
<link>
<name>[source path] src</name>
<type>2</type>
<locationURI>DOCUMENTS/Another_Project/src</locationURI>
</link>
</linkedResources>
EGit show all linked files each time in commit screen.
I've tried various combination of entries in .gitignore without success. Default right click Team -> Ignore adds this line : /[source path] src to .gitignore, but it doesn't work.
Is there a way around this?
The way we solved it was manually editing the relevant .gitignore files, for a fuller answer please check my response here answer to question 3310129
Actually EGit still lacks proper treatment of Linked Resources, see eclipse bug 333338. I've been working out a patch to resolve this issue. So if you really want EGit to gracefully ignore linked resources, you probably need to build from source and include that patch. The EGit contributor guide should help you get started. Otherwise the .gitignore workaround mentioned previously may be your only option.
Here's a solution that we can use while waiting for this bug to be properly fixed by the EGit team. Let's say (as suggested above) that you have a linked resource defined in this way in your Eclipse .project file:
<linkedResources>
<link>
<name>[source path] src</name>
<type>2</type>
<locationURI>DOCUMENTS/Another_Project/src</locationURI>
</link>
</linkedResources>
You could manually add all files and folders located under DOCUMENTS/Another_Project/src to the .gitignore file by using the * or ** wildcards:
**/com/domain/module_name/some_package/
Warning: Since the ** wildcard matches any level of directories, you would have to be sure that the paths and/or file names are unique and cannot be found elsewhere in the project. But if, like me, your structure uses a reverse-dns naming style followed by module name, this solution might be all you need.
Related
We have a build step that installs and updates the nuget packages in a solution on out build server (TeamCity). Recently this has stopped doing the updates correctly. I have investigated this and found that the problem seems to be that the update command in nuget is not updating all the projects in the soltution. I can replicate this on my local machine.
When I run this command:
.nuget\NuGet.exe update Our.Company.sln -Source http:/ourTcServer:8888/guestAuth/app/nuget/v1/FeedService.svc -RepositoryPath packages -verbosity detailed
I get this a list of 10 projects it is going to update
Found 10 projects with a packages.config file. (
Company.Project1.csproj,
Company.Project2.csproj,
Company.Project3.csproj,
Company.Project4.csproj,
Company.Project4.SubProject1.csproj,
Company.Project4.SubProject2.csproj,
Company.Project1.SubProject1.csproj,
Company.Project1.SubProject2.csproj,
Company.Project2.SubProject1.csproj,
Company.Project2.SubProject1.FurtherSubProject1.csproj)
However the solution contains 13 projects and these all contain packages.config files and as far as I can tell are no different to any of the other projects. The projects are a single project and its subprojects and our projects directory structure matches the projects names (so project1.subproject1 implies that subproject1 is in a folder inside project1) in case that is important. The projects with the issue are all in a project which has the specific names like :
Company.Something.SomethingElse.Routing
Company.Something.SomethingElse.Routing.Tests
Company.Something.SomethingElse.Routing.Tests.Specifications
In case the routing part of the name causes a problem (we had a problem before using the word Resources at the end of our package name)
We have 50+ solutions that all use the same build configuration and steps and it works fine for all of them. This solution seems to be the only one which is not updating correctly.
Does anyone know why this might be the case? Or does anyone know what the code that finds packages in a solution does which might cause it not to find some packages.config files? Or anything that might help track down this issue?
Ok so the issue was that we had renamed some of our projects and so the .csproj files and had not removed to old, unused project files and nuget has a piece of code which finds the projectfile into which it it going to update the references of the updated packages. It does this by finding all the files which are .csproj (or whatever project file flavour you are using) in the same directory as the packages.config. If this does not result in exactly 1 file then it throws an exception, which is subsequently caught and ignored and nothing is logged, so you are non the wiser.
Hopefully this will help someone else in the future. Maybe me.
I found that the problem I ran into was that my projects were not in the same directory tree of the solution.
The nuget.exe update command when given solution file searches for packages.config files using the solution directory as the starting point instead of looking at each project file in the solution.
From the nuget code on GitHub:
string[] packagesConfigFiles = Directory.GetFiles(
solutionDir, "*.config", SearchOption.AllDirectories);
You can see that they are just looking for *.config files starting in the solution directory.
My projects and solutions are organized like this:
/Libraries/Shared/Shared.csproj
/Programs/NTService/NTService.csproj
/Programs/NTService.sln
In this case, if I run update on the NTService.sln file it will only update the NTService.csproj references because it is in the same directory tree as the NTService.sln file.
Since it just looks at all packages in the whole tree, I just put a solution file at the root of my repository and then run the update on that. It doesn't matter what projects are in that solution file.
I'm in the process of converting a handful of projects from ripple to Paket. The way I do this is install Paket, then take my ripple.config and copy my sources and nugets over to my paket.dependencies, taking care to == the versions that I have fixed. Then I .paket/paket install over and over and over again trying to resolve versioning errors that come up from that.
After that, I open all my .csproj files and add an extra ..\ to all the HintPaths before opening my project and manually resolving whatever errors pop up.
Is there a better way to do this? I know there's a ripple-to-paket converter but I not only couldn't get it to work, but many people I work with say that it's terrible.
Thank you.
1 add a paket.references file in each project's folder
In each of your project files' folder, you should create a paket.references and list there the package name (only, the other info is kept consistent in your paket.dependencies in your root folder).
2 make sure the actual reference are handled with paket
you can manually remove the reference in the project files (either from VS or edit the project file), and call paket install which will add them (according to paket.references in the project's folder) with an additional <Paket>True</Paket> node (making it clear that this reference is handled by paket itself)
I think this is it.
In our Eclipse plugin are we managing some resources using navigator. For every folder in the navigator Eclipse is creating an .project file which leads to some problem in the code under resource management.
One way is to filter .project file pragmatically. But I wonder if there is a configuration or setting in Eclipse to prevent creation of .project files for the maps under navigator?
.project files created by Eclipse IDE is essential cannot be prevented from generation.
For Further information please refer to documentation at Eclipse Documentation.
EDIT:
The workaround would be to create a project in your workspace and then create a linked folder to the resources you want to scan that are somewhere else on the file system.
Don't try to delete the project meta data. That will lead to more trouble afterwards than simply configuring the team API to ignore the .project files during all version control operations. That .project file contains meta information from all plugins, not only from yours.
Depending on the VCS used, you should just create a default .gitignore, svn:ignore, or whatever you need.
Besides that, I would simply call it a bug in your plugin that it tries to do something with that file. It simply should not do that. Other plugins will create other files in the projects and you should not try to handle each and every file, if they don't belong to your plugin. The JDT plugin also knows which files to compile and which to ignore.
I want to upload my xcode project to git, but only needed files. I see different files that i'm sure are created during build, but about others i'm not. I'm talking about *pbx* and *.oa files.
I'm using git. And want to configure an "exclude" file with patterns of files to be ignored. Is it safe to add the following patterns: *pbx* and *.oa?
Maybe someone can share an exclude file..
When using Git, I use the following .gitignore file:
.DS_Store
build/
*.xcodeproj/*
!*.xcodeproj/project.pbxproj
That's for Xcode 3.x. There may be additional files generated by Xcode 4 that should be ignored (maybe someone else will kindly provide that information).
No it is not safe for pbx because project.pbxproject is very important (and a real pain with version control). I am unsure about *.oa but here is a list of items I currently exclude in svn.
*.pbxuser,
*.mode*,
build,
.DS_Store,
*.perspectivev*,
*.xcworkspace,
xcuserdata
I created an Eclipse project and now I want to put it on my SVN repository. Which files should I put on ignore list? There are many files that I don't know what they are used for. There are folders like .history, .root, .safetable, .log, .settings ... and many .index files, also some .running files. Can I put all that to ignore list? Do you know which extensions/folders can always be on ignore?
Thanks.
The answer is very dependent on your project. Committing the source is a good thing however it'll force new developer to recreate the project environment which can be painful. If you are using Maven with the m2eclipse plugin committing only src and pom.xml is a good approach as it only takes a few minutes to recreate the Eclipse environment from src and pom.xml.
On the other hand it is ok to commit .classpath and .project but that also means extra work such as never using external jar directly but through variables or user library, etc.
If you have time to experiment, why not check in everything, have a colleague check out the project, and see what throws up errors? Anything that references paths outside the project is likely to fail if your colleague doesn't organize her harddrive the same as yours. Those things should be changed to reference variables, or not placed under version control.
Let your colleague build the project, run the IDE through its paces, and then sync up to the repository to see what changed. Files that are volatile, run time logs, and temp files should be omitted. Anything that makes it easier for another developer to setup the project and get running should be included. Taking time to experiment will help you gain a better understanding how your project is setup.
Basically, you want to avoid checking in anything derived from source (like .class files in a Java project) or anything that every developer would have to change for their local environment, like a file with absolute references outside the project directory. One approach I have used in the past for handling configuration files that require customization by developers is to include a copy of the file, usually with extra comments, with a .example extension. Make it clear in a README or other documentation which example files need to be customized and what the "real" name for the file should be. Also include he "real" file name in the svnignore list so it doesn't get checked in and overwrite everyone's local customizations.
To address your specific examples:
.history, .root, .safetable, .log,
.settings ... and many .index files,
also some .running
.settings is one you'll have to experiment with. If you have settings, such as code style or formatting guidelines, that all developers need to follow, then it can be handy to have those under version control, but some other settings may not be appropriate for all developers. The other examples are not familiar to me, possibly because they are associated with a type of Eclipse project I don't work with.
My first guess would be that any file whose name is starting with a dot should not be versioned. Most commonly such files refer to Eclipse settings which are not project-relevant.
Now, the .project and the .classpath files, in a Java project, are quite "project dependant" and I usually include them.
To get a more precise answer you should specify which project type you are working on.