Eric Lewin | 1 Jun 2007 11:46
Picon

Re: [jbehave-user] Recent changes to JBehave

Hi Elizabeth,

Using the method getSimpleName() is not compatible with jdk 1.4. I do 
not mind, as we are using "JSE 6" but I thought you should be aware of 
the compability issue.

See the line
                buffer.append("a " + arg.getClass().getSimpleName() + " 
containing ");
in both UsingCollectionMatchers and UsingArrayMatchers.

Cheers,
Eric.

Elizabeth Keogh wrote:
>
> - JUnitAdapter now uses behaviours in Behaviours (thanks, Alexandre!)
> - JComboBox is now supported in both editable and non-editable modes 
> (thanks George!)
> - Added collection matchers
> - Added array matchers
>
> Also... remember that bug that I was sure had to be Swing in Linux? I 
> think it was me. So hopefully text typing works in Linux now too (it 
> better, cos I've taken out the PendingException and added it as 
> Runtime). Will verify this when I get to my linux box!
>
> Cheers,
> Liz.
>
(Continue reading)

Elizabeth Keogh | 1 Jun 2007 12:48

Re: Re: [jbehave-user] Recent changes to JBehave


Eric Lewin <eric.lewin-w/qro3bMI4A@public.gmane.org> wrote on 01/06/2007 10:46:31:

> Hi Elizabeth,
>
> Using the method getSimpleName() is not compatible with jdk 1.4. I do
> not mind, as we are using "JSE 6" but I thought you should be aware of
> the compability issue.
>
> See the line
>                 buffer.append("a " + arg.getClass().getSimpleName() + "
> containing ");
> in both UsingCollectionMatchers and UsingArrayMatchers.
>
> Cheers,
> Eric.

Oops! Thank you, Eric. Long names should be fine; will fix.

Cheers,
Liz.

--
Elizabeth Keogh
liz-IFekc9qy6S0WhyVFc8JwjA@public.gmane.org
http://sirenian.livejournal.com
http://jbehave.org
Dan North | 1 Jun 2007 14:27

Re: Re: [jbehave-user] Recent changes to JBehave

Good catch Eric.

I think there are still enough 1.4 projects out there to retain 
compatibility, but I'm open to being persuaded otherwise.

Cheers,
Dan

Eric Lewin wrote:
> Hi Elizabeth,
>
> Using the method getSimpleName() is not compatible with jdk 1.4. I do 
> not mind, as we are using "JSE 6" but I thought you should be aware of 
> the compability issue.
>
> See the line
>                buffer.append("a " + arg.getClass().getSimpleName() + " 
> containing ");
> in both UsingCollectionMatchers and UsingArrayMatchers.
>
> Cheers,
> Eric.
>
> Elizabeth Keogh wrote:
>>
>> - JUnitAdapter now uses behaviours in Behaviours (thanks, Alexandre!)
>> - JComboBox is now supported in both editable and non-editable modes 
>> (thanks George!)
>> - Added collection matchers
>> - Added array matchers
>>
>> Also... remember that bug that I was sure had to be Swing in Linux? I 
>> think it was me. So hopefully text typing works in Linux now too (it 
>> better, cos I've taken out the PendingException and added it as 
>> Runtime). Will verify this when I get to my linux box!
>>
>> Cheers,
>> Liz.
>>
>> -- 
>> Elizabeth Keogh
>> liz@...
>> http://sirenian.livejournal.com
>> http://jbehave.org
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>    http://xircles.codehaus.org/manage_email
>

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

    http://xircles.codehaus.org/manage_email

Stefan Hübner (JIRA | 4 Jun 2007 00:11

[jira] Updated: (JBEHAVE-49) Maven 2 support


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

Stefan Hübner updated JBEHAVE-49:
---------------------------------

    Attachment: jbehave-49-classloader.patch

Dear Mauro and JBehave team,

please find attached patch with a proposed fix for BehaviourRunnerMojo's classloader issue. It works by
completly isolating into an classloader the BehaviourRunner and the behaviours to be verified. That
classloader only knows a project's target/classes, target/test-classes and its dependencies of scope "test".

Hope this helps you, as it helped me.

Cheers
Stefan

PS: Also, I was working on extending your mojos to accept include/exlude patterns for searching for
Behaviour-/Story-classes. That way JBehave's ant tasks and maven plugin would provide similar options
to the user regarding the selection of classes (at least, in the beginning I was confused with those slight differences).
If you're interested, please let me know. I'd be happy to contribute the code.

> 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

Mauro Talevi (JIRA | 4 Jun 2007 09:55

[jira] Commented: (JBEHAVE-49) Maven 2 support


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

Mauro Talevi commented on JBEHAVE-49:
-------------------------------------

Stefan, a few comments from a cursory look. 

I have purposefully avoided linking the behaviour scope to 'test'.  
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'll have a look into more detail during the week.  Thanks.

> 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

Stefan Hübner (JIRA | 5 Jun 2007 01:44

[jira] Commented: (JBEHAVE-49) Maven 2 support


    [
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

Stefan Hübner | 5 Jun 2007 01:52
Gravatar

Re: [jira] Commented: (JBEHAVE-49) Maven 2 support

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) <jira <at> codehaus.org>:
>
>     [
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
>
>
Mauro Talevi (JIRA | 5 Jun 2007 09:14

[jira] Commented: (JBEHAVE-49) Maven 2 support


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

Mauro Talevi commented on JBEHAVE-49:
-------------------------------------

Stefan, these are valid points, worth discussing.  Bringing it to dev list.

> 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

Mauro Talevi | 5 Jun 2007 09:37

Re: Maven 2 support

Bringing discussion to the list:

Stefan Hübner (JIRA) wrote:

> 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.

I personally see behaviours as more along the lines of acceptance testing than unit testing.  So 
rather than a replacement for JUnit, I would see it a replacement for Fit.

That said, some people might want to use BDD as a replacement for TDD.

I would aim to find a configurable way to support both paradigms.

> 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.

I still need to convince myself of the best approach in this regard.   I don't see "hyper-isolation" 
in classloading as necessarily a significant advantage - especially if offset against other cons or 
complications.  The current approach is quite simple and configurable - it takes the libs configured 
in a given maven scope and builds a classloader with them.  I'll give it more thought.

> 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.

Sure - and I appreciate your help greatly.  I've been snowed under of late, but I'm aiming to get 
some work done (have some other patches to apply) and get out a 1.1 release soon.

Cheers

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

    http://xircles.codehaus.org/manage_email

Stefan Hübner | 6 Jun 2007 01:21
Gravatar

Re: Re: Maven 2 support

Hi,

Mauro wrote:
> Bringing discussion to the list:

[SNIP]

> I personally see behaviours as more along the lines of acceptance testing than unit testing.  So
> rather than a replacement for JUnit, I would see it a replacement for Fit.
>
> That said, some people might want to use BDD as a replacement for TDD.
>
> I would aim to find a configurable way to support both paradigms.

So this would boil down to placing behaviours/stories either in
"src/main/java" or "src/test/java" and scoping jbehave either in
compile or test scope.

The switch could be easily supported by a simple boolean configuration
option, I guess. The plugin then would create a classloader upon
either compile scope or test scope classpath elements.

> > 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.
>
> I still need to convince myself of the best approach in this regard.   I don't see "hyper-isolation"
> in classloading as necessarily a significant advantage - especially if offset against other cons or
> complications.  The current approach is quite simple and configurable - it takes the libs configured
> in a given maven scope and builds a classloader with them.  I'll give it more thought.

Fine. I'll those two classloader approaches a try in different scenarios.

> > 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.
>
> Sure - and I appreciate your help greatly.  I've been snowed under of late, but I'm aiming to get
> some work done (have some other patches to apply) and get out a 1.1 release soon.

Since we're talking about Maven2 support, may I also suggest to update
jbehave's parent- and core-poms? The dependencies should be mentioned
properly. This would help developers great deals.

Cheers

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

    http://xircles.codehaus.org/manage_email


Gmane