June 2017 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-15332) stop linking skipRequirements and tests.skip to download of requirements

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15332?page=com.atlassian.jira.plugi... ] Nick Boldt closed JBIDE-15332. ------------------------------ Resolution: Out of Date Rejecting, out of date. No progress since Nov 2015 so this is clearly for the dead letter pile. > stop linking skipRequirements and tests.skip to download of requirements > ------------------------------------------------------------------------- > > Key: JBIDE-15332 > URL: https://issues.jboss.org/browse/JBIDE-15332 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Affects Versions: 4.2.0.Beta1 > Reporter: Max Rydahl Andersen > Assignee: Nick Boldt > Priority: Minor > Labels: f2f2014 > Fix For: 4.5.0.AM2 > > > I stumbled on [~dgolovin]'s patch for livreload at https://github.com/jbosstools/jbosstools-livereload/pull/54/files > This is not the first time i've seen skip having to be enabled for plain normal mvn dependencies. > skipRequirements are supposed to only cover big downloads (like EAP, jboss etc.) - things done via non-maven download mechanism. > Why is this applied to mvn dependency downloads ? > The culprit for needing this line is at: > https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml... > and a bugzilla (*not* jira?!) is referenced as the reason for this back in 2012: https://github.com/jbosstools/jbosstools-build/commit/2e18baaf88e0cd73b3b... > I understand why the explicit google download plugin (why is there two versions used btw?) but why is skipTests controlling normal mvn dependency download ? Which requirements are using this for download ? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15332) stop linking skipRequirements and tests.skip to download of requirements

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15332?page=com.atlassian.jira.plugi... ] Rob Stryker reassigned JBIDE-15332: ----------------------------------- Assignee: Nick Boldt (was: Denis Golovin) > stop linking skipRequirements and tests.skip to download of requirements > ------------------------------------------------------------------------- > > Key: JBIDE-15332 > URL: https://issues.jboss.org/browse/JBIDE-15332 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Affects Versions: 4.2.0.Beta1 > Reporter: Max Rydahl Andersen > Assignee: Nick Boldt > Priority: Minor > Labels: f2f2014 > Fix For: 4.5.0.AM2 > > > I stumbled on [~dgolovin]'s patch for livreload at https://github.com/jbosstools/jbosstools-livereload/pull/54/files > This is not the first time i've seen skip having to be enabled for plain normal mvn dependencies. > skipRequirements are supposed to only cover big downloads (like EAP, jboss etc.) - things done via non-maven download mechanism. > Why is this applied to mvn dependency downloads ? > The culprit for needing this line is at: > https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml... > and a bugzilla (*not* jira?!) is referenced as the reason for this back in 2012: https://github.com/jbosstools/jbosstools-build/commit/2e18baaf88e0cd73b3b... > I understand why the explicit google download plugin (why is there two versions used btw?) but why is skipTests controlling normal mvn dependency download ? Which requirements are using this for download ? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15332) stop linking skipRequirements and tests.skip to download of requirements

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15332?page=com.atlassian.jira.plugi... ] Rob Stryker updated JBIDE-15332: -------------------------------- Fix Version/s: 4.5.0.AM2 (was: 4.5.0.AM1) > stop linking skipRequirements and tests.skip to download of requirements > ------------------------------------------------------------------------- > > Key: JBIDE-15332 > URL: https://issues.jboss.org/browse/JBIDE-15332 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Affects Versions: 4.2.0.Beta1 > Reporter: Max Rydahl Andersen > Assignee: Nick Boldt > Priority: Minor > Labels: f2f2014 > Fix For: 4.5.0.AM2 > > > I stumbled on [~dgolovin]'s patch for livreload at https://github.com/jbosstools/jbosstools-livereload/pull/54/files > This is not the first time i've seen skip having to be enabled for plain normal mvn dependencies. > skipRequirements are supposed to only cover big downloads (like EAP, jboss etc.) - things done via non-maven download mechanism. > Why is this applied to mvn dependency downloads ? > The culprit for needing this line is at: > https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml... > and a bugzilla (*not* jira?!) is referenced as the reason for this back in 2012: https://github.com/jbosstools/jbosstools-build/commit/2e18baaf88e0cd73b3b... > I understand why the explicit google download plugin (why is there two versions used btw?) but why is skipTests controlling normal mvn dependency download ? Which requirements are using this for download ? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15671) WildFly / EAP domain mode management UI

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15671?page=com.atlassian.jira.plugi... ] Rob Stryker updated JBIDE-15671: -------------------------------- Fix Version/s: LATER (was: 4.5.0.AM1) > WildFly / EAP domain mode management UI > --------------------------------------- > > Key: JBIDE-15671 > URL: https://issues.jboss.org/browse/JBIDE-15671 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: server > Reporter: Ondrej Zizka > Assignee: Rob Stryker > Fix For: LATER > > Attachments: domainmodeinitialmockup.bmml, domainmodeinitialmockup.png > > > Max brought the topic of Domain mode management UI. > The domain mode needs a special treatment. > Logically it's a matrix, and calls for a matrix-like UI instead of a tree. > The structure would be similar to the pictures of domain mode in tutorials (TBD: link). > An inspiration may be taken from AS web console. > As a preliminary solution, a tree may be used, in which case it may omit host controllers which do not play much role in domain mode management, from the admin PoV. > The nodes would represent server groups, and their leaves would represent particular servers (JVMs). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19182) Incremental Publish after Full Publish WRT dodeploy markers

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19182?page=com.atlassian.jira.plugi... ] Rob Stryker resolved JBIDE-19182. --------------------------------- Resolution: Won't Fix There is no reported scenario of this ever actually happening. After a full publish we wait for it to finish before performing any incrementals. The small increase in speed is not worth upsetting this apple cart. > Incremental Publish after Full Publish WRT dodeploy markers > ----------------------------------------------------------- > > Key: JBIDE-19182 > URL: https://issues.jboss.org/browse/JBIDE-19182 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: server > Affects Versions: 4.2.0.Final > Reporter: Rob Stryker > Assignee: Rob Stryker > Fix For: 4.5.0.AM1 > > > THis issue is opened in regards to comments by [~dlmiles] on https://issues.jboss.org/browse/JBIDE-18862 > I am saying you should block all 'deployment directory' file modifications when you know the AS is busy using the 'deployment directory' to "deploy" (a.k.a. starting) or "undeploy" (a.k.a. stopping) of a module (or the AS itself is starting/stopping in certain scenarios). Ideally you use a file watcher API when available so there is no busy/wait loop adding additional milliseconds of delays because the wait part is never instant. > But in an example scenario where you perform a Full Publish then 2 additional Incremental Publish ops immediately after, there is no reason to block the incrementals if you know the AS has not picked up the original Full Publish yet. You can effectively merge those two incrementals into the full publish operation behind the back of the AS. > But you are presented with a race scenario, you have already laid down the *.dodeploy at the end of the original Full Publish. So Eclipse needs to effectively notice that scenario exists, revoke and remember that instruction to the AS in an atomic way (what I mean by this is Eclipse knows for sure if it cancelled it in time, or if it was too late and the AS got to the full publish first and started deploying). > You need to do this so Eclipse can make file change modifications to the 'deployment directory' again. > Once Eclipse has completed the file change operations, if takes that remembered state and puts back the *.dodeploy file (even though this is an Incremental Publish operation). You can think of this like a "save state" and "restore state" pattern if that helps. Or you can think of this like the Eclipse target goal state for the AS (such as "AS:started" and "module.abc:started") is compared to the actual AS state (such as "AS: started" and "module.abc:stopped"), and Eclipse then brings them into alignment to do this it realizes it needs to lay down the *.dodeploy marker file (even though this is an incremental publish). > I think with the current marker file arrangements there maybe a tiny window of time where Eclipse IDE will get things wrong in respect of the AS ? But maybe ensuring both Eclipse IDE and the AS check the return value of the file delete for *.dodeploy whomever was successful in deleting the file wins, whichever party got the error "No Such File" loses and performs a rollback/cleanup of the situation to ensure it tries again soon. > So you can speak for the JBIDE side but can someone check the AS side ? File#delete(new File("foobar.dodeploy")) != true. The AS has to delete the command instruction file before it starts to process that command, but after it has laid down a state change file (*.isdeploying). > One of the goals of the marker files is that at no point in time is there a snapshot of the files that exist in the directory; that would leave an observer to interpret the wrong state. For example deleting one marker file before laying down the next would be bad, because there is a snapshot of time when no state marker file exists in the directory, leaving the observer to interpret that nothing is happening with that module. The alternative is to lay both the new file first then delete the old one, now there is a window of time when 2 marker files indicate state for 1 module, this is good and valid since the observer can clearly see the correct state. > So if you got here and are still with me, then you can see how things should only slow down, when they need to slow down. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-24539) Explorer, Properties: User should be able to see what OpenShift version a connection is

