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 Answer 1

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.

2
  • 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? Commented Jan 27, 2015 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
    Commented Jan 27, 2015 at 16:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .