[JBoss Tools] - How to use Eclipse EGit with Github (in JBoss Tools)
by Andre Dietisheim
Andre Dietisheim [https://community.jboss.org/people/adietish] modified the blog post:
"How to use Eclipse EGit with Github (in JBoss Tools)"
To view the blog post, visit: https://community.jboss.org/community/tools/blog/2013/06/18/how-to-use-ec...
--------------------------------------------------------------
h1. What is this all about?
At JBoss Tools we use git when it comes to source control and have all our components hosted on Github. Eclipse offers very capable and handy git tooling with *EGit*. Nevertheless most of us still use the command line even though we do and use Eclipse on a daily base. The main reasons are manifold. EGit was for a long time still on the maturing curve and was not on par with the command line. Migrating users did not feel safe either since EGit was not operated in the way it used to be with CVS, SVN etc. Furthermore many UIs in EGit dont try to accomodate the newbie user but offer all the nots and bolts instead.
I'm using the EGit/JGit API (not the UI) in our OpenShift tooling. EGit/JGit is thus thus vital for my product. I therefore started to eat my own dogfood and forced myself to use EGit where I had the reflex to switch to the command line before. I found a pretty mature and very capable EGit. It is IMHO even more handy than the command line in certain usecases. I'll therefore try to improve EGit and convert most of us to us to use what was an unloved child before. I am very convinced that a little effort here and there will tranform EGit into first class and most excellent tooling that noone wants to miss.
h1. A tale of branches and main repos.
As I already mentioned, all JBoss Tools components are available from Github. All developes within JBoss Tools have their very own fork of those master repos and also have them on Github. When it comes to issue tracking, we use Jira. Whenever we tackle an issue we branch from master and commit our work to this topic branch. Since git is decentralized, one would have a local clone of its Github fork, commit the changes to it and push it back to Github. A pull request then notifies the maintainer of the master repo to review the suggested changes and merge them into the master branch in the master repo.
h1. Clone your Fork
Everything starts by having a personal fork on github. Once this is done one clones this repository to the local machine by issuing (I'm cloning my fork of the openshift-java-client here):
> git clone git://github.com/adietish/openshift-java-client.git
>
In EGit things are as easy as on the command line. You make sure that you have the Git URI in your clipboard and switch to the *Git Repository Exploring* perspective...
https://community.jboss.org/servlet/JiveServlet/showImage/38-5239-20943/g... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-5239-209...
You pick the *Clone a Git Repository* action from the toolbar in the *Git Repositories* view...
https://community.jboss.org/servlet/JiveServlet/showImage/38-5239-20957/c... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-5239-209...
... and EGit will use the Git URI in your clipboard to prefill the upcoming cloning settings:
https://community.jboss.org/servlet/JiveServlet/showImage/38-5239-20958/c... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-5239-209...
In an additional step you tell EGit where to clone to and once you're done the new repository will show up in your *Git Repositories* view:
https://community.jboss.org/servlet/JiveServlet/showImage/38-5239-20959/i... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-5239-209...
A last step involves importing the Eclipse project to your workspace. You pick *Import Projects...* from the context menu of your repository and you're all done:
https://community.jboss.org/servlet/JiveServlet/showImage/38-5239-20960/i... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-5239-209...
h1. Create your topic branch
Every issue is tackled in a separate topics branch. That allows us to separate the concerns when coding. It also allows us to switch among different task if priorities shift. We simply switch topic branch and focus on the current task.
To create a new topic branch based on the current master branch one does:
> git checkout -b my-topic master
Using EGit you wont have any more steps involved, it is as easy as it is with the command line. In the *Git Repository Exploring* perspective you unfold the branches of your local git repo, select the branch you want your topic branch to be based on (which usually is master) and pick *Create Branch...* in the context menu.
https://community.jboss.org/servlet/JiveServlet/showImage/38-5239-20951/c... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-5239-209...
In the upcoming dialog you choose the name of your new branch and hit *Finish*. EGit will by default switch your code to the new branch (see *Checkout new branch* checkbox).
https://community.jboss.org/servlet/JiveServlet/showImage/38-5239-20952/c... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-5239-209...
h1. Do your work
Now that you have a branch for your task you're ready to do your changes. Get to the Java or JEE perspective and make sure you have the *Git Staging* view opened. It will track the files you change and make them show up in the *Unstaged Changes*. If I change the README.md in my project and save it will instantly get listed in the *Unstaged Changes*:
https://community.jboss.org/servlet/JiveServlet/showImage/38-5239-20953/u... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-5239-209...
h1. Commit and Push
As soon as we're done with all our coding we're ready to commit and push. When we started we cloned our Github fork to the local machine. Our local repository is thus originating from the Github fork, it's *Origin* is pointing to this Github repository. Committing and pushing our changes to this fork is done in 2 steps when using the git command line:
> git commit -a -m "[JIRA-XXXX] corrected readme"
> git push origin my-topic-branch
In EGit things are even more handy. it's mostly a single click experience:
PIck the unstaged files that you want to commit and drag and drop them to the *Staged Changes*. Then provide some commit message and you're ready to go:
https://community.jboss.org/servlet/JiveServlet/showImage/38-5239-20955/s... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-5239-209...
Hit *Commit and Push*:
https://community.jboss.org/servlet/JiveServlet/showImage/38-5239-20956/c... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-5239-209...
EGit will commit your changes to your topic branch and push it to its *origin*, the fork on Github. The topic branch only exists on the local machine, pushing it to Github will thus create a new branch in this remote repository. EGit will show you that in the upcoming dialog:
https://community.jboss.org/servlet/JiveServlet/downloadImage/38-5239-209... (https://community.jboss.org/servlet/JiveServlet/showImage/38-5239-20961/p...)
h1. Oh, my change was incomplete
If I now discover that I forgot to do some modifications I could easily add another commit and push it as I just did before. The commit history would then show 2 distinct commits that tackle the very same topic though. I personally prefer to ammend in these cases. I could alternatively merge these 2 commits into a single one (by rebasing). I personally prefer to amend since this keeps me focused, I wont have to rebase once I'm ready to merge.
Let us do the change we had forgotten and amend it. On the command line this would look like this:
> git commit -a --amend
In Eclipse I'll proceed as shown before. I change my files, drag them from unstaged to staged and tell EGit to amend by htting *Amend Previous Commit*:
https://community.jboss.org/servlet/JiveServlet/downloadImage/38-5239-209... (https://community.jboss.org/servlet/JiveServlet/showImage/38-5239-20962/a...)
When hitting *Amend Previous Commit* the previous commit message shows up in the message area.
Also Notice the warning that the Git Staging view is issuing. It tells you that your current commit was already pushed to a remote branch. It tells you that pushing will most likely fail if done to the very same remote:
https://community.jboss.org/servlet/JiveServlet/showImage/38-5239-20973/a... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-5239-209...
h1. Doors shut, push rejected?
If I now hit *Commit and Push* committing will succeed but pushing wont. It'll tell me that it is rejected, that it is *non-fast-forward*:
https://community.jboss.org/servlet/JiveServlet/showImage/38-5239-20963/r... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-5239-209...
Amending modifies an existing commit. I had pushed this commit to my fork already. The new push sends a modifed version of the very same commit. The remote therefore rejects it and tells me that I pushed a conflicting change, a change that is non-fast-forward.
h1. Use the force, Luke!
To solve this conflict I'll use the force. I changed my commit on purpose, I wanted to add some missing pieces. I therefore insist on pushing my change and tell git to *force my push*. Using the command line one does:
> git push -f origin my-topic-branch
The Git Staging view unfortunately doesn't offer this option yet. We should consider ways of pushing force in the staging view in order to keep the workflow smooth.
To currently push force in EGit you have to get to the full fledged push action that is accessible in the *project explorer*: *Team -> Remote -> Push...*
*https://community.jboss.org/servlet/JiveServlet/showImage/38-5239-20964/team-remote-push.png https://community.jboss.org/servlet/JiveServlet/downloadImage/38-5239-209...
In the upcoming wizard you can then choose the remote repository you want to push to. I therefore pick *origin*, which points to Github fork:
https://community.jboss.org/servlet/JiveServlet/showImage/38-5239-20965/p... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-5239-209...
On the next wizard page I then pick the branch I want to push:
https://community.jboss.org/servlet/JiveServlet/showImage/38-5239-20966/p... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-5239-209...
EGit will then pick the existing (remote) topic branch as destination:
https://community.jboss.org/servlet/JiveServlet/showImage/38-5239-20967/p... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-5239-209...
I can then add this source-destination pair to the refspecs that EGit will push:
https://community.jboss.org/servlet/JiveServlet/showImage/38-5239-20968/p... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-5239-209...
EGit then lists it in the push specifications and allows me to further further fine-tune it:
https://community.jboss.org/servlet/JiveServlet/showImage/38-5239-20969/p... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-5239-209...
I can then tell it push force in the *Force Update* column:
https://community.jboss.org/servlet/JiveServlet/showImage/38-5239-20970/p... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-5239-209...
Once I executed all these steps I'm ready to go and can hit *Finish*, telling EGit to push force my local topic branch.
https://community.jboss.org/servlet/JiveServlet/showImage/38-5239-20971/p... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-5239-209...
In my opinion the wizard we just used - especially the 2nd page where you build a push-force refspec is far too complicated. It's not inutitive enough, especially for newbie users. The git command line is so much simpler. We should seriously think about providing a simpler version which fits the vast majority of the usecases. A very simple first improvement is to have the current branch preselected (in Source ref).
h1. Let there be merge
Now that we pushed our topic branch to Github we're ready to file a pull request and let the review happen. Github contributed Mylin connectors for EGit/Github. I honestly didn't find out how to file pull-requests though. Looking into their code this must be possible, the functionality is there, but I didnt get how to use the UI to file those. That's another area where I'd love to enhance. IMHO it should be possible to file pull requests right from Eclipse. I'm not even sure if we really should require Mylyn. Mylyn is very nice, no doubt about But at times you just want to create the PR and dont want to edit it. Having it prefilled with the commit-message is fairly sufficient.
For the sake of breveity I wont get into details how one would file a pull request on github, I'll just assume we filed it on github.
https://community.jboss.org/servlet/JiveServlet/showImage/38-5239-20974/p... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-5239-209...
I then get back to the *Git Repository Exploring* perspective and merge master with my topics branch. I double click my *master* branch and make sure it's checked out. I then pick *Merge...* from its context menu:
https://community.jboss.org/servlet/JiveServlet/showImage/38-5239-20975/m... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-5239-209...
...and tell the wizard to merge my master with my topic branch.
https://community.jboss.org/servlet/JiveServlet/showImage/38-5239-20976/m... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-5239-209...
Once the merge is done I can push it to master by using the push outlined above. This time I'll just push to the master repo, too and publish my code the official repo. My task is finished, I merged my topics branch (my work) into master and made it official JBoss Tools code. I can now kill my topics local and remote branches.
h1. Egit, what about new clothes?
In the above I spotted several steps that could get enhanced to get your EGit journey perfect. EGit has all you need, it's became pretty stable and mature over the years. I'd love to gather those ideas and wishes and get your feedback!
h2. Push Force
A first shortcoming I spotted is that you cannot push force from git staging view. Maybe that's a good practice since push force should stay the exception, it should not become the general rule. It should not be too easy since there's too much you can do wrong and loose all your work.Nevertheless I'd love to allow this common practice when correcting pull-request (in github or EGit gerrit) in the *Git Staging* view.
* What about displaying a *force update* checkbox when the *already pushed* warning is displayed?
https://community.jboss.org/servlet/JiveServlet/showImage/38-5239-20977/a... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-5239-209...
* Alternatively we could ask the user if he wants to push force in something similar to this:
https://community.jboss.org/servlet/JiveServlet/showImage/38-5239-20978/w... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-5239-209...
h2. Push dialog
IMHO the dialog that pops up when you want to push to some remote could get quite some love.
* First of all it pops up with no default being filled out. Having the current branch selected as source and the corresponding remote on origin (that gets selected as soon as you choose your source) would spare you 1 first unneeded click:
https://community.jboss.org/servlet/JiveServlet/showImage/38-5239-20980/p... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-5239-209...
* Secondly the dialog is far too complex and not intuitive enough for the newbie user. There are far too many nots and bolts for the default usecase. We could offer the simple 1:1 push with a force option in a single line and hide the advanced option behind an *Advanced >>* button:
https://community.jboss.org/servlet/JiveServlet/showImage/38-5239-20981/p... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-5239-209...
h1. Github Pull-Request
I might be wrong but it looks very much as if there was no way to create a Github pull request within Eclipse. One has to use hub or get to the website. I'd love to have this in Eclipse so that there's no need to switch app. IMHO we should offer this with or without Mylyn. Maybe we should offer an action in the context menu that opens the Mylyn pull-request editor prefilled with all the relevant informations that I can then just confirm.
h1. Feeback please!
I'd love to get your feedback, get to know what you guys think. Please shout at me, confirm me or comment with your very own ideas. Thanks!
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/community/tools/blog/2013/06/18/how-to-use-ec...]
11 years, 5 months
[jBPM] - jBPM 5.4 web application
by Naju K
Naju K [https://community.jboss.org/people/najumu] created the discussion
"jBPM 5.4 web application"
To view the discussion, visit: https://community.jboss.org/message/823618#823618
--------------------------------------------------------------
I installed jBPM5.4 in my system. I started the engine by *start.demo*, and i could see the processes using *jpm console*, and i have gone through *drools guvnor* process designer.. Following are my doubts.
1. I have installed this BPM in my machine, and created some processes.. please tell me how it is related to a real life projects ??? why most of the jboss documentations ends with drools guvnor process designer ??? ...
Its like "you are installed jBPM in you machine, you are created some sample processes using jbpm console, and you are desinged one process using drools guvnor or eclipse plugin, now you are a jbpm devleper, you are ready to go" ... where to go ? what is next ? how can create a real life application with jbpm ??
Suppose i want create very simple "Leave Approval" web applcation using jBPM .. so
i) I have a start event
ii) i have *User task* "Employee Application", here employee is filling a form and submitting to HR manager
iii) i have a *User task* "HR manger verification", here HR manager verify the application, and he approves the leave
iv) I have an end event
How can i acheive this Process using jBPM ???
2. If i want to create Employee Form and HR Form, using any other UI technology like *JPS or JSF*, how can i do that ??
If am not using any of these UI technologies, jBPM have its own UI tools to create user forms ??
3. *How the flow happens from start event to end event.. ie, programatically what should i do, to move to next task* ??
4. *How can i deploy a jBPM web applcation in jBoss AS 7* ?
5. How can i monitor above process ??
*A small sample web application is more that enough for me, to clear all my doubts*..
And sorry for my language( I am searching *last three days*, for a real life sample jBPM web application :( )..
Thanks in advance
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/823618#823618]
Start a new discussion in jBPM at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 6 months
[jBPM] - Proposed temporary and limited approach to supporting excluded owners
by jemmerling
jemmerling [https://community.jboss.org/people/jemmerling] created the discussion
"Proposed temporary and limited approach to supporting excluded owners"
To view the discussion, visit: https://community.jboss.org/message/646719#646719
--------------------------------------------------------------
I have been looking at way to do the following within jBPM:
Have a node in a process definition be associated with a particular group (or groups), however due to the history of a given process, to exclude some actor(s) who might be members of that group.
Now the WS-HumanTask specification supports something called excluded owners. Here is a snippet from one version of this specification (not certain if it is the latest one):
+"Potential owners of a task are persons who receive the task so that they can claim and complete it. A potential owner becomes the actual owner of a task by explicitly claiming it. Before the task has been claimed, potential owners can influence the progress of the task, for example by changing the priority of the task, adding ad-hoc attachments or comments. All excluded owners are implicitly removed from the set of potential owners. A WS-HumanTask Definition MAY define assignment for this generic human role.+
+Excluded owners are are people who cannot become an actual or potential owner and thus they cannot reserve or start the task. A WS-HumanTask Definition MAY define assignment for this generic human role. "+
Although the jBPM5 schema supports the existence of excluded owners, I have seen no explicit mechanism to support this when developing an application. If there is something I am missing, please point this out.
In the meantime, I can see a way that a developer could add this functionality without the need to directly modify jBPM5, using the following approach. I would like to know whether it is believed this would work. I am not completely comfortable with this for reasons I will give (although these reasons should be more or less obvious):
1.) First, define a new work item parameter (or analogous mechanism) that represents users who will be excluded from the next node. Let's assume we can correctly identify the next node.
2.) Create a class that extends WSHumanTaskHandler. This class will override the executeWorkItem method. This method will populate excluded owners in the people assignments from having inspected the new parameter. It will otherwise be the same as the method it overrides except for this one additional logic step.
3.) Replace the existing Taskorm.xml with a modified version in which the TasksAssignedAsPotentialOwnerByGroup named query (and possibly some similar named queries) is modified so that excluded owners are not able to claim the task.
I believe all the above is feasible because a.) there is nothing to stop the developer from extending WSHumanTaskHandler in the described manner, and using it in the application code and b.) the ORM file is specified in persistence.xml which is a developer-configurable file, so the developer should be at liberty to specify a different file. So all this could be done without "hacking" jBPM directly.
However I am uncomfortable with this approach because the overridden executeWorkItem method as well as the replacement ORM file would be created using a copy-and-paste methodology so that when progressing to a later version of jBPM it would be necessary to modify these to reflect the original logic.
Nevertheless, if there is some intention to support this type of functionality in a future release of jBPM (and assuming I am right to conclude it is not currently supported) this might be a justifiable short-term solution.
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/646719#646719]
Start a new discussion in jBPM at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 6 months
[EJB3] - A question about the transaction?
by Michael Owen
Michael Owen [https://community.jboss.org/people/liverpoolilove] created the discussion
"A question about the transaction?"
To view the discussion, visit: https://community.jboss.org/message/823591#823591
--------------------------------------------------------------
I created an MDB in my project.As follows：
/**
* Message-Driven Bean implementation class for: QueueListenerMDB
*/
@MessageDriven(activationConfig = {
@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
@ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/test") })
@Interceptors(SpringBeanAutowiringInterceptor.class)
public class QueueListenerMDB implements MessageListener {
/**
* Default constructor.
*/
public QueueListenerMDB() {
}
/**
* @see MessageListener#onMessage(Message)
*/
public void onMessage(Message message) {
sendMessage(message);
}
public void sendMessage(Message message) {
try {
if (message instanceof TextMessage) {
System.out.println("Queue: I received a TextMessage at "
+ new Date());
TextMessage msg = (TextMessage) message;
System.out.println("Message is : " + msg.getText());
} else if (message instanceof ObjectMessage) {
System.out.println("Queue: I received an ObjectMessage at "
+ new Date());
ObjectMessage msg = (ObjectMessage) message;
DBTrigger trigger = (DBTrigger) msg.getObject();
triggerService.saveTrigger(trigger);
System.out.println("trigger Details: ");
System.out.println(trigger);
} else {
System.out.println("Not valid message for this Queue MDB");
}
} catch (JMSException e) {
e.printStackTrace();
}
}
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/823591#823591]
Start a new discussion in EJB3 at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 6 months
[JBoss Web Services] - calling Web Service Method Through wsdl
by Sunil Kunwar
Sunil Kunwar [https://community.jboss.org/people/suniel] created the discussion
"calling Web Service Method Through wsdl"
To view the discussion, visit: https://community.jboss.org/message/823569#823569
--------------------------------------------------------------
I have a web application which calls the web service methods through wsdl. The wsdl url is successfully browsed through web browser but get following exception while calling webservice through web application deployed in jboss server.
Stacktrace:
Org. apache. jasper. servlet. JspServletWrapper. handleJspException (JspServletWrapper.java: 504)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:393)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
root cause
com.sun.xml.ws.client.ClientTransportException: The server sent HTTP status code 403: Forbidden
com.sun.xml.ws.transport.http.client.HttpTransportPipe.checkStatusCode(HttpTransportPipe.java:222)
com.sun.xml.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:179)
com.sun.xml.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:93)
com.sun.xml.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:105)
com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:629)
com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:588)
com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:573)
com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:470)
com.sun.xml.ws.client.Stub.process(Stub.java:319)
com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:157)
com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:109)
Thanks In Advance.
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/823569#823569]
Start a new discussion in JBoss Web Services at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 6 months
