[JBoss JIRA] (JBIDE-18695) Internal Error when removing an entity with Forge (CLI)
by Xavier Coulon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18695?page=com.atlassian.jira.plugi... ]
Xavier Coulon commented on JBIDE-18695:
---------------------------------------
[~gastaldi], if the problem could not be reproduced when removing the Java file from CLI, then I guess it's been solved since I opened the issue. Unless you tried with Forge 3 while I was using Forge 2 at that time ?
> Internal Error when removing an entity with Forge (CLI)
> -------------------------------------------------------
>
> Key: JBIDE-18695
> URL: https://issues.jboss.org/browse/JBIDE-18695
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: forge
> Affects Versions: 4.2.0.Final
> Reporter: Xavier Coulon
> Assignee: Koen Aers
> Fix For: 4.2.x, 4.3.x
>
>
> I got the following error when removing a JPA entity with forge ({{rm <Entity>.java}}:
> {code}
> org.eclipse.core.internal.resources.ResourceException: Resource '/conferences/src/main/java/org/conferences/model/Session.java' does not exist.
> at org.eclipse.core.internal.resources.Resource.checkExists(Resource.java:341)
> at org.eclipse.core.internal.resources.Resource.checkAccessible(Resource.java:215)
> at org.eclipse.core.internal.resources.Resource.findMaxProblemSeverity(Resource.java:1051)
> at org.eclipse.jdt.ui.ProblemsLabelDecorator.getPackageErrorTicksFromMarkers(ProblemsLabelDecorator.java:337)
> at org.eclipse.jdt.ui.ProblemsLabelDecorator.computeAdornmentFlags(ProblemsLabelDecorator.java:212)
> at org.eclipse.jdt.internal.ui.viewsupport.TreeHierarchyLayoutProblemsDecorator.computePackageAdornmentFlags(TreeHierarchyLayoutProblemsDecorator.java:47)
> at org.eclipse.jdt.internal.ui.viewsupport.TreeHierarchyLayoutProblemsDecorator.computeAdornmentFlags(TreeHierarchyLayoutProblemsDecorator.java:56)
> at org.eclipse.jdt.internal.ui.packageview.PackageExplorerProblemsDecorator.computeAdornmentFlags(PackageExplorerProblemsDecorator.java:35)
> at org.eclipse.jdt.ui.ProblemsLabelDecorator.decorateImage(ProblemsLabelDecorator.java:170)
> at org.eclipse.jdt.internal.ui.viewsupport.JavaUILabelProvider.decorateImage(JavaUILabelProvider.java:134)
> at org.eclipse.jdt.internal.ui.viewsupport.JavaUILabelProvider.getImage(JavaUILabelProvider.java:149)
> at org.eclipse.jdt.internal.ui.packageview.PackageExplorerLabelProvider.getImage(PackageExplorerLabelProvider.java:140)
> at org.eclipse.jdt.internal.ui.navigator.JavaNavigatorLabelProvider.getImage(JavaNavigatorLabelProvider.java:128)
> at org.eclipse.ui.internal.navigator.NavigatorContentServiceLabelProvider.findImage(NavigatorContentServiceLabelProvider.java:197)
> at org.eclipse.ui.internal.navigator.NavigatorContentServiceLabelProvider.getColumnImage(NavigatorContentServiceLabelProvider.java:105)
> at org.eclipse.ui.internal.navigator.NavigatorContentServiceLabelProvider.getImage(NavigatorContentServiceLabelProvider.java:98)
> at org.eclipse.ui.internal.navigator.NavigatorDecoratingLabelProvider$StyledLabelProviderAdapter.getImage(NavigatorDecoratingLabelProvider.java:59)
> at org.eclipse.jface.viewers.DelegatingStyledCellLabelProvider.getImage(DelegatingStyledCellLabelProvider.java:195)
> at org.eclipse.jface.viewers.DecoratingStyledCellLabelProvider.getImage(DecoratingStyledCellLabelProvider.java:173)
> at org.eclipse.ui.navigator.CommonNavigatorManager.updateStatusBar(CommonNavigatorManager.java:308)
> at org.eclipse.ui.navigator.CommonNavigatorManager$1.selectionChanged(CommonNavigatorManager.java:74)
> at org.eclipse.jface.viewers.StructuredViewer$3.run(StructuredViewer.java:876)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:50)
> at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:178)
> at org.eclipse.jface.viewers.StructuredViewer.firePostSelectionChanged(StructuredViewer.java:873)
> at org.eclipse.jface.viewers.StructuredViewer.setSelection(StructuredViewer.java:1708)
> at org.eclipse.jface.viewers.TreeViewer.setSelection(TreeViewer.java:1093)
> at org.eclipse.ui.navigator.CommonViewer.setSelection(CommonViewer.java:375)
> at org.eclipse.ui.navigator.CommonNavigator.selectReveal(CommonNavigator.java:383)
> at org.jboss.tools.forge.ui.internal.cli.CommandLineListener.expandInProjectExplorer(CommandLineListener.java:217)
> at org.jboss.tools.forge.ui.internal.cli.CommandLineListener.expandWorkspaceResource(CommandLineListener.java:191)
> at org.jboss.tools.forge.ui.internal.cli.CommandLineListener.selectFile(CommandLineListener.java:175)
> at org.jboss.tools.forge.ui.internal.cli.CommandLineListener.selectResource(CommandLineListener.java:136)
> at org.jboss.tools.forge.ui.internal.cli.CommandLineListener.access$5(CommandLineListener.java:133)
> at org.jboss.tools.forge.ui.internal.cli.CommandLineListener$1.run(CommandLineListener.java:99)
> at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
> at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:136)
> at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3983)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3660)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032)
> at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:636)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:579)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:135)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
> 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.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22007) JPA: New Field should select the field in outline view and editor
by Josef Kopriva (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22007?page=com.atlassian.jira.plugi... ]
Josef Kopriva edited comment on JBIDE-22007 at 7/7/16 4:22 AM:
---------------------------------------------------------------
Steps to reproduce:
1. Create new project
2. Create connection profile (sakila)
3. Create jboss data source
4. Crl+4 -> jpa-setup
5. Crl+4 -> jpa generate entities from tables (select *)
6. Select new generated class -> Crl+4 -> JPA: New Field -> Enter Field name and Click on Finish - > New field is generated in Class, but it is not selected.
was (Author: jkopriva):
Steps to reproduce:
1. Create new project
2. Create connection profile (sakila)
3. Create jboss data source
4. jpa-setup
5. jpa generate entities from tables (select *)
6. Select new generated class -> Crl+4 -> JPA: New Field -> Enter Field name and Click on Finish - > New field is generated in Class, but it is not selected.
> JPA: New Field should select the field in outline view and editor
> -----------------------------------------------------------------
>
> Key: JBIDE-22007
> URL: https://issues.jboss.org/browse/JBIDE-22007
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: forge
> Affects Versions: 4.3.1.CR1
> Reporter: Pavol Srna
> Assignee: George Gastaldi
> Fix For: 4.4.x
>
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-13671) Replace build timestamp in qualifier by last-mod-timestamp from git
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13671?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-13671:
---------------------------------------
[~mlabuda] noticed today that the latest nightly build of devstudio has this name:
devstudio-10.0.1.v20160613-2041-installer-standalone.jar
It was built on 05-Jul. Sure, the filename does not necessarily need to include that date now, but such an old date seems odd, no?
Or is this completely unrelated to this JIRA?
> Replace build timestamp in qualifier by last-mod-timestamp from git
> -------------------------------------------------------------------
>
> Key: JBIDE-13671
> URL: https://issues.jboss.org/browse/JBIDE-13671
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Affects Versions: 4.1.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Priority: Optional
> Fix For: 4.4.1.AM1
>
> Attachments: after-jgit.png, after-jgit2.png, arq-dirty-workspace-compare1.png, arq-dirty-workspace-compare2.png, arq-dirty-workspace-compare3-bigger-change.png, arq-dirty-workspace-compare4-bigger-change.png, base-before-after-jgit.png, before-jgit.png, before-jgit2.png, jbide13671-before-and-after.png, server-before-after-jgit-3-different-timestamps.png, server-before-after-jgit-4-different-timestamps-features.png, server-before-after-jgit-dirty-workspace-upversioned-features.png, server-before-after-jgit-dirty-workspace-upversioned-plugin-with-change.png
>
>
> This needs to be added to master parent pom:
> {code}
> <plugin>
> <groupId>org.eclipse.tycho</groupId>
> <artifactId>tycho-packaging-plugin</artifactId>
> <version>${tycho.version}</version>
> <dependencies>
> <dependency>
> <groupId>org.eclipse.tycho.extras</groupId>
> <artifactId>tycho-buildtimestamp-jgit</artifactId>
> <version>${tycho-extras.version}</version>
> </dependency>
> </dependencies>
> <configuration>
> <strictBinIncludes>false</strictBinIncludes>
> <format>'v'yyyyMMdd-HHmm</format>
> <timestampProvider>jgit</timestampProvider>
> <jgit.ignore>
> </jgit.ignore>
> </configuration>
> </plugin>
> {code}
> Ref: http://pweclipse.blogspot.ch/2012_09_01_archive.html
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22617) Integrate DockViz in to Docker Tooling
by Xavier Coulon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22617?page=com.atlassian.jira.plugi... ]
Xavier Coulon updated JBIDE-22617:
----------------------------------
Fix Version/s: 4.4.x
> Integrate DockViz in to Docker Tooling
> --------------------------------------
>
> Key: JBIDE-22617
> URL: https://issues.jboss.org/browse/JBIDE-22617
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: docker, upstream
> Affects Versions: 4.4.0.Alpha2
> Reporter: Mustafa Musaji
> Assignee: Xavier Coulon
> Priority: Optional
> Fix For: 4.4.x
>
>
> DockVIz is a tool used to provide a way to view docker information on a system in a number of ways, one of which is a tree like structure to be able to visualise docker layers.
> This would be a nice thing to include in our docker toolset.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22580) Deploy Docker Image wizard: Cannot push already tagged image to docker registry
by Xavier Coulon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22580?page=com.atlassian.jira.plugi... ]
Xavier Coulon updated JBIDE-22580:
----------------------------------
Fix Version/s: 4.4.1.AM2
(was: 4.4.1.AM1)
> Deploy Docker Image wizard: Cannot push already tagged image to docker registry
> -------------------------------------------------------------------------------
>
> Key: JBIDE-22580
> URL: https://issues.jboss.org/browse/JBIDE-22580
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: docker, openshift
> Affects Versions: 4.4.0.Final
> Reporter: Marián Labuda
> Assignee: Xavier Coulon
> Labels: deploy_docker_wizard, docker, openshift_v3
> Fix For: 4.4.1.AM2
>
>
> There is a CDK docker registry located at hub.openshift.rhel-cdk.10.1.2.2.xip.io. From command line user has to tag image at first before pushing it to remote registry to match registry URL, e.g. to push image msa/helloworld from local repository to CDK docker registry I have to tag image as follows hub.openshift.rhel-cdk.10.1.2.2.xip.io/msa/helloworld and then I can just push it "docker push hub.openshift.rhel-cdk.10.1.2.2.xip.io/msa/helloworld". Users used to command line tooling and not aware of "auto-tag" feature of OpenShift tooling can bump into issues. When I am trying to push already tagged image (as I would be expecting from command line) I get an error with following stack trace
> {code}Failed to push the selected Docker image into OpenShift registry
> org.eclipse.linuxtools.docker.core.DockerException: Conflict: Tag latest is already set to image 2e0ddd37ace80cf13a9d3c664445430972fb3440661eb5d8efb7cc994f11bbdb, if you want to replace it, please use -f option
> at org.eclipse.linuxtools.internal.docker.core.DockerConnection.tagImage(DockerConnection.java:1083)
> at org.jboss.tools.openshift.internal.ui.dockerutils.PushImageToRegistryJob.doRun(PushImageToRegistryJob.java:65)
> at org.jboss.tools.openshift.internal.common.core.job.AbstractDelegatingMonitorJob.run(AbstractDelegatingMonitorJob.java:37)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> {code}
> I think it would be better at first try to check, whether an image does not already have specific tag and if it does, then we should involve confirmation dialog to use force push. If there is no such tagged image, push would behave as it is. Alternatively after checking of image existence we could just simply ignore it, because it is being tagged on same tag.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22627) Docker image tag is ignored in Deploy Image to OpenShift wizard
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22627?page=com.atlassian.jira.plugi... ]
Marián Labuda updated JBIDE-22627:
----------------------------------
Steps to Reproduce:
ASSERT: Have an OpenShift 3 connection with a project and Docker connection with an image with at least 2 tags.
EXEC: Select the with some tag in docker explorer and open its context menu Deploy to OpenShift...
RESULT: Image details are prefilled in the Deploy Image to OpenShift wizard but wizard tag is ignored (there is no explicit tag in the text widget in the wizard and thus latest is used).
EXPECTED RESULT: Image details are prefilled with correct tag.
> Docker image tag is ignored in Deploy Image to OpenShift wizard
> ---------------------------------------------------------------
>
> Key: JBIDE-22627
> URL: https://issues.jboss.org/browse/JBIDE-22627
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.0.Final
> Reporter: Marián Labuda
> Labels: docker, openshift_v3
> Fix For: 4.4.1.AM2
>
>
> When deploying a docker image from docker explorer by selecting context menu item Deploy to OpenShift..., image name in opened Deploy Image to OpenShift wizard does not contain tag of the image. This requires manual addition of image tag, otherwise latest tag is presumed by default, what does not have to be desired at some scenarios.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months