[JBoss JIRA] (JBIDE-18678) Make dependencies to org.jboss.tools.usage optional
by Kaloyan Raev (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18678?page=com.atlassian.jira.plugi... ]
Kaloyan Raev commented on JBIDE-18678:
--------------------------------------
I pushed another pull request: https://github.com/jbosstools/jbosstools-base/pull/364
The change is only in the org.jboss.tools.usage bundle is backward compatible as long as the clients use only non-internal classes from the org.jboss.tools.usage bundle.
If this pull requested is accepted then the two previous ones in browsersim and aerogear won't be needed anymore.
> Make dependencies to org.jboss.tools.usage optional
> ---------------------------------------------------
>
> Key: JBIDE-18678
> URL: https://issues.jboss.org/browse/JBIDE-18678
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: browsersim, usage
> Affects Versions: 4.2.0.CR1
> Reporter: Kaloyan Raev
> Assignee: Alexey Kazakov
> Fix For: 4.3.x
>
>
> I am interested in adopting the CordovaSim feature in our product. However, most of the browsersim bundles have a strong dependency to org.jboss.tools.usage bundle, which force a Usage Reporting popup on startup. I want to avoid this and have the org.jboss.tools.usage excluded from my build.
> Is it possible to make the dependencies to org.jboss.tools.usage optional?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBDS-3297) Download/Import Existing OpenShift Project
by Burr Sutter (JIRA)
[ https://issues.jboss.org/browse/JBDS-3297?page=com.atlassian.jira.plugin.... ]
Burr Sutter updated JBDS-3297:
------------------------------
Description:
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...
was:
Use Case #1 - Download/Import Existing OpenShift Project
a) Assume OpenShift is started remotely and provides an entrypoint URL
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...
> 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
> Reporter: Burr Sutter
> Assignee: Max Rydahl Andersen
>
> 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, 3 months
[JBoss JIRA] (JBDS-3298) Push changes to Existing OpenShift Project
by Burr Sutter (JIRA)
[ https://issues.jboss.org/browse/JBDS-3298?page=com.atlassian.jira.plugin.... ]
Burr Sutter updated JBDS-3298:
------------------------------
Description:
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.
was:
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 will allow for "auto-build=false" and "auto-deploy=true" with hot deployment of the binary .war or .ear.
> 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)
11 years, 3 months
[JBoss JIRA] (JBDS-3297) Download/Import Existing OpenShift Project
by Burr Sutter (JIRA)
[ https://issues.jboss.org/browse/JBDS-3297?page=com.atlassian.jira.plugin.... ]
Burr Sutter updated JBDS-3297:
------------------------------
Description:
Use Case #1 - Download/Import Existing OpenShift Project
a) Assume OpenShift is started remotely and provides an entrypoint URL
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...
was:
Use Case #1 - Download/Import Existing OpenShift Project
a) Assume OpenShift is started remotely and provides an entrypoint URL
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 "download" or git clone it
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
> 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
> Reporter: Burr Sutter
> Assignee: Max Rydahl Andersen
>
> Use Case #1 - Download/Import Existing OpenShift Project
> a) Assume OpenShift is started remotely and provides an entrypoint URL
> 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, 3 months
[JBoss JIRA] (JBDS-3298) Push changes to Existing OpenShift Project
by CDW Engine (JIRA)
[ https://issues.jboss.org/browse/JBDS-3298?page=com.atlassian.jira.plugin.... ]
CDW Engine updated JBDS-3298:
-----------------------------
CDW pm_ack: ?
CDW release: ?
> 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 will allow for "auto-build=false" and "auto-deploy=true" with hot deployment of the binary .war or .ear.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months