[JBoss JIRA] (JBIDE-21090) Open github project hooks settings page rather than project page
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21090?page=com.atlassian.jira.plugi... ]
Marián Labuda closed JBIDE-21090.
---------------------------------
Verified in nightly 4.3.1.Beta1 build with OpenShift plug-ins version 3.1.0.Beta1-v20151123-1937-B86.
> Open github project hooks settings page rather than project page
> ----------------------------------------------------------------
>
> Key: JBIDE-21090
> URL: https://issues.jboss.org/browse/JBIDE-21090
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.0.Final
> Reporter: Fred Bricon
> Assignee: Fred Bricon
> Priority: Minor
> Fix For: 4.3.1.Beta1
>
>
> When opening the "Show WebHook" dialog for an OpenShift 3 project, the Github link currently opens the project page. Ideally we should add the hook automagically. while this is technically possible, it requires the user's github credentials, which we don't have. As a compromise, we should open https://github.com/<user>/<repo>/settings/hooks
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-21091) [Connection Wizard] Automatically strip "/console" suffix from OpenShift server url
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21091?page=com.atlassian.jira.plugi... ]
Marián Labuda closed JBIDE-21091.
---------------------------------
Verified in nightly 4.3.1.Beta1 build with OpenShift plug-ins version 3.1.0.Beta1-v20151123-1937-B86.
> [Connection Wizard] Automatically strip "/console" suffix from OpenShift server url
> -----------------------------------------------------------------------------------
>
> Key: JBIDE-21091
> URL: https://issues.jboss.org/browse/JBIDE-21091
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.0.Final
> Reporter: Fred Bricon
> Assignee: Fred Bricon
> Priority: Minor
> Labels: connection_wizard, openshift_v2, openshift_v3
> Fix For: 4.3.1.Beta1
>
>
> I often copy/paste OpenShift's web console url in the new connection wizard's server textbox. Since I'm a pretty lazy dude, I'd like the wizard to automatically strip the /console suffix from the url for me.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-20766) Merge jbosstools-4.3.1.x branch into jbosstools-4.3.x branch
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20766?page=com.atlassian.jira.plugi... ]
Marián Labuda closed JBIDE-20766.
---------------------------------
> Merge jbosstools-4.3.1.x branch into jbosstools-4.3.x branch
> -------------------------------------------------------------
>
> Key: JBIDE-20766
> URL: https://issues.jboss.org/browse/JBIDE-20766
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: openshift
> Affects Versions: 4.3.1.Final
> Reporter: Fred Bricon
> Assignee: Fred Bricon
> Priority: Blocker
> Fix For: 4.3.1.Beta1
>
>
> For jbosstools-openshift, ongoing work towards the JBoss Tools 4.3.1.Final release must happen on the jbosstools-4.3.1.x branch.
> Once 4.3.0.Final has been released, the jbosstools-4.3.1.x branch must be merged into jbosstools-4.3.x branch, where subsequent commits will be pushed, until the 4.3.1.Final release.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-20596) Next button in the New OpenShift Application window is enabled only after clicking Use default server check box
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20596?page=com.atlassian.jira.plugi... ]
Marián Labuda closed JBIDE-20596.
---------------------------------
Verified in nightly 4.3.1.Beta1 build with OpenShift plug-ins version 3.1.0.Beta1-v20151123-1937-B86.
> Next button in the New OpenShift Application window is enabled only after clicking Use default server check box
> ---------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-20596
> URL: https://issues.jboss.org/browse/JBIDE-20596
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Reporter: Supriya Bharadwaj
> Assignee: Andre Dietisheim
> Fix For: 4.3.1.Beta1
>
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> In the New OpenShift Application window, after all the fields are filled in and the token is entered in the Token field, (my guess is) the Next button should get enabled, which doesn't happen. The button gets enabled only after the "Use default Server" check box is clicked. Is this a bug?
> (I am trying this in JBDS v9.0cr1)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-21120) Why do we deploy TP zips to Nexus snapshots repo?
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21120?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-21120 at 11/26/15 11:38 AM:
---------------------------------------------------------------
Reverted previous changes since Mickael's solution is easier/cleaner and more "maven-friendly".
https://github.com/jbosstools/jbosstools-target-platforms/commits/4.60.x
Here's the job config change:
https://github.com/jbdevstudio/jbdevstudio-ci/commit/0349c99e890e1c1b06dd...
Which results in this order of 8 steps (5 mvn, 3 bash):
* checkout correct branch of code based on the input VERSION = 4.51.1.CR1-SNAPSHOT or 4.51.2.Beta1-SNAPSHOT or 4.60.0.Alpha1-SNAPSHOT
** git checkout ${branch}
* push multiple .target to nexus
** mvn clean deploy -U -e -f multiple/pom.xml
* resolve TP to get site + zip
** mvn install -U -Pmultiple2repo -e -f multiple/pom.xml
* publish the full target platform + zip to dl.jb.o / ds.rh.c
** rsync ...
* since unified .target depends on having published new bits to dl.jb.o / ds.rh.c, we can now build and deploy that
** mvn clean deploy -U -e -f unified/pom.xml
* fetch groovy dependencies for doing install tests
** org.jboss.tools.installation-tests:scripts
* fetch shell dependencies for doing install tests
** org.jboss.tools.releng:jbosstools-releng-publish
* now, do install tests (which might fail if the Eclipse JEE bundle contains incompatible versions of something in the TP (eg., we include a newer egit or m2e)
** getAndInstallEclipse.groovy ...
** installFromTarget.sh ...
was (Author: nickboldt):
Reverted previous changes since Mickael's solution is easier/cleaner and more "maven-friendly".
https://github.com/jbosstools/jbosstools-target-platforms/commits/4.60.x
Here's the job config change:
https://github.com/jbdevstudio/jbdevstudio-ci/commit/0349c99e890e1c1b06dd...
Which results in this order of 8 steps (5 mvn, 3 bash):
* checkout correct branch of code based on the input VERSION = 4.51.1.CR1-SNAPSHOT or 4.51.2.Beta1-SNAPSHOT or 4.60.0.Alpha1-SNAPSHOT
** git checkout ${branch}
* push multiple .target to nexus
** mvn clean deploy -U -e -f multiple/pom.xml
* resolve TP to get site + zip
** mvn install -U -Pmultiple2repo -e -f multiple/pom.xml
* publish the full target platform + zip to dl.jb.o / ds.rh.c
** rsync ...
* since unified .target depends on having published new bits to dl.jb.o / ds.rh.c, we can now build and deploy that
** mvn clean deploy -U -e -f unified/pom.xml
* fetch dependencies for doing install tests
** org.jboss.tools.installation-tests:scripts
** org.jboss.tools.releng:jbosstools-releng-publish
* now, do install tests (which might fail if the Eclipse JEE bundle contains incompatible versions of something in the TP (eg., we include a newer egit or m2e)
** getAndInstallEclipse.groovy ...
** installFromTarget.sh ...
> Why do we deploy TP zips to Nexus snapshots repo?
> -------------------------------------------------
>
> Key: JBIDE-21120
> URL: https://issues.jboss.org/browse/JBIDE-21120
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, updatesite
> Affects Versions: 4.3.0.Final, 4.4.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.3.1.Beta1, 4.4.0.Alpha1
>
>
> Currently, we deploy our TP update sites to the JBoss Nexus snapshots repo.
> {code}
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
> ...
> {code}
> But other than Locus and the Browsersim Standalone zip, we don't ever use these artifacts, so they just:
> * eat disk space in Nexus
> * consume time/resources in Jenkins
> So, why don't we set a custome deployment strategy (eg., akin to *maven.deploy.skip=true*) in the jbosstools-targetplatform & jbosstools-discovery root pom to prevent this waste of time/space? Then we can just deploy the .target files, not the zips.
> This would certainly speed up builds, which currently take 30-60 mins per TP build.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-21120) Why do we deploy TP zips to Nexus snapshots repo?
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21120?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-21120:
------------------------------------
Reverted previous changes since Mickael's solution is easier/cleaner and more "maven-friendly".
https://github.com/jbosstools/jbosstools-target-platforms/commits/4.60.x
Here's the job config change:
https://github.com/jbdevstudio/jbdevstudio-ci/commit/0349c99e890e1c1b06dd...
Which results in this order of 8 steps (5 mvn, 3 bash):
* checkout correct branch of code based on the input VERSION = 4.51.1.CR1-SNAPSHOT or 4.51.2.Beta1-SNAPSHOT or 4.60.0.Alpha1-SNAPSHOT
** git checkout ${branch}
* push multiple .target to nexus
** mvn clean deploy -U -e -f multiple/pom.xml
* resolve TP to get site + zip
** mvn install -U -Pmultiple2repo -e -f multiple/pom.xml
* publish the full target platform + zip to dl.jb.o / ds.rh.c
** rsync ...
* since unified .target depends on having published new bits to dl.jb.o / ds.rh.c, we can now build and deploy that
** mvn clean deploy -U -e -f unified/pom.xml
* fetch dependencies for doing install tests
** org.jboss.tools.installation-tests:scripts
** org.jboss.tools.releng:jbosstools-releng-publish
* now, do install tests (which might fail if the Eclipse JEE bundle contains incompatible versions of something in the TP (eg., we include a newer egit or m2e)
** getAndInstallEclipse.groovy ...
** installFromTarget.sh ...
> Why do we deploy TP zips to Nexus snapshots repo?
> -------------------------------------------------
>
> Key: JBIDE-21120
> URL: https://issues.jboss.org/browse/JBIDE-21120
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, updatesite
> Affects Versions: 4.3.0.Final, 4.4.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.3.1.Beta1, 4.4.0.Alpha1
>
>
> Currently, we deploy our TP update sites to the JBoss Nexus snapshots repo.
> {code}
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
> ...
> {code}
> But other than Locus and the Browsersim Standalone zip, we don't ever use these artifacts, so they just:
> * eat disk space in Nexus
> * consume time/resources in Jenkins
> So, why don't we set a custome deployment strategy (eg., akin to *maven.deploy.skip=true*) in the jbosstools-targetplatform & jbosstools-discovery root pom to prevent this waste of time/space? Then we can just deploy the .target files, not the zips.
> This would certainly speed up builds, which currently take 30-60 mins per TP build.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-15332) why are skipRequirements controlling download of normal maven dependencies ?
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15332?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-15332:
---------------------------------------------
>both download-maven-plugin and maven-dependency-plugin have cache mechanism that makes that a single file is >downloaded only twice.
Yes, that saves time for the download but not for unzipping of the runtime. That continuously happen and what really makes the process slow.
>For "runtime" bundles (such as forge, livereload...) consuming jars and zips to work propertly, we never want to skip the >download of their inner parts. Then, for those, we can simply unset/remove the skip property or force it to false, so we're >sure whenever they build their runtime are copied where necessary (and fetched if necessary).
These are what I call *normal* dependencies and should just always work and no pom doing these should need to do special things (like listing skip stuff at all - the default should just work imo)
>For "tests" bundles, I believe (I'm less sure) that it's about the same: whenever one is going to run the tests, the the artifacts >need to be downloaded.
Often just once; and don't need to be unzipped for quick builds runs.
>So I believe we can set in such bundles (or in their parent pom in component/tests for better >factorization) skip=skipTests. >Since maven-download-plugin already provides the mdep.skip property and download-maven-plugin provides a >download.plugin.skip properties, here are the concrete step I suggest:
>Remove the skipRequirements in parent pom https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml...
I think having a standard property name for it makes sense IMO
> Remove default setting of skip on line 509 and 519
> In components/tests/pom.xml for components that have test requiring runtimes,
YES! This is the actual bug/problem IMO. That we tie a global property into the skip/disable of these plugins that are used for more than just runtime requirements downloads for testing.
> add
> <properties>
> <mdep.skip>${skipTests}</mdep.skip>
> <download.plugin.skip>${skipTests}</download.plugin.skip>
> </properties>
I would make this:
{code:shell}
<properties>
<mdep.skip>${skipRequirements}</mdep.skip>
<download.plugin.skip>${skipRequirements}</download.plugin.skip>
</properties>
{code}
Then you can still do "mvn verify -DskipRequirements=true" and you will have a faster test run.
> why are skipRequirements controlling download of normal maven dependencies ?
> ----------------------------------------------------------------------------
>
> 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: Mickael Istria
> Priority: Minor
> Labels: f2f2014
> Fix For: LATER
>
>
> 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
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-21137) Consistency of sorting in EmbedCartridgesJob
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21137?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-21137:
------------------------------------------
[~scabanovich] thanks for reporting! We're full steam working on providing decent tooling for OpenShift 3 so this will unfortunately have to wait a bit until we can spare time to do v2 maintenance.
> Consistency of sorting in EmbedCartridgesJob
> --------------------------------------------
>
> Key: JBIDE-21137
> URL: https://issues.jboss.org/browse/JBIDE-21137
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.0.Final
> Reporter: Viacheslav Kabanovich
> Priority: Minor
> Labels: openshift_v2
> Fix For: 4.3.x
>
>
> Sorting with CartridgeAddRemovePriorityComparator implies that cartridges should be stored in IApplication in a specific order, for instance, "mysql" should precede all other cartridges. If Edit Embedded Cartridges wizard is run once, the desirable order is guaranteed. However, if wizard is run twice, with "postgresql" selected on the first run and "mysql" added on the second run, the cartridges will be added to IApplication unsorted by the comparator.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months