[JBoss JIRA] (JBDS-3275) Add wildfly archetypes to JBoss Central
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/JBDS-3275?page=com.atlassian.jira.plugin.... ]
Pete Muir commented on JBDS-3275:
---------------------------------
Agreed.
> Add wildfly archetypes to JBoss Central
> ---------------------------------------
>
> Key: JBDS-3275
> URL: https://issues.jboss.org/browse/JBDS-3275
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: central, requirements
> Reporter: Burr Sutter
> Assignee: Fred Bricon
> Fix For: 8.1.0.GA
>
>
> Supporting Wildfly archetypes with JBoss Central. As an Java EE developer, I need to be able to switch between EAP and Wildfly, when I select Wildfly, the archetype needs to correctly include the right BOMs, where all artifacts are available only on Maven Central.
> This should include both the Java EE Web Project, Java EE EAR Project, and HTML5 Project
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 6 months
[JBoss JIRA] (JBDS-3250) Support for OpenShift 3 with Docker and Kubernetes
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBDS-3250?page=com.atlassian.jira.plugin.... ]
Andre Dietisheim updated JBDS-3250:
-----------------------------------
Fix Version/s: 9.0.0.GA
> Support for OpenShift 3 with Docker and Kubernetes
> --------------------------------------------------
>
> Key: JBDS-3250
> URL: https://issues.jboss.org/browse/JBDS-3250
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Epic
> Components: openshift
> Reporter: Max Rydahl Andersen
> Assignee: Andre Dietisheim
> Fix For: 9.0.0.GA
>
>
> Copied from JBDS-3278:
> As an OpenShift v3 end-user, I need to be deploy, undeploy, add, remove, etc. for applications targeting the v3 API.
> The UI for OpenShift Explorer will need to be expanded (or replaced) to handle v3's new terminology and architecture.
> For June @Burr tells us to implement (Mail "Forget everything you know about OpenShift"):
> {quote}
> It could be as simple as…somewhere in OpenShift v3 is the git URL to a source repo….
> Our Eclipse end-user needs to be able to “browse” for it and select it
> git clone it
> make changes
> git push it back
> {quote}
> This gives us 3 main use cases (as in mail and chats):
> # Import existing OpenShift project (JBDS-3297)
> # Push Changes to Existing OpenShift project (JBDS-3298)
> # New Project from Template (template should have a default buildconfig, deployconfig and docker image)
> {quote}
> Use Case #1 assumes a TON about what has happened before me.
> - Assumes that OpenShift Enterprise is installed, configured and running happily at an accessible URL
> - Assumes end-user is already logged in (there is no auth method at this time)
> - Assumes that someone else (not our eclipse end-user) has manually created his/her “project” with an image, a git repo, a deployment config, a build config, defined routes, defined services, etc.
> {quote}
> We have a more extensive document that outlines the usecases:
> https://docs.google.com/a/redhat.com/document/d/1VwYNuKWUzuorU-6GcF420Vl_...
> {quote}
> These are features/capabilities currently NOT planned for OpenShift v3's Eclipse Tooling:
> 1) Create SSH Keys
> 2) Upload SSH Keys
> 3) Create Domain
> 4) Add a database, message broker, cache (embeddable cartridge)
> 5) Show In Web Browser
> 6) Review Env Vars
> 7) Edit Env Vars
> 8) Review Logs
> 9) Log Streaming
> 10) SSH in
> 11) Delete/Destroy
> 12) Remote Debugging (though that might "just work")
> 13) Snapshot creation
> 14) Snapshot restore
> 15) Port Forwarding
> 16) Marker Files
> 17) Node.js
> 18) PHP
> 19) Python
> 20) C++
> 21) Perl
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 6 months
[JBoss JIRA] (JBDS-3298) Push changes to Existing OpenShift Project
by Jeff Cantrill (JIRA)
[ https://issues.jboss.org/browse/JBDS-3298?page=com.atlassian.jira.plugin.... ]
Jeff Cantrill edited comment on JBDS-3298 at 1/6/15 4:19 PM:
-------------------------------------------------------------
[~maxandersen]
i: This is the user waiting which we will either need to poll or the user will refresh
j: There is a route object that has not been talked about but does exist. We must assume that the URL they receive is from that object if it exists which it has to otherwise you wont be able to access it. Also, you are correct in that most of this is dependent upon what is already configured. All the magic WILL happen when you push assuming the build hook is configured for your github repo.
was (Author: jcantrill):
[~maxandersen]
i: This is the user waiting which we will either need to poll or the user will refresh
j: There is a route object that has not been talked about but does exist. We must assume that the URL they receive is from that object if it exists which it has to otherwise you wont be able to access it.
> Push changes to Existing OpenShift Project
> ------------------------------------------
>
> Key: JBDS-3298
> URL: https://issues.jboss.org/browse/JBDS-3298
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: openshift
> Reporter: Burr Sutter
> Assignee: Max Rydahl Andersen
>
> Use Case #2 Push changes to Existing OpenShift Project
> a) assumes the steps in Use Case #1 JBDS-3297
> b) assumes the end-user has uploaded his SSH keys (to allow for git push)
> c) Eclipse user will add, edit and delete files from the originally downloaded/imported set of files - leveraging Eclipse specialized editors, content-assist, etc
> d) Eclipse user will run (deploy) Maven-based Java projects on a local EAP
> e) Eclipse user will test (JUnit, Arquillian)
> f) Eclipse user will debug with the local EAP (run on localhost or from Docker Image)
> g) Eclipse user will git add and git commit as appropriate
> h) Eclipse user will git push to the original URL provided in Use Case #1
> i) Eclipse user will await the automatic rebuild of a new image, deployment of the same
> j) Eclipse user will then be provided a URL and the browser can be opened automatically
> Note:
> i) auto-build=true, auto-deploy=true
> assumes the auto-build (.war and docker image) upon git push enabled in Use Case #1c (JBDS-3297). This step also assumes the auto-deploy upon build is enabled in 1c.
> A future variation of #2 should allow for "auto-build=false" and "auto-deploy=true" with hot deployment of the binary .war or .ear.
> If auto-build=false and auto-deploy=false then the Eclipse user will simply receive a message that his git push was successful, no URL, no browser opening.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 6 months
[JBoss JIRA] (JBDS-3298) Push changes to Existing OpenShift Project
by Jeff Cantrill (JIRA)
[ https://issues.jboss.org/browse/JBDS-3298?page=com.atlassian.jira.plugin.... ]
Jeff Cantrill commented on JBDS-3298:
-------------------------------------
[~maxandersen]
i: This is the user waiting which we will either need to poll or the user will refresh
j: There is a route object that has not been talked about but does exist. We must assume that the URL they receive is from that object if it exists which it has to otherwise you wont be able to access it.
> Push changes to Existing OpenShift Project
> ------------------------------------------
>
> Key: JBDS-3298
> URL: https://issues.jboss.org/browse/JBDS-3298
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: openshift
> Reporter: Burr Sutter
> Assignee: Max Rydahl Andersen
>
> Use Case #2 Push changes to Existing OpenShift Project
> a) assumes the steps in Use Case #1 JBDS-3297
> b) assumes the end-user has uploaded his SSH keys (to allow for git push)
> c) Eclipse user will add, edit and delete files from the originally downloaded/imported set of files - leveraging Eclipse specialized editors, content-assist, etc
> d) Eclipse user will run (deploy) Maven-based Java projects on a local EAP
> e) Eclipse user will test (JUnit, Arquillian)
> f) Eclipse user will debug with the local EAP (run on localhost or from Docker Image)
> g) Eclipse user will git add and git commit as appropriate
> h) Eclipse user will git push to the original URL provided in Use Case #1
> i) Eclipse user will await the automatic rebuild of a new image, deployment of the same
> j) Eclipse user will then be provided a URL and the browser can be opened automatically
> Note:
> i) auto-build=true, auto-deploy=true
> assumes the auto-build (.war and docker image) upon git push enabled in Use Case #1c (JBDS-3297). This step also assumes the auto-deploy upon build is enabled in 1c.
> A future variation of #2 should allow for "auto-build=false" and "auto-deploy=true" with hot deployment of the binary .war or .ear.
> If auto-build=false and auto-deploy=false then the Eclipse user will simply receive a message that his git push was successful, no URL, no browser opening.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 6 months