[JBoss JIRA] (JBDS-3286) Remove Seam tooling from default JBDS installation
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-3286?page=com.atlassian.jira.plugin.... ]
Nick Boldt commented on JBDS-3286:
----------------------------------
OK, I've replaced PR 250 with 252, which only removes the features from the JBDS core.feature, but does nothing to hide them on the update site.
> Remove Seam tooling from default JBDS installation
> --------------------------------------------------
>
> Key: JBDS-3286
> URL: https://issues.jboss.org/browse/JBDS-3286
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: central, installer, seam
> Affects Versions: 9.0.0.Alpha1
> Reporter: Fred Bricon
> Assignee: Nick Boldt
> Fix For: 9.0.0.Alpha1
>
>
> With Seam being pretty much dead and the tools in maintenance mode, I'm opening this issue to discuss whether we should drop Seam from the JBDS installer and only keep it available from JBoss Central (required as part of JBIDE-18922 already).
> [~burrsutter], [~maxandersen], [~ldimaggio], [~akazakov], [~mmurray] : WDYT?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JBIDE-18857) Java EE 7 Batch support
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18857?page=com.atlassian.jira.plugi... ]
Alexey Kazakov commented on JBIDE-18857:
----------------------------------------
If we want to contribute batch to WTP we can't reuse a lot of our code:
- Field editors for wizards
- Our content assist
- validation
- some core code for scanning/building model (which we reuse in cdi and jsf for example)
...
It means we would need much more time for re-implementing this common staff or trying to prepare to contribute it to WTP to (which is not so easy).
> Java EE 7 Batch support
> -----------------------
>
> Key: JBIDE-18857
> URL: https://issues.jboss.org/browse/JBIDE-18857
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: batch
> Reporter: Alexey Kazakov
> Assignee: Alexey Kazakov
> Labels: new_and_noteworthy
> Fix For: 4.3.x
>
>
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JBIDE-18857) Java EE 7 Batch support
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18857?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich commented on JBIDE-18857:
-----------------------------------------------
Yes, if we cannot contribute kb model.
Then, if we have to implement Batch support as a possible contribution to eclipse WTP, how much can we reuse from our plugins?
I am most concerned with org.jboss.tools.common.ui which has very efficient field editors that make creating our wizards a piece of cake.
> Java EE 7 Batch support
> -----------------------
>
> Key: JBIDE-18857
> URL: https://issues.jboss.org/browse/JBIDE-18857
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: batch
> Reporter: Alexey Kazakov
> Assignee: Alexey Kazakov
> Labels: new_and_noteworthy
> Fix For: 4.3.x
>
>
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JBDS-3256) JBoss specific Docker Tooling (Basic Integration)
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3256?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen updated JBDS-3256:
--------------------------------------
Summary: JBoss specific Docker Tooling (Basic Integration) (was: Docker Tooling (Basic Integration))
> 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
> Reporter: Burr Sutter
> Assignee: Andre Dietisheim
>
> 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, 4 months
[JBoss JIRA] (JBDS-3256) Docker Tooling (Basic Integration)
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3256?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-3256:
-------------------------------------------
This is not what I consider basic docker tooling - this is appserver *specific* integration which for being possible needs to have someone produce these docker images. [~burrsutter] are you expecting the tools team products these ?
btw. we can do *all* of the above as long as the server inside the docker image is a standard jboss server and SSH is open to execute commands - so need to be more specific on what is expected here besides that.
For me basic docker features are those that just work with docker and does not assume any specifics about what is inside the docker image.
That means browsing images, run them and connect to them via terminal.
> 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
> Reporter: Burr Sutter
> Assignee: Andre Dietisheim
>
> 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, 4 months
[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: [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.
was:
There are about 20 artefacts 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 artefacts. However, there is so much common in them that it makes sense also (or instead) to have one wizard with list choice of artefact. When a specific artefact should be created from the context of Batch XML editor, this wizard can be invoked with selection of that artefact (list of artefacts may be disabled or hidden).
1. Artefact 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 artefact. 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. Artefact class may declare fields, with values to be injected from properties set in job xml element referencing that artefact:
{code}
@Inject @BatchProperty(name="property1") String property;
@Inject @BatchProperty String property2;
{code}
Thus, the wizard will have inputs as follows:
- Artefact: [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: Sub-task
> Components: batch
> Affects Versions: 4.3.0.Alpha1
> Reporter: Viacheslav Kabanovich
> Assignee: Viacheslav Kabanovich
> Labels: new_and_noteworthy
> Fix For: 4.3.0.Alpha1
>
>
> 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.11#6341)
11 years, 4 months
[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:
------------------------------------------
Summary: New Batch Artifact wizard (was: New Batch Artefact wizard)
> New Batch Artifact wizard
> -------------------------
>
> Key: JBIDE-18950
> URL: https://issues.jboss.org/browse/JBIDE-18950
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: batch
> Affects Versions: 4.3.0.Alpha1
> Reporter: Viacheslav Kabanovich
> Assignee: Viacheslav Kabanovich
> Labels: new_and_noteworthy
> Fix For: 4.3.0.Alpha1
>
>
> There are about 20 artefacts 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 artefacts. However, there is so much common in them that it makes sense also (or instead) to have one wizard with list choice of artefact. When a specific artefact should be created from the context of Batch XML editor, this wizard can be invoked with selection of that artefact (list of artefacts may be disabled or hidden).
> 1. Artefact 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 artefact. 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. Artefact class may declare fields, with values to be injected from properties set in job xml element referencing that artefact:
> {code}
> @Inject @BatchProperty(name="property1") String property;
> @Inject @BatchProperty String property2;
> {code}
> Thus, the wizard will have inputs as follows:
> - Artefact: [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.11#6341)
11 years, 4 months