October 2013 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-15614) Rename EAP 6.1 server type to 6.1+, ensure runtime detection is accurate

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15614?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-15614: --------------------------------------------- link the "full" jira for EAP 6.2 support. for now EAP 6.2 is supported as if it was an EAP 6.1. > 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

1
0
0 / 0

[JBoss JIRA] (JBIDE-15610) For 4.1.1.Beta1: since one forge plugin has bumped, so should they all

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15610?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-15610: --------------------------------------------- nick - point is that no plugins with same version number (ignoring timestamp qualifier part) but different binary content should not be released. Thus if we release a new build of forge the runtime plugin makes sense to bump to at least show difference. But as said - this plugin (like xulrunner) falls into this edge-case of being based on which binary runtime are inside it. Just saying, if you want to be 100% clean adding a, b, etc. would be more correct. > 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

1
0
0 / 0

[JBoss JIRA] (JBIDE-15621) Runtime isn't detected when adding it right after it was deleted

by Snjezana Peco (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15621?page=com.atlassian.jira.plugi... ] Snjezana Peco reassigned JBIDE-15621: ------------------------------------- Assignee: Snjezana Peco > 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 > Assignee: Snjezana Peco > 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

1
0
0 / 0

[JBoss JIRA] (JBIDE-15622) Automatically open/send report when log has error

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15622?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-15622: ---------------------------------------- Related resources about automatic reports/search of StackTraces: * http://code-recommenders.blogspot.ch/2011/05/oh-stacktrace-my-stacktrace.... * http://support.leagueusa.com/help/Articles/GetCrashReportsFromUsersA.html > 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

1
0
0 / 0

[JBoss JIRA] (JBIDE-15606) build tool to regenerate component update sites from published JBT aggregate

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15606?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-15606: ------------------------------------ ORG-1647 would certainly replace the need to use the jbosstools-promote job to push nightly/staged/CI bits into /updates/stable/kepler/core/<projectName>/<version>/ ... but are we sure that Nexus has a better or equal uptime / performance to download.jboss.org? > build tool to regenerate component update sites from published JBT aggregate > ---------------------------------------------------------------------------- > > Key: JBIDE-15606 > URL: https://issues.jboss.org/browse/JBIDE-15606 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build, updatesite > Affects Versions: 4.1.1.Alpha2 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.1.1.Beta1 > > > When we released JBT 4.1.0.Final, we didn't publish the individual projects as sites themselves, so now when we're trying to aggregate JBT 4.1.1.Alpha2 using a combination of unchanged older projects + changed newer projects, we're unable to do so. > We could rebuild the projects from source, but it would be better to simply re-aggregate the binaries in order to produce subset sites which match the content of the released JBT site, but only for those individual projects. > This would allow us to swap in/out projects like GWT, Freemarker, Birt, Hibernate and Portal, which haven't changed yet since JBT 4.1.0.Final was released. -- 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

1
0
0 / 0

[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 edited comment on JBIDE-15482 at 10/7/13 12:55 PM: -------------------------------------------------------------- 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). was (Author: nickboldt): 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

1
0
0 / 0

[JBoss JIRA] (JBIDE-15606) build tool to regenerate component update sites from published JBT aggregate

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15606?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-15606: ------------------------------------ Some composite*.xml files are generated. Some are not. In this context, they WILL be generated once JBIDE-15482 is complete, but for older releases and other implementations, NO, they are NOT generated. "#2 and #3 could be fixed - i'm still wondering why these even have to be separate sites." << What do you mean? How? "makes more sense to publish these intermediate sites instead of creating them from an previously generated aggregate" << YES. But it would help to know in advance which ones won't be changing, so I don't need to create mirrors of things that WILL be changing (like the Base or Server component, because that's always being updated/refactored/improved). > build tool to regenerate component update sites from published JBT aggregate > ---------------------------------------------------------------------------- > > Key: JBIDE-15606 > URL: https://issues.jboss.org/browse/JBIDE-15606 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build, updatesite > Affects Versions: 4.1.1.Alpha2 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.1.1.Beta1 > > > When we released JBT 4.1.0.Final, we didn't publish the individual projects as sites themselves, so now when we're trying to aggregate JBT 4.1.1.Alpha2 using a combination of unchanged older projects + changed newer projects, we're unable to do so. > We could rebuild the projects from source, but it would be better to simply re-aggregate the binaries in order to produce subset sites which match the content of the released JBT site, but only for those individual projects. > This would allow us to swap in/out projects like GWT, Freemarker, Birt, Hibernate and Portal, which haven't changed yet since JBT 4.1.0.Final was released. -- 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

1
0
0 / 0

[JBoss JIRA] (JBIDE-15198) Move away from sonatype aether to eclipse aether

by Snjezana Peco (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15198?page=com.atlassian.jira.plugi... ] Snjezana Peco commented on JBIDE-15198: --------------------------------------- The PR seems to be correct, but is created only for the jbosstools-4.1.x branch. Suppose it also need to be applied to the master. > Move away from sonatype aether to eclipse aether > ------------------------------------------------ > > Key: JBIDE-15198 > URL: https://issues.jboss.org/browse/JBIDE-15198 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: maven, project-examples, testing-tools > Affects Versions: 4.1.0.CR1 > Reporter: Fred Bricon > Assignee: Max Rydahl Andersen > Fix For: 4.1.1.Beta1, 4.2.0.Alpha1 > > > With Maven 3.1.0, Sonatype Aether has been replaced with Eclipse Aether. m2e 1.5.0 will soon do the same. Currently, I've found that at least the following plugins have a dependency to the Sonatype version : > - org.jboss.tools.arquillian.core > - org.jboss.tools.maven.project.examples > - org.jboss.tools.maven.ui > Ideally the next m2e version won't embed the jars directly (but this is not guaranteed). Aether is available from this p2 repo : http://download.eclipse.org/aether/aether-core/milestones -- 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

1
0
0 / 0

[JBoss JIRA] (JBIDE-15624) Unable to install m2e connectors with jdk7u40

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15624?page=com.atlassian.jira.plugi... ] Fred Bricon updated JBIDE-15624: -------------------------------- Summary: Unable to install m2e connectors with jdk7u40 (was: Unable to install Tycho Configurator with jdk7u40) > Unable to install m2e connectors 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

1
0
0 / 0

[JBoss JIRA] (JBIDE-15374) Create target platform from Luna M2 dependencies

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15374?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-15374: ------------------------------- Summary: Create target platform from Luna M2 dependencies (was: Create target platform from Luna M1 or M2 dependencies) > Create target platform from Luna M2 dependencies > ------------------------------------------------ > > Key: JBIDE-15374 > URL: https://issues.jboss.org/browse/JBIDE-15374 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: target-platform > Affects Versions: 4.2.0.Alpha1 > Reporter: Nick Boldt > Assignee: Mickael Istria > > Create a new target platform for use with JBoss Tools 4.2 (Luna). Should be versioned 4.40.x. > Luna schedule: > http://wiki.eclipse.org/Luna/Simultaneous_Release_Plan#Schedule -- 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

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-issues October 2013