[JBoss JIRA] (JBDS-3258) Docker Tooling (Advanced Integration)
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3258?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen updated JBDS-3258:
--------------------------------------
Component/s: docker
(was: openshift)
> Docker Tooling (Advanced Integration)
> -------------------------------------
>
> Key: JBDS-3258
> URL: https://issues.jboss.org/browse/JBDS-3258
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: docker, requirements
> Reporter: Burr Sutter
> Assignee: Xavier Coulon
>
> Once significant delta between the "basic" and advanced scenarios is that here I wish to custom craft my own docker images instead of using an existing one - where my custom crafted image includes my .war or .ear.
> In addition to the basic integrations of pull, run, stop, commit and push
> boot2docker init
> boot2docker up
> boot2docker down
> boot2docker ip
> docker run -d
> docker ps
> docker rm
> docker rmi
> docker build
> End-user steps:
> 0) assumes boot2docker has been dowloaded and installed
> 1) boot2docker init : required to to insure boot2docker-vm is properly initialized
> 2) boot2docker up : starts the VirtualBox boot2docker-vm
> 3) boot2docker ip : returns the IP address - this will be vital when it comes to testing - it would need to be integrated with our Run - As on Docker capability.
> 4) docker run -i -t -p 80:8080 jboss/wildfly -d : the -d means detached, I may need to run N containers simultaneously
> 5) docker ps : allows me to see all my currently running containers
> 6) docker rm : allows me to kill a currently running container
> 7) docker rmi : allows me to remove a local image
> 8) docker build : assumes that I have crafted a Dockerfile - this will create the local image - with my .war or .ear embedded
> 9) docker run : this new created image
> The docker build scenario can be triggered via a Maven plugin
> The docker build scenario can also be triggered via an Eclipse menu option (like a Maven install)
> We need to figure out the file-system layout so that the Dockerfile and the maven project are all nicely checked into git/svn. So that Jenkins can pick up this repository and perform an automated "docker build" (post Maven install) and then run all the appropriate unit, integration and functional tests.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-19467) repository-utils :: FetchSourcesFromManifests should create its own source zip, not rely on publish.sh
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19467?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen updated JBIDE-19467:
----------------------------------------
Priority: Blocker (was: Major)
> 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
> Priority: Blocker
> Fix For: 4.3.0.Beta1
>
>
> In repository-utils, FetchSourcesFromManifests should create its own source zip, not rely on publish.sh. Because we no longer use publish.sh and don't want to have rsync.sh produce artifacts, only rsync them.
> Here's what publish.sh does:
> {code}
> # collect component zips from upstream aggregated build jobs
> if [[ ${JOB_NAME/.aggregate} != ${JOB_NAME} ]] && [[ -d ${WORKSPACE}/sources/aggregate/site/zips ]]; then
> mkdir -p ${STAGINGDIR}/components
> for z in $(find ${WORKSPACE}/sources/aggregate/site/zips -name "*updatesite-*.zip"); do
> # generate MD5 sum for zip (file contains only the hash, not the hash + filename)
> for m in $(md5sum ${z}); do if [[ $m != ${z} ]]; then echo $m > ${z}.MD5; fi; done
> mv $z ${z}.MD5 ${STAGINGDIR}/components
> done
> # TODO :: JBIDE-9870 When we have a -Update-Sources- zip, this can be removed
> mkdir -p ${STAGINGDIR}/all/sources
> # OLD: unpack component source zips like jbosstools-pi4soa-3.1_trunk-Sources-SNAPSHOT.zip or jbosstools-3.2_trunk.component--ws-Sources-SNAPSHOT.zip
> # NEW: JBIDE-16632: unpack component source zips like jbosstools-base_Alpha2-v20140221-1555-B437_184e18cc3ac7c339ce406974b6a4917f73909cc4_sources.zip
> for z in $(find ${WORKSPACE}/sources/aggregate/site/zips -name "*Sources*.zip" -o -name "*_sources.zip" -o -name "*-src.zip"); do
> zn=${z%*-Sources*.zip}; zn=${zn%*_sources.zip}; zn=${zn%*-src.zip}; zn=${zn#*--}; zn=${zn##*/}; zn=${zn#jbosstools-};
> # zn=${zn%_trunk}; zn=${zn%_stable_branch};
> mkdir -p ${STAGINGDIR}/all/sources/${zn}/
> # remove one level of folder nesting - don't want an extra jbosstools-base-184e18cc3ac7c339ce406974b6a4917f73909cc4 folder under jbosstools-base_Alpha2-v20140221-1555-B437_184e18cc3ac7c339ce406974b6a4917f73909cc4
> unzip -qq -o -d ${tmpdir}/${zn}/ $z
> mkdir -p ${STAGINGDIR}/all/sources/${zn}/
> mv ${tmpdir}/${zn}/jbosstools-*/* ${STAGINGDIR}/all/sources/${zn}/
> rm -fr ${tmpdir}/${zn}/
> done
> # add component sources into sources zip
> pushd ${STAGINGDIR}/all/sources
> zip ${STAGINGDIR}/all/${SRCSNAME} -q -r * -x hudson_workspace\* -x documentation\* -x download.jboss.org\* -x requirements\* \
> -x workingset\* -x labs\* -x build\* -x \*test\* -x \*target\* -x \*.class -x \*classes\* -x \*bin\* -x \*.zip \
> -x \*docs\* -x \*reference\* -x \*releng\* -x \*.git\* -x \*/lib/\*.jar -x \*getRemoteFile\*
> popd
> rm -fr ${STAGINGDIR}/all/sources
> z=${STAGINGDIR}/all/${SRCSNAME}; for m in $(md5sum ${z}); do if [[ $m != ${z} ]]; then echo $m > ${z}.MD5; fi; done
> # JBIDE-7444 get aggregate metadata xml properties file
> if [[ -f ${WORKSPACE}/sources/aggregate/site/zips/build.properties.all.xml ]]; then
> rsync -aq ${WORKSPACE}/sources/aggregate/site/zips/build.properties.all.xml ${STAGINGDIR}/logs/
> fi
> fi
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBDS-3425) Disable Unintsaller generation for Mac OS X
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBDS-3425?page=com.atlassian.jira.plugin.... ]
Martin Malina commented on JBDS-3425:
-------------------------------------
I have one worry here.
If we change the runtimes location to ~/Library/Application Support/jbdevstudio9/runtimes as was suggested in JBDS-3411, then having an uninstaller would actually be helpful, because just removing the app will leave the installed runtime on the disk (if one installs the installer with eap).
> Disable Unintsaller generation for Mac OS X
> -------------------------------------------
>
> Key: JBDS-3425
> URL: https://issues.jboss.org/browse/JBDS-3425
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: installer
> Affects Versions: 9.0.0.Alpha2
> Reporter: Denis Golovin
> Assignee: Denis Golovin
> Fix For: 9.0.0.Beta1
>
>
> Uninstaller doesn't make sense for Mac platform, because it is literally just removing .app package.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBDS-1234) Installer could check OS architecture
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBDS-1234?page=com.atlassian.jira.plugin.... ]
Mickael Istria commented on JBDS-1234:
--------------------------------------
In "it is supported by IzPack", what is "it" ?
Is it something that will improve user experience or developer productivity?
> Installer could check OS architecture
> -------------------------------------
>
> Key: JBDS-1234
> URL: https://issues.jboss.org/browse/JBDS-1234
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: installer
> Affects Versions: 3.0.1.GA
> Reporter: Jiri Peterka
> Assignee: Denis Golovin
> Fix For: 9.0.0.Beta2
>
>
> Installer could check OS architecture, for example if installing 32-bit package on 64 bit OS there should be a warning and non-compatible package should be forced to exit installation.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBDS-1234) Installer could check OS architecture
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-1234?page=com.atlassian.jira.plugin.... ]
Denis Golovin commented on JBDS-1234:
-------------------------------------
It is supported by IzPack, so we at least can add Linux/Mac/Windows platforms right away, arch support is not that clear, but I can figure it out :)
> Installer could check OS architecture
> -------------------------------------
>
> Key: JBDS-1234
> URL: https://issues.jboss.org/browse/JBDS-1234
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: installer
> Affects Versions: 3.0.1.GA
> Reporter: Jiri Peterka
> Assignee: Denis Golovin
> Fix For: 9.0.0.Beta2
>
>
> Installer could check OS architecture, for example if installing 32-bit package on 64 bit OS there should be a warning and non-compatible package should be forced to exit installation.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBTIS-416) Need to doc split of SOA Development between release and early access
by Misha Ali (JIRA)
[ https://issues.jboss.org/browse/JBTIS-416?page=com.atlassian.jira.plugin.... ]
Misha Ali commented on JBTIS-416:
---------------------------------
Thanks, Paul and Andrej. This is now pushed public and available here: https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Developer_Stu...
If this is all that was required for this particular JIRA, we can probably close it, unless we need to change/remove this content in one of the upcoming releases?
> Need to doc split of SOA Development between release and early access
> ---------------------------------------------------------------------
>
> Key: JBTIS-416
> URL: https://issues.jboss.org/browse/JBTIS-416
> Project: JBoss Tools Integration Stack
> Issue Type: Task
> Components: distribution
> Affects Versions: 8.0.1.GA, 4.2.1.Final
> Reporter: Paul Leacu
> Assignee: Misha Ali
> Attachments: ss0.png, ss1.png
>
>
> Component categorization for the SOA Development tooling falls in both the released and Early Access update sites. B*MS tooling is now being productized and Fuse Tooling/ SwitchYard are in 'Early Access'. This situation is temporary (until Fuse Tooling/SwitchYard are GA).
> To address this issue I've done the following:
> JBDSIS 8.0.1.GA:
> site-ga: (released)
> JBoss Business Process and Rules Development
> *All features available
> JBoss Data Virtualization Development
> *All features available
> JBoss Integration and SOA Development
> *All features except Fuse Tooling and SwitchYard
> JBoss SOA 5.x Development
> *All features available
>
> site-ea: (early access)
> JBoss Fuse Development
> *All features available
> JBoss Integration and SOA Development
> *Fuse Tooling and SwitchYard only available
> To simplify the user experience, Early Access will contain only features which are early access. Released (production) features will appear in the primary update window.
> The community JBTIS install will do something similar.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months