[ 
http://jira.codehaus.org/browse/JBEHAVE-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98345
 ] 

Stefan Hübner commented on JBEHAVE-49:
--------------------------------------

Mauro,

bq. Stefan, a few comments from a cursory look. I have purposefully avoided 
linking the behaviour scope to 'test'.

Oh, maybe I should have asked before altering the plugin to serve my personal 
needs. I was assuming, that behaviours are - in a way - like unit tests. So I 
put them into the src/test/java-folder instinctively. Now I know, my perception 
was misled maybe.

But to stretch that thought a bit - by assuming the behaviours are to be found 
in src/main/java you seem to recommend a multiproject structure, where 
behaviours or stories are placed in parallel modules of the one to be verified. 
So e.g. I have a modul "A" for what I like to write some specs. I would end up 
with a multiproject structure comprising a second modul "A-behaviours" and a 
third "A-stories". Or maybe just two, like "A" and "A-specs"-modules glued 
together by an aggregating multiproject-POM. Is this what you suggest? I could 
happily live with that. Should have known just a bit earlier.

bq. Also, I'm not sure I understand how this proposed patch differs from 
current implementation. It too uses a separate classloader to instantiate the 
behaviours.

I took the approach the surefire-plugin is based on. It doesn't import *any* 
JUnit-specific classes, but instead loads them into a completely isolated 
classloader. Of course this brings some nasty reflection mechanics as a side 
effect, though.

The difference to your implementation is, that the patched plugin doesn't leave 
the classloading hassles to the jbehave-library. Rather it puts the 
jbehave-classes into the same classloader, that serves as the classloader for 
the behaviours to be verified. So jbehave is on the same classpath as the 
behaviours and nowhere else.

I did some experiments with the hellbound example, put it's sources into 
different modules and tried to run the behaviours. The patch worked fine. So I 
was happy with it and thought, you'd find it handy too.

But either way, I'd just like to see a maven plugin that works, since I 
appreciate your effort very much. I do hope seeing the project gaining momentum 
in the near future. To me, a maven plugin is a must though, before I can spread 
the word.

> Maven 2 support
> ---------------
>
>                 Key: JBEHAVE-49
>                 URL: http://jira.codehaus.org/browse/JBEHAVE-49
>             Project: JBehave
>          Issue Type: New Feature
>          Components: Build system
>            Reporter: Mauro Talevi
>         Attachments: jbehave-49-classloader.patch, maven-patch.txt
>
>
> Regardless of feelings about maven vs ant, there is a case for supporting 
> both.
> IMO maven 2 provides a declarative approach that simplifies readability of 
> build system, 
> especially for multicomponent systems.
> Discussions on merits should be on the list.   
> Here I'm attaching an initial spike patch that mavenises build for people to 
> have a look at and get a feel.
> Read README.txt to start off with - need to install cotta jar in the local 
> repo (this is just a temporary step to get build
> working - it can also be configured to be installed automatically or deployed 
> to ibiblio).
> The behaviours still fail to run because of the 
> jbehave.core.util.BehavioursLoader does not provide injection of classloader. 
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply via email to