[JBoss JIRA] (JBDS-3319) JBDS 8.0.2 EAP installer displays incorrect storage requirements to user
by Len DiMaggio (JIRA)
Len DiMaggio created JBDS-3319:
----------------------------------
Summary: JBDS 8.0.2 EAP installer displays incorrect storage requirements to user
Key: JBDS-3319
URL: https://issues.jboss.org/browse/JBDS-3319
Project: Developer Studio (JBoss Developer Studio)
Issue Type: Bug
Components: installer
Affects Versions: 8.0.2.GA
Reporter: Len DiMaggio
Assignee: Nick Boldt
The (eap embedded) installer for JBDS 8.0.2 informs the user that this much disk space is required:
Disk Space:
Available Disk Space: 31.64 GB Required Disk Space: 585.78 MB
The actual install uses this much:
du -sh installdir/
822M installdir/
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBIDE-18915) Create Icons for Batch tools
by Daniel Azarov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18915?page=com.atlassian.jira.plugi... ]
Daniel Azarov updated JBIDE-18915:
----------------------------------
Description:
batch_icon16.png - file batch.xml (initial image is attached, it can be replaced or used)
* *analyzer.png* - receives intermediary results from each partition sent via partition collector and serves as a collection point for this data; it may be used to implement custom exit status handling for the step
* *batchlet.png* - 'batchlet' element specifies a task-oriented batch step
* *checkpoint-algorithm.png* - an optional custom checkpoint algorithm that may be used to provide a checkpoint decision based on factors other than only number of items, or amount of time
* *chunk.png* - kind of step that processes multiple items and is periodically checkpointed by the batch runtime according to a configured checkpoint policy
* *collector.png* - partition collector is used by step partitions for sharing data that is used to decide the overall outcome of the step
* *decision.png* - decision provides a customized way of determining sequencing among steps, flows, and splits (batch status is set to FAILED)
* *end.png* - end element is used to terminate the job at the current step (batch status is set to COMPLETED)
* *exclude.png* - element 'exclude' specifies a class name of an exception or exception superclass to not be taken into account
* *fail.png* - fail element is used to terminate the job at the conclusion of the current step or flow
* *flow.png* - flow defines a sequence of execution elements that execute together as a unit
* *include.png* - element 'include' specifies the class name of an exception or exception superclass that should be taken into account
* *job.png* - root node of file batch.xml, it may be the same as batch_icon16.png
* *listeners.png* - folder for listeners
* *listener.png* - job listener
* *mapper.png* - partition mapper provides a programmatic means for calculating the number of partitions and threads for a partitioned step
* *next.png* - transition element that defines condition and target for transition to next step.
* *partition.png* - 'partition' element specifies that a step is a partitioned step
* *plan.png* - plan defines the number of partitions and the maximum number of threads on which to execute the partitions of the partitioned step
* *processor.png* - 'processor' element specifies the item processor for a chunk step
* *properties.png* - folder for properties
* *property.png* - common 'name'='value' object.
* *reader.png* - 'reader' element specifies the item reader for a chunk step
* *reducer.png* - partition reducer provides a kind of unit of work demarcation around the processing of the partitions
* *no-rollback-exception-classes.png* - list of exceptions that override the default behavior of rollback for retryable exceptions
* *retryable-exception-classes.png* - set of exceptions that chunk processing will retry
* *skippable-exception-classes.png* - set of exceptions that chunk processing will skip
* *split.png* - split defines a set of flows that execute concurrently
* *step.png* - 'step' element identifies a job step, job may contain any number of steps
* *stop.png* - stop element is used to terminate the job after the current step or flow (batch status is set to STOPPED), optionally defines step at which job can be restarted
* *writer.png* - 'writer' element specifies the item writer for a chunk step
was:
batch_icon16.png - file batch.xml (initial image is attached, it can be replaced or used)
* *analyzer.png* - receives intermediary results from each partition sent via partition collector and serves as a collection point for this data; it may be used to implement custom exit status handling for the step
* *batchlet.png* - 'batchlet' element specifies a task-oriented batch step
checkpoint-algorithm.png - an optional custom checkpoint algorithm that may be used to provide a checkpoint decision based on factors other than only number of items, or amount of time
* *chunk.png* - kind of step that processes multiple items and is periodically checkpointed by the batch runtime according to a configured checkpoint policy
* *collector.png* - partition collector is used by step partitions for sharing data that is used to decide the overall outcome of the step
* *decision.png* - decision provides a customized way of determining sequencing among steps, flows, and splits (batch status is set to FAILED)
* *end.png* - end element is used to terminate the job at the current step (batch status is set to COMPLETED)
* *exclude.png* - element 'exclude' specifies a class name of an exception or exception superclass to not be taken into account
* *fail.png* - fail element is used to terminate the job at the conclusion of the current step or flow
* *flow.png* - flow defines a sequence of execution elements that execute together as a unit
* *include.png* - element 'include' specifies the class name of an exception or exception superclass that should be taken into account
* *job.png* - root node of file batch.xml, it may be the same as batch_icon16.png
* *listeners.png* - folder for listeners
* *listener.png* - job listener
* *mapper.png* - partition mapper provides a programmatic means for calculating the number of partitions and threads for a partitioned step
* *next.png* - transition element that defines condition and target for transition to next step.
* *partition.png* - 'partition' element specifies that a step is a partitioned step
* *plan.png* - plan defines the number of partitions and the maximum number of threads on which to execute the partitions of the partitioned step
* *processor.png* - 'processor' element specifies the item processor for a chunk step
* *properties.png* - folder for properties
* *property.png* - common 'name'='value' object.
* *reader.png* - 'reader' element specifies the item reader for a chunk step
* *reducer.png* - partition reducer provides a kind of unit of work demarcation around the processing of the partitions
* *no-rollback-exception-classes.png* - list of exceptions that override the default behavior of rollback for retryable exceptions
* *retryable-exception-classes.png* - set of exceptions that chunk processing will retry
* *skippable-exception-classes.png* - set of exceptions that chunk processing will skip
* *split.png* - split defines a set of flows that execute concurrently
* *step.png* - 'step' element identifies a job step, job may contain any number of steps
* *stop.png* - stop element is used to terminate the job after the current step or flow (batch status is set to STOPPED), optionally defines step at which job can be restarted
* *writer.png* - 'writer' element specifies the item writer for a chunk step
> Create Icons for Batch tools
> ----------------------------
>
> Key: JBIDE-18915
> URL: https://issues.jboss.org/browse/JBIDE-18915
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: batch
> Reporter: Viacheslav Kabanovich
> Assignee: Daniel Azarov
> Fix For: 4.3.0.Alpha1
>
> Attachments: batch_editor_icon.png, batch_icon16.png, batch_node_icon.png
>
>
> batch_icon16.png - file batch.xml (initial image is attached, it can be replaced or used)
> * *analyzer.png* - receives intermediary results from each partition sent via partition collector and serves as a collection point for this data; it may be used to implement custom exit status handling for the step
> * *batchlet.png* - 'batchlet' element specifies a task-oriented batch step
> * *checkpoint-algorithm.png* - an optional custom checkpoint algorithm that may be used to provide a checkpoint decision based on factors other than only number of items, or amount of time
> * *chunk.png* - kind of step that processes multiple items and is periodically checkpointed by the batch runtime according to a configured checkpoint policy
> * *collector.png* - partition collector is used by step partitions for sharing data that is used to decide the overall outcome of the step
> * *decision.png* - decision provides a customized way of determining sequencing among steps, flows, and splits (batch status is set to FAILED)
> * *end.png* - end element is used to terminate the job at the current step (batch status is set to COMPLETED)
> * *exclude.png* - element 'exclude' specifies a class name of an exception or exception superclass to not be taken into account
> * *fail.png* - fail element is used to terminate the job at the conclusion of the current step or flow
> * *flow.png* - flow defines a sequence of execution elements that execute together as a unit
> * *include.png* - element 'include' specifies the class name of an exception or exception superclass that should be taken into account
> * *job.png* - root node of file batch.xml, it may be the same as batch_icon16.png
> * *listeners.png* - folder for listeners
> * *listener.png* - job listener
> * *mapper.png* - partition mapper provides a programmatic means for calculating the number of partitions and threads for a partitioned step
> * *next.png* - transition element that defines condition and target for transition to next step.
> * *partition.png* - 'partition' element specifies that a step is a partitioned step
> * *plan.png* - plan defines the number of partitions and the maximum number of threads on which to execute the partitions of the partitioned step
> * *processor.png* - 'processor' element specifies the item processor for a chunk step
> * *properties.png* - folder for properties
> * *property.png* - common 'name'='value' object.
> * *reader.png* - 'reader' element specifies the item reader for a chunk step
> * *reducer.png* - partition reducer provides a kind of unit of work demarcation around the processing of the partitions
> * *no-rollback-exception-classes.png* - list of exceptions that override the default behavior of rollback for retryable exceptions
> * *retryable-exception-classes.png* - set of exceptions that chunk processing will retry
> * *skippable-exception-classes.png* - set of exceptions that chunk processing will skip
> * *split.png* - split defines a set of flows that execute concurrently
> * *step.png* - 'step' element identifies a job step, job may contain any number of steps
> * *stop.png* - stop element is used to terminate the job after the current step or flow (batch status is set to STOPPED), optionally defines step at which job can be restarted
> * *writer.png* - 'writer' element specifies the item writer for a chunk step
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBDS-3285) Git: Easy Import
by Len DiMaggio (JIRA)
[ https://issues.jboss.org/browse/JBDS-3285?page=com.atlassian.jira.plugin.... ]
Len DiMaggio updated JBDS-3285:
-------------------------------
Component/s: requirements
> Git: Easy Import
> ----------------
>
> Key: JBDS-3285
> URL: https://issues.jboss.org/browse/JBDS-3285
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: requirements, upstream
> Affects Versions: 8.0.0.GA
> Reporter: Burr Sutter
> Assignee: Burr Sutter
> Labels: usability
> Fix For: 9.0.x
>
>
> As a Java EE developer, in some cases using Git for the first time (or only familiar with command line git), I find it very difficult to clone and import a project correctly into JBDS, having the appropriate facets configured, if it has a maven pom.xml, correctly setting the build path, where it is easily deployable to a localhost EAP instance.
> The mission here is to make the Git experience much more user friendly.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBDS-3285) Git: Easy Import
by Len DiMaggio (JIRA)
[ https://issues.jboss.org/browse/JBDS-3285?page=com.atlassian.jira.plugin.... ]
Len DiMaggio updated JBDS-3285:
-------------------------------
Labels: usability (was: requirements usability)
> Git: Easy Import
> ----------------
>
> Key: JBDS-3285
> URL: https://issues.jboss.org/browse/JBDS-3285
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: requirements, upstream
> Affects Versions: 8.0.0.GA
> Reporter: Burr Sutter
> Assignee: Burr Sutter
> Labels: usability
> Fix For: 9.0.x
>
>
> As a Java EE developer, in some cases using Git for the first time (or only familiar with command line git), I find it very difficult to clone and import a project correctly into JBDS, having the appropriate facets configured, if it has a maven pom.xml, correctly setting the build path, where it is easily deployable to a localhost EAP instance.
> The mission here is to make the Git experience much more user friendly.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBDS-3210) create a JBDS Central feature which includes only JBDS Central branding plugin
by Len DiMaggio (JIRA)
[ https://issues.jboss.org/browse/JBDS-3210?page=com.atlassian.jira.plugin.... ]
Len DiMaggio updated JBDS-3210:
-------------------------------
Component/s: requirements
> create a JBDS Central feature which includes only JBDS Central branding plugin
> ------------------------------------------------------------------------------
>
> Key: JBDS-3210
> URL: https://issues.jboss.org/browse/JBDS-3210
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: central, requirements
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 9.0.0.Alpha1
>
>
> Purpose:
> Provide a single feature which includes both JBoss Central (pulled from JBoss Tools, minus its "community" plugin, org.jboss.tools.community.central) and the JBDS Central branding plugin, com.jboss.devstudio.core.central.
> Reason:
> This will allow us to create Marketplace installs for things like JBDS Fuse Tooling which include ONLY the Fuse features + the bare bones of Central, without having all of JBDS come along for the ride. Without this, we can create a JBoss Tools-branded Fuse entry in the Marketplace, or a JBDS-branded Fuse entry in the Marketplace [which includes all of JBDS]. We want a JBDS-branded Fuse entry, which only includes the bare bones, not ALL the JBDS stuff.
> Technical problems:
> * Marketplace can only install features, not individual plugins
> * Today, the only way to install JBDS Central via Marketplace is to include the com.jboss.devstudio.core.feature, which includes the com.jboss.devstudio.core.central branding plugin. But doing so installs ALL of JBDS, too.
> Solution:
> 1. Create a com.jboss.devstudio.core.central.feature which includes:
> * com.jboss.devstudio.core.central
> * org.jboss.tools.central
> 2. Optionally, could also include these plugins:
> * com.jboss.devstudio.core.project.examples
> * com.jboss.devstudio.core.usage.branding
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBDS-3258) Docker Tooling (Advanced Integration)
by Len DiMaggio (JIRA)
[ https://issues.jboss.org/browse/JBDS-3258?page=com.atlassian.jira.plugin.... ]
Len DiMaggio updated JBDS-3258:
-------------------------------
Component/s: requirements
> 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: openshift, 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.11#6341)
11 years, 3 months
[JBoss JIRA] (JBDS-3256) JBoss specific Docker Tooling (Basic Integration)
by Len DiMaggio (JIRA)
[ https://issues.jboss.org/browse/JBDS-3256?page=com.atlassian.jira.plugin.... ]
Len DiMaggio updated JBDS-3256:
-------------------------------
Component/s: requirements
> JBoss specific Docker Tooling (Basic Integration)
> -------------------------------------------------
>
> Key: JBDS-3256
> URL: https://issues.jboss.org/browse/JBDS-3256
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: openshift, requirements
> Reporter: Burr Sutter
> Assignee: Xavier Coulon
>
> Goal: to allow the Eclipse user to easily discover, pull, run, deploy my .war or .ear to it, stop, commit, push for docker images/containers.
> Expected end-user flow 1:
> 0) Installation - assumes boot2docker pre-installed on the end-user's machine
> 1) I, the Java developer, need to browse a docker registry (either DockerHub or private registry), identify the image that I wish to have local and download (docker pull) for that image+tag.
> 2) Assumption: the docker image includes not only the operating system + JVM but also the EAP, Wildfly or Tomcat installed in a 'known' location.
> 3) I start (docker run) the image which auto-starts the embedded app server
> 4) I can then deploy my .war or .ear to the running app server
> 5) I can restart the running app server in debug mode and run the debugger
> 6) I can undeploy and redeploy my .war or .ear
> 7) I can stop/restart the running, embedded app server
> 8) I can then commit (docker commit)
> 9) then I can publish my changes (docker push)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months