October 2014 - overlord-issues - Jboss List Archives

[JBoss JIRA] (SRAMP-16) Eclipse IDE: S-RAMP tooling

by Jan Bouška (JIRA)

[ https://issues.jboss.org/browse/SRAMP-16?page=com.atlassian.jira.plugin.s... ] Jan Bouška commented on SRAMP-16: --------------------------------- Hello [~brmeyer]. I made changes according to your advice. Could you have a look on the new UI Mockup? Thank you. > 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.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-466) Better utilize batch mode for relationship resolution

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/SRAMP-466?page=com.atlassian.jira.plugin.... ] Work on SRAMP-466 started by Brett Meyer. ----------------------------------------- > Better utilize batch mode for relationship resolution > ----------------------------------------------------- > > Key: SRAMP-466 > URL: https://issues.jboss.org/browse/SRAMP-466 > Project: S-RAMP > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Better utilize "batch mode" during relationship resolution. Links within the batch would take priority over existing artifacts in the repo. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-609) Create a new ArtifactBuilder concept

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/SRAMP-609?page=com.atlassian.jira.plugin.... ] Work on SRAMP-609 started by Brett Meyer. ----------------------------------------- > Create a new ArtifactBuilder concept > ------------------------------------ > > Key: SRAMP-609 > URL: https://issues.jboss.org/browse/SRAMP-609 > Project: S-RAMP > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > > The Deriver and Linker concepts are necessary, but are somewhat inflexible and unextenadble. For SRAMP-547, SRAMP-465, SRAMP-466, etc., a better solution is needed. > Replace with an ArtifactBuilder that is in charge of building up the primary artifact and its set of derived artifacts. The set of available builders will be chained together, allowing devs to extend the build-in capabilities. > When building, if a relationship target is not available in the current set of primary/derived artifacts, a new mediation layer, RelationshipSource, will be given enough information to define the target value in a later step. This information could include a QName, etc. > After the artifacts are persisted in JCR, the builders are re-called to process any RelationshipSources. Technically, this could be combined with the above into one single step. However, due to the chaining, we want to provide visibility into the entire set of artifacts provided by the whole chain. The alternative, passing the list of artifacts through the chain, is brittle and would require knowing required ordering ahead of time. This idea will be vital for SRAMP-466 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-608) SimpleTypeDeclaration/ComplexTypeDeclaration queries incorrect

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/SRAMP-608?page=com.atlassian.jira.plugin.... ] Brett Meyer commented on SRAMP-608: ----------------------------------- Also see JCRBatchPersistenceTest#testWsdlBatch > SimpleTypeDeclaration/ComplexTypeDeclaration queries incorrect > -------------------------------------------------------------- > > Key: SRAMP-608 > URL: https://issues.jboss.org/browse/SRAMP-608 > Project: S-RAMP > Issue Type: Bug > Reporter: Brett Meyer > Assignee: Brett Meyer > Priority: Critical > > Complex returns both Complex and Simple. Simple does not work, period. See commented-out failure at the bottom of JCRWsdlDocumentPersistenceTest -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-609) Create a new ArtifactBuilder concept

by Brett Meyer (JIRA)

Brett Meyer created SRAMP-609: --------------------------------- Summary: Create a new ArtifactBuilder concept Key: SRAMP-609 URL: https://issues.jboss.org/browse/SRAMP-609 Project: S-RAMP Issue Type: Enhancement Reporter: Brett Meyer Assignee: Brett Meyer The Deriver and Linker concepts are necessary, but are somewhat inflexible and unextenadble. For SRAMP-547, SRAMP-465, SRAMP-466, etc., a better solution is needed. Replace with an ArtifactBuilder that is in charge of building up the primary artifact and its set of derived artifacts. The set of available builders will be chained together, allowing devs to extend the build-in capabilities. When building, if a relationship target is not available in the current set of primary/derived artifacts, a new mediation layer, RelationshipSource, will be given enough information to define the target value in a later step. This information could include a QName, etc. After the artifacts are persisted in JCR, the builders are re-called to process any RelationshipSources. Technically, this could be combined with the above into one single step. However, due to the chaining, we want to provide visibility into the entire set of artifacts provided by the whole chain. The alternative, passing the list of artifacts through the chain, is brittle and would require knowing required ordering ahead of time. This idea will be vital for SRAMP-466 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-608) SimpleTypeDeclaration/ComplexTypeDeclaration queries incorrect

