You need to sign in to do that
Don't have an account?
![okaylah52 okaylah52](https://dfc-org-production.my.site.com/img/userprofile/default_profile_45_v2.png)
Want to remove package but the contents must stay
We installed a package we developed. But now we want to remove the package but we still want to keep all components, e.g. Apex classes, triggers, custome fields, etc in tact. Can we just remove everything from the package using the Remove option in the Package Detail/Package Components section?
Thanks.
Could you say more about specifically what you did to get this error? When you created your Force.com project against Sandbox in the IDE did you select a package from the picklist, or did you use another option like the "Choose Metadata Components" dialog?
If you create a Force.com project against a package, then that package name is part of the project. Any new components you create from within the Force.com IDE will be added to the package on the server, and likewise any new components you add to the package on the server will be added to your project when you Refresh from Server in the IDE. This is convenient when you're actually trying to create/modify a package to publish to AppExchange, but as you discovered it's not how you want to create a project when you just want to copy things to another org.
What I think is happening, is that you have an editable package "Foo" on Sandbox, and an installed package "Foo" on production. In the IDE, when you Deploy to Server from the Sandbox project to your production organization, it tries to deploy into the "Foo" package on production. But since on production it's an installed package, you can't actually add new components to it. And since it's an unmanaged package, it's not upgradeable via the Packaging mechanism.
If my assumptions here are correct, what you want to do is create a new Force.com project against your Sandbox organization, but DON'T use the package setting. Instead, use the Choose Metadata Components dialog to select the specific components you want to deploy to production. Then when you run the Deploy to Server wizard, it won't send any information about what package any component should belong to--it should just work. Since the contents of an installed *unmanaged* package are editable in the subscriber organization, deploying from the IDE should let you overwrite anything you want. What you can't do is delete a component that's installed via an unmanaged package; to remove it you have to uninstall the entire package (I believe).
In the long run, it might be worth uninstalling the unmanaged package now and redeploying the components directly through the IDE. If your package contains any schema objects, uninstalling the package will delete the data, so if you want to preserve it you'll need to export it and reimport it (using the Data Loader or another tool)--you'll probably want to test reimporting your data on your Sandbox unless you have absolute confidence in what you're doing.
We know the question of packaging vs. deployment has been confusing in the past and we recently published a Development Lifecycle Guide that discusses a number of Force.com development process best practices in detail. You may want to check it out.
Jon
salesforce.com Product Manager
All Answers
This isn't possible. It sounds like you simply wanted to migrate the changes from one org to another. The Force.com IDE deploy operation would probably be a better tool for this as there is no package involved.
Thanks,
This is a legacy issue. When we started our development in very first time, we developed our codes online in a sandbox. Later when we wanted to migrate the codes to the production, we didn't know we could have used Eclipse. As the result, we packaged our codes and deployed the package to the production. After we gained experience and knowledge, we started to use Eclipse/Force.com IDE to develop codes.
Recently we changed some codes that were included in the package. When we tried to migrate the individual codes to the production using Force.com/Eclipse IDE, we encountered "Not in the package" error.
How can we migrate the changes to the production without using packaging. We want to get rid of using packaging since we don't deploy changes to multiple org. It's always dev sandbox > uat sandbox > production migration?
If there is no way to resolve this, then how can I migrate the changes to the production? Through the package by updating the contents then reinstall the package?
Thanks.
Could you say more about specifically what you did to get this error? When you created your Force.com project against Sandbox in the IDE did you select a package from the picklist, or did you use another option like the "Choose Metadata Components" dialog?
If you create a Force.com project against a package, then that package name is part of the project. Any new components you create from within the Force.com IDE will be added to the package on the server, and likewise any new components you add to the package on the server will be added to your project when you Refresh from Server in the IDE. This is convenient when you're actually trying to create/modify a package to publish to AppExchange, but as you discovered it's not how you want to create a project when you just want to copy things to another org.
What I think is happening, is that you have an editable package "Foo" on Sandbox, and an installed package "Foo" on production. In the IDE, when you Deploy to Server from the Sandbox project to your production organization, it tries to deploy into the "Foo" package on production. But since on production it's an installed package, you can't actually add new components to it. And since it's an unmanaged package, it's not upgradeable via the Packaging mechanism.
If my assumptions here are correct, what you want to do is create a new Force.com project against your Sandbox organization, but DON'T use the package setting. Instead, use the Choose Metadata Components dialog to select the specific components you want to deploy to production. Then when you run the Deploy to Server wizard, it won't send any information about what package any component should belong to--it should just work. Since the contents of an installed *unmanaged* package are editable in the subscriber organization, deploying from the IDE should let you overwrite anything you want. What you can't do is delete a component that's installed via an unmanaged package; to remove it you have to uninstall the entire package (I believe).
In the long run, it might be worth uninstalling the unmanaged package now and redeploying the components directly through the IDE. If your package contains any schema objects, uninstalling the package will delete the data, so if you want to preserve it you'll need to export it and reimport it (using the Data Loader or another tool)--you'll probably want to test reimporting your data on your Sandbox unless you have absolute confidence in what you're doing.
We know the question of packaging vs. deployment has been confusing in the past and we recently published a Development Lifecycle Guide that discusses a number of Force.com development process best practices in detail. You may want to check it out.
Jon
salesforce.com Product Manager