Recent check-in...

[jwcarman]

All,

I just checked in some changes to the pom.xml files and moved the
HiveMindTestCase into src/test.  Let me know how it looks for you.
All test cases passed for me.  I might try to move stuff around into
the "normal" maven directories, too (src/main/java, etc.)

James

[Henri Yandell]

James has helped me out on Commons projects, so I figure I owe him a
bit of time :) Especially as the below doesn't need much Hivemind
knowledge.

First - complaints about the site:

1) Takes effort to find the svn url for Hivemind. "Project
Information", the Maven default, is never a good way for developers to
find something. The webpage needs a link to the svn page, or a
developer page that links to the svn page and the dev list.

2) Given that - it's not obvious where to file bugs, or where users
should talk. Plus side is that the site navigation is minor, but it's
still a random click away. Replace the project information bit with
the elements inside it at the top level. If that makes sense :)

3) The svn page is for the site. And a bad url at that as it would
check everything out.

4) Which of hivemind1/hivemind2 is the live development. This would be
obvious if the svn instructions point to one, but is often good to say
what the deal is with the 2nd version.

---

On the email below - moving the tests into the test tree makes sense,
and 'mvn clean install' succeeds for me [jdk 1.5 on OS X]. The tests
seem to cause System.out noise - those should be asserts or not there
imo (debugging should be temporary).

---

A couple of further thoughts:

*) If you can (any of you here) - for a minor release it's best to
stagger your activity in small chunks, than waiting for large periods
of time to be available. Continual small levels of activity grow
community activity better than unpredictable and large levels of
activity. So better to set aside a little time in the week. [It's the
other way around for new development I think - so different for 2.0].

*) Activity begats activity. I'm willing to bet that there is a very
odd curve in forums/lists between 1 entry on a thread and N entries.
There's something about a reply that creates a conversation, when the
first email was just fishing. I think it's because the first email
feels like a one-to-one conversation, and when you realize someone
else is reading the email you change how you're approaching the
emails. So the advice there is - a little reply can go a long way.
Those annoying replies with nothing but '+1' in, actually play a
crucial role in the activity of a community.

Thanks for listening :)

Hen

On Fri, May 16, 2008 at 8:23 AM, James Carman
<james@...> wrote:
> All,
>
> I just checked in some changes to the pom.xml files and moved the
> HiveMindTestCase into src/test.  Let me know how it looks for you.
> All test cases passed for me.  I might try to move stuff around into
> the "normal" maven directories, too (src/main/java, etc.)
>
> James
>

[jwcarman]

On Sat, May 17, 2008 at 1:03 PM, Henri Yandell <flamefew@...> wrote:
> James has helped me out on Commons projects, so I figure I owe him a
> bit of time :)

I believe I'm still in the red when it comes to paying you back for
all of your help!  :)

>
> First - complaints about the site:

Are you talking about the current site we've got deployed or the site
that's generated by mvn when you do mvn site?

[Henri Yandell]

On Sat, May 17, 2008 at 3:31 PM, James Carman
<james@...> wrote:
> On Sat, May 17, 2008 at 1:03 PM, Henri Yandell <flamefew@...> wrote:
>
>> First - complaints about the site:
>
> Are you talking about the current site we've got deployed or the site
> that's generated by mvn when you do mvn site?

Current one. It's a great user site - boilerplate right at the top,
very prominent and easy to find download, and I now see the
active/alpha bit in the nav so ignore my comment on not knowing which
version to checkout. The only things really missing for users are:

* That the versions menu is really linking to documentation (or subsites).
* Where to report bugs

There's nothing for developers though. A simple page that links to svn
instructions, jira instructions. Maybe link over to the general ASF
pages on using svn and committing etc etc.

Hen

[Johan Lindquist]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi James,

Builds fine for me too [JDK 1.5 & Ubuntu].

Cheers,

Johan

James Carman wrote:

> All,
>
> I just checked in some changes to the pom.xml files and moved the
> HiveMindTestCase into src/test.  Let me know how it looks for you.
> All test cases passed for me.  I might try to move stuff around into
> the "normal" maven directories, too (src/main/java, etc.)
>
> James
>
>

- --
you too?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIMWnUpHYnED7evioRAkFpAJ4y6JBSYd0NDhfOD32vEwTfE2LD3wCdFGAI
obq+MRZUkTSsDIaRfUBl65Q=
=Ztq8
-----END PGP SIGNATURE-----

[Raffael Herzog-2]

