Remove vocabulary support

This strikes me as sort of a co-issue between UUID Features and UUID itself. I can see two topics to touch on in resolving it:

1. Feature deployment. The more immediate issue is how terms are associated with vocabularies, and subsequently their UUIDs. Since a term must exist under a vocabulary, if that vocabulary doesn't already exist (but is added via Features core taxonomies), do you simply add it to that vocabulary? How do you account for the UUID of that newly-created vocabulary?
2. Vocabulary distributing. When distributing the vocabulary in any fashion (publishing, etc.), how do we account for its identifier? By using UUIDs of a single vocabulary that may or may not actually be the same across installations (refer to previous point)? By using the vocabulary's machine name? Can we rely on developers (or even just noob site admins) to namespace it properly so we don't run into consistency problems? In other words, are we ready to give up on the power (and complexity) of UUIDs to uniquely identify vocabularies?

Food for thought.

P.S. This is probably too dirty for its own good, but one could alter the core taxonomy export to include the UUIDs of vocabularies and still tie a term to the UUID of the vocabulary. But hey at least it's practical.

Actually, I suppose this doesn't at all conflict with core taxonomy. All it will potentially do is save the vocabulary a second time (or first, if core taxonomy gets rebuilt first) and set the UUID for this vocabulary. The existing solution addresses both issues above in #1.

Then again, @zroger will need to remember to update the implementation when Features changes its core taxonomy features.

A potential solution is to simply export the machine name + UUID.

In hook_features_export_options, return only vocabularies that have both a machine name and a UUID.

In hook_features_export, add in core taxonomy vocabulary. This way everybody's happy.

Here's my go at it.

Since it has essentially become a matter of exporting the UUID of vocabularies, I've renamed the component to "Vocabulary UUID".

Hello maintainers. Any word on this?

If #1159832: Remove vocabulary support for Drupal 6 moves forward, I will reroll a patch that removes support for vocabulary UUIDs. If necessary, I will also see if I can devise a transition procedure to re-export terms with vocabulary machine names.

Per my request in the UUID issue above, I propose this module also advance to 6.x-2.x for this issue.

Hi guys !

UUID Features vocabulary support is conflicting with Features' core.
When enabling a Feature, vocabulary is created twice with the same machine name so UUID Features terms support crash followed by node support.
I have just tried it under the last 7.x-1.x-dev version.

I think it is time to defintely drop vocabulary support as it is fully and reliably integrated in Features' core.

Here is a patch for 7.x branch
It just removes vocabulary support as it is now handled by Features' core.

There are other bugs that needs to be fixed but I will use another thread for it

Cancels and replaces the previous patch.
Sorry for the inconvenient I made a mistake in my commits.

Seems this patch is already applied in 7.x dev.
How about this:

./includes/modules/taxonomy.inc-12-    foreach ($node->taxonomy as $term) {
./includes/modules/taxonomy.inc-13-      $vocabulary = taxonomy_vocabulary_load($term->vid);
./includes/modules/taxonomy.inc-14-      $voc_uuid = $vocabulary->machine_name;
./includes/modules/taxonomy.inc:15:      $pipe['uuid_vocabulary'][$voc_uuid] = $voc_uuid;

6.x related: #926012: Misspelled 'hierarchy' in vocabulary properties whitelist