May 2013 - overlord-issues - Jboss List Archives

[JBoss JIRA] (SRAMP-160) Change artifact's 'delete' action to be a logical delete

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-160?page=com.atlassian.jira.plugin.... ] Eric Wittmann updated SRAMP-160: -------------------------------- Priority: Major (was: Minor) > Change artifact's 'delete' action to be a logical delete > -------------------------------------------------------- > > Key: SRAMP-160 > URL: https://issues.jboss.org/browse/SRAMP-160 > Project: S-RAMP > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Core > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.3.0 JBPM6 Integration > > > The reason for doing this is that we should not allow duplicate UUIDs, even for deleted artifacts. Currently a delete will remove the artifact from the repository. Instead, we should either move the artifact to some alternate collection or simply tag it as deleted (and then augment all incoming queries with a predicate that will exclude deleted artifacts). > Do we need a way to actually for-real delete an artifact? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-175) Update S-RAMP Installer with additional platform options

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-175?page=com.atlassian.jira.plugin.... ] Eric Wittmann updated SRAMP-175: -------------------------------- Fix Version/s: 0.4.0 API Management (was: 0.2.0 Security) > Update S-RAMP Installer with additional platform options > -------------------------------------------------------- > > Key: SRAMP-175 > URL: https://issues.jboss.org/browse/SRAMP-175 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.4.0 API Management > > > The s-ramp distro installer needs to offer a path through the installer that will install *only* the S-RAMP repository (not a full jBPM5 with governance installed). > Also it should offer the option to install all components *except* jBPM. Hopefully the user can be prompted for input. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-182) Make artifact type detection less generic (atom layer)

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-182?page=com.atlassian.jira.plugin.... ] Eric Wittmann updated SRAMP-182: -------------------------------- Priority: Minor (was: Major) > Make artifact type detection less generic (atom layer) > ------------------------------------------------------ > > Key: SRAMP-182 > URL: https://issues.jboss.org/browse/SRAMP-182 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Atom Binding, Core > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Priority: Minor > Fix For: 0.3.0 JBPM6 Integration > > > Currently the artifact type detection methods are very generic and do not consider the context. There are two basic scenarios where an artifact type must be detected from an Atom Entry: > 1) atom summary entries > 2) full atom entries > In the former case we need to figure out the type based on meta-data in the Entry, such as the URL, or from the 'x-s-ramp:2010:type' Category (for example) > In the latter case, we should look at the wrapped artifact itself (there will be an <artifact> custom element in the Atom Entry with a single child - that single child is the full artifact meta-data, and the element name will indicate the type). > Currently we just try both under all circumstances. I want to change from "getArtifactTypeFromEntry" to two methods: > getArtifactTypeFromSummaryEntry > getArtifactTypeFromFullEntry > Callers must know what they have (summary or full). This should be known in all cases. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-182) Make artifact type detection less generic (atom layer)

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-182?page=com.atlassian.jira.plugin.... ] Eric Wittmann updated SRAMP-182: -------------------------------- Fix Version/s: 0.3.0 JBPM6 Integration (was: 0.2.0 Security) > Make artifact type detection less generic (atom layer) > ------------------------------------------------------ > > Key: SRAMP-182 > URL: https://issues.jboss.org/browse/SRAMP-182 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Atom Binding, Core > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.3.0 JBPM6 Integration > > > Currently the artifact type detection methods are very generic and do not consider the context. There are two basic scenarios where an artifact type must be detected from an Atom Entry: > 1) atom summary entries > 2) full atom entries > In the former case we need to figure out the type based on meta-data in the Entry, such as the URL, or from the 'x-s-ramp:2010:type' Category (for example) > In the latter case, we should look at the wrapped artifact itself (there will be an <artifact> custom element in the Atom Entry with a single child - that single child is the full artifact meta-data, and the element name will indicate the type). > Currently we just try both under all circumstances. I want to change from "getArtifactTypeFromEntry" to two methods: > getArtifactTypeFromSummaryEntry > getArtifactTypeFromFullEntry > Callers must know what they have (summary or full). This should be known in all cases. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-189) Upload Switchyard SCA diagram automatically from maven

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-189?page=com.atlassian.jira.plugin.... ] Eric Wittmann updated SRAMP-189: -------------------------------- Fix Version/s: 0.3.0 JBPM6 Integration (was: 0.2.0 Security) > Upload Switchyard SCA diagram automatically from maven > ------------------------------------------------------ > > Key: SRAMP-189 > URL: https://issues.jboss.org/browse/SRAMP-189 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.3.0 JBPM6 Integration > > > Switchyard is planning on generating an SCA diagram for applications during build. When uploading the application to s-ramp this diagram should be included and appropriately linked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-161) S-RAMP Client: obey endpoints found in /servicedocument

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-161?page=com.atlassian.jira.plugin.... ] Eric Wittmann updated SRAMP-161: -------------------------------- Fix Version/s: 0.3.0 JBPM6 Integration (was: 0.2.0 Security) > S-RAMP Client: obey endpoints found in /servicedocument > ------------------------------------------------------- > > Key: SRAMP-161 > URL: https://issues.jboss.org/browse/SRAMP-161 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: S-RAMP API > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.3.0 JBPM6 Integration > > > Currently we use the non-normative URL formats suggested in the S-RAMP Atom Binding document as presumptive endpoints for the various artifact types. Instead, the Atom API Java client should obey the endpoints it finds in the /servicedocument. This means it will *always* query that service document. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-157) Implement Auditing in the S-RAMP repository

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-157?page=com.atlassian.jira.plugin.... ] Eric Wittmann updated SRAMP-157: -------------------------------- Fix Version/s: 0.3.0 JBPM6 Integration (was: 0.2.0 Security) > Implement Auditing in the S-RAMP repository > ------------------------------------------- > > Key: SRAMP-157 > URL: https://issues.jboss.org/browse/SRAMP-157 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Core > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.3.0 JBPM6 Integration > > > We want to make sure that we have full auditing support so that we can track all changes made to artifacts. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-90) Support for Relationships

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-90?page=com.atlassian.jira.plugin.s... ] Eric Wittmann updated SRAMP-90: ------------------------------- Fix Version/s: 0.4.0 API Management (was: 0.2.0 Security) > Support for Relationships > ------------------------- > > Key: SRAMP-90 > URL: https://issues.jboss.org/browse/SRAMP-90 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Core > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.4.0 API Management > > > Create support for relationships in s-ramp. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-168) Create a TCK test suite

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-168?page=com.atlassian.jira.plugin.... ] Eric Wittmann updated SRAMP-168: -------------------------------- Fix Version/s: 0.5.0 - Future > Create a TCK test suite > ----------------------- > > Key: SRAMP-168 > URL: https://issues.jboss.org/browse/SRAMP-168 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Distro > Reporter: Kurt Stam > Assignee: Kurt Stam > Fix For: 0.5.0 - Future > > > Adding a Technical Compatibility Kit. > - add examples from spec docs > - add tests to validate the implementation adheres to the spec -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-165) Implement negation (not() function) for S-RAMP queries

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-165?page=com.atlassian.jira.plugin.... ] Eric Wittmann updated SRAMP-165: -------------------------------- Fix Version/s: 0.3.0 JBPM6 Integration (was: 0.2.0 Security) > Implement negation (not() function) for S-RAMP queries > ------------------------------------------------------ > > Key: SRAMP-165 > URL: https://issues.jboss.org/browse/SRAMP-165 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Core > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.3.0 JBPM6 Integration > > > We added support for negation in s-ramp queries to the spec recently. Need to implement that function. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

overlord-issues May 2013