September 2014 - overlord-issues - Jboss List Archives

[JBoss JIRA] (SRAMP-582) Create Maven Facade unit/integration test

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/SRAMP-582?page=com.atlassian.jira.plugin.... ] Brett Meyer updated SRAMP-582: ------------------------------ Description: This should be the priority and done before any other sub-task. Create extensive unit/integration tests to provide adequate coverage of all Maven Facade functionality. Due to the Facade's potential complexity, it should be developed with a test-first approach. See SrampWagonTest for some inspiration. Some of it may be directly applicable. was:This should be the priority and done before any other sub-task. Create extensive unit/integration tests to provide adequate coverage of all Maven Facade functionality. Due to the Facade's potential complexity, it should be developed with a test-first approach. > Create Maven Facade unit/integration test > ----------------------------------------- > > Key: SRAMP-582 > URL: https://issues.jboss.org/browse/SRAMP-582 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Brett Meyer > Priority: Critical > > This should be the priority and done before any other sub-task. Create extensive unit/integration tests to provide adequate coverage of all Maven Facade functionality. Due to the Facade's potential complexity, it should be developed with a test-first approach. > See SrampWagonTest for some inspiration. Some of it may be directly applicable. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-584) Test and document Nexus Proxy support

by Brett Meyer (JIRA)

Brett Meyer created SRAMP-584: --------------------------------- Summary: Test and document Nexus Proxy support Key: SRAMP-584 URL: https://issues.jboss.org/browse/SRAMP-584 Project: S-RAMP Issue Type: Sub-task Reporter: Brett Meyer Once the Facade is "finished", verify that it can be used as a Nexus Proxy. Then, document this use case: "gain S-RAMP without losing your existing enterprise repo!" -- 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 Brett Meyer (JIRA)

Brett Meyer created SRAMP-583: --------------------------------- Summary: 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] (SRAMP-581) Finish the Maven Facade

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/SRAMP-581?page=com.atlassian.jira.plugin.... ] Brett Meyer updated SRAMP-581: ------------------------------ Description: The vision for the Maven Facade is the eventual replacement of the Maven Wagon, in addition to several interesting use cases. - deployment repository - dependency repository - Nexus Proxy support > Finish the Maven Facade > ----------------------- > > Key: SRAMP-581 > URL: https://issues.jboss.org/browse/SRAMP-581 > Project: S-RAMP > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > The vision for the Maven Facade is the eventual replacement of the Maven Wagon, in addition to several interesting use cases. > - deployment repository > - dependency repository > - Nexus Proxy support -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-582) Create Maven Facade unit/integration test

by Brett Meyer (JIRA)

Brett Meyer created SRAMP-582: --------------------------------- Summary: Create Maven Facade unit/integration test Key: SRAMP-582 URL: https://issues.jboss.org/browse/SRAMP-582 Project: S-RAMP Issue Type: Sub-task Reporter: Brett Meyer Priority: Critical This should be the priority and done before any other sub-task. Create extensive unit/integration tests to provide adequate coverage of all Maven Facade functionality. Due to the Facade's potential complexity, it should be developed with a test-first approach. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

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

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/SRAMP-506?page=com.atlassian.jira.plugin.... ] Brett Meyer updated SRAMP-506: ------------------------------ Parent: SRAMP-581 Issue Type: Sub-task (was: Feature Request) > Maven repository facade. Add extended type > ------------------------------------------ > > Key: SRAMP-506 > URL: https://issues.jboss.org/browse/SRAMP-506 > Project: S-RAMP > Issue Type: Sub-task > Reporter: David virgil naranjo > Assignee: David virgil naranjo > > 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.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-581) Finish the Maven Facade

by Brett Meyer (JIRA)

