January 2015 - overlord-issues - Jboss List Archives

[JBoss JIRA] (ARTIF-645) Allow users to supply extensions through a new plugin architecture

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/ARTIF-645?page=com.atlassian.jira.plugin.... ] Gary Brown commented on ARTIF-645: ---------------------------------- Like the idea of a pluggable architecture - especially in respect of the UI. The current UI is very much a generic browser to navigate around a wide range of artifacts and view their metadata and relationships. However the information held within the repository could be idea for business specific views - so this pluggable approach could be one way in which organisations could define their build specific views, presenting the key information they are interested in, and allowing users to navigate through the relevant subsets of information they are interested in. For example, one usecase I heard related to the deployment lifecycle information being stored in SRAMP, was having service reports that showed how long it took to progress though the various stages of the lifecycle, and who (i.e. which teams) delayed the deployment. Although with custom views, it may also be good to look at this capability in the context of fine grained access control, to potential enable only some of these custom views to be offered/presented to specific users - e.g. a business user may not be presented with the generic browser and instead may only see a specific set of the custom views, to restrict (a) the information they see (presented at a suitable high level) and (b) the way in which they can navigate around the model. > Allow users to supply extensions through a new plugin architecture > ------------------------------------------------------------------ > > Key: ARTIF-645 > URL: https://issues.jboss.org/browse/ARTIF-645 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > The illustrious [~eric.wittmann] demoed his plugin architecture within APIMan, which allows users to contribute, among other things, UI components (!!!). A similar structure could be extremely valuable for Artificer. Things a plugin could contribute: > - extension contract impls (ArtifactBuilder, TypeDetector, etc.) > - JCR node types (assuming we're able to change the spec to allow /s-ramp/[custom model]/[custom type] > - UI elements (custom metadata displays, custom actions, etc.) > - endpoint bindings (again, /s-ramp/model/type) > Eric's demo: https://bluejeans.com/s/82tW/ -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ARTIF-227) Allow derivers to define and use custom node types

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/ARTIF-227?page=com.atlassian.jira.plugin.... ] Brett Meyer reassigned ARTIF-227: --------------------------------- Assignee: Brett Meyer (was: Kurt Stam) > Allow derivers to define and use custom node types > -------------------------------------------------- > > Key: ARTIF-227 > URL: https://issues.jboss.org/browse/ARTIF-227 > Project: Artificer > Issue Type: Sub-task > Reporter: Randall Hauch > Assignee: Brett Meyer > > Presently, any content produced by a deriver is stored in the JCR repository with S-RAMP-defined node types, and it is not possible for a deriver to use custom or domain-specific node types or mixins. > This enhancement would allow derivers to define such domain-specific node types and/or mixins, and to produce content that uses these node types. This would allow directly querying the underlying JCR repository using JCR-SQL (which is based very much on using specific node types and mixins). > Granted, it may be very difficult to abstract the JCR-ness of the custom node types, especially during content creation. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ARTIF-227) Allow derivers to define and use custom node types

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/ARTIF-227?page=com.atlassian.jira.plugin.... ] Brett Meyer updated ARTIF-227: ------------------------------ Parent: ARTIF-645 Issue Type: Sub-task (was: Enhancement) > Allow derivers to define and use custom node types > -------------------------------------------------- > > Key: ARTIF-227 > URL: https://issues.jboss.org/browse/ARTIF-227 > Project: Artificer > Issue Type: Sub-task > Reporter: Randall Hauch > Assignee: Kurt Stam > > Presently, any content produced by a deriver is stored in the JCR repository with S-RAMP-defined node types, and it is not possible for a deriver to use custom or domain-specific node types or mixins. > This enhancement would allow derivers to define such domain-specific node types and/or mixins, and to produce content that uses these node types. This would allow directly querying the underlying JCR repository using JCR-SQL (which is based very much on using specific node types and mixins). > Granted, it may be very difficult to abstract the JCR-ness of the custom node types, especially during content creation. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ARTIF-645) Allow users to supply extensions through a new plugin architecture

by Brett Meyer (JIRA)

