uhm, "bq." is the way to quote in JIRA. It doesn't help reading
mail-replies though. please read "bq. ..." in the mail below as
Mauro's quoted statements.
Stefan
2007/6/5, Stefan Hübner (JIRA) <[EMAIL PROTECTED]>:
[
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
