[JBoss JIRA] (JBIDE-14122) Add VJET to Central
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14122?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-14122 at 5/1/13 2:46 PM:
------------------------------------------------------------
Reported upstream as https://bugs.eclipse.org/bugs/show_bug.cgi?id=407014
was (Author: nickboldt):
[~dgolovin] Did you open a bugzilla for this at Eclipse? If not, please file one here: https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Vjet
> Add VJET to Central
> -------------------
>
> Key: JBIDE-14122
> URL: https://issues.jboss.org/browse/JBIDE-14122
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: central, target-platform
> Affects Versions: 4.1.0.Beta1
> Reporter: Victor Rubezhny
> Assignee: Victor Rubezhny
> Fix For: 4.1.0.Beta1
>
> Attachments: installing-vjet-from-jbt-mirrors.png, installing-vjet-from-jbt-mirrors2.png, installing-vjet-from-jbt-mirrors3-problem-with-junit4.png, installing-vjet-from-jbt-mirrors4-success.png, installing-vjet-from-jbt-mirrors5-problem-with-junit4-SOLVED.png, JBIDE14122-central-with-vjet.png
>
>
> We should provide an ability to install VJET v.0.10 through Central
> The latest stable VJET Update Site: [http://download.eclipse.org/vjet/updates-0.10] - v.0.10.0, Released
> The following dependencies (in addition to what we already have in TP) are to be satisfied in order to run VJet:
> {code:title=Orbit bundles for VJET}
> <unit id="org.apache.xml.serializer" version="2.7.1.v201005080400"/>
> <unit id="org.apache.xml.resolver" version="1.2.0.v201005080400"/>
> <unit id="org.apache.batik.css" version="1.7.0.v201011041433"/>
> <unit id="org.apache.batik.css.source" version="1.7.0.v201011041433"/>
> <unit id="org.apache.batik.dom" version="1.7.0.v201011041433"/>
> <unit id="org.apache.batik.dom.source" version="1.7.0.v201011041433"/>
> <unit id="org.apache.batik.util" version="1.7.0.v201011041433"/>
> <unit id="org.apache.batik.util.source" version="1.7.0.v201011041433"/>
> <unit id="org.apache.xerces" version="2.9.0.v201101211617"/>
> <unit id="org.ccil.cowan.tagsoup" version="1.2.0.v201202211000"/>
> <unit id="org.w3c.css.sac" version="1.3.1.v200903091627"/>
> <unit id="org.w3c.css.sac.source" version="1.3.1.v200903091627"/>
> <unit id="org.w3c.dom.svg" version="1.1.0.v201011041433"/>
> <unit id="org.w3c.dom.svg.source" version="1.1.0.v201011041433"/>
> <unit id="javax.xml" version="1.3.4.v201005080400"/>
> <unit id="org.apache.commons.collections" version="3.2.0.v2013030210310"/>
> <unit id="org.apache.commons.io" version="2.0.1.v201105210651"/>
> {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, 11 months
[JBoss JIRA] (JBDS-2622) Do we need to add new server types to the installer?
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-2622?page=com.atlassian.jira.plugin.... ]
Denis Golovin resolved JBDS-2622.
---------------------------------
Release Notes Docs Status: Not Required
Resolution: Done
Removed ServerType and ServerTypeTest classes from installer.
Fixed failing JUnit tests.
> Do we need to add new server types to the installer?
> ----------------------------------------------------
>
> Key: JBDS-2622
> URL: https://issues.jboss.org/browse/JBDS-2622
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: installer
> Affects Versions: 7.0.0.Alpha2
> Reporter: Nick Boldt
> Assignee: Denis Golovin
> Fix For: 7.0.0.Beta1
>
>
> Do we need to add a new server type string for EAP 6.1?
> {code:title=https://svn.jboss.org/repos/devstudio/trunk/product/installer/src/panels/com/jboss/jbds/installer/bean/ServerType.java, lines 46-50}
> "Application Server",
> BIN_PATH+File.separatorChar + TWIDDLE_JAR_NAME,
> new String[]{"6.0","5.1", "5.0", "4.2", "4.0", "3.2"}, new ASServerTypeCondition());
>
> public static final ServerType EAP = new ServerType(
> {code}
> {code:title=https://svn.jboss.org/repos/devstudio/trunk/product/installer/src/panels/com/jboss/jbds/installer/bean/ServerType.java, lines 82-86}
> UNKNOWN_STR,
> "",
> new String[]{"6.0", "5.1", "5.0", "4.3", "4.2", "4.0", "3.2"}, null);
> public String toString() {
> {code}
> What about WildFly (AS 8), SOA-P 6, etc.?
--
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, 11 months
[JBoss JIRA] (JBIDE-14364) Select best browser for jQuery Mobile Palette Wizards
by Daniel Azarov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14364?page=com.atlassian.jira.plugi... ]
Daniel Azarov updated JBIDE-14364:
----------------------------------
Description:
Currently adopted algorithm is as follows:
1) Try Mozilla.
2) If it fails then try default browser.
3) If both fail then work without browser.
If Mozilla is available, it is selected. However, Xulrunner does not support jQuery Mobile 1.3, and then wizards for new widgets cannot be represented in preview (e.g. Range Slider, Panel, Table).
We also have to take into account, that for specific widgets some browsers may have specific bugs. As a result it may be that each wizard may have its own best and worst browser. A general solution is to let each wizard override the default algorithm.
Test results:
||Browser||Issues||
|Windows 8, Webkit (Safari)|Range Slider - sometimes mouse click on slider makes them stack together|
was:
Currently adopted algorithm is as follows:
1) Try Mozilla.
2) If it fails then try default browser.
3) If both fail then work without browser.
If Mozilla is available, it is selected. However, Xulrunner does not support jQuery Mobile 1.3, and then wizards for new widgets cannot be represented in preview (e.g. Range Slider, Panel, Table).
We also have to take into account, that for specific widgets some browsers may have specific bugs. As a result it may be that each wizard may have its own best and worst browser. A general solution is to let each wizard override the default algorithm.
> Select best browser for jQuery Mobile Palette Wizards
> -----------------------------------------------------
>
> Key: JBIDE-14364
> URL: https://issues.jboss.org/browse/JBIDE-14364
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: jsp/jsf/xml/html source editing
> Reporter: Viacheslav Kabanovich
> Assignee: Viacheslav Kabanovich
> Labels: new_and_noteworthy
> Fix For: 4.1.0.Beta1
>
>
> Currently adopted algorithm is as follows:
> 1) Try Mozilla.
> 2) If it fails then try default browser.
> 3) If both fail then work without browser.
> If Mozilla is available, it is selected. However, Xulrunner does not support jQuery Mobile 1.3, and then wizards for new widgets cannot be represented in preview (e.g. Range Slider, Panel, Table).
> We also have to take into account, that for specific widgets some browsers may have specific bugs. As a result it may be that each wizard may have its own best and worst browser. A general solution is to let each wizard override the default algorithm.
> Test results:
> ||Browser||Issues||
> |Windows 8, Webkit (Safari)|Range Slider - sometimes mouse click on slider makes them stack together|
--
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, 11 months
[JBoss JIRA] (JBDS-2623) Create target platform for mirrored parts of Central / 3rd Party Extras
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-2623?page=com.atlassian.jira.plugin.... ]
Nick Boldt updated JBDS-2623:
-----------------------------
Description:
As discussed in JBDS-2486 ( https://issues.jboss.org/browse/JBDS-2486?focusedCommentId=12770186&page=... ) we need to produce a target file for use with Central.
Goal here would be to build the Extras site (used by Central) as a TP update site rather than a composite of mirrors, which would provide us with a manifest of exactly which versions of these duped IUs were to be contained in the Extras site. If something bad happens, we can add duplicate versions of IUs to the TP and know exactly why we include both Jetty 8.1.3 and 8.1.9 (for example) or two different spins of WindowBuilder. This would mean it wouldn't matter if we filtered content out of the mirrors, because we'd be handling the filtering in a single place (extras.target) rather than multiple build.xml files.
In future, we would:
* mirror the individual upstream projects into /updates/requirements/<project> [on dl.jb.org]
* mirror the individual upstream projects into /updates/requirements/<project> [on www.qa]
* produce an aggregate of the stuff that Central needs, and publish that instead of the composite [on dl.jb.org]
* produce an aggregate of the stuff that Central needs, and publish that instead of the composite [on www.qa]
* produce an aggregate of the stuff that Central needs, and publish that instead of the composite [on ds.jb.com]
* add a whole new aggregate for old + new content
was:
As discussed in JBDS-2486 ( https://issues.jboss.org/browse/JBDS-2486?focusedCommentId=12770186&page=... ) we need to produce a target file for use with Central.
Goal here would be to build the Extras site (used by Central) as a TP update site rather than a composite of mirrors, which would provide us with a manifest of exactly which versions of these duped IUs were to be contained in the Extras site. If something bad happens, we can add duplicate versions of IUs to the TP and know exactly why we include both Jetty 8.1.3 and 8.1.9 (for example) or two different spins of WindowBuilder. This would mean it wouldn't matter if we filtered content out of the mirrors, because we'd be handling the filtering in a single place (extras.target) rather than multiple build.xml files.
In future, we would:
* mirror the individual upstream projects into /updates/requirements/<project> [on dl.jb.org] [283M]
* mirror the individual upstream projects into /updates/requirements/<project> [on www.qa] [283M]
* produce an aggregate of the stuff that Central needs, and publish that instead of the composite [on dl.jb.org] [283M]
* produce an aggregate of the stuff that Central needs, and publish that instead of the composite [on www.qa] [283M]
* produce an aggregate of the stuff that Central needs, and publish that instead of the composite [on ds.jb.com] [283M]
* add a whole new aggregate for old + new content, eg., a new version of GWT will add another 283M each time, not 166M.
> Create target platform for mirrored parts of Central / 3rd Party Extras
> -----------------------------------------------------------------------
>
> Key: JBDS-2623
> URL: https://issues.jboss.org/browse/JBDS-2623
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: 3rdPartyCertification, 3rdPartyDependencies, central, updatesite, Upstream
> Affects Versions: 7.0.0.Beta1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 7.0.0.Beta1
>
>
> As discussed in JBDS-2486 ( https://issues.jboss.org/browse/JBDS-2486?focusedCommentId=12770186&page=... ) we need to produce a target file for use with Central.
> Goal here would be to build the Extras site (used by Central) as a TP update site rather than a composite of mirrors, which would provide us with a manifest of exactly which versions of these duped IUs were to be contained in the Extras site. If something bad happens, we can add duplicate versions of IUs to the TP and know exactly why we include both Jetty 8.1.3 and 8.1.9 (for example) or two different spins of WindowBuilder. This would mean it wouldn't matter if we filtered content out of the mirrors, because we'd be handling the filtering in a single place (extras.target) rather than multiple build.xml files.
> In future, we would:
> * mirror the individual upstream projects into /updates/requirements/<project> [on dl.jb.org]
> * mirror the individual upstream projects into /updates/requirements/<project> [on www.qa]
> * produce an aggregate of the stuff that Central needs, and publish that instead of the composite [on dl.jb.org]
> * produce an aggregate of the stuff that Central needs, and publish that instead of the composite [on www.qa]
> * produce an aggregate of the stuff that Central needs, and publish that instead of the composite [on ds.jb.com]
> * add a whole new aggregate for old + new content
--
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, 11 months
[JBoss JIRA] (JBDS-2484) 3rd party certification for JBDS 7.x (JBDS70_1211)
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-2484?page=com.atlassian.jira.plugin.... ]
Nick Boldt updated JBDS-2484:
-----------------------------
Description:
For JBDS 7, we need to ensure this list is as current and up to date as possible.
The current list of Extras/Central connectors that we mirror are:
* atlassian/3.0.6.v20120628 --> 3.2.0.v20130212 - JBIDE-13670, JBIDE-13682
* gwt/3.1.0.v201208080121-rel-r42 --> 3.2.1 - JBDS-2486
* springide/2.7.2.201109122348 --> 3.2.0 - JBDS-2395
* subclipse/1.8.16_1.7.5.v1 --> 1.8.18_1.7.8.1 - JBDS-2485
* testng/6.7.0.20120825_1316 --> 6.8.0.20121120_1820 - JBDS-2415
* VJET 0.10 - JBIDE-14122
These are currently unchanged since December when we released JBDS 6.0.0:
* eclipsecs/5.6.0.201209221626 - nothing new as of 2013.03.22
* findbugs/2.0.2.20121210 - nothing new as of 2013.03.22
* pmd/3.2.6 - nothing new as of 2013.03.22
Additionally:
* egit/2.3.1.201302201838-r - JBIDE-13629 (not included in Kepler M5, but in M6; not part of Central as this is included in TP / Core)
* swtbot 2.1 / junit4 - JBIDE-13843 (included in JBT TP; needed for running UI tests)
See comments below for latest site URLs.
was:
For JBDS 7, we need to ensure this list is as current and up to date as possible.
The current list of Extras/Central connectors that we mirror are:
* atlassian/3.0.6.v20120628 --> 3.2.0.v20130212 - JBIDE-13670, JBIDE-13682
* gwt/3.1.0.v201208080121-rel-r42 --> 3.2.1 - JBDS-2486
* springide/2.7.2.201109122348 --> 3.2.0 - JBDS-2395
* subclipse/1.8.16_1.7.5.v1 --> 1.8.18_1.7.8.1 - JBDS-2485
* testng/6.7.0.20120825_1316 --> 6.8.0.20121120_1820 - JBDS-2415
These are currently unchanged since December when we released JBDS 6.0.0:
* eclipsecs/5.6.0.201209221626 - nothing new as of 2013.03.22
* findbugs/2.0.2.20121210 - nothing new as of 2013.03.22
* pmd/3.2.6 - nothing new as of 2013.03.22
Additionally:
* egit/2.3.1.201302201838-r - JBIDE-13629 (not included in Kepler M5, but in M6; not part of Central as this is included in TP / Core)
* swtbot 2.1 / junit4 - JBIDE-13843 (included in JBT TP; needed for running UI tests)
See comments below for latest site URLs.
> 3rd party certification for JBDS 7.x (JBDS70_1211)
> --------------------------------------------------
>
> Key: JBDS-2484
> URL: https://issues.jboss.org/browse/JBDS-2484
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: 3rdPartyCertification, 3rdPartyDependencies, Requirements
> Affects Versions: 7.0.0.Alpha1
> Reporter: Max Rydahl Andersen
> Assignee: Len DiMaggio
> Priority: Blocker
> Fix For: 7.0.0.Beta1
>
>
> For JBDS 7, we need to ensure this list is as current and up to date as possible.
> The current list of Extras/Central connectors that we mirror are:
> * atlassian/3.0.6.v20120628 --> 3.2.0.v20130212 - JBIDE-13670, JBIDE-13682
> * gwt/3.1.0.v201208080121-rel-r42 --> 3.2.1 - JBDS-2486
> * springide/2.7.2.201109122348 --> 3.2.0 - JBDS-2395
> * subclipse/1.8.16_1.7.5.v1 --> 1.8.18_1.7.8.1 - JBDS-2485
> * testng/6.7.0.20120825_1316 --> 6.8.0.20121120_1820 - JBDS-2415
> * VJET 0.10 - JBIDE-14122
> These are currently unchanged since December when we released JBDS 6.0.0:
> * eclipsecs/5.6.0.201209221626 - nothing new as of 2013.03.22
> * findbugs/2.0.2.20121210 - nothing new as of 2013.03.22
> * pmd/3.2.6 - nothing new as of 2013.03.22
> Additionally:
> * egit/2.3.1.201302201838-r - JBIDE-13629 (not included in Kepler M5, but in M6; not part of Central as this is included in TP / Core)
> * swtbot 2.1 / junit4 - JBIDE-13843 (included in JBT TP; needed for running UI tests)
> See comments below for latest site URLs.
--
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, 11 months
[JBoss JIRA] (JBDS-2623) Create target platform for mirrored parts of Central / 3rd Party Extras
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-2623?page=com.atlassian.jira.plugin.... ]
Nick Boldt updated JBDS-2623:
-----------------------------
Description:
As discussed in JBDS-2486 ( https://issues.jboss.org/browse/JBDS-2486?focusedCommentId=12770186&page=... ) we need to produce a target file for use with Central.
Goal here would be to build the Extras site (used by Central) as a TP update site rather than a composite of mirrors, which would provide us with a manifest of exactly which versions of these duped IUs were to be contained in the Extras site. If something bad happens, we can add duplicate versions of IUs to the TP and know exactly why we include both Jetty 8.1.3 and 8.1.9 (for example) or two different spins of WindowBuilder. This would mean it wouldn't matter if we filtered content out of the mirrors, because we'd be handling the filtering in a single place (extras.target) rather than multiple build.xml files.
In future, we would:
* mirror the individual upstream projects into /updates/requirements/<project> [on dl.jb.org] [283M]
* mirror the individual upstream projects into /updates/requirements/<project> [on www.qa] [283M]
* produce an aggregate of the stuff that Central needs, and publish that instead of the composite [on dl.jb.org] [283M]
* produce an aggregate of the stuff that Central needs, and publish that instead of the composite [on www.qa] [283M]
* produce an aggregate of the stuff that Central needs, and publish that instead of the composite [on ds.jb.com] [283M]
* add a whole new aggregate for old + new content, eg., a new version of GWT will add another 283M each time, not 166M.
was:As discussed in JBDS-2486 ( https://issues.jboss.org/browse/JBDS-2486?focusedCommentId=12770186&page=... ) we need to produce a target file for use with Central.
> Create target platform for mirrored parts of Central / 3rd Party Extras
> -----------------------------------------------------------------------
>
> Key: JBDS-2623
> URL: https://issues.jboss.org/browse/JBDS-2623
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: 3rdPartyCertification, 3rdPartyDependencies, central, updatesite, Upstream
> Affects Versions: 7.0.0.Beta1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 7.0.0.Beta1
>
>
> As discussed in JBDS-2486 ( https://issues.jboss.org/browse/JBDS-2486?focusedCommentId=12770186&page=... ) we need to produce a target file for use with Central.
> Goal here would be to build the Extras site (used by Central) as a TP update site rather than a composite of mirrors, which would provide us with a manifest of exactly which versions of these duped IUs were to be contained in the Extras site. If something bad happens, we can add duplicate versions of IUs to the TP and know exactly why we include both Jetty 8.1.3 and 8.1.9 (for example) or two different spins of WindowBuilder. This would mean it wouldn't matter if we filtered content out of the mirrors, because we'd be handling the filtering in a single place (extras.target) rather than multiple build.xml files.
> In future, we would:
> * mirror the individual upstream projects into /updates/requirements/<project> [on dl.jb.org] [283M]
> * mirror the individual upstream projects into /updates/requirements/<project> [on www.qa] [283M]
> * produce an aggregate of the stuff that Central needs, and publish that instead of the composite [on dl.jb.org] [283M]
> * produce an aggregate of the stuff that Central needs, and publish that instead of the composite [on www.qa] [283M]
> * produce an aggregate of the stuff that Central needs, and publish that instead of the composite [on ds.jb.com] [283M]
> * add a whole new aggregate for old + new content, eg., a new version of GWT will add another 283M each time, not 166M.
--
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, 11 months
[JBoss JIRA] (JBIDE-14364) Select best browser for jQuery Mobile Palette Wizards
by Viacheslav Kabanovich (JIRA)
Viacheslav Kabanovich created JBIDE-14364:
---------------------------------------------
Summary: Select best browser for jQuery Mobile Palette Wizards
Key: JBIDE-14364
URL: https://issues.jboss.org/browse/JBIDE-14364
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: jsp/jsf/xml/html source editing
Reporter: Viacheslav Kabanovich
Assignee: Viacheslav Kabanovich
Fix For: 4.1.0.Beta1
Currently adopted algorithm is as follows:
1) Try Mozilla.
2) If it fails then try default browser.
3) If both fail then work without browser.
If Mozilla is available, it is selected. However, Xulrunner does not support jQuery Mobile 1.3, and then wizards for new widgets cannot be represented in preview (e.g. Range Slider, Panel, Table).
We also have to take into account, that for specific widgets some browsers may have specific bugs. As a result it may be that each wizard may have its own best and worst browser. A general solution is to let each wizard override the default algorithm.
--
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, 11 months