Unique Projects for Enterprise

New features are out there for VersionEye Enterprise. In an Enterprise environment it makes sense that ALL users can see ALL projects. If everybody can see everything you want to avoid to monitor the same project twice. That can happen if 2 developers create a new VersionEye project from the same project file in the same git repository and the same branch. In that case 2 VersionEye projects point to the exactly same project file on the git server. The new features address exactly this problem.

How do you define a unique project? That’s not as easy as it sounds. At first we would could say every combination of

<GIT FULLNAME> : <BRANCH> : <FILENAME>

has to be unique. That will work for most of the projects. But if you are creating/updating projects via the VersionEye API or through the VersionEye Maven Plugin, this will not work anymore. For Maven based projects the combination of GroupId and ArtifactId has to be unique.

The current version of VersionEye Enterprise supports both. If you are logged in as admin you can turn this 2 constraints on under the “Global Settings” there is a new section for “Project Settings”.

Screen Shot 2015-03-30 at 17.28.50

This new feature is implemented in the business logic of VersionEye and it works without database constraints/indexes. That means it will have no effect on already existing projects. But if somebody tries to create a new project wich already is monitored by VersionEye an error message will popup.

js_error_message_versioneye

The error message shows the Project ID of the already existing project.

This 2 constraints are specially a big help if you have a lot of projects and a lot of developers. Let me know if you have questions to this new feature.