[JBoss JIRA] (JBIDE-15463) Increment version's service part for jbosstools-base/foundation submodule
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15463?page=com.atlassian.jira.plugi... ]
Denis Golovin updated JBIDE-15463:
----------------------------------
Affects Version/s: (was: 4.1.1.Alpha2)
> Increment version's service part for jbosstools-base/foundation submodule
> -------------------------------------------------------------------------
>
> Key: JBIDE-15463
> URL: https://issues.jboss.org/browse/JBIDE-15463
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: common/jst/core
> Affects Versions: 4.1.1.Alpha1
> Reporter: Denis Golovin
> Assignee: Denis Golovin
> Priority: Blocker
> Fix For: 4.1.1.Alpha1
>
>
> jbosstools-base/foundation submodule had changes since 4.1.0.Final is released:
> {code}$ git diff --name-only jbosstools-4.1.0.Final -- foundation
> foundation/plugins/org.jboss.tools.foundation.core/.options
> foundation/plugins/org.jboss.tools.foundation.core/src/org/jboss/tools/foundation/core/Trace.java
> foundation/plugins/org.jboss.tools.foundation.core/src/org/jboss/tools/foundation/core/ecf/internal/InternalURLTransport.java
> foundation/plugins/org.jboss.tools.foundation.core/src/org/jboss/tools/foundation/core/ecf/internal/URLTransportCache.java
> foundation/plugins/org.jboss.tools.foundation.core/src/org/jboss/tools/foundation/core/jobs/BarrierProgressWaitJob.java
> foundation/plugins/org.jboss.tools.foundation.core/src/org/jboss/tools/foundation/core/jobs/BarrierWaitJob.java
> foundation/plugins/org.jboss.tools.foundation.core/src/org/jboss/tools/foundation/core/jobs/InterruptableJoinJob.java
> foundation/pom.xml{code}
> No changes in Public API so far and hat means only service version should be incremented:
> 1.0.0-SNAPSHOT => 1.0.1-SNAPSHOT
--
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
12 years, 7 months
[JBoss JIRA] (JBIDE-14828) OpenShift application/import wizard: if git clone directory already exist i cannot do anything
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14828?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-14828:
-------------------------------------
Fix Version/s: 4.2.0.Alpha1
(was: 4.2.x)
> OpenShift application/import wizard: if git clone directory already exist i cannot do anything
> ----------------------------------------------------------------------------------------------
>
> Key: JBIDE-14828
> URL: https://issues.jboss.org/browse/JBIDE-14828
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.1.0.Beta2
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Fix For: 4.2.0.Alpha1
>
> Attachments: application-folder-already-exists.png
>
>
> steps to reproduce:
> # EXEC: create and/or import some appliaction from OpenShift to your local workspace using the application/import wizard
> # EXEC: once you have the project imported to your workspace, delete it
> # EXEC: once it is deleted, go and try to re-import the very same application
> Result:
> The 3rd wizard page errors on the git cloning destination. You're told that the destination folder already exists within the clone destination folder. The only way out currently is to choose a different clone destination folder.
> !application-folder-already-exists.png!
> Expected:
> It would help a lot if wizard would allow you to overwrite the existing destination. The wizard could also check if the given folder holds a prior clone and then allow one to "reuse" this folder. The given folder would then simply get imported to Eclipse and we'd fetch instead of cloning.
--
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
12 years, 7 months
[JBoss JIRA] (JBIDE-15399) openshift-java-client: dont fail on unknown link-type
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15399?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-15399:
------------------------------------------
openshift bot merged the PR into master
> openshift-java-client: dont fail on unknown link-type
> -----------------------------------------------------
>
> Key: JBIDE-15399
> URL: https://issues.jboss.org/browse/JBIDE-15399
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.1.0.Final
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Labels: openshift-java-client
>
> When unmarshalling responses from the server there are among other objects links that shall get created. Links look like the following:
> {code}
> "links":{
> "UPDATE":{
> "href":"/domains/foobar",
> "optional_params":[
>
> ],
> "required_params":[
> {
> "name":"id",
> "valid_options":[
>
> ],
> "description":"Name of the domain",
> "type":"string"
> }
> ],
> "method":"PUT",
> "rel":"Update domain"
> ...
> {code}
> The unmarshalling code currently turns the "type" property into an enum. If the type that's provided is not known, then an exception is thrown:
> {code}
> public enum LinkParameterType {
> STRING, BOOLEAN, INTEGER, ARRAY;
>
> public static LinkParameterType valueOfIgnoreCase(String name) throws OpenShiftRequestException {
> if (name == null) {
> // no type provided (this is valid, not an error)
> return null;
> }
> try {
> return valueOf(name.toUpperCase());
> } catch(IllegalArgumentException e) {
> throw new OpenShiftRequestException("Unknow request parameter type {0}", name);
> }
> }
> {code}
> This is not a good approach. The client library should be tolerant, it should ignore things it doesn't know to ensure it works with future responses. This is even more true as responses evolve over time even in the same protocol version: OpenShift is backporting new features (additions only) to old protocols!
--
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
12 years, 7 months
[JBoss JIRA] (JBIDE-15399) openshift-java-client: dont fail on unknown link-type
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15399?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-15399:
------------------------------------------
filed a PR for openshift-java-client 2.4.0: https://github.com/openshift/openshift-java-client/pull/71
> openshift-java-client: dont fail on unknown link-type
> -----------------------------------------------------
>
> Key: JBIDE-15399
> URL: https://issues.jboss.org/browse/JBIDE-15399
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.1.0.Final
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Labels: openshift-java-client
>
> When unmarshalling responses from the server there are among other objects links that shall get created. Links look like the following:
> {code}
> "links":{
> "UPDATE":{
> "href":"/domains/foobar",
> "optional_params":[
>
> ],
> "required_params":[
> {
> "name":"id",
> "valid_options":[
>
> ],
> "description":"Name of the domain",
> "type":"string"
> }
> ],
> "method":"PUT",
> "rel":"Update domain"
> ...
> {code}
> The unmarshalling code currently turns the "type" property into an enum. If the type that's provided is not known, then an exception is thrown:
> {code}
> public enum LinkParameterType {
> STRING, BOOLEAN, INTEGER, ARRAY;
>
> public static LinkParameterType valueOfIgnoreCase(String name) throws OpenShiftRequestException {
> if (name == null) {
> // no type provided (this is valid, not an error)
> return null;
> }
> try {
> return valueOf(name.toUpperCase());
> } catch(IllegalArgumentException e) {
> throw new OpenShiftRequestException("Unknow request parameter type {0}", name);
> }
> }
> {code}
> This is not a good approach. The client library should be tolerant, it should ignore things it doesn't know to ensure it works with future responses. This is even more true as responses evolve over time even in the same protocol version: OpenShift is backporting new features (additions only) to old protocols!
--
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
12 years, 7 months
[JBoss JIRA] (JBIDE-15463) Increment version's service part for jbosstools-base/foundation submodule
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15463?page=com.atlassian.jira.plugi... ]
Denis Golovin updated JBIDE-15463:
----------------------------------
Git Pull Request: https://github.com/jbosstools/jbosstools-base/pull/182, https://github.com/jbosstools/jbosstools-base/pull/183 (was: https://github.com/jbosstools/jbosstools-base/pull/182)
> Increment version's service part for jbosstools-base/foundation submodule
> -------------------------------------------------------------------------
>
> Key: JBIDE-15463
> URL: https://issues.jboss.org/browse/JBIDE-15463
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: common/jst/core
> Affects Versions: 4.1.1.Alpha1, 4.1.1.Alpha2
> Reporter: Denis Golovin
> Priority: Blocker
>
> jbosstools-base/foundation submodule had changes since 4.1.0.Final is released:
> {code}$ git diff --name-only jbosstools-4.1.0.Final -- foundation
> foundation/plugins/org.jboss.tools.foundation.core/.options
> foundation/plugins/org.jboss.tools.foundation.core/src/org/jboss/tools/foundation/core/Trace.java
> foundation/plugins/org.jboss.tools.foundation.core/src/org/jboss/tools/foundation/core/ecf/internal/InternalURLTransport.java
> foundation/plugins/org.jboss.tools.foundation.core/src/org/jboss/tools/foundation/core/ecf/internal/URLTransportCache.java
> foundation/plugins/org.jboss.tools.foundation.core/src/org/jboss/tools/foundation/core/jobs/BarrierProgressWaitJob.java
> foundation/plugins/org.jboss.tools.foundation.core/src/org/jboss/tools/foundation/core/jobs/BarrierWaitJob.java
> foundation/plugins/org.jboss.tools.foundation.core/src/org/jboss/tools/foundation/core/jobs/InterruptableJoinJob.java
> foundation/pom.xml{code}
> No changes in Public API so far and hat means only service version should be incremented:
> 1.0.0-SNAPSHOT => 1.0.1-SNAPSHOT
--
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
12 years, 7 months
[JBoss JIRA] (JBIDE-15463) Increment version's service part for jbosstools-base/foundation submodule
by Denis Golovin (JIRA)
Denis Golovin created JBIDE-15463:
-------------------------------------
Summary: Increment version's service part for jbosstools-base/foundation submodule
Key: JBIDE-15463
URL: https://issues.jboss.org/browse/JBIDE-15463
Project: Tools (JBoss Tools)
Issue Type: Task
Components: common/jst/core
Affects Versions: 4.1.1.Alpha1, 4.1.1.Alpha2
Reporter: Denis Golovin
jbosstools-base/foundation submodule had changes since 4.1.0.Final is released:
{code}$ git diff --name-only jbosstools-4.1.0.Final -- foundation
foundation/plugins/org.jboss.tools.foundation.core/.options
foundation/plugins/org.jboss.tools.foundation.core/src/org/jboss/tools/foundation/core/Trace.java
foundation/plugins/org.jboss.tools.foundation.core/src/org/jboss/tools/foundation/core/ecf/internal/InternalURLTransport.java
foundation/plugins/org.jboss.tools.foundation.core/src/org/jboss/tools/foundation/core/ecf/internal/URLTransportCache.java
foundation/plugins/org.jboss.tools.foundation.core/src/org/jboss/tools/foundation/core/jobs/BarrierProgressWaitJob.java
foundation/plugins/org.jboss.tools.foundation.core/src/org/jboss/tools/foundation/core/jobs/BarrierWaitJob.java
foundation/plugins/org.jboss.tools.foundation.core/src/org/jboss/tools/foundation/core/jobs/InterruptableJoinJob.java
foundation/pom.xml{code}
No changes in Public API so far and hat means only service version should be incremented:
1.0.0-SNAPSHOT => 1.0.1-SNAPSHOT
--
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
12 years, 7 months
[JBoss JIRA] (JBIDE-15463) Increment version's service part for jbosstools-base/foundation submodule
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15463?page=com.atlassian.jira.plugi... ]
Denis Golovin updated JBIDE-15463:
----------------------------------
Priority: Blocker (was: Major)
> Increment version's service part for jbosstools-base/foundation submodule
> -------------------------------------------------------------------------
>
> Key: JBIDE-15463
> URL: https://issues.jboss.org/browse/JBIDE-15463
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: common/jst/core
> Affects Versions: 4.1.1.Alpha1, 4.1.1.Alpha2
> Reporter: Denis Golovin
> Priority: Blocker
>
> jbosstools-base/foundation submodule had changes since 4.1.0.Final is released:
> {code}$ git diff --name-only jbosstools-4.1.0.Final -- foundation
> foundation/plugins/org.jboss.tools.foundation.core/.options
> foundation/plugins/org.jboss.tools.foundation.core/src/org/jboss/tools/foundation/core/Trace.java
> foundation/plugins/org.jboss.tools.foundation.core/src/org/jboss/tools/foundation/core/ecf/internal/InternalURLTransport.java
> foundation/plugins/org.jboss.tools.foundation.core/src/org/jboss/tools/foundation/core/ecf/internal/URLTransportCache.java
> foundation/plugins/org.jboss.tools.foundation.core/src/org/jboss/tools/foundation/core/jobs/BarrierProgressWaitJob.java
> foundation/plugins/org.jboss.tools.foundation.core/src/org/jboss/tools/foundation/core/jobs/BarrierWaitJob.java
> foundation/plugins/org.jboss.tools.foundation.core/src/org/jboss/tools/foundation/core/jobs/InterruptableJoinJob.java
> foundation/pom.xml{code}
> No changes in Public API so far and hat means only service version should be incremented:
> 1.0.0-SNAPSHOT => 1.0.1-SNAPSHOT
--
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
12 years, 7 months
[JBoss JIRA] (JBIDE-15160) support comparing bundle folders as well as bundle jars when comparing MD5 sums
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15160?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-15160 at 9/6/13 11:07 AM:
-------------------------------------------------------------
Appears to be working:
{code:title=https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevStudio_Trunk/job/devstudio.versionwatch_71/36/console}
457581 [main] WARN org.jboss.tools.vwatch.service.EvaluationService - Bundle org.jboss.tools.central.themes.feature is a folder; must jar it to compare MD5 sums.
{code}
Also getting some errors:
{code}
Running org.jboss.tools.vwatch.VersionTest
0 [main] ERROR org.jboss.tools.vwatch.service.EvaluationService - ERROR - Bundle org.hibernate.eclipse.console3.4.1 in 5.0.0 must be >= to version in 4.1.3
2 [main] ERROR org.jboss.tools.vwatch.service.EvaluationService - ERROR - Bundle org.hibernate.eclipse3.4.1 in 5.0.0 must be >= to version in 4.1.3
14 [main] ERROR org.jboss.tools.vwatch.service.EvaluationService - ERROR - Bundle org.hibernate.eclipse.jdt.ui3.4.1 in 5.0.0 must be >= to version in 4.1.3
14 [main] ERROR org.jboss.tools.vwatch.service.EvaluationService - ERROR - Bundle org.hibernate.eclipse.mapper3.4.1 in 5.0.0 must be >= to version in 4.1.3
16 [main] ERROR org.jboss.tools.vwatch.service.EvaluationService - ERROR - Bundle org.jboss.tools.hibernate.jpt.ui3.4.1 in 5.0.0 must be >= to version in 4.1.3
17 [main] ERROR org.jboss.tools.vwatch.service.EvaluationService - ERROR - Bundle org.jboss.tools.hibernate.ui3.4.1 in 5.0.0 must be >= to version in 4.1.3
19 [main] ERROR org.jboss.tools.vwatch.service.EvaluationService - ERROR - Bundle org.jboss.tools.hibernate.jpt.core3.4.1 in 5.0.0 must be >= to version in 4.1.3{code}
was (Author: nickboldt):
Appears to be working:
{code:title=https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevStudio_Trunk/job/devstudio.versionwatch_71/36/console}
457581 [main] WARN org.jboss.tools.vwatch.service.EvaluationService - Bundle org.jboss.tools.central.themes.feature is a folder; must jar it to compare MD5 sums.
{code}
> support comparing bundle folders as well as bundle jars when comparing MD5 sums
> -------------------------------------------------------------------------------
>
> Key: JBIDE-15160
> URL: https://issues.jboss.org/browse/JBIDE-15160
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: build, qa
> Affects Versions: 4.1.0.CR1
> Reporter: Nick Boldt
> Assignee: Pavol Srna
> Priority: Critical
> Fix For: 4.1.1.Alpha2
>
>
> Currently, versionwatch can only compare md5s for jars. Adding support for zipping folders to jars and then comparing those should be fairly simple to add.
> We could also compare MD5s for plugins' manifest.mf files as well as the jars themselves.
--
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
12 years, 7 months