[JBoss JIRA] (SRAMP-535) Correct JCR trash pat
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/SRAMP-535?page=com.atlassian.jira.plugin.... ]
Brett Meyer updated SRAMP-535:
------------------------------
Summary: Correct JCR trash pat (was: Reset UUID of artifact when it is deleted)
> Correct JCR trash pat
> ---------------------
>
> Key: SRAMP-535
> URL: https://issues.jboss.org/browse/SRAMP-535
> Project: S-RAMP
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.5.0.Beta3
> Reporter: Eric Wittmann
> Assignee: Brett Meyer
> Priority: Critical
> Fix For: 0.6.0
>
>
> Currently when an artifact is deleted we do not delete the JCR node. Instead we move it to another location in the JCR tree. This allows us to potentially add a new node with the same UUID (e.g. a user-specified one).
> However, the deleted artifact is still sitting over in the trash JCR folder with that original user-defined UUID. So now if you try to delete the new artifact you'll get this:
> {code}
> A node definition that allows same name siblings could not be found for the node "/s-ramp-trash/artifacts/03/3a/75/4766e0b8f42a6810ecd6dd73c441a3ed7e[2]" in workspace "default"
> {code}
> Possible solution is to generate a new UUID for the trashed artifact when it gets moved? Or else allow same-name-siblings in the JCR tree only for s-ramp/trash (not sure this is possible).
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (SRAMP-535) Correct JCR trash path
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/SRAMP-535?page=com.atlassian.jira.plugin.... ]
Brett Meyer updated SRAMP-535:
------------------------------
Summary: Correct JCR trash path (was: Correct JCR trash pat)
> Correct JCR trash path
> ----------------------
>
> Key: SRAMP-535
> URL: https://issues.jboss.org/browse/SRAMP-535
> Project: S-RAMP
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.5.0.Beta3
> Reporter: Eric Wittmann
> Assignee: Brett Meyer
> Priority: Critical
> Fix For: 0.6.0
>
>
> Currently when an artifact is deleted we do not delete the JCR node. Instead we move it to another location in the JCR tree. This allows us to potentially add a new node with the same UUID (e.g. a user-specified one).
> However, the deleted artifact is still sitting over in the trash JCR folder with that original user-defined UUID. So now if you try to delete the new artifact you'll get this:
> {code}
> A node definition that allows same name siblings could not be found for the node "/s-ramp-trash/artifacts/03/3a/75/4766e0b8f42a6810ecd6dd73c441a3ed7e[2]" in workspace "default"
> {code}
> Possible solution is to generate a new UUID for the trashed artifact when it gets moved? Or else allow same-name-siblings in the JCR tree only for s-ramp/trash (not sure this is possible).
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (SRAMP-535) Reset UUID of artifact when it is deleted
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/SRAMP-535?page=com.atlassian.jira.plugin.... ]
Brett Meyer commented on SRAMP-535:
-----------------------------------
Impl note: The sramp:uuid property stays the same on the Node. I simply changed the trash path to s-ramp-trash/uuid/timestamp. Later, when auditing supports deleted artifacts, we can simply look up the uuid path and grab its children, rather than having to deal with convoluted logic.
> Reset UUID of artifact when it is deleted
> -----------------------------------------
>
> Key: SRAMP-535
> URL: https://issues.jboss.org/browse/SRAMP-535
> Project: S-RAMP
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.5.0.Beta3
> Reporter: Eric Wittmann
> Assignee: Brett Meyer
> Priority: Critical
> Fix For: 0.6.0
>
>
> Currently when an artifact is deleted we do not delete the JCR node. Instead we move it to another location in the JCR tree. This allows us to potentially add a new node with the same UUID (e.g. a user-specified one).
> However, the deleted artifact is still sitting over in the trash JCR folder with that original user-defined UUID. So now if you try to delete the new artifact you'll get this:
> {code}
> A node definition that allows same name siblings could not be found for the node "/s-ramp-trash/artifacts/03/3a/75/4766e0b8f42a6810ecd6dd73c441a3ed7e[2]" in workspace "default"
> {code}
> Possible solution is to generate a new UUID for the trashed artifact when it gets moved? Or else allow same-name-siblings in the JCR tree only for s-ramp/trash (not sure this is possible).
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (SRAMP-535) Reset UUID of artifact when it is deleted
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/SRAMP-535?page=com.atlassian.jira.plugin.... ]
Work on SRAMP-535 started by Brett Meyer.
-----------------------------------------
> Reset UUID of artifact when it is deleted
> -----------------------------------------
>
> Key: SRAMP-535
> URL: https://issues.jboss.org/browse/SRAMP-535
> Project: S-RAMP
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.5.0.Beta3
> Reporter: Eric Wittmann
> Assignee: Brett Meyer
> Priority: Critical
> Fix For: 0.6.0
>
>
> Currently when an artifact is deleted we do not delete the JCR node. Instead we move it to another location in the JCR tree. This allows us to potentially add a new node with the same UUID (e.g. a user-specified one).
> However, the deleted artifact is still sitting over in the trash JCR folder with that original user-defined UUID. So now if you try to delete the new artifact you'll get this:
> {code}
> A node definition that allows same name siblings could not be found for the node "/s-ramp-trash/artifacts/03/3a/75/4766e0b8f42a6810ecd6dd73c441a3ed7e[2]" in workspace "default"
> {code}
> Possible solution is to generate a new UUID for the trashed artifact when it gets moved? Or else allow same-name-siblings in the JCR tree only for s-ramp/trash (not sure this is possible).
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (SRAMP-535) Reset UUID of artifact when it is deleted
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/SRAMP-535?page=com.atlassian.jira.plugin.... ]
Brett Meyer updated SRAMP-535:
------------------------------
Priority: Critical (was: Major)
> Reset UUID of artifact when it is deleted
> -----------------------------------------
>
> Key: SRAMP-535
> URL: https://issues.jboss.org/browse/SRAMP-535
> Project: S-RAMP
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.5.0.Beta3
> Reporter: Eric Wittmann
> Assignee: Brett Meyer
> Priority: Critical
> Fix For: 0.6.0
>
>
> Currently when an artifact is deleted we do not delete the JCR node. Instead we move it to another location in the JCR tree. This allows us to potentially add a new node with the same UUID (e.g. a user-specified one).
> However, the deleted artifact is still sitting over in the trash JCR folder with that original user-defined UUID. So now if you try to delete the new artifact you'll get this:
> {code}
> A node definition that allows same name siblings could not be found for the node "/s-ramp-trash/artifacts/03/3a/75/4766e0b8f42a6810ecd6dd73c441a3ed7e[2]" in workspace "default"
> {code}
> Possible solution is to generate a new UUID for the trashed artifact when it gets moved? Or else allow same-name-siblings in the JCR tree only for s-ramp/trash (not sure this is possible).
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (SRAMP-16) Eclipse IDE: S-RAMP tooling
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/SRAMP-16?page=com.atlassian.jira.plugin.s... ]
Brett Meyer updated SRAMP-16:
-----------------------------
Fix Version/s: (was: 0.6.0)
> Eclipse IDE: S-RAMP tooling
> ---------------------------
>
> Key: SRAMP-16
> URL: https://issues.jboss.org/browse/SRAMP-16
> Project: S-RAMP
> Issue Type: Task
> Components: IDE Integration
> Affects Versions: 0.6.0
> Reporter: Kurt Stam
> Assignee: Brett Meyer
>
> Introducing IDE-based tooling, interacting with the S-RAMP repo, brings up several interesting use cases. For instance, allowing an app developer to search for a WSDL in S-RAMP, then pull it down into his/her project (all from within the IDE) would be powerful.
> One idea would be to look into writing this as a JBoss Forge plugin. Not only would we gain Eclipse support, but also any other Forge-supported environment. The unknown is how to integrate that plugin with an Eclipse view UI, as opposed to simply relying on the Forge shell.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (SRAMP-16) Eclipse IDE: S-RAMP tooling
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/SRAMP-16?page=com.atlassian.jira.plugin.s... ]
Brett Meyer reassigned SRAMP-16:
--------------------------------
Assignee: Brett Meyer (was: Kurt Stam)
> Eclipse IDE: S-RAMP tooling
> ---------------------------
>
> Key: SRAMP-16
> URL: https://issues.jboss.org/browse/SRAMP-16
> Project: S-RAMP
> Issue Type: Task
> Components: IDE Integration
> Affects Versions: 0.6.0
> Reporter: Kurt Stam
> Assignee: Brett Meyer
>
> Introducing IDE-based tooling, interacting with the S-RAMP repo, brings up several interesting use cases. For instance, allowing an app developer to search for a WSDL in S-RAMP, then pull it down into his/her project (all from within the IDE) would be powerful.
> One idea would be to look into writing this as a JBoss Forge plugin. Not only would we gain Eclipse support, but also any other Forge-supported environment. The unknown is how to integrate that plugin with an Eclipse view UI, as opposed to simply relying on the Forge shell.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months