[JBoss JIRA] (SRAMP-534) Content assist in S-RAMP shell not working well for maven command
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/SRAMP-534?page=com.atlassian.jira.plugin.... ]
Brett Meyer commented on SRAMP-534:
-----------------------------------
Hey [~stalep], it appears that if command namespace results in a CompleteOperation with > 1 completionCandidates, tab completion works great. If there's only 1 command in the namespace, it's getting chopped off. Examples:
audit:[TAB] -> audit:ditTrail (should be audit:showAuditTrail)
jvm:[TAB] -> jvm:us (should be jvm:status)
…
[View More]maven:[TAB] -> maven: (should be maven:deploy)
It looks like it's chopping off namespaces.length()+1 (includes the colon). Are we expected to manually call CompleteOperation#setOffset? When Console#completeOperation hands us the CompleteOperation, #cursor == 4 and #offset == 0 (using jvm: as an example). If I include the following, it works as expected:
{code}
if (completeOperation.getCompletionCandidates().size() == 1) {
completeOperation.setOffset(completeOperation.getCursor());
}
{code}
> Content assist in S-RAMP shell not working well for maven command
> -----------------------------------------------------------------
>
> Key: SRAMP-534
> URL: https://issues.jboss.org/browse/SRAMP-534
> Project: S-RAMP
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Shell
> Affects Versions: 0.5.0.Beta3
> Reporter: Stefan Bunciak
> Assignee: Brett Meyer
>
> Content assist/command completion in S-RAMP shell did not provide me with possible commands for 'maven' namespace.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
[View Less]
10 years, 8 months
[JBoss JIRA] (SRAMP-535) Reset UUID of artifact when it is deleted
by Eric Wittmann (JIRA)
Eric Wittmann created SRAMP-535:
-----------------------------------
Summary: 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
Security Level: Public (Everyone can see)
Components: Core
Affects Versions: 0.5.0.Beta3
Reporter: Eric Wittmann
Assignee: Brett Meyer
Fix For: 0.5.0.Beta4
…
[View More]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.2.6#6264)
[View Less]
10 years, 8 months