0

I am trying to deploy an unmanaged package in a Metadata API zip file and access it via a namespace. My zip file has the structure:

Test_Package/package.xml
Test_Package/classes/ZZZ.cls
Test_Package/classes/ZZZ.cls-meta.xml

My package.xml looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <fullName>Test_Package</fullName>
    <types>
        <members>ZZZ</members>
        <name>ApexClass</name>
    </types>
    <version>32.0</version>
</Package>

ZZZ.cls is this:

global class ZZZ { }

... and finally ZZZ.cls-meta.xml is this:

<?xml version="1.0" encoding="UTF-8"?>
<ApexClass xmlns="http://soap.sforce.com/2006/04/metadata">
    <apiVersion>32.0</apiVersion>
    <status>Active</status>
</ApexClass>

When I run this deploy, everything succeeds, and afterwards I can see "Test_Package" under the Create > Packages setup menu, with "ZZZ" as a class inside. However, when I click "ZZZ" it has a blank namespace prefix. The "ZZZ" class also appears in the Develop > Apex Classes menu on it's own, and I can refer to it in code like this:

ZZZ z = new ZZZ();

It appears that this did not deploy into a namespace as I had hoped... Is there something I did wrong here in the deployment steps, or do I misunderstand how unmanaged packages work?

1

Namespaces are only for managed packages. Unmanaged packages can't have a namespace. Namespaces aren't meant to avoid conflicts within a single org, but instead designed for ISVs to produce packages that will install in any org without the risk of name collisions between objects, classes, triggers, etc, as well as creating extension packages.

|improve this answer|||||
  • Thanks for the clarification. This is unfortunate for us, as we have some shared code we would like to install in multiple orgs without conflict (without need for a managed package) but it seems that this may not be a viable solution. If an unmanaged package doesn't provide a namespace, do you know what the purpose for one is? – user2221343 Jan 27 '15 at 15:27
  • As I stated, it's for ISVs to create upgradable packages. There's no real purpose for non-ISVs to use namespaces at this time. The limitations of namespaces is arguably one reason why you wouldn't want to use them anyways, such as not being able to change data types, deprecate global APIs, etc... – sfdcfox Jan 27 '15 at 16:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.