[jBPM Development] - Not able to get the Node Name
by Balaji Subramaniam
Balaji Subramaniam [https://community.jboss.org/people/balajiora] created the discussion
"Not able to get the Node Name"
To view the discussion, visit: https://community.jboss.org/message/806955#806955
--------------------------------------------------------------
I have simple Human Task Process, Using JBPM API, I am trying to get the Node Name and I am getting Null Pointer Exception. But I am able to get the Node Id.
long nodeId = ((org.jbpm.workflow.instance.WorkflowProcessInstance)processInst).getNodeInstances().iterator().next().getId();
LOG.info("Node Id : "+nodeId);
nodeName = ((org.jbpm.workflow.instance.WorkflowProcessInstance)processInst).getNodeInstances().iterator().next().getNodeName();
https://community.jboss.org/servlet/JiveServlet/showImage/2-806955-20583/... https://community.jboss.org/servlet/JiveServlet/downloadImage/2-806955-20...
Exception Message:
Exception in getNodeName Method
java.lang.NullPointerException
at org.jbpm.process.instance.impl.ProcessInstanceImpl.getProcess(ProcessInstanceImpl.java:68)
at org.jbpm.workflow.instance.impl.WorkflowProcessInstanceImpl.getWorkflowProcess(WorkflowProcessInstanceImpl.java:181)
at org.jbpm.workflow.instance.impl.WorkflowProcessInstanceImpl.getNodeContainer(WorkflowProcessInstanceImpl.java:69)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.getNode(NodeInstanceImpl.java:103)
at org.jbpm.workflow.instance.node.WorkItemNodeInstance.getNodeName(WorkItemNodeInstance.java:314)
at com.jpmorgan.jbpm.process.SpringProcessManagement.getNodeName(SpringProcessManagement.java:206)
at com.jpmorgan.jbpm.controllers.StartProcess.actionOnTask(StartProcess.java:106)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.springframework.web.method.support.InvocableHandlerMethod.invoke(InvocableHandlerMethod.java:219)
at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:132)
at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:104)
at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandleMethod(RequestMappingHandlerAdapter.java:745)
at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:686)
at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:80)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:925)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:856)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:920)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:816)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:801)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Could you please help me to resolve this issue?
Balaji
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/806955#806955]
Start a new discussion in jBPM Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
13 years, 1 month
[jBPM Development] - problem during starting task service
by Mahdi k
Mahdi k [https://community.jboss.org/people/mahdi1991] created the discussion
"problem during starting task service"
To view the discussion, visit: https://community.jboss.org/message/809272#809272
--------------------------------------------------------------
hi
i tried to start human task service but i encountered a problem here:
C:\jbpm-installer 5.4>ant start.human.task
Buildfile: C:\jbpm-installer 5.4\build.xml
start.human.task:
[mkdir] Created dir: C:\jbpm-installer 5.4\task-service\target
[javac] C:\jbpm-installer 5.4\build.xml:864: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds
[javac] Compiling 1 source file to C:\jbpm-installer 5.4\task-service\target
[copy] Copying 5 files to C:\jbpm-installer 5.4\task-service\target
* [java] 14 22/02 04:13:56,274[main] ERROR task.identity.DefaultUserGroupCallbackImpl.<init> - Error when loading group information for callback from location: file:null/roles.properties*
* [java] java.io.FileNotFoundException: null\roles.properties (The system cannot find the path specified)*
[java] at java.io.FileInputStream.open(Native Method)
[java] at java.io.FileInputStream.<init>(FileInputStream.java:138)
[java] at java.io.FileInputStream.<init>(FileInputStream.java:97)
[java] at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:90)
[java] at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:188)
[java] at java.net.URL.openStream(URL.java:1037)
[java] at org.jbpm.task.identity.DefaultUserGroupCallbackImpl.<init>(DefaultUserGroupCallbackImpl.java:55)
[java] at org.jbpm.task.identity.DefaultUserGroupCallbackImpl.<init>(DefaultUserGroupCallbackImpl.java:40)
[java] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
[java] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
[java] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
[java] at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
[java] at java.lang.Class.newInstance0(Class.java:372)
[java] at java.lang.Class.newInstance(Class.java:325)
[java] at org.jbpm.task.identity.UserGroupCallbackManager.setCallbackFromProperties(UserGroupCallbackManager.java:69)
[java] at org.jbpm.DemoTaskService.main(Unknown Source)
[java] Task service registered usergroup callback ...
[java] Task service started correctly!
[java] Task service running ...
what should i do now?
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/809272#809272]
Start a new discussion in jBPM Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
13 years, 1 month
[JBoss AS 7 Development] - Logging Id's
by Thomas Diesler
Thomas Diesler [https://community.jboss.org/people/thomas.diesler] modified the document:
"Logging Id's"
To view the document, visit: https://community.jboss.org/docs/DOC-16810
--------------------------------------------------------------
Logging id ranges for JBoss AS7 i18n message interfaces.
|| %1,3% *Status* ||
| C | = | Complete |
| I | = | In Progress |
| P | = | Merged, but not complete |
| W | = | Waiting Merge |
|| *Range* || *Subsystem
* || *Status
* ||
| *10100 - 10199* | *Transaction* | C |
| *10200 - 10399
* | *Clustering**
* | C |
| *10400 - 10499* | *Connector**
* | C |
| *10500 - 10599* | *CLI (not applicable)
* | N/A |
| *10600 - 10699* | *Controller Client* | C |
| *10700 - 10799*, *18500 - 18699, 18800-18999* | *CMP* | C |
| *10800 - 10899* | *Host Controller (domain packages)* | C |
| *10900 - 10999, 16500 - 16599* | *Host Controller (host packages)* | C |
| *11000 - 11099, 16700 - 16799* | *EE* | C |
| *11100 - 11199* | *Embedded* | C |
| *11200 - 11299* | *JAXRS* | C |
| *11300 - 11399* | *JMX* | C |
| *11400 - 11499* | *JPA* | C |
| *11500 - 11599* | *Logging* | C |
| *11600 - 11699* | *Messaging* | C |
| *11700 - 11799* | *mod_cluster* | C |
| *11800 - 11899* | *Naming* | C |
| *11900 - 11999* | *OSGi* | C |
| *12000 - 12099, 16600 - 16699* | *Process Controller* | C |
| *12100 - 12199* | *Protocol* | C |
| *12200 - 12299* | *Management Client Content* | C |
| *12300 - 12399* | *Platform MBeans* | C |
| *12400 - 12499* | *Threads* | C |
| *12500 - 12599* | *PicketLink* | I |
| *12600 - 12699* | *JSF (proposed)* |
|
| *12700 - 13100* | *IIOP Common (proposed)* |
|
| *13100 - 13199* | *JDR* | C |
| *13200 - 13299* | *AppClient* | C |
| *13300 - 13399* | **Security*
* | C |
| *13400 - 13499, 14600 - 14899* | *Controller* | C |
| available block(s) |
|
|
| *14000 - 14099* | *JAXR* | W |
| *14100 - 14599* | *Ejb3* | P |
| **13400 - 13499, 14600 - 14899** | *Controller* | C |
| *14900 - 14999* | *Deployment Repository* | C |
| *15000 - 15099* | *Deployment Scanner* | C |
| *15100 - 15199* | *Domain Management HTTP Interface* | C |
| *15200 - 15299* | *Deployment Management* | C |
| *15300 - 15399* | *Network* | C |
| *15400 - 15499* | *Mail* | C |
| *15500 - 15699* | *Web Services (AS subsystem)* | C |
| *15700 - 15999*, *18700 - 18799* | *Server* | C |
| *1**6000 - 16099* | *Weld* | C |
| *16100 - 16199* | *EE Deployment* | C |
| *16200 - 16299* | *Configadmin* | C |
| *16300 - 16499* | *Jacorb* | C |
| *10900 - 10999, 16500 - 16599* | *Host Controller (host packages)* | C |
| *12000 - 12099, 16600 - 16699* | *Process Controller* | C |
| *11000 - 11099, 16700 - 16799* | *EE* | C |
| *16800 - 16899* | *Patching (Library)* | C |
| *16900 - 16999* | *Patching (Server)* |
|
| *17000 - 17099* | *POJO* | C |
| *17100 - 17199* | *Remoting* | W |
| *17200 - 17299* | *SAR* | W |
| *17300 - 17699* | *Web/Undertow (reserved)* | I |
| available block(s) |
|
|
| *18000 - 18399* | *Web* | C |
| *18400 - 18499* | *Xts* | C |
| *15700 - 15999, 18700 - 18799* | *Server* | C |
| available block(s) |
|
|
| *19000-19999* | *JSR-77* | I |
| *20000-20999* | *Camel* | I |
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-16810]
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 Transactions Development] - Compensating Transactions: When ACID is too much
by Paul Robinson
Paul Robinson [https://community.jboss.org/people/paul.robinson] modified the document:
"Compensating Transactions: When ACID is too much"
To view the document, visit: https://community.jboss.org/docs/DOC-48610
--------------------------------------------------------------
I'm using this article as a place for people to review a blog post I'm preparing.
The plan is to base my JUDCon:Boston talk roughly on this blog post. In addition to this theory, my presentation will include plenty of code examples for each of the scenarios. These code examples will demonstrate the current design of the compensations API. I'll also be adding sections at the end to explain what we have implemented so far and our future roadmap.
My current thoughts are that this text is too long for a blog post.
h1. Compensating Transactions: When ACID is too much
ACID transactions are a useful tool for application developers and can provide very strong guarantees, even in the presence of failures. However, ACID transactions are not always appropriate for every situation.
ACID transactions are achieved by holding locks on resources and require the ability to rollback changes. In some situations, the blocking nature of the protocol can be too limiting to performance, especially if the transaction is distributed. Also, some actions can’t simply be rolled back; for example, sending an email.
A common strategy for applications that can’t use ACID, is to throw out transactions altogether. However, with this approach you are missing out on many of the benefits that transactions can provide. There are alternative transaction models that relax some of the ACID properties, while still retaining many of the strong guarantees essential for building robust enterprise applications. These should be considered before deciding not to use transactions at all.
In a recent post I talked about the work we are doing, in the Narayana project, to improve support for compensation-based transactions. In this post I’ll show how this technology can be applied to scenarios in which ACID transactions are frequently seen as inappropriate.
What is a ‘Compensation-based transaction’?
In an ACID transaction, changes are not visible outside of the transaction until it completes. An atomic outcome is guaranteed using a two-phase protocol in which locks are obtained prior to the first phase and released in the second phase. The transaction manager guarantees an atomic outcome, even in the presence of failures.
In a compensation-based transaction, changes are visible outside of the transaction as soon as they are made. If any of the participants are unsuccessful, the transaction compensates those participants that have already completed their work. This compensation action is application specific and is required to ‘undo’ the changes made by the transaction. Similarly to the ACID transaction, the transaction manager guarantees an atomic outcome, even in the presence of failures.
h4. When are Compensation-based Transactions a good fit?
h6. Non-transactional work
ACID transactions rely on the work supporting rollback. This is fine for work that interacts with transactional resources, such as databases or message queues. However actions like sending an email cannot be rolled back. Here a compensation-based transaction can be used as an alternative. In this case the compensation action is to send another email notifying the recipient of the final outcome.
Alternatively, you may have multiple XA (two-phase) aware resources, but due to performance reasons you need to run them in one-phase mode.
Maybe you have a combination of transactional and non-transactional work. In this case the transactional work can be rolled back, if required, whilst the non-transactional resources are compensated.
Also, you may have transactional resources or services, but, for whatever reason, they will not participate in an existing transaction. This can occur when you try to compose multiple services outside of your control. For example, a travel agent application may compose a transaction of calls to third party services. Providing these services offer an interface for cancelling (compensating) a booking, you should be able to use a compensation-based transaction to coordinate them.
If you find yourself needing to coordinate multiple non-transactional tasks, you should consider using compensations.
h6. Cross-Domain Distributed Transactions
When your application becomes distributed, you greatly increase the chances of failure. Many of these failures can be tolerated by using a distributed ACID transaction. However, this approach is often dismissed as impractical for a number of reasons.
The first is that distributed transactions tend to take longer to run, due to the increased communication latency. This can cause big problems for your throughput as the duration of held locks greatly increases.
The second issue is that all the servers in the distributed transaction become tightly-coupled. Furthermore, the server that begun the transaction has full control over when the transaction should complete (ignoring the option of making a heuristic decision, which is really bad!). This may be acceptable if all the servers reside in the same business domain, but it’s rarely acceptable for cross-business domain applications.
Compensation-based transactions can be used to solve both of these problems. The latency imposed by the distributed transaction does not result in holding of locks for extended periods as the work is completed immediately, rather than waiting until the end of the transaction. If this work was a database update, it would be committed immediately. A second database update would be made to undo the change, should compensation be required.
Compensation-based transactions also encourage a loosely-coupled architecture as each participant offers a more natural interface to the coordinator. For example, in a flight booking example, the service interface would consist of ‘bookFlight’ and ‘cancelFlight’ operations (‘cancel’ being the compensating action).
h6. Long Lived Transactions (LLT)
ACID transactions are not particularly well suited for transactions that take a long time to run. This is because they acquire locks on resources as they progress and don’t release them until the transaction completes. In the meantime, other transactions, requiring that data, are blocked. Furthermore, a failure of a long running transaction results in the loss of all work completed so far.
A compensation-based transaction can be composed of multiple short-lived ACID transactions. When each transaction completes, it releases the locks on the data it held, allowing other transactions, requiring that data, to proceed. A compensation action is registered for each ACID transaction. These actions are invoked, in reverse order, for all completed transactions, should the LLT need to be aborted.
Furthermore, should one of these short-lived transactions fail, it could be possible to find an alternative, preventing the entire transaction from failing, and allowing forward progress to be achieved. Also, in some situations, as the transaction progresses, you may decide to abort just part of the transaction.
For example, take a travel booking example. We begin by booking a flight. We then try to book a taxi, but that fails. At this point we don’t want to compensate the flight as it may be fully-booked next time we try. Therefore we try to find an alternative Taxi, which in this example succeeds. Later, in the LLT, we may find a cheaper flight, in which case we want to cancel the original flight whilst keeping the taxi and booking the cheaper flight. In this case we notify our intentions to the transaction manager who ensures that the more expensive flight is compensated when the LLT completes.
h6. Conclusion
In this blog post I’ve introduced the concept of a compensation-based transaction and showed how it could be used to provide strong guarantees in situations that are not applicable for ACID transactions.
Most of what is discussed here is already supported through our WS-BA implementation. We are currently in the process of decoupling this technology from Web Services and improving the developer API.
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-48610]
Create a new document in JBoss Transactions Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
13 years, 1 month
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-11920
--------------------------------------------------
> In the general tasks section there are a couple of lines mentioning "Enforce Permissions" in web console and CLI - I would suggest there should be no mention on client side enforcement as that is just not enforcement - all of that needs to be on the server side.
Agreed; we need another term.
>
> This in turn implies to me that anything server side needs to be more than just enforcement i.e. performing an authorization check at the time of an attempt to access the model / execute an operation is the bare minimum - we potentially need to be able to go beyond this to pro-actively identify what can or can not be accessed.
>
> As we have mentioned previously for any permissions schema to be secure it needs to be understandable, one possibility here is to look at ways to show the effect of the currently defined permissions scheme on the domain model. This could be something along the lines of generating a report which visualises the tree and highlights what can and can not be accessed by a specific user / role - alternatively social networks commonly have a view profile as option to see what others can see, this could be a mode to consider in the console.
>
> Some of these items might be out of scope for this phase of development but just wanted to raise them so we can at least take them into account.
>
This is what I was getting at with
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)
My assumption is the admin console will need something like this to provide a proper UI. If it does a read-resource, a response header associated with the response can indicate that certain attributes or children were filtered out due to access control reasons, so the console can take action when it renders the screen. But to know that the "Test JDBC Connection" button should be disabled or hidden, the console will need to know that the op is not allowed, and that won't come from any existing op.
The report thing you mention could be a twist on this with parameter(s) to set the "view as" value. Perhaps a different op but with shared implementation details.
--------------------------------------------------
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 and there is not reason for a nightly build.
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. The integration-stack-base and core-base combine to include all dependencies which are included as part of JBDS. See the generated aggregate-base.target in your repository. The community target extends the base target by including dependencies which are only available in community JBT releases (aggregate-full.target).
e.g. I need to update to graphiti 0.9.2:
0.0.0.1. fork/branch/modify https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... integration-stack-base.target
0.0.0.2. update the version of graphiti
0.0.0.3. verify that the updated version is being mirrored correctly on jboss.org
0.0.1. Modify project version in https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... pom.xml
0.0.2. Ensure plugins are mirrored on jboss.org
1. Build locally to validate stack dependencies.
2. 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)
3. 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
4. Merge any changes required by other components from subtasks (e.g. update Savara to 2.1.0.Final)
5. Build IS locally to validate dependency consistency
6. Issue pull request against upstream IS configuration project
7. Process pull (by release engineer)
8. 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. Three target platforms are provided: 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 and https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... community.target (see Component Updates above). 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.
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
