[JBoss JIRA] (JBIDE-19697) org.jboss.tools.runtime.ui.prefs mysteriously appears in Eclipse dir during JBDS BYOE installation
by Snjezana Peco (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19697?page=com.atlassian.jira.plugi... ]
Snjezana Peco commented on JBIDE-19697:
---------------------------------------
This is normal behaviour. The org.jboss.tools.runtime.ui plugin includes the startup extension point that initializes runtimes and creates some configuration preferences. The org.jboss.tools.usage plugin creates a similar file because it also initializes some configuration preferences.
> org.jboss.tools.runtime.ui.prefs mysteriously appears in Eclipse dir during JBDS BYOE installation
> --------------------------------------------------------------------------------------------------
>
> Key: JBIDE-19697
> URL: https://issues.jboss.org/browse/JBIDE-19697
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: runtime-detection
> Affects Versions: 4.3.0.Alpha2
> Reporter: Martin Malina
> Assignee: Snjezana Peco
>
> When I install JBDs 9.0.0.Alpha2 B24 BYOE into new Eclipse Mars M6 and new workspace, during the installation, suddenly the runtime detection config appears inside my Eclipse isntall dir:
> {code}
> $ find Eclipse-runtime-test.app/ -name 'org.jboss.tools.runtime.*.prefs'
> Eclipse-runtime-test.app//Contents/Eclipse/configuration/.settings/org.jboss.tools.runtime.ui.prefs
> {code}
> This is inside the file:
> {code}
> $ find Eclipse-runtime-test.app/ -name 'org.jboss.tools.runtime.*.prefs'|xargs cat
> eclipse.preferences.version=1
> runtimePaths=<?xml version\="1.0" encoding\="UTF-8" standalone\="no"?>\n<runtimePaths version\="2">\n <runtimePath path\="/Users/rasp/jbossqa/runtimes/jboss-eap-6.3.0" scanOnEveryStartup\="false" timestamp\="-1">\n <serverDefinitions>\n <serverDefinition description\="" enabled\="true" location\="/Users/rasp/jbossqa/runtimes/jboss-eap-6.3.0" name\="JBoss EAP 6.3" type\="EAP" version\="6.3">\n <included/>\n </serverDefinition>\n </serverDefinitions>\n </runtimePath>\n</runtimePaths>\n
> {code}
> It contains /Users/rasp/jbossqa/runtimes/jboss-eap-6.3.0 which I use regularly when testing server tooling. But how did this happen?
> I looked for the pref file before I started BYOE installation. Then a bit later, a few minutes into the installation, I checked again and the file is there now.
> Can somebody explain what's going on?
> Note: This happened to me yesterday and it surprised me, but I wasn't sure if it wasn't my mistake somehow. But Max preferred I try again, so I did. And it is happening again now.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (JBIDE-19467) repository-utils :: FetchSourcesFromManifests should create its own source zip, not rely on publish.sh
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19467?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-19467:
------------------------------------
[~mickael_istria] Can this get in for Alpha2, or does it need to slip to Beta1? If you need me to change the PRs again, assign back to me & let me know what needs to be changed. Thanks!
> repository-utils :: FetchSourcesFromManifests should create its own source zip, not rely on publish.sh
> ------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-19467
> URL: https://issues.jboss.org/browse/JBIDE-19467
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.3.0.Alpha2
> Reporter: Nick Boldt
> Assignee: Mickael Istria
> Fix For: 4.3.0.Alpha2
>
>
> In repository-utils, FetchSourcesFromManifests should create its own source zip, not rely on publish.sh. Because we no longer use publish.sh and don't want to have rsync.sh produce artifacts, only rsync them.
> Here's what publish.sh does:
> {code}
> # collect component zips from upstream aggregated build jobs
> if [[ ${JOB_NAME/.aggregate} != ${JOB_NAME} ]] && [[ -d ${WORKSPACE}/sources/aggregate/site/zips ]]; then
> mkdir -p ${STAGINGDIR}/components
> for z in $(find ${WORKSPACE}/sources/aggregate/site/zips -name "*updatesite-*.zip"); do
> # generate MD5 sum for zip (file contains only the hash, not the hash + filename)
> for m in $(md5sum ${z}); do if [[ $m != ${z} ]]; then echo $m > ${z}.MD5; fi; done
> mv $z ${z}.MD5 ${STAGINGDIR}/components
> done
> # TODO :: JBIDE-9870 When we have a -Update-Sources- zip, this can be removed
> mkdir -p ${STAGINGDIR}/all/sources
> # OLD: unpack component source zips like jbosstools-pi4soa-3.1_trunk-Sources-SNAPSHOT.zip or jbosstools-3.2_trunk.component--ws-Sources-SNAPSHOT.zip
> # NEW: JBIDE-16632: unpack component source zips like jbosstools-base_Alpha2-v20140221-1555-B437_184e18cc3ac7c339ce406974b6a4917f73909cc4_sources.zip
> for z in $(find ${WORKSPACE}/sources/aggregate/site/zips -name "*Sources*.zip" -o -name "*_sources.zip" -o -name "*-src.zip"); do
> zn=${z%*-Sources*.zip}; zn=${zn%*_sources.zip}; zn=${zn%*-src.zip}; zn=${zn#*--}; zn=${zn##*/}; zn=${zn#jbosstools-};
> # zn=${zn%_trunk}; zn=${zn%_stable_branch};
> mkdir -p ${STAGINGDIR}/all/sources/${zn}/
> # remove one level of folder nesting - don't want an extra jbosstools-base-184e18cc3ac7c339ce406974b6a4917f73909cc4 folder under jbosstools-base_Alpha2-v20140221-1555-B437_184e18cc3ac7c339ce406974b6a4917f73909cc4
> unzip -qq -o -d ${tmpdir}/${zn}/ $z
> mkdir -p ${STAGINGDIR}/all/sources/${zn}/
> mv ${tmpdir}/${zn}/jbosstools-*/* ${STAGINGDIR}/all/sources/${zn}/
> rm -fr ${tmpdir}/${zn}/
> done
> # add component sources into sources zip
> pushd ${STAGINGDIR}/all/sources
> zip ${STAGINGDIR}/all/${SRCSNAME} -q -r * -x hudson_workspace\* -x documentation\* -x download.jboss.org\* -x requirements\* \
> -x workingset\* -x labs\* -x build\* -x \*test\* -x \*target\* -x \*.class -x \*classes\* -x \*bin\* -x \*.zip \
> -x \*docs\* -x \*reference\* -x \*releng\* -x \*.git\* -x \*/lib/\*.jar -x \*getRemoteFile\*
> popd
> rm -fr ${STAGINGDIR}/all/sources
> z=${STAGINGDIR}/all/${SRCSNAME}; for m in $(md5sum ${z}); do if [[ $m != ${z} ]]; then echo $m > ${z}.MD5; fi; done
> # JBIDE-7444 get aggregate metadata xml properties file
> if [[ -f ${WORKSPACE}/sources/aggregate/site/zips/build.properties.all.xml ]]; then
> rsync -aq ${WORKSPACE}/sources/aggregate/site/zips/build.properties.all.xml ${STAGINGDIR}/logs/
> fi
> fi
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (JBIDE-19467) repository-utils :: FetchSourcesFromManifests should create its own source zip, not rely on publish.sh
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19467?page=com.atlassian.jira.plugi... ]
Nick Boldt reassigned JBIDE-19467:
----------------------------------
Assignee: Mickael Istria (was: Nick Boldt)
> repository-utils :: FetchSourcesFromManifests should create its own source zip, not rely on publish.sh
> ------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-19467
> URL: https://issues.jboss.org/browse/JBIDE-19467
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.3.0.Alpha2
> Reporter: Nick Boldt
> Assignee: Mickael Istria
> Fix For: 4.3.0.Alpha2
>
>
> In repository-utils, FetchSourcesFromManifests should create its own source zip, not rely on publish.sh. Because we no longer use publish.sh and don't want to have rsync.sh produce artifacts, only rsync them.
> Here's what publish.sh does:
> {code}
> # collect component zips from upstream aggregated build jobs
> if [[ ${JOB_NAME/.aggregate} != ${JOB_NAME} ]] && [[ -d ${WORKSPACE}/sources/aggregate/site/zips ]]; then
> mkdir -p ${STAGINGDIR}/components
> for z in $(find ${WORKSPACE}/sources/aggregate/site/zips -name "*updatesite-*.zip"); do
> # generate MD5 sum for zip (file contains only the hash, not the hash + filename)
> for m in $(md5sum ${z}); do if [[ $m != ${z} ]]; then echo $m > ${z}.MD5; fi; done
> mv $z ${z}.MD5 ${STAGINGDIR}/components
> done
> # TODO :: JBIDE-9870 When we have a -Update-Sources- zip, this can be removed
> mkdir -p ${STAGINGDIR}/all/sources
> # OLD: unpack component source zips like jbosstools-pi4soa-3.1_trunk-Sources-SNAPSHOT.zip or jbosstools-3.2_trunk.component--ws-Sources-SNAPSHOT.zip
> # NEW: JBIDE-16632: unpack component source zips like jbosstools-base_Alpha2-v20140221-1555-B437_184e18cc3ac7c339ce406974b6a4917f73909cc4_sources.zip
> for z in $(find ${WORKSPACE}/sources/aggregate/site/zips -name "*Sources*.zip" -o -name "*_sources.zip" -o -name "*-src.zip"); do
> zn=${z%*-Sources*.zip}; zn=${zn%*_sources.zip}; zn=${zn%*-src.zip}; zn=${zn#*--}; zn=${zn##*/}; zn=${zn#jbosstools-};
> # zn=${zn%_trunk}; zn=${zn%_stable_branch};
> mkdir -p ${STAGINGDIR}/all/sources/${zn}/
> # remove one level of folder nesting - don't want an extra jbosstools-base-184e18cc3ac7c339ce406974b6a4917f73909cc4 folder under jbosstools-base_Alpha2-v20140221-1555-B437_184e18cc3ac7c339ce406974b6a4917f73909cc4
> unzip -qq -o -d ${tmpdir}/${zn}/ $z
> mkdir -p ${STAGINGDIR}/all/sources/${zn}/
> mv ${tmpdir}/${zn}/jbosstools-*/* ${STAGINGDIR}/all/sources/${zn}/
> rm -fr ${tmpdir}/${zn}/
> done
> # add component sources into sources zip
> pushd ${STAGINGDIR}/all/sources
> zip ${STAGINGDIR}/all/${SRCSNAME} -q -r * -x hudson_workspace\* -x documentation\* -x download.jboss.org\* -x requirements\* \
> -x workingset\* -x labs\* -x build\* -x \*test\* -x \*target\* -x \*.class -x \*classes\* -x \*bin\* -x \*.zip \
> -x \*docs\* -x \*reference\* -x \*releng\* -x \*.git\* -x \*/lib/\*.jar -x \*getRemoteFile\*
> popd
> rm -fr ${STAGINGDIR}/all/sources
> z=${STAGINGDIR}/all/${SRCSNAME}; for m in $(md5sum ${z}); do if [[ $m != ${z} ]]; then echo $m > ${z}.MD5; fi; done
> # JBIDE-7444 get aggregate metadata xml properties file
> if [[ -f ${WORKSPACE}/sources/aggregate/site/zips/build.properties.all.xml ]]; then
> rsync -aq ${WORKSPACE}/sources/aggregate/site/zips/build.properties.all.xml ${STAGINGDIR}/logs/
> fi
> fi
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (JBIDE-19695) Annoying message "Be sure, may be you also should rename setter methods to avoid compilation problems."
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19695?page=com.atlassian.jira.plugi... ]
Alexey Kazakov commented on JBIDE-19695:
----------------------------------------
The seam message is not used anymore. This search participant was originally placed in seam. Then it was moved to jst/jsf but the warning message was copied. Not moved.
I'm going to remove the dead seam message, remove this warning from jst/jsf and add a check for our JST KB nature to make sure we don't trigger JSF/JST searching for plain java projects.
> Annoying message "Be sure, may be you also should rename setter methods to avoid compilation problems."
> -------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-19695
> URL: https://issues.jboss.org/browse/JBIDE-19695
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: jsf, jsp/jsf/xml/html source editing, seam2
> Affects Versions: 4.2.3.Final
> Reporter: Clovis Seragiotto
> Assignee: Alexey Kazakov
> Fix For: 4.3.0.Beta1
>
> Attachments: after installation.png, renaming a get method.png, Version chosen.png
>
>
> When renaming a get-method in Eclipse, the warning "Be sure, may be you also should rename setter methods to avoid compilation problems." is displayed.
> It should be possible to turn this warning off (and the sentence should be fixed).
> By Googling the message, I found:
> JBoss Tools SVN: r40216 - trunk/seam/plugins/org.jboss.tools.seam.core/src/org/jboss/tools/seam/core.
> That is why I suppose the right component is seam.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (JBIDE-19695) Annoying message "Be sure, may be you also should rename setter methods to avoid compilation problems."
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19695?page=com.atlassian.jira.plugi... ]
Alexey Kazakov updated JBIDE-19695:
-----------------------------------
Component/s: jsf
jsp/jsf/xml/html source editing
> Annoying message "Be sure, may be you also should rename setter methods to avoid compilation problems."
> -------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-19695
> URL: https://issues.jboss.org/browse/JBIDE-19695
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: jsf, jsp/jsf/xml/html source editing, seam2
> Affects Versions: 4.2.3.Final
> Reporter: Clovis Seragiotto
> Assignee: Alexey Kazakov
> Fix For: 4.3.0.Beta1
>
> Attachments: after installation.png, renaming a get method.png, Version chosen.png
>
>
> When renaming a get-method in Eclipse, the warning "Be sure, may be you also should rename setter methods to avoid compilation problems." is displayed.
> It should be possible to turn this warning off (and the sentence should be fixed).
> By Googling the message, I found:
> JBoss Tools SVN: r40216 - trunk/seam/plugins/org.jboss.tools.seam.core/src/org/jboss/tools/seam/core.
> That is why I suppose the right component is seam.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (JBIDE-19695) Annoying message "Be sure, may be you also should rename setter methods to avoid compilation problems."
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19695?page=com.atlassian.jira.plugi... ]
Alexey Kazakov updated JBIDE-19695:
-----------------------------------
Sprint: Sprint #2 April 2015
> Annoying message "Be sure, may be you also should rename setter methods to avoid compilation problems."
> -------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-19695
> URL: https://issues.jboss.org/browse/JBIDE-19695
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: jsf, jsp/jsf/xml/html source editing, seam2
> Affects Versions: 4.2.3.Final
> Reporter: Clovis Seragiotto
> Assignee: Alexey Kazakov
> Fix For: 4.3.0.Beta1
>
> Attachments: after installation.png, renaming a get method.png, Version chosen.png
>
>
> When renaming a get-method in Eclipse, the warning "Be sure, may be you also should rename setter methods to avoid compilation problems." is displayed.
> It should be possible to turn this warning off (and the sentence should be fixed).
> By Googling the message, I found:
> JBoss Tools SVN: r40216 - trunk/seam/plugins/org.jboss.tools.seam.core/src/org/jboss/tools/seam/core.
> That is why I suppose the right component is seam.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (JBIDE-19695) Annoying message "Be sure, may be you also should rename setter methods to avoid compilation problems."
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19695?page=com.atlassian.jira.plugi... ]
Alexey Kazakov reassigned JBIDE-19695:
--------------------------------------
Assignee: Alexey Kazakov
> Annoying message "Be sure, may be you also should rename setter methods to avoid compilation problems."
> -------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-19695
> URL: https://issues.jboss.org/browse/JBIDE-19695
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: seam2
> Affects Versions: 4.2.3.Final
> Reporter: Clovis Seragiotto
> Assignee: Alexey Kazakov
> Fix For: 4.3.0.Beta1
>
> Attachments: after installation.png, renaming a get method.png, Version chosen.png
>
>
> When renaming a get-method in Eclipse, the warning "Be sure, may be you also should rename setter methods to avoid compilation problems." is displayed.
> It should be possible to turn this warning off (and the sentence should be fixed).
> By Googling the message, I found:
> JBoss Tools SVN: r40216 - trunk/seam/plugins/org.jboss.tools.seam.core/src/org/jboss/tools/seam/core.
> That is why I suppose the right component is seam.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (JBTIS-430) JBTIS 4.2.3 target platform updates
by Paul Leacu (JIRA)
Paul Leacu created JBTIS-430:
--------------------------------
Summary: JBTIS 4.2.3 target platform updates
Key: JBTIS-430
URL: https://issues.jboss.org/browse/JBTIS-430
Project: JBoss Tools Integration Stack
Issue Type: Feature Request
Components: target-platform
Affects Versions: 4.2.2.Final-TP
Reporter: Paul Leacu
Assignee: Paul Leacu
Need to push the JBTIS target platform fuse dependencies to the release side from the EA side.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years