Correct.
2012/12/8 Max Spring <m2spr...@springdot.org> > I'm merging the activiti-explorer branch to master. > These two artifactItems should not actually be in the POM any more, right? > https://github.com/jenkinsci/**jenkow-plugin/blob/activiti-** > explorer/jenkow-plugin/pom.**xml#L206<https://github.com/jenkinsci/jenkow-plugin/blob/activiti-explorer/jenkow-plugin/pom.xml#L206> > Thanks! > -Max > > > > On 12/07/2012 07:02 PM, Kohsuke Kawaguchi wrote: > >> >> As we discussed in IRC, I moved the activiti explorer part to a separate >> plugin and the activiti-explorer branch in the jenkow-plugin repository is >> now ready to be merged to the trunk. >> >> The merge is virtually conflict free, so I'll let you pick the timing to >> merge this back into the trunk. >> >> On 11/28/2012 12:01 PM, Kohsuke Kawaguchi wrote: >> >>> >>> This is mainly to Max, >>> >>> Over the Thanksgiving break, I hacked more on the Jenkow plugin (in the >>> activiti-explorer branch.) >>> >>> I successfully embedded Activiti Explorer (AE) inside the plugin. You >>> load the plugin, you hit >>> http://localhost:8080/**activiti-explorer/<http://localhost:8080/activiti-explorer/>and >>> you'll see AE embedded within. >>> >>> I've also created database-plugin [1,2] that defines a common >>> abstraction for connecting database (more about this in a separate >>> post.) I've used that in this branch to let the administrator configure >>> the backend database for Activiti. >>> >>> Both the embedded AE and the activiti engine that the Jenkow plugin uses >>> honor this configuration. >>> >>> I've also took a stub at integrating authentication between Jenkins and >>> AE --- if you run AE stand-alone, you'll see that it asks you to login >>> to the app. But in the embedded code, I alter the way AE wires the >>> components to inject our own code that relies on Jenkins to do the >>> authentication. So in effect it creates a single sign-on. >>> >>> The good thing about AE is that it has a contract interface for the >>> identity/authentication service separated from its default >>> implementation, and this is how I was able to swap in Jenkins auth as >>> the backend. >>> >>> However, the bad thing about AE is that the assumption that AE makes >>> about the identity/authentication service is so strict that even if I go >>> all the way of implementing this contract (with Jenkins SecurityRealm as >>> the real backend), we won't be able to avoid some clunkiness --- for >>> example, it has methods like changePassword. >>> >>> So another conceivable approach is to do federation --- we have >>> administrators define uses and groups in AE as it is today, then we let >>> Jenkins users to be linked with AE users, so that once you login to >>> Jenkins, you automatically login as the corresponding linked user in AE. >>> >>> >>> Also, now that I've done it, I think it might make more sense for the >>> embedded AE to be in a separate plugin from Jenkow. Or maybe not, given >>> that presumably it doesn't prevent other AE instances to run elsewhere >>> that connects to the same database. >>> >>> >>> >>> This act of embedding a real web application inside another web >>> application was an interesting work that I really had fun with. >>> >>> Your thoughts would be appreciated. >>> >>> >>> >>> [1] >>> https://wiki.jenkins-ci.org/**display/JENKINS/Database+**Plugin<https://wiki.jenkins-ci.org/display/JENKINS/Database+Plugin> >>> [2] >>> https://github.com/jenkinsci/**database-plugin<https://github.com/jenkinsci/database-plugin> >>> >>> >> >> > -- Kohsuke Kawaguchi
