[JBoss JIRA] (JBIDE-25977) remove features from JBoss Tools which were deprecated in 4.5
by Nick Boldt (JIRA)
Nick Boldt created JBIDE-25977:
----------------------------------
Summary: remove features from JBoss Tools which were deprecated in 4.5
Key: JBIDE-25977
URL: https://issues.jboss.org/browse/JBIDE-25977
Project: Tools (JBoss Tools)
Issue Type: Task
Components: aerogear-hybrid, browsersim, cordovasim, livereload, portal-gatein
Affects Versions: 4.6.0.AM1
Reporter: Nick Boldt
In JBIDE-25736 we deprecated these projects:
* jbosstools-portlet
* jbosstools-aerogear
* jbosstools-browsersim
* jbosstools-livereload
So, in 4.6, we should remove them.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (JBIDE-25971) Add Red Hat Developers sign up link to CDK New Server wizard
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25971?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-25971:
---------------------------------------
{quote}
> And when you add the credentials you will see the domain there too, which is enough.
These two UIs use the same composite. If I hide the domain in one, it will hide it in the other.
{quote}
OK, so in that case remove both :)
{quote}
> Or once you click Add.. to add credentials.
The credentials framework doesn't have a registration portion of the API. I really don't think it'd be appropriate to add such things to the API now considering the current state of development and the future direction of the tools.
{quote}
OK, so it can be on the New Server wizard, i.e. somewhere close to the Add button. Or do you think it's a bad idea? You could say it's just more clutter. But isn't it a valid concern that a user may end up there without an account and it would be nice to provide a link? What do you think?
> Add Red Hat Developers sign up link to CDK New Server wizard
> ------------------------------------------------------------
>
> Key: JBIDE-25971
> URL: https://issues.jboss.org/browse/JBIDE-25971
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: cdk
> Affects Versions: 4.5.3.Final
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Attachments: new-server-cdk.png
>
>
> While reviewing documentation updates for cdk installation in devstudio, we noticed a thing that is not ideal in the workflow.
> Imagine you don't have an account on developers.redhat.com yet.
> You go to New Server -> CDK 3.2+.
> On the next page, you're supposed to fill out your credentials, but you don't have any. Yes, you could argue that there is a way to get there: If you don't have an account, that probably also means that you don't have a cdk binary either - you need the account to download it. So you need to click Download and install runtime... and that will offer you a link to register. So once cdk is downloaded, you can then add the credentials. But that's pretty cumbersome.
> So I would suggest we add a Register link somewhere - either on the New Server wizard's second page. Or once you click Add.. to add credentials.
> That's issue 1.
> !new-server-cdk.png!
> There are also a few side issues:
> 2. I would suggest you remove the Domain field/dropdown from the wizard. It's always just greyed out. If we ever want to support more of them we can add it back. And when you add the credentials you will see the domain there too, which is enough.
> 3. When you click Download and install runtime..., select a version and then go to the next page, this page is called JBoss.org Credentials - it's actually access.redhat.com credentials, can you change the title?
> 3.a Also, the link for signing up leads to access.redhat.com. Wouldn't it be better to point to developers.redhat.com sign up page? That's what devsuite installer does.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (JBDS-4690) Import Spring Starter Project shows error
by Josef Kopriva (JIRA)
[ https://issues.jboss.org/browse/JBDS-4690?page=com.atlassian.jira.plugin.... ]
Josef Kopriva closed JBDS-4690.
-------------------------------
Now it works without errors.
Verified in:
Red Hat JBoss Developer Studio
Version: 11.3.0.GA
Build id: GA-v20180413-0714-B2352
Build date: 20180413-0714
> Import Spring Starter Project shows error
> -----------------------------------------
>
> Key: JBDS-4690
> URL: https://issues.jboss.org/browse/JBDS-4690
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: 3rd-party-certification
> Affects Versions: 11.3.0.AM3
> Environment: F28
> +
> Red Hat JBoss Developer Studio
> Version: 11.3.0.AM3
> Build id: AM3-v20180322-1027-B2194
> Build date: 20180322-1027
> Reporter: Josef Kopriva
> Assignee: Nick Boldt
> Fix For: 11.3.0.GA
>
>
> {code:java}
> null
> org.springframework.ide.eclipse.beans.core
> Error
> Fri Mar 23 15:35:53 CET 2018
> Problems occurred when invoking code from plug-in: "org.springframework.ide.eclipse.beans.core".
> java.lang.NoSuchMethodError: org.springframework.util.Assert.state(ZLjava/util/function/Supplier;)V
> at org.springframework.boot.autoconfigure.cache.CacheConfigurations.getConfigurationClass(CacheConfigurations.java:55)
> at org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration$CacheConfigurationImportSelector.selectImports(CacheAutoConfiguration.java:169)
> at org.springframework.context.annotation.ConfigurationClassParser.processImports(ConfigurationClassParser.java:517)
> at org.springframework.context.annotation.ConfigurationClassParser.doProcessConfigurationClass(ConfigurationClassParser.java:286)
> at org.springframework.context.annotation.ConfigurationClassParser.processConfigurationClass(ConfigurationClassParser.java:237)
> at org.springframework.context.annotation.ConfigurationClassParser.processImports(ConfigurationClassParser.java:536)
> at org.springframework.context.annotation.ConfigurationClassParser.processDeferredImportSelectors(ConfigurationClassParser.java:481)
> at org.springframework.context.annotation.ConfigurationClassParser.parse(ConfigurationClassParser.java:191)
> at org.springframework.context.annotation.ConfigurationClassPostProcessor.processConfigBeanDefinitions(ConfigurationClassPostProcessor.java:321)
> at org.springframework.ide.eclipse.metadata.process.JdtConfigurationClassPostProcessor.postProcess(JdtConfigurationClassPostProcessor.java:88)
> at org.springframework.ide.eclipse.beans.core.internal.model.BeansJavaConfig$3.run(BeansJavaConfig.java:332)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.springframework.ide.eclipse.beans.core.internal.model.BeansJavaConfig.executePostProcessor(BeansJavaConfig.java:321)
> at org.springframework.ide.eclipse.beans.core.internal.model.BeansJavaConfig.access$5(BeansJavaConfig.java:319)
> at org.springframework.ide.eclipse.beans.core.internal.model.BeansJavaConfig$2.call(BeansJavaConfig.java:233)
> at org.springframework.ide.eclipse.beans.core.internal.model.BeansJavaConfig$2.call(BeansJavaConfig.java:1)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months