April 2015 - jbosstools-issues - Jboss List Archives

[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)

11 years

1
0
0 / 0

[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)

11 years

1
0
0 / 0

[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)

11 years

1
0
0 / 0

[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)

11 years

1
0
0 / 0

[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)

11 years

1
0
0 / 0

[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)

11 years

1
0
0 / 0

[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)

11 years

1
0
0 / 0

[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)

11 years

1
0
0 / 0

[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)

11 years

1
0
0 / 0

[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)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-18556) battery status is not reflected in browsersim's status bar

by Ilya Buziuk (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18556?page=com.atlassian.jira.plugi... ] Ilya Buziuk updated JBIDE-18556: -------------------------------- Sprint: Sprint #2 April 2015 > battery status is not reflected in browsersim's status bar > ---------------------------------------------------------- > > Key: JBIDE-18556 > URL: https://issues.jboss.org/browse/JBIDE-18556 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: cordovasim > Reporter: Max Rydahl Andersen > Assignee: Ilya Buziuk > Fix For: 4.3.x > > Attachments: log.png > > > create basic cordova app. > run in cordova sim. > changing the battery level and is-plugged does not take effect in the simulator. > Should it not be able to detect these ? -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-18583) pong index.html no longer works on cordovasim

by Ilya Buziuk (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18583?page=com.atlassian.jira.plugi... ] Ilya Buziuk updated JBIDE-18583: -------------------------------- Sprint: Sprint #2 April 2015 > pong index.html no longer works on cordovasim > ---------------------------------------------- > > Key: JBIDE-18583 > URL: https://issues.jboss.org/browse/JBIDE-18583 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: cordovasim > Affects Versions: 4.2.0.CR2 > Environment: Mac Os > Reporter: Max Rydahl Andersen > Assignee: Ilya Buziuk > Fix For: 4.3.x > > Attachments: index.html.zip > > > This works in previous versions. > replace the index.html into a hybrid app - it works when using ios simulator but not with cordovasim. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-12108) BrowserSim is not visible in Quick Access by default when installed individually

by Ilya Buziuk (JIRA)

