[JBoss JIRA] (JBDS-3963) Devstudio uses old timestamps
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-3963?page=com.atlassian.jira.plugin.... ]
Nick Boldt edited comment on JBDS-3963 at 7/7/16 9:08 AM:
----------------------------------------------------------
Please be more specific. What artifact in the build is datestamped 20160613-2041 ?
Could this be because we moved to use jgit timestamps and that's the last time the artfact was updated in github?
Can you provide a link or screenshot when you report a problem so it's easier to know what you're seeing, and to reproduce it?
See JBIDE-13671
was (Author: nickboldt):
Please be more specific. What artifact in the build is datestamped 20160613-2041 ?
Could this be because we moved to use jgit timestamps and that's the last time the artfact was updated in github?
See JBIDE-13671
> Devstudio uses old timestamps
> -----------------------------
>
> Key: JBDS-3963
> URL: https://issues.jboss.org/browse/JBDS-3963
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: build
> Affects Versions: 10.0.1.AM1
> Reporter: Marián Labuda
> Priority: Minor
>
> Build id of devstudio installers contains old timestamp. E.g. latest build 2016-07-05_17-10-13-B5634 contains timestamp 20160613-2041 although the build which is producing bits is 20160705-5634.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBDS-3963) Devstudio uses old timestamps
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-3963?page=com.atlassian.jira.plugin.... ]
Nick Boldt commented on JBDS-3963:
----------------------------------
Please be more specific. What artifact in the build is datestamped 20160613-2041 ?
Could this be because we moved to use jgit timestamps and that's the last time the artfact was updated in github?
See JBIDE-13671
> Devstudio uses old timestamps
> -----------------------------
>
> Key: JBDS-3963
> URL: https://issues.jboss.org/browse/JBDS-3963
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: build
> Affects Versions: 10.0.1.AM1
> Reporter: Marián Labuda
> Priority: Minor
>
> Build id of devstudio installers contains old timestamp. E.g. latest build 2016-07-05_17-10-13-B5634 contains timestamp 20160613-2041 although the build which is producing bits is 20160705-5634.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-18695) Internal Error when removing an entity with Forge (CLI)
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18695?page=com.atlassian.jira.plugi... ]
George Gastaldi resolved JBIDE-18695.
-------------------------------------
Fix Version/s: 4.4.1.AM2
(was: 4.2.x)
(was: 4.3.x)
Assignee: George Gastaldi (was: Koen Aers)
Resolution: Cannot Reproduce Bug
Closing as cannot reproduce. Please reopen if the problem persists. Thanks
> 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: George Gastaldi
> Fix For: 4.4.1.AM2
>
>
> 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] (JBDS-3963) Devstudio uses old timestamps
by Marián Labuda (JIRA)
Marián Labuda created JBDS-3963:
-----------------------------------
Summary: Devstudio uses old timestamps
Key: JBDS-3963
URL: https://issues.jboss.org/browse/JBDS-3963
Project: Red Hat JBoss Developer Studio (devstudio)
Issue Type: Bug
Components: build
Affects Versions: 10.0.1.AM1
Reporter: Marián Labuda
Priority: Minor
Build id of devstudio installers contains old timestamp. E.g. latest build 2016-07-05_17-10-13-B5634 contains timestamp 20160613-2041 although the build which is producing bits is 20160705-5634.
--
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 Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13671?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-13671:
----------------------------------------
[~mlabuda] As this issues tracks a task that was done in a previous sprint and tracks much more than the sole JBDS package, can you please open a separate Jira for the package timestamp issue?
> 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-22695) Environment Variables of application deployment should have different workflow
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22695?page=com.atlassian.jira.plugi... ]
Marián Labuda updated JBIDE-22695:
----------------------------------
Labels: openshift_v3 (was: )
> Environment Variables of application deployment should have different workflow
> ------------------------------------------------------------------------------
>
> Key: JBIDE-22695
> URL: https://issues.jboss.org/browse/JBIDE-22695
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.1.AM1
> Reporter: Marián Labuda
> Priority: Critical
> Labels: openshift_v3
>
> Reset All button in Environment Var wizard dialog should get application to default state. At the moment it reset environment variables in the table just to the values at the point of opening the wizard. If I would delete some environment variables and confirm changes, but I would find out I broke something and I would like to rollback it to original state, I would try to reset it with Reset All button. But it won't work for me. This is causing the more serious issue:
> Because we edit same deployment configuration and start deployments from it and in the same time we set number of replicas in other deployment configs to zero. So we don't have the original deployment config and thus we cannot rollback easily (well there is a way but nasty one - edit replication controller, copy and paste environment variables to the deployment config, save it and deploy latest).
> There are 2 options:
> a) Create a new deployment configuration for a new (modified) set of environment variables and create a new replication controller (deployment) from this deployment configuration. There is one con - it can lead to many deployment configurations and replication controllers (for each deployment configuration there would be one replication controller).
> b) Just edit current replication controller (deployment) of an application or create a new one from an existing but with modified env. vars and with correct amount of replicas and set replicas in the previous to 0. And then let respin pods with correct setup. One of those approaches (create/edit RC) would be, I think, more satisfying.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months