[JBoss JIRA] (JBIDE-13905) portlet-api library of JPP 6 is not imported
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13905?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-13905:
---------------------------------------------
The existing hardcodings are equally broken.
EAP 6.1 has a different module layout structure so don't assume that will
work if you are hardcoding this.
> portlet-api library of JPP 6 is not imported
> --------------------------------------------
>
> Key: JBIDE-13905
> URL: https://issues.jboss.org/browse/JBIDE-13905
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: Portal/GateIn
> Affects Versions: 4.0.1.Final, 4.1.0.Alpha1
> Reporter: Petr Suchý
> Assignee: Snjezana Peco
> Fix For: 4.1.0.Alpha2
>
>
> When you want to create Dynamic Web Project using JPP 6.0.0.GA, you cannot simply choose Portlet implementation library as a Portlet Target Runtime Provider in a New Dynamic Web Project Wizard. You are forced to add _portlet-api.jar_ manually from here:
> {code}
> ${JPP6}/modules/javax/portlet/api/main/
> {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
13 years, 2 months
[JBoss JIRA] (JBIDE-13934) implement application ready-wait using dns_resolvable
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13934?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-13934:
-------------------------------------
Description:
When waiting for an app to become ready, we simply try to resolve it's hostname and report it ready as soon as we can resolve it.
Apparently there's a cache for DNS resolution that holds entries (successful/unsuccessful resolution) that prevents immediate feedback. The immediate feedback is provided by a RESTful resource on the broker:
{code}
GET https://host/broker/rest/domains/<id>/applications/<id>/dns_resolvable
{code}
Quote from rally
{quote}
1. Who is it for? (e.g. all users, serious developers, paid tier)
All users
2. What product does it apply to? (Online, Enterprise, Origin)
All
3. What is it? What does it do?
A simple broker API check to see if DNS is created via an actual DNS nameserver lookup that is not subject to caching.
4. How do you use it? What is the user impact?
Request:
GET https://host/broker/rest/domains/<id>/applications/<id>/dns_resolvable
Response:
->If DNS is resolvable
HTTP status:200
Body: {"supported_api_versions":[1.0,1.1,1.2],"data":true,"type":"boolean","status":"ok","messages":[],"version":"1.2"}
->If DNS is not resolvable
HTTP status:404
5. Why is it important?
The problem is when a client tool checks to see if DNS is available or not, that value gets cached for a solid 30 seconds. To avoid the cache, queries can be run directly against DYN's DNS servers.
This broker API check to see if DNS is created by querying DNS servers directly.
6. What version number of software, package, client tools, etc?
NA
7. When is it available for GA? (OSE 1.2, Online Sprint #)
Spring 19
8. What tools / software does the docs team need to test it? (if applicable)
NA - already been tested by QE
9. Are there any blog or wiki posts on the subject? (Provide links)
No
10. Any other notes or details that users should know that will help the docs team?
{quote}
was:
When waiting for an app to become ready, we simply try to resolve it's hostname and report it ready as soon as we can resolve it.
Apparently there's a cache for DNS resolution that holds entries (successful/unsuccessful resolution) that prevents immediate feedback. The immediate feedback is provided by a RESTful resource on the broker:
{code}
GET https://host/broker/rest/domains/<id>/applications/<id>/dns_resolvable
{code}
Quote from rally
{quote}
1. Who is it for? (e.g. all users, serious developers, paid tier)
All users
2. What product does it apply to? (Online, Enterprise, Origin)
All
3. What is it? What does it do?
A simple broker API check to see if DNS is created via an actual DNS nameserver lookup that is not subject to caching.
4. How do you use it? What is the user impact?
Request:
GET https://host/broker/rest/domains/<id>/applications/<id>/dns_resolvable
Response:
->If DNS is resolvable
HTTP status:200
Body: {"supported_api_versions":[1.0,1.1,1.2],"data":true,"type":"boolean","status":"ok","messages":[],"version":"1.2"}
->If DNS is not resolvable
HTTP status:404
5. Why is it important?
The problem is when a client tool checks to see if DNS is available or not, that value gets cached for a solid 30 seconds. To avoid the cache, queries can be run directly against DYN's DNS servers.
This broker API check to see if DNS is created by querying DNS servers directly.
6. What version number of software, package, client tools, etc?
NA
7. When is it available for GA? (OSE 1.2, Online Sprint #)
Spring 19
8. What tools / software does the docs team need to test it? (if applicable)
NA - already been tested by QE
9. Are there any blog or wiki posts on the subject? (Provide links)
No
10. Any other notes or details that users should know that will help the docs team?
{quote}
> implement application ready-wait using dns_resolvable
> -----------------------------------------------------
>
> Key: JBIDE-13934
> URL: https://issues.jboss.org/browse/JBIDE-13934
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.1.0.Alpha2
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Fix For: 4.1.x
>
>
> When waiting for an app to become ready, we simply try to resolve it's hostname and report it ready as soon as we can resolve it.
> Apparently there's a cache for DNS resolution that holds entries (successful/unsuccessful resolution) that prevents immediate feedback. The immediate feedback is provided by a RESTful resource on the broker:
> {code}
> GET https://host/broker/rest/domains/<id>/applications/<id>/dns_resolvable
> {code}
> Quote from rally
> {quote}
> 1. Who is it for? (e.g. all users, serious developers, paid tier)
> All users
> 2. What product does it apply to? (Online, Enterprise, Origin)
> All
> 3. What is it? What does it do?
> A simple broker API check to see if DNS is created via an actual DNS nameserver lookup that is not subject to caching.
> 4. How do you use it? What is the user impact?
> Request:
> GET https://host/broker/rest/domains/<id>/applications/<id>/dns_resolvable
> Response:
> ->If DNS is resolvable
> HTTP status:200
> Body: {"supported_api_versions":[1.0,1.1,1.2],"data":true,"type":"boolean","status":"ok","messages":[],"version":"1.2"}
> ->If DNS is not resolvable
> HTTP status:404
> 5. Why is it important?
> The problem is when a client tool checks to see if DNS is available or not, that value gets cached for a solid 30 seconds. To avoid the cache, queries can be run directly against DYN's DNS servers.
> This broker API check to see if DNS is created by querying DNS servers directly.
> 6. What version number of software, package, client tools, etc?
> NA
> 7. When is it available for GA? (OSE 1.2, Online Sprint #)
> Spring 19
> 8. What tools / software does the docs team need to test it? (if applicable)
> NA - already been tested by QE
> 9. Are there any blog or wiki posts on the subject? (Provide links)
> No
> 10. Any other notes or details that users should know that will help the docs team?
> {quote}
--
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
13 years, 2 months
[JBoss JIRA] (JBIDE-13934) implement application ready-wait using dns_resolvable
by Andre Dietisheim (JIRA)
Andre Dietisheim created JBIDE-13934:
----------------------------------------
Summary: implement application ready-wait using dns_resolvable
Key: JBIDE-13934
URL: https://issues.jboss.org/browse/JBIDE-13934
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Components: openshift
Affects Versions: 4.1.0.Alpha2
Reporter: Andre Dietisheim
Assignee: Andre Dietisheim
Fix For: 4.1.x
When waiting for an app to become ready, we simply try to resolve it's hostname and report it ready as soon as we can resolve it.
Apparently there's a cache for DNS resolution that holds entries (successful/unsuccessful resolution) that prevents immediate feedback. The immediate feedback is provided by a RESTful resource on the broker:
{code}
GET https://host/broker/rest/domains/<id>/applications/<id>/dns_resolvable
{code}
Quote from rally
{quote}
1. Who is it for? (e.g. all users, serious developers, paid tier)
All users
2. What product does it apply to? (Online, Enterprise, Origin)
All
3. What is it? What does it do?
A simple broker API check to see if DNS is created via an actual DNS nameserver lookup that is not subject to caching.
4. How do you use it? What is the user impact?
Request:
GET https://host/broker/rest/domains/<id>/applications/<id>/dns_resolvable
Response:
->If DNS is resolvable
HTTP status:200
Body: {"supported_api_versions":[1.0,1.1,1.2],"data":true,"type":"boolean","status":"ok","messages":[],"version":"1.2"}
->If DNS is not resolvable
HTTP status:404
5. Why is it important?
The problem is when a client tool checks to see if DNS is available or not, that value gets cached for a solid 30 seconds. To avoid the cache, queries can be run directly against DYN's DNS servers.
This broker API check to see if DNS is created by querying DNS servers directly.
6. What version number of software, package, client tools, etc?
NA
7. When is it available for GA? (OSE 1.2, Online Sprint #)
Spring 19
8. What tools / software does the docs team need to test it? (if applicable)
NA - already been tested by QE
9. Are there any blog or wiki posts on the subject? (Provide links)
No
10. Any other notes or details that users should know that will help the docs team?
{quote}
--
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
13 years, 2 months
[JBoss JIRA] (JBIDE-13914) Have a test run that runs test plugins for each component in a fully installed JBT
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13914?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-13914:
---------------------------------------------
Yes, I know tycho does not understand eclipse install (at least not until we learn it).
mvn test -Declipse.install=~/runtimes/eclipse/keplerwithjbt
is much nicer than any custom, only possible to run on jenkins kind of setup.
This stuff should not depend on install grinder IMO; we can use install grinder on jenkins to generate the install, but be able to run the tests locally without doing any rebuilding etc. would be a big win.
> Have a test run that runs test plugins for each component in a fully installed JBT
> ----------------------------------------------------------------------------------
>
> Key: JBIDE-13914
> URL: https://issues.jboss.org/browse/JBIDE-13914
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: Build/Releng
> Affects Versions: 4.1.0.Alpha2
> Reporter: Max Rydahl Andersen
> Assignee: Mickael Istria
> Fix For: 4.1.0.Alpha2
>
>
> You said you had a way to run tests against existing install.
> Thus lets get this rolling by having a way to run a components test plugins and its included Test classes in a fully loaded JBoss Tools installation.
--
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
13 years, 2 months
[JBoss JIRA] (JBIDE-13928) Should JBoss Tools and JBDS include org.jboss.tools.maven.apt.feature.source, or just org.jboss.tools.maven.apt.feature?
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13928?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-13928:
---------------------------------------------
It is not blocking alpha2 but i'm wondering why we need this in TP for it to work ? what is special about this component vs another org.jboss.tools.maven.* component ?
> Should JBoss Tools and JBDS include org.jboss.tools.maven.apt.feature.source, or just org.jboss.tools.maven.apt.feature?
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-13928
> URL: https://issues.jboss.org/browse/JBIDE-13928
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: maven, UpStream
> Affects Versions: 4.1.0.Alpha2
> Reporter: Nick Boldt
> Assignee: Fred Bricon
>
> In JBIDE-12310 a source feature was added to org.jboss.tools.maven.apt.feature, but the second part of the JIRA was never done -- adding that feature to JBT and JBDS.
> Today, I attempted to add it, and realized that unless we add org.jboss.tools.maven.apt.feature.source to the target platform it won't be available when creating the JBT or JBDS aggregate sites.
> Do we care? Do we need the sources for this feature/plugin included in JBT and JBDS?
> If we only need it in JBDS I can add the latest m2e mirror to the Central/Extras site [1] and be able to resolve it from there.
> [1] https://devstudio.jboss.com/updates/7.0-development/extras/
--
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
13 years, 2 months
[JBoss JIRA] (JBIDE-13817) aggregate site build should produce junit test output to confirm if the contents of the zips fetched from the upstream composite site match 100% the contents of the produced aggregate site
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13817?page=com.atlassian.jira.plugi... ]
Mickael Istria updated JBIDE-13817:
-----------------------------------
Fix Version/s: 4.1.0.Beta1
(was: 4.1.0.Alpha2)
> aggregate site build should produce junit test output to confirm if the contents of the zips fetched from the upstream composite site match 100% the contents of the produced aggregate site
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-13817
> URL: https://issues.jboss.org/browse/JBIDE-13817
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: Build/Releng, updatesite
> Affects Versions: 4.1.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Mickael Istria
> Fix For: 4.1.0.Beta1
>
>
> The old way to pull zips is with https://github.com/jbosstools/jbosstools-build-sites/blob/master/aggregat... but it is an incomplete solution as it has never verified that the zips were the same content as the aggregate site (they could have changed AFTER the aggregate was built). It also tried to pull the list of zips from a local zip.list.txt file [0] rather than just going right to the composite site.
> [0] http://download.jboss.org/jbosstools/builds/staging/jbosstools-build-site...
> The new way should be an *optional* mojo (runs only for aggregate builds, not individual project builds) which:
> * reads the upstream composite site [1], and
> ** for each child site listed,
> *** downloads a zip matching the last CI build for that project
> **** IFF the contents of that downloaded zip match the IU versions of the aggregate site we just built, then produce a passing JUnit xml report. If the contents differ, return an error report.
> Aggregate jobs will therefore need to be updated to look for these JUnit reports, and mark the build UNSTABLE (yellow) if any non-passing results are found.
> [1] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trunk/,
> There is also this file [2] produced by this job [3], which might make things easier:
> [2] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trun...
> [3] http://hudson.qa.jboss.com/hudson/view/DevStudio/view/DevStudio_Trunk/job...
--
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
13 years, 2 months