[ https://issues.jboss.org/browse/JBIDE-12108?page=com.atlassian.jira.plugi... ] Ilya Buziuk updated JBIDE-12108: -------------------------------- Labels: new_and_noteworthy (was: ) > BrowserSim is not visible in Quick Access by default when installed individually > -------------------------------------------------------------------------------- > > Key: JBIDE-12108 > URL: https://issues.jboss.org/browse/JBIDE-12108 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: browsersim > Affects Versions: 3.3.0.CR1 > Environment: JBT 3.3.0.CR1b, L64, Ubuntu 12.04 > Reporter: Jiri Peterka > Assignee: Ilya Buziuk > Labels: new_and_noteworthy > Fix For: 4.3.0.Beta1 > > Attachments: browsersim-enabled.png, customize-perspective.png, enable-browsersim.png, mobile-browser.bmp > > > Unable to access BrowserSIM when installed as single feature from JBT CR1. Additional steps are required. This is confusing for a users. BrowserSIM should be accessible and visible after installation if possible. > *These additional steps are:* > # Right click on the Eclipse toolbar→Customize Perspective...: > !customize-perspective.png! > # Go to the Command Group Availability tab and select BrowserSim command group: > !enable-browsersim.png! > # BrowserSim icon will appear on the toolbar: > !browsersim-enabled.png! -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-12108) BrowserSim is not visible in Quick Access by default when installed individually

by Ilya Buziuk (JIRA)

[ https://issues.jboss.org/browse/JBIDE-12108?page=com.atlassian.jira.plugi... ] Ilya Buziuk commented on JBIDE-12108: ------------------------------------- Pushed to master Steps to verify: - After BrowserSim installation "Run BrowserSim" command should be available in Quick Access regardless of perspective and Command Groups availability > BrowserSim is not visible in Quick Access by default when installed individually > -------------------------------------------------------------------------------- > > Key: JBIDE-12108 > URL: https://issues.jboss.org/browse/JBIDE-12108 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: browsersim > Affects Versions: 3.3.0.CR1 > Environment: JBT 3.3.0.CR1b, L64, Ubuntu 12.04 > Reporter: Jiri Peterka > Assignee: Ilya Buziuk > Fix For: 4.3.0.Beta1 > > Attachments: browsersim-enabled.png, customize-perspective.png, enable-browsersim.png, mobile-browser.bmp > > > Unable to access BrowserSIM when installed as single feature from JBT CR1. Additional steps are required. This is confusing for a users. BrowserSIM should be accessible and visible after installation if possible. > *These additional steps are:* > # Right click on the Eclipse toolbar→Customize Perspective...: > !customize-perspective.png! > # Go to the Command Group Availability tab and select BrowserSim command group: > !enable-browsersim.png! > # BrowserSim icon will appear on the toolbar: > !browsersim-enabled.png! -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19551) Ionic Palette: Empty list item

by Alexey Kazakov (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19551?page=com.atlassian.jira.plugi... ] Alexey Kazakov updated JBIDE-19551: ----------------------------------- Attachment: fixed.png Fixed for GTK3: !fixed.png! > Ionic Palette: Empty list item > ------------------------------ > > Key: JBIDE-19551 > URL: https://issues.jboss.org/browse/JBIDE-19551 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: jsp/jsf/xml/html source editing > Affects Versions: 4.3.0.Alpha2 > Environment: Linux Ubuntu. GTK 3. > Reporter: Alexey Kazakov > Assignee: Viacheslav Kabanovich > Fix For: 4.3.0.Beta1 > > Attachments: fixed.png, list.png > > > In New List wizard, if there is more than one item then all items but the first are empty: > !list.png! -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBDS-3411) have installer build actually use M6 p2 product build

by Denis Golovin (JIRA)

[ https://issues.jboss.org/browse/JBDS-3411?page=com.atlassian.jira.plugin.... ] Denis Golovin edited comment on JBDS-3411 at 4/24/15 8:36 PM: -------------------------------------------------------------- I found better and simpler solution. Instead of renaming $\{target-dir\}/studio and have a bunch of changes in installer, I just changed where product is materialized under Mac OS X. In attached PR p2.director target dir is changed from $\{target-dir\}/studio to $\{target-dir\}/studio/jbdevstudio.app. That solution has all the benefits: 1. jbdevstudio.app location doesn't change; 2. jbdevstudio.app has the same structure as Eclipse.app and it is normal Mac OS X application package that contains all Eclipse artifacts (plug-ins, features and etc) inside; 3. jbdevstudio.ini is in right location and is not ignored anymore (BDS-3410 is fixed). The only drawback(?) tycho 0.23.0-SNAPSHOT should be used in jbdevstudio-product build. There are several unnecessary .png and .ico files but that is a different issue. was (Author: dgolovin): I found better and simpler solution. Instead of renaming ${target-dir}/studio and have a bunch of changes in installer, I just changed where product is materialized under Mac OS X. In attached PR p2.director target dir is changed from ${target-dir}/studio to ${target-dir}/studio/jbdevstudio.app. That solution has all the benefits: 1. jbdevstudio.app location doesn't change; 2. jbdevstudio.app has the same structure as Eclipse.app and it is normal Mac OS X application package that contains all Eclipse artifacts (plug-ins, features and etc) inside; 3. jbdevstudio.ini is in right location and is not ignored anymore (BDS-3410 is fixed). The only drawback(?) tycho 0.23.0-SNAPSHOT should be used in jbdevstudio-product build. There are several unnecessary .png and .ico files but that is a different issue. > 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)

11 years

1
0
0 / 0

[JBoss JIRA] (JBDS-3411) have installer build actually use M6 p2 product build

by Denis Golovin (JIRA)

[ https://issues.jboss.org/browse/JBDS-3411?page=com.atlassian.jira.plugin.... ] Denis Golovin commented on JBDS-3411: ------------------------------------- I found better and simpler solution. Instead of renaming ${target-dir}/studio and have a bunch of changes in installer, I just changed where product is materialized under Mac OS X. In attached PR p2.director target dir is changed from ${target-dir}/studio to ${target-dir}/studio/jbdevstudio.app. That solution has all the benefits: 1. jbdevstudio.app location doesn't change; 2. jbdevstudio.app has the same structure as Eclipse.app and it is normal Mac OS X application package that contains all Eclipse artifacts (plug-ins, features and etc) inside; 3. jbdevstudio.ini is in right location and is not ignored anymore (BDS-3410 is fixed). The only drawback(?) tycho 0.23.0-SNAPSHOT should be used in jbdevstudio-product build. There are several unnecessary .png and .ico files but that is a different issue. > 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)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-18818) Test timeout in org.jboss.tools.jsf.verification.test

by Alexey Kazakov (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18818?page=com.atlassian.jira.plugi... ] Alexey Kazakov updated JBIDE-18818: ----------------------------------- Fix Version/s: (was: 4.2.x) > Test timeout in org.jboss.tools.jsf.verification.test > ----------------------------------------------------- > > Key: JBIDE-18818 > URL: https://issues.jboss.org/browse/JBIDE-18818 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: jsf > Affects Versions: 4.2.1.CR1 > Reporter: Nick Boldt > Assignee: Alexey Kazakov > Priority: Blocker > Fix For: 4.3.x > > > Tests that time out due to blocking UI or other thread lock result in builds that are recorded as ABORTED [0]. This isn't a problem in terms of publishing new content because the build runs quickly, publishes the new bits, and THEN starts running tests. > [0] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_4.... > But where it IS a problem is where we use a buildflow job to run the whole stack of JBT projects. Buildflows will also abort if they encounter an aborted job [1]. > [1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-buildflow... > Why is this a problem? Because when we do a weekend spin (or respin) not all the projects in the stack are guaranteed to rebuild to verify all the downstream component tests all still work. > -- > If you cannot fix these tests so they run cleanly in Jenkins, please disable them or move them such that they can still be run LOCALLY using a profile, but will be skipped in Jenkins. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19714) seam.core test failure

by Alexey Kazakov (JIRA)

Alexey Kazakov created JBIDE-19714: -------------------------------------- Summary: seam.core test failure Key: JBIDE-19714 URL: https://issues.jboss.org/browse/JBIDE-19714 Project: Tools (JBoss Tools) Issue Type: Bug Components: seam2 Affects Versions: 4.3.0.Alpha2 Reporter: Alexey Kazakov Assignee: Daniel Azarov Fix For: 4.3.0.Beta1 Failed tests: SeamComponentRefactoringTest.testSeamComponentRename:90->renameComponent:142 There is unexpected number of changes expected:<7> but was:<3> SeamContextVariableRefactoringTest.testSeamContextVariable_Component_Rename:76->AbstractRefactorTest.checkRename:33 expected:<2> but was:<1> SeamEARTest.testEarProject:80 War project must see component 'org.jboss.seam.core.interpolator' declared in ejb project -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBDS-3411) have installer build actually use M6 p2 product build

by Denis Golovin (JIRA)

[ https://issues.jboss.org/browse/JBDS-3411?page=com.atlassian.jira.plugin.... ] Denis Golovin updated JBDS-3411: -------------------------------- Git Pull Request: https://github.com/jbdevstudio/jbdevstudio-product/pull/303 > 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)

11 years

1
0
0 / 0

[JBoss JIRA] (JBDS-3411) have installer build actually use M6 p2 product build

by Denis Golovin (JIRA)

[ https://issues.jboss.org/browse/JBDS-3411?page=com.atlassian.jira.plugin.... ] Denis Golovin updated JBDS-3411: -------------------------------- CDW devel_ack: + (was: ?) Status: New (was: New) > 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)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19713) Location for 'runtime-locations.proprty' file hardcodes 'studio' segment in relative path

by Denis Golovin (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19713?page=com.atlassian.jira.plugi... ] Denis Golovin updated JBIDE-19713: ---------------------------------- Summary: Location for 'runtime-locations.proprty' file hardcodes 'studio' segment in relative path (was: Location for 'runtime-locations.proprty' file hardcode 'studio' segment) > Location for 'runtime-locations.proprty' file hardcodes 'studio' segment in relative path > ----------------------------------------------------------------------------------------- > > Key: JBIDE-19713 > URL: https://issues.jboss.org/browse/JBIDE-19713 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: runtime-detection > Affects Versions: 4.3.0.Alpha2 > Reporter: Denis Golovin > Assignee: Denis Golovin > Fix For: 4.3.0.Beta1 > > > Latest p2 release introduces new RCP Product layout for Mac where all bits are located inside Product.app package. This leads to runtime detection not being able to find runtime-locations.properties file with default configuration for locations where to search for runtimes. It happens because path to file above has two extra path segments '../studio' which are not required at all. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19710) Add new caching strategy in URLTransportUtility

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19710?page=com.atlassian.jira.plugi... ] Fred Bricon edited comment on JBIDE-19710 at 4/24/15 5:45 PM: -------------------------------------------------------------- You're right, CACHE_FOREVER still performs the HEAD requests to check for updates. Using this strategy makes Central survive offline restarts. was (Author: fbricon): You're right CACHE_FOREVER still performs the HEAD requests to check for updates. Using this strategy makes Central survive offline restarts. > Add new caching strategy in URLTransportUtility > ----------------------------------------------- > > Key: JBIDE-19710 > URL: https://issues.jboss.org/browse/JBIDE-19710 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: common/jst/core > Affects Versions: 4.3.0.Alpha2 > Reporter: Fred Bricon > Assignee: Rob Stryker > Fix For: 4.3.0.Beta1 > > > Currently, you can use URLTransportUtility like > new URLTransportUtility().getCachedFileForURL(url, "Download stuff", lifespan, monitor); > with lifespan possible values being : > - URLTransportUtility.CACHE_UNTIL_EXIT : will cache the file during the workspace session > - URLTransportUtility.CACHE_FOREVER : will cache the file forever once downloaded > In certain cases, we want to be able to use CACHE_UNTIL_EXIT, but also be able to recover from network outages. So adding something like > - URLTransportUtility.SAFE_CACHE_UNTIL_EXIT (feel free to find a better name) : if the remote file is available, it will be downloaded on new Eclipse session, if it's not, the last valid cache will be returned. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19710) Add new caching strategy in URLTransportUtility

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19710?page=com.atlassian.jira.plugi... ] Fred Bricon resolved JBIDE-19710. --------------------------------- Resolution: Rejected You're right CACHE_FOREVER still performs the HEAD requests to check for updates. Using this strategy makes Central survive offline restarts. > Add new caching strategy in URLTransportUtility > ----------------------------------------------- > > Key: JBIDE-19710 > URL: https://issues.jboss.org/browse/JBIDE-19710 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: common/jst/core > Affects Versions: 4.3.0.Alpha2 > Reporter: Fred Bricon > Assignee: Rob Stryker > Fix For: 4.3.0.Beta1 > > > Currently, you can use URLTransportUtility like > new URLTransportUtility().getCachedFileForURL(url, "Download stuff", lifespan, monitor); > with lifespan possible values being : > - URLTransportUtility.CACHE_UNTIL_EXIT : will cache the file during the workspace session > - URLTransportUtility.CACHE_FOREVER : will cache the file forever once downloaded > In certain cases, we want to be able to use CACHE_UNTIL_EXIT, but also be able to recover from network outages. So adding something like > - URLTransportUtility.SAFE_CACHE_UNTIL_EXIT (feel free to find a better name) : if the remote file is available, it will be downloaded on new Eclipse session, if it's not, the last valid cache will be returned. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19710) Add new caching strategy in URLTransportUtility

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19710?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-19710: ------------------------------------- Hi Fred: Can you verify the current behavior of CACHE_FOREVER doesn't work for you? My understanding is that CACHE_FOREVER will still check the remote timestamp before attempting to download a new one, or will use the local cache. I suspect strongly that this should fit your usecase and another cache behavior isn't necessary. > Add new caching strategy in URLTransportUtility > ----------------------------------------------- > > Key: JBIDE-19710 > URL: https://issues.jboss.org/browse/JBIDE-19710 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: common/jst/core > Affects Versions: 4.3.0.Alpha2 > Reporter: Fred Bricon > Assignee: Rob Stryker > Fix For: 4.3.0.Beta1 > > > Currently, you can use URLTransportUtility like > new URLTransportUtility().getCachedFileForURL(url, "Download stuff", lifespan, monitor); > with lifespan possible values being : > - URLTransportUtility.CACHE_UNTIL_EXIT : will cache the file during the workspace session > - URLTransportUtility.CACHE_FOREVER : will cache the file forever once downloaded > In certain cases, we want to be able to use CACHE_UNTIL_EXIT, but also be able to recover from network outages. So adding something like > - URLTransportUtility.SAFE_CACHE_UNTIL_EXIT (feel free to find a better name) : if the remote file is available, it will be downloaded on new Eclipse session, if it's not, the last valid cache will be returned. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19266) Batch validation problems QuickFixes

by Alexey Kazakov (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19266?page=com.atlassian.jira.plugi... ] Alexey Kazakov updated JBIDE-19266: ----------------------------------- Sprint: Sprint #2 April 2015 (was: Sprint #3 May 2015) > Batch validation problems QuickFixes > ------------------------------------ > > Key: JBIDE-19266 > URL: https://issues.jboss.org/browse/JBIDE-19266 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: batch > Reporter: Alexey Kazakov > Assignee: Daniel Azarov > Labels: new_and_noteworthy > Fix For: 4.3.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19266) Batch validation problems QuickFixes

by Alexey Kazakov (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19266?page=com.atlassian.jira.plugi... ] Alexey Kazakov updated JBIDE-19266: ----------------------------------- Sprint: Sprint #3 May 2015 (was: Sprint #2 April 2015) > Batch validation problems QuickFixes > ------------------------------------ > > Key: JBIDE-19266 > URL: https://issues.jboss.org/browse/JBIDE-19266 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: batch > Reporter: Alexey Kazakov > Assignee: Daniel Azarov > Labels: new_and_noteworthy > Fix For: 4.3.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-18950) New Batch Artifact wizard

by Viacheslav Kabanovich (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18950?page=com.atlassian.jira.plugi... ] Viacheslav Kabanovich updated JBIDE-18950: ------------------------------------------ Description: There are about 20 artifacts in Java EE Batch: Batchlet; Checkpoint Algorithm; Decider; Item Reader; Item Writer; Item Processor; Partition Analyzer; Partition Reducer; Partition Collector; Partition Mapper; Partition Plan; Chunk Listener; Item Process Listener; Item Reader Listener; Item Writer Listener; Job Listener; Step Listener; Retry Process Listener; Retry Read Listener; Retry Write Listener; Skip Process Listener; Skip Listener; Skip Write Listener. We may have one wizard for each, or some of this artifacts. However, there is so much common in them that it makes sense also (or instead) to have one wizard with list choice of artifact. When a specific artifact should be created from the context of Batch XML editor, this wizard can be invoked with selection of that artifact (list of artifacts may be disabled or hidden). 1. Artifact implements a specific Java interface (for interfaces that have more than 1 method, there is optional abstract class to extend that implements rarely overridden methods); 2. Reference name should be provided for each artifact. There are 3 options: - An implementation of Batch runtime may define its own way of matching class to name. For example, CDI uses javax.inject.Named; - META-INF/batch.xml - by default, when first 2 options failed reference name is tried as the qualified class name. 3. Artifact class may declare fields, with values to be injected from properties set in job xml element referencing that artifact: {code} @Inject @BatchProperty(name="property1") String property; @Inject @BatchProperty String property2; {code} Thus, the wizard will have inputs as follows: - Source folder: [as in New Java Class wizard] - Package: [as in New Java Class wizard] - Name: [text] - Artifact: [combo] - [radio] implement interface [radio] extend abstract class (if class is not available, the option is disabled) - Reference name: (block of inputs) - Artifact loader: [radio] @Named [radio] batch.xml [radio] Class loader - Artifact name: [text] (for first 2 options filled with default value; for the last option disabled) - Properties: [list editor with 'Add' and 'Remove' buttons] Some more inputs may be inherited from New Java Class wizard, if default values are not enough. !artifact.png! was: There are about 20 artifacts in Java EE Batch: Batchlet; Checkpoint Algorithm; Decider; Item Reader; Item Writer; Item Processor; Partition Analyzer; Partition Reducer; Partition Collector; Partition Mapper; Partition Plan; Chunk Listener; Item Process Listener; Item Reader Listener; Item Writer Listener; Job Listener; Step Listener; Retry Process Listener; Retry Read Listener; Retry Write Listener; Skip Process Listener; Skip Listener; Skip Write Listener. We may have one wizard for each, or some of this artifacts. However, there is so much common in them that it makes sense also (or instead) to have one wizard with list choice of artifact. When a specific artifact should be created from the context of Batch XML editor, this wizard can be invoked with selection of that artifact (list of artifacts may be disabled or hidden). 1. Artifact implements a specific Java interface (for interfaces that have more than 1 method, there is optional abstract class to extend that implements rarely overridden methods); 2. Reference name should be provided for each artifact. There are 3 options: - An implementation of Batch runtime may define its own way of matching class to name. For example, CDI uses javax.inject.Named; - META-INF/batch.xml - by default, when first 2 options failed reference name is tried as the qualified class name. 3. Artifact class may declare fields, with values to be injected from properties set in job xml element referencing that artifact: {code} @Inject @BatchProperty(name="property1") String property; @Inject @BatchProperty String property2; {code} Thus, the wizard will have inputs as follows: - Artifact: [combo] - Source folder: [as in New Java Class wizard] - Package: [as in New Java Class wizard] - Class name: [text] - [radio] implement interface [radio] extend abstract class (if class is not available, the option is disabled) - Reference name: (block of inputs) | - [radio] Annotation Named [radio] batch.xml [radio] Qualified name | - Name: [text] (for first 2 options filled with default value; for the last option disabled) - Properties: [list editor with 'Add' and 'Remove' buttons] Some more inputs may be inherited from New Java Class wizard, if default values are not enough. !artifact.png! > New Batch Artifact wizard > ------------------------- > > Key: JBIDE-18950 > URL: https://issues.jboss.org/browse/JBIDE-18950 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: batch > Affects Versions: 4.3.0.Alpha1 > Reporter: Viacheslav Kabanovich > Assignee: Viacheslav Kabanovich > Labels: new_and_noteworthy > Fix For: 4.3.0.Beta1 > > Attachments: artifact.png, BatchArtifact.png, BatchArtifactWizBan.png > > > There are about 20 artifacts in Java EE Batch: > Batchlet; Checkpoint Algorithm; Decider; Item Reader; Item Writer; Item Processor; Partition Analyzer; Partition Reducer; Partition Collector; Partition Mapper; Partition Plan; Chunk Listener; Item Process Listener; Item Reader Listener; Item Writer Listener; Job Listener; Step Listener; Retry Process Listener; Retry Read Listener; Retry Write Listener; Skip Process Listener; Skip Listener; Skip Write Listener. > We may have one wizard for each, or some of this artifacts. However, there is so much common in them that it makes sense also (or instead) to have one wizard with list choice of artifact. When a specific artifact should be created from the context of Batch XML editor, this wizard can be invoked with selection of that artifact (list of artifacts may be disabled or hidden). > 1. Artifact implements a specific Java interface (for interfaces that have more than 1 method, there is optional abstract class to extend that implements rarely overridden methods); > 2. Reference name should be provided for each artifact. There are 3 options: > - An implementation of Batch runtime may define its own way of matching class to name. For example, CDI uses javax.inject.Named; > - META-INF/batch.xml > - by default, when first 2 options failed reference name is tried as the qualified class name. > 3. Artifact class may declare fields, with values to be injected from properties set in job xml element referencing that artifact: > {code} > @Inject @BatchProperty(name="property1") String property; > @Inject @BatchProperty String property2; > {code} > Thus, the wizard will have inputs as follows: > - Source folder: [as in New Java Class wizard] > - Package: [as in New Java Class wizard] > - Name: [text] > - Artifact: [combo] > - [radio] implement interface [radio] extend abstract class (if class is not available, the option is disabled) > - Reference name: (block of inputs) > - Artifact loader: [radio] @Named [radio] batch.xml [radio] Class loader > - Artifact name: [text] (for first 2 options filled with default value; for the last option disabled) > - Properties: [list editor with 'Add' and 'Remove' buttons] > Some more inputs may be inherited from New Java Class wizard, if default values are not enough. > !artifact.png! -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-18950) New Batch Artifact wizard

by Viacheslav Kabanovich (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18950?page=com.atlassian.jira.plugi... ] Viacheslav Kabanovich updated JBIDE-18950: ------------------------------------------ Description: There are about 20 artifacts in Java EE Batch: Batchlet; Checkpoint Algorithm; Decider; Item Reader; Item Writer; Item Processor; Partition Analyzer; Partition Reducer; Partition Collector; Partition Mapper; Partition Plan; Chunk Listener; Item Process Listener; Item Reader Listener; Item Writer Listener; Job Listener; Step Listener; Retry Process Listener; Retry Read Listener; Retry Write Listener; Skip Process Listener; Skip Listener; Skip Write Listener. We may have one wizard for each, or some of this artifacts. However, there is so much common in them that it makes sense also (or instead) to have one wizard with list choice of artifact. When a specific artifact should be created from the context of Batch XML editor, this wizard can be invoked with selection of that artifact (list of artifacts may be disabled or hidden). 1. Artifact implements a specific Java interface (for interfaces that have more than 1 method, there is optional abstract class to extend that implements rarely overridden methods); 2. Reference name should be provided for each artifact. There are 3 options: - An implementation of Batch runtime may define its own way of matching class to name. For example, CDI uses javax.inject.Named; - META-INF/batch.xml - by default, when first 2 options failed reference name is tried as the qualified class name. 3. Artifact class may declare fields, with values to be injected from properties set in job xml element referencing that artifact: {code} @Inject @BatchProperty(name="property1") String property; @Inject @BatchProperty String property2; {code} Thus, the wizard will have inputs as follows: - Artifact: [combo] - Source folder: [as in New Java Class wizard] - Package: [as in New Java Class wizard] - Class name: [text] - [radio] implement interface [radio] extend abstract class (if class is not available, the option is disabled) - Reference name: (block of inputs) | - [radio] Annotation Named [radio] batch.xml [radio] Qualified name | - Name: [text] (for first 2 options filled with default value; for the last option disabled) - Properties: [list editor with 'Add' and 'Remove' buttons] Some more inputs may be inherited from New Java Class wizard, if default values are not enough. !artifact.png! was: There are about 20 artifacts in Java EE Batch: Batchlet; Checkpoint Algorithm; Decider; Item Reader; Item Writer; Item Processor; Partition Analyzer; Partition Reducer; Partition Collector; Partition Mapper; Partition Plan; Chunk Listener; Item Process Listener; Item Reader Listener; Item Writer Listener; Job Listener; Step Listener; Retry Process Listener; Retry Read Listener; Retry Write Listener; Skip Process Listener; Skip Listener; Skip Write Listener. We may have one wizard for each, or some of this artifacts. However, there is so much common in them that it makes sense also (or instead) to have one wizard with list choice of artifact. When a specific artifact should be created from the context of Batch XML editor, this wizard can be invoked with selection of that artifact (list of artifacts may be disabled or hidden). 1. Artifact implements a specific Java interface (for interfaces that have more than 1 method, there is optional abstract class to extend that implements rarely overridden methods); 2. Reference name should be provided for each artifact. There are 3 options: - An implementation of Batch runtime may define its own way of matching class to name. For example, CDI uses javax.inject.Named; - META-INF/batch.xml - by default, when first 2 options failed reference name is tried as the qualified class name. 3. Artifact class may declare fields, with values to be injected from properties set in job xml element referencing that artifact: {code} @Inject @BatchProperty(name="property1") String property; @Inject @BatchProperty String property2; {code} Thus, the wizard will have inputs as follows: - Artifact: [combo] - Source folder: [as in New Java Class wizard] - Package: [as in New Java Class wizard] - Class name: [text] - [radio] implement interface [radio] extend abstract class (if class is not available, the option is disabled) - Reference name: (block of inputs) | - [radio] Annotation Named [radio] batch.xml [radio] Qualified name | - Name: [text] (for first 2 options filled with default value; for the last option disabled) - Properties: [table editor with 'Property name' and 'Field name' columns] Some more inputs may be inherited from New Java Class wizard, if default values are not enough. !artifact.png! > New Batch Artifact wizard > ------------------------- > > Key: JBIDE-18950 > URL: https://issues.jboss.org/browse/JBIDE-18950 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: batch > Affects Versions: 4.3.0.Alpha1 > Reporter: Viacheslav Kabanovich > Assignee: Viacheslav Kabanovich > Labels: new_and_noteworthy > Fix For: 4.3.0.Beta1 > > Attachments: artifact.png, BatchArtifact.png, BatchArtifactWizBan.png > > > There are about 20 artifacts in Java EE Batch: > Batchlet; Checkpoint Algorithm; Decider; Item Reader; Item Writer; Item Processor; Partition Analyzer; Partition Reducer; Partition Collector; Partition Mapper; Partition Plan; Chunk Listener; Item Process Listener; Item Reader Listener; Item Writer Listener; Job Listener; Step Listener; Retry Process Listener; Retry Read Listener; Retry Write Listener; Skip Process Listener; Skip Listener; Skip Write Listener. > We may have one wizard for each, or some of this artifacts. However, there is so much common in them that it makes sense also (or instead) to have one wizard with list choice of artifact. When a specific artifact should be created from the context of Batch XML editor, this wizard can be invoked with selection of that artifact (list of artifacts may be disabled or hidden). > 1. Artifact implements a specific Java interface (for interfaces that have more than 1 method, there is optional abstract class to extend that implements rarely overridden methods); > 2. Reference name should be provided for each artifact. There are 3 options: > - An implementation of Batch runtime may define its own way of matching class to name. For example, CDI uses javax.inject.Named; > - META-INF/batch.xml > - by default, when first 2 options failed reference name is tried as the qualified class name. > 3. Artifact class may declare fields, with values to be injected from properties set in job xml element referencing that artifact: > {code} > @Inject @BatchProperty(name="property1") String property; > @Inject @BatchProperty String property2; > {code} > Thus, the wizard will have inputs as follows: > - Artifact: [combo] > - Source folder: [as in New Java Class wizard] > - Package: [as in New Java Class wizard] > - Class name: [text] > - [radio] implement interface [radio] extend abstract class (if class is not available, the option is disabled) > - Reference name: (block of inputs) > | - [radio] Annotation Named [radio] batch.xml [radio] Qualified name > | - Name: [text] (for first 2 options filled with default value; for the last option disabled) > - Properties: [list editor with 'Add' and 'Remove' buttons] > Some more inputs may be inherited from New Java Class wizard, if default values are not enough. > !artifact.png! -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-18950) New Batch Artifact wizard

by Alexey Kazakov (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18950?page=com.atlassian.jira.plugi... ] Alexey Kazakov updated JBIDE-18950: ----------------------------------- Attachment: artifact.png > New Batch Artifact wizard > ------------------------- > > Key: JBIDE-18950 > URL: https://issues.jboss.org/browse/JBIDE-18950 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: batch > Affects Versions: 4.3.0.Alpha1 > Reporter: Viacheslav Kabanovich > Assignee: Viacheslav Kabanovich > Labels: new_and_noteworthy > Fix For: 4.3.0.Beta1 > > Attachments: artifact.png, BatchArtifact.png, BatchArtifactWizBan.png > > > There are about 20 artifacts in Java EE Batch: > Batchlet; Checkpoint Algorithm; Decider; Item Reader; Item Writer; Item Processor; Partition Analyzer; Partition Reducer; Partition Collector; Partition Mapper; Partition Plan; Chunk Listener; Item Process Listener; Item Reader Listener; Item Writer Listener; Job Listener; Step Listener; Retry Process Listener; Retry Read Listener; Retry Write Listener; Skip Process Listener; Skip Listener; Skip Write Listener. > We may have one wizard for each, or some of this artifacts. However, there is so much common in them that it makes sense also (or instead) to have one wizard with list choice of artifact. When a specific artifact should be created from the context of Batch XML editor, this wizard can be invoked with selection of that artifact (list of artifacts may be disabled or hidden). > 1. Artifact implements a specific Java interface (for interfaces that have more than 1 method, there is optional abstract class to extend that implements rarely overridden methods); > 2. Reference name should be provided for each artifact. There are 3 options: > - An implementation of Batch runtime may define its own way of matching class to name. For example, CDI uses javax.inject.Named; > - META-INF/batch.xml > - by default, when first 2 options failed reference name is tried as the qualified class name. > 3. Artifact class may declare fields, with values to be injected from properties set in job xml element referencing that artifact: > {code} > @Inject @BatchProperty(name="property1") String property; > @Inject @BatchProperty String property2; > {code} > Thus, the wizard will have inputs as follows: > - Artifact: [combo] > - Source folder: [as in New Java Class wizard] > - Package: [as in New Java Class wizard] > - Class name: [text] > - [radio] implement interface [radio] extend abstract class (if class is not available, the option is disabled) > - Reference name: (block of inputs) > | - [radio] Annotation Named [radio] batch.xml [radio] Qualified name > | - Name: [text] (for first 2 options filled with default value; for the last option disabled) > - Properties: [table editor with 'Property name' and 'Field name' columns] > Some more inputs may be inherited from New Java Class wizard, if default values are not enough. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-18950) New Batch Artifact wizard

by Alexey Kazakov (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18950?page=com.atlassian.jira.plugi... ] Alexey Kazakov updated JBIDE-18950: ----------------------------------- Description: There are about 20 artifacts in Java EE Batch: Batchlet; Checkpoint Algorithm; Decider; Item Reader; Item Writer; Item Processor; Partition Analyzer; Partition Reducer; Partition Collector; Partition Mapper; Partition Plan; Chunk Listener; Item Process Listener; Item Reader Listener; Item Writer Listener; Job Listener; Step Listener; Retry Process Listener; Retry Read Listener; Retry Write Listener; Skip Process Listener; Skip Listener; Skip Write Listener. We may have one wizard for each, or some of this artifacts. However, there is so much common in them that it makes sense also (or instead) to have one wizard with list choice of artifact. When a specific artifact should be created from the context of Batch XML editor, this wizard can be invoked with selection of that artifact (list of artifacts may be disabled or hidden). 1. Artifact implements a specific Java interface (for interfaces that have more than 1 method, there is optional abstract class to extend that implements rarely overridden methods); 2. Reference name should be provided for each artifact. There are 3 options: - An implementation of Batch runtime may define its own way of matching class to name. For example, CDI uses javax.inject.Named; - META-INF/batch.xml - by default, when first 2 options failed reference name is tried as the qualified class name. 3. Artifact class may declare fields, with values to be injected from properties set in job xml element referencing that artifact: {code} @Inject @BatchProperty(name="property1") String property; @Inject @BatchProperty String property2; {code} Thus, the wizard will have inputs as follows: - Artifact: [combo] - Source folder: [as in New Java Class wizard] - Package: [as in New Java Class wizard] - Class name: [text] - [radio] implement interface [radio] extend abstract class (if class is not available, the option is disabled) - Reference name: (block of inputs) | - [radio] Annotation Named [radio] batch.xml [radio] Qualified name | - Name: [text] (for first 2 options filled with default value; for the last option disabled) - Properties: [table editor with 'Property name' and 'Field name' columns] Some more inputs may be inherited from New Java Class wizard, if default values are not enough. !artifact.png! was: There are about 20 artifacts in Java EE Batch: Batchlet; Checkpoint Algorithm; Decider; Item Reader; Item Writer; Item Processor; Partition Analyzer; Partition Reducer; Partition Collector; Partition Mapper; Partition Plan; Chunk Listener; Item Process Listener; Item Reader Listener; Item Writer Listener; Job Listener; Step Listener; Retry Process Listener; Retry Read Listener; Retry Write Listener; Skip Process Listener; Skip Listener; Skip Write Listener. We may have one wizard for each, or some of this artifacts. However, there is so much common in them that it makes sense also (or instead) to have one wizard with list choice of artifact. When a specific artifact should be created from the context of Batch XML editor, this wizard can be invoked with selection of that artifact (list of artifacts may be disabled or hidden). 1. Artifact implements a specific Java interface (for interfaces that have more than 1 method, there is optional abstract class to extend that implements rarely overridden methods); 2. Reference name should be provided for each artifact. There are 3 options: - An implementation of Batch runtime may define its own way of matching class to name. For example, CDI uses javax.inject.Named; - META-INF/batch.xml - by default, when first 2 options failed reference name is tried as the qualified class name. 3. Artifact class may declare fields, with values to be injected from properties set in job xml element referencing that artifact: {code} @Inject @BatchProperty(name="property1") String property; @Inject @BatchProperty String property2; {code} Thus, the wizard will have inputs as follows: - Artifact: [combo] - Source folder: [as in New Java Class wizard] - Package: [as in New Java Class wizard] - Class name: [text] - [radio] implement interface [radio] extend abstract class (if class is not available, the option is disabled) - Reference name: (block of inputs) | - [radio] Annotation Named [radio] batch.xml [radio] Qualified name | - Name: [text] (for first 2 options filled with default value; for the last option disabled) - Properties: [table editor with 'Property name' and 'Field name' columns] Some more inputs may be inherited from New Java Class wizard, if default values are not enough. > New Batch Artifact wizard > ------------------------- > > Key: JBIDE-18950 > URL: https://issues.jboss.org/browse/JBIDE-18950 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: batch > Affects Versions: 4.3.0.Alpha1 > Reporter: Viacheslav Kabanovich > Assignee: Viacheslav Kabanovich > Labels: new_and_noteworthy > Fix For: 4.3.0.Beta1 > > Attachments: artifact.png, BatchArtifact.png, BatchArtifactWizBan.png > > > There are about 20 artifacts in Java EE Batch: > Batchlet; Checkpoint Algorithm; Decider; Item Reader; Item Writer; Item Processor; Partition Analyzer; Partition Reducer; Partition Collector; Partition Mapper; Partition Plan; Chunk Listener; Item Process Listener; Item Reader Listener; Item Writer Listener; Job Listener; Step Listener; Retry Process Listener; Retry Read Listener; Retry Write Listener; Skip Process Listener; Skip Listener; Skip Write Listener. > We may have one wizard for each, or some of this artifacts. However, there is so much common in them that it makes sense also (or instead) to have one wizard with list choice of artifact. When a specific artifact should be created from the context of Batch XML editor, this wizard can be invoked with selection of that artifact (list of artifacts may be disabled or hidden). > 1. Artifact implements a specific Java interface (for interfaces that have more than 1 method, there is optional abstract class to extend that implements rarely overridden methods); > 2. Reference name should be provided for each artifact. There are 3 options: > - An implementation of Batch runtime may define its own way of matching class to name. For example, CDI uses javax.inject.Named; > - META-INF/batch.xml > - by default, when first 2 options failed reference name is tried as the qualified class name. > 3. Artifact class may declare fields, with values to be injected from properties set in job xml element referencing that artifact: > {code} > @Inject @BatchProperty(name="property1") String property; > @Inject @BatchProperty String property2; > {code} > Thus, the wizard will have inputs as follows: > - Artifact: [combo] > - Source folder: [as in New Java Class wizard] > - Package: [as in New Java Class wizard] > - Class name: [text] > - [radio] implement interface [radio] extend abstract class (if class is not available, the option is disabled) > - Reference name: (block of inputs) > | - [radio] Annotation Named [radio] batch.xml [radio] Qualified name > | - Name: [text] (for first 2 options filled with default value; for the last option disabled) > - Properties: [table editor with 'Property name' and 'Field name' columns] > Some more inputs may be inherited from New Java Class wizard, if default values are not enough. > !artifact.png! -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19713) Location for 'runtime-locations.proprty' file hardcode 'studio' segment

by Denis Golovin (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19713?page=com.atlassian.jira.plugi... ] Denis Golovin reassigned JBIDE-19713: ------------------------------------- Assignee: Denis Golovin > Location for 'runtime-locations.proprty' file hardcode 'studio' segment > ----------------------------------------------------------------------- > > Key: JBIDE-19713 > URL: https://issues.jboss.org/browse/JBIDE-19713 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: runtime-detection > Affects Versions: 4.3.0.Alpha2 > Reporter: Denis Golovin > Assignee: Denis Golovin > Fix For: 4.3.0.Beta1 > > > Latest p2 release introduces new RCP Product layout for Mac where all bits are located inside Product.app package. This leads to runtime detection not being able to find runtime-locations.properties file with default configuration for locations where to search for runtimes. It happens because path to file above has two extra path segments '../studio' which are not required at all. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19713) Location for 'runtime-locations.proprty' file hardcode 'studio' segment

by Denis Golovin (JIRA)

Denis Golovin created JBIDE-19713: ------------------------------------- Summary: Location for 'runtime-locations.proprty' file hardcode 'studio' segment Key: JBIDE-19713 URL: https://issues.jboss.org/browse/JBIDE-19713 Project: Tools (JBoss Tools) Issue Type: Bug Components: runtime-detection Affects Versions: 4.3.0.Alpha2 Reporter: Denis Golovin Fix For: 4.3.0.Beta1 Latest p2 release introduces new RCP Product layout for Mac where all bits are located inside Product.app package. This leads to runtime detection not being able to find runtime-locations.properties file with default configuration for locations where to search for runtimes. It happens because path to file above has two extra path segments '../studio' which are not required at all. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19681) OpenShift New and Noteworthy for 4.3.0.Alpha2

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19681?page=com.atlassian.jira.plugi... ] Andre Dietisheim commented on JBIDE-19681: ------------------------------------------ content is ready to be merged. > OpenShift New and Noteworthy for 4.3.0.Alpha2 > --------------------------------------------- > > Key: JBIDE-19681 > URL: https://issues.jboss.org/browse/JBIDE-19681 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: openshift > Reporter: Alexey Kazakov > Assignee: Andre Dietisheim > Priority: Critical > Fix For: 4.3.0.Alpha2 > > > This [query|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+an...] contains the search for the specific component(s), to see all, use this [query|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+an...]. > If OpenShift is not listed here check if there are issues that should be added and add them. > Document the ones relevant for OpenShift by adding to [whatsnew|https://github.com/jbosstools/jbosstools-website/tree/master/doc...] and submit a pullrequest. > If no news for this component please reject and close this issue. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-17686) get TCF and RSE terminals to coexist without bad UX of multiple terminals

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-17686?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-17686: ------------------------------------- In a fresh m6 install, there's only one view there matching the string 'terminal' and it is in org.eclipse.tcf.te.ui.terminals (1.3.0.201503040858) The RSE "Remote Shell" view is still technically present, and is the default shell to open when browsing from the Remote System Explorer view. This is contributed by org.eclipse.rse.shells.ui (3.0.500.201403271554) > Optimally we could remove the RSE terminal and just use the new one Removing org.eclipse.rse.shells.ui (3.0.500.201403271554) probably won't fix anything. *WE* can just use the new one wherever we're using it, but by removing the RSE one, all we'd be doing is removing the ability to right-click on a connection in the Remote System Explorer and selecting "Launch Shell". It'd also probably break the following plugins, which seem to depend on it: 696 ACTIVE org.eclipse.rse.subsystems.shells.core_3.1.300.201403271554 697 ACTIVE org.eclipse.rse.subsystems.shells.dstore_2.1.400.201403100950 698 ACTIVE org.eclipse.rse.subsystems.shells.local_2.1.400.201403100950 699 ACTIVE org.eclipse.rse.subsystems.shells.ssh_2.1.400.201403100950 700 ACTIVE org.eclipse.rse.subsystems.shells.telnet_1.2.300.201403100950 In order to get "Launch Shell" to open one of the new terminals, instead, we'd probably need to remove all of the above plugins *and* provide replacements for them, that implement the same extension points and fill the same niche. Otherwise we'll be losing that action from the Remote System Explorer view to open a shell. Lars and the Fuse tools seem to be using a deprecated and disappeared terminal view: org.eclipse.tm.terminal.view. Either that or I'm pretty blind. But an 'ss' command in m6 does not show this view present at all. This view (org.eclipse.tm.terminal.view) is definitely present when using a fuseide dev-env and tp, so it seems to have been recently removed. Lars will 100% need to rewrite his terminal integration for any Mars release. It would be very very important for him to review the current proposed terminal to see it meets his API needs. So anyway, can TCF and RSE terminals co-exist without bad UI? Probably not. The RSE terminal is tied to the RSE views, and simply removing them removes functionality. We could rewrite the entire terminal portion of RSE, but since RSE is being deprecated / killed softly, that seems like a big waste of time (unless we planned to continue going with RSE even when it was no longer maintained, or take it over). It seems to me that just leaving them in is hte better short-term fix, but if we had ideas to take over RSE entirely, then it might make sense to get rid of their old crappy terminal and migrate them to the new one. Of course whether this is even technically possible hasn't been investigated by me yet. > get TCF and RSE terminals to coexist without bad UX of multiple terminals > ------------------------------------------------------------------------- > > Key: JBIDE-17686 > URL: https://issues.jboss.org/browse/JBIDE-17686 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: upstream > Affects Versions: 4.2.0.Beta2 > Reporter: Max Rydahl Andersen > Assignee: Rob Stryker > Priority: Minor > Fix For: 4.3.0.Beta1 > > Attachments: eclipse-can-has-many-consoles.png > > > luna has new Eclipse TCF terminal that brings better Terminal support. > I would assume it is in there but I couldn't find a way to actually open it. Maybe we havent included the full set of plugins. > http://marketplace.eclipse.org/content/tcf-terminals#.U6sJ92Vp7wV > http://eclipsesource.com/blogs/2014/06/17/tcf-terminal-top-eclipse-luna-f... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBDS-3408) installer is trying to reach download.jboss.org for content

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBDS-3408?page=com.atlassian.jira.plugin.... ] Max Rydahl Andersen commented on JBDS-3408: ------------------------------------------- cool thanks. if this happeend before - time to get a test in place to guard against it. > installer is trying to reach download.jboss.org for content > ----------------------------------------------------------- > > Key: JBDS-3408 > URL: https://issues.jboss.org/browse/JBDS-3408 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Components: installer > Affects Versions: 8.0.0.Alpha2 > Reporter: Max Rydahl Andersen > Assignee: Denis Golovin > Priority: Critical > Fix For: 9.0.0.Beta1 > > > Running latest devstudio 9 installer I caught it in reaching out to download.jboss.org which it should have *zero* links/dependency on. > My guess is there is an updatesite that have bad reference to download.jboss.org that we need fixing. > See screenshot at https://www.dropbox.com/s/wkr30jlvdc7d8wu/Screenshot%202015-04-15%2013.11... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19668) Freemarker New and Noteworthy for 4.3.0.Alpha2

by Denis Golovin (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19668?page=com.atlassian.jira.plugi... ] Denis Golovin closed JBIDE-19668. --------------------------------- Resolution: Rejected > Freemarker New and Noteworthy for 4.3.0.Alpha2 > ---------------------------------------------- > > Key: JBIDE-19668 > URL: https://issues.jboss.org/browse/JBIDE-19668 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: freemarker > Reporter: Alexey Kazakov > Priority: Critical > Fix For: 4.3.0.Alpha2 > > > This [query|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+an...] contains the search for the specific component(s), to see all, use this [query|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+an...]. > If Freemarker is not listed here check if there are issues that should be added and add them. > Document the ones relevant for Freemarker by adding to [whatsnew|https://github.com/jbosstools/jbosstools-website/tree/master/doc...] and submit a pullrequest. > If no news for this component please reject and close this issue. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBDS-2635) Installation sometimes fail with bundle was not found on Windows

by Denis Golovin (JIRA)

[ https://issues.jboss.org/browse/JBDS-2635?page=com.atlassian.jira.plugin.... ] Denis Golovin updated JBDS-2635: -------------------------------- Comment: was deleted (was: We'll try to use the same font as in title throughout the installer controls.) > Installation sometimes fail with bundle was not found on Windows > ---------------------------------------------------------------- > > Key: JBDS-2635 > URL: https://issues.jboss.org/browse/JBDS-2635 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Components: installer > Affects Versions: 7.0.0.Beta1 > Environment: JBDS 7.0.0.Beta1, W8_64, Java 1.7.0_07 > Reporter: Jiri Peterka > Assignee: Denis Golovin > Fix For: 9.0.0.Beta1 > > Attachments: 1369261136479.log, 1372203584223.log, 1372203590931.bak_0.log, 1372203590931.bak_1.log, 1372203590931.bak_2.log, 1372203590931.log, 1372355790692.log > > > For the first time JBDS 7.0.0.Beta1 failed on windows8: > {code} > An error occurred while installing the items > session context was:(profile=jbds, phase=org.eclipse.equinox.internal.p2.engine.phases.Install, operand=null --> [R]org.eclipse.jst.common.frameworks 1.1.601.v201208160700, action=org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.InstallBundleAction). > The artifact file for osgi.bundle,org.eclipse.jst.common.frameworks,1.1.601.v201208160700 was not found. > Application failed, log file location: C:\vw\jbds-7.0.0-beta1\studio\p2\director\configuration\1369261136579.log > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19256) Autocomplete shows white on white using default RHEL7 theme

by Denis Golovin (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19256?page=com.atlassian.jira.plugi... ] Denis Golovin commented on JBIDE-19256: --------------------------------------- I cannot, because I don't have RHEL7 subscription. > Autocomplete shows white on white using default RHEL7 theme > ----------------------------------------------------------- > > Key: JBIDE-19256 > URL: https://issues.jboss.org/browse/JBIDE-19256 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: jsp/jsf/xml/html source editing, upstream > Affects Versions: 4.2.0.Final > Environment: JBDS 8.0.0, RHEL 7 > Reporter: Alexey Kazakov > Assignee: Alexey Kazakov > Fix For: 4.3.0.Alpha1 > > > I can't see code completion in Eclipse while using default Adawaita theme in RHEL7. See attached screenshot > Tracked in upstream by https://bugs.eclipse.org/bugs/show_bug.cgi?id=439884 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19712) Add create from template details pain

by Jeff Cantrill (JIRA)

Jeff Cantrill created JBIDE-19712: ------------------------------------- Summary: Add create from template details pain Key: JBIDE-19712 URL: https://issues.jboss.org/browse/JBIDE-19712 Project: Tools (JBoss Tools) Issue Type: Sub-task Components: openshift Affects Versions: 4.3.0.Beta1 Reporter: Jeff Cantrill Assignee: Jeff Cantrill Add details pain similiar to v2 where you get template details when you select an individual template -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19711) WTP servertools integration with CDT launchbar

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19711?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-19711: ------------------------------------- Proof of concept is here: https://github.com/robstryker/jbt-experimental/tree/master/org.eclipse.ws... You'll also need to check out the following repo, which I've made modifications to: with my patches: https://github.com/robstryker/org.eclipse.launchbar/commits/bugfixes_only original: http://git.eclipse.org/c/cdt/org.eclipse.launchbar.git/ Finally, you'll need the org.eclipse.remote framework as well: git://git.eclipse.org/gitroot/ptp/org.eclipse.remote.git The PoC still needs a bit of cleanup (such as icons, etc), and the upstream launchbar still needs some cleanup as well. > WTP servertools integration with CDT launchbar > ---------------------------------------------- > > Key: JBIDE-19711 > URL: https://issues.jboss.org/browse/JBIDE-19711 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: server, upstream > Reporter: Rob Stryker > > CDT has a new framework called Launchbar https://wiki.eclipse.org/CDT/LaunchBar > Integrating this with servertools, proof of concept, to see how feasible it is. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19711) WTP servertools integration with CDT launchbar

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19711?page=com.atlassian.jira.plugi... ] Rob Stryker edited comment on JBIDE-19711 at 4/24/15 1:20 PM: -------------------------------------------------------------- Proof of concept is here: https://github.com/robstryker/jbt-experimental/ You'll also need to check out the following repo, which I've made modifications to: with my patches: https://github.com/robstryker/org.eclipse.launchbar/commits/bugfixes_only original: http://git.eclipse.org/c/cdt/org.eclipse.launchbar.git/ Finally, you'll need the org.eclipse.remote framework as well: git://git.eclipse.org/gitroot/ptp/org.eclipse.remote.git The PoC still needs a bit of cleanup (such as icons, etc), and the upstream launchbar still needs some cleanup as well. was (Author: rob.stryker): Proof of concept is here: https://github.com/robstryker/jbt-experimental/tree/master/org.eclipse.ws... You'll also need to check out the following repo, which I've made modifications to: with my patches: https://github.com/robstryker/org.eclipse.launchbar/commits/bugfixes_only original: http://git.eclipse.org/c/cdt/org.eclipse.launchbar.git/ Finally, you'll need the org.eclipse.remote framework as well: git://git.eclipse.org/gitroot/ptp/org.eclipse.remote.git The PoC still needs a bit of cleanup (such as icons, etc), and the upstream launchbar still needs some cleanup as well. > WTP servertools integration with CDT launchbar > ---------------------------------------------- > > Key: JBIDE-19711 > URL: https://issues.jboss.org/browse/JBIDE-19711 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: server, upstream > Reporter: Rob Stryker > > CDT has a new framework called Launchbar https://wiki.eclipse.org/CDT/LaunchBar > Integrating this with servertools, proof of concept, to see how feasible it is. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19711) WTP servertools integration with CDT launchbar

by Rob Stryker (JIRA)

Rob Stryker created JBIDE-19711: ----------------------------------- Summary: WTP servertools integration with CDT launchbar Key: JBIDE-19711 URL: https://issues.jboss.org/browse/JBIDE-19711 Project: Tools (JBoss Tools) Issue Type: Feature Request Components: server, upstream Reporter: Rob Stryker CDT has a new framework called Launchbar https://wiki.eclipse.org/CDT/LaunchBar Integrating this with servertools, proof of concept, to see how feasible it is. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19710) Add new caching strategy in URLTransportUtility

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19710?page=com.atlassian.jira.plugi... ] Fred Bricon commented on JBIDE-19710: ------------------------------------- A concrete use case is the JBoss Central page being downloaded once per session, but which also need to work when running offline. > Add new caching strategy in URLTransportUtility > ----------------------------------------------- > > Key: JBIDE-19710 > URL: https://issues.jboss.org/browse/JBIDE-19710 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: common/jst/core > Affects Versions: 4.3.0.Alpha2 > Reporter: Fred Bricon > Assignee: Rob Stryker > Fix For: 4.3.0.Beta1 > > > Currently, you can use URLTransportUtility like > new URLTransportUtility().getCachedFileForURL(url, "Download stuff", lifespan, monitor); > with lifespan possible values being : > - URLTransportUtility.CACHE_UNTIL_EXIT : will cache the file during the workspace session > - URLTransportUtility.CACHE_FOREVER : will cache the file forever once downloaded > In certain cases, we want to be able to use CACHE_UNTIL_EXIT, but also be able to recover from network outages. So adding something like > - URLTransportUtility.SAFE_CACHE_UNTIL_EXIT (feel free to find a better name) : if the remote file is available, it will be downloaded on new Eclipse session, if it's not, the last valid cache will be returned. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19710) Add new caching strategy in URLTransportUtility

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19710?page=com.atlassian.jira.plugi... ] Fred Bricon updated JBIDE-19710: -------------------------------- Component/s: common/jst/core > Add new caching strategy in URLTransportUtility > ----------------------------------------------- > > Key: JBIDE-19710 > URL: https://issues.jboss.org/browse/JBIDE-19710 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: common/jst/core > Affects Versions: 4.3.0.Alpha2 > Reporter: Fred Bricon > Assignee: Rob Stryker > Fix For: 4.3.0.Beta1 > > > Currently, you can use URLTransportUtility like > new URLTransportUtility().getCachedFileForURL(url, "Download stuff", lifespan, monitor); > with lifespan possible values being : > - URLTransportUtility.CACHE_UNTIL_EXIT : will cache the file during the workspace session > - URLTransportUtility.CACHE_FOREVER : will cache the file forever once downloaded > In certain cases, we want to be able to use CACHE_UNTIL_EXIT, but also be able to recover from network outages. So adding something like > - URLTransportUtility.SAFE_CACHE_UNTIL_EXIT (feel free to find a better name) : if the remote file is available, it will be downloaded on new Eclipse session, if it's not, the last valid cache will be returned. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19710) Add new caching strategy in URLTransportUtility

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19710?page=com.atlassian.jira.plugi... ] Fred Bricon reassigned JBIDE-19710: ----------------------------------- Assignee: Rob Stryker > Add new caching strategy in URLTransportUtility > ----------------------------------------------- > > Key: JBIDE-19710 > URL: https://issues.jboss.org/browse/JBIDE-19710 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Affects Versions: 4.3.0.Alpha2 > Reporter: Fred Bricon > Assignee: Rob Stryker > Fix For: 4.3.0.Beta1 > > > Currently, you can use URLTransportUtility like > new URLTransportUtility().getCachedFileForURL(url, "Download stuff", lifespan, monitor); > with lifespan possible values being : > - URLTransportUtility.CACHE_UNTIL_EXIT : will cache the file during the workspace session > - URLTransportUtility.CACHE_FOREVER : will cache the file forever once downloaded > In certain cases, we want to be able to use CACHE_UNTIL_EXIT, but also be able to recover from network outages. So adding something like > - URLTransportUtility.SAFE_CACHE_UNTIL_EXIT (feel free to find a better name) : if the remote file is available, it will be downloaded on new Eclipse session, if it's not, the last valid cache will be returned. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19710) Add new caching strategy in URLTransportUtility

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19710?page=com.atlassian.jira.plugi... ] Fred Bricon updated JBIDE-19710: -------------------------------- Fix Version/s: 4.3.0.Beta1 > Add new caching strategy in URLTransportUtility > ----------------------------------------------- > > Key: JBIDE-19710 > URL: https://issues.jboss.org/browse/JBIDE-19710 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Affects Versions: 4.3.0.Alpha2 > Reporter: Fred Bricon > Assignee: Rob Stryker > Fix For: 4.3.0.Beta1 > > > Currently, you can use URLTransportUtility like > new URLTransportUtility().getCachedFileForURL(url, "Download stuff", lifespan, monitor); > with lifespan possible values being : > - URLTransportUtility.CACHE_UNTIL_EXIT : will cache the file during the workspace session > - URLTransportUtility.CACHE_FOREVER : will cache the file forever once downloaded > In certain cases, we want to be able to use CACHE_UNTIL_EXIT, but also be able to recover from network outages. So adding something like > - URLTransportUtility.SAFE_CACHE_UNTIL_EXIT (feel free to find a better name) : if the remote file is available, it will be downloaded on new Eclipse session, if it's not, the last valid cache will be returned. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19710) Add new caching strategy in URLTransportUtility

