Re: jBPM Hudson instance
by Thomas Diesler
Hi Len/Jiri,
I moved this to
https://jira.jboss.org/jira/browse/JBPM-1408
As we are moving forward with the product release, this has now become
critical.
cheers
-thomas
Jiri Pechanec wrote:
> Hi Thomas,
>
> I think we need to clarify your request a little bit. Right now we are
> running internal Hudson that can publish build results to the public
> Hudson instance (it does it for jBPM).
>
> But if I understand your request correctly you want us to have a
> publicly accessbile machine (environment) where we start another Hudson
> instance that will be dedicated to just jBPM?
>
> J.
>
> On Tue, 08 Jul 2008 09:46:47 +0200, Thomas Diesler
> <thomas.diesler(a)jboss.com> wrote:
>
>> Hi Len,
>>
>> we made the Hudson setup an integral part of the jBPM project
>>
>> http://jbpm.dyndns.org/jbpmwiki/index.php?title=JBPM3BuildingFromSource#S...
>>
>>
>> It is now a two step process to get the QA environment setup remotely
>> or locally. This is important because it will allow us to go back in
>> time to any given release and recreate the QA environment that was
>> used for that release. Patches can then be applied and verified using
>> the tagged QA environment.
>>
>> Could you please setup a public Hudson instance using the link above?
>>
>> For the username/password combination I prefer:
>>
>> username: hudson
>> password: deadbeefjboss
>>
>> cheers
>> -thomas
>>
>> Len DiMaggio wrote:
>>> You can start with Jirka and me I guess - you want to make the SOA-P
>>> jBPM tests on Hudson public?
>>> -- Len
>>> Thomas Diesler wrote:
>>>> Hi Len,
>>>>
>>>> do you know who I want to talk to about the jBPM Hudson QA?
>>>>
>>>> http://jira.jboss.org/jira/browse/JBPM-1373
>>>>
>>>> cheers
>>>> -thomas
>>>>
>>>>
>>>>
>>>
>>
>
>
>
16 years, 3 months
[Design of JBoss jBPM] - Re: applying the hudson jobs in the sources
by thomas.diesler＠jboss.com
anonymous wrote :
| 0) do you know any docs that explain the schema of the hudson configuration files ? or do you create them through the web user interface configure page and then copy them from the hudson instance to the source repository ?
|
The latter. The copies are then parametrized using ant filters.
anonymous wrote :
| 1) what do we have to get the hudson jobs defined in the sources configured in an existing hudson instance (like our QA lab)
|
Hudson instances should not get modified through the web interface.
| ant hudson-setup
|
run by a QA engineer should be the only way to setup the QA environment for any given version - otherwise the QA is not guarantied to be in sync with the source.
anonymous wrote :
| * can that be applied to a running hudson instance ?
|
| * can those targets be applied to a hudson instance that has other jobs (like in our QA lab) ?
|
| * do you envision an automatic update mechanism that synchronizes the hudson configurations in the sources to the hudson installation ?
|
no, see above
anonymous wrote :
| 2) do you know if it is possible to share this configuration between Bull and JBoss. we would like to have all job configurations in svn, but then Bull and JBoss would each only execute a subset of those configurations on their own QA boxes.
|
ant-hudson setup could be configured to only copy a subset of jobs dependeing on the settings in ant.properties
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167791#4167791
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167791
16 years, 3 months
[Design of JBoss jBPM] - Re: login 'unification'
by kukeltje
Heiko,
Sorry for the kind of rude tone in my comment in Jira, but there are so many changes and things going one without (at least for what it seems public) discussion that it is very hard to follow things and still have a clear overall picture. I sometimes get the impression that people making changes also have no clear picture, a clear picture of jBPM that is. The fact that you ask what the relation is with the identity module to me is an example of this (no offence). Changes like this login config lead to unnecessary discussions, frustrations if changes are discussed upfront.
Ok, now the elaboration.
The identity module can be used to do assignments in the workflow engine. There is a kind of 'expression language' that can be used to decide e.g. who should get a task. The default implementation of this uses the database with users, groups, role etc... so when part of this is in files, we either have to duplicate things, keep them in sync or rewrite the identity module to use files (nah... ). The login-config.xml currently uses the same database as identity module, so things are shared and *unified*.
Using the database instead of files would solve this, so keeping things as they are... regardless of using a .sar for this.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167565#4167565
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167565
16 years, 3 months
[Design of JBoss jBPM] - applying the hudson jobs in the sources
by tom.baeyens＠jboss.com
0) do you know any docs that explain the schema of the hudson configuration files ? or do you create them through the web user interface configure page and then copy them from the hudson instance to the source repository ?
1) what do we have to get the hudson jobs defined in the sources configured in an existing hudson instance (like our QA lab)
i assume the ant.properties.example and the build.xml has something to do with it.
* can that be applied to a running hudson instance ?
* can those targets be applied to a hudson instance that has other jobs (like in our QA lab) ?
* do you envision an automatic update mechanism that synchronizes the hudson configurations in the sources to the hudson installation ?
2) do you know if it is possible to share this configuration between Bull and JBoss. we would like to have all job configurations in svn, but then Bull and JBoss would each only execute a subset of those configurations on their own QA boxes.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167553#4167553
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167553
16 years, 3 months
[Design of JBoss jBPM] - Re: Defining the API Mission
by koen.aers＠jboss.com
"Ed" wrote : Re use of GPD... I'm pretty unhappy with GPD. The code base is not very extensible, and is highly dependent on the XML editor codebase.
I am sorry to hear that you are unhappy with GPD. But as a matter of fact I know its limitations and I am not that happy with it myself.
The current code is indeed very dependent on the XML editor. The reason for this is a combination of history and the initial goal of providing support for the developers to edit the XML file.
As for extensibility, as Matthew and others have shown, it is doable but there are indeed some quirks that have to be overcome. However, the input that came from users that extend the GPD has been very valuable to make this mechanism somewhat better.
"Ed" wrote : I went to the talk by the Eclipse BPMN editor guys at EclipseCon, and was very sold on GMF. The BPMN editor is really slick, and easily extensible. People kept complimenting them on this or that feature, and they kept saying things like "well, it wasn't really a requirement, but all we had to do to implement it was write these 5 lines of code, so we just threw it in." High praise for the framework!
I have looked at the BPMN editor and it is indeed a very nice piece of work. However, its approach has a number of issues that I haven't been able to solve until now:
- serialization of XML compliant to our jPDL XSD
- graphical info serialized in another file or not
- easily integrate with an XML editor to edit the serialized XML
GMF builds on top of EMF and while I have been able to build small prototypes that come close to what we want, I still haven't been able to walk the final mile. I will open up a different topic with some of the results of my research. Maybe some people are able to help out with closing this final gap.
"Ed" wrote : After spending some time with the code, I am even more sold. I would very strongly suggest that Koen look at GMF et al again - it's probably grown up a lot since he checked it out the first time.
I definitely agree with you that GMF has become better in the meantime. I have checked it out again after the last EclipseCon as well. Maybe I am still missing things, but as I stated before I still have problems in making it do what I want it to do.
So after a discussion with Kris Verlaenen (from the Drools team) around the effort to implement a common base for a 'flow' editor we have decided to not use GMF for this (the high dependency of GMF on the very intrusive EMF framework was a real breakpoint for Kris). As a plus, this new effort will be highly focused on extensibility. Anyway, if we have been looking past important things, we are open to suggestions. As already said, I will open a different topic with the ideas and research results that I obtained earlier.
Regards,
Koen
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166915#4166915
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166915
16 years, 3 months