Apex Code Development You need to sign in to do that
Don't have an account?
slane Why does my project include "referenced packages"?
Hi All:
I'm developing using Eclipse and trying to figure out why I keep getting "Referenced Packages" in my project definition.
I'm using a standard 2-person development org. Made a new project in Eclipse, and defined it to include just a single Apex class.
When the project is done building, I have my src folder, with src/classes/MyClass.cls. But I also have a "Referenced Packages" folder with, in this case, a bunch of stuff from the Ajax Toolkit.
IN this case, it makes the local project hard to manage or delete since the resources come down as read-only. On another larger project I'm working on, it's a much larger pain, as Eclipse tries to run tests in the referenced packages (which I don't manage or control) when I am running unit tests.
Can anyone help me understand why this happens, and whether it can be avoided?
Thanks,
Steve Lane
What I do when creating a new eclipse project is to select the radio button to not bring down anything from the server (or you could just bring down the unpackaged stuff). The point is the default is to bring in everything (so don't choose that). After the project is created, go into project synchronization and select the specific folders you want in your project. When you go back to the project page, just update the project from the server (which will bring in the stuff from only the folders you selected from now on).
You can remove the stuff you already have without starting a new project. Just go to the directory, and actually delete the folders you don't want and then do a project refresh in eclipse. It only downloads into folders that exist in your project. Example: Project with package A and B. Want to stop getting package B. Go to project directory and remove folder B. When next you update the project, it will not see folder/package B so it will not grab it from the server.
Thanks lamayc. I think I'm mostly doing this. When I defined the project I selected the option to choose components by hand -- rather than get all components, or get a specific SFDC package.
Even when I selected just one Apex class file, I still get a folder full of "Referenced Packages." They are read-only and can't be deleted even from my local drive without extra trouble.
I see no references to these packages anywhere in my packahe.xml or anywhere else, so I'm cofused why they're coming down when, as lamayc suggests, I've defined the project to just include the items I want to work with.
The "Referenced Packages" folder is created for every Force.com project, and it contains the contents of any installed managed packages in the organization. It's there because there's no other mechanism available to request managed content, but some of the files may be useful for reference (but not for editing).
I can assure you, the presence of the Referenced Packages folder has NO impact on what tests are run on the server.
May I ask, are you by chance creating projects against a production organization? (In the Force.com IDE, saving a file uses the same API verb as deploying, which means if you create a project against production then every time you save, it runs all tests in the organization. Which is why we strongly recommend against creating projects against production.)
As for deleting projects, the Spring '09 release of the Force.com IDE works around the Eclipse bug that makes deleting read onnly files so painful in previous releases.
If you don't need to look at any of the metadata in under Referenced Packages you can usually just ignore it. Are you experiencing other negative impacts from the presence of this folder?
Jon
salesforce.com Product Manager
Jon:
Thanks, good to know this is expected behavior :-)
Now that said, we are definitely seeing tests run that don't involve our code. Is it possible that some of our objects, like profiles, were created in such a way as to auto-create dependencies on these managed packages?
We are creating the project against a development sandbox, not production.
-- Steve
You're running tests by right-clicking on "src/classes/", or on individually selected Apex classes, and selecting Force.com > Run Tests?
Can you post a screenshot of the Apex Test Runner window, showing the installed managed package tests being executed?
What Force.com IDE, Eclipse, and OS versions are you running?
Thanks,
Jon
Hi Jon:
Yes, we're running tests by right-clicking src/classes and selecting Force.com > Run Tests.
Here's our project structure:
And here's the test run result. Our components are almost all prefixed with SMART_.
Force.com IDE 14.0.2.200812101436
Eclipse 3.3.2
Mac OS 10.5.6
For what it's worth, our Eclipse project is sourced from a development package.
Thanks very much for looking at this with me.
-- SGL
It looks to me like most of those extra items are triggers, not classes. Since triggers can't contain test methods, that's not adding any overhead. What you're seeing is code coverage results from the tests you've run. It may be that your tests are not intended to cover many of those triggers, in which case you can just ignore that.
If I recall correctly, a change went out in the Spring '09 release to make Sandbox/DE code coverage reporting (but not enforcement!) more like production. Previously, a lot of people had posted that they were seeing different overall code coverage results in production than in Sandbox/DE. This was because Sandbox/DE used to calculate the number from just the code you called. So the Sandbox/DE test results have been brought more in line with how production works so you will be more likely to discover code coverage gaps early (as opposed to during your productiond deployment window).
Sorry if I'm a little fuzzy on the details, it's been a while. But I think this is why you're seeing what you're seeing.
What would you ideally like to see when you run tests from the IDE?
Thanks,
Jon
Yes, the extra items have nothing to do with our app. A good number of them do appear to be classes, where the code coverage is being counted in our overall. So even when the code coverage OF OUR CODE approaches say 85%, the coverage result for the above run will be like 65%.
What I'd ideally like to see is an indicator of whether my code will deploy successfully. And it sounds like there's something maybe I don't understand here. When code is pushed to production, is just that code assessed for coverage, or are tests re-run on the whole org? From your response, sounds like the latter.
But here's the issue, it seems to me. It sounds like for Salesforce the focus is really at the org level, and the behavior of the org is considered as a whole. This view of things doesn't work terribly well for our app. We're developing it in a client's org. We really don't know what the other apps and objects in the org are, nor can we do anything with them, fix errors, etc. We may not even know who owns them, the org is very large. (This has actually created other issues for us, as the org is so large that it is apparently impossible to run all tests in the org without the testing UIs timing out. We have escalated this).
Ultimately what I would want to see in this case is the coverage just for my app. I'mon the hook for the deployability of my app, but if someone's else's tests fail when I deploy, that may or may not be my problem.
I see how, for apps that hook into, modify or extend standard objects, you would need to in effect test the whole org. Our case is interesting, as our app has nothing to do with the CRM and is really entirely self-contained.