by Fred Bricon (JIRA)

Fred Bricon created JBIDE-19710: ----------------------------------- Summary: Add new caching strategy in URLTransportUtility Key: JBIDE-19710 URL: https://issues.jboss.org/browse/JBIDE-19710 Project: Tools (JBoss Tools) Issue Type: Feature Request Affects Versions: 4.3.0.Alpha2 Reporter: Fred Bricon Currently, you can use URLTransportUtility like new URLTransportUtility().getCachedFileForURL(url, "Download stuff", lifespan, monitor); with lifespan possible values being : - URLTransportUtility.CACHE_UNTIL_EXIT : will cache the file during the workspace session - URLTransportUtility.CACHE_FOREVER : will cache the file forever once downloaded In certain cases, we want to be able to use CACHE_UNTIL_EXIT, but also be able to recover from network outages. So adding something like - URLTransportUtility.SAFE_CACHE_UNTIL_EXIT (feel free to find a better name) : if the remote file is available, it will be downloaded on new Eclipse session, if it's not, the last valid cache will be returned. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19703) Offline script is unable to resolve dependencies (error grabbing Grapes)

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19703?page=com.atlassian.jira.plugi... ] Fred Bricon reassigned JBIDE-19703: ----------------------------------- Assignee: Fred Bricon > Offline script is unable to resolve dependencies (error grabbing Grapes) > ------------------------------------------------------------------------ > > Key: JBIDE-19703 > URL: https://issues.jboss.org/browse/JBIDE-19703 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: project-examples > Affects Versions: 4.3.0.Alpha2 > Environment: JBDS 9.0.0.Alpha2 > Reporter: Radim Hopp > Assignee: Fred Bricon > Fix For: 4.3.0.Beta1 > > > When user has empty .groovy/grapes, offline script is not working: > {noformat}groovy "/home/rhopp/workspace-tests/.metadata/.plugins/org.jboss.tools.project.examples/offline/go_offline_3.0.0.Alpha2_v20150417_1854_B11.groovy" http://download.jboss.org/jbosstools/examples/4.3/project-examples-catego... http://download.jboss.org/jbosstools/examples/4.3/project-examples-shared... http://download.jboss.org/jbosstools/examples/4.3/project-examples-jbds90... http://download.jboss.org/gatein/quickstarts/jboss-portal-6.2/project-exa... -e |tee output > org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: > General error during conversion: Error grabbing Grapes -- [download failed: org.jboss.logging#jboss-logging;3.1.2.GA!jboss-logging.jar] > java.lang.RuntimeException: Error grabbing Grapes -- [download failed: org.jboss.logging#jboss-logging;3.1.2.GA!jboss-logging.jar] > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:422) > at org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:77) > at org.codehaus.groovy.reflection.CachedConstructor.doConstructorInvoke(CachedConstructor.java:71) > at org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrap.callConstructor(ConstructorSite.java:81) > at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:57) > at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:230) > at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:242) > at groovy.grape.GrapeIvy.getDependencies(GrapeIvy.groovy:418) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSite.invoke(PogoMetaMethodSite.java:166) > at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:56) > at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:49) > at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:149) > at groovy.grape.GrapeIvy.resolve(GrapeIvy.groovy:563) > at groovy.grape.GrapeIvy$resolve$1.callCurrent(Unknown Source) > at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:49) > at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:149) > at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:185) > at groovy.grape.GrapeIvy.resolve(GrapeIvy.groovy:532) > at groovy.grape.GrapeIvy$resolve$0.callCurrent(Unknown Source) > at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:49) > at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:149) > at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:177) > at groovy.grape.GrapeIvy.grab(GrapeIvy.groovy:254) > at groovy.grape.Grape.grab(Grape.java:163) > at groovy.grape.GrabAnnotationTransformation.visit(GrabAnnotationTransformation.java:358) > at org.codehaus.groovy.transform.ASTTransformationVisitor$3.call(ASTTransformationVisitor.java:319) > at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:928) > at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:590) > at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:566) > at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:543) > at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:297) > at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:267) > at groovy.lang.GroovyShell.parseClass(GroovyShell.java:692) > at groovy.lang.GroovyShell.run(GroovyShell.java:521) > at groovy.lang.GroovyShell.run(GroovyShell.java:511) > at groovy.ui.GroovyMain.processOnce(GroovyMain.java:650) > at groovy.ui.GroovyMain.run(GroovyMain.java:381) > at groovy.ui.GroovyMain.process(GroovyMain.java:367) > at groovy.ui.GroovyMain.processArgs(GroovyMain.java:126) > at groovy.ui.GroovyMain.main(GroovyMain.java:106) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:106) > at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:128) > 1 error > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19703) Offline script is unable to resolve dependencies (error grabbing Grapes)

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19703?page=com.atlassian.jira.plugi... ] Fred Bricon updated JBIDE-19703: -------------------------------- Fix Version/s: 4.3.0.Beta1 > Offline script is unable to resolve dependencies (error grabbing Grapes) > ------------------------------------------------------------------------ > > Key: JBIDE-19703 > URL: https://issues.jboss.org/browse/JBIDE-19703 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: project-examples > Affects Versions: 4.3.0.Alpha2 > Environment: JBDS 9.0.0.Alpha2 > Reporter: Radim Hopp > Assignee: Fred Bricon > Fix For: 4.3.0.Beta1 > > > When user has empty .groovy/grapes, offline script is not working: > {noformat}groovy "/home/rhopp/workspace-tests/.metadata/.plugins/org.jboss.tools.project.examples/offline/go_offline_3.0.0.Alpha2_v20150417_1854_B11.groovy" http://download.jboss.org/jbosstools/examples/4.3/project-examples-catego... http://download.jboss.org/jbosstools/examples/4.3/project-examples-shared... http://download.jboss.org/jbosstools/examples/4.3/project-examples-jbds90... http://download.jboss.org/gatein/quickstarts/jboss-portal-6.2/project-exa... -e |tee output > org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: > General error during conversion: Error grabbing Grapes -- [download failed: org.jboss.logging#jboss-logging;3.1.2.GA!jboss-logging.jar] > java.lang.RuntimeException: Error grabbing Grapes -- [download failed: org.jboss.logging#jboss-logging;3.1.2.GA!jboss-logging.jar] > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:422) > at org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:77) > at org.codehaus.groovy.reflection.CachedConstructor.doConstructorInvoke(CachedConstructor.java:71) > at org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrap.callConstructor(ConstructorSite.java:81) > at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:57) > at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:230) > at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:242) > at groovy.grape.GrapeIvy.getDependencies(GrapeIvy.groovy:418) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSite.invoke(PogoMetaMethodSite.java:166) > at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:56) > at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:49) > at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:149) > at groovy.grape.GrapeIvy.resolve(GrapeIvy.groovy:563) > at groovy.grape.GrapeIvy$resolve$1.callCurrent(Unknown Source) > at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:49) > at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:149) > at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:185) > at groovy.grape.GrapeIvy.resolve(GrapeIvy.groovy:532) > at groovy.grape.GrapeIvy$resolve$0.callCurrent(Unknown Source) > at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:49) > at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:149) > at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:177) > at groovy.grape.GrapeIvy.grab(GrapeIvy.groovy:254) > at groovy.grape.Grape.grab(Grape.java:163) > at groovy.grape.GrabAnnotationTransformation.visit(GrabAnnotationTransformation.java:358) > at org.codehaus.groovy.transform.ASTTransformationVisitor$3.call(ASTTransformationVisitor.java:319) > at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:928) > at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:590) > at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:566) > at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:543) > at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:297) > at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:267) > at groovy.lang.GroovyShell.parseClass(GroovyShell.java:692) > at groovy.lang.GroovyShell.run(GroovyShell.java:521) > at groovy.lang.GroovyShell.run(GroovyShell.java:511) > at groovy.ui.GroovyMain.processOnce(GroovyMain.java:650) > at groovy.ui.GroovyMain.run(GroovyMain.java:381) > at groovy.ui.GroovyMain.process(GroovyMain.java:367) > at groovy.ui.GroovyMain.processArgs(GroovyMain.java:126) > at groovy.ui.GroovyMain.main(GroovyMain.java:106) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:106) > at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:128) > 1 error > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19703) Offline script is unable to resolve dependencies (error grabbing Grapes)

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19703?page=com.atlassian.jira.plugi... ] Fred Bricon commented on JBIDE-19703: ------------------------------------- what version of Java/Groovy are you using? > Offline script is unable to resolve dependencies (error grabbing Grapes) > ------------------------------------------------------------------------ > > Key: JBIDE-19703 > URL: https://issues.jboss.org/browse/JBIDE-19703 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: project-examples > Affects Versions: 4.3.0.Alpha2 > Environment: JBDS 9.0.0.Alpha2 > Reporter: Radim Hopp > Assignee: Fred Bricon > Fix For: 4.3.0.Beta1 > > > When user has empty .groovy/grapes, offline script is not working: > {noformat}groovy "/home/rhopp/workspace-tests/.metadata/.plugins/org.jboss.tools.project.examples/offline/go_offline_3.0.0.Alpha2_v20150417_1854_B11.groovy" http://download.jboss.org/jbosstools/examples/4.3/project-examples-catego... http://download.jboss.org/jbosstools/examples/4.3/project-examples-shared... http://download.jboss.org/jbosstools/examples/4.3/project-examples-jbds90... http://download.jboss.org/gatein/quickstarts/jboss-portal-6.2/project-exa... -e |tee output > org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: > General error during conversion: Error grabbing Grapes -- [download failed: org.jboss.logging#jboss-logging;3.1.2.GA!jboss-logging.jar] > java.lang.RuntimeException: Error grabbing Grapes -- [download failed: org.jboss.logging#jboss-logging;3.1.2.GA!jboss-logging.jar] > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:422) > at org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:77) > at org.codehaus.groovy.reflection.CachedConstructor.doConstructorInvoke(CachedConstructor.java:71) > at org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrap.callConstructor(ConstructorSite.java:81) > at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:57) > at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:230) > at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:242) > at groovy.grape.GrapeIvy.getDependencies(GrapeIvy.groovy:418) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSite.invoke(PogoMetaMethodSite.java:166) > at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:56) > at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:49) > at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:149) > at groovy.grape.GrapeIvy.resolve(GrapeIvy.groovy:563) > at groovy.grape.GrapeIvy$resolve$1.callCurrent(Unknown Source) > at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:49) > at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:149) > at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:185) > at groovy.grape.GrapeIvy.resolve(GrapeIvy.groovy:532) > at groovy.grape.GrapeIvy$resolve$0.callCurrent(Unknown Source) > at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:49) > at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:149) > at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:177) > at groovy.grape.GrapeIvy.grab(GrapeIvy.groovy:254) > at groovy.grape.Grape.grab(Grape.java:163) > at groovy.grape.GrabAnnotationTransformation.visit(GrabAnnotationTransformation.java:358) > at org.codehaus.groovy.transform.ASTTransformationVisitor$3.call(ASTTransformationVisitor.java:319) > at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:928) > at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:590) > at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:566) > at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:543) > at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:297) > at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:267) > at groovy.lang.GroovyShell.parseClass(GroovyShell.java:692) > at groovy.lang.GroovyShell.run(GroovyShell.java:521) > at groovy.lang.GroovyShell.run(GroovyShell.java:511) > at groovy.ui.GroovyMain.processOnce(GroovyMain.java:650) > at groovy.ui.GroovyMain.run(GroovyMain.java:381) > at groovy.ui.GroovyMain.process(GroovyMain.java:367) > at groovy.ui.GroovyMain.processArgs(GroovyMain.java:126) > at groovy.ui.GroovyMain.main(GroovyMain.java:106) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:106) > at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:128) > 1 error > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19640) [thym] ClassCastException when trying to remove Platform with no engines

