[JBoss JIRA] (SRAMP-622) Relationship.getOtherAttributes() should be persisted and queryable
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/SRAMP-622?page=com.atlassian.jira.plugin.... ]
Brett Meyer commented on SRAMP-622:
-----------------------------------
Alright, here's where this landed. Relationship#getOtherAttributes is now persisted. The following queries are available:
/s-ramp/xsd/XsdDocument[someRelationship[s-ramp:getRelationshipAttribute(., 'FooKey') = 'FooValue']]
/s-ramp/xsd/XsdDocument[someRelationship[s-ramp:getRelationshipAttribute(., 'FooKey')]]
/s-ramp/xsd/XsdDocument[someRelationship[s-ramp:getRelationshipAttribute(., 'InvalidKey')]]
The last 2 essentially create a "hasRelationshipAttribute".
CAVEAT!
Technically, something like the following should be supported:
/s-ramp/xsd/XsdDocument[someRelationship[s-ramp:getRelationshipAttribute(., 'FooKey') = 'FooValue' and @FooProperty = 'FooValue']]
That would return an XSD with a relationship containing the FooKey attribute *and* the targeted artifact containing the @FooProperty. Obviously, those would affect 2 different portions of the eventual query. However, I'm learning how brittle and fragile our current query builder really is. Under SRAMP-627, I'll be working on using an actual Builder pattern (and most likely AST objects, provided by ModeShape) that would allow that type of query.
Until then, getRelationshipAttribute must be used *by itself* in a relationship predicate. Pairing it with others simply will not work. If others are needed, clients will need to omit getRelationshipAttribute, then filter using the attribute *in memory*. Hopefully that's not too limiting in the short-term.
> Relationship.getOtherAttributes() should be persisted and queryable
> -------------------------------------------------------------------
>
> Key: SRAMP-622
> URL: https://issues.jboss.org/browse/SRAMP-622
> Project: S-RAMP
> Issue Type: Bug
> Components: Persistence
> Affects Versions: 0.7.0.Final
> Reporter: Lukas Krejci
> Assignee: Brett Meyer
> Attachments: reproducer.zip
>
>
> The API allows for the relationships to have arbitrary "other" attributes on them.
> These attributes don't seem to be persisted.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years
[JBoss JIRA] (SRAMP-622) Relationship.getOtherAttributes() should be persisted and queryable
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/SRAMP-622?page=com.atlassian.jira.plugin.... ]
Brett Meyer edited comment on SRAMP-622 at 12/3/14 12:39 PM:
-------------------------------------------------------------
These also need to be queryable. Suggestion: /s-ramp/wsdl/WsdlDocument[someRelationship[s-ramp:getRelationshipAttribute(., 'someAttribute') = 'true']]
was (Author: brmeyer):
These also need to be queryable. Suggestion: /s-ramp/wsdl/WsdlDocument[includedXsds[s-ramp:getRelationshipAttribute(., 'someAttribute') = 'true]]
> Relationship.getOtherAttributes() should be persisted and queryable
> -------------------------------------------------------------------
>
> Key: SRAMP-622
> URL: https://issues.jboss.org/browse/SRAMP-622
> Project: S-RAMP
> Issue Type: Bug
> Components: Persistence
> Affects Versions: 0.7.0.Final
> Reporter: Lukas Krejci
> Assignee: Brett Meyer
> Attachments: reproducer.zip
>
>
> The API allows for the relationships to have arbitrary "other" attributes on them.
> These attributes don't seem to be persisted.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years
[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 commented on SRAMP-16:
----------------------------------
Sounds good. Can you guys bump the version up to 0.7.0-SNAPSHOT and re-test? I hit at least one error -- attempting to download a WSDL and import it into a project resulted in an exception on the server. When you're satistifed, I'll give it another in-depth go. Thanks!
> 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.Final
> Reporter: Kurt Stam
> Assignee: Brett Meyer
> Attachments: UIMockup.gliffy, UImockup.gliffy
>
>
> 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.8#6338)
10 years
[JBoss JIRA] (SRAMP-16) Eclipse IDE: S-RAMP tooling
by Stefan Bunciak (JIRA)
[ https://issues.jboss.org/browse/SRAMP-16?page=com.atlassian.jira.plugin.s... ]
Stefan Bunciak commented on SRAMP-16:
-------------------------------------
SRAMP-626 is going to be a big deal of help. Thanks!
{quote}
Can you bump sramp.version up to 0.6.0.Final or, even better, 0.7.0-SNAPSHOT?
{quote}
Sure.
{quote}
Are you guys interested in any feedback, yet? Really, it's just a few nitpicky improvements for the look and feel. Functionality wise, this is great.
{quote}
Of course we are ;-)
{quote}
Once you're satistifed with where it's at, I'd say let's go ahead and integrate it as a module in the actual project, but within a branch until it's "finished".
{quote}
I suppose we could consider it finished later this month. It depends on how much feedback will you give us, but basically from functionality perspective I think we are done for now. So, once we incorporate your feedback we can send a pull request.
> 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.Final
> Reporter: Kurt Stam
> Assignee: Brett Meyer
> Attachments: UIMockup.gliffy, UImockup.gliffy
>
>
> 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.8#6338)
10 years
[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 commented on SRAMP-16:
----------------------------------
I did finally have a chance to build and install the plugin. Very, very impressive for a proof of concept! Once polished, this is going to be a huge win for the project and a really useful tool. Good work!
Are you guys interested in any feedback, yet? Really, it's just a few nitpicky improvements for the look and feel. Functionality wise, this is great.
Once you're satistifed with where it's at, I'd say let's go ahead and integrate it as a module in the actual project, but within a branch until it's "finished".
> 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.Final
> Reporter: Kurt Stam
> Assignee: Brett Meyer
> Attachments: UIMockup.gliffy, UImockup.gliffy
>
>
> 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.8#6338)
10 years
[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 commented on SRAMP-16:
----------------------------------
Can you bump sramp.version up to 0.6.0.Final or, even better, 0.7.0-SNAPSHOT?
> 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.Final
> Reporter: Kurt Stam
> Assignee: Brett Meyer
> Attachments: UIMockup.gliffy, UImockup.gliffy
>
>
> 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.8#6338)
10 years
[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 commented on SRAMP-16:
----------------------------------
Apologies for the delayed response!
{quote}
My suggestion is to create a s-ramp-client plugin that could be installed into the target platform/eclipse and S-RAMP IDE plugin could just reference it in its MANIFEST as required bundle.
{quote}
I guess I'm not quite following as to why that would be an improvement. Doesn't that simply introduce another installation step and maintain the same overall download size (between the 2 plugins)?
That being said, I'm sure I could trim down the size of s-ramp-client. It currently pulls in s-ramp-common and s-ramp-atom in their entirety -- both have fairly large transitive trees. I'll take a look under SRAMP-626.
> 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.Final
> Reporter: Kurt Stam
> Assignee: Brett Meyer
> Attachments: UIMockup.gliffy, UImockup.gliffy
>
>
> 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.8#6338)
10 years