Re: [jboss-dev-forums] [JBoss AS 7 Development] - Access control notes
by Brian Stansberry
Brian Stansberry [https://community.jboss.org/people/brian.stansberry] commented on the document
"Access control notes"
To view all comments on this document, visit: https://community.jboss.org/docs/DOC-48596#comment-11900
--------------------------------------------------
A question for server-groups is resources that are not directly referenced by the server-group (e.g. a profile) or contained by something directly referenced (e.g. a subsystem) but rather are only brought in via indirect references (e.g. a path or interface) or convention (e.g. system properties).
My inclination would be any simple system where we allow restriction to a given server-group would restrict access to such resources.
It's possible we could analyze the socket-binding-group resource and determine whether an interface is relevant. I can't see doing that for paths or system properties.
--------------------------------------------------
13 years, 1 month
[JBoss AS 7 Development] - Access control notes
by Brian Stansberry
Brian Stansberry [https://community.jboss.org/people/brian.stansberry] modified the document:
"Access control notes"
To view the document, visit: https://community.jboss.org/docs/DOC-48596
--------------------------------------------------------------
h1. Timeline
Design Phase I:
+ Lay out the fundamental architecture, identify the main requirements and intended approach for meeting each
+ Main participants (67% time task):
++ Brian Stansberry, Darran Lofthouse, Heiko Braun, Jason Greene
+ Partial participants (25% time task):
++ David Lloyd, one other member of Domain Management team, Anil Saldhana, Harald Pehl
+ 2 weeks
+ Completion allows some aspects of dev to begin (which, TBD)
+ Inability to get the stated time commitments from all participants delays completion by that amount of time
Design Phase II:
+ Design in detail some of the fundamental areas where either coordinated design is required or a sub-team needs to flesh out details
+ Participants and time commitment -- same as Design Phase I
+ 2 weeks
Dev Phase:
++ TBD (see tasks below)
++ need to assign resources and timelines to each task.
Test Phase:
TBD
h1. Tasks
interface to decision point
+ information about resource access request
+ information about user
+ other information about request (time of day, interface, etc)
misc op authorization
+ basic control over op execution
write-attribute/undefine-attribute authorization
add op authorization
+ trick here is cases where certain attributes can't be written
++ my instinct is to reject the add; no sophisticated rules
read-attribute authorization
read-resource authorization, output control to use response header to indicate content was filtered
configuration of our default decision point
user info configuration (what data to provide decision point, where to get it)
read-resource-access op (an op to learn about user's ability to use API; based on read-resource-description)
+ uses
++ general information
++ allow caller to disable features that will be non-functional (e.g. buttons for misc ops that are not available)
model-reference issues
+ general issue of resources in a tree being affected by other resources
+ server groups
++ user has rights to a resource that affects an SG, but not to the SG itself
+ hosts
++ similar issue
++ twist is host-specific config vs domain-wide config affecting server's on a host
+ others?
+ notion: enforce this at domain rollout time?
++ problem: what about an admin-only HC situation? -- no rollout
Console
+ the interface structure doesn't necessarily refelct the model structure
++ i.e. some coarse grained interface compoments rely on a number of resources across the model
+ distinction between interface structure (interaction units) and DMR payload
+ suppression of interaction units can only be done if the screens properly bootstrap from the model
++ relates to "read-resource-access"
++ currently not the case and a major change (intended first prototype for AS8)
+ distinction between logical entities and resource tree structure
++ i.e. /subsystem=datasources is resource tree structure
++ datasource=ExampleDS is a logical entity within the tree structure
++ makes a diference for address pattern matching...
+ do we support security constraints for logical entities? (can see datasource "Foo" but not datasource "Bar")
++ relates to "model-reference issues".
CLI issues
+ basic handling of low-level (should be ok)
+ disable high-level commands in advance?
+ ls -- high-level equivalent to read-resource
Configuration propagation
++ master HC to slave
JMX security
+ AS domains depend on core security, as they just delegate
++ provide some information about access mechanism
+ other mbeans
++ what policy?
++ what control point?
Misc issues:
sniffing for resources -- request a resource to learn it exists from the failure response
h1. Resource Attributes
The following describes resource attributes required to enforce some permission schemes we've heard:
DMR API and Wireformat
+ separate static security meta data from dynamic runtime headers?
++ static: part of "read-resource-access"
++ dynamic: indication of enforced constraints as part of a DMR response (i.e suppressed elements)
h4. Scheme 1:
Monitor:
-- read-only flag on the operation
Configurator:
-- Storage flag on attribute
-- flag on operation to indicate runtime-only
-- "security privileged" flag attribute
-- "security privileged" flag on resource
-- attribute value is a vault expression?
Operator:
-- Storage flag on attribute
-- flag on operation to indicate runtime-only
-- "security privileged" flag attribute
-- "security privileged" flag on resource
-- attribute value is a vault expression?
Administrator
-- resource address
Deployer
-- resource address
-- see IBM details at http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.ba... http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.ba... to check for more
Admin Security Manager
-- I would consider the equivalent for us to be the ability to configure the access control policies
-- resource address
Auditor
-- resource address
h4. Scheme 2:
Anonymous
-- N/A
Admin
-- none; user is root
Deployer
seems equivalent to Scheme 3's read-write
-- "security privileged" flag attribute
-- "security privileged" flag on resource
-- attribute value is a vault expression?
Operator
-- read-only flag on the operation
-- resource-address
-- operation name
-- "security privileged" flag attribute
-- "security privileged" flag on resource
-- attribute value is a vault expression?
Monitor
-- read-only flag on the operation
-- "security privileged" flag attribute
-- "security privileged" flag on resource
-- attribute value is a vault expression?
h4. Scheme 3:
Read-only
-- read-only flag on the operation
-- "security privileged" flag attribute
-- "security privileged" flag on resource
-- attribute value is a vault expression?
Read-write
-- "security privileged" flag attribute
-- "security privileged" flag on resource
-- attribute value is a vault expression?
Privileged
-- none; user is root
This is basically equivalent to Scheme 2, without Scheme 2's "Operator".
Scheme 4:
Administrator
view or modify anything; deploy apps, perform lifecycle functions
Deployer
view anything, deploy apps, perform lifecycle functions
Operator
view anything, perform lifecycle
Monitor
view anything
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-48596]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
13 years, 1 month
[JBoss AS 7 Development] - Access control notes
by Brian Stansberry
Brian Stansberry [https://community.jboss.org/people/brian.stansberry] modified the document:
"Access control notes"
To view the document, visit: https://community.jboss.org/docs/DOC-48596
--------------------------------------------------------------
h1. Timeline
Design Phase I:
+ Lay out the fundamental architecture, identify the main requirements and intended approach for meeting each
+ Main participants (67% time task):
++ Brian Stansberry, Darran Lofthouse, Heiko Braun, Jason Greene
+ Partial participants (25% time task):
++ David Lloyd, one other member of Domain Management team, Anil Saldhana, Harald Pehl
+ 2 weeks
+ Completion allows some aspects of dev to begin (which, TBD)
+ Inability to get the stated time commitments from all participants delays completion by that amount of time
Design Phase II:
+ Design in detail some of the fundamental areas where either coordinated design is required or a sub-team needs to flesh out details
+ Participants and time commitment -- same as Design Phase I
+ 2 weeks
Dev Phase:
++ TBD (see tasks below)
++ need to assign resources and timelines to each task.
Test Phase:
TBD
h1. Tasks
interface to decision point
+ information about resource access request
+ information about user
+ other information about request (time of day, interface, etc)
misc op authorization
+ basic control over op execution
write-attribute/undefine-attribute authorization
add op authorization
+ trick here is cases where certain attributes can't be written
++ my instinct is to reject the add; no sophisticated rules
read-attribute authorization
read-resource authorization, output control to use response header to indicate content was filtered
configuration of our default decision point
user info configuration (what data to provide decision point, where to get it)
read-resource-access op (an op to learn about user's ability to use API; based on read-resource-description)
+ uses
++ general information
++ allow caller to disable features that will be non-functional (e.g. buttons for misc ops that are not available)
model-reference issues
+ general issue of resources in a tree being affected by other resources
+ server groups
++ user has rights to a resource that affects an SG, but not to the SG itself
+ hosts
++ similar issue
++ twist is host-specific config vs domain-wide config affecting server's on a host
+ others?
+ notion: enforce this at domain rollout time?
++ problem: what about an admin-only HC situation? -- no rollout
Console
+ the interface structure doesn't necessarily refelct the model structure
++ i.e. some coarse grained interface compoments rely on a number of resources across the model
+ distinction between interface structure (interaction units) and DMR payload
+ suppression of interaction units can only be done if the screens properly bootstrap from the model
++ relates to "read-resource-access"
++ currently not the case and a major change (intended first prototype for AS8)
+ distinction between logical entities and resource tree structure
++ i.e. /subsystem=datasources is resource tree structure
++ datasource=ExampleDS is a logical entity within the tree structure
++ makes a diference for address pattern matching...
+ do we support security constraints for logical entities? (can see datasource "Foo" but not datasource "Bar")
++ relates to "model-reference issues".
CLI issues
+ basic handling of low-level (should be ok)
+ disable high-level commands in advance?
+ ls -- high-level equivalent to read-resource
Configuration propagation
++ master HC to slave
JMX security
+ AS domains depend on core security, as they just delegate
++ provide some information about access mechanism
+ other mbeans
++ what policy?
++ what control point?
Misc issues:
sniffing for resources -- request a resource to learn it exists from the failure response
h1. Resource Attributes
The following describes resource attributes required to enforce some permission schemes we've heard:
DMR API and Wireformat
+ separate static security meta data from dynamic runtime headers?
++ static: part of "read-resource-access"
++ dynamic: indication of enforced constraints as part of a DMR response (i.e suppressed elements)
h4. Scheme 1:
Monitor:
-- read-only flag on the operation
Configurator:
-- Storage flag on attribute
-- flag on operation to indicate runtime-only
-- "security privileged" flag attribute
-- "security privileged" flag on resource
-- attribute value is a vault expression?
Operator:
-- Storage flag on attribute
-- flag on operation to indicate runtime-only
-- "security privileged" flag attribute
-- "security privileged" flag on resource
-- attribute value is a vault expression?
Administrator
-- resource address
iscadmins
-- N/A
Deployer
-- resource address
-- see IBM details at http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.ba... http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.ba... to check for more
Admin Security Manager
-- I would consider the equivalent for us to be the ability to configure the access control policies
-- resource address
Auditor
-- resource address
h4. Scheme 2:
Anonymous
-- N/A
Admin
-- none; user is root
Deployer
seems equivalent to Scheme 3's read-write
-- "security privileged" flag attribute
-- "security privileged" flag on resource
-- attribute value is a vault expression?
Operator
-- read-only flag on the operation
-- resource-address
-- operation name
-- "security privileged" flag attribute
-- "security privileged" flag on resource
-- attribute value is a vault expression?
Monitor
-- read-only flag on the operation
-- "security privileged" flag attribute
-- "security privileged" flag on resource
-- attribute value is a vault expression?
h4. Scheme 3:
Read-only
-- read-only flag on the operation
-- "security privileged" flag attribute
-- "security privileged" flag on resource
-- attribute value is a vault expression?
Read-write
-- "security privileged" flag attribute
-- "security privileged" flag on resource
-- attribute value is a vault expression?
Privileged
-- none; user is root
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-48596]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
13 years, 1 month
[JBoss ESB Development] - JBossESB - sending an ESB aware message
by Martin Myslík
Martin Myslík [https://community.jboss.org/people/m.myslik] created the discussion
"JBossESB - sending an ESB aware message"
To view the discussion, visit: https://community.jboss.org/message/808250#808250
--------------------------------------------------------------
Hi, I am a newbie to JBossESB and I am currently writing a test client to send both ESB aware and ESB unaware(JMS) messages to que. JMS messages work just fine, but I have a problem with ESB aware clients. I think that there is probably something wrong with my *jboss-esb.xml* file. (I am running my JBoss AS on a localhost and I am trying to connect to it from and outside application).
This is my sample code for ESB message sender:
public class SenderESB {
private String name = "NoName";
public SenderESB(String name) {
this.name = name;
}
//send ESB message
public void sendAMessage(String message) throws Exception {
// Create the delivery adapter for the target service (cache it)
System.setProperty("javax.xml.registry.ConnectionFactoryClass", "org.apache.ws.scout.registry.ConnectionFactoryImpl");
// Create the delivery adapter for the target service (cache it)
ServiceInvoker deliveryAdapter = new ServiceInvoker("ESB-Listener","Serviceconsumer");
// Create and populate the request message...
Message requestMessage = MessageFactory.getInstance().getMessage(MessageType.JBOSS_XML);
requestMessage.getBody().add(message);
// Deliver the request message synchronously - timeout after 20
// seconds...
deliveryAdapter.deliverAsync(requestMessage);
}
//GETTERS
public String getName() {
return name;
}
}
I am putting here my jboss-esb.xml as an attachment... Thanks for any answer.
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/808250#808250]
Start a new discussion in JBoss ESB Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
13 years, 1 month
[JBoss Tools Development] - Integration Tooling Release Process
by Paul Leacu
Paul Leacu [https://community.jboss.org/people/pleacu] modified the document:
"Integration Tooling Release Process"
To view the document, visit: https://community.jboss.org/docs/DOC-48326
--------------------------------------------------------------
h1. Overview
This document details the process for building and releasing composite/aggregate update sites for the JBoss integration tooling (formerly SOA tools).
h2. Goals
* Provide a light-weight process with minimal overhead for component owners.
* Provide an ever-current update site containing the latest, stable releases of integration tooling components.
* Allow component owners to independently manage their release schedules.
* Allow component owners to manage their own dependency stack.
h2. Assumptions
* Components use released versions of dependencies (i.e. stable builds).
* Component owners manage their own interdependencies with other integration components.
* Components and dependencies adhere to Eclipse API versioning rules.
h2. Implications
* Aggregate releases will be driven by component releases.
* Aggregate releases should manage themselves.
* Component nightly/milestone builds should always be compatible with other components in the aggregate.
h2. Definitions
* *Integration Stack (IS)* - all JBoss middleware integration tooling
* *IS configuration* - the definition of specific components and versions that make up the IS
* *IS build* - an update site (p2 repo) aggregating specific versions of integration tooling components.
* *Release types:** *stable* - an IS build aggregating stable (i.e. final) builds of all components that has been certified/tested by QA.
* *development* - an IS build aggregating stable builds of all components that has not been certified/tested by QA.
* *integration* - an IS build aggregating stable, development (e.g. beta) and/or integration builds of all components
* *next* - an internal IS build incorporating the latest integration builds of all components (i.e. the current "trunk" build). This will be used for identifying potential future incompatibilities.
Stable builds will align with a JBDS release in the same way JBT core builds do today. Development builds will reflect the current state of all stable components. Theoretically, any development build could be QA'd and promoted to stable (assuming no test failures). Integration builds allow for an "interim" stack which may be useful during a QA cycle (e.g. verifying a fix that requires updates to multiple components; a single component can be updated via the component update site). Next builds are used to identify potential incompatiblilities among components before they are integrated into a release and would occur weekly/monthly via a Hudson job (e.g. targeting JBT integration builds).
An IS build only needs to occur when the IS configuration changes. Because the IS stack is composed of stable components, configuration changes will only occur when individual components are released. For this reason, it is assumed the build would be invoked manually.
h1. Roles and Responsibilities
h2. Component Owners
1. *Component update site:* Component owners must provide an update site for each release of their component that is included in an IS build.
2. *Updating IS configuration:* Component owners must update the IS build configuration when a new version of their component is released. This ensures the IS is up-to-date.
3. *Respond to change requests:* Component owners must review IS configuration change requests and respond in a timely manner. If a requested change is incompatible with the current version of your component, provide details regarding when your component will be compatible, along with a patch containing changes to the IS configuration for your compatible release.
h2. Release Engineers
1. *Maintain build infrastructure:* Release engineers will be responsible for maintianing the build infrastructure, primarily the Jenkins jobs.
2. *Processing pull requests:* Release engineers will be responsible processing all pull requests related to IS configuration. This is to ensure consistency in the composition of the stack (e.g. components, component versions, IS version, etc.).
3. *Initiate IS builds:* Release engineers will be responsible for initiating IS builds.
4. *Build promotion:* Release engineers will be responsible for the promotion of IS builds (e.g. from development to stable).
h1. Release Process
h2. Component Updates
The following outlines the basic process for updating the IS configuration. Typically, this would occur when a component is released, but the same process is also used for updating shared dependencies (e.g. JBT core, third-party plugins, etc.).
1. Create a branch in the user repository for your IS configuration changes.
2. Modify the Integration Stack configuration for your updates, e.g. update URL for SwitchYard from 0.5.0.Final to 0.6.0.Final; update IS version from 0.9.0 to 0.9.1 (see versioning rules)1. For changes to your component within the community aggregate: https://github.com/jbosstools/jbosstools-integration-stack/tree/master/jb... https://github.com/jbosstools/jbosstools-integration-stack/tree/master/jb.... Modify the https://github.com/jbosstools/jbosstools-integration-stack/tree/master/jb... compositeArtifacts.xml and https://github.com/jbosstools/jbosstools-integration-stack/tree/master/jb... compositeContent.xml files to point to the new component update site.
2. Modify the https://github.com/jbosstools/jbosstools-integration-stack/tree/master/jb... category.xml file as necessary for any feature changes (e.g. adding a feature).
3. Modify the project version in https://github.com/jbosstools/jbosstools-integration-stack/tree/master/jb... pom.xml.
2. For changes to your component within the production aggregate: https://github.com/jbosstools/jbosstools-integration-stack/tree/master/de... https://github.com/jbosstools/jbosstools-integration-stack/tree/master/de.... Modify the https://github.com/jbosstools/jbosstools-integration-stack/tree/master/de... compositeArtifacts.xml and https://github.com/jbosstools/jbosstools-integration-stack/tree/master/de... compositeContent.xml files to point to the new component update site.
2. Modify the https://github.com/jbosstools/jbosstools-integration-stack/tree/master/de... category.xml file as necessary for any feature changes (e.g. adding a feature).
3. Modify the project version in https://github.com/jbosstools/jbosstools-integration-stack/tree/master/de... pom.xml.
3. For changes to dependencies: https://github.com/jbosstools/jbosstools-integration-stack/tree/master/ta... https://github.com/jbosstools/jbosstools-integration-stack/tree/master/ta.... Modify https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... integration-stack-base.target, https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... core-base.target or https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... community.target
2. Modify project version in https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... pom.xml
3. Ensure plugins are mirrored on jboss.org
3. Build locally to validate stack dependencies.
4. Create a https://issues.jboss.org/browse/JBTIS JBTIS JIRA task requesting update, e.g. update SwitchYard to 0.6.0.Final* Include link to github branch in task
* Include build results (e.g. SUCCESS or specific dependency resolution errors)
5. Create subtasks against each IS component for verification/approval* For components that failed the consistency check, mark subtasks appropriately, e.g. m2e-wtp version is inconsistent
6. Merge any changes required by other components from subtasks (e.g. update Savara to 2.1.0.Final)
7. Build IS locally to validate dependency consistency
8. Issue pull request against upstream IS configuration project
9. Process pull (by release engineer)
10. Invoke build job (by release engineer)
h2. Platform Updates
*Goal:* release updated IS within four weeks of JBT/JBDS core release.
1. Initiate platform update during JBT beta phase
2. Follow the component update process above (e.g. update JBT core from 3.3 to 4.0)
h2. JBoss Central Discovery Updates
*Goal:* Modify the JBoss Central mylyn discovery install/update mechanism.
JBoss Central, based on http://wiki.eclipse.org/Mylyn/Discovery Mylyn Discovery, is in part a UI for installing new features into Eclipse or JBDS. It provides a richer, yet simpler UI than what the Eclipse equinox p2 install manager provides out of the box.
For detailed information see https://community.jboss.org/docs/DOC-48297 https://community.jboss.org/wiki/JBossCentralsSoftwareUpdateTab-HowDoesIt...
1. For changes to the jbosstools community discovery update: https://github.com/jbosstools/jbosstools-integration-stack/tree/master/jb... https://github.com/jbosstools/jbosstools-integration-stack/tree/master/jb... or production discovery update: https://github.com/jbosstools/jbosstools-integration-stack/tree/master/de... https://github.com/jbosstools/jbosstools-integration-stack/tree/master/de... follow the same git process as defined in the Components Updates section.
2. Modify the plugin connector descriptors and installation units as needed within the discovery plugin.
3. Add any icons that may be required.
h2. Dependency Updates
The process for updating a shared dependency is the same as that for updating any other component, with the following additions:
1. Make sure the dependency is mirrored on jboss.org.
2. Make sure the dependency is not already included through JBT core.
If a dependency is included through JBT core, you will need to coordinate with the core team on the upgrade, as the change may impact components outside the IS.
h2. Versioning Rules - major.minor.update.build
*Major* should be updated for:
* Base platform changes, e.g. Eclipse Indigo->Juno, JBT 3.3->4.0
* Major component updates, e.g. SwitchYard 1.0->2.0
*Minor* should be updated for minor component updates, e.g. SwitchYard 0.5->0.6
*Update* should be updated for minor component updates, e.g. SwitchYard 0.5.0->0.5.1
*Build* should be updated for each build, e.g. when building against nightly/integration/development repositories
** Note, the basic assumption here is that components are adhering to basic API rules (per Eclipse; e.g. minor includes bug fixes and api additions, major may include breaking api changes).
h1. Update Site Locations
* *Integration builds: http://download.jboss.org/jbosstools/updates/integration/juno/integration... http://download.jboss.org/jbosstools/updates/integration/juno/integration...
* *Development builds: http://http://download.jboss.org/jbosstools/updates/development/juno/inte... http://http://download.jboss.org/jbosstools/updates/development/juno/inte...
* *Stable builds: http://http://download.jboss.org/jbosstools/updates/stable/juno/integrati... http://http://download.jboss.org/jbosstools/updates/stable/juno/integrati...
h1. Infrastructure
* *JIRA -* https://issues.jboss.org/browse/JBTIS https://issues.jboss.org/browse/JBTIS
* *Source -* https://github.com/jbosstools/jbosstools-integration-stack https://github.com/jbosstools/jbosstools-integration-stack* *target-platform* - provides a target platform defining all upstream dependencies for use by IS components (e.g. JBT core, third-party plugins)
* *aggregate-site* - provides category and feature definitions for the IS update site
* *discovery* - provides JBoss Central discovery support
* *Jenkins* - * *target platform* - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-target-platform https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-target-platform
* *aggregate* - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-aggregate https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-aggregate
* *aggregate publish/promote* - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-aggregate-publish https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-aggregate-publish
* *discovery* - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-discovery https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-discovery
* *install tests* - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-4.0_stable_bra... https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-4.0_stable_bra...
h2. Target Platforms
The provided target platforms define all upstream dependencies available to an IS component. Two target platforms are provided: base and community. The base target platform includes all dependencies which are also included as part of JBDS. The community target extends the base target by including dependencies which are only available in community JBT releases. If your component needs to be included in a JBDS release, DO NOT use the community target platform. For more information and an example on how to refer to the target platform definition, see: https://github.com/jbosstools/jbosstools-integration-stack/blob/master/RE... https://github.com/jbosstools/jbosstools-integration-stack/blob/master/RE...
h1. Future Plans
1. Add support for executing component unit tests as part of the aggregate build. The goal being to help ensure the stability of the aggregate.
2. Add a "next" build that will build against upcoming core platforms (e.g. Kepler, JBT 4.1). This should serve as an early warning system to identify platform incompatibilities early in the process.
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-48326]
Create a new document in JBoss Tools Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
13 years, 1 month