[JBoss JIRA] (JBDS-3298) Push changes to Existing OpenShift Project
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3298?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-3298:
-------------------------------------------
Yes, this is the example. Note, the "hacky about it" part - thats what makes it really hard for us to build tools since hacks are needed at the docker image level (for now ;)
> 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, requirements
> Affects Versions: 8.0.0.GA
> Reporter: Burr Sutter
> Assignee: Max Rydahl Andersen
> Priority: Blocker
> Fix For: 9.0.0.GA
>
>
> 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)
11 years, 1 month
[JBoss JIRA] (JBDS-3297) Download/Import Existing OpenShift Project
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3297?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-3297:
-------------------------------------------
I'm not following to see how this is affected at all by docker tooling being available or not ?
No matter if docker is available download/import of openshift configured projects is needed and very separate from docker (at least if STI is being used)
If openshift STI is used then you are *not* deploying the same maven generated war, but it is being rebuilt as part of openshift STI.
I think this issue is much more affected by how much of v3 will be ready to actually provide the metadata and services needed to even known which of possibley many git repositories an openshift project (which is not the same as eclipse project) will have.
Thus how this will all work is still very fluid imo.
> Download/Import Existing OpenShift Project
> ------------------------------------------
>
> Key: JBDS-3297
> URL: https://issues.jboss.org/browse/JBDS-3297
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: openshift, requirements
> Reporter: Burr Sutter
> Assignee: Max Rydahl Andersen
> Priority: Blocker
>
> Use Case #1 - Download/Import Existing OpenShift Project
> a) Assume OpenShift is started remotely and provides an entrypoint URL (e.g. http://localhost:8080/osapi/v1beta1/projects)
> b) Assume end-user is logged in (ignore auth for now)
> c) Assume OpenShift already has some deployed "projects", this "project" definition includes the buildconfig, deployconfig, docker image, source git URL, routes and services.
> d) Eclipse user will open a dialog and enter the URL from step a
> e) Eclipse user will see a list of "things" associated with "projects" from step 1c
> "things"
> f) Embedded in one of those things is a Git URL - that will be displayed to the user who will agree to git clone it [1f]
> g) If the downloaded items include a Maven project, the Eclipse user will see a newly configured Eclipse project based on Maven with the appropriately configured facets
> h) If there is no pom.xml, the Eclipse user will see a newly configured generic Eclipse project containing the downloaded files
> i) It is expected that a Maven-based Java project will build locally (leveraging Maven Central and/or maven.repository.redhat.com)
> j) It is expected that a Maven-based Java project will deploy to a localhost EAP/Wildfly or a locally running Docker container:
> docker run -it -p 8080:8080 openshift/wildfly-8-centos
> [1f] https://github.com/openshift/origin/blob/master/examples/sample-app/appli...
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (JBDS-3291) Support for auto generating jboss-deployment-structure based on JBoss Modules selected in a project
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3291?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen closed JBDS-3291.
-------------------------------------
Resolution: Rejected
Agreed. Rejected as there is no known practical nor pragmatic approach to do this.
> Support for auto generating jboss-deployment-structure based on JBoss Modules selected in a project
> ---------------------------------------------------------------------------------------------------
>
> Key: JBDS-3291
> URL: https://issues.jboss.org/browse/JBDS-3291
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: integration, requirements, server
> Affects Versions: 8.0.0.GA
> Reporter: Mustafa Musaji
> Assignee: Max Rydahl Andersen
>
> If you have a POM for a project that defines the following
> {code}
> <project>
> ...
> <dependencyManagement>
> <dependencies>
> <dependency>
> <groupId>org.jboss.bom</groupId>
> <artifactId>eap6-supported-artifacts</artifactId>
> <version>6.3.1.GA</version>
> <scope>import</scope>
> <type>pom</type>
> </dependency>
> </dependencies>
> </dependencyManagement>
> ...
> <dependencies>
> <dependency>
> <groupId>commons-beanutils</groupId>
> <artifactId>commons-beanutils</artifactId>
> <scope>provided</scope>
> </dependency>
> </dependencies>
> </project>
> {code}
> The tooling should create a jboss-deployment-structure.xml that contains the "org.apache.commons.beanutils" dependency automatically.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (JBDS-3354) Seam 2 is still included in JBDS 9 Alpha1 installed from jar
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3354?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-3354:
-------------------------------------------
[~akazakov] question is if the supported annotations in here are 100% seam3 specific or available now via deltaspike ?
> Seam 2 is still included in JBDS 9 Alpha1 installed from jar
> ------------------------------------------------------------
>
> Key: JBDS-3354
> URL: https://issues.jboss.org/browse/JBDS-3354
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: build, cdi, seam
> Affects Versions: 9.0.0.Alpha1
> Reporter: Martin Malina
> Assignee: Fred Bricon
> Priority: Blocker
> Fix For: 9.0.0.Alpha2
>
>
> It seems to me that we removed the wrong feature.
> This is JBDS 8.0.2:
> {code}
> nattura:features rasp$ ls |grep seam
> org.jboss.tools.cdi.seam.feature_1.6.1.Final-v20141209-0505-B79
> org.jboss.tools.maven.seam.feature_1.6.1.Final-v20150109-2320-B116
> org.jboss.tools.runtime.seam.detector.feature_3.6.1.Final-v20141209-0505-B79
> org.jboss.tools.seam.feature_3.6.1.Final-v20141209-0505-B79
> {code}
> And this is JBDS 9.0.0.Alpha1 B11:
> {code}
> nattura:features rasp$ ls |grep seam
> org.jboss.tools.seam.feature_3.7.0.Alpha1-v20150213-0551-B3
> {code}
> When you look at plugins, it looks as follows:
> JBDS 8.0.2:
> {code}
> nattura:plugins rasp$ ls|grep seam
> org.jboss.tools.cdi.seam.config.core_1.6.1.Final-v20141209-0505-B79.jar
> org.jboss.tools.cdi.seam.config.ui_1.6.1.Final-v20141209-0505-B79.jar
> org.jboss.tools.cdi.seam.core_1.6.1.Final-v20141209-0505-B79.jar
> org.jboss.tools.cdi.seam.faces.core_1.6.1.Final-v20141209-0505-B79.jar
> org.jboss.tools.cdi.seam.solder.core_1.6.1.Final-v20141209-0505-B79.jar
> org.jboss.tools.cdi.seam.text.ext_1.6.1.Final-v20141209-0505-B79.jar
> org.jboss.tools.jsf.vpe.seam_3.6.1.Final-v20141209-0505-B79
> org.jboss.tools.maven.seam_1.6.1.Final-v20150109-2320-B116.jar
> org.jboss.tools.runtime.seam.detector_3.6.1.Final-v20141209-0505-B79.jar
> org.jboss.tools.seam.core_3.6.1.Final-v20141209-0505-B79.jar
> org.jboss.tools.seam.pages.xml_3.6.1.Final-v20141209-0505-B79.jar
> org.jboss.tools.seam.text.ext_3.6.1.Final-v20141209-0505-B79.jar
> org.jboss.tools.seam.ui.pages_3.6.1.Final-v20141209-0505-B79.jar
> org.jboss.tools.seam.ui_3.6.1.Final-v20141209-0505-B79.jar
> org.jboss.tools.seam.xml.ui_3.6.1.Final-v20141209-0505-B79.jar
> org.jboss.tools.seam.xml_3.6.1.Final-v20141209-0505-B79.jar
> {code}
> JBDS 9.0.0.Alpha1 B11:
> {code}
> nattura:plugins rasp$ ls|grep seam
> org.jboss.tools.cdi.seam.solder.core_1.7.0.Alpha1-v20150213-0551-B3.jar
> org.jboss.tools.jsf.vpe.seam_3.7.0.Alpha1-v20150213-0551-B3
> org.jboss.tools.seam.core_3.7.0.Alpha1-v20150213-0551-B3.jar
> org.jboss.tools.seam.pages.xml_3.7.0.Alpha1-v20150213-0551-B3.jar
> org.jboss.tools.seam.text.ext_3.7.0.Alpha1-v20150213-0551-B3.jar
> org.jboss.tools.seam.ui.pages_3.7.0.Alpha1-v20150213-0551-B3.jar
> org.jboss.tools.seam.ui_3.7.0.Alpha1-v20150213-0551-B3.jar
> org.jboss.tools.seam.xml.ui_3.7.0.Alpha1-v20150213-0551-B3.jar
> org.jboss.tools.seam.xml_3.7.0.Alpha1-v20150213-0551-B3.jar
> {code}
> For JBoss Tools, both are there (seam and cdi.seam) - I'm not sure if that's intentional. Is there a JIRA for dropping seam?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (JBDS-3285) Git: Easy Import
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3285?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-3285:
-------------------------------------------
[~mickael_istria] we want easy import in JBoss Tools/Developer Studio.
We should get it in as a tech preview or in worst case earlyaccess at least.
How can we go about bundling it ?
> Git: Easy Import
> ----------------
>
> Key: JBDS-3285
> URL: https://issues.jboss.org/browse/JBDS-3285
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: requirements, upstream
> Affects Versions: 8.0.0.GA
> Reporter: Burr Sutter
> Assignee: Mickael Istria
> Labels: usability
> Fix For: 9.0.x
>
>
> As a Java EE developer, in some cases using Git for the first time (or only familiar with command line git), I find it very difficult to clone and import a project correctly into JBDS, having the appropriate facets configured, if it has a maven pom.xml, correctly setting the build path, where it is easily deployable to a localhost EAP instance.
> The mission here is to make the Git experience much more user friendly.
> Progress/Status (updated progressively):
> {quote}
> Easymport framework has been contributed to e4 (Platform Incubator): in http://git.eclipse.org/c/e4/org.eclipse.e4.ui.git/tree/bundles , see all org.eclipse.e4.ui.importer* . You can install it in your IDE from http://download.eclipse.org/e4/snapshots/org.eclipse.e4.ui . The entry-points are either the new menu "File > Import projects from folder..." or from legacy import wizard under "General > Local folder(s) as project into workspace".
> We have working extensions that allow to import Java EE & Maven: https://github.com/jbosstools/jbosstools-playground/tree/master/plugins (install from http://download.jboss.org/jbosstools/builds/staging/jbosstools-playground... ) , that we plan to contribute upstream when projects such as m2e and WTP when the framework seems mature enough.
> There is not yet an easy link from the EGit wizard to the Easymport one, nor an easy link from SVN wizard to Easymport.
> There is almost no chance that this can be included in Eclipse IDE for Mars release in June. But we could already think about including it in next JBoss Tools and JBoss Developer Studio milestones, so that we'd get more feedback. At this point, feedback from users and adopters is the key point.
> I invite you to give it a try, and to report issues here.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (JBDS-3285) Git: Easy Import
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3285?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen reassigned JBDS-3285:
-----------------------------------------
Assignee: Mickael Istria (was: Burr Sutter)
> Git: Easy Import
> ----------------
>
> Key: JBDS-3285
> URL: https://issues.jboss.org/browse/JBDS-3285
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: requirements, upstream
> Affects Versions: 8.0.0.GA
> Reporter: Burr Sutter
> Assignee: Mickael Istria
> Labels: usability
> Fix For: 9.0.x
>
>
> As a Java EE developer, in some cases using Git for the first time (or only familiar with command line git), I find it very difficult to clone and import a project correctly into JBDS, having the appropriate facets configured, if it has a maven pom.xml, correctly setting the build path, where it is easily deployable to a localhost EAP instance.
> The mission here is to make the Git experience much more user friendly.
> Progress/Status (updated progressively):
> {quote}
> Easymport framework has been contributed to e4 (Platform Incubator): in http://git.eclipse.org/c/e4/org.eclipse.e4.ui.git/tree/bundles , see all org.eclipse.e4.ui.importer* . You can install it in your IDE from http://download.eclipse.org/e4/snapshots/org.eclipse.e4.ui . The entry-points are either the new menu "File > Import projects from folder..." or from legacy import wizard under "General > Local folder(s) as project into workspace".
> We have working extensions that allow to import Java EE & Maven: https://github.com/jbosstools/jbosstools-playground/tree/master/plugins (install from http://download.jboss.org/jbosstools/builds/staging/jbosstools-playground... ) , that we plan to contribute upstream when projects such as m2e and WTP when the framework seems mature enough.
> There is not yet an easy link from the EGit wizard to the Easymport one, nor an easy link from SVN wizard to Easymport.
> There is almost no chance that this can be included in Eclipse IDE for Mars release in June. But we could already think about including it in next JBoss Tools and JBoss Developer Studio milestones, so that we'd get more feedback. At this point, feedback from users and adopters is the key point.
> I invite you to give it a try, and to report issues here.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (JBDS-3258) Docker Tooling (Advanced Integration)
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3258?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-3258:
-------------------------------------------
Let me map these:
1-2: actually running docker instance is something we can initially document/provide links for. Next version we can look into having a way to easily run boot2docker/vagrant/etc. but I think there will be so many variations trying to keep up with it in the plugin is too early.
3: we will try detect the ip where we can, but because of the many combinations I think we will in addition on trying to autodetect also simply listen to a ~/.docker.cfg or similar that can be shared between scripts and tools (both in and outside eclipse). And in all cases it will possible to explicitly put an ip/hostname into the docker UI
4 same as 9 - will be made available from the image and container view as 'Add...' or 'Run...' action
5 that is what container view does
6 context menu/stop button in container view
7 that is what image view does
8 context menu/delete button in image view
9 see #4
10 Run in context menu. Should provide UI to map ports, links, volumes and console log will show the output ...possibly use terminal ui for it to provide input.
11/12 you mean disconnected terminal ? not sure it makes sense to have explicit in eclipse ui, but just allow to open/close the console log for a container.
13-16 is extremely specific to what the image is capable of doing so this is not covered by generic docker tooling. Also, do you expect the deployment to be incremental (thus requiring understanding/assume alot about the volume mappings) or be complete ones (thus just relying on management API being exposed)
17) context menu action
18) context menu action - I think we should put docker registry interactions in separate sub task.
19) I image "Docker build" as being a context menu action on DockerFile files in the project explorer.
> Docker Tooling (Advanced Integration)
> -------------------------------------
>
> Key: JBDS-3258
> URL: https://issues.jboss.org/browse/JBDS-3258
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: openshift, requirements
> Reporter: Burr Sutter
> Assignee: Xavier Coulon
>
> Once significant delta between the "basic" and advanced scenarios is that here I wish to custom craft my own docker images instead of using an existing one - where my custom crafted image includes my .war or .ear.
> In addition to the basic integrations of pull, run, stop, commit and push
> boot2docker init
> boot2docker up
> boot2docker down
> boot2docker ip
> docker run -d
> docker ps
> docker rm
> docker rmi
> docker build
> End-user steps:
> 0) assumes boot2docker has been dowloaded and installed
> 1) boot2docker init : required to to insure boot2docker-vm is properly initialized
> 2) boot2docker up : starts the VirtualBox boot2docker-vm
> 3) boot2docker ip : returns the IP address - this will be vital when it comes to testing - it would need to be integrated with our Run - As on Docker capability.
> 4) docker run -i -t -p 80:8080 jboss/wildfly -d : the -d means detached, I may need to run N containers simultaneously
> 5) docker ps : allows me to see all my currently running containers
> 6) docker rm : allows me to kill a currently running container
> 7) docker rmi : allows me to remove a local image
> 8) docker build : assumes that I have crafted a Dockerfile - this will create the local image - with my .war or .ear embedded
> 9) docker run : this new created image
> The docker build scenario can be triggered via a Maven plugin
> The docker build scenario can also be triggered via an Eclipse menu option (like a Maven install)
> We need to figure out the file-system layout so that the Dockerfile and the maven project are all nicely checked into git/svn. So that Jenkins can pick up this repository and perform an automated "docker build" (post Maven install) and then run all the appropriate unit, integration and functional tests.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month