[JBoss JIRA] (JBIDE-15482) Replace staging & staging.previous (two builds w/ reused URLs) with uniquely timestamped build URLs and auto-regenerated composite*.xml files
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15482?page=com.atlassian.jira.plugi... ]
Denis Golovin edited comment on JBIDE-15482 at 3/10/14 3:42 PM:
----------------------------------------------------------------
I just noticed we're back to using just one nightly repo per component nightly build after JBIDE-16309 was fixed, because all sites now points to all/repo and it is not a composite repository.
was (Author: dgolovin):
I just noticed we'r back to using just one nightly repo per component nightly build after JBIDE-16309 was fixed, because all sites now points to all/repo and it is not a composite repository.
> Replace staging & staging.previous (two builds w/ reused URLs) with uniquely timestamped build URLs and auto-regenerated composite*.xml files
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-15482
> URL: https://issues.jboss.org/browse/JBIDE-15482
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: build, updatesite
> Reporter: Nick Boldt
> Assignee: Denis Golovin
> Fix For: 4.2.x
>
>
> Be it proposed:
> {quote}
> that instead of an in-place move which reuses
> generic folder names like "staging" and "staging.previous", we
> composite build output using unique names like
> 2013-08-09_05-05-26-B7222/ or 2013-08-13_10-05-28-B7255
> {quote}
> We therefore need:
> a) to regenerate the composite site each time there's a new build
> published, in order to remove the oldest and add the newest (keeping
> only the Nth and N-1rst builds)
> (I have a script that might already work for this, or would need
> tweaking.)
> b) heuristics to determine when an older (N-2, N-3, ... N-z) build is
> no longer needed, perhaps simply by assuming no one needs it after
> 24hrs?
> 24 hours should be more that enough.
> c) a cleanup script which can purge all but the builds which are no
> more than 1 day old, keeping at all times at least two builds (N and
> N-1)
> (I have a script that already does this for folders like
> http://download.jboss.org/jbosstools/builds/nightly/core/trunk/ but
> might need to be tweaked to work for a new pattern of
> staging/\$\{JOB_NAME}/<BUILD_ID>/ .)
> {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
12 years, 3 months
[JBoss JIRA] (JBIDE-15482) Replace staging & staging.previous (two builds w/ reused URLs) with uniquely timestamped build URLs and auto-regenerated composite*.xml files
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15482?page=com.atlassian.jira.plugi... ]
Denis Golovin commented on JBIDE-15482:
---------------------------------------
I just noticed we'r back to using just one nightly repo per component nightly build after JBIDE-16309 was fixed, because all sites now points to all/repo and it is not a composite repository.
> Replace staging & staging.previous (two builds w/ reused URLs) with uniquely timestamped build URLs and auto-regenerated composite*.xml files
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-15482
> URL: https://issues.jboss.org/browse/JBIDE-15482
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: build, updatesite
> Reporter: Nick Boldt
> Assignee: Denis Golovin
> Fix For: 4.2.x
>
>
> Be it proposed:
> {quote}
> that instead of an in-place move which reuses
> generic folder names like "staging" and "staging.previous", we
> composite build output using unique names like
> 2013-08-09_05-05-26-B7222/ or 2013-08-13_10-05-28-B7255
> {quote}
> We therefore need:
> a) to regenerate the composite site each time there's a new build
> published, in order to remove the oldest and add the newest (keeping
> only the Nth and N-1rst builds)
> (I have a script that might already work for this, or would need
> tweaking.)
> b) heuristics to determine when an older (N-2, N-3, ... N-z) build is
> no longer needed, perhaps simply by assuming no one needs it after
> 24hrs?
> 24 hours should be more that enough.
> c) a cleanup script which can purge all but the builds which are no
> more than 1 day old, keeping at all times at least two builds (N and
> N-1)
> (I have a script that already does this for folders like
> http://download.jboss.org/jbosstools/builds/nightly/core/trunk/ but
> might need to be tweaked to work for a new pattern of
> staging/\$\{JOB_NAME}/<BUILD_ID>/ .)
> {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
12 years, 3 months
[JBoss JIRA] (JBIDE-16720) Allow easier access to openshift operations from jboss servers
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16720?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-16720:
------------------------------------------
Not fully sure if the following is correct:
{quote}
Unfortunately there is currently no obvious distinction for a user between #1 and #2.
{quote}
In openshift-java-client you can ask an ItandaloneCartrdige#isDownloadable which will return *true* in case the cartridge has a valid url (which is not the case for built-ins).
https://github.com/openshift/openshift-java-client/blob/master/src/main/j...
https://github.com/openshift/openshift-java-client/blob/master/src/main/j...
{code}
@Override
public boolean isDownloadable() {
return url != null;
}
{code}
What do I miss?
> Allow easier access to openshift operations from jboss servers
> --------------------------------------------------------------
>
> Key: JBIDE-16720
> URL: https://issues.jboss.org/browse/JBIDE-16720
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift, server
> Affects Versions: 4.1.1.Final
> Reporter: Mark Drilling
>
> We currently have a couple issues with connecting to an OpenShift Data Virtualization instance from the tooling. I'm aware that issues are being addressed for future release, others I'm not sure. This is intended to help guide your development to accommodate this use case.
> Our expected usage with Data Virtualization is a bit different than some others. With DV we expect to deploy via a DV cartridge to OpenShift, then connect to the OpenShift DV instance as a remote server. We typically would not deploy using git push.
> Currently, we connect to an OpenShift DV instance like this:
> 1) Deploy DV cartridge via OpenShift web console.
> 2) Port forward from command line using rhc port-forward
> 3) Set up EAP server instance in the tooling, mark as externally managed and start it. From there we can connect to the DV instance and continue with modeling and deployments in Teiid Designer perspective
> The issues we observed:
> 1) Creation of the OpenShift 'server' forces a git repo to be copied locally. We'd like to simply create the 'OpenShift server' without cloning the repo.
> 2) Can't deploy our downloadable cartridge from the wizard. I believe OpenShift is now (or will soon) allow downloadable carts to be registered, so this problem should be solved as the cart will show up in the cartridge list.
> Our current method of connecting is ok for now, but a simpler usage of the OpenShift server adapter would allow us to more easily manage the instance (e.g. port-forward without going to the command line, viewing logs, 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, 3 months
[JBoss JIRA] (JBIDE-16720) Allow easier access to openshift operations from jboss servers
by Mark Drilling (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16720?page=com.atlassian.jira.plugi... ]
Mark Drilling edited comment on JBIDE-16720 at 3/10/14 3:27 PM:
----------------------------------------------------------------
Heres explanation from Ben Parees (OpenShift) on the current state of cartridges
v========================================v
So essentially there are 3 types of cartridges now:
1) system cartridges (rpm based, maintained by openshift team) - appear on the web page and in rhc cartridge list
2) imported downloadable cartridges (downloadable cartridge, but imported so they show up in the same places as system cartridges)
3) non-imported downloadable cartridges - these do not explicitly show up anywhere. The historic way to promote a downloadable cartridge was to create a quickstart based on it, and promote the quickstart.
Unfortunately there is currently no obvious distinction for a user between #1 and #2.
Both the site and command line indicate cartridges which do not receive automatic security updates, which for now is effectively the same as being an imported downloadable cartridge, but it's not explicit that the cartridge is downloadable.
========================================
I think 2) is a new feature and seems to be the way they prefer to register the cartridges now. I'm not sure how the import works, but it will apparently then show up same as system cartridges. If that is the case, it will be available in the wizard's drop-down with everything else.
And yes about the localhost issue. (Can't use the openshift hostname because of the port forwarding.)
was (Author: mdrillin):
Heres explanation from Ben Parees (OpenShift) on the current state of cartridges
v========================================v
So essentially there are 3 types of cartridges now:
1) system cartridges (rpm based, maintained by openshift team)
- appear on the web page and in rhc cartridge list
2) imported downloadable cartridges (downloadable cartridge, but imported so they show up in the same places as system cartridges)
3) non-imported downloadable cartridges - these do not explicitly show up anywhere. The historic way to promote a downloadable cartridge was to create a quickstart based on it, and promote the quickstart.
Unfortunately there is currently no obvious distinction for a user between #1 and #2.
Both the site and command line indicate cartridges which do not receive automatic security updates, which for now is effectively the same as being an imported downloadable cartridge, but it's not explicit that the cartridge is downloadable.
^========================================^
I think 2) is a new feature and seems to be the way they prefer to register the cartridges now. I'm not sure how the import works, but it will apparently then show up same as system cartridges. If that is the case, it will be available in the wizard's drop-down with everything else.
And yes about the localhost issue. (Can't use the openshift hostname because of the port forwarding.)
> Allow easier access to openshift operations from jboss servers
> --------------------------------------------------------------
>
> Key: JBIDE-16720
> URL: https://issues.jboss.org/browse/JBIDE-16720
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift, server
> Affects Versions: 4.1.1.Final
> Reporter: Mark Drilling
>
> We currently have a couple issues with connecting to an OpenShift Data Virtualization instance from the tooling. I'm aware that issues are being addressed for future release, others I'm not sure. This is intended to help guide your development to accommodate this use case.
> Our expected usage with Data Virtualization is a bit different than some others. With DV we expect to deploy via a DV cartridge to OpenShift, then connect to the OpenShift DV instance as a remote server. We typically would not deploy using git push.
> Currently, we connect to an OpenShift DV instance like this:
> 1) Deploy DV cartridge via OpenShift web console.
> 2) Port forward from command line using rhc port-forward
> 3) Set up EAP server instance in the tooling, mark as externally managed and start it. From there we can connect to the DV instance and continue with modeling and deployments in Teiid Designer perspective
> The issues we observed:
> 1) Creation of the OpenShift 'server' forces a git repo to be copied locally. We'd like to simply create the 'OpenShift server' without cloning the repo.
> 2) Can't deploy our downloadable cartridge from the wizard. I believe OpenShift is now (or will soon) allow downloadable carts to be registered, so this problem should be solved as the cart will show up in the cartridge list.
> Our current method of connecting is ok for now, but a simpler usage of the OpenShift server adapter would allow us to more easily manage the instance (e.g. port-forward without going to the command line, viewing logs, 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, 3 months
[JBoss JIRA] (JBIDE-16720) Allow easier access to openshift operations from jboss servers
by Mark Drilling (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16720?page=com.atlassian.jira.plugi... ]
Mark Drilling commented on JBIDE-16720:
---------------------------------------
Heres explanation from Ben Parees (OpenShift) on the current state of cartridges
v========================================v
So essentially there are 3 types of cartridges now:
1) system cartridges (rpm based, maintained by openshift team)
- appear on the web page and in rhc cartridge list
2) imported downloadable cartridges (downloadable cartridge, but imported so they show up in the same places as system cartridges)
3) non-imported downloadable cartridges - these do not explicitly show up anywhere. The historic way to promote a downloadable cartridge was to create a quickstart based on it, and promote the quickstart.
Unfortunately there is currently no obvious distinction for a user between #1 and #2.
Both the site and command line indicate cartridges which do not receive automatic security updates, which for now is effectively the same as being an imported downloadable cartridge, but it's not explicit that the cartridge is downloadable.
^========================================^
I think 2) is a new feature and seems to be the way they prefer to register the cartridges now. I'm not sure how the import works, but it will apparently then show up same as system cartridges. If that is the case, it will be available in the wizard's drop-down with everything else.
And yes about the localhost issue. (Can't use the openshift hostname because of the port forwarding.)
> Allow easier access to openshift operations from jboss servers
> --------------------------------------------------------------
>
> Key: JBIDE-16720
> URL: https://issues.jboss.org/browse/JBIDE-16720
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift, server
> Affects Versions: 4.1.1.Final
> Reporter: Mark Drilling
>
> We currently have a couple issues with connecting to an OpenShift Data Virtualization instance from the tooling. I'm aware that issues are being addressed for future release, others I'm not sure. This is intended to help guide your development to accommodate this use case.
> Our expected usage with Data Virtualization is a bit different than some others. With DV we expect to deploy via a DV cartridge to OpenShift, then connect to the OpenShift DV instance as a remote server. We typically would not deploy using git push.
> Currently, we connect to an OpenShift DV instance like this:
> 1) Deploy DV cartridge via OpenShift web console.
> 2) Port forward from command line using rhc port-forward
> 3) Set up EAP server instance in the tooling, mark as externally managed and start it. From there we can connect to the DV instance and continue with modeling and deployments in Teiid Designer perspective
> The issues we observed:
> 1) Creation of the OpenShift 'server' forces a git repo to be copied locally. We'd like to simply create the 'OpenShift server' without cloning the repo.
> 2) Can't deploy our downloadable cartridge from the wizard. I believe OpenShift is now (or will soon) allow downloadable carts to be registered, so this problem should be solved as the cart will show up in the cartridge list.
> Our current method of connecting is ok for now, but a simpler usage of the OpenShift server adapter would allow us to more easily manage the instance (e.g. port-forward without going to the command line, viewing logs, 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, 3 months
[JBoss JIRA] (JBDS-2956) Spring IDE's associated projects and files cannot be created and many plugins never goes past "Starting"
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-2956?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-2956:
-------------------------------------------
[~mlabuda] thats very weird and concerning. Can you reproduce this on other installations/machines?
[~snjeza] could you take a look and see if you can figure out why some plugins just stays in "starting" mode on JBDS but seem to work on JBT ?
> Spring IDE's associated projects and files cannot be created and many plugins never goes past "Starting"
> --------------------------------------------------------------------------------------------------------
>
> Key: JBDS-2956
> URL: https://issues.jboss.org/browse/JBDS-2956
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: 3rd-party-certification
> Affects Versions: 8.0.0.Alpha2
> Environment: Fedora 17
> Reporter: Marián Labuda
> Assignee: Snjezana Peco
> Attachments: jbds800Alpha2report.zip, jbds_part1.png, jbds_part2.png, JBT4.2.0.Alpha2breport.zip, jbt_part1.png, jbt_part2.png, jbt_part3.png, spring_projects.png
>
>
> After installing Spring IDE into JBDS 8.0.0.Alpha2 there should be option to create associated projects / examples / files... from menu File - Other - Spring, but there is only item for creation Spring bean configuration file. Others are missing. Tests also JBT 4.2.0.Alpha2 and there was not this issue.
> See attached file.
--
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, 3 months
[JBoss JIRA] (JBDS-2956) Spring IDE's associated projects and files cannot be created and many plugins never goes from "Starting"
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-2956?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen updated JBDS-2956:
--------------------------------------
Summary: Spring IDE's associated projects and files cannot be created and many plugins never goes from "Starting" (was: Spring IDE's associated projects and files cannot be created)
> Spring IDE's associated projects and files cannot be created and many plugins never goes from "Starting"
> --------------------------------------------------------------------------------------------------------
>
> Key: JBDS-2956
> URL: https://issues.jboss.org/browse/JBDS-2956
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: 3rd-party-certification
> Affects Versions: 8.0.0.Alpha2
> Environment: Fedora 17
> Reporter: Marián Labuda
> Assignee: Snjezana Peco
> Attachments: jbds800Alpha2report.zip, jbds_part1.png, jbds_part2.png, JBT4.2.0.Alpha2breport.zip, jbt_part1.png, jbt_part2.png, jbt_part3.png, spring_projects.png
>
>
> After installing Spring IDE into JBDS 8.0.0.Alpha2 there should be option to create associated projects / examples / files... from menu File - Other - Spring, but there is only item for creation Spring bean configuration file. Others are missing. Tests also JBT 4.2.0.Alpha2 and there was not this issue.
> See attached file.
--
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, 3 months