[JBoss JIRA] (JBIDE-19008) As a user, I want to delete OpenShift resources
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19008?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-19008:
------------------------------------------
rebased, merged and pushed to upstream/master
> As a user, I want to delete OpenShift resources
> -----------------------------------------------
>
> Key: JBIDE-19008
> URL: https://issues.jboss.org/browse/JBIDE-19008
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.2.2.Final
> Reporter: Jeff Cantrill
> Assignee: Jeff Cantrill
> Fix For: 4.3.0.Beta1
>
>
> We should allow users to remove OpenShift v3 resources.
> Beside the primary usecase there's an additional requirement: If you submit several resource creations in 1 config/file the backend might stop processing right in the middle, the operation is not transactional. We therefore need to allow the user to clean up.
> Any resource in the browser may be deleted except projects. Project are a special case where we MAY need to 'cleanup' all the resources associated with the project. Defer handling that case for now
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JBIDE-19757) Use jbosstools aggregate site instead of special webtools-site for WTP's AS server discovery
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19757?page=com.atlassian.jira.plugi... ]
Mickael Istria updated JBIDE-19757:
-----------------------------------
Fix Version/s: 4.3.0.Beta1
(was: 4.3.0.Beta2)
> Use jbosstools aggregate site instead of special webtools-site for WTP's AS server discovery
> --------------------------------------------------------------------------------------------
>
> Key: JBIDE-19757
> URL: https://issues.jboss.org/browse/JBIDE-19757
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build, server
> Reporter: Mickael Istria
> Assignee: Nick Boldt
> Fix For: 4.3.0.Beta1
>
>
> With https://bugs.eclipse.org/bugs/show_bug.cgi?id=434185 , WTP Server Discovery mechanism was granted a new strategy which allows to rely on regular p2 metadata instead of a site.xml.
> Support for this was already merged in server ( https://github.com/jbosstools/jbosstools-server/commit/2d3cc63a9b67753ad9... )
> In order to save an artifact to manage (the webtools p2 repository), we could use this mechanism and consider contributing directly the main JBT URL to webtools discovery.
> However, server discovery also keeps older strategies and since we produce invalid site.xml files, this is currently failing
> {code}
> !ENTRY org.eclipse.equinox.p2.updatesite 2 0 2015-05-04 09:40:58.088
> !MESSAGE Error parsing feature stream. The unique identifier or the version is null or empty for the State: "Category": unique identifier="minimal-json" version="null".
> {code}
> because we are lines specifying bundle but no version in the site.xml.
> [~nickboldt] What are those site.xml useful for? Could we get rid of them?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JBIDE-19757) Use jbosstools aggregate site instead of special webtools-site for WTP's AS server discovery
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19757?page=com.atlassian.jira.plugi... ]
Mickael Istria updated JBIDE-19757:
-----------------------------------
Fix Version/s: 4.3.0.Beta2
(was: 4.3.0.Beta1)
> Use jbosstools aggregate site instead of special webtools-site for WTP's AS server discovery
> --------------------------------------------------------------------------------------------
>
> Key: JBIDE-19757
> URL: https://issues.jboss.org/browse/JBIDE-19757
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build, server
> Reporter: Mickael Istria
> Assignee: Nick Boldt
> Fix For: 4.3.0.Beta2
>
>
> With https://bugs.eclipse.org/bugs/show_bug.cgi?id=434185 , WTP Server Discovery mechanism was granted a new strategy which allows to rely on regular p2 metadata instead of a site.xml.
> Support for this was already merged in server ( https://github.com/jbosstools/jbosstools-server/commit/2d3cc63a9b67753ad9... )
> In order to save an artifact to manage (the webtools p2 repository), we could use this mechanism and consider contributing directly the main JBT URL to webtools discovery.
> However, server discovery also keeps older strategies and since we produce invalid site.xml files, this is currently failing
> {code}
> !ENTRY org.eclipse.equinox.p2.updatesite 2 0 2015-05-04 09:40:58.088
> !MESSAGE Error parsing feature stream. The unique identifier or the version is null or empty for the State: "Category": unique identifier="minimal-json" version="null".
> {code}
> because we are lines specifying bundle but no version in the site.xml.
> [~nickboldt] What are those site.xml useful for? Could we get rid of them?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JBIDE-19814) sources zip should include local sources too (jbosstools-build-sites or jbdevstudio-product)
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19814?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-19814:
----------------------------------------
Would "git archive" fit?
> sources zip should include local sources too (jbosstools-build-sites or jbdevstudio-product)
> --------------------------------------------------------------------------------------------
>
> Key: JBIDE-19814
> URL: https://issues.jboss.org/browse/JBIDE-19814
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.3.0.Beta1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.3.0.Beta1
>
>
> If we change the way the jbosstools-src.zip is produced, such that in addition to upstream projects it ALSO includes the contents of jbosstools-build-sites too, then we can reuse that mojo for the jbdevstudio-product src.zip too, as it will ALSO include the 17 upstream JBT zips (from Github) and also the local JBDS sources.
> This would mean a large chunk of ant code in jbdevstudio-product/sources/build.xml (if not all of it) could go away. Hooray for 1 solution spanning both projects and product! :D
> Max also suggested that we use a clean copy of the sources just in case the build process makes them dirty:
> {code}
> git clone --depth=1 . clean-sources-dir && rm -rf clean-sources-dir/.git{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JBIDE-19715) Get rid of "fullSite", stick with "repository"
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19715?page=com.atlassian.jira.plugi... ]
Mickael Istria updated JBIDE-19715:
-----------------------------------
Priority: Minor (was: Major)
> Get rid of "fullSite", stick with "repository"
> ----------------------------------------------
>
> Key: JBIDE-19715
> URL: https://issues.jboss.org/browse/JBIDE-19715
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Affects Versions: 4.3.0.Alpha1
> Reporter: Mickael Istria
> Assignee: Mickael Istria
> Priority: Minor
> Fix For: 4.3.0.Beta1
>
>
> Currently, some builds such as aggregate create a "site/target/fullSite" folder, which is aimed at being deployed. However, it would be simpler to populate the site/target/repository folder, so it would be only one directory to move, and the same one for all builds.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JBIDE-16128) Publish component sites to Nexus
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16128?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-16128:
----------------------------------------
If we replace the BUILD_ALIAS by a fixed version in the root pom of each components, here is what we gain:
* We deploy to Nexus, using regular Maven deployment steps (less usage of in-house scripts)
* We don't have to maintain conventions on download.jboss.org for the CI builds
* We move to a more standard Maven approach, that several other Eclipse projects are using
So overall, are build/publication process becomes more accessible.
The simplicity to publish comes with the following drawbacks, mainly caused by the fact that Maven versions are statically defined and don't allow to reference variables (such as BUILD_ALIAS).
* It's very important that components do not forget to bump version in there root pom (and immediate children), to make sure master and branch do not collide to the same URL on Nexus. => Possible workaround: we add the BUILD_ALIAS property to jobs and add a step on CI or in pom.xml to guarantee that version ends with BUILD_ALIAS-SNAPSHOT.
* it's more complicated to update root pom + immediate children than to update only root pom. => However, if you do it wrong, build fails explicitly, so not much surprise.
My impression is that it seems worth it, and that the cost in lower than the gain.
> Publish component sites to Nexus
> --------------------------------
>
> Key: JBIDE-16128
> URL: https://issues.jboss.org/browse/JBIDE-16128
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Reporter: Mickael Istria
> Assignee: Mickael Istria
> Priority: Optional
> Fix For: 4.3.x
>
> Attachments: deployWithJenkins.png
>
>
> In order to get a first idea of how easy/difficult it would be to rely on Nexus for publication,we could simply start by configuring CI jobs to also run a "mvn deploy" to deploy the output p2 repository onto Nexus.
> Then we'll see what are the pros/cons of this approach.
> Current publication process and locations will be kept. These p2 repo on Nexus won't be consumed by aggregator, at least not until we are sure it's worth it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JBIDE-16128) Publish component sites to Nexus
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16128?page=com.atlassian.jira.plugi... ]
Mickael Istria edited comment on JBIDE-16128 at 5/18/15 10:59 AM:
------------------------------------------------------------------
If we replace the BUILD_ALIAS by a fixed version in the root pom of each components, here is what we gain:
* We deploy to Nexus, using regular Maven deployment steps (less usage of in-house scripts)
* We don't have to maintain conventions on download.jboss.org for the CI builds
* We move to a more standard Maven approach, that several other Eclipse projects are using
So overall, are build/publication process becomes more accessible.
The simplicity to publish comes with the following drawbacks, mainly caused by the fact that Maven versions are statically defined and don't allow to reference variables (such as BUILD_ALIAS).
* It's very important that components do not forget to bump version in there root pom (and immediate children), to make sure master and branch do not collide to the same URL on Nexus. => Possible workaround: we add the BUILD_ALIAS property to jobs and add a step on CI or in pom.xml to guarantee that version ends with BUILD_ALIAS-SNAPSHOT.
* it's more complicated to update root pom + immediate children than to update only root pom. => However, if you do it wrong, build fails explicitly, so not much surprise.
My impression is that it seems worth it, and that the cost in lower than the gain.
was (Author: mickael_istria):
If we replace the BUILD_ALIAS by a fixed version in the root pom of each components, here is what we gain:
* We deploy to Nexus, using regular Maven deployment steps (less usage of in-house scripts)
* We don't have to maintain conventions on download.jboss.org for the CI builds
* We move to a more standard Maven approach, that several other Eclipse projects are using
So overall, are build/publication process becomes more accessible.
The simplicity to publish comes with the following drawbacks, mainly caused by the fact that Maven versions are statically defined and don't allow to reference variables (such as BUILD_ALIAS).
* It's very important that components do not forget to bump version in there root pom (and immediate children), to make sure master and branch do not collide to the same URL on Nexus. => Possible workaround: we add the BUILD_ALIAS property to jobs and add a step on CI or in pom.xml to guarantee that version ends with BUILD_ALIAS-SNAPSHOT.
* it's more complicated to update root pom + immediate children than to update only root pom. => However, if you do it wrong, build fails explicitly, so not much surprise.
My impression is that it seems worth it, and that the cost in lower than the gain.
> Publish component sites to Nexus
> --------------------------------
>
> Key: JBIDE-16128
> URL: https://issues.jboss.org/browse/JBIDE-16128
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Reporter: Mickael Istria
> Assignee: Mickael Istria
> Priority: Optional
> Fix For: 4.3.x
>
> Attachments: deployWithJenkins.png
>
>
> In order to get a first idea of how easy/difficult it would be to rely on Nexus for publication,we could simply start by configuring CI jobs to also run a "mvn deploy" to deploy the output p2 repository onto Nexus.
> Then we'll see what are the pros/cons of this approach.
> Current publication process and locations will be kept. These p2 repo on Nexus won't be consumed by aggregator, at least not until we are sure it's worth it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JBIDE-19751) Update Sapphire to latest 9.0.0.x version
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19751?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-19751:
----------------------------------------
We need a decision ASAP on this topic in order to move forward with target-platfoms. The best would be that we migrate to Sapphire 9.0. Can the affected project provide an evaluation of how much effort it is to move to 9.0? With some luck, the API we consume didn't change...
> Update Sapphire to latest 9.0.0.x version
> -----------------------------------------
>
> Key: JBIDE-19751
> URL: https://issues.jboss.org/browse/JBIDE-19751
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: arquillian, batch, target-platform
> Reporter: Alexey Kazakov
> Assignee: Alexey Kazakov
> Fix For: 4.3.0.Beta1
>
>
> The current version (included in Mars 6 update site) is 9.0.0.201408261741.
> It doesn't include some critical fixes.
> We need to figure out what version will be included in Mars final and what we can do now:
> - Update our TP to the latest sapphire nightly build? - https://hudson.eclipse.org/sapphire/job/9.0.x/
> - Wait for Mars Final?
> - Set proper range for Sapphire dependencies in Batch plugin.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JBDS-3434) Kubernetes editor & wizard
by Jeff Cantrill (JIRA)
[ https://issues.jboss.org/browse/JBDS-3434?page=com.atlassian.jira.plugin.... ]
Jeff Cantrill commented on JBDS-3434:
-------------------------------------
[~adietish] Challenge accepted! I don't think our primary goal is necessarily source-to-build since OpenShift supports both source and Docker build strategies. Presumably a person could have a Dockerfile in their source repo that we could use to create and build their image. We have discussed a new-app flow that is more similiar to what is provided by the command line tool so there is probably something there. My brief chat with [~maxandersen] suggested this should be broken into 2 issues (1 for editor, 1 for wizard) though I thought we had both these features targed already for after summit.
> Kubernetes editor & wizard
> --------------------------
>
> Key: JBDS-3434
> URL: https://issues.jboss.org/browse/JBDS-3434
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 8.x
> Reporter: Charles Moulliard
> Assignee: Jeff Cantrill
> Fix For: 9.0.x
>
>
> To deploy a project on Openshift3, it will be required to edit/generate a kubernetes.json file. The fabric8 project has created a maven plugin to generate the kubernetes.json file and next to deploy the project on OS" (= maven fabic8:install) but it could be interesteting also that we propose :
> - a kubernetes editor within JBDS to update the YAML or JSON file and
> - a wizard to create a kubernetes template file using some criteria like the API version, name, ports to be exposed, volumes to mount, ...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JBDS-3434) Kubernetes editor & wizard
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3434?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-3434:
-------------------------------------------
we should get the editor and wizard split into separate jiras - they are doable separately and just complementary to each other.
> Kubernetes editor & wizard
> --------------------------
>
> Key: JBDS-3434
> URL: https://issues.jboss.org/browse/JBDS-3434
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 8.x
> Reporter: Charles Moulliard
> Assignee: Jeff Cantrill
> Fix For: 9.0.x
>
>
> To deploy a project on Openshift3, it will be required to edit/generate a kubernetes.json file. The fabric8 project has created a maven plugin to generate the kubernetes.json file and next to deploy the project on OS" (= maven fabic8:install) but it could be interesteting also that we propose :
> - a kubernetes editor within JBDS to update the YAML or JSON file and
> - a wizard to create a kubernetes template file using some criteria like the API version, name, ports to be exposed, volumes to mount, ...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months