[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 Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15482?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-15482:
------------------------------------
CI = continuous integration. These are CI builds. "CI builds are normally staged eventually but not directly from CI ?" << No idea what you're asking.
*Re: need for name change: * The addition of the /CI/ path segment *for all builds using the new publish script* was an arbitrary change, simply done to differentiate them from the older staging/staging.previous builds. It *is* being done uniformly - all a project needs to do is adopt the new publish script and they'll start publishing to the new location scheme.
Making this distinction makes it easier to see which builds are being built the new way vs. which are built the old way (eg., the ongoing SOA Tooling 5.x builds).
> 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: Nick Boldt
> Fix For: 4.1.1.Alpha2
>
>
> 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, 6 months
[JBoss JIRA] (JBIDE-15610) For 4.1.1.Beta1: since one forge plugin has bumped, so should they all
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15610?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-15610:
------------------------------------
The approach [~koen.aers] has used for the forge.runtime plugin has been to match its version to that of the forge runtime jar included therein. As such we will likely never have a situation where the runtime jar changes inside the plugin but the plugin's version does not (or only appends "a").
> For 4.1.1.Beta1: since one forge plugin has bumped, so should they all
> ----------------------------------------------------------------------
>
> Key: JBIDE-15610
> URL: https://issues.jboss.org/browse/JBIDE-15610
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: forge
> Affects Versions: 4.1.1.Alpha2
> Reporter: Nick Boldt
> Assignee: Koen Aers
> Priority: Blocker
> Fix For: 4.1.1.Beta1
>
>
> [~maxandersen] would prefer that since a single forge plugin (forge.runtime) has bumped from 1.3.3 to 1.4.1, that all the forge plugins (and their containing features) also bump at least their service (micro) increment.
> Thus:
> 1.2.0 -> 1.2.1
> 1.0.0 -> 1.0.1
> 2.0.0 -> 2.0.1
> And in master branch [1], I'm guessing this is wrong:
> {code}org.jboss.tools.forge2.runtime_2.0.1.Alpha1-v20130927-1755-B403.jar{code}
> Shouldn't that be at version 2.1.0 or 2.0.100, not 2.0.1?
> [1] http://download.jboss.org/jbosstools/builds/staging/jbosstools-forge_mast...
--
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, 6 months
[JBoss JIRA] (JBIDE-15624) Unable to install Tycho Configurator with jdk7u40
by Andrej Podhradsky (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15624?page=com.atlassian.jira.plugi... ]
Andrej Podhradsky commented on JBIDE-15624:
-------------------------------------------
Now I found that this bug is reported at
https://bugs.eclipse.org/bugs/show_bug.cgi?id=417241
> Unable to install Tycho Configurator with jdk7u40
> -------------------------------------------------
>
> Key: JBIDE-15624
> URL: https://issues.jboss.org/browse/JBIDE-15624
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: maven, upstream
> Affects Versions: 4.1.0.Final
> Environment: FC19_64, jdk7u40
> Reporter: Andrej Podhradsky
>
> After importing a tycho maven project I'm not able to install tycho configurator via quickfix like before. I'm getting the following error
> java.io.IOException: Unable to create temporary file
> at java.io.File$TempDirectory.generateFile(File.java:1891)
> at java.io.File.createTempFile(File.java:1979)
> at org.eclipse.equinox.internal.p2.discovery.compatibility.RemoteBundleDiscoveryStrategy$DownloadBundleJob.call(RemoteBundleDiscoveryStrategy.java:197)
> at org.eclipse.equinox.internal.p2.discovery.compatibility.RemoteBundleDiscoveryStrategy$DownloadBundleJob.call(RemoteBundleDiscoveryStrategy.java:1)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
--
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, 6 months
[JBoss JIRA] (JBIDE-15624) Unable to install Tycho Configurator with jdk7u40
by Andrej Podhradsky (JIRA)
Andrej Podhradsky created JBIDE-15624:
-----------------------------------------
Summary: Unable to install Tycho Configurator with jdk7u40
Key: JBIDE-15624
URL: https://issues.jboss.org/browse/JBIDE-15624
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: maven, upstream
Affects Versions: 4.1.0.Final
Environment: FC19_64, jdk7u40
Reporter: Andrej Podhradsky
After importing a tycho maven project I'm not able to install tycho configurator via quickfix like before. I'm getting the following error
java.io.IOException: Unable to create temporary file
at java.io.File$TempDirectory.generateFile(File.java:1891)
at java.io.File.createTempFile(File.java:1979)
at org.eclipse.equinox.internal.p2.discovery.compatibility.RemoteBundleDiscoveryStrategy$DownloadBundleJob.call(RemoteBundleDiscoveryStrategy.java:197)
at org.eclipse.equinox.internal.p2.discovery.compatibility.RemoteBundleDiscoveryStrategy$DownloadBundleJob.call(RemoteBundleDiscoveryStrategy.java:1)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
--
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, 6 months
[JBoss JIRA] (JBIDE-15622) Automatically open/send report when log has error
by Mickael Istria (JIRA)
Mickael Istria created JBIDE-15622:
--------------------------------------
Summary: Automatically open/send report when log has error
Key: JBIDE-15622
URL: https://issues.jboss.org/browse/JBIDE-15622
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Components: common/jst/core
Affects Versions: 4.1.1.Alpha1
Reporter: Mickael Istria
JBT should set up an ILogListener on the Eclipse log and send an error report whenever something is logged as error.
As it's probably not possible to send the error report without asking users, it should show the "Report problem" page.
NetBeans does that and has reported an actual quality benefit.
--
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, 6 months
[JBoss JIRA] (JBIDE-15621) Runtime isn't detected when adding it right after it was deleted
by Radoslav Rábara (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15621?page=com.atlassian.jira.plugi... ]
Radoslav Rábara updated JBIDE-15621:
------------------------------------
Attachment: runtime 01 - select a folder.jpg
runtime 02 - found runtime.jpg
runtime 03 - remove runtime.jpg
runtime 04 - select the folder again.jpg
runtime 05 - no runtime found.jpg
runtime 06 - workaround - uncheck.jpg
runtime 07 - workaround - check.jpg
> Runtime isn't detected when adding it right after it was deleted
> ----------------------------------------------------------------
>
> Key: JBIDE-15621
> URL: https://issues.jboss.org/browse/JBIDE-15621
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: runtime-detection
> Affects Versions: 4.0.1.Final
> Reporter: Radoslav Rábara
> Attachments: runtime 01 - select a folder.jpg, runtime 02 - found runtime.jpg, runtime 03 - remove runtime.jpg, runtime 04 - select the folder again.jpg, runtime 05 - no runtime found.jpg, runtime 06 - workaround - uncheck.jpg, runtime 07 - workaround - check.jpg
>
>
> JBoss Runtime Detection doesn't detect a runtime, when the runtime is removed and then added.
> Workaround exists.
--
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, 6 months
[JBoss JIRA] (JBIDE-15614) Rename EAP 6.1 server type to 6.1+, ensure runtime detection is accurate
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15614?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-15614:
---------------------------------------
[~rob.stryker] Since I don't see you mentioning it explicitly, I would like to point out the fact that even if I could add 6.2 as 6.1 I got warnings about it. So I hope your patch fixes that, too (I didn't check)
> Rename EAP 6.1 server type to 6.1+, ensure runtime detection is accurate
> ------------------------------------------------------------------------
>
> Key: JBIDE-15614
> URL: https://issues.jboss.org/browse/JBIDE-15614
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: runtime-detection, server
> Affects Versions: 4.1.0.Final
> Environment: JBDS 7.0.0.GA
> Reporter: Martin Malina
> Assignee: Max Rydahl Andersen
> Fix For: 4.1.1.Beta1
>
>
> 1. When you try to add EAP 6.2 using runtime detection, it detects it as EAP 6.0.
> 2. When trying to add EAP 6.2 manually, there is no type EAP 6.2
> Let me know if you want subtasks for these two.
--
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, 6 months