[JBoss JIRA] (WFLY-4571) Merge the wildfly BOMs into a single BOM
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4571?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-4571:
-----------------------------------
Also guys keep in mind that this is *wildfly* bom not arquillian/testing/quickstart bom.
not everyone uses arquillian & friends for testing.
and wildfly boms should focus on providing GAVs for what are user accessible APIs.
wildfly-arquillian adapter is not part of wildfly it is its add-on. as such should also be part of separate bom not a main one.
> Merge the wildfly BOMs into a single BOM
> ----------------------------------------
>
> Key: WFLY-4571
> URL: https://issues.jboss.org/browse/WFLY-4571
> Project: WildFly
> Issue Type: Enhancement
> Reporter: Paul Gier
> Assignee: Paul Gier
>
> We had some discussion on the jbossdeveloper list [1] about merging the current wildfly/eap boms into a single one instead of a separate bom for each use case.
> The only problematic BOM might be the hibernate3 bom because this includes dependencies which conflict with the hibernate 4 bom. So the hibernate 3 bom will probably need to remain separate.
> [1]http://lists.jboss.org/pipermail/jbossdeveloper/2015-April/000347.html
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFLY-4571) Merge the wildfly BOMs into a single BOM
by Paul Gier (JIRA)
[ https://issues.jboss.org/browse/WFLY-4571?page=com.atlassian.jira.plugin.... ]
Paul Gier commented on WFLY-4571:
---------------------------------
The risk is if arquillian brings in some thirdparty dependency version which unintentionally overrides a transitive dep in the current build. I think it's a relatively small risk, but I'm ok with the boms either way. One single bom or a separate one for tools which inherits the other deps from the main bom.
> Merge the wildfly BOMs into a single BOM
> ----------------------------------------
>
> Key: WFLY-4571
> URL: https://issues.jboss.org/browse/WFLY-4571
> Project: WildFly
> Issue Type: Enhancement
> Reporter: Paul Gier
> Assignee: Paul Gier
>
> We had some discussion on the jbossdeveloper list [1] about merging the current wildfly/eap boms into a single one instead of a separate bom for each use case.
> The only problematic BOM might be the hibernate3 bom because this includes dependencies which conflict with the hibernate 4 bom. So the hibernate 3 bom will probably need to remain separate.
> [1]http://lists.jboss.org/pipermail/jbossdeveloper/2015-April/000347.html
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFCORE-669) Make it possible to propagate attachments from the operation context to the transformer context
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-669?page=com.atlassian.jira.plugin... ]
Kabir Khan updated WFCORE-669:
------------------------------
Description:
The transformation context needs attachments, and the operation context attachments should be propagable to the transformation context so that the write attribute handlers can give signals to the transformers. We don't want to propagate everything, so I have created TransformerOperationAttachment which in turn contains attach() methods. Only attachments added there get propagated.
One use case is if the old model used child resources, so it has child=1, child=2. If the new model was refactored to use this as a map attribute on the parent resource, when the attribute is overwritten, the transformer needs to create a composite to add what is new, remove what is missing, and update things which were changed. However, this is not known to the transformer. So the idea is that the write attribute handler can use these attachments to signal the transformer about what has been added and removed by comparing the new and old values.
was:
The transformation context needs attachments, and the operation context attachments should be propagable to the transformation context so that the write attribute handlers can give signals to the transformers. We don't want to propagate everything, so I have created TransformerOperationAttachment which in turn contains attach() methods. Only attachments added there get propagated.
One use case is if the old model used child resources, so it has child=1, child=2. If the new model was refactored to use this as a map attribute on the parent resource, when the attribute is overwritten, the transformer needs to create a composite to add what is new, remove what is missing, and update things which were changed. However, this is not known to the transformer. So the idea is that the write attribute handler can use these attachments to signal the transformer about what has been added and removed.
> Make it possible to propagate attachments from the operation context to the transformer context
> -----------------------------------------------------------------------------------------------
>
> Key: WFCORE-669
> URL: https://issues.jboss.org/browse/WFCORE-669
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 1.0.0.CR1
>
>
> The transformation context needs attachments, and the operation context attachments should be propagable to the transformation context so that the write attribute handlers can give signals to the transformers. We don't want to propagate everything, so I have created TransformerOperationAttachment which in turn contains attach() methods. Only attachments added there get propagated.
> One use case is if the old model used child resources, so it has child=1, child=2. If the new model was refactored to use this as a map attribute on the parent resource, when the attribute is overwritten, the transformer needs to create a composite to add what is new, remove what is missing, and update things which were changed. However, this is not known to the transformer. So the idea is that the write attribute handler can use these attachments to signal the transformer about what has been added and removed by comparing the new and old values.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFCORE-669) Make it possible to propagate attachments from the operation context to the transformer context
by Kabir Khan (JIRA)
Kabir Khan created WFCORE-669:
---------------------------------
Summary: Make it possible to propagate attachments from the operation context to the transformer context
Key: WFCORE-669
URL: https://issues.jboss.org/browse/WFCORE-669
Project: WildFly Core
Issue Type: Feature Request
Components: Domain Management
Reporter: Kabir Khan
Assignee: Kabir Khan
Fix For: 1.0.0.CR1
The transformation context needs attachments, and the operation context attachments should be propagable to the transformation context so that the write attribute handlers can give signals to the transformers. We don't want to propagate everything, so I have created TransformerOperationAttachment which in turn contains attach() methods. Only attachments added there get propagated.
One use case is if the old model used child resources, so it has child=1, child=2. If the new model was refactored to use this as a map attribute on the parent resource, when the attribute is overwritten, the transformer needs to create a composite to add what is new, remove what is missing, and update things which were changed. However, this is not known to the transformer. So the idea is that the write attribute handler can use these attachments to signal the transformer about what has been added and removed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFCORE-585) Offline CLI for a Host Controller
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-585?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-585:
------------------------------------
Fix Version/s: 2.0.0.Beta1
(was: 2.0.0.Alpha1)
> Offline CLI for a Host Controller
> ---------------------------------
>
> Key: WFCORE-585
> URL: https://issues.jboss.org/browse/WFCORE-585
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI, Domain Management
> Reporter: Brian Stansberry
> Assignee: luck3y
> Fix For: 2.0.0.Beta1
>
>
> Direct local administration of a Host Controller running from a WildFly Core-based installation via the CLI without requiring a socket-based connection. The general use case is initial setup type activities where the user doesn't want to have to launch a WF server or HC process and potentially have it be visible on the network. WFLY-3288 is one use case; another is a desire some folks have expressed in being able to do configuration without first having to edit any xml to avoid port conflicts on 9990 or 9999.
>
> As the CLI is itself embeddable, this also opens up the possibility of embedding the CLI inside some other process (say a test class, a provisioning tool or a jar with a main) and then launching the embedded server and using the embedded CLI as a convenient management tool.
> This JIRA is for administering a Host Controller. A separate JIRA, WFCORE-584 is for equivalent functionality for a standalone server.
> This will require some rework of the Host Controller / Process Controller relationship, as embedding a PC in the CLI makes no sense. The server-lifecycle control functions of the PC will need to be moved into the same process.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFCORE-585) Offline CLI for a Host Controller
by luck3y (JIRA)
[ https://issues.jboss.org/browse/WFCORE-585?page=com.atlassian.jira.plugin... ]
luck3y reassigned WFCORE-585:
-----------------------------
Assignee: luck3y
> Offline CLI for a Host Controller
> ---------------------------------
>
> Key: WFCORE-585
> URL: https://issues.jboss.org/browse/WFCORE-585
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI, Domain Management
> Reporter: Brian Stansberry
> Assignee: luck3y
> Fix For: 2.0.0.Alpha1
>
>
> Direct local administration of a Host Controller running from a WildFly Core-based installation via the CLI without requiring a socket-based connection. The general use case is initial setup type activities where the user doesn't want to have to launch a WF server or HC process and potentially have it be visible on the network. WFLY-3288 is one use case; another is a desire some folks have expressed in being able to do configuration without first having to edit any xml to avoid port conflicts on 9990 or 9999.
>
> As the CLI is itself embeddable, this also opens up the possibility of embedding the CLI inside some other process (say a test class, a provisioning tool or a jar with a main) and then launching the embedded server and using the embedded CLI as a convenient management tool.
> This JIRA is for administering a Host Controller. A separate JIRA, WFCORE-584 is for equivalent functionality for a standalone server.
> This will require some rework of the Host Controller / Process Controller relationship, as embedding a PC in the CLI makes no sense. The server-lifecycle control functions of the PC will need to be moved into the same process.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years