I just want to know if the search result in eclipse search view can be shared with fellow team mate as it is.
I perform a search and delete few unwanted entries and then send it to him/ her
The other person shall be able to view it exactly same manner in the search view.
Is there a way to do this?
The will be very helpful for me
You should be looking at the Mylyn project (http://eclipse.org/mylyn).
This project allows you to create tasks and send them to co-workers through a task repository (such as bugzilla, jira, or most major issue trackers). Attached to these tasks are "contexts", which associate code elements (methods, fields, classes, etc) with the task.
Here is what you would need to do:
Install mylyn (you and all co-workers)
Install the proper connector for your issue tracker (most major issue trackers have one). If you are not using an issue tracker, then you can still import and export tasks as files, but it is less easy to do, and I'd recommend using an issue tracker anyway.
Now add the task repository to your Eclipse. This is the way that mylyn speaks to your issue tracker. It allows you to create issues, bug reports, tasks, etc, from within Eclipse.
With this set up, you can now create a task associated with a task repository and activate it. You can add the desired program elements to your task by right clicking -> Mark as Landmark.
Once you have your task context complete, you can then attach the context to the remote repository (essentially attaching a zip file to the issue in your issue tracker). Other users can then retrieve the context and immediately start working with the context that you created.
It is really a great way to work when you need to share information about specific features in the code to other people on the project.
Related
We are currently working on the architecture of our Salesforce DX project. We've got an extensive codebase of existing customizations and are planning to turn them into multiple Unlocked Packages to make everything more modular etc. Of cause, not everything is subject to be packaged, some features would stay unpackaged.
And the question is: should this be a single project (with multiple package directories inside and single Git repo) or a project per feature is more preferrable (multiple Git repos)? How would you manage dependencies between packages and unpackaged stuff?
Could you please advise?
The Salesforce cli can run from anywhere. But certain commands are required to executed in the context of a Salesforce project directory. This includes all commands that execute packaging, deploying code to an org, all of which drives any CI/CD process you might use.
As I imagine trying to arrange a CI process spread across multiple projects, each with their own project folders, it seems like it would be adding unnecessary complexity.
Fundamentally, unlocked packages were designed to share a single Salesforce project. So unless you've found a reason otherwise, going that direction is the right move.
The Salesforce developer evangelist team maintains a sample app that is built using the multiple package model called "Easy Spaces". I'd suggest looking in the sfdx-package.json file there to understand how to arrange and identify package dependencies.
You may be able to infer some ways to organise the code in your project accordingly.
How to make all those decisions is way too much for a single answer. But this youtube video is a customer development team leader sharing how they rearchitected their codebase to use unlocked packages.
If you have any problems as you get started, there are also a number of questions already asked on the Salesforce StackExchange site, too.
In Eclipse PDE, when looking for resource changes (using IResourceChangeEvent), how do I find out exactly when a project is created? Do I have access to the project (as an IProject) in this context?
Several parts to this answer:
When resources change, your listener gets an event. From that event you can get a delta describing the resources that were changes. You implement a visitor (passed to the delta with the accept() method) that actually implements your response to the change and controls how far down the delta you want to traverse by answering a boolean from its visit() method. You probably won't traverse too much since any new projects will be at the top of the delta. Once you've recognized that you're visiting a delta node representing a new project (you use flags() and getKind() to see whether or not it's a new project) you can take whatever action you'd like.
The other part of this answer is to warn you that often resource changes are batched, usually for performance reasons, so you might get notified of a new project being created after many files have been created into that project.
To augment the other answer that referenced resource change listeners...
Reliably detecting project creation is actually rather difficult. The issue is what you define as project creation. To the Eclipse resources layer, project creation is when a blank project is created (no metadata or files of any sort), but in a typical scenario you want to know when a particular kind of project is created.
This means that you cannot assume that when your code receives a project creation event, that you will be able to ask questions about that project. Project creation event may be delivered together with subsequent file events in a single batch or the events may trickle in separately.
Another consideration is that to Eclipse project creation is a number of different scenarios. It could be user running a project creation wizard, or importing existing project from disk, or importing from Git, or any number of other ways that a third party plugin may cause a project to be added to the workspace. Each of those scenarios will have slightly different way in which events are batched or trickle in.
The only solution is to look at file events as opposed to project events. Figure out what questions your listener needs to ask of the project, then figure out what files contain the answers and track those files. For instance, if you need to check for a nature and a classpath entry, monitor .project and .classpath files. Don't assume that the project is always in consistent state. It may not be if you are looking at it part way through a Git import.
So I've recently started using Mylyn at my company, love it personally and works great with Jira. However now I'm trying to get it working on Github for personal projects that I work on with several other people.
I'm using Eclipse Juno with the Github connector and added the repository information. When I go create a task, it correctly does so and does pull the tags that I have configured correctly, so I know it has good connectivity both ways. When I save the task in Mylyn it will show up on Github just fine.
The problem is, I need access to issues that others create on Github, but when I create a Query in Mylyn and name it ( Say "All Bugs" ), then choose the bug labels and hit finish it shows the query in the Task view, however it is empty and never retrieves the list of Issues from Github. I know their there, it's just not showing them in Mylyn, and Mylyn isn't throwing any errors.
I've also tried a Query with all the above and "Mention" field with my name( just in case the blank fields were messing with the query ) however that didn't work either.
One thing to note, I'm using this on a Private repo, but doing searching( and as evidence that I can fetch labels and push issues ) I don't think private Vs public repos are an issue here.
Really hope someone can lend a hand. Thanks
#TheKojuEffect answered this one for me here:
Why Mylyn is not getting issues from GitHub?
Basically, if you select more than one label in your query in Eclipse, the query will only pull the issues with ALL of those labels (Logical AND, as opposed to the OR that I was expecting). Create a query for each of the issue labels you'd like to see.
The best approach to this is to open a bug report against Github connector for Mylyn.
I am looking quickly move changes between Salesforce Production & Sandbox. Is there any way we can know the difference between two environments i.e How many workflows, objects, email templates are modified/added in compared view.
I know we can use outbound change set but its tedious job of moving the changes and not feasible when Production is continuously being updated.
After speaking with the experts at two Dreamforce conferences I find the only way to get a description of an instance is to use the force.com IDE, as suggested by LaceySnr. I've learned a couple techniques that help.
First, I no longer even attempt to use change sets. These are time consuming to build, have no clarity as to what is really inside and sometimes just won't work.
Second, I keep at least two force.com IDE projects for each instance (test,production). The first project has everything (check everything in the metadata component). The second project is tiny and only has the components I want to work on.
The first project is checked into some change control system; CVS, SVN, Git, Mercurial, etc. Your choice. Using the differencing tools on this project let's you compare change sets.
But it is nearly impossible to develop using the first project because it takes too long for force.com to process even the smallest change. This is because it processes the entire project whenever any change is made. So, make all the code changes in the smaller project.
Then look at the ANT build tools http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_deploying_ant.htm to automate the migration of changes from the smaller to larger project.
I've not done this with workflows, but it is a method I use for code, layouts and objects: Use the force.com IDE from http://developer.force.com to setup projects for both Sandbox and Production, being sure to select all of the metadata components that you want (you'll want to include workflows for instance).
This will leave you with the contents of your projects stored inside a project directory in the IDE's workspace directory, then you can easily use a diff tool (I use the free DiffMerge on Mac) to compare the directories, and of course drill down into files to see what changes exist.
Context: I'm currently working as an intern at a company which has made the move to TFS 2010 from VSS. TFS has been in use here for a couple of months now, but in the early period after the move some 'mistakes' were made in setting up the projects. After while the need for a custom team project template was recognized. The template has been developed and is now being introduced into the organisation. (small web development company, many small projects)
Question:
We're trying to migrate old projects to the new template by setting up new pojects with the custom template. We'd like to move the sources of the old projects into projects making use of the new template. The history of the sources should be preserved for support reasons. It is undesireable for the old projects to appear in the Team Collections' Team Projects list, so we'd like to hide them if deletion is not an option. (to reduce the garbage in the list)
I have some solutions on my mind to get the job done, but I'm unsure if they'll work out. (even after spending some time researching the issue on the web)
1: Doing a branch from the old project into the new and then deleting the old project. I think it should keep the history of the the old project has been deleted. Some people over here are very vocal about this not being the case causing some strife. Before pushing this option I'd like to be sure this will work
2: Hijack the migration tool to migrate sources between projects (possibly via via a temporary Team Collection). I have read this could be an option, but the details of how to execute such a move are still unclear to me. It seems this has a lot of caveats attached to it and can be cumbersome to execute. (I'm no superman when it come to these matters, but so is noone else over here)
The Migration guide seems to suggest that this might be possible, but I can't determine if this scenario is supported, and how to recover if things go wrong.
Maybe it is possible to set up the new projects and hide the old projects from the team collections' team projects list without deleting them? (I wonder if there is some kind of inactive setting for team projects, I can't seem to find any such option after exploring the tfsconfig tool of the admin console)
An explanation of how to best apporach this problem and possible solutions would be much appreaciated.
Doing a branch from the old project
into the new and then deleting the old
project. I think it should keep the
history of the the old project has
been deleted.
I'm pretty sure if the old team project is deleted, the part of history that is associated with that team project will also be gone, see here for more details. You can confirm this by doing a quick test move if you want.
Maybe it is possible to set up the new
projects and hide the old projects
from the team collections' team
projects list without deleting them?
You can mostly achieve this by denying read access (GenericRead) to most of the users on the old team projects. Of course for the Project Collection Administrators who have this permission by default on all the team projects, the old team projects still appear in the list for them.
Good luck!
There is no firm relationship between a team project and a particular part of the source control tree. Let's say you have a team project named "Mistake". You have source at "$/Mistake". You can now create a new team project named "Got It Right", and specify to use the sources at "$/Mistake".
Use the source control explorer to move a solution between projects. Here is how the projects and solutions appear before moving a solution.
The move selection is found by either
right-clicking the solution, choosing Move from the drop-down menu
Selecting Move from the Source Control menu found under File in the drop down menu