by Gorkem Ercan (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19640?page=com.atlassian.jira.plugi... ] Gorkem Ercan updated JBIDE-19640: --------------------------------- Fix Version/s: 4.3.0.Beta1 (was: 4.3.0.Alpha2) > [thym] ClassCastException when trying to remove Platform with no engines > ------------------------------------------------------------------------ > > Key: JBIDE-19640 > URL: https://issues.jboss.org/browse/JBIDE-19640 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: aerogear-hybrid, upstream > Affects Versions: 4.3.0.Alpha2 > Reporter: Pavol Srna > Fix For: 4.3.0.Beta1 > > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=465004 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19643) [thym] Cordova 3.7.1. engine is listed twice after download

by Gorkem Ercan (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19643?page=com.atlassian.jira.plugi... ] Gorkem Ercan updated JBIDE-19643: --------------------------------- Fix Version/s: 4.3.0.Beta1 (was: 4.3.0.Alpha2) > [thym] Cordova 3.7.1. engine is listed twice after download > ----------------------------------------------------------- > > Key: JBIDE-19643 > URL: https://issues.jboss.org/browse/JBIDE-19643 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: aerogear-hybrid, upstream > Affects Versions: 4.3.0.Alpha2 > Reporter: Pavol Srna > Fix For: 4.3.0.Beta1 > > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=465012 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19642) [thym] Can not detect version. VERSION file ~/.cordova/lib/android/cordova/4.0.0/CordovaLib/VERSION is missing

