[JBoss JIRA] (JBDS-3411) have installer build actually use M6 p2 product build
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBDS-3411?page=com.atlassian.jira.plugin.... ]
Martin Malina commented on JBDS-3411:
-------------------------------------
I wonder if we could go all the way (as Eclipse did) and just have the jbdevstudio.app, without ${target-dir}/studio. But then we wouldn't have anywhere to put the uninstaller, so I guess that stops us from doing that.
> have installer build actually use M6 p2 product build
> -----------------------------------------------------
>
> Key: JBDS-3411
> URL: https://issues.jboss.org/browse/JBDS-3411
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: build, installer, updatesite
> Reporter: Max Rydahl Andersen
> Assignee: Denis Golovin
> Priority: Critical
> Fix For: 9.0.0.Beta1
>
>
> talking with [~prapicault] I learned that since M6 the following changes are required for proper working p2 product/osx build:
> {code}
> <products>
> <product>
> ...
> <rootFolders>
> <macosx>MyProduct.app</macosx>
> </rootFolders>
> </product>
> {code}
> And to use tycho 0.23-snapshot
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-19467) repository-utils :: FetchSourcesFromManifests should create its own source zip, not rely on publish.sh
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19467?page=com.atlassian.jira.plugi... ]
Mickael Istria reassigned JBIDE-19467:
--------------------------------------
Assignee: Nick Boldt (was: Mickael Istria)
> 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: Nick Boldt
> Fix For: 4.3.0.Beta1
>
>
> 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)
10 years, 11 months
[JBoss JIRA] (JBTIS-416) Need to doc split of SOA Development between release and early access
by Andrej Podhradsky (JIRA)
[ https://issues.jboss.org/browse/JBTIS-416?page=com.atlassian.jira.plugin.... ]
Andrej Podhradsky commented on JBTIS-416:
-----------------------------------------
I looks good to me too
> Need to doc split of SOA Development between release and early access
> ---------------------------------------------------------------------
>
> Key: JBTIS-416
> URL: https://issues.jboss.org/browse/JBTIS-416
> Project: JBoss Tools Integration Stack
> Issue Type: Task
> Components: distribution
> Affects Versions: 8.0.1.GA, 4.2.1.Final
> Reporter: Paul Leacu
> Assignee: Misha Ali
> Attachments: ss0.png, ss1.png
>
>
> Component categorization for the SOA Development tooling falls in both the released and Early Access update sites. B*MS tooling is now being productized and Fuse Tooling/ SwitchYard are in 'Early Access'. This situation is temporary (until Fuse Tooling/SwitchYard are GA).
> To address this issue I've done the following:
> JBDSIS 8.0.1.GA:
> site-ga: (released)
> JBoss Business Process and Rules Development
> *All features available
> JBoss Data Virtualization Development
> *All features available
> JBoss Integration and SOA Development
> *All features except Fuse Tooling and SwitchYard
> JBoss SOA 5.x Development
> *All features available
>
> site-ea: (early access)
> JBoss Fuse Development
> *All features available
> JBoss Integration and SOA Development
> *Fuse Tooling and SwitchYard only available
> To simplify the user experience, Early Access will contain only features which are early access. Released (production) features will appear in the primary update window.
> The community JBTIS install will do something similar.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-19467) repository-utils :: FetchSourcesFromManifests should create its own source zip, not rely on publish.sh
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19467?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-19467:
----------------------------------------
I don't think PR #39 is related, so I removed it from the jira metadata.
> 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.Beta1
>
>
> 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)
10 years, 11 months
[JBoss JIRA] (JBIDE-19467) repository-utils :: FetchSourcesFromManifests should create its own source zip, not rely on publish.sh
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19467?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-19467:
----------------------------------------
Sorry for the delay. It's already too late for Alpha2, however, it's something I'd like to have for Beta1 as it reduces the importance of publish.sh.
I just have a couple of comments I made in the PR and that I believe need to be fixed before merging.
> 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.Beta1
>
>
> 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)
10 years, 11 months
[JBoss JIRA] (JBIDE-19467) repository-utils :: FetchSourcesFromManifests should create its own source zip, not rely on publish.sh
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19467?page=com.atlassian.jira.plugi... ]
Mickael Istria updated JBIDE-19467:
-----------------------------------
Git Pull Request: https://github.com/jbosstools/jbosstools-maven-plugins/pull/38 (was: https://github.com/jbosstools/jbosstools-maven-plugins/pull/38, https://github.com/jbosstools/jbosstools-maven-plugins/pull/39)
> 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.Beta1
>
>
> 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)
10 years, 11 months
[JBoss JIRA] (JBIDE-19467) repository-utils :: FetchSourcesFromManifests should create its own source zip, not rely on publish.sh
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19467?page=com.atlassian.jira.plugi... ]
Mickael Istria updated JBIDE-19467:
-----------------------------------
Fix Version/s: 4.3.0.Beta1
(was: 4.3.0.Alpha2)
> 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.Beta1
>
>
> 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)
10 years, 11 months
[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 edited comment on JBIDE-19697 at 4/25/15 4:01 PM:
----------------------------------------------------------------
The org.jboss.tools.runtime.ui plugin initializes runtimes in the $USER_HOME/jboss_runtimes and $ECLIPSE_HOME/../../runtimes/jboss-eap directory as well as runtimes defined in the $ECLIPSE_HOME/../../../../studio/runtime_locations.properties and $ECLIPSE_HOME/../../studio/runtime_locations.properties files.
I suppose [~mmalina] has EAP 6.3 defined in some runtime_locations.properties file (maybe in some other JBDS installation).
was (Author: snjeza):
The org.jboss.tools.runtime.ui plugin initializes runtimes in the $USER_HOME/jboss_runtimes and $ECLIPSE_HOME/../../runtimes/jboss-eap directory as well as runtimes defined in the $ECLIPSE_HOME/../../../../studio/runtime_locations.properties and $ECLIPSE_HOME/../../studio/runtime_locations.properties files.
I suppose Martin has EAP 6.3 defined in some runtime_locations.properties file (maybe in some other JBDS installation).
> 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)
10 years, 11 months
[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:
---------------------------------------
The org.jboss.tools.runtime.ui plugin initializes runtimes in the $USER_HOME/jboss_runtimes and $ECLIPSE_HOME/../../runtimes/jboss-eap directory as well as runtimes defined in the $ECLIPSE_HOME/../../../../studio/runtime_locations.properties and $ECLIPSE_HOME/../../studio/runtime_locations.properties files.
I suppose Martin has EAP 6.3 defined in some runtime_locations.properties file (maybe in some other JBDS installation).
> 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)
10 years, 11 months
[JBoss JIRA] (JBIDE-15884) Allow the runBrowserSim command to accept a URL as a parameter
by Ilya Buziuk (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15884?page=com.atlassian.jira.plugi... ]
Ilya Buziuk commented on JBIDE-15884:
-------------------------------------
well, it seems to be that it's not possible to hide command. But we can still have two commands "Run BrowserSim" & "Run BrowserSim for Cheet Sheets" (with vpe prefix) for compatibility - https://github.com/ibuziuk/jbosstools-browsersim/commit/174a0aa8f2c2711be...
> Allow the runBrowserSim command to accept a URL as a parameter
> --------------------------------------------------------------
>
> Key: JBIDE-15884
> URL: https://issues.jboss.org/browse/JBIDE-15884
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: browsersim
> Affects Versions: 4.1.0.Final
> Reporter: Vineet Reynolds
> Assignee: Ilya Buziuk
> Priority: Minor
> Fix For: 4.3.0.Beta1
>
>
> Apologies for not setting the Affect version; I'm not sure which JBIDE version is affected.
> When creating a cheatsheet in JBDS 7.0.1.GA (for JDF-497), I'm using the {{org.jboss.tools.vpe.browsersim.eclipse.commands.runBrowserSim}} command in the cheatsheet. This launches BrowserSim successfully (when I'm in the correct perspective). However, BrowserSim navigates to about:blank so the cheatsheet requires users to manually key in the URL. It would be nice to have the launch URL specified as a configurable value.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months