I want to hide a physical file (eg: Sample.abc) which is generated at runtime.This should not be shown to the user.How can i programmatically handle this logic in my eclipse plugin development.
Thanks in advance
Regards
Mathan
When you want to hide some files in your application based on eclipse, you can call
IFolder byteFolder; // Some folder
byteFolder.setTeamPrivateMember(true);
byteFolder.setDerived(true);
setDerived is a interface methode of IResource
A derived resource is a regular file
or folder that is created in the
course of translating, compiling,
copying, or otherwise processing other
files. Derived resources are not
original data, and can be recreated
from other resources. It is
commonplace to exclude derived
resources from version and
configuration management because they
would otherwise clutter the team
repository with version of these
ever-changing files as each user
regenerates them.
If a resource or any of its ancestors
is marked as derived, a team provider
should assume that the resource is not
under version and configuration
management by default. That is, the
resource should only be stored in a
team repository if the user explicitly
indicates that this resource is worth
saving.
Newly-created resources are not marked
as derived; rather, the mark must be
set explicitly using setDerived(true).
Derived marks are maintained in the
in-memory resource tree, and are
discarded when the resources are
deleted. Derived marks are saved to
disk when a project is closed, or when
the workspace is saved.
Projects and the workspace root are
never considered derived; attempts to
mark them as derived are ignored.
This operation does not result in a
resource change event, and does not
trigger autobuilds.
I'd probably go with Markus' solution as it works in the generic case.
An alternative, much simpler, approach is to make the file name begin with ".", by default all files with that prefix are hidden in Eclipse (e.g. the .project and .classpath files in every project).
Related
I'm working with TFS 2013 via the TFS Server plug-in for Eclipse (Team Explorer Everywhere v14.0.1).
We have two branches of a project, a master and a release. Each has a DEV folder (containing application.properties, logback.xml, etc ) in which environment configuration is maintained. The folder was initially placed in source control to allow new members to pull everything they need in one shot. Now, however this seems burdensome to established team members as when trying to switch between branches, the error
The item $/projectName/project-branchName/src.../DEV may not be
cloaked because it does not have a mapped parent.
To switch branches, one must uncloak any cloaked folders to continue. I have since deleted folders which contain dev configurations or those which should stay out of source control.
However, I'd like to know is there another way to resolve this?
Are you trying to use and edit a single workspace when trying to "switch" branches?
If so, the recommended approach is to use two different workspaces, one for each branch, and then switch between workspaces.
The reason for this can be best illustrated with an example:
Imagine your workspace contains two mappings:
map $/projectName/project-branchName/src some-local-path
cloak $/projectName/project-branchName/src.../DEV
and by “switching” you mean that you edit the workspace mappings and change project-branchName from master to release or vice versa. This is a typical catch-22. If you change the branch name in the first mapping first, you immediately get an error because the second mapping tries to cloak a folder in the old branch, which is not mapped anymore. If you first change the branch name in the second mapping, you get an error because the mapping tries to cloak a folder in the new branch, which is not mapped yet.
Not sure this fully answers your question. If not, please feel free to provide a little more explanation of what you are attempting to do and we'll see if we can better assist!
Thanks!
How do I have a Project Explorer's Working Set be built automatically from the contents of .gitignore, and then kept in sync with .gitignore?
I am working on a C++ AutoTools project which, as it is common for AutoTools projects, generates quite a lot of files during the build stage. I do have them .gitignored already. Now I'm trying Eclipse on that project, and found that I'd have to carefully pick files to ignore again.
You cannot. This feature does not exist.
The working sets functionality was implemented a long time before GIT appeared, and it was a method for removing clutter in large projects, and what is important, it was was a method that resided in the UI domain.
In fact, A working set extension point documentation shows it is possible to create a self-updating working set, and the search over the egit codebase returns no results.
As I have said, this feature is not implemented.
However, you can create your own plugin that will do what you want. It is not very complicated, and should not take more than a day or two. Or just open a feature request in the Eclipse bugzilla.
As for your underlying problem, you could try using the derived resources mechanism. It was added to make possible to prevent team providers (CVS/GIT) from managing files that are a result of a build.
Just a word of warning - GIT won't allow you to ignore further changes to any resource already under its control.
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.
I work on a large project where all the source files are stored in a version control except the project files. This was the lead developer's decision. His reasoning was:
Its to time consuming to reconcile the differences among developers' working directories.
It allows developers to work independently until their changes are stable
Instead, a developer initially gets a copy of a fellow developer's project files. Then when new files are added each developer notifies all the rest about the change. This strikes me as far more time consuming in the long run.
In my opinion the supposed benefits of not tracking changes to the project files are outweighed by the danger. In addition to references to its needed source files each project file has configuration settings that would be very time consuming and error prone to reproduce if it became corrupted or there was a hardware failure. Some of them have source code embedded in them that would be nearly impossible to recover.
I tried to convince the lead that both of his reasons can be accomplished by:
Agreeing on a standard folder structure
Using relative paths in the project files
Using the version control system more effectively
But so far he's unwilling to heed my suggestions. I checked the svn log and discovered that each major version's history begins with an Add. I have a feeling he doesn't know how to use the branching feature at all.
Am I worrying about nothing or are my concerns valid?
Your concerns are valid. There's no good reason to exclude project files from the repository. They should absolutely be under version control. You'll need to standardize on a directory structure for automated builds as well, so your lead is just postponing the inevitable.
Here are some reasons to check project (*.*proj) files into version control:
Avoid unnecessary build breaks. Relying on individual developers to notify the rest of the team every time the add, remove or rename a source file is not a sustainable practice. There will be mistakes and you will end up with broken builds and your team will waste valuable time trying to determine why the build broke.
Maintain an authoritative source configuration. If there are no project files in the repository, you don't have enough information there to reliably build the solution. Is your team planning to deliver a build from one of your developer's machines? If so, which one? The whole point of having a source control repository is to maintain an authoritative source configuration from which you build and deliver releases.
Simplify management of your projects. Having each team member independently updating their individual copies of your various project files gets more complicated when you introduce project types that not everyone is familiar with. What happens if you need to introduce a WiX project to generate an MSI package or a Database project?
I'd also argue that the two points made in defense of this strategy of not checking in project files are easily refuted. Let's take a look at each:
Its to time consuming to reconcile the differences among developers' working directories.
Source configurations should always be setup with relative paths. If you have hard coded paths in your source configuration (project files, resource files, etc.) then you're doing it wrong. Choosing to ignore the problem is not going to make it go away.
It allows developers to work independently until their changes are stable
No, using version control lets developers work in isolation until their changes are stable. If you each continue to maintain your own separate copies of the project files, as soon as someone checks in a change that references a class in a new source file, you've broken everyone on the team until they stop what they're doing and carefully update their project files. Compare that experience with just "getting latest" from source control.
Generally, a project checked out of SVN should be working, or there should be tools included to make it work (e.g. autogen.sh). If the project file is missing or you need knowledge about which files should be in the project, there is something missing.
Automatically generated files should not be in SVN, as it is pointless to track the changes to these.
Project files with relative path belong under source control.
Files that don't: For example in .Net, I would not put the .suo (user options) web.config (or app.config under source control. You may have developers using different connection strings, etc.
In the case of web.config, I like to put a web.config.example in. That way you copy the file to web.config upon initial checkout and tweak what settings you'd like. If you add something that needs to be added to all web.config, you merge those lines into the .example version and notify the team to merge that into their local version.
I think it depends on the IDE and configuration of the project. Some IDEs have hard-coded absolute paths and that's a real problem with multiple developers working on the same code with different local copies and configurations. Avoid absolute path references to libraries, for example, if you can.
In Eclipse (and Java), it's fine to commit .project and .classpath files (so long as the classpath doesn't have absolute references). However, you may find that using tools like Maven can help having some independence from the IDE and individual settings (in which case you wouldn't need to commit .project, .settings and .classpath in Eclipse since m2eclipse would re-create them for you automatically). This might not apply as well to other languages/environments.
In addition, if I need to reference something really specific to my machine (either configuration or file location), it tend to have my own local branch in Git which I rebase when necessary, committing only the common parts to the remote repository. Git diff/rebase works well: it tends to be able to work out the diffs even if the local changes affect files that have been modified remotely, except when those changes conflict, in which case you get the opportunity to merge the changes manually.
That's just retarded. With a set up like that, I can have a perfectly working project containing files that are subtly different from everyone else. Imagine the havoc this would cause if someone accidentally propagates this mess into QA and everyone is trying to figure out what's going on. Imagine the catastrophe that would ensue if it ever got released to the production environment...!
I have been using an open source Java project and had to make some custom changes for our site. I have downloaded the source code via Subversion, modified two files and built a custom JAR file. Now I need to store these custom changes into OUR Subversion source control system. What is the best way to do this?
Should I check the entire tagged version of the open source code into our system and then create a branch with our change in it? Or should I just check-in our custom files and rely on the open source tagged version to always be around? Or perhaps something else altogether?
Take a good look at Subversion vendor branches, which are meant for "maintain[ing] custom modifications to third-party data in your own version control system". This sounds like exactly what you want. You would create a vendor branch for the open source Java project in your main repo (from their last SVN revision before your modifications). Then, check in your modifications. In the future, you can merge in upstream changes.
The Subversion book is free and available online, with a section devoted to choosing a repository layout.
the Subversion community recommends
that you choose a repository location
for each project root—the “topmost”
directory that contains data related
to that project—and then create three
subdirectories beneath that root:
trunk, meaning the directory under
which the main project development
occurs; branches, which is a directory
in which to create various named
branches of the main development line;
and tags, which is a collection of
tree snapshots that are created, and
perhaps destroyed, but never changed.
I'm happy to elaborate if you are having trouble determining what exactly this means for your project.
First try to avoid this as long as you can, if it is possible try to get your changes into the open-source project (less work for your self in the future...)
But if that was not a option, I would follow Matthew Flaschen advice about vendor branches.