Am Freitag, 16. Mai 2008 17.23:36 schrieb James Carman:
> I just checked in some changes to the pom.xml files and moved the
> HiveMindTestCase into src/test.  Let me know how it looks for you.
> All test cases passed for me.  I might try to move stuff around into
> the "normal" maven directories, too (src/main/java, etc.)

Well, an open question about this is: How is a user supposed to use that
class now? Right, having it in HiveMind's core framework isn't a nice
solution. On the other hand, moving it to src/test makes this class
unusable for other projects, as it won't ever be included in any artifact.

To avoid dependencies on JUnit/EasyMock, it should actually be a separate
project producing a separate artifact, something like hivemind-test, which
users can include as dependency scoped test. Then again, a whole
sub-project for a single class file seems a bit ridiculous. Also, this
would introduce a circular dependency: HiveMind's test cases need
HiveMindTestCase, so hivemind-test would have to be built before
hivemind-framework. However, HiveMindTestCase won't compile if
hivemind-framework isn't built.

I think, keeping HiveMindTestCase in src/main and declaring the dependencies
on JUnit and EasyMock in the scope "test" is the better solution, if users
should be able to use that class in their own tests.

If JUnit and EasyMock are scoped "test", this scope will be included in the
test scope of projects that depend on hivemind-framework with scope "test"
and "runtime". Unfortunately, in 99% of the cases, my hivemind dependency
is scoped "provided", so I still would have to include them manually (if
I'd like to use HiveMindTestCase). I use TestNG anyway, however, and in my
case, unit tests *never* need HiveMind (maybe a few interfaces like Module
from it, but never a running registry), and assuming, that HiveMind works,
this is what EasyMock is for ... ;)

This throws us back at the question: Is there any need to provide
HiveMindTestCase to the user at all? Tests that need a running HiveMind
registry are integration tests, not unit tests, so users should have no
need for that class.

For a table of which scope translates to which scope in transitive
dependencies, see here:
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope

Cheers,
   Raffi

--
The difference between theory and practice is that in theory, there is
no difference, but in practice, there is.

herzog@... · Jabber: herzog@...
PGP Key 0x5FFDB5DB5D1FF5F4 · http://keyserver.pgp.com

[jwcarman]

It is included in an artifact.  Check out hivemind-lib.  It uses it.

On Mon, May 19, 2008 at 8:50 AM, Raffael Herzog <herzog@...> wrote:

> Am Freitag, 16. Mai 2008 17.23:36 schrieb James Carman:
>> I just checked in some changes to the pom.xml files and moved the
>> HiveMindTestCase into src/test.  Let me know how it looks for you.
>> All test cases passed for me.  I might try to move stuff around into
>> the "normal" maven directories, too (src/main/java, etc.)
>
> Well, an open question about this is: How is a user supposed to use that
> class now? Right, having it in HiveMind's core framework isn't a nice
> solution. On the other hand, moving it to src/test makes this class
> unusable for other projects, as it won't ever be included in any artifact.
>
> To avoid dependencies on JUnit/EasyMock, it should actually be a separate
> project producing a separate artifact, something like hivemind-test, which
> users can include as dependency scoped test. Then again, a whole
> sub-project for a single class file seems a bit ridiculous. Also, this
> would introduce a circular dependency: HiveMind's test cases need
> HiveMindTestCase, so hivemind-test would have to be built before
> hivemind-framework. However, HiveMindTestCase won't compile if
> hivemind-framework isn't built.
>
> I think, keeping HiveMindTestCase in src/main and declaring the dependencies
> on JUnit and EasyMock in the scope "test" is the better solution, if users
> should be able to use that class in their own tests.
>
> If JUnit and EasyMock are scoped "test", this scope will be included in the
> test scope of projects that depend on hivemind-framework with scope "test"
> and "runtime". Unfortunately, in 99% of the cases, my hivemind dependency
> is scoped "provided", so I still would have to include them manually (if
> I'd like to use HiveMindTestCase). I use TestNG anyway, however, and in my
> case, unit tests *never* need HiveMind (maybe a few interfaces like Module
> from it, but never a running registry), and assuming, that HiveMind works,
> this is what EasyMock is for ... ;)
>
> This throws us back at the question: Is there any need to provide
> HiveMindTestCase to the user at all? Tests that need a running HiveMind
> registry are integration tests, not unit tests, so users should have no
> need for that class.
>
> For a table of which scope translates to which scope in transitive
> dependencies, see here:
> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
>
> Cheers,
>   Raffi
>
> --
> The difference between theory and practice is that in theory, there is
> no difference, but in practice, there is.
>
> herzog@... · Jabber: herzog@...
> PGP Key 0x5FFDB5DB5D1FF5F4 · http://keyserver.pgp.com
>

