[
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)