[JBoss JIRA] (JBDS-3872) rename JBoss perspective?
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-3872?page=com.atlassian.jira.plugin.... ]
Nick Boldt commented on JBDS-3872:
----------------------------------
In terms of how to learn what type of user is installing DS... for the DS installer and the DP installer, we could add a page that asks the user into which perspective (collection of views & their default layout) they'd like to start DS: Containers, Java, JavaEE, JavaScript, Integration Stack).
For Marketplace and BYOE installs, we could provide a feature for each perspective and let users simply choose the feature that maps to the perspective they want to use on first start. I'm thinking these features would simply be wrappers for a p2.inf instruction to set a different default perspective for the first start. After that they can just CTRL-3 / CMD-3 and find the other perspectives they might want to use.
We could also use these "perspective features" the way that they exist in JBDS IS, in that they allow a user to cherry-pick which actual pieces of functionality to install from the Marketplace:
* JBoss Business Process and Rules Development (BPEL, BPMN2, jBPM, Drools, Guvnor)
* JBoss Data Virtualization Development (ModeShape, Teiid Designer)
* JBoss Fuse Development (Fuse tooling related to Camel route development)
* JBoss Integration and SOA Development (deprecated in JBDS IS 9.0)
If we wanted to bifurcate DS into smaller installable chunks, we could consider doing a similar thing, but I'd need to know that the functional blocks are, what they'd be called, and which features would be included in each block. (Yes, features can be shared across multiple blocks.)
Please note that I'm *not* suggesting we provide 4 or 5 different DS or DP installers; rather, I'm saying that we can provide the option for users to customize their Marketplace install (smaller footprint installed into Eclipse) but the installer-based installs will still install everything to disk, with the only customization option being the choice of initial perspective.
> rename JBoss perspective?
> -------------------------
>
> Key: JBDS-3872
> URL: https://issues.jboss.org/browse/JBDS-3872
> Project: Red Hat Developer Studio (DevStudio)
> Issue Type: Feature Request
> Components: build
> Affects Versions: 10.0.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Alexey Kazakov
> Fix For: 10.0.0.Alpha2
>
> Attachments: icon-titlebar-jbds10.png
>
>
> Should we rename the default perspective that opens OOTB in devstudio so it's not the "JBoss Perspective? Reason I ask is that it's the first word you see in the titlebar when you fire up DS for the first time:
> !icon-titlebar-jbds10.png!
> We're rebranding Central, the product, and everything in Devstudio. Should we also rename the JBoss perspective?
> cc: [~fbricon] [~akazakov]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBDS-3872) rename JBoss perspective?
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3872?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-3872:
-------------------------------------------
I don't think to rename the JBoss perspective and adding *more* content to it is of great value (as I think both Todd and Alexey) mentions above.
The issue here is that Developer Studio by now has multiple target audiences (Java, JavaEE, Integration Stack (which has even more sub-parts) and recently Containers).
I think its time we start looking at that age old idea of central "learning" about what kind of user you are and guide the content of central from that, likewise having the installer be able to set what is the "first" perspective it opens. i.e. using plain devstudio installer use JBoss, if using platform use a new "Container" one and if integration stack use Fuse, etc.
> rename JBoss perspective?
> -------------------------
>
> Key: JBDS-3872
> URL: https://issues.jboss.org/browse/JBDS-3872
> Project: Red Hat Developer Studio (DevStudio)
> Issue Type: Feature Request
> Components: build
> Affects Versions: 10.0.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Alexey Kazakov
> Fix For: 10.0.0.Alpha2
>
> Attachments: icon-titlebar-jbds10.png
>
>
> Should we rename the default perspective that opens OOTB in devstudio so it's not the "JBoss Perspective? Reason I ask is that it's the first word you see in the titlebar when you fire up DS for the first time:
> !icon-titlebar-jbds10.png!
> We're rebranding Central, the product, and everything in Devstudio. Should we also rename the JBoss perspective?
> cc: [~fbricon] [~akazakov]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBIDE-22273) Conflicting handlers for org.eclipse.e4.ui.importer.openDirectory
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22273?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-22273:
---------------------------------------
[~nickboldt], I won't be able to verify this until when I come back from PTO. You may want to ask somebody else. Perhaps [~rhopp] or [~psrna] can check?
> Conflicting handlers for org.eclipse.e4.ui.importer.openDirectory
> -----------------------------------------------------------------
>
> Key: JBIDE-22273
> URL: https://issues.jboss.org/browse/JBIDE-22273
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, target-platform
> Affects Versions: 4.4.0.Alpha1
> Reporter: Martin Malina
> Assignee: Nick Boldt
>
> When I instal JBT 4.4.0.Alpha1 nightly into Eclipse Java EE Neon M6, I get this after starting Eclipse:
> {code}
> Conflicting handlers for org.eclipse.e4.ui.importer.openDirectory: {org.eclipse.ui.internal.wizards.datatransfer.OpenFolderCommand} vs {org.eclipse.ui.internal.wizards.datatransfer.OpenFolderCommand@25fb43a9}
> {code}
> It's actually twice there and it then happens again at various times.
> I'm on Mac. And BTW I haven't seen this in JBDS, only in JBT.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBIDE-20937) Create resource(s) from json
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20937?page=com.atlassian.jira.plugi... ]
Alexey Kazakov updated JBIDE-20937:
-----------------------------------
Labels: new_and_noteworthy (was: )
> Create resource(s) from json
> ----------------------------
>
> Key: JBIDE-20937
> URL: https://issues.jboss.org/browse/JBIDE-20937
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.3.0.CR2
> Reporter: Marián Labuda
> Assignee: Jeff MAURY
> Priority: Critical
> Labels: new_and_noteworthy
> Fix For: 4.4.0.Alpha2
>
> Attachments: New Resource Wizard Mockup.bmml, New Resource Wizard Mockup.png
>
>
> It would be nice to have feature to create a new resource, e.g. image stream or pod, from provided json. Similar to "oc create -f some_resource.json"
> Currently it would be very usable for MW application templates, because jboss-eap basic s2i template requires image stream which is defined in another json. Also there are applications which are consisting of separately defined resources (e.g. in openshift origin repo is hello world application and its having defined pod in separated json).
> This could be available via context menu New - Resource (like we have for application, projects and connections). And it could be accessible via context menu of a project and specific resource type (e.g. for tree item Image Streams).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBDS-3859) Use SHA256sums to intelligently download latest CI builds into DP installer
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-3859?page=com.atlassian.jira.plugin.... ]
Nick Boldt updated JBDS-3859:
-----------------------------
Git Pull Request: https://github.com/redhat-developer-tooling/developer-platform-install/pu...
> Use SHA256sums to intelligently download latest CI builds into DP installer
> ---------------------------------------------------------------------------
>
> Key: JBDS-3859
> URL: https://issues.jboss.org/browse/JBDS-3859
> Project: Red Hat Developer Studio (DevStudio)
> Issue Type: Feature Request
> Components: platform-installer
> Affects Versions: 10.0.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 10.0.0.Alpha1
>
>
> Per discussion with Denis today, we could:
> * check REMOTE sha256sum before pulling down a new JBDS jar; this will allow us to only fetch a new jbds.jar if the SHAs don't match because a new CI build is available
> * re-enable creation of sha256sum after a download (so that we don't have to create them every time we want to compare to a remote one
> * switch json to use nightly for CDK, vbox, jbds, so builds will use the latest CI
> * add cmdline flag to use the values in requirements.json vs. nightly latest CI, so it's easy to switch between a CI-based build and a statically-defined list of deps
> * add url-latest in requirements.json so that for requirements that have a CI or latest URL, we know where to pull the nightly; this would obviate the need to pass in the URLs via commandline, or to have to toggle between stable/staging and snapshot/CI every time we want to run one type of build or the other
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBDS-3859) Use SHA256sums to intelligently download latest CI builds into DP installer
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-3859?page=com.atlassian.jira.plugin.... ]
Nick Boldt updated JBDS-3859:
-----------------------------
Description:
Per discussion with Denis today, we could:
* check REMOTE sha256sum before pulling down a new JBDS jar; this will allow us to only fetch a new jbds.jar if the SHAs don't match because a new CI build is available
* re-enable creation of sha256sum after a download (so that we don't have to create them every time we want to compare to a remote one
* switch json to use nightly for CDK, vbox, jbds, so builds will use the latest CI
* add cmdline flag to use the values in requirements.json vs. nightly latest CI, so it's easy to switch between a CI-based build and a statically-defined list of deps
* add url-latest in requirements.json so that for requirements that have a CI or latest URL, we know where to pull the nightly; this would obviate the need to pass in the URLs via commandline, or to have to toggle between stable/staging and snapshot/CI every time we want to run one type of build or the other
was:
Per discussion with Denis today, we:
* need to check REMOTE sha256sum before pulling down a new JBDS jar; this will allow us to only fetch a new jbds.jar if the SHAs don't match because a new CI build is available
* re-enable creation of sha256sum after a download (so that we don't have to create them every time we want to compare to a remote one
* switch json to use nightly for CDK, vbox, jbds, so builds will use the latest CI
* add cmdline flag to use the values in requirements.json vs. nightly latest CI, so it's easy to switch between a CI-based build and a statically-defined list of deps
* add url-latest in requirements.json so that for requirements that have a CI or latest URL, we know where to pull the nightly; this would obviate the need to pass in the URLs via commandline, or to have to toggle between stable/staging and snapshot/CI every time we want to run one type of build or the other
> Use SHA256sums to intelligently download latest CI builds into DP installer
> ---------------------------------------------------------------------------
>
> Key: JBDS-3859
> URL: https://issues.jboss.org/browse/JBDS-3859
> Project: Red Hat Developer Studio (DevStudio)
> Issue Type: Feature Request
> Components: platform-installer
> Affects Versions: 10.0.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 10.0.0.Alpha1
>
>
> Per discussion with Denis today, we could:
> * check REMOTE sha256sum before pulling down a new JBDS jar; this will allow us to only fetch a new jbds.jar if the SHAs don't match because a new CI build is available
> * re-enable creation of sha256sum after a download (so that we don't have to create them every time we want to compare to a remote one
> * switch json to use nightly for CDK, vbox, jbds, so builds will use the latest CI
> * add cmdline flag to use the values in requirements.json vs. nightly latest CI, so it's easy to switch between a CI-based build and a statically-defined list of deps
> * add url-latest in requirements.json so that for requirements that have a CI or latest URL, we know where to pull the nightly; this would obviate the need to pass in the URLs via commandline, or to have to toggle between stable/staging and snapshot/CI every time we want to run one type of build or the other
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBDS-3872) rename JBoss perspective?
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBDS-3872?page=com.atlassian.jira.plugin.... ]
Alexey Kazakov commented on JBDS-3872:
--------------------------------------
Well, JBoss Perspective is very similar to Java perspective. So it has a set of views most useful for Java development such as Package Explorer etc. And yes, a major addition to this is a Server view. Which is not tied to JBoss server actually. This is a standard Eclipse view and you use it for whatever application server(s) you use (JBoss WildFly, EAP, Glassfish, Tomcat etc).
So I don't see anything 100% JBoss specific in the current perspective. But if we are focusing on container development then we probably want to create a new perspective (see JBDS-3846) for container oriented development. And we could use that new perspective by default in devstudio.
WDYT?
> rename JBoss perspective?
> -------------------------
>
> Key: JBDS-3872
> URL: https://issues.jboss.org/browse/JBDS-3872
> Project: Red Hat Developer Studio (DevStudio)
> Issue Type: Feature Request
> Components: build
> Affects Versions: 10.0.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Alexey Kazakov
> Fix For: 10.0.0.Alpha2
>
> Attachments: icon-titlebar-jbds10.png
>
>
> Should we rename the default perspective that opens OOTB in devstudio so it's not the "JBoss Perspective? Reason I ask is that it's the first word you see in the titlebar when you fire up DS for the first time:
> !icon-titlebar-jbds10.png!
> We're rebranding Central, the product, and everything in Devstudio. Should we also rename the JBoss perspective?
> cc: [~fbricon] [~akazakov]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBDS-3871) installer credentials misleading/incomplete information.
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3871?page=com.atlassian.jira.plugin.... ]
Denis Golovin updated JBDS-3871:
--------------------------------
Fix Version/s: 10.0.0.Alpha3
> installer credentials misleading/incomplete information.
> --------------------------------------------------------
>
> Key: JBDS-3871
> URL: https://issues.jboss.org/browse/JBDS-3871
> Project: Red Hat Developer Studio (DevStudio)
> Issue Type: Bug
> Components: platform-installer
> Affects Versions: 9.1.0.Beta1
> Environment: Win 7/64 bit
> Reporter: Robert Terzi
> Assignee: Denis Golovin
> Priority: Minor
> Fix For: 10.0.0.Alpha3
>
>
> There are several problems a with the information on the platform installer's login screen:
> # "Your developers.redhat.com credentials" is misleading, Should probably be "Your Red Hat username" to be consistent with RHDeveloper registration process.
> # The register link points to the login page, not the register page.
> # Registering on RHDevelopers isn't sufficient. (A registered user gets " Terms and Conditions for CDK have not been signed."
> # There should probably be a link to a page on RHDev with more info/FAQ about credentials, the registration process, and obtaining a (no-cost) subscription.
> The platform installer description of the credentials to use are misleading. Currently it says " Try it now by providing your developers.redhat.com credentials to get access."
> Users can log into RHDevelopers via other accounts (github, linkedin, stack overflow, etc. using OAUTH). They can not log into access.redhat.com (the customer portal) or other Red Hat sites with their developer.redhat.com "credentials".
> During registration on RHDevelopers, a simple developers account is created. (Note: At this point, a Red Hat username hasn't been created yet.
> Currently, when the user clicks a download link that goes through RHDev download manager, their account is "upgraded", which creates a Red Hat user than can be used to log into RHCP. Terms & conditions are presented. A no-cost RHEL Developer suite subscription is added to the user's Red Hat account.
> Their Red Hat username and password which could be different from the RHDeveloper credentials. They will need their Red Hat username for the CDK box to attach to their subscription. Without it the CDK box won't start up correctly as it can't download software.
> Some of this is covered for external users in the No-cost RHEL Dev. Suite FAQ. http://developers.redhat.com/articles/no-cost-rhel-faq/ We might need to do a version of that for CDK and JBDS platform installer..
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years