[Johan Lindquist]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Also check out the discussion of how this came about here [1]

Cheers,

Johan

[1] https://issues.apache.org/jira/browse/HIVEMIND-173

James Carman wrote:

> It is included in an artifact.  Check out hivemind-lib.  It uses it.
>
> On Mon, May 19, 2008 at 8:50 AM, Raffael Herzog <herzog@...> wrote:
>> Am Freitag, 16. Mai 2008 17.23:36 schrieb James Carman:
>>> I just checked in some changes to the pom.xml files and moved the
>>> HiveMindTestCase into src/test.  Let me know how it looks for you.
>>> All test cases passed for me.  I might try to move stuff around into
>>> the "normal" maven directories, too (src/main/java, etc.)
>> Well, an open question about this is: How is a user supposed to use that
>> class now? Right, having it in HiveMind's core framework isn't a nice
>> solution. On the other hand, moving it to src/test makes this class
>> unusable for other projects, as it won't ever be included in any artifact.
>>
>> To avoid dependencies on JUnit/EasyMock, it should actually be a separate
>> project producing a separate artifact, something like hivemind-test, which
>> users can include as dependency scoped test. Then again, a whole
>> sub-project for a single class file seems a bit ridiculous. Also, this
>> would introduce a circular dependency: HiveMind's test cases need
>> HiveMindTestCase, so hivemind-test would have to be built before
>> hivemind-framework. However, HiveMindTestCase won't compile if
>> hivemind-framework isn't built.
>>
>> I think, keeping HiveMindTestCase in src/main and declaring the dependencies
>> on JUnit and EasyMock in the scope "test" is the better solution, if users
>> should be able to use that class in their own tests.
>>
>> If JUnit and EasyMock are scoped "test", this scope will be included in the
>> test scope of projects that depend on hivemind-framework with scope "test"
>> and "runtime". Unfortunately, in 99% of the cases, my hivemind dependency
>> is scoped "provided", so I still would have to include them manually (if
>> I'd like to use HiveMindTestCase). I use TestNG anyway, however, and in my
>> case, unit tests *never* need HiveMind (maybe a few interfaces like Module
>> from it, but never a running registry), and assuming, that HiveMind works,
>> this is what EasyMock is for ... ;)
>>
>> This throws us back at the question: Is there any need to provide
>> HiveMindTestCase to the user at all? Tests that need a running HiveMind
>> registry are integration tests, not unit tests, so users should have no
>> need for that class.
>>
>> For a table of which scope translates to which scope in transitive
>> dependencies, see here:
>> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
>>
>> Cheers,
>>   Raffi
>>
>> --
>> The difference between theory and practice is that in theory, there is
>> no difference, but in practice, there is.
>>
>> herzog@... · Jabber: herzog@...
>> PGP Key 0x5FFDB5DB5D1FF5F4 · http://keyserver.pgp.com
>>
>
>

- --
you too?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIMXtLpHYnED7evioRAsykAKCRuGxs+Bq9oBX637Ri2ztm5yockACcC7ku
k0+OzeDLX3yoQ0BqwKV9M+A=
=ples
-----END PGP SIGNATURE-----

[Raffael Herzog-2]

Am Montag, 19. Mai 2008 14.54:26 schrieb James Carman:
> It is included in an artifact.  Check out hivemind-lib.  It uses it.

Oops, didn't see that you create an additional JAR in the build section. ;)
OK, that seems like to most elegant solution (still a bit "hackish",
though). I still leave this one open, however:

> On Mon, May 19, 2008 at 8:50 AM, Raffael Herzog <herzog@...> wrote:
[...]
> > Is there any need to provide
> > HiveMindTestCase to the user at all? Tests that need a running HiveMind
> > registry are integration tests, not unit tests, so users should have no
> > need for that class.

Cheers,
   Raffi

--
The difference between theory and practice is that in theory, there is
no difference, but in practice, there is.

herzog@... · Jabber: herzog@...
PGP Key 0x5FFDB5DB5D1FF5F4 · http://keyserver.pgp.com

[jwcarman]

On Mon, May 19, 2008 at 9:08 AM, Raffael Herzog <herzog@...> wrote:
> Am Montag, 19. Mai 2008 14.54:26 schrieb James Carman:
>> It is included in an artifact.  Check out hivemind-lib.  It uses it.
>
> Oops, didn't see that you create an additional JAR in the build section. ;)
> OK, that seems like to most elegant solution (still a bit "hackish",
> though). I still leave this one open, however:

As I understand it, this is the Maven "way" to expose test classes to
other projects, so that's why I did it this way.