by Gorkem Ercan (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19642?page=com.atlassian.jira.plugi... ] Gorkem Ercan updated JBIDE-19642: --------------------------------- Fix Version/s: 4.3.0.Beta1 (was: 4.3.0.Alpha2) > [thym] Can not detect version. VERSION file ~/.cordova/lib/android/cordova/4.0.0/CordovaLib/VERSION is missing > -------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-19642 > URL: https://issues.jboss.org/browse/JBIDE-19642 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: aerogear-hybrid, upstream > Affects Versions: 4.3.0.Alpha2 > Reporter: Pavol Srna > Fix For: 4.3.0.Beta1 > > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=465011 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19639) [thym] ArrayIndexOutOfBoundsException when no engines are downloaded

by Gorkem Ercan (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19639?page=com.atlassian.jira.plugi... ] Gorkem Ercan updated JBIDE-19639: --------------------------------- Fix Version/s: 4.3.0.Beta1 (was: 4.3.0.Alpha2) > [thym] ArrayIndexOutOfBoundsException when no engines are downloaded > -------------------------------------------------------------------- > > Key: JBIDE-19639 > URL: https://issues.jboss.org/browse/JBIDE-19639 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: aerogear-hybrid, upstream > Affects Versions: 4.3.0.Alpha2 > Reporter: Pavol Srna > Fix For: 4.3.0.Beta1 > > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=465002 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19639) [thym] ArrayIndexOutOfBoundsException when no engines are downloaded

by Gorkem Ercan (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19639?page=com.atlassian.jira.plugi... ] Gorkem Ercan commented on JBIDE-19639: -------------------------------------- Moving to beta1 since a new thym version was not delivered > [thym] ArrayIndexOutOfBoundsException when no engines are downloaded > -------------------------------------------------------------------- > > Key: JBIDE-19639 > URL: https://issues.jboss.org/browse/JBIDE-19639 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: aerogear-hybrid, upstream > Affects Versions: 4.3.0.Alpha2 > Reporter: Pavol Srna > Fix For: 4.3.0.Beta1 > > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=465002 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19640) [thym] ClassCastException when trying to remove Platform with no engines

by Gorkem Ercan (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19640?page=com.atlassian.jira.plugi... ] Gorkem Ercan commented on JBIDE-19640: -------------------------------------- Moving to beta1 since a new thym version was not delivered > [thym] ClassCastException when trying to remove Platform with no engines > ------------------------------------------------------------------------ > > Key: JBIDE-19640 > URL: https://issues.jboss.org/browse/JBIDE-19640 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: aerogear-hybrid, upstream > Affects Versions: 4.3.0.Alpha2 > Reporter: Pavol Srna > Fix For: 4.3.0.Alpha2 > > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=465004 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19642) [thym] Can not detect version. VERSION file ~/.cordova/lib/android/cordova/4.0.0/CordovaLib/VERSION is missing

by Gorkem Ercan (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19642?page=com.atlassian.jira.plugi... ] Gorkem Ercan commented on JBIDE-19642: -------------------------------------- Moving to beta1 since a new thym version was not delivered > [thym] Can not detect version. VERSION file ~/.cordova/lib/android/cordova/4.0.0/CordovaLib/VERSION is missing > -------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-19642 > URL: https://issues.jboss.org/browse/JBIDE-19642 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: aerogear-hybrid, upstream > Affects Versions: 4.3.0.Alpha2 > Reporter: Pavol Srna > Fix For: 4.3.0.Alpha2 > > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=465011 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19671) Aerogear New and Noteworthy for 4.3.0.Alpha2

by Gorkem Ercan (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19671?page=com.atlassian.jira.plugi... ] Gorkem Ercan commented on JBIDE-19671: -------------------------------------- PR sent https://github.com/jbosstools/jbosstools-website/pull/384 > Aerogear New and Noteworthy for 4.3.0.Alpha2 > -------------------------------------------- > > Key: JBIDE-19671 > URL: https://issues.jboss.org/browse/JBIDE-19671 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: aerogear-hybrid > Reporter: Alexey Kazakov > Assignee: Gorkem Ercan > Priority: Critical > Fix For: 4.3.0.Alpha2 > > > This [query|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+an...] contains the search for the specific component(s), to see all, use this [query|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+an...]. > If Aerogear is not listed here check if there are issues that should be added and add them. > Document the ones relevant for Aerogear by adding to [whatsnew|https://github.com/jbosstools/jbosstools-website/tree/master/doc...] and submit a pullrequest. > If no news for this component please reject and close this issue. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19671) Aerogear New and Noteworthy for 4.3.0.Alpha2

by Gorkem Ercan (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19671?page=com.atlassian.jira.plugi... ] Gorkem Ercan resolved JBIDE-19671. ---------------------------------- Resolution: Done > Aerogear New and Noteworthy for 4.3.0.Alpha2 > -------------------------------------------- > > Key: JBIDE-19671 > URL: https://issues.jboss.org/browse/JBIDE-19671 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: aerogear-hybrid > Reporter: Alexey Kazakov > Assignee: Gorkem Ercan > Priority: Critical > Fix For: 4.3.0.Alpha2 > > > This [query|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+an...] contains the search for the specific component(s), to see all, use this [query|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+an...]. > If Aerogear is not listed here check if there are issues that should be added and add them. > Document the ones relevant for Aerogear by adding to [whatsnew|https://github.com/jbosstools/jbosstools-website/tree/master/doc...] and submit a pullrequest. > If no news for this component please reject and close this issue. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19671) Aerogear New and Noteworthy for 4.3.0.Alpha2

by Gorkem Ercan (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19671?page=com.atlassian.jira.plugi... ] Gorkem Ercan reassigned JBIDE-19671: ------------------------------------ Assignee: Gorkem Ercan > Aerogear New and Noteworthy for 4.3.0.Alpha2 > -------------------------------------------- > > Key: JBIDE-19671 > URL: https://issues.jboss.org/browse/JBIDE-19671 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: aerogear-hybrid > Reporter: Alexey Kazakov > Assignee: Gorkem Ercan > Priority: Critical > Fix For: 4.3.0.Alpha2 > > > This [query|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+an...] contains the search for the specific component(s), to see all, use this [query|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+an...]. > If Aerogear is not listed here check if there are issues that should be added and add them. > Document the ones relevant for Aerogear by adding to [whatsnew|https://github.com/jbosstools/jbosstools-website/tree/master/doc...] and submit a pullrequest. > If no news for this component please reject and close this issue. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19709) Deadlock when trying to stop multiple containers at the same time

by Xavier Coulon (JIRA)

Xavier Coulon created JBIDE-19709: ------------------------------------- Summary: Deadlock when trying to stop multiple containers at the same time Key: JBIDE-19709 URL: https://issues.jboss.org/browse/JBIDE-19709 Project: Tools (JBoss Tools) Issue Type: Bug Components: docker Affects Versions: 4.3.0.Alpha2 Reporter: Xavier Coulon Assignee: Xavier Coulon Fix For: 4.3.0.Beta1 When selecting multiple containers (mix of running and stopped or all running) and call the 'stop' method, the UI freezes after the fist container is stopped. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-18772) Include publish.sh in parent pom as versioned maven dependency

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18772?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-18772: ------------------------------------ Yes. For simple projects (base, server, ..., central) we can use `mvn deploy -Pdeploy-to-jboss.org`. For everyone else we can use `mvn deploy -Pdeploy-to-jboss.org -Doverride=this -Doverride=that -Doverride=the-other ...` We might also need a "copy-or-rename stuff after it's built before calling rsync" step. Otherwise the staging & release processes can handle renames as required (eg., when we have to strip qualifiers off JBDS artifacts so they use Beta1 instead of Beta1-v20150623-1234-B456). > Include publish.sh in parent pom as versioned maven dependency > -------------------------------------------------------------- > > Key: JBIDE-18772 > URL: https://issues.jboss.org/browse/JBIDE-18772 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Reporter: Max Rydahl Andersen > Assignee: Mickael Istria > Priority: Critical > Fix For: 4.3.0.Beta1 > > > instead of relying to publish.sh being on master, we should use a versioned publish.sh (or maybe even mojo) that the build then uses. > suggestion: > publish.sh (or mojo) gets released to our maven repo, use it in the pom.xml to perform publishing. > What this helps with is: > a) can do changes to publish mechanism without affecting every past builds. > b) more movable build system > c) isolated testing possible > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19605) Avoid need for multiple javax.servlet

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19605?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-19605: ------------------------------------ Remove it, rebuild it, and see what happens? > Avoid need for multiple javax.servlet > ------------------------------------- > > Key: JBIDE-19605 > URL: https://issues.jboss.org/browse/JBIDE-19605 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: target-platform, webservices > Affects Versions: 4.3.0.Alpha2 > Reporter: Mickael Istria > Assignee: Brian Fitzpatrick > Fix For: LATER > > > We currently use 2 different version of javax.servlet bundle. We'd rather decide on sticking to 1. > {code} > On 04/15/2015 11:56 PM, Nick Boldt wrote: > > Just wondering if anyone knows WHY we include javax.servlet 3.0.0 and > > 3.1.0 in JBDS. > > More importantly... SHOULD we be including both? Or can we just include > > 3.1.0 and drop 3.0.0? > I have JBDS installed from installer, which basically ran a p2 director. And I get jetty 3.0.0 and jetty 3.1.0. Than means that while resolving what to installed, p2 has to keep both versions of javax.servlet. That's definitely a sign that our dependency chain currently need both (or p2 wouldn't have installed both). > So I've tried the ultimate test: > $ cd jbdevstudio-9.0.0.Alpha2/studio > $ rm plugins/javax.servlet_3.0.0* > $ ./jbdevstudio > And saw > !ENTRY org.jboss.tools.ws.ui 4 0 2015-04-16 10:35:49.110 > !MESSAGE FrameworkEvent ERROR > !STACK 0 > org.osgi.framework.BundleException: Could not resolve module: org.jboss.tools.ws.ui [967] > Unresolved requirement: Import-Package: javax.servlet; version="[2.4.0,3.0.0)" > at org.eclipse.osgi.container.Module.start(Module.java:434) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1561) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) > at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) > at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) > Fun thing is that the javax.servlet_3.0.0 actually exports packages in version 2.6.0, whereas javax.servlet_3.1.0 exports them in version 3.1.0. > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBDS-3249) As an Integration User I would like to easily install parts of IS without many unnecessary intermediate steps