by Brett Meyer (JIRA)

Brett Meyer created SRAMP-608: --------------------------------- Summary: SimpleTypeDeclaration/ComplexTypeDeclaration queries incorrect Key: SRAMP-608 URL: https://issues.jboss.org/browse/SRAMP-608 Project: S-RAMP Issue Type: Bug Reporter: Brett Meyer Assignee: Brett Meyer Priority: Critical Complex returns both Complex and Simple. Simple does not work, period. See commented-out failure at the bottom of JCRWsdlDocumentPersistenceTest -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-607) Hardcoded connection factory jndi name in JMSEventProducer

by Stefan Bunciak (JIRA)

Stefan Bunciak created SRAMP-607: ------------------------------------ Summary: Hardcoded connection factory jndi name in JMSEventProducer Key: SRAMP-607 URL: https://issues.jboss.org/browse/SRAMP-607 Project: S-RAMP Issue Type: Bug Components: Core Affects Versions: 0.6.0.Final Reporter: Stefan Bunciak Assignee: Brett Meyer Fix For: 0.7.0.Final -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[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: ---------------------------------- (CC [~eric.wittmann] & [~objectiser]) [~bouskaj], hello! Glad to have your help! The approach looks like a great start! You've encompassed the 2 main use cases: uploading an artifact to S-RAMP, and downloading artifacts from S-RAMP and incorporating them into your project. Here's a few comments: - When you upload an artifact, it would be useful to use a popup screen where the user could provide artifact metadata (name, artifact type, properties, etc.). - Your S-RAMP repo screen currently has 1 "Query" box. Definitely keep that -- that will allow developers to use the S-RAMP query language. However, we might also need a sidebar with an advanced search form, really similar to what the web UI has. That way, users can still filter the artifacts, even if they don't know the full query language. Other than that, you're on the right track! Thanks again for the help! > 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 > > > 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)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-583) Consider completely removing the web-view support in the Maven Facade

by David virgil naranjo (JIRA)

[ https://issues.jboss.org/browse/SRAMP-583?page=com.atlassian.jira.plugin.... ] David virgil naranjo commented on SRAMP-583: -------------------------------------------- I think is good to have a maven tree view depending on trhe complex situations we can reach to. I thought the current implementation was complete and it displayed the artifacts included in a group and listed correctly the groups. What are the key areas that are being missed? And what are the complex situations maybe we have to deal in the future? Just for my understanding. I imagine the artifact grouping could be one situation. Just as the user view, I think having a view like this is useful. As this url will be added as maven repository, I like the idea of having access to the artifacts. What would be good also, is to have a kind of tree organized view in s-ramp. > Consider completely removing the web-view support in the Maven Facade > --------------------------------------------------------------------- > > Key: SRAMP-583 > URL: https://issues.jboss.org/browse/SRAMP-583 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Brett Meyer > > Although I understand the initial desire to have a web-view interface for the Maven Facade (similar to Nexus' ability to navigate the repo w/ a web browser), I think I'd recommend removing the capability entirely. The current implementation isn't complete and misses a few key areas. Overcoming every complex situation will be challenging and not worth the effort. > I would much rather require the use of the real S-RAMP UI. If there are specific use cases that the Facade view aimed for, implement them as improvements to the UI. > So, I'm advocating that we strip out the Facade view, JSPs, etc. entirely. Thoughts? -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-604) Dependency graph not displayed correctly

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-604?page=com.atlassian.jira.plugin.... ] Gary Brown resolved RTGOV-604. ------------------------------ Resolution: Done > Dependency graph not displayed correctly > ---------------------------------------- > > Key: RTGOV-604 > URL: https://issues.jboss.org/browse/RTGOV-604 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > The size of the dependency graph is cropped so diagrams are not being displayed correctly. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

overlord-issues October 2014