Verified in JBT 4.0.0.CR1-v20121125-0706-B9.

Rob I have found out, why archive identifiers had the same value. Packages file from my original test project is:

<?xml version="1.0" encoding="UTF-8"?><packages version="1.3">
  <package exploded="false" inWorkspace="true" name="pr3a.jar">
    <properties/>
  </package>
  <package exploded="false" inWorkspace="true" name="pr3b.jar">
    <properties/>
  </package>
  <properties/>
</packages>

As you can see, there are no archive identifiers. So when importing such a project into workspace, these identifiers were generated with the same values because there were generated at the same time I guess.

My question is: how can be generated such a package file where there are no identifiers?

This has been committed to cr1 with more randomness.

propVal = (("" + new Date().getTime()) + System.nanoTime()) + generator2.nextInt();//$NON-NLS-1$

(generator2 is a Random object).

Other options are:

• UUID
• Random

Dennis:

Would it make sense to put in a 2ms delay after generation of each archive and synchronize the method in charge of it to ensure multiple threads can't enter it at once?

The current mechanism obviously fails and there is no checks for duplicate id generation or setup within even the same file - that is broken!

Why aren't the relative workspace location of the .archive folder + a truly unique field (i.e. the name or an id?) within this single file enough ?

> Grab Intel i7 Quad Core 3.2GHz and try it. I got equal values for your scenario above. I cannot understand why do you need this ID if file names should be unique anyway?

There needs to be a unique identifier for the project archive. You argue it could be the "file name" but that's not true. Two different projects and their .packages files can have files with the same name. it could also be the output file's full path, but some users may choose to have a strange workspace environment where two projects output to the same place.

Finally, even if we chose one of these, the user may change those values. If we chose the full output path of the archive to be the unique identifier, than when a user changes the output folder, or output name, the rest of the toolset would think it's a different archive.

This becomes more important when it comes to deployment of project archives. If you were just using project archives alone, this wouldn't matter at all, but because a server keeps a "module id" to know what's deployed, every archive needs a unique identifier, and this cannot change. So therefore, using any property that can change (archive name, archive output folder, archive source folder, includes / excludes pattern, or ANYTHING that can be changed), this leads to failures.

Rob I created the project and archives simply with UI, not programmatically.

So the real question here is, how did you get a single project that has two identical id's?

Grab Intel i7 Quad Core 3.2GHz and try it. I got equal values for your scenario above. I cannot understand why do you need this ID if file names should be unique anyway?

looking for more feedback to track the origin of the bug.