Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 320659

Summary:

[TS Explorer] Creating an artifact with the same name as an inner package confuses TS Explorer

Product:

[Technology] Tigerstripe

Reporter:

Navid Mehregani <nmehrega>

Component:

Assignee:

Project Inbox <tigerstripe.ui-inbox>

Status:

VERIFIED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

skanton, yuri

Version:

unspecified

Target Milestone:

0.5M0

Hardware:

OS:

Mac OS X - Carbon (unsup.)

Whiteboard:

Attachments:

Description	Flags
Screenshot	none
320659 patch	none

Description Navid Mehregani

2010-07-22 15:28:59 EDT

Build Identifier: 

Follow the instructions below to reproduce this issue:

- Create a new TS Project
- Create a package called com.mycompany.foo
- Create a new Entity under com.mycompany called 'foo'

This will cause the icon for the 'foo' package to change to an Entity package (see attached screenshot).  You can still drag and drop the Entity into foo package, but the icon changes to a package icon used in the Package Explorer!!

Reproducible: Always

Comment 1 Navid Mehregani

2010-07-22 15:29:37 EDT

Created attachment 175014 [details]
Screenshot

Comment 2 Anton Salnik

2010-12-30 04:09:19 EST

Internally Tigerstripe manages each artifact by it's FQN, where FQN is string representation of package name + artifact name. And internally there are only one artifact associated with a FQN. Therefore the existence of two artifacts with the same FQNs causes problems discribed above (ArtifactManager returns entity artifact instead of corresponding package artifact).

I see two possible solutions to solve the problem:

1. Now you can't create a package if an artifact with the FQN is already exists. You receive "Type already exists" warning. So we can show the similar warning to prevent an artifact creation if a package with the FQN is already exists;
2. Change FQN structure, i.e. add additional information about element type.

The 1. is more easy solution, when 2. is more correct but a lot of core parts will need to be refactored.

What do you think about it?

Comment 3 Navid Mehregani

2011-01-03 09:52:51 EST

Hey Anton,

Solution #1 is sufficient.  I don't think a lot of users will run into this case so we shouldn't spend all the efforts involved for #2.  Instead we should prevent them from falling into the trap.

Comment 4 Anton Salnik

2011-01-12 07:53:34 EST

Created attachment 186618 [details]
320659 patch

Comment 5 Yuri Strot

2011-01-13 00:55:12 EST

Anton's patch applied.

Comment 6 Navid Mehregani

2011-01-17 09:44:10 EST

Verified. Thanks!