Brett Meyer created SRAMP-581: --------------------------------- Summary: Finish the Maven Facade Key: SRAMP-581 URL: https://issues.jboss.org/browse/SRAMP-581 Project: S-RAMP Issue Type: Feature Request Reporter: Brett Meyer Assignee: Brett Meyer -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-580) Server-side autodetection of artifact types

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/SRAMP-580?page=com.atlassian.jira.plugin.... ] Brett Meyer updated SRAMP-580: ------------------------------ Description: Currently, artifact type autodetection exists in multiple forms, nearly all of them client-side. The Maven Wagon inspects the deployment URL and makes assumptions. The UI checks file extensions. Instead, move a more complete set of artifact-inspection logic server-side. Some semblance of this already exists, to a certain degree. For example, ZipToSrampArchiveProvider#accept(ArtifactType) already exists, but is currently used only to determine which module should expand the artifact. But, the concept could be used to define the artifact type based on the new artifact. It would require a hierarchy of sorts where the most "specialized" integrations (Switchyard, RTGov, DTGov, etc.) are considered first. If none of those "accept" the artifact, the next tier (more generic types) are considered. The logic could be a mix of filename regex, archive inspection (ex: look for switchyard.xml), etc. This should completely replace all other types of client-side logic. was: Currently, artifact type autodetection exists in multiple forms, nearly all of them client-side. The Maven Wagon inspects the deployment URL and makes assumptions. The UI checks file extensions. Instead, move a more complete set of artifact-inspection logic server-side. Some semblance of this already exists, to a certain degree. For example, ZipToSrampArchiveProvider#accept(ArtifactType) already exists, but is currently used only to determine which module should expand the artifact. But, the concept could be used to define the artifact type based on the new artifact. It would require a hierarchy of sorts where the most "specialized" integrations (Switchyard, RTGov, DTGov, etc.) are considered first. If none of those "accept" the artifact, the next tier (more generic types) are considered. The logic could be a mix of filename regex, archive inspection (ex: look for switchyard.xml), etc. > Server-side autodetection of artifact types > ------------------------------------------- > > Key: SRAMP-580 > URL: https://issues.jboss.org/browse/SRAMP-580 > Project: S-RAMP > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Currently, artifact type autodetection exists in multiple forms, nearly all of them client-side. The Maven Wagon inspects the deployment URL and makes assumptions. The UI checks file extensions. > Instead, move a more complete set of artifact-inspection logic server-side. Some semblance of this already exists, to a certain degree. For example, ZipToSrampArchiveProvider#accept(ArtifactType) already exists, but is currently used only to determine which module should expand the artifact. But, the concept could be used to define the artifact type based on the new artifact. It would require a hierarchy of sorts where the most "specialized" integrations (Switchyard, RTGov, DTGov, etc.) are considered first. If none of those "accept" the artifact, the next tier (more generic types) are considered. > The logic could be a mix of filename regex, archive inspection (ex: look for switchyard.xml), etc. > This should completely replace all other types of client-side logic. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-580) Server-side autodetection of artifact types

by Brett Meyer (JIRA)

Brett Meyer created SRAMP-580: --------------------------------- Summary: Server-side autodetection of artifact types Key: SRAMP-580 URL: https://issues.jboss.org/browse/SRAMP-580 Project: S-RAMP Issue Type: Feature Request Reporter: Brett Meyer Assignee: Brett Meyer Currently, artifact type autodetection exists in multiple forms, nearly all of them client-side. The Maven Wagon inspects the deployment URL and makes assumptions. The UI checks file extensions. Instead, move a more complete set of artifact-inspection logic server-side. Some semblance of this already exists, to a certain degree. For example, ZipToSrampArchiveProvider#accept(ArtifactType) already exists, but is currently used only to determine which module should expand the artifact. But, the concept could be used to define the artifact type based on the new artifact. It would require a hierarchy of sorts where the most "specialized" integrations (Switchyard, RTGov, DTGov, etc.) are considered first. If none of those "accept" the artifact, the next tier (more generic types) are considered. The logic could be a mix of filename regex, archive inspection (ex: look for switchyard.xml), etc. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (OVERLORD-151) Fuse Fabric Commands refactoring

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/OVERLORD-151?page=com.atlassian.jira.plug... ] RH Bugzilla Integration updated OVERLORD-151: --------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1146591 > Fuse Fabric Commands refactoring > -------------------------------- > > Key: OVERLORD-151 > URL: https://issues.jboss.org/browse/OVERLORD-151 > Project: Overlord > Issue Type: Bug > Reporter: David virgil naranjo > Assignee: David virgil naranjo > > Remove the fuse fabric interpolation. Now there is not interpolation done by them and it is done using the apache commons interpolation. > Improve the Karaf commands for Fabric. Do not allow to modify the overlord commons profile user information when it is executed from a subclass. > Add a Karaf Command to modify the Overlord user in case it is desired. -- 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 September 2014