[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 edited comment on JBIDE-18857 at 12/10/14 12:44 PM:
--------------------------------------------------------------------------
Batch uses annotation javax.inject.Named on Java classes. We have it processed in CDI tools, but batch project can do without CDI, as javax.inject.Named does not require CDI.
It seems we may need nature/facet/builder for a Batch project. Batch tools should not depend on whether the project has or not CDI nature/facet.
Batch project definitely needs its own model which should collect Batch specific objects and should be built by some builder.
There is a way to avoid Batch nature/builder - use extension to KB nature/builder. KB nature now is attached to all projects that would use in full JBoss Tools capabilities. So, kb plugin may define interfaces and extension point for models that would be stored/accessed through KBModel, and had their builders called through KBBuilder. We have already used it for JSF 2 project model. Theoretically, CDI model/builder could be also implemented in this way.
So, here is choice for voting.
1. New nature/builder for projects with Batch capabilities.
2. Framework that uses KB nature/builder to access and build projects with Batch capabilities (detected by Batch specific libraries).
3. Just manage Batch model through JDT's IElementChangedListener - this approach will have bad performance for large projects (but maybe Batch projects are small?)
4. ...
I would prefer (1) as most straitforward and Eclipse-like, but ready to implement any of the choices.
[~maxandersen], [~akazakov], please take a look.
was (Author: scabanovich):
Batch uses annotation javax.inject.Named on Java classes. We have it processed in CDI tools, but batch project can do without CDI, as javax.inject.Named does not require CDI.
It seems we may need nature/facet/builder for a Batch project. Batch tools should not depend on whether the project has or not CDI nature/facet.
Batch project definitely needs its own model which should collect Batch specific objects and should be built by some builder.
There is a way to avoid Batch nature/builder - use extension to KB nature/builder. KB nature now is attached to all projects that would use in full JBoss Tools capabilities. So, kb plugin may define interfaces and extension point for models that would be stored/accessed through KBModel, and had their builders called through KBBuilder. Theoretically, CDI model/builder could be also implemented in this way.
So, here is choice for voting.
1. New nature/builder for projects with Batch capabilities.
2. Framework that uses KB nature/builder to access and build projects with Batch capabilities (detected by Batch specific libraries).
3. Just manage Batch model through JDT's IElementChangedListener - this approach will have bad performance for large projects (but maybe Batch projects are small?)
4. ...
I would prefer (1) as most straitforward and Eclipse-like, but ready to implement any of the choices.
[~maxandersen], [~akazakov], please take a look.
> 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.8#6338)
11 years, 6 months
[JBoss JIRA] (JBIDE-18861) module start action does not delete *.undeployed file
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18861?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-18861:
-------------------------------------
Ok... so i've verified it only happens when mixing filesystem vs management operations. Because the deploy was done via filesystem, the 'stop' should also be done via filesystem, as should the start. So what this means is when the server is in non-management mode, we should not be doign a management-based stop / start. We should be doing deployment marker based start and stop of modules only (when server is in fs mode).
> module start action does not delete *.undeployed file
> -----------------------------------------------------
>
> Key: JBIDE-18861
> URL: https://issues.jboss.org/browse/JBIDE-18861
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: server
> Environment: Windows7 64bit, JDK 8u25
> Reporter: Darryl Miles
> Priority: Minor
> Fix For: 4.2.2.Final, 4.3.0.Alpha1
>
>
> If you start Wildfly with all modules enabled and started.
> Now use STOP action on an EAR module.
> Now stop Wildfly.
> Now start Wildfly (debug or run).
> It will start up without the EAR module running, this is correct behavior at this point.
> Now use START on EAR module. It fails to start at all.
> This is because the file *.undeployed still exists. If you manually remove the file (using system file manager) the module will start up.
> If you perform a "full publish" on the module that appears to cause it to start up as well.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 6 months
[JBoss JIRA] (JBDS-3284) Ionic Palette - version selection, detection
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBDS-3284?page=com.atlassian.jira.plugin.... ]
Alexey Kazakov updated JBDS-3284:
---------------------------------
Component/s: jsp/jsf/xml/html source editing
> Ionic Palette - version selection, detection
> --------------------------------------------
>
> Key: JBDS-3284
> URL: https://issues.jboss.org/browse/JBDS-3284
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: jsp/jsf/xml/html source editing
> Reporter: Burr Sutter
> Assignee: Alexey Kazakov
>
> As a Cordova-focused hybrid mobile app developer, I need to be able to import existing Ionic projects and modify the version of the Ionic framework, where the Palette is flexible enough to handle version changes, including addition/subtraction of specific widgets only available in particular versions.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 6 months
[JBoss JIRA] (JBDS-3272) JBoss Central HTML
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3272?page=com.atlassian.jira.plugin.... ]
Denis Golovin updated JBDS-3272:
--------------------------------
Component/s: central
> JBoss Central HTML
> ------------------
>
> Key: JBDS-3272
> URL: https://issues.jboss.org/browse/JBDS-3272
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: central
> Reporter: Burr Sutter
>
> Convert JBoss Central into a HTML-based component. This should allow for easier long-term maintenance and faster/easier ad-hoc updates being pushed to users. In addition, better scalability should others wish to contribute wizards, archetypes, quickstarts and showcase examples.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 6 months