by Jeff MAURY (JIRA)

[ https://issues.jboss.org/browse/JBIDE-24539?page=com.atlassian.jira.plugi... ] Jeff MAURY updated JBIDE-24539: ------------------------------- Sprint: devex #134 Jun 2017 (was: devex #133 Jun 2017) > Explorer, Properties: User should be able to see what OpenShift version a connection is > --------------------------------------------------------------------------------------- > > Key: JBIDE-24539 > URL: https://issues.jboss.org/browse/JBIDE-24539 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.5.0.AM1 > Reporter: Andre Dietisheim > Assignee: Dmitrii Bocharov > Labels: explorer, openshift_v2, openshift_v3, properties > Fix For: 4.5.0.Final > > Attachments: image-2017-06-06-11-54-02-000.png > > > steps: > # ASSERT: have a connection to an OpenShift 3 and an OpenShift 2 server respectively > # EXEC: look at the entries in the explorer and in the Properties view > Result: > !image-2017-06-06-11-54-02-000.png! > You have no idea about the versions of the OpenShift servers of the connections that you have. You may only figure out implicitly by the "Domains" displayed in the properties for the OpenShift 2 connection. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22969) Make sure OpenShift Tools support proxies

by Jeff MAURY (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22969?page=com.atlassian.jira.plugi... ] Jeff MAURY updated JBIDE-22969: ------------------------------- Sprint: devex #123 November 2016, devex #134 Jun 2017 (was: devex #123 November 2016, devex #133 Jun 2017) > Make sure OpenShift Tools support proxies > ----------------------------------------- > > Key: JBIDE-22969 > URL: https://issues.jboss.org/browse/JBIDE-22969 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: openshift > Reporter: Alexey Kazakov > Assignee: Dmitrii Bocharov > Fix For: 4.5.0.AM1 > > Attachments: proxy_settings.png, proxy_settings_2.png > > > CDK is now support proxy servers. We also should make sure OpenShift Tools works fine with proxies too. > If devstudio and cdk are installed using DevSuite installer and user configured proxy server correctly then everything should just work on Eclipse side. > This issue covers: > - testing > - creating all needed (currently missing) automated tests (including reddeer/swt bot Integration Tests) > - fixing any problems we have in OpenShift tooling regarding proxy support. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22613) Connection wizard: When a connection is configured with a stored token, switching back with basic will fail if token is invalid

by Jeff MAURY (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22613?page=com.atlassian.jira.plugi... ] Jeff MAURY updated JBIDE-22613: ------------------------------- Sprint: devex #123 November 2016, devex #134 Jun 2017 (was: devex #123 November 2016, devex #133 Jun 2017) > Connection wizard: When a connection is configured with a stored token, switching back with basic will fail if token is invalid > ------------------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-22613 > URL: https://issues.jboss.org/browse/JBIDE-22613 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.4.0.Final > Reporter: Jeff MAURY > Assignee: Dmitrii Bocharov > Labels: connection, connection_wizard, openshift_v3 > Fix For: 4.5.0.Final > > > If an Openshift is configured with a OAuth and a stored token, if you want to switch back to basic, the connection will fail because the connection is still made using Oauth -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-24499) Deploy Docker Image wizard: no projects are available if connection wasn't expanded in explorer

by Jeff MAURY (JIRA)

[ https://issues.jboss.org/browse/JBIDE-24499?page=com.atlassian.jira.plugi... ] Jeff MAURY updated JBIDE-24499: ------------------------------- Sprint: devex #134 Jun 2017 (was: devex #133 Jun 2017) > Deploy Docker Image wizard: no projects are available if connection wasn't expanded in explorer > ----------------------------------------------------------------------------------------------- > > Key: JBIDE-24499 > URL: https://issues.jboss.org/browse/JBIDE-24499 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.4.4.Final > Reporter: Andre Dietisheim > Assignee: Dmitrii Bocharov > Labels: deploy_docker_wizard, openshift_v3 > Fix For: 4.5.0.Final > > Attachments: image-2017-05-23-11-20-07-473.png > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20153) Docker server adapter

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20153?page=com.atlassian.jira.plugi... ] Rob Stryker updated JBIDE-20153: -------------------------------- Fix Version/s: LATER (was: 4.5.0.AM1) > Docker server adapter > --------------------- > > Key: JBIDE-20153 > URL: https://issues.jboss.org/browse/JBIDE-20153 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: docker, server > Reporter: Max Rydahl Andersen > Assignee: Rob Stryker > Priority: Critical > Fix For: LATER > > > I've been wondering for a time what would be the best way to integrate docker with our server adapters. > I initially first thought it should be an additional profile to the existing local or remote profiles - but I think that option actually ends up being too limiting. To start - the server inside the docker then is assumed to always be a wildfly server; and I think for docker that is too limiting. > Watching Eclipse Che demo at EclipseCon I realized their approach for "Runners" actually fits perfectly. > What they do is that they don't actually have any insight into what servers they are running - they simply just have an associated DockerFile for a "runner" which they build and then run before launching. > Once launched they then know where the server port is, where the possible debug port is, where files are mounted etc. > So this Docker Server Adapter can be made to run *any* kind of application. > WildFly, Tomcat, Python, even plain java apps. > And actually it is not just a DockerFile that is associated with the run but a templated dockerfile. A file where certain variables will be replaced; like: > {code} > VOLUME /deployments > ADD $app$ /deployments > {code} > will add the packaged app (i.e. wonka.war) into the /deployments folder and /deployments is mounted. > And actually the /deployments can then be updated incrementally if wanted to. > Even greater is that if we could support the same syntax and semantics of the templating we can simply reuse the templates defined by Che at https://github.com/codenvy/dockerfiles/ > You can see more complete info on what codenvy/che does http://docs.codenvy.com/user/builders-and-runners/#custom-machines > This would cover all the usecases I can currently think of with launching docker from eclipse - but not be tied to any specific server type. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-issues June 2017