Brett Meyer created ARTIF-645: --------------------------------- Summary: Allow users to supply extensions through a new plugin architecture Key: ARTIF-645 URL: https://issues.jboss.org/browse/ARTIF-645 Project: Artificer Issue Type: Feature Request Reporter: Brett Meyer Assignee: Brett Meyer The illustrious [~eric.wittmann] demoed his plugin architecture within APIMan, which allows users to contribute, among other things, UI components (!!!). A similar structure could be extremely valuable for Artificer. Things a plugin could contribute: - extension contract impls (ArtifactBuilder, TypeDetector, etc.) - JCR node types (assuming we're able to change the spec to allow /s-ramp/[custom model]/[custom type] - UI elements (custom metadata displays, custom actions, etc.) - endpoint bindings (again, /s-ramp/model/type) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ARTIF-645) Allow users to supply extensions through a new plugin architecture

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/ARTIF-645?page=com.atlassian.jira.plugin.... ] Brett Meyer updated ARTIF-645: ------------------------------ Description: The illustrious [~eric.wittmann] demoed his plugin architecture within APIMan, which allows users to contribute, among other things, UI components (!!!). A similar structure could be extremely valuable for Artificer. Things a plugin could contribute: - extension contract impls (ArtifactBuilder, TypeDetector, etc.) - JCR node types (assuming we're able to change the spec to allow /s-ramp/[custom model]/[custom type] - UI elements (custom metadata displays, custom actions, etc.) - endpoint bindings (again, /s-ramp/model/type) Eric's demo: https://bluejeans.com/s/82tW/ was: The illustrious [~eric.wittmann] demoed his plugin architecture within APIMan, which allows users to contribute, among other things, UI components (!!!). A similar structure could be extremely valuable for Artificer. Things a plugin could contribute: - extension contract impls (ArtifactBuilder, TypeDetector, etc.) - JCR node types (assuming we're able to change the spec to allow /s-ramp/[custom model]/[custom type] - UI elements (custom metadata displays, custom actions, etc.) - endpoint bindings (again, /s-ramp/model/type) > Allow users to supply extensions through a new plugin architecture > ------------------------------------------------------------------ > > Key: ARTIF-645 > URL: https://issues.jboss.org/browse/ARTIF-645 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > The illustrious [~eric.wittmann] demoed his plugin architecture within APIMan, which allows users to contribute, among other things, UI components (!!!). A similar structure could be extremely valuable for Artificer. Things a plugin could contribute: > - extension contract impls (ArtifactBuilder, TypeDetector, etc.) > - JCR node types (assuming we're able to change the spec to allow /s-ramp/[custom model]/[custom type] > - UI elements (custom metadata displays, custom actions, etc.) > - endpoint bindings (again, /s-ramp/model/type) > Eric's demo: https://bluejeans.com/s/82tW/ -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ARTIF-463) OpenShift cartridge

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/ARTIF-463?page=com.atlassian.jira.plugin.... ] Brett Meyer updated ARTIF-463: ------------------------------ Description: https://developers.openshift.com/en/get-involved-extend-openshift.html https://blog.openshift.com/new-openshift-cartridge-format-part-1/ https://blog.openshift.com/new-openshift-cartridge-format-part-2/ http://www.openshift.org/documentation/oo_cartridge_developers_guide.html > OpenShift cartridge > ------------------- > > Key: ARTIF-463 > URL: https://issues.jboss.org/browse/ARTIF-463 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > https://developers.openshift.com/en/get-involved-extend-openshift.html > https://blog.openshift.com/new-openshift-cartridge-format-part-1/ > https://blog.openshift.com/new-openshift-cartridge-format-part-2/ > http://www.openshift.org/documentation/oo_cartridge_developers_guide.html -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ARTIF-463) OpenShift cartridge

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/ARTIF-463?page=com.atlassian.jira.plugin.... ] Brett Meyer commented on ARTIF-463: ----------------------------------- https://github.com/keycloak/openshift-keycloak-cartridge Presumably, that could be a reference > OpenShift cartridge > ------------------- > > Key: ARTIF-463 > URL: https://issues.jboss.org/browse/ARTIF-463 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ARTIF-506) Maven repository facade. Add extended type

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/ARTIF-506?page=com.atlassian.jira.plugin.... ] Brett Meyer reassigned ARTIF-506: --------------------------------- Assignee: Brett Meyer (was: David virgil naranjo) > Maven repository facade. Add extended type > ------------------------------------------ > > Key: ARTIF-506 > URL: https://issues.jboss.org/browse/ARTIF-506 > Project: Artificer > Issue Type: Sub-task > Reporter: David virgil naranjo > Assignee: Brett Meyer > Fix For: 1.0.0.Alpha1 > > > It is necessary to add the possibility of setting a different s-ramp type. > By default right now the s-ramp type is Java Archive. For uploading switchyard applications it is necessary to add a mechanism to set the extended type. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ARTIF-509) Unify s-ramp maven code

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/ARTIF-509?page=com.atlassian.jira.plugin.... ] Brett Meyer updated ARTIF-509: ------------------------------ Parent: ARTIF-581 Issue Type: Sub-task (was: Enhancement) > Unify s-ramp maven code > ----------------------- > > Key: ARTIF-509 > URL: https://issues.jboss.org/browse/ARTIF-509 > Project: Artificer > Issue Type: Sub-task > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: 1.0.0.Alpha1 > > > Both the S-ramp Wagon, Maven Repository Servlet Facade and Deploy Command (shell) uses the s-ramp client to store maven artifacts in the system. > They make more or less the same, use the same methods to find existing artifacts and to save the artifact. Also all of them have methods that parse the input string that contains the gav, and store this info in different mojos. > This means there is lot of common duplicate code. The idea is to create in s-ramp common project a new package maven and there include only one MavenMetadata class, and include one Factory class that transform from Metadata to BaseArtifactType. > Also it is required a MavenUtil class where will be included the common operations. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

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

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/ARTIF-583?page=com.atlassian.jira.plugin.... ] Brett Meyer resolved ARTIF-583. ------------------------------- Resolution: Done > Consider completely removing the web-view support in the Maven Facade > --------------------------------------------------------------------- > > Key: ARTIF-583 > URL: https://issues.jboss.org/browse/ARTIF-583 > Project: Artificer > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Alpha1 > > > 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.11#6341)

9 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

overlord-issues January 2015