[JBoss JIRA] (FORGEPLUGINS-133) Arquillian Forge plugin installation fails on Forge 1.3.3.FINAL
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGEPLUGINS-133?page=com.atlassian.jira.... ]
George Gastaldi closed FORGEPLUGINS-133.
----------------------------------------
Resolution: Cannot Reproduce Bug
We couldn't reproduce the bug, probably fixed in a later version
> Arquillian Forge plugin installation fails on Forge 1.3.3.FINAL
> ---------------------------------------------------------------
>
> Key: FORGEPLUGINS-133
> URL: https://issues.jboss.org/browse/FORGEPLUGINS-133
> Project: Forge Plugins
> Issue Type: Bug
> Components: Arquillian Plugin
> Environment: Forge 1.3.3.Final
> Reporter: Vineet Reynolds
> Assignee: Aslak Knutsen
>
> Cloned from : https://github.com/forge/plugin-arquillian/issues/31
> Plugin install fails with forge 1.3.3.FINAL. I am trying to follow the arquillian tutorial.
> {noformat}
> forge install-plugin arquillian
> Connecting to remote repository [https://raw.github.com/forge/plugin-repository/master/repository.yaml]... connected!
> ***INFO*** Preparing to install plugin: arquillian
> ***INFO*** Checking out plugin source files to [/tmp/forgetemp2717179280024408314] via 'git'
> ***INFO*** Switching to branch/tag [refs/heads/1.0.6.Final]
> ***INFO*** Project found
> ***INFO*** Name: arquillian-plugin
> ***INFO*** Version: 1.0.0-SNAPSHOT
> ***INFO*** Type: Java Application
> ? The project does not appear to be a Forge Plugin Project, install anyway? [y/N] y
> ***INFO*** Project found
> ***INFO*** Name: arquillian-demo
> ***INFO*** Version: 1.0.0-SNAPSHOT
> ***INFO*** Type: Java Application
> ***INFO*** Cleaning up temp workspace [/tmp/forgetemp2717179280024408314]
> Wrote /home/dbeer/.forge/httpsrawgithubcomforgepluginrepositorymasterrepositoryyaml.yaml
> Deleted /tmp/forgetemp2717179280024408314
> ***ERROR*** Exception encountered: (type "set VERBOSE false" to disable stack traces)
> java.lang.NullPointerException
> at org.jboss.forge.shell.plugins.builtin.ForgePlugin.buildFromCurrentProject(ForgePlugin.java:625)
> at org.jboss.forge.shell.plugins.builtin.ForgePlugin.installFromGit(ForgePlugin.java:414)
> at org.jboss.forge.shell.plugins.builtin.ForgePlugin.installFromIndex(ForgePlugin.java:233)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.forge.shell.command.Execution.perform(Execution.java:160)
> at org.jboss.forge.shell.command.fshparser.FSHRuntime.run(FSHRuntime.java:109)
> at org.jboss.forge.shell.command.fshparser.FSHRuntime.run(FSHRuntime.java:47)
> at org.jboss.forge.shell.ShellImpl$ExecutorThread.run(ShellImpl.java:795)
> at org.jboss.forge.shell.ShellImpl.execute(ShellImpl.java:818)
> at org.jboss.forge.shell.ShellImpl.doShell(ShellImpl.java:608)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.weld.bean.proxy.AbstractBeanInstance.invoke(AbstractBeanInstance.java:48)
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:125)
> at org.jboss.forge.shell.ShellImpl$Proxy$_$$_WeldClientProxy.doShell(ShellImpl$Proxy$_$$_WeldClientProxy.java)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305)
> at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54)
> at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163)
> at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299)
> at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188)
> at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59)
> at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:198)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:282)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:265)
> at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:234)
> at org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:635)
> at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:622)
> at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:616)
> at org.jboss.forge.shell.Bootstrap$1.run(Bootstrap.java:186)
> at java.lang.Thread.run(Thread.java:724)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (FORGEPLUGINS-64) Getting Started Experience
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGEPLUGINS-64?page=com.atlassian.jira.p... ]
George Gastaldi closed FORGEPLUGINS-64.
---------------------------------------
Resolution: Out of Date
Already fixed for some time in Forge 1.x
> Getting Started Experience
> --------------------------
>
> Key: FORGEPLUGINS-64
> URL: https://issues.jboss.org/browse/FORGEPLUGINS-64
> Project: Forge Plugins
> Issue Type: Feature Request
> Environment: JBoss Tools 3.3.M4
> Reporter: Burr Sutter
> Assignee: Mike Brock
> Labels: eap6-ux
> Attachments: Forge_JBossTools-2.png, new_project_while_in_project.png
>
>
> I typed in "new project" into the prompt and received an ugly error message
> [no project] workspace_eclipse-jee-indigo-win32_3.3_M4 $ new project
> ***ERROR*** Exception encountered: 11 (type "set VERBOSE true" to enable stack traces)
> [no project] workspace_eclipse-jee-indigo-win32_3.3_M4 $
> 1) This error message is too hideous for average users
> 2) Forge should know what I mean by 'new project' and provide some assistance
> 3) My workaround was to type in "help"
> which displayed
> Welcome to Seam Forge, a next-generation interactive Shell and project-generation tool. If you find yourself lost, or uncertain how to complete an operation, you may press the <TAB> key for command-completion, or <TAB><TAB> for hints while typing a command.
> Type 'list-commands' for a list of available commands in the current Resource context.
> You are not working on a project. Type 'help new-project' to get started.
> 4) Again, help should know that I have not yet created a project and the piece of information I need is at the bottom of the listing - many users will not read that far.
> 5) Now I realize that the command is "new-project" with a dash in the middle.
> Attached is a screenshot of what it looks like in JBoss Tools 3.3.M4
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (FORGE-944) Thoughts on CLI renaming on Forge 2
by Antonio Goncalves (JIRA)
[ https://issues.jboss.org/browse/FORGE-944?page=com.atlassian.jira.plugin.... ]
Antonio Goncalves commented on FORGE-944:
-----------------------------------------
[~lincolnthree] mentioned on : https://community.jboss.org/message/843635#843635
{quote}
So far, our command style is following this basic premise:
jpa-new-entity (instead of entity --named)
jpa-new-embedable
jpa-new-mapped-superclass --named Person
jpa-new-entity --named Vet --extends Person
(spec alias or acronym)-new-(something)
(spec alias or acronym)-(something)-from-(something else)
We have a dilemma with faces and CDI, though. Should we call them 'faces' and 'rest' or "jsf" and "jaxrs", since we already have "jpa" "ejb" etc. I think JAX-RS is the real issue, because most people know it as REST.
{quote}
Today, most of the commands follow the proposed pattern, except for JAX-RS (rest), JAX-WS (soap), JPA (entity, persistence, field), JASF (faces) and Bean Validation (constraint, validation) . So to make it more explicit in some edges, here is what we have now and what could happen
|| Specification || Today's commands || Tomorow's commands ? ||
| CDI | beans | beans |
| Bean Validation | constraint, validation | constraint |
| EJB | ejb | ejb |
| JSF | faces | jsf |
| JPA | field, persistence, entity | jpa |
| JMS | jms | jms |
| JTA | jta | jta |
| JAX-RS | rest | rest |
| Servlet | servlet | servlet |
| JAX-WS | soap | soap |
And some other might come in the future such as Batch...
> Thoughts on CLI renaming on Forge 2
> -----------------------------------
>
> Key: FORGE-944
> URL: https://issues.jboss.org/browse/FORGE-944
> Project: Forge
> Issue Type: Enhancement
> Components: Brainstorming
> Affects Versions: 2.x Future
> Reporter: Antonio Goncalves
> Priority: Optional
> Labels: cli, renaming
> Fix For: 2.x Future
>
>
> I was talking about having CLI naming conventions on the forum and George and Lincoln suggested to add these ideas on a JIRA. So here is my humble contribution to record all the ideas about renaming commands.
> Disclaimer : I haven't used Forge for a long time, I've just started using it again, so some of the following ideas might not be accurate
> As a new comer in Forge I felt the commands were not that intuitive. I loved the following :
> {code}
> java new-enum-type
> java new-itnerface
> java new-class
> {code}
>
> So I was expecting to have something similar in all the other techologies, such as JPA :
> {code}
> jpa new-entity (instead of entity --named)
> jpa new-embedable
> jpa new-mapped-superclass --named Person
> jpa new-entity --named Vet --extends Person
> {code}
> Lincoln suggested having single-level command keywords only such as :
> {code}
> jpa-new-entity (instead of entity --named)
> jpa-new-embedable
> jpa-new-mapped-superclass --named Person
> jpa-new-entity --named Vet --extends Person
> {code}
> h3. Verbs and keywords
> When you look at the commansd, there are several common verbs and keywords than come often :
> {code}
> add : ejb-add-transaction-attribute
> new : beans-new-bean, faces-new-view, new-project (prefer project-new)
> list : list-web-resources, beans list-interceptors, beans list-alternatives, list-scaffold-providers
> setup : ejb setup, entity setup
> put : i18n put
> remove : i18n remove, project remove-property
> execute : execute-java
> set : maven set-groupid
> find : forge find-plugin
> install :
> update : forge update-abort, gitignore update-repo
> run : run-url
> info : analytics info
> {code}
> That brings several thoughts :
> * {{ls}} is used as well as {{list}}, should this be homogenize (e.g. beans-ls-interceptors)
> * {{rm}} is used as well as {{remove}}, should this be homogenize (e.g. i18n-rm, project-rm-property)
> * The difference between {{execute}} and {{run}} is not clear, should this be homogenize and only use one ?
> * Also there is {{execute}} and {{exec}}, this should be homogenize (e.g. {{execute-java}} and {{exec}})
> * Confusion between {{new}} and {{add}}. You create a new class with {{java-new-class}} and shouldn't you add a field and a method to existing class ({{java-add-field}} instead of {{java-new-field}})
> * Some confusion between {{maven}} and {{project}}
> * Is there any difference between {{set}} and {{update}} ? {{maven set-artifactid}} updates the already existing artifactId and {{gitignore update-repo}} updates an existing repo
> * we use {{field}} (e.g. {{java-add-field}}) and then property ({{constraint Future --onProperty date}}), it should be fiels ({{constraint Future --onField date}})
> In many commands you find a type argument such as ({{type}}, {{scaffoldType}}, {{fieldType}} :
> {code}
> scaffold setup --scaffoldType faces
> field manyToMany --named specialties --fieldType ~.model.Specialty.java
> field temporal --type DATE --named date
> {code}
> Why not having only {{type}} in all the cases :
> {code}
> scaffold-setup --type faces
> jpa-add-field manyToMany --named specialties --type ~.model.Specialty.java
> jpa-add-field temporal --named date --type DATE
> {code}
> h3. Grammar
> The CLI grammar could look like this :
> {code}
> command = shell | forge command ;
> forge command = technology,-action,[-artifact] [{--argument value}] ;
> shell = cat | cd | cp | edit | find | grep | ls ...
> technology = project | scaffold | beans | constraint | java | jpa | i18n | ejb ...
> action = add | new | ls | rm | setup ...
> artifact = providers | interceptors | class | filter...
> argument = named | onField | type | extends
> {code}
> h3. Examples
> So if we take that grammar and apply single-level command keywords, we could have things like that :
> {code}
> mkdir
> ls
> ls-commands -all
> project-new --named MyPro
> scaffold-ls-providers
> scaffold-templates --scaffoldType faces
> beans-ls-interceptors
> constraint-new-constraint --named MyConstraint
> constraint-add-constraint MyConstraint --onField MyProp
> java-new-class --named MyClass
> java-add-field 'private List<Vet> vets'
> java-add-method 'public List<Vet> getVetList() {return null;}'
> java-add-annotation --type XmlRootElement --onClass MyClass
> java-add-annotation --type XmlAttribute --onField MyProp
> jpa-new-mapped-superclass --named Person
> jpa-new-entity --named Vet --extends Person
> jpa-add-field manyToOne --named owner --type ~.model.Owner.java
> i18n-add-locale --locale PT
> ejb-new-stateless --named MyStateless
> ejb-new-singleton --named MySingleton --implements MyInterface AndAnotherInterface
> ejb-add-transaction-attribute --type NEVER
> ejb-add-transaction-attribute --type NEVER --onMethod MyNeverMethod
> faces-new-view --named MyView
> faces-set-project-stage --stage PRODUCTION
> servlet-new-filter --named MyFilter
> rest-new-endpoint --named MyEndpoint --extends MyRestExtension
> mvn-build --notest
> {code}
> Scaffolding is a bit tricky because it's extendable and you could end up with
> {code}
> scaffold-ui-from-entity ~.model.*
> scaffold-rest-endpoint-from-entity ~.model.*
> scaffold-dao-from-entity ~.model.*
> scaffold-ejb-service-from-dao ~.dao.*
> scaffold-rest-endpoint-from-dao ~.dao.*
> {code}
> Or something like that
> {code}
> scaffold --ui --from-entity ~.model.*
> scaffold --rest-endpoint --from-entity ~.model.*
> scaffold --dao --from-entity ~.model.*
> scaffold --ejb-service --from-dao ~.dao.*
> scaffold --rest-endpoint --from-dao ~.dao.*
> {code}
> Here are my 2 cents thoughts on a topic that I'm discovering. As you all know, naming is really important and should be looked at carefully. Let's use this JIRA to exchange ideas.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (FORGE-1296) Allow constraints to be specified on the versions of the Facets during setup
by Vineet Reynolds (JIRA)
Vineet Reynolds created FORGE-1296:
--------------------------------------
Summary: Allow constraints to be specified on the versions of the Facets during setup
Key: FORGE-1296
URL: https://issues.jboss.org/browse/FORGE-1296
Project: Forge
Issue Type: Feature Request
Components: UI - API
Affects Versions: 2.0.0.Alpha14
Reporter: Vineet Reynolds
The current implementation of the Scaffold and possibly other addons, verifies if facets are setup and then proceeds to add the wizards for these facets to the NavigationResult.
It is possible that some of the versions displayed in the individual wizards will not be applicable when used in a composite wizard like the scaffold. We need to find a way for the composite to hint or specify the allowed versions of the individual facets.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (FORGEPLUGINS-148) Got java runtime exception "unknow request parameter type integer" when run rhc setup in forge shell
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGEPLUGINS-148?page=com.atlassian.jira.... ]
George Gastaldi updated FORGEPLUGINS-148:
-----------------------------------------
Component/s: OpenShift Plugin
> Got java runtime exception "unknow request parameter type integer" when run rhc setup in forge shell
> ----------------------------------------------------------------------------------------------------
>
> Key: FORGEPLUGINS-148
> URL: https://issues.jboss.org/browse/FORGEPLUGINS-148
> Project: Forge Plugins
> Issue Type: Bug
> Components: OpenShift Plugin
> Environment: JDK 1.7.0_45 & git 1.8.0
> windows 7& fedora 19
> Reporter: weiweijiang jiang
> Priority: Blocker
>
> when rhc setup in forge shell, it got java runtime error message "unknow request parameter type integer".
> And according to https://bugzilla.redhat.com/show_bug.cgi?id=1020283#c1 the issue has been fixed in client version pre-2.4.0, but the forge-plugin-openshift still use client version 2.0.1
> [no project] forge-distribution-1.4.2.Final $ forge find-plugin openshift
> Connecting to remote repository [https://raw.github.com/forge/plugin-repository/
> master/repository.yaml]... connected!
> - openshift (com.redhat.openshift:forge-openshift-plugin:::)
> Author: Pete Muir <pmuir(a)redhat.com>
> Website: http://openshift.com
> Location: https://github.com/forge/plugin-openshift.git
> Tags: cloud, openshift, redhat, jboss, deploy, rhc
> Description: Plugins for creating cloud instances, managing existing clo
> uds, and deploying applications to the Red Hat express cloud.
> And the following is https://raw.github.com/forge/plugin-openshift/master/pom.xml
> <?xml version="1.0" encoding="UTF-8"?>
> <project
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"
> xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> <modelVersion>4.0.0</modelVersion>
> <groupId>com.redhat.openshift</groupId>
> <artifactId>forge-openshift-plugin</artifactId>
> <version>1.0.6.Final</version>
> <properties>
> <forge.api.version>1.0.6.Final</forge.api.version>
> <jgit.version>2.0.0.201206130900-r</jgit.version>
> <log4j.extras.version>1.1</log4j.extras.version>
> <openshift.client.version>2.0.1</openshift.client.version>
> <jsch.version>0.1.48</jsch.version>
> </properties>
> ...
> <build>
> <finalName>forge-openshift-plugin</finalName>
> <plugins>
> <plugin>
> <artifactId>maven-compiler-plugin</artifactId>
> <version>2.3.2</version>
> <configuration>
> <source>1.6</source>
> <target>1.6</target>
> </configuration>
> </plugin>
> </plugins>
> </build>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (FORGEPLUGINS-148) Got java runtime exception "unknow request parameter type integer" when run rhc setup in forge shell
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGEPLUGINS-148?page=com.atlassian.jira.... ]
George Gastaldi moved FORGE-1295 to FORGEPLUGINS-148:
-----------------------------------------------------
Project: Forge Plugins (was: Forge)
Key: FORGEPLUGINS-148 (was: FORGE-1295)
Affects Version/s: (was: 1.4.1.Final)
(was: 1.4.2.Final)
> Got java runtime exception "unknow request parameter type integer" when run rhc setup in forge shell
> ----------------------------------------------------------------------------------------------------
>
> Key: FORGEPLUGINS-148
> URL: https://issues.jboss.org/browse/FORGEPLUGINS-148
> Project: Forge Plugins
> Issue Type: Bug
> Environment: JDK 1.7.0_45 & git 1.8.0
> windows 7& fedora 19
> Reporter: weiweijiang jiang
> Priority: Blocker
>
> when rhc setup in forge shell, it got java runtime error message "unknow request parameter type integer".
> And according to https://bugzilla.redhat.com/show_bug.cgi?id=1020283#c1 the issue has been fixed in client version pre-2.4.0, but the forge-plugin-openshift still use client version 2.0.1
> [no project] forge-distribution-1.4.2.Final $ forge find-plugin openshift
> Connecting to remote repository [https://raw.github.com/forge/plugin-repository/
> master/repository.yaml]... connected!
> - openshift (com.redhat.openshift:forge-openshift-plugin:::)
> Author: Pete Muir <pmuir(a)redhat.com>
> Website: http://openshift.com
> Location: https://github.com/forge/plugin-openshift.git
> Tags: cloud, openshift, redhat, jboss, deploy, rhc
> Description: Plugins for creating cloud instances, managing existing clo
> uds, and deploying applications to the Red Hat express cloud.
> And the following is https://raw.github.com/forge/plugin-openshift/master/pom.xml
> <?xml version="1.0" encoding="UTF-8"?>
> <project
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"
> xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> <modelVersion>4.0.0</modelVersion>
> <groupId>com.redhat.openshift</groupId>
> <artifactId>forge-openshift-plugin</artifactId>
> <version>1.0.6.Final</version>
> <properties>
> <forge.api.version>1.0.6.Final</forge.api.version>
> <jgit.version>2.0.0.201206130900-r</jgit.version>
> <log4j.extras.version>1.1</log4j.extras.version>
> <openshift.client.version>2.0.1</openshift.client.version>
> <jsch.version>0.1.48</jsch.version>
> </properties>
> ...
> <build>
> <finalName>forge-openshift-plugin</finalName>
> <plugins>
> <plugin>
> <artifactId>maven-compiler-plugin</artifactId>
> <version>2.3.2</version>
> <configuration>
> <source>1.6</source>
> <target>1.6</target>
> </configuration>
> </plugin>
> </plugins>
> </build>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (FORGE-1295) Got java runtime exception "unknow request parameter type integer" when run rhc setup in forge shell
by weiweijiang jiang (JIRA)
weiweijiang jiang created FORGE-1295:
----------------------------------------
Summary: Got java runtime exception "unknow request parameter type integer" when run rhc setup in forge shell
Key: FORGE-1295
URL: https://issues.jboss.org/browse/FORGE-1295
Project: Forge
Issue Type: Bug
Affects Versions: 1.4.2.Final, 1.4.1.Final
Environment: JDK 1.7.0_45 & git 1.8.0
windows 7& fedora 19
Reporter: weiweijiang jiang
Priority: Blocker
when rhc setup in forge shell, it got java runtime error message "unknow request parameter type integer".
And according to https://bugzilla.redhat.com/show_bug.cgi?id=1020283#c1 the issue has been fixed in client version pre-2.4.0, but the forge-plugin-openshift still use client version 2.0.1
[no project] forge-distribution-1.4.2.Final $ forge find-plugin openshift
Connecting to remote repository [https://raw.github.com/forge/plugin-repository/
master/repository.yaml]... connected!
- openshift (com.redhat.openshift:forge-openshift-plugin:::)
Author: Pete Muir <pmuir(a)redhat.com>
Website: http://openshift.com
Location: https://github.com/forge/plugin-openshift.git
Tags: cloud, openshift, redhat, jboss, deploy, rhc
Description: Plugins for creating cloud instances, managing existing clo
uds, and deploying applications to the Red Hat express cloud.
And the following is https://raw.github.com/forge/plugin-openshift/master/pom.xml
<?xml version="1.0" encoding="UTF-8"?>
<project
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"
xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>
<groupId>com.redhat.openshift</groupId>
<artifactId>forge-openshift-plugin</artifactId>
<version>1.0.6.Final</version>
<properties>
<forge.api.version>1.0.6.Final</forge.api.version>
<jgit.version>2.0.0.201206130900-r</jgit.version>
<log4j.extras.version>1.1</log4j.extras.version>
<openshift.client.version>2.0.1</openshift.client.version>
<jsch.version>0.1.48</jsch.version>
</properties>
...
<build>
<finalName>forge-openshift-plugin</finalName>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
</configuration>
</plugin>
</plugins>
</build>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months