by Paul Leacu (JIRA)

[ https://issues.jboss.org/browse/JBDS-3249?page=com.atlassian.jira.plugin.... ] Paul Leacu updated JBDS-3249: ----------------------------- Fix Version/s: (was: 8.1.0.GA) > As an Integration User I would like to easily install parts of IS without many unnecessary intermediate steps > ------------------------------------------------------------------------------------------------------------- > > Key: JBDS-3249 > URL: https://issues.jboss.org/browse/JBDS-3249 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Epic > Components: installer, integration-platform, requirements, updatesite > Reporter: Max Rydahl Andersen > Assignee: Paul Leacu > Fix For: 9.0.0.GA > > > Today users can only install integration stack from jboss central which has some great advantages (uniform installation and only shows what is compatible/supported) but has the disadvantage of being an extra step on top of basic install plus harder to find. > Suggestion been to at least have marketplace entry for Integration stack (JBTIS-355 and JBDS-3293) and an focused installer that includes integration-stack (JBDS-3276) > From discussions from 12th December with Alan Santos we are targeting market place improvements for JBDS 8 and installers for JBDS 9. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19683) Create a user visible location for downloading tutorial metadata

by Petr Penicka (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19683?page=com.atlassian.jira.plugi... ] Petr Penicka commented on JBIDE-19683: -------------------------------------- Hi Max, let me provide the context first. The Fuse Tooling Tutorials book Jane is talking about is this [1]. It is different from a quickstart in that it does not provide a prefabricated deployable app, but goes one step back and demonstrates how to create one from scratch. Because the tutorial chapters go in a sequence, each utilizing code created in the previous one, we recently enhanced the book with downloadable files of the code created in each chapter. The primary delivery mechanism of this book has been the Customer Portal and as a side product, it has also been provided in Fuse Tooling embedded help. While it's easy to provide the downloads on the portal, it's not the case in the embedded help, so we were considering to provide the downloads on jboss.org. Though your suggested approach seems interesting in the long run, we don't have the resources to make that happen for the upcoming Fuse release. Because of that, we decided to drop the tutorial from the Fuse Tooling embedded help and only provide it on the Customer Portal. I hope this clarifies what was originally asked in this issue and as the request is not longer valid, I believe you can close the issue. Regards, Petr Penicka, Documentation Program Manager - Red Hat JBoss Fuse and A-MQ [1] https://access.redhat.com/site/documentation/en-US/Red_Hat_JBoss_Fuse/6.1... > Create a user visible location for downloading tutorial metadata > ---------------------------------------------------------------- > > Key: JBIDE-19683 > URL: https://issues.jboss.org/browse/JBIDE-19683 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: project-examples > Reporter: Jane Murphey > > Need to modify jbosstools-download.jboss.org to establish a directory to be used by documentation tutorials. Fuse Tooling will be the first. I will generate a PR soon. Please assign to me (jmurphey). -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19443) java.lang.NoClassDefFoundError in Reveng editor when using Hibernate 3.6

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19443?page=com.atlassian.jira.plugi... ] Koen Aers updated JBIDE-19443: ------------------------------ Sprint: Sprint #2 April 2015 > java.lang.NoClassDefFoundError in Reveng editor when using Hibernate 3.6 > ------------------------------------------------------------------------ > > Key: JBIDE-19443 > URL: https://issues.jboss.org/browse/JBIDE-19443 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: hibernate > Affects Versions: 4.2.3.Beta1 > Reporter: Jiri Peterka > Assignee: Koen Aers > Priority: Critical > Fix For: 4.3.0.Beta1 > > > java.lang.NoClassDefFoundError: Could not initialize class org.hibernate.cfg.reveng.OverrideRepository > at org.jboss.tools.hibernate.proxy.ServiceProxy.newOverrideRepository(ServiceProxy.java:198) > at org.hibernate.eclipse.mapper.editors.ReverseEngineeringEditor.getLazyDatabaseSchema(ReverseEngineeringEditor.java:207) > at org.hibernate.eclipse.mapper.editors.reveng.TablePropertiesBlock.doAdd(TablePropertiesBlock.java:172) > at org.hibernate.eclipse.mapper.editors.reveng.TablePropertiesBlock$1.widgetSelected(TablePropertiesBlock.java:128) > at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:248) > at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) > at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4454) > at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1388) > at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3799) > at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3409) > at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151) > at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) > at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032) > at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148) > at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:636) > at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) > at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:579) > at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150) > at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:135) > at org.jboss.reddeer.eclipse.core.UITestApplication.start(UITestApplication.java:47) > at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) > at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) > at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) > at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380) > at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648) > at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603) > at org.eclipse.equinox.launcher.Main.run(Main.java:1465) > at org.eclipse.equinox.launcher.Main.main(Main.java:1438) -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19431) Cannot generate ddl when hibernate console is used

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19431?page=com.atlassian.jira.plugi... ] Koen Aers updated JBIDE-19431: ------------------------------ Sprint: Sprint #2 April 2015 > Cannot generate ddl when hibernate console is used > -------------------------------------------------- > > Key: JBIDE-19431 > URL: https://issues.jboss.org/browse/JBIDE-19431 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: hibernate > Affects Versions: 4.2.3.Beta1 > Environment: JBDS 8.1.0.Beta1 > Reporter: Jiri Peterka > Assignee: Koen Aers > Priority: Critical > Fix For: 4.3.0.Beta1 > > > Cannot generate ddl when hibernate console is used. I will investigate further, it worked for 4.3 (and didn't work for lower hibernate versions) -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19605) Avoid need for multiple javax.servlet

by Xavier Coulon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19605?page=com.atlassian.jira.plugi... ] Xavier Coulon commented on JBIDE-19605: --------------------------------------- I have no idea how it's used on {{org.jboss.tools.ws.ui}}. But it's not used at all on JAX-RS. > Avoid need for multiple javax.servlet > ------------------------------------- > > Key: JBIDE-19605 > URL: https://issues.jboss.org/browse/JBIDE-19605 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: target-platform, webservices > Affects Versions: 4.3.0.Alpha2 > Reporter: Mickael Istria > Assignee: Brian Fitzpatrick > Fix For: LATER > > > We currently use 2 different version of javax.servlet bundle. We'd rather decide on sticking to 1. > {code} > On 04/15/2015 11:56 PM, Nick Boldt wrote: > > Just wondering if anyone knows WHY we include javax.servlet 3.0.0 and > > 3.1.0 in JBDS. > > More importantly... SHOULD we be including both? Or can we just include > > 3.1.0 and drop 3.0.0? > I have JBDS installed from installer, which basically ran a p2 director. And I get jetty 3.0.0 and jetty 3.1.0. Than means that while resolving what to installed, p2 has to keep both versions of javax.servlet. That's definitely a sign that our dependency chain currently need both (or p2 wouldn't have installed both). > So I've tried the ultimate test: > $ cd jbdevstudio-9.0.0.Alpha2/studio > $ rm plugins/javax.servlet_3.0.0* > $ ./jbdevstudio > And saw > !ENTRY org.jboss.tools.ws.ui 4 0 2015-04-16 10:35:49.110 > !MESSAGE FrameworkEvent ERROR > !STACK 0 > org.osgi.framework.BundleException: Could not resolve module: org.jboss.tools.ws.ui [967] > Unresolved requirement: Import-Package: javax.servlet; version="[2.4.0,3.0.0)" > at org.eclipse.osgi.container.Module.start(Module.java:434) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1561) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) > at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) > at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) > Fun thing is that the javax.servlet_3.0.0 actually exports packages in version 2.6.0, whereas javax.servlet_3.1.0 exports them in version 3.1.0. > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19535) Cannot generate ddl when hibernate console is NOT used

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19535?page=com.atlassian.jira.plugi... ] Koen Aers updated JBIDE-19535: ------------------------------ Sprint: Sprint #2 April 2015 > Cannot generate ddl when hibernate console is NOT used > ------------------------------------------------------ > > Key: JBIDE-19535 > URL: https://issues.jboss.org/browse/JBIDE-19535 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: hibernate > Affects Versions: 4.2.3.Beta1 > Environment: JBDS 8.1.0.GA > Reporter: Jiri Peterka > Assignee: Koen Aers > Priority: Critical > Fix For: 4.3.0.Beta1 > > > Cannot generate ddl when hibernate console is NOT used. It actually works when Hibernate 3.5, 3.6, 4.0 is used but not for 4.3. Found by extended automated tests. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19190) migrate VersionWatch to jbosstools-* repo

by Jiri Peterka (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19190?page=com.atlassian.jira.plugi... ] Jiri Peterka commented on JBIDE-19190: -------------------------------------- Max, there is a PR with latest updates - https://github.com/jbosstools/jbosstools-versionwatch/pull/1 > migrate VersionWatch to jbosstools-* repo > ----------------------------------------- > > Key: JBIDE-19190 > URL: https://issues.jboss.org/browse/JBIDE-19190 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: qa > Affects Versions: 4.3.0.Alpha1 > Reporter: Nick Boldt > Assignee: Jiri Peterka > Priority: Minor > Fix For: 4.3.0.Alpha2 > > > 0. decide where to put this... under jbosstools-ci or some new repo? Create a new component in JIRA accordingly. > 1. remove all refs to QA Jenkins file paths to make this more generic > 2. migrate those internal file paths into jenkins config.xml files > 3. document how to do installs for Eclipse, JBT or JBDS BYOE via commandline for setting up the footprint of installs against which to do baseline version watches -- pre-existing doc here: > http://download.jboss.org/jbosstools/updates/scripted-installation/ > https://devstudio.redhat.com/download/scripted-install/ > 4. test #3 to ensure it works, and that a mix of "studio" and "eclipse" folders can be used in a vwatch report -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19190) migrate VersionWatch to jbosstools-* repo

by Jiri Peterka (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19190?page=com.atlassian.jira.plugi... ] Jiri Peterka updated JBIDE-19190: --------------------------------- Git Pull Request: https://github.com/jbosstools/jbosstools-versionwatch/pull/1 > migrate VersionWatch to jbosstools-* repo > ----------------------------------------- > > Key: JBIDE-19190 > URL: https://issues.jboss.org/browse/JBIDE-19190 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: qa > Affects Versions: 4.3.0.Alpha1 > Reporter: Nick Boldt > Assignee: Jiri Peterka > Priority: Minor > Fix For: 4.3.0.Alpha2 > > > 0. decide where to put this... under jbosstools-ci or some new repo? Create a new component in JIRA accordingly. > 1. remove all refs to QA Jenkins file paths to make this more generic > 2. migrate those internal file paths into jenkins config.xml files > 3. document how to do installs for Eclipse, JBT or JBDS BYOE via commandline for setting up the footprint of installs against which to do baseline version watches -- pre-existing doc here: > http://download.jboss.org/jbosstools/updates/scripted-installation/ > https://devstudio.redhat.com/download/scripted-install/ > 4. test #3 to ensure it works, and that a mix of "studio" and "eclipse" folders can be used in a vwatch report -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19605) Avoid need for multiple javax.servlet

by Brian Fitzpatrick (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19605?page=com.atlassian.jira.plugi... ] Brian Fitzpatrick commented on JBIDE-19605: ------------------------------------------- Interesting. I wonder then if we need the bundle at all? > Avoid need for multiple javax.servlet > ------------------------------------- > > Key: JBIDE-19605 > URL: https://issues.jboss.org/browse/JBIDE-19605 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: target-platform, webservices > Affects Versions: 4.3.0.Alpha2 > Reporter: Mickael Istria > Assignee: Brian Fitzpatrick > Fix For: LATER > > > We currently use 2 different version of javax.servlet bundle. We'd rather decide on sticking to 1. > {code} > On 04/15/2015 11:56 PM, Nick Boldt wrote: > > Just wondering if anyone knows WHY we include javax.servlet 3.0.0 and > > 3.1.0 in JBDS. > > More importantly... SHOULD we be including both? Or can we just include > > 3.1.0 and drop 3.0.0? > I have JBDS installed from installer, which basically ran a p2 director. And I get jetty 3.0.0 and jetty 3.1.0. Than means that while resolving what to installed, p2 has to keep both versions of javax.servlet. That's definitely a sign that our dependency chain currently need both (or p2 wouldn't have installed both). > So I've tried the ultimate test: > $ cd jbdevstudio-9.0.0.Alpha2/studio > $ rm plugins/javax.servlet_3.0.0* > $ ./jbdevstudio > And saw > !ENTRY org.jboss.tools.ws.ui 4 0 2015-04-16 10:35:49.110 > !MESSAGE FrameworkEvent ERROR > !STACK 0 > org.osgi.framework.BundleException: Could not resolve module: org.jboss.tools.ws.ui [967] > Unresolved requirement: Import-Package: javax.servlet; version="[2.4.0,3.0.0)" > at org.eclipse.osgi.container.Module.start(Module.java:434) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1561) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) > at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) > at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) > Fun thing is that the javax.servlet_3.0.0 actually exports packages in version 2.6.0, whereas javax.servlet_3.1.0 exports them in version 3.1.0. > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19605) Avoid need for multiple javax.servlet

by Xavier Coulon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19605?page=com.atlassian.jira.plugi... ] Xavier Coulon commented on JBIDE-19605: --------------------------------------- [~bfitzpat], No, the https://github.com/jbosstools/jbosstools-webservices/blob/master/plugins/... only defines {{String}} constants that are later used to match specific class names, but the JAX-RS tooling does not depend on the {{javax.servlet}} bundle. > Avoid need for multiple javax.servlet > ------------------------------------- > > Key: JBIDE-19605 > URL: https://issues.jboss.org/browse/JBIDE-19605 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: target-platform, webservices > Affects Versions: 4.3.0.Alpha2 > Reporter: Mickael Istria > Assignee: Brian Fitzpatrick > Fix For: LATER > > > We currently use 2 different version of javax.servlet bundle. We'd rather decide on sticking to 1. > {code} > On 04/15/2015 11:56 PM, Nick Boldt wrote: > > Just wondering if anyone knows WHY we include javax.servlet 3.0.0 and > > 3.1.0 in JBDS. > > More importantly... SHOULD we be including both? Or can we just include > > 3.1.0 and drop 3.0.0? > I have JBDS installed from installer, which basically ran a p2 director. And I get jetty 3.0.0 and jetty 3.1.0. Than means that while resolving what to installed, p2 has to keep both versions of javax.servlet. That's definitely a sign that our dependency chain currently need both (or p2 wouldn't have installed both). > So I've tried the ultimate test: > $ cd jbdevstudio-9.0.0.Alpha2/studio > $ rm plugins/javax.servlet_3.0.0* > $ ./jbdevstudio > And saw > !ENTRY org.jboss.tools.ws.ui 4 0 2015-04-16 10:35:49.110 > !MESSAGE FrameworkEvent ERROR > !STACK 0 > org.osgi.framework.BundleException: Could not resolve module: org.jboss.tools.ws.ui [967] > Unresolved requirement: Import-Package: javax.servlet; version="[2.4.0,3.0.0)" > at org.eclipse.osgi.container.Module.start(Module.java:434) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1561) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) > at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) > at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) > Fun thing is that the javax.servlet_3.0.0 actually exports packages in version 2.6.0, whereas javax.servlet_3.1.0 exports them in version 3.1.0. > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBTIS-416) Need to doc split of SOA Development between release and early access

