[JBoss JIRA] (JBIDE-11259) BrowserSim: broken layout on Linux
by Konstantin Marmalyukov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-11259?page=com.atlassian.jira.plugi... ]
Konstantin Marmalyukov updated JBIDE-11259:
-------------------------------------------
Fix Version/s: 4.2.x
(was: 4.1.x)
> BrowserSim: broken layout on Linux
> ----------------------------------
>
> Key: JBIDE-11259
> URL: https://issues.jboss.org/browse/JBIDE-11259
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: browsersim
> Affects Versions: 3.3.0.Beta1
> Reporter: Yahor Radtsevich
> Assignee: Konstantin Marmalyukov
> Fix For: 4.2.x
>
> Attachments: BrowserSim_BrokenRender.png, screenshot-1.png
>
>
> *Steps to reproduce:*
> # Run BrowserSim on Linux (I used Ubuntu Linux 11.10 x86_64)
> # Check 'Use Skins' if it is not checked.
> # Select 'Samsung Galaxy Tab 10.1' skin
> # Click 'Turn Left' several times.
> *Actual result:*
> From time to time the layout of the window is broken:
> !screenshot-1.png|thumbnail!
> *Update:*
> Video created by [~rhopp]: http://youtu.be/HKN7hnLQOz8
--
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, 9 months
[JBoss JIRA] (JBIDE-14586) Install Tests does not use latest TP
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14586?page=com.atlassian.jira.plugi... ]
Mickael Istria resolved JBIDE-14586.
------------------------------------
Resolution: Done
Current solution (using discovery site which references latest JBT and TP sites from the right branch) makes sure we do provide the latest TP during installation-tests.
The few additional stuff we add shouldn't create false positive as Nick explained, so marking this issue resolved.
> Install Tests does not use latest TP
> ------------------------------------
>
> Key: JBIDE-14586
> URL: https://issues.jboss.org/browse/JBIDE-14586
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: Build/Releng
> Affects Versions: 4.1.0.Alpha2
> Reporter: Mickael Istria
> Assignee: Mickael Istria
> Fix For: 4.1.0.CR1
>
>
> Install-Grinder, in its current state, uses TP referenced by aggregate site rather than the one we build against.
> This is mainly because of the referenced repository in jbosstools-build-site/aggregate/site/pom.xml
> Long version
> {code}
> Install test to control TP version used at install time
> Status: updates/kepler is still 4.30.5.Alpha3
> Dev site http://download.jboss.org/jbosstools/discovery/nightly/core/trunk/ links to http://download.jboss.org/jbosstools/updates/kepler/ which links to ../../targetplatforms/jbosstoolstarget/4.30.5.Alpha3/REPO/
> When to update it? It's required to change it for correct installation tests
> Time to update: after Alpha2 is no longer the defacto release? Did you want all those users to break suddenly? ~nboldt
> No, you can do install tests using the discovery site:
> http://download.jboss.org/jbosstools/discovery/nightly/core/4.1.kepler/co... (contains the correct version of JBT, TP, and Extras for 4.1.kepler stable branch (which is currently Beta1)
> Suggestion 0 (Mickael): Can't we directly use url http://download.jboss.org/tools/targetplatforms/${tpc.version}/REPO in aggregated site?
> We could, yes. https://github.com/jbosstools/jbosstools-build-sites/blob/master/aggregat... However, that means we would need to keep old TP sites around longer (?)
> At least keep TP releases forever
> Drawback: Static link to static URL will make Eclipse keep reference to older site even if we are updating
> Suggestion 1 (Max): use relative path for references in aggregate site
> example:
> core/trunk/ -> p2 ref to ./tpc (assumes relative link works for p2.??? <-- what property is it?) => It's the "repository" element inside "references" in content.jar/xml (on site) and in https://github.com/jbosstools/jbosstools-build-sites/blob/master/aggregat...
> core/trunk/tpc -> composite link to TPC (will be ${tpc.version}/REPO in ci's, but gets updated to updates/kepler on staging
> Sounds good, but p2 does not accept relative reference
> Suggestion 2 (Max): Test composite
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS... tests http://download.jboss.org/jbosstools/builds/staging/_composite_/core/{tru...
> Then nothing tests the aggregate site, which is error prone => Not good
> Suggestion 3 (Nick): Using different "quality" sites for references (just like JBDS)
> TODO: generate TWO aggregates: one w/ references to TP, one with none
> http://download.jboss.org/jbosstools/updates/kepler/ <-- each stable milestone and release
> http://download.jboss.org/jbosstools/updates/kepler/staging/ <-- use this for QE
> End users want one site w/ all TP refs embedded (one site does everything)
> Max thinks QE wants a site that has NO references so it's easier to test
> For JBDS we use this:
> https://devstudio.jboss.com/updates/7.0-staging/ (QE pre-milestone)
> https://devstudio.jboss.com/updates/7.0-development/ (latest milestone)
> https://devstudio.jboss.com/updates/7.0/ (eventual GA)
> And when installing, this happens:
> https://svn.jboss.org/repos/devstudio/trunk/product/features/com.jboss.jb...
> Suggestion 4 (Max):
> Generate aggreate WITHOUT references to TP
> Generate composite that references ^^^ + TP <==
> No reference is the only valid long-term solution
> Suggestion 5 (Max & Mickael): Allow more control on install-grinder to ensure we can explicitly use right sites
> install-grinder --site http://download.jboss.org/jbosstools/discovery/nightly/core/trunk/ --site http://download.jboss.org/tools/targetplatforms/${tpc.version}/REPO
> ACTION: Mistria, makes
> install-grinder --removeAllSites --addRef http://download.jboss.org/tools/targetplatforms/${tpc.version}/REPO --installSite http://download.jboss.org/jbosstools/discovery/nightly/core/trunk/
> @Pavol already did something for that: https://github.com/jbosstools/jbosstools-install-grinder/blob/master/plug...
> Pitfall: Not perfect util we stop setting references in aggregate.
> {code}
--
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, 9 months
[JBoss JIRA] (JBIDE-15059) Server adapter: tells me that there are local commits that I can publish even though there are none
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15059?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-15059:
---------------------------------------------
is this what egit do when pushing ? it pushes and then fetch ?
> Server adapter: tells me that there are local commits that I can publish even though there are none
> ---------------------------------------------------------------------------------------------------
>
> Key: JBIDE-15059
> URL: https://issues.jboss.org/browse/JBIDE-15059
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.1.0.CR1
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Fix For: 4.1.0.CR1, 4.2.0.Alpha1
>
> Attachments: already-up-to-date.png, committed-changes-to-publish.png, is-ahead-0.png, is-ahead-1.png
>
>
> 1. EXEC: launch OpenShift Application wizard
> 2. EXEC: create a new application and have it imported to your workspace
> 3. EXEC: After the import the adapter will tell you that there are local commits that you may want to publish to OpenShift. Tell it to do so by hitting *Yes*
> !committed-changes-to-publish.png!
> 4. ASSERT: In the Package Explorer: the freshly imported project is decorated with an arrow an a 1 (is ahead of origin by 1)
> !is-ahead-1.png! (*wrong!* since we pushed)
> 5. EXEC: Pick your server adapter and tell it to publish to OpenShift
> Result:
> The adapter tells you that you that there are local commits that you may push. (*wrong!*)
> !committed-changes-to-publish.png!
> Expected:
> We just pushed there cannot be local commits that were not pushed yet
> 6. EXEC: Confirm the dialog and tell it to publish
> Result:
> It tells you that OpenShift is already up-to-date (which is true!)
> !already-up-to-date.png!
> 7. EXEC: pick Team->Fetch from Upstream
> 8 ASSERT:
> The remote "is ahead of" state of the current branch compared to origin is updated. The EGit decorators in the Project Explorer get corrected (the ^1 gets removed).
> !is-ahead-0.png!
> If you now publish via adapter it'll tell you that there are no local changes that you can push.
--
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, 9 months
[JBoss JIRA] (JBDS-2673) Can't build JBDS because of p2.mirrors
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-2673?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-2673:
-------------------------------------------
This line was added in r11616:
max@slowbeard:(master|…) $ svn log -r 11616 pom.xml ~/code/devstudio/trunk/product
------------------------------------------------------------------------
r11616 | nickboldt | 2013-04-18 00:11:30 +0200 (Thu, 18 Apr 2013) | 1 line
JBDS-2548 add TODO re: GPE in JBDS TP so jboss-requirements-composite-extras-mirror profile is no longer needed; set tpc.targetKind=multiple so users can build w/o VPN; set tpc.version=TARGET_PLATFORM_VERSION_MAXIMUM by default
------------------------------------------------------------------------
Not sure why [~nickboldt] want the default to be something we know is broken. Maybe it was added for external builders but that is not what we want to do for release build.
I think we should just use the default (unified) and those who want to use multiple can use -Dtpc.targetKind=multiple or any other documented way for that.
> Can't build JBDS because of p2.mirrors
> --------------------------------------
>
> Key: JBDS-2673
> URL: https://issues.jboss.org/browse/JBDS-2673
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: updatesite
> Reporter: Nick Boldt
> Assignee: Mickael Istria
>
> Tried to build JBDS 7.0.0.CR1 tonight in Jenkins, but got this instead:
> {code:title=https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevStudio_7.0.kepler/job/devstudio.product_70/347/console}
> [ERROR] Internal error: java.lang.RuntimeException: "Messages while reading artifacts from child repositories": ["Problems while reading artifacts from http://download.jboss.org/jbosstools/updates/requirements/kepler/20130626...": ["Retry another mirror": ["HTTP Server 'Service Unavailable': http://ftp.ussg.iu.edu/eclipse/releases/kepler/201306260900/plugins/org.e..."], "Retry another mirror": ["HTTP Server 'Service Unavailable': http://ftp.ussg.iu.edu/eclipse/releases/kepler/201306260900/plugins/org.e..."]]] -> [Help 1]
> {code}
> I thought we were filtering out all the external references from the metadata after we mirrored?
--
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, 9 months
[JBoss JIRA] (JBIDE-15063) Bad display of download size
by Fred Bricon (JIRA)
Fred Bricon created JBIDE-15063:
-----------------------------------
Summary: Bad display of download size
Key: JBIDE-15063
URL: https://issues.jboss.org/browse/JBIDE-15063
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: common/jst/core
Affects Versions: 4.1.0.CR1
Reporter: Fred Bricon
Assignee: Rob Stryker
Priority: Minor
Fix For: 4.1.0.CR1, 4.2.0.Alpha1
When downloading stacks from Central (click on the html5 project after starting your workspace), the dialog shows the total size of the file is -1 Byte
!https://issues.jboss.org/secure/attachment/12363524/12363524_download_stacks.png!
Can you see if a trivial fix is doable for CR1? Else we punt it to the next version
--
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, 9 months