In a multi-module maven project, Mylyn adds newly opened files to the context multiple times: once for the project where the file really lives, and then once again for each parent project in the hierarchy. It is possible to remove the parent references but they reappear.
What makes things worse is that Mylyn shows fully opened path branches for each folder in the parent project that contains files. That clutters the Package explorer a lot.
Is it possible to tell Mylyn to disregard maven parent projects in the workspace?
It is possible using working sets.
see http://wiki.eclipse.org/Mylyn/User_Guide#Working_Set_Integration
Create a working set that contains only non-parent projects, then go to the package explorer and use the small triangle from the package explorer toolbar to open the working set menu.
Choose 'Top-level Elements-Working Sets'. That gives you a package explorer with two folders: 'Other projects' and your working set containing the projects that are no parent projects.
From the context menu of your working set, choose 'Go Into'
Related
I've accidentally added my solution to wrong Team project on TFS, I've gone to File/Source Control/Advanced/Change source control, I've selected all my projects and unbinded them, went to solution, and after right click I've chosen Add Solution To Source Control, but pop-up appeared saying:
The item 'ProjectName.sln' is already under source control at the selected location.
If you are trying to rebind a project that you have already added to source control
outside Microsoft Visual Studio, you should use the Change Source Control command. If you are
adding this project for the first time, you should either choose a different server folder for the project or move the
existing project to a different server folder.
I've tried to bind project to new Team project, but when I tried to check in, not whole project was checked but only changes added since I've accidentally added it to wrong Team project.
To sum up how can now I add my project to TFS source control ?
You need to unbind it, then manually move the files into a local folder that is mapped to the correct team project. Then try doing the Add Solution to Source Control.
Each team project will be mapped to a different folder in your local workspace. If your files are under the folder for project A (which I assume they are if you've already added it to that team project), then you need to move them to a folder under Project B before trying to bind to Project B.
I have a folder structure setup for my code like so:
MyCodeFolder
-SolutionFileOne.sln
-ProjectFolder1
-ProjectFolder2
-ProjectFolder3
-SolutionFileTwo.sln
-ProjectFolderA
-ProjectFolderB
-ProjectFolderC
-ProjectFolderCommon
Solution one contains projects 1,2,3 and Common and Solution two contains project A, B ,C and Common.
When I come to create my TFS Builds I am getting a problem. If I just add MyCodeFolder in the working folder set up then both builds will succeed but then check-ins against project 2 will kick off a build of solution two and vice versa.
If I map only the folders the solution needs the build fails, which I am guessing is down to the fact I haven't included a mapping to the folder where the solution file is (the MyCodeFolder).
Is there a way I can solve this issue without altering my file structure?
The continuous integration trigger in TFS builds will queue a new build any time an item within that build's workspace is altered. Workspace mappings can only contain folders - you cannot include \ exclude (aka "cloak") individual files within folders.
What you can do is setup your build workspace to use the entire /MyCodeFolder folder. Then, in the build for SolutionFileOne.sln you can cloak ProjectFolderA, ProjectFolderB, and ProjectFolderC. In the build for SolutionFileTwo.sln you can cloak ProjectFolder1, ProjectFolder2, and ProjectFolder3.
This is only a partial solution. Both builds will still get kicked off when someone changes either solution file, or when anything in the ProjectFolderCommon folder is changed. Since you can't cloak the solution files themselves there's no way to avoid both builds getting kicked off on a solution file check-in without changing the structure of your files.
My problem is that in my scenario, I have a project with two parallel project files for different build targets. I have a ProjectName.WP8.csproj and ProjectName.WinRT.csproj, which essentially include the same files.
I am trying to check-in this solution (SolutionName.WinRT.sln) to TFS and I get no errors. All the code changes to the code in the project goes through, but when I check the actual state of TFS, the (newer) PorjectName.WinRT.csproj files are not checked in.
This is quite peculiar since it worked perfectly for the WP8 version. How can I support this kind of scenario?
(If it's not possible, how do I easily migrate my parallel project to another TFS project?)
Just had this come up myself. I had been working on a project for a few days before checking the solution in. During the initial check in for the project, only the most recent file edits were seen by source control. I was able to highlight all the files in the Solution Explorer and select Add to Source Control from the right click menu, but the csproj files themselves did not check in. To do this, I had to go into the Source Control Explorer and open the project directory. From within the directory, right click and select Add Items to Folder. Then you can select the csproj files and you're good to go.
We have installers referencing a wixlib file to get some common functionality. The wixlib is built in another solution then moved to a folder within that solution. When we try to build the installers with a TFS build, we get an error from light.exe:
light.exe: The system cannot find the file '..\..\..\Core\Common\assemblies\v1.0\Common.Wix.wixlib' with type 'Source'.
Our regular projects can reference \assembiles\v1.0, since we have some other common assemblies stored there. How do we get WiX to recognize this location during build?
You are referencing wixlib directly. So as far as I understand the TFS build process, it should be added to TFS project of your solution. TFS project shouldn't be dependent on the output of another non-dependent solution. It is at least bad practice. And in any case you can't guarantee this output would be generated before your project build on server.
As far as I remember, TFS build creates separate folder for each build and gets sources there. So your solutions are no longer on the same folder hierarchy level.
One more point in favor of explicitly copying wixlibs into your installer project: versioning - in this case any bugs made in the common library will not immediately break all projects that reference it. And you can gradually upgrade and test every project. Can you imagine auomatically downloading new version of any 3rd party dll on every build? Any change in that dll will immediately break your application even if changes are not critical to you.
Since the shared component and the active solution are in two separate projects in TFS, the workspace must be setup so that the relative paths for references remain intact. The easiest way to do this is to set your Build Agent Folder structure in Workspace in your TFS Build to have $(SourceDir) represent your root. However, don't change your Source Control Folder - that stays the same.
For example, say you have the following structure:
-TFS
|-SharedComponents
||-MyComponents
|-ProjectArea
||-MyProject
You would want to have the following two items in the build Workspace:
Source Control Folder Build Agent Folder
---------------------------------------------------------------------------------
$/ProjectArea/MyProject $(SourceDir)\ProjectArea\MyProject
$/SharedComponents/MyComponents $(SourceDir)\SharedComponents\MyComponents
This mimics the structure in TFS in your build folder, thus allowing all relative paths to remain intact.
One more note about this configuration: Since you have the shared components in another location, you may want to create a solution folder in MyProject and add the components that you are using to it. This will ensure they get pulled automatically when anyone loads your project from TFS - they won't have to go back and pull down the share components folder separately after discovering a build error.
Underneath one "Project" in TFS we have multiple products. This is because for us, a project is a business unit and they each can have many applications that we develop for them. Each one has its own folder in source control(under the TFS project) and each one has its own TeamBuild set up. The issue I have is that whenever a build runs, the report generated for it contains a listing of all the changesets that were associated to the TFS Project; even though many of them were for a different product and the code referenced actually wasn't compiled or built during that build.
Does anyone know how to get TFS to only include changesets in its report that are associated to the actual VisualStudio projects that are being built in TeamBuild?
The best solution would to to modify the Workspace Mapping for the Team Build Definition to include the Solution Root path instead of the Team Project Root.
In TFS2008,
Right click the Team Build Definition and choose 'Edit Build Definition'
Select the 'Workspace' tab
Remove the existing mapping: $/TeamProjectName
Add a new mapping to the solution root, for example: $/TeamProject/Main/Solution1/
In TFS2005,
Open Source Control Explorer
Browse to $/TeamProject/TeamBuildTypes/BuildName/WorkspaceMappings.xml
Get Latest of the file and check it out for edit
Remove the existing mapping: $/TeamProjectName
Add a new mapping to the solution root, for example: $/TeamProject/Main/Solution1/
This workspace mapping defines the scope for changesets to be included in the build.
See:
http://blogs.msdn.com/buckh/archive/2007/08/14/tfs-2008-a-basic-guide-to-team-build-2008.aspx
http://msdn.microsoft.com/en-us/library/ms181718.aspx
http://msdn.microsoft.com/en-us/library/ms181286.aspx
Grant