by Paul Leacu (JIRA)

[ https://issues.jboss.org/browse/JBTIS-416?page=com.atlassian.jira.plugin.... ] Paul Leacu commented on JBTIS-416: ---------------------------------- Thanks Misha - looks good to me. [~apodhrad] - what do you think? > 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)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19708) Runtime-detection is not supporting Servlet only distribution of Wildfly 9

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19708?page=com.atlassian.jira.plugi... ] Fred Bricon updated JBIDE-19708: -------------------------------- Component/s: server > Runtime-detection is not supporting Servlet only distribution of Wildfly 9 > -------------------------------------------------------------------------- > > Key: JBIDE-19708 > URL: https://issues.jboss.org/browse/JBIDE-19708 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: runtime-detection, server > Affects Versions: 4.3.0.Alpha2 > Reporter: Radim Hopp > > Runtime detection correctly detects servlet-only distribution of wildfly 9, but fails to add it. Error log is silent. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19708) Runtime-detection is not supporting Servlet only distribution of Wildfly 9

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19708?page=com.atlassian.jira.plugi... ] Fred Bricon reassigned JBIDE-19708: ----------------------------------- Assignee: Rob Stryker > Runtime-detection is not supporting Servlet only distribution of Wildfly 9 > -------------------------------------------------------------------------- > > Key: JBIDE-19708 > URL: https://issues.jboss.org/browse/JBIDE-19708 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: runtime-detection, server > Affects Versions: 4.3.0.Alpha2 > Reporter: Radim Hopp > Assignee: Rob Stryker > > Runtime detection correctly detects servlet-only distribution of wildfly 9, but fails to add it. Error log is silent. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBDS-3408) installer is trying to reach download.jboss.org for content

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBDS-3408?page=com.atlassian.jira.plugin.... ] Nick Boldt commented on JBDS-3408: ---------------------------------- I'll try to reproduce with one of the latest builds here http://www.qa.jboss.com/binaries/RHDS/9.0/snapshots/builds/devstudio.prod... > installer is trying to reach download.jboss.org for content > ----------------------------------------------------------- > > Key: JBDS-3408 > URL: https://issues.jboss.org/browse/JBDS-3408 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Components: installer > Affects Versions: 8.0.0.Alpha2 > Reporter: Max Rydahl Andersen > Assignee: Denis Golovin > Priority: Critical > Fix For: 9.0.0.Beta1 > > > Running latest devstudio 9 installer I caught it in reaching out to download.jboss.org which it should have *zero* links/dependency on. > My guess is there is an updatesite that have bad reference to download.jboss.org that we need fixing. > See screenshot at https://www.dropbox.com/s/wkr30jlvdc7d8wu/Screenshot%202015-04-15%2013.11... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-18348) Add support for WildFly 9

by Radim Hopp (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18348?page=com.atlassian.jira.plugi... ] Radim Hopp closed JBIDE-18348. ------------------------------ Resolution: Done Done: JBIDE-19708. Closing this one. > Add support for WildFly 9 > ------------------------- > > Key: JBIDE-18348 > URL: https://issues.jboss.org/browse/JBIDE-18348 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: runtime-detection, server > Affects Versions: 4.2.0.CR1 > Reporter: Martin Malina > Assignee: Rob Stryker > Labels: new_and_noteworthy > Fix For: 4.3.0.Alpha2 > > > Now that WildFly 9.0.0.Alpha1 is out, we need to make sure it works properly with JBT/JBDS. > I played with it a little, tried to start/stop, deploy a project and so far I haven't seen any issue. > Other than the one expected that is - when you add the server, you get a warning that the runtime version doesn't match - it detected 9, but 8 is expected. We need to deal with this somehow. > Runtime detection doesn't work. It find the server (although with a strange Type of "WILDFLY-FULL"), but doesn't actually add it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBDS-3408) installer is trying to reach download.jboss.org for content

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBDS-3408?page=com.atlassian.jira.plugin.... ] Nick Boldt commented on JBDS-3408: ---------------------------------- This might be a consequence of one or more of the update sites within the JBDS installer not having had its associate sites scrubbed out (to remove all feature.xml refs to upstream URLs at eclipse.org or jboss.org). If so, might be a dupe of what caused JBDS-3423. > installer is trying to reach download.jboss.org for content > ----------------------------------------------------------- > > Key: JBDS-3408 > URL: https://issues.jboss.org/browse/JBDS-3408 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Components: installer > Affects Versions: 8.0.0.Alpha2 > Reporter: Max Rydahl Andersen > Assignee: Denis Golovin > Priority: Critical > Fix For: 9.0.0.Beta1 > > > Running latest devstudio 9 installer I caught it in reaching out to download.jboss.org which it should have *zero* links/dependency on. > My guess is there is an updatesite that have bad reference to download.jboss.org that we need fixing. > See screenshot at https://www.dropbox.com/s/wkr30jlvdc7d8wu/Screenshot%202015-04-15%2013.11... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19708) Runtime-detection is not supporting Servlet only distribution of Wildfly 9

by Radim Hopp (JIRA)

Radim Hopp created JBIDE-19708: ---------------------------------- Summary: Runtime-detection is not supporting Servlet only distribution of Wildfly 9 Key: JBIDE-19708 URL: https://issues.jboss.org/browse/JBIDE-19708 Project: Tools (JBoss Tools) Issue Type: Bug Components: runtime-detection Affects Versions: 4.3.0.Alpha2 Reporter: Radim Hopp Runtime detection correctly detects servlet-only distribution of wildfly 9, but fails to add it. Error log is silent. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBDS-3408) installer is trying to reach download.jboss.org for content

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBDS-3408?page=com.atlassian.jira.plugin.... ] Max Rydahl Andersen commented on JBDS-3408: ------------------------------------------- nick - the latest installer of devstudio 9 as available april 15 when this bug was opened. since then there been more builds and I have deleted the installer so I cannot give you more info than that and should not need to since we have nighlty builds of the installer. if you cannot reproduce the issue the issue is fixed. > installer is trying to reach download.jboss.org for content > ----------------------------------------------------------- > > Key: JBDS-3408 > URL: https://issues.jboss.org/browse/JBDS-3408 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Components: installer > Affects Versions: 8.0.0.Alpha2 > Reporter: Max Rydahl Andersen > Assignee: Denis Golovin > Priority: Critical > Fix For: 9.0.0.Beta1 > > > Running latest devstudio 9 installer I caught it in reaching out to download.jboss.org which it should have *zero* links/dependency on. > My guess is there is an updatesite that have bad reference to download.jboss.org that we need fixing. > See screenshot at https://www.dropbox.com/s/wkr30jlvdc7d8wu/Screenshot%202015-04-15%2013.11... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBDS-3408) installer is trying to reach download.jboss.org for content

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBDS-3408?page=com.atlassian.jira.plugin.... ] Max Rydahl Andersen edited comment on JBDS-3408 at 4/24/15 9:33 AM: -------------------------------------------------------------------- nick - the latest installer of devstudio 9 as available april 15 when this bug was opened. since then there been more builds and I have deleted the installer so I cannot give you more info than that and should not need to since we have nighlty builds of the installer. if you cannot reproduce the issue the issue is probably fixed. was (Author: maxandersen): nick - the latest installer of devstudio 9 as available april 15 when this bug was opened. since then there been more builds and I have deleted the installer so I cannot give you more info than that and should not need to since we have nighlty builds of the installer. if you cannot reproduce the issue the issue is fixed. > installer is trying to reach download.jboss.org for content > ----------------------------------------------------------- > > Key: JBDS-3408 > URL: https://issues.jboss.org/browse/JBDS-3408 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Components: installer > Affects Versions: 8.0.0.Alpha2 > Reporter: Max Rydahl Andersen > Assignee: Denis Golovin > Priority: Critical > Fix For: 9.0.0.Beta1 > > > Running latest devstudio 9 installer I caught it in reaching out to download.jboss.org which it should have *zero* links/dependency on. > My guess is there is an updatesite that have bad reference to download.jboss.org that we need fixing. > See screenshot at https://www.dropbox.com/s/wkr30jlvdc7d8wu/Screenshot%202015-04-15%2013.11... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBDS-3408) installer is trying to reach download.jboss.org for content

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBDS-3408?page=com.atlassian.jira.plugin.... ] Nick Boldt commented on JBDS-3408: ---------------------------------- Max: I used the latest. Nick: Please state which *version* you used. Max: The version is the latest. Nick: http://cdn.alltheragefaces.com/img/faces/large/misc-jackie-chan-l.png --- How would you see sites "in the installer" ? > installer is trying to reach download.jboss.org for content > ----------------------------------------------------------- > > Key: JBDS-3408 > URL: https://issues.jboss.org/browse/JBDS-3408 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Components: installer > Affects Versions: 8.0.0.Alpha2 > Reporter: Max Rydahl Andersen > Assignee: Denis Golovin > Priority: Critical > Fix For: 9.0.0.Beta1 > > > Running latest devstudio 9 installer I caught it in reaching out to download.jboss.org which it should have *zero* links/dependency on. > My guess is there is an updatesite that have bad reference to download.jboss.org that we need fixing. > See screenshot at https://www.dropbox.com/s/wkr30jlvdc7d8wu/Screenshot%202015-04-15%2013.11... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-18847) Extract discovery code out of project examples

by Radim Hopp (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18847?page=com.atlassian.jira.plugi... ] Radim Hopp closed JBIDE-18847. ------------------------------ As this is ust refactoring and I didn't find any problems during testing of JBDS 9.0.0.Alpha2 I suppose this is correctly sovled. Closing. > Extract discovery code out of project examples > ---------------------------------------------- > > Key: JBIDE-18847 > URL: https://issues.jboss.org/browse/JBIDE-18847 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: project-examples > Affects Versions: 4.2.0.Final > Reporter: Fred Bricon > Assignee: Fred Bricon > Fix For: 4.3.0.Alpha1 > > > Discovery code used by central (to install software) and project-examples (to discover proxy-wizards) lives in project examples. Because of that dependency, project examples also contain API that configures central content. That forces com.jboss.devstudio.core.central to depend on project examples, just to configure central contents. > This sucks big time and that common discovery code should be extracted to another component, consumed by both central and examples. The central configuration API should move back to central. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-18348) Add support for WildFly 9

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18348?page=com.atlassian.jira.plugi... ] Fred Bricon commented on JBIDE-18348: ------------------------------------- [~rhopp] please resolve this one and open a new ticket for Wildfly Servet support. > Add support for WildFly 9 > ------------------------- > > Key: JBIDE-18348 > URL: https://issues.jboss.org/browse/JBIDE-18348 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: runtime-detection, server > Affects Versions: 4.2.0.CR1 > Reporter: Martin Malina > Assignee: Rob Stryker > Labels: new_and_noteworthy > Fix For: 4.3.0.Alpha2 > > > Now that WildFly 9.0.0.Alpha1 is out, we need to make sure it works properly with JBT/JBDS. > I played with it a little, tried to start/stop, deploy a project and so far I haven't seen any issue. > Other than the one expected that is - when you add the server, you get a warning that the runtime version doesn't match - it detected 9, but 8 is expected. We need to deal with this somehow. > Runtime detection doesn't work. It find the server (although with a strange Type of "WILDFLY-FULL"), but doesn't actually add it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19566) Central allows to "Update" items with no updates available, then produces an error

by Radim Hopp (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19566?page=com.atlassian.jira.plugi... ] Radim Hopp closed JBIDE-19566. ------------------------------ Verified in JBDS 9.0.0.Alpha2. Closing. > Central allows to "Update" items with no updates available, then produces an error > ---------------------------------------------------------------------------------- > > Key: JBIDE-19566 > URL: https://issues.jboss.org/browse/JBIDE-19566 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: central > Affects Versions: 4.2.3.CR1 > Reporter: Jan Richter > Assignee: Mickael Istria > Fix For: 4.3.0.Alpha2 > > > It is possible to select installed items in central before it finishes checking for their updates. Clicking "Update" will then produce an error: > Problems occurred while performing installation: There are no connectors to install > There are no connectors to install > I understand it is trying to say there is nothing to update, but I would expect a more user friendly response. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19605) Avoid need for multiple javax.servlet

by Brian Fitzpatrick (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19605?page=com.atlassian.jira.plugi... ] Brian Fitzpatrick edited comment on JBIDE-19605 at 4/24/15 8:53 AM: -------------------------------------------------------------------- It's added here: https://github.com/jbosstools/jbosstools-webservices/blob/master/plugins/... And being referenced by the JAX-RS tooling support here - https://github.com/jbosstools/jbosstools-webservices/blob/master/plugins/... [~xcoulon] Can you illuminate the need for javax.servlet support here and if we can change the version range to avoid the clash with Jetty? was (Author: bfitzpat): It is being added by the JAX-RS tooling support here - https://github.com/jbosstools/jbosstools-webservices/blob/master/plugins/... [~xcoulon] Can you illuminate the need for javax.servlet support here and if we can change the version range to avoid the clash with Jetty? > Avoid need for multiple javax.servlet > ------------------------------------- > > Key: JBIDE-19605 > URL: https://issues.jboss.org/browse/JBIDE-19605 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: target-platform, webservices > Affects Versions: 4.3.0.Alpha2 > Reporter: Mickael Istria > Assignee: Brian Fitzpatrick > Fix For: LATER > > > We currently use 2 different version of javax.servlet bundle. We'd rather decide on sticking to 1. > {code} > On 04/15/2015 11:56 PM, Nick Boldt wrote: > > Just wondering if anyone knows WHY we include javax.servlet 3.0.0 and > > 3.1.0 in JBDS. > > More importantly... SHOULD we be including both? Or can we just include > > 3.1.0 and drop 3.0.0? > I have JBDS installed from installer, which basically ran a p2 director. And I get jetty 3.0.0 and jetty 3.1.0. Than means that while resolving what to installed, p2 has to keep both versions of javax.servlet. That's definitely a sign that our dependency chain currently need both (or p2 wouldn't have installed both). > So I've tried the ultimate test: > $ cd jbdevstudio-9.0.0.Alpha2/studio > $ rm plugins/javax.servlet_3.0.0* > $ ./jbdevstudio > And saw > !ENTRY org.jboss.tools.ws.ui 4 0 2015-04-16 10:35:49.110 > !MESSAGE FrameworkEvent ERROR > !STACK 0 > org.osgi.framework.BundleException: Could not resolve module: org.jboss.tools.ws.ui [967] > Unresolved requirement: Import-Package: javax.servlet; version="[2.4.0,3.0.0)" > at org.eclipse.osgi.container.Module.start(Module.java:434) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1561) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) > at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) > at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) > Fun thing is that the javax.servlet_3.0.0 actually exports packages in version 2.6.0, whereas javax.servlet_3.1.0 exports them in version 3.1.0. > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19605) Avoid need for multiple javax.servlet

by Brian Fitzpatrick (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19605?page=com.atlassian.jira.plugi... ] Brian Fitzpatrick commented on JBIDE-19605: ------------------------------------------- It is being added by the JAX-RS tooling support here - https://github.com/jbosstools/jbosstools-webservices/blob/master/plugins/... [~xcoulon] Can you illuminate the need for javax.servlet support here and if we can change the version range to avoid the clash with Jetty? > Avoid need for multiple javax.servlet > ------------------------------------- > > Key: JBIDE-19605 > URL: https://issues.jboss.org/browse/JBIDE-19605 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: target-platform, webservices > Affects Versions: 4.3.0.Alpha2 > Reporter: Mickael Istria > Assignee: Brian Fitzpatrick > Fix For: LATER > > > We currently use 2 different version of javax.servlet bundle. We'd rather decide on sticking to 1. > {code} > On 04/15/2015 11:56 PM, Nick Boldt wrote: > > Just wondering if anyone knows WHY we include javax.servlet 3.0.0 and > > 3.1.0 in JBDS. > > More importantly... SHOULD we be including both? Or can we just include > > 3.1.0 and drop 3.0.0? > I have JBDS installed from installer, which basically ran a p2 director. And I get jetty 3.0.0 and jetty 3.1.0. Than means that while resolving what to installed, p2 has to keep both versions of javax.servlet. That's definitely a sign that our dependency chain currently need both (or p2 wouldn't have installed both). > So I've tried the ultimate test: > $ cd jbdevstudio-9.0.0.Alpha2/studio > $ rm plugins/javax.servlet_3.0.0* > $ ./jbdevstudio > And saw > !ENTRY org.jboss.tools.ws.ui 4 0 2015-04-16 10:35:49.110 > !MESSAGE FrameworkEvent ERROR > !STACK 0 > org.osgi.framework.BundleException: Could not resolve module: org.jboss.tools.ws.ui [967] > Unresolved requirement: Import-Package: javax.servlet; version="[2.4.0,3.0.0)" > at org.eclipse.osgi.container.Module.start(Module.java:434) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1561) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) > at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) > at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) > Fun thing is that the javax.servlet_3.0.0 actually exports packages in version 2.6.0, whereas javax.servlet_3.1.0 exports them in version 3.1.0. > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19330) Arquillian is missing icon in Central

by Radim Hopp (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19330?page=com.atlassian.jira.plugi... ] Radim Hopp closed JBIDE-19330. ------------------------------ Verifird in JBT 4.3.0.Alpha2. Closing. > Arquillian is missing icon in Central > ------------------------------------- > > Key: JBIDE-19330 > URL: https://issues.jboss.org/browse/JBIDE-19330 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: central, discovery > Affects Versions: 4.3.0.Alpha1 > Reporter: Radim Hopp > Assignee: Nick Boldt > Priority: Minor > Fix For: 4.3.0.Alpha2 > > > Arquillian is missing icon in JBT in Central: > http://i.imgur.com/Lwwbovy.png -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19605) Avoid need for multiple javax.servlet

by Brian Fitzpatrick (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19605?page=com.atlassian.jira.plugi... ] Brian Fitzpatrick updated JBIDE-19605: -------------------------------------- Fix Version/s: LATER > Avoid need for multiple javax.servlet > ------------------------------------- > > Key: JBIDE-19605 > URL: https://issues.jboss.org/browse/JBIDE-19605 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: target-platform, webservices > Affects Versions: 4.3.0.Alpha2 > Reporter: Mickael Istria > Assignee: Brian Fitzpatrick > Fix For: LATER > > > We currently use 2 different version of javax.servlet bundle. We'd rather decide on sticking to 1. > {code} > On 04/15/2015 11:56 PM, Nick Boldt wrote: > > Just wondering if anyone knows WHY we include javax.servlet 3.0.0 and > > 3.1.0 in JBDS. > > More importantly... SHOULD we be including both? Or can we just include > > 3.1.0 and drop 3.0.0? > I have JBDS installed from installer, which basically ran a p2 director. And I get jetty 3.0.0 and jetty 3.1.0. Than means that while resolving what to installed, p2 has to keep both versions of javax.servlet. That's definitely a sign that our dependency chain currently need both (or p2 wouldn't have installed both). > So I've tried the ultimate test: > $ cd jbdevstudio-9.0.0.Alpha2/studio > $ rm plugins/javax.servlet_3.0.0* > $ ./jbdevstudio > And saw > !ENTRY org.jboss.tools.ws.ui 4 0 2015-04-16 10:35:49.110 > !MESSAGE FrameworkEvent ERROR > !STACK 0 > org.osgi.framework.BundleException: Could not resolve module: org.jboss.tools.ws.ui [967] > Unresolved requirement: Import-Package: javax.servlet; version="[2.4.0,3.0.0)" > at org.eclipse.osgi.container.Module.start(Module.java:434) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1561) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476) > at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) > at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) > at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) > Fun thing is that the javax.servlet_3.0.0 actually exports packages in version 2.6.0, whereas javax.servlet_3.1.0 exports them in version 3.1.0. > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBDS-3404) Cannot update from JBDS 9.0.0.Alpha1 to Alpha2 (nightly)

by Pavol Srna (JIRA)

[ https://issues.jboss.org/browse/JBDS-3404?page=com.atlassian.jira.plugin.... ] Pavol Srna closed JBDS-3404. ---------------------------- Verified in JBDS alpha2a. > Cannot update from JBDS 9.0.0.Alpha1 to Alpha2 (nightly) > -------------------------------------------------------- > > Key: JBDS-3404 > URL: https://issues.jboss.org/browse/JBDS-3404 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Components: build > Affects Versions: 9.0.0.Alpha1 > Reporter: Pavol Srna > Priority: Blocker > Fix For: 9.0.0.Alpha2 > > Attachments: Screenshot 2015-04-13 14.03.50.png, Screenshot 2015-04-13 14.12.04.png, Screenshot 2015-04-16 15.36.03.png, Screenshot 2015-04-16 15.36.38.png > > > When you do Check for update, only thym update is offered: > !Screenshot 2015-04-13 14.03.50.png! > Output when you do Install/Check All > {code} > Your original request has been modified. > "Java EE Batch Configuration Tools" is already installed, so an update will be performed instead. > "JBoss JAX-RS Tools" is already installed, so an update will be performed instead. > "JBoss Maven Hibernate Configurator" is already installed, so an update will be performed instead. > "Apache Deltaspike Tools" is already installed, so an update will be performed instead. > "JBoss Developer Studio (Core Features)" is already installed, so an update will be performed instead. > "JBoss Tools Foundation" is already installed, so an update will be performed instead. > "JBoss Tools JDT Extensions" is already installed, so an update will be performed instead. > "JBoss Maven CDI Configurator" is already installed, so an update will be performed instead. > "JBoss Maven Portlet Configurator" is already installed, so an update will be performed instead. > "JBoss Tools RichFaces" is already installed, so an update will be performed instead. > "JBoss Maven Endorsed Libraries Configurator" is already installed, so an update will be performed instead. > "JBoss Tools Foundation Security for Linux" is already installed, so an update will be performed instead. > "JBoss Maven Project Examples" is already installed, so an update will be performed instead. > "JBoss Tools Java Standard Tools Tern.java Adapter" is already installed, so an update will be performed instead. > "JMX Console" is already installed, so an update will be performed instead. > "JBoss OpenShift v2 Tools" is already installed, so an update will be performed instead. > "JBoss Tools JSF" is already installed, so an update will be performed instead. > "Seam Tools" is already installed, so an update will be performed instead. > "Hybrid Mobile Application Development Tools" is already installed, so an update will be performed instead. > "JBoss Archives Tools" is already installed, so an update will be performed instead. > "JBoss Stacks Tools" is already installed, so an update will be performed instead. > "JBoss Tools Java Standard Tools" is already installed, so an update will be performed instead. > "JBoss Tools Visual Page Editor" is already installed, so an update will be performed instead. > "Project Examples" is already installed, so an update will be performed instead. > "JBoss Maven Integration" is already installed, so an update will be performed instead. > "JBoss Runtime Detection Core" is already installed, so an update will be performed instead. > "JBoss Tools Apache Tomcat Integration" is already installed, so an update will be performed instead. > "JBoss WebServices Tools" is already installed, so an update will be performed instead. > "Hibernate Tools" is already installed, so an update will be performed instead. > "JBoss Tools LiveReload" is already installed, so an update will be performed instead. > "JBoss Tools Eclipse Thym Integration" is already installed, so an update will be performed instead. > "JBoss Tools EGit Integration" is already installed, so an update will be performed instead. > "JBoss Tools Maven Source Lookup" is already installed, so an update will be performed instead. > "Forge Tools" is already installed, so an update will be performed instead. > "Context and Dependency Injection Tools" is already installed, so an update will be performed instead. > "JBossAS Tools" is already installed, so an update will be performed instead. > Cannot complete the install because of a conflicting dependency. > Software being installed: JBoss Tools Java Standard Tools Tern.java Adapter 3.7.0.Alpha2-v20150322-0547-B822 (org.jboss.tools.jst.jsdt.feature.feature.group 3.7.0.Alpha2-v20150322-0547-B822) > Software currently installed: JBoss Tools Java Standard Tools AngularJS 3.7.0.Alpha1-v20150213-0215-B3 (org.jboss.tools.jst.angularjs.feature.feature.group 3.7.0.Alpha1-v20150213-0215-B3) > Only one of the following can be installed at once: > JBoss Tools Java Standard Tools - Tern Project Adapter 3.7.0.Alpha2-v20150322-0547-B822 (org.jboss.tools.jst.jsdt 3.7.0.Alpha2-v20150322-0547-B822) > JBoss Tools Java Standard Tools - Tern Project Adapter 3.7.0.Alpha1-v20150213-0215-B3 (org.jboss.tools.jst.jsdt 3.7.0.Alpha1-v20150213-0215-B3) > Cannot satisfy dependency: > From: JBoss Tools Java Standard Tools AngularJS 3.7.0.Alpha1-v20150213-0215-B3 (org.jboss.tools.jst.angularjs.feature.feature.group 3.7.0.Alpha1-v20150213-0215-B3) > To: org.jboss.tools.jst.jsdt.feature.feature.group [3.7.0.Alpha1-v20150213-0215-B3] > Cannot satisfy dependency: > From: JBoss Tools Java Standard Tools Tern.java Adapter 3.7.0.Alpha1-v20150213-0215-B3 (org.jboss.tools.jst.jsdt.feature.feature.group 3.7.0.Alpha1-v20150213-0215-B3) > To: org.jboss.tools.jst.jsdt [3.7.0.Alpha1-v20150213-0215-B3] > Cannot satisfy dependency: > From: JBoss Tools Java Standard Tools Tern.java Adapter 3.7.0.Alpha2-v20150322-0547-B822 (org.jboss.tools.jst.jsdt.feature.feature.group 3.7.0.Alpha2-v20150322-0547-B822) > To: org.jboss.tools.jst.jsdt [3.7.0.Alpha2-v20150322-0547-B822] > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19707) Remove direct use of the core Hibernate classes and/or Hibernate Proxy classes

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19707?page=com.atlassian.jira.plugi... ] Koen Aers updated JBIDE-19707: ------------------------------ Component/s: birt > Remove direct use of the core Hibernate classes and/or Hibernate Proxy classes > ------------------------------------------------------------------------------ > > Key: JBIDE-19707 > URL: https://issues.jboss.org/browse/JBIDE-19707 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: birt, seam2 > Affects Versions: 4.3.0.Alpha2 > Reporter: Koen Aers > Assignee: Koen Aers > > These uses should ideally be replaced by uses of the Hibernate SPI interfaces. It may be needed to create new SPI interfaces. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19707) Remove direct use of the core Hibernate classes and/or Hibernate Proxy classes

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19707?page=com.atlassian.jira.plugi... ] Koen Aers updated JBIDE-19707: ------------------------------ Component/s: hibernate > Remove direct use of the core Hibernate classes and/or Hibernate Proxy classes > ------------------------------------------------------------------------------ > > Key: JBIDE-19707 > URL: https://issues.jboss.org/browse/JBIDE-19707 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: birt, hibernate, seam2 > Affects Versions: 4.3.0.Alpha2 > Reporter: Koen Aers > Assignee: Koen Aers > > These uses should ideally be replaced by uses of the Hibernate SPI interfaces. It may be needed to create new SPI interfaces. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19707) Remove direct use of the core Hibernate classes and/or Hibernate Proxy classes

by Koen Aers (JIRA)

Koen Aers created JBIDE-19707: --------------------------------- Summary: Remove direct use of the core Hibernate classes and/or Hibernate Proxy classes Key: JBIDE-19707 URL: https://issues.jboss.org/browse/JBIDE-19707 Project: Tools (JBoss Tools) Issue Type: Task Components: seam2 Affects Versions: 4.3.0.Alpha2 Reporter: Koen Aers These uses should ideally be replaced by uses of the Hibernate SPI interfaces. It may be needed to create new SPI interfaces. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19707) Remove direct use of the core Hibernate classes and/or Hibernate Proxy classes

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19707?page=com.atlassian.jira.plugi... ] Koen Aers reassigned JBIDE-19707: --------------------------------- Assignee: Koen Aers > Remove direct use of the core Hibernate classes and/or Hibernate Proxy classes > ------------------------------------------------------------------------------ > > Key: JBIDE-19707 > URL: https://issues.jboss.org/browse/JBIDE-19707 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: seam2 > Affects Versions: 4.3.0.Alpha2 > Reporter: Koen Aers > Assignee: Koen Aers > > These uses should ideally be replaced by uses of the Hibernate SPI interfaces. It may be needed to create new SPI interfaces. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19706) Refactor the hibernate service provider implementations

by Koen Aers (JIRA)

Koen Aers created JBIDE-19706: --------------------------------- Summary: Refactor the hibernate service provider implementations Key: JBIDE-19706 URL: https://issues.jboss.org/browse/JBIDE-19706 Project: Tools (JBoss Tools) Issue Type: Task Components: hibernate Affects Versions: 4.3.0.Alpha2 Reporter: Koen Aers The SPI implementation "proxy" classes need a common superclass that can implement most of the functionality using introspection. In this way probably 70% of the code can be eliminated. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-19706) Refactor the hibernate service provider implementations

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19706?page=com.atlassian.jira.plugi... ] Koen Aers reassigned JBIDE-19706: --------------------------------- Assignee: Koen Aers > Refactor the hibernate service provider implementations > -------------------------------------------------------- > > Key: JBIDE-19706 > URL: https://issues.jboss.org/browse/JBIDE-19706 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: hibernate > Affects Versions: 4.3.0.Alpha2 > Reporter: Koen Aers > Assignee: Koen Aers > > The SPI implementation "proxy" classes need a common superclass that can implement most of the functionality using introspection. In this way probably 70% of the code can be eliminated. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-18558) Improve usability of up-to-date Central items

by Radim Hopp (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18558?page=com.atlassian.jira.plugi... ] Radim Hopp closed JBIDE-18558. ------------------------------ When all selected connectors are installed and up to date, shell saying that everything is up to data is shown. Verified in JBDS 9.0.0.Alpha2. Closing. > Improve usability of up-to-date Central items > --------------------------------------------- > > Key: JBIDE-18558 > URL: https://issues.jboss.org/browse/JBIDE-18558 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: central > Reporter: Max Rydahl Andersen > Assignee: Mickael Istria > Priority: Minor > Fix For: 4.3.0.Alpha2 > > > Install hybrid tools. > restart eclipse. > enable show installed, click hybrid tools. > Install/update is greyed out. > why can I not run update ? -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-18948) Include new jbosstools-javaee/batch component into aggregated update site

by Martin Malina (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18948?page=com.atlassian.jira.plugi... ] Martin Malina closed JBIDE-18948. --------------------------------- I assume this was checked by Alexey. But I just checked now that the batch feature is included in both JBoss Tools 4.3.0.Alpha2 and JBDS 9.0.0.Alpha2 update sites, also it is installed in my installation of JBDS 9.0.0.Alpha2 BYOE. So I consider this done. Closing. > Include new jbosstools-javaee/batch component into aggregated update site > ------------------------------------------------------------------------- > > Key: JBIDE-18948 > URL: https://issues.jboss.org/browse/JBIDE-18948 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: build > Reporter: Alexey Kazakov > Assignee: Alexey Kazakov > Priority: Critical > Fix For: 4.3.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

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 April 2015