project naming standards

[Krzysztof Koźmic]

I think it was discussed some time ago, but I can't find that thread.

Did we set on a consistent naming standard for out projects files/ folder?
Currently each project has its own structure.

If we did, please point me to the thread where we did.

If not, here's my proposition I would like to discuss.

Provided we have project "Castle.Foo" here's my suggested structure of
src folder

src\
Castle.Foo-vs2008.sln
Castle.Foo-vs2010.sln //eventually
Castle.Foo-Silverlight.sln
Foo\
Bar.cs
Baz.cs
Foo.csproj
Foo-Silverlight.csproj
Foo.Tests\
BarTestCase.cs
BazTestCase.cs
Foo.Tests.csproj
Foo.Tests-Silverlight.csproj

I would like to point out that it would be nice to set on a common
naming suffix for test fixtures.
From a very quick look I can see we have at least three at use:
1. FooTests.cs
2. FooFixture.cs
3. FooTestFixture.cs

Same goes for test methods:

1. Some_are_named_like_this()
2. SomeLikeThis()
3. AndSome_likeThis()

I'm not saying let's stop what we're all doing and go rename all the
code we have, but let's be consistent with the new work we're doing, and
adjust non-conforming code when we find a spare moment.

Krzysztof

[Jonathon Rossi]

Inline.

While we are on naming/coding conventions. I would like to bring up the "usings grouped and each group separated by a new line" comment in our standards (http://www.castleproject.org/community/codingstandards.html). I don't know of any project that has a new line between the groups, so I think we should remove this from our standards; I don't think it helps anyway.

2009/11/17 Krzysztof Koźmic <krzyszto...@gmail.com>

I think it was discussed some time ago, but I can't find that thread.

Did we set on a consistent naming standard for out projects files/ folder?
Currently each project has its own structure.

I didn't think that the structure was that different across projects.
 

If we did, please point me to the thread where we did.

If not, here's my proposition I would like to discuss.

Provided we have project "Castle.Foo" here's my suggested structure of
src folder

src\
   Castle.Foo-vs2008.sln
   Castle.Foo-vs2010.sln //eventually
   Castle.Foo-Silverlight.sln
   Foo\
      Bar.cs
      Baz.cs
      Foo.csproj
      Foo-Silverlight.csproj
   Foo.Tests\
      BarTestCase.cs
      BazTestCase.cs
      Foo.Tests.csproj
      Foo.Tests-Silverlight.csproj

Most, if not all our csproj files have the full assembly name much closer to the solution name.
 

I would like to point out that it would be nice to set on a common
naming suffix for test fixtures.
 From a very quick look I can see we have at least three at use:
1. FooTests.cs
2. FooFixture.cs
3. FooTestFixture.cs

You missed the one that is most common, FooTestCase.cs. The majority of files are named *TestCase.cs (I think followed by *Tests.cs), so we should continue to follow the TestCase convention.
 

Same goes for test methods:

1. Some_are_named_like_this()
2. SomeLikeThis()
3. AndSome_likeThis()

AFAIK the majority of tests are using upper camel case.

I'm not saying let's stop what we're all doing and go rename all the
code we have, but let's be consistent with the new work we're doing, and
adjust non-conforming code when we find a spare moment.

Yes. Once we have these confirmed we should add them to the coding standards page.
 

Krzysztof

--

You received this message because you are subscribed to the Google Groups "Castle Project Development List" group.
To post to this group, send email to castle-pro...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=.

--
Jono

[Krzysztof Koźmic]

Jonathon Rossi wrote:

Inline

Inline.

While we are on naming/coding conventions. I would like to bring up the "usings grouped and each group separated by a new line" comment in our standards (http://www.castleproject.org/community/codingstandards.html). I don't know of any project that has a new line between the groups, so I think we should remove this from our standards; I don't think it helps anyway.

I actually do use it.. or at least I started recently, after I found out about it, and updated our ReSharper coding settings file to obey it, but I agree, we might ditch it if no one opposes. I'm +1 for that

2009/11/17 Krzysztof Ko�mic <krzyszto...@gmail.com>

I think it was discussed some time ago, but I can't find that thread.

Did we set on a consistent naming standard for out projects files/ folder?
Currently each project has its own structure.

I didn't think that the structure was that different across projects.

ďż˝

If we did, please point me to the thread where we did.

If not, here's my proposition I would like to discuss.

Provided we have project "Castle.Foo" here's my suggested structure of
src folder

src\

� �Castle.Foo-vs2008.sln
� �Castle.Foo-vs2010.sln //eventually
� �Castle.Foo-Silverlight.sln
� �Foo\
ďż˝ ďż˝ ďż˝ Bar.cs
ďż˝ ďż˝ ďż˝ Baz.cs
ďż˝ ďż˝ ďż˝ Foo.csproj
ďż˝ ďż˝ ďż˝ Foo-Silverlight.csproj
� �Foo.Tests\
ďż˝ ďż˝ ďż˝ BarTestCase.cs
ďż˝ ďż˝ ďż˝ BazTestCase.cs
ďż˝ ďż˝ ďż˝ Foo.Tests.csproj
ďż˝ ďż˝ ďż˝ Foo.Tests-Silverlight.csproj

Most, if not all our csproj files have the full assembly name much closer to the solution name.

I was actually suggesting this to avoid lengthy paths, but ok. I'm +1 for naming Folders and .scproj files the full assembly name of the project.

ďż˝

I would like to point out that it would be nice to set on a common
naming suffix for test fixtures.

�From a very quick look I can see we have at least three at use:

1. FooTests.cs
2. FooFixture.cs
3. FooTestFixture.cs

4. FooTestCase.cs

You missed the one that is most common, FooTestCase.cs. The majority of files are named *TestCase.cs (I think followed by *Tests.cs), so we should continue to follow the TestCase convention.

Lol, yeah, I put it in suggested structure above but forgot to list it here. So I'm +1 for four.

ďż˝

Same goes for test methods:

1. Some_are_named_like_this()
2. SomeLikeThis()
3. AndSome_likeThis()

AFAIK the majority of tests are using upper camel case.

Actually here I'm +1 for 1 as I find it MUCH more readable.

I'm not saying let's stop what we're all doing and go rename all the
code we have, but let's be consistent with the new work we're doing, and
adjust non-conforming code when we find a spare moment.

Yes. Once we have these confirmed we should add them to the coding standards page.

agreed.

ďż˝

Krzysztof

--

You received this message because you are subscribed to the Google Groups "Castle Project Development List" group.
To post to this group, send email to castle-pro...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=.

[James Curran]

I hust joined another open source projefct and we're discussing naming
standards there too. For unit tests they choose:

MethodName_StateUnderTest_ExpectedBehavior()

for example:
CompareTo_Null_ThrowsException
CompareTo_NullDateTimeZone_UsesSystemTime
Division_ByZero_ReturnsInfinityInsteadOfThrowingAnException

if the Expected Behavior is just "_Works: it can be omitted:
CompareTo_WithInstant
CompareTo_WithDateTime
CompareTo_WithLong


2009/11/17 Krzysztof Koźmic <krzyszto...@gmail.com>:

> Jonathon Rossi wrote:
>
> Inline
>
> Inline.
>
> While we are on naming/coding conventions. I would like to bring up the
> "usings grouped and each group separated by a new line" comment in our
> standards (http://www.castleproject.org/community/codingstandards.html). I
> don't know of any project that has a new line between the groups, so I think
> we should remove this from our standards; I don't think it helps anyway.
>
> I actually do use it.. or at least I started recently, after I found out
> about it, and updated our ReSharper coding settings file to obey it, but I
> agree, we might ditch it if no one opposes. I'm +1 for that
>

> 2009/11/17 Krzysztof Koźmic <krzyszto...@gmail.com>

>>
>> I think it was discussed some time ago, but I can't find that thread.
>>
>> Did we set on a consistent naming standard for out projects files/ folder?
>> Currently each project has its own structure.
>
> I didn't think that the structure was that different across projects.
>
>>

>> If we did, please point me to the thread where we did.
>>
>> If not, here's my proposition I would like to discuss.
>>
>> Provided we have project "Castle.Foo" here's my suggested structure of
>> src folder
>>
>> src\

>>    Castle.Foo-vs2008.sln
>>    Castle.Foo-vs2010.sln //eventually
>>    Castle.Foo-Silverlight.sln
>>    Foo\
>>       Bar.cs
>>       Baz.cs
>>       Foo.csproj
>>       Foo-Silverlight.csproj
>>    Foo.Tests\
>>       BarTestCase.cs
>>       BazTestCase.cs
>>       Foo.Tests.csproj

>>       Foo.Tests-Silverlight.csproj
>
> Most, if not all our csproj files have the full assembly name much closer to
> the solution name.
>
> I was actually suggesting this to avoid lengthy paths, but ok. I'm +1 for
> naming Folders and .scproj files the full assembly name of the project.
>
>
>>

>> I would like to point out that it would be nice to set on a common
>> naming suffix for test fixtures.

>>  From a very quick look I can see we have at least three at use:
>> 1. FooTests.cs
>> 2. FooFixture.cs
>> 3. FooTestFixture.cs
>
> 4. FooTestCase.cs
>
> You missed the one that is most common, FooTestCase.cs. The majority of
> files are named *TestCase.cs (I think followed by *Tests.cs), so we should
> continue to follow the TestCase convention.
>
> Lol, yeah, I put it in suggested structure above but forgot to list it here.
> So I'm +1 for four.
>
>
>>

>> Same goes for test methods:
>>
>> 1. Some_are_named_like_this()
>> 2. SomeLikeThis()
>> 3. AndSome_likeThis()
>
> AFAIK the majority of tests are using upper camel case.
>
> Actually here I'm +1 for 1 as I find it MUCH more readable.
>
>> I'm not saying let's stop what we're all doing and go rename all the
>> code we have, but let's be consistent with the new work we're doing, and
>> adjust non-conforming code when we find a spare moment.
>
> Yes. Once we have these confirmed we should add them to the coding standards
> page.
>
> agreed.
>
>
>>

>> Krzysztof
>>
>> --
>>
>> You received this message because you are subscribed to the Google Groups
>> "Castle Project Development List" group.
>> To post to this group, send email to
>> castle-pro...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/castle-project-devel?hl=.
>>
>>
>
>
>
> --
> Jono
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Castle Project Development List" group.
> To post to this group, send email to castle-pro...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/castle-project-devel?hl=.
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Castle Project Development List" group.
> To post to this group, send email to castle-pro...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/castle-project-devel?hl=.
>



--

Truth,
James

[Krzysztof Koźmic (2)]

@James,
I don't like it.
It has nice division into three parts, but you don't always want this,
and this rigidity brings more headaches than advantages IMO.
You don't always test a single method, for example in DynamicProxy
most tests don't test single method.

But what you suggested, is basically an option 3 on my list, so I take
it as you're +1 for option 3, is that right?

Krzysztof

On 17 Lis, 09:21, James Curran <james.cur...@gmail.com> wrote:
> I hust joined another open source projefct and we're discussing naming
> standards there too. For unit tests they choose:
>
> MethodName_StateUnderTest_ExpectedBehavior()
>
> for example:
> CompareTo_Null_ThrowsException
> CompareTo_NullDateTimeZone_UsesSystemTime
> Division_ByZero_ReturnsInfinityInsteadOfThrowingAnException
>
> if the Expected Behavior is just "_Works: it can be omitted:
> CompareTo_WithInstant
> CompareTo_WithDateTime
> CompareTo_WithLong
>

> 2009/11/17 Krzysztof Koźmic <krzysztof.koz...@gmail.com>:

>
>
>
> > Jonathon Rossi wrote:
>
> > Inline
>
> > Inline.
>
> > While we are on naming/coding conventions. I would like to bring up the
> > "usings grouped and each group separated by a new line" comment in our
> > standards (http://www.castleproject.org/community/codingstandards.html). I
> > don't know of any project that has a new line between the groups, so I think
> > we should remove this from our standards; I don't think it helps anyway.
>
> > I actually do use it.. or at least I started recently, after I found out
> > about it, and updated our ReSharper coding settings file to obey it, but I
> > agree, we might ditch it if no one opposes. I'm +1 for that
>

> > 2009/11/17 Krzysztof Koźmic <krzysztof.koz...@gmail.com>

[John Simons]

+1 to remove newline grouping in namespace

+1 for naming Folders and .scproj files the full assembly name of the project.

+1 for James convention to name test methods, @Krzysztof this convention comes from "The art of unit testing"

+1 for "Tests" naming suffix for test fixtures

And I would also like to vote to abolish naming variables starting with underscore

 
Cheers John

---

Win 1 of 4 Sony home entertainment packs thanks to Yahoo!7. Enter now.

[Krzysztof Koźmic]

John Simons wrote:

+1 to remove newline grouping in namespace

+1 for�naming Folders and .scproj files the full assembly name of the project.

+1 for James convention to name test methods, @Krzysztof this convention comes from "The art of unit testing"

I know it does, which does not make it the best choice in our scenario.

+1 for "Tests"�naming suffix for test fixtures

And I would also like to vote to abolish naming variables starting with underscore

We don't name variables with underscores. There are some places that do have that, but it's an old code.
Both Castle naming standards and resharper file contain this rule, which I'm of course +1 for.

Krzysztof

ďż˝
Cheers John

On 17/11/2009, at 11:29 AM, Krzysztof Ko�mic (2) <krzy...@kozmic.pl> wrote:

@James,
I don't like it.
It has nice division into three parts, but you don't always want this,
and this rigidity brings more headaches than advantages IMO.

You don't always test a single method, for example �in DynamicProxy

most tests don't test single method.

But what you suggested, is basically an option 3 on my list, so I take
it as you're +1 for option 3, is that right?

Krzysztof

On 17 Lis, 09:21, James Curran <james.cur...@gmail.com> wrote:

I hust joined another open source projefct and we're discussing naming

standards there too. For unit tests they choose:

MethodName_StateUnderTest_ExpectedBehavior()

for example:

CompareTo_Null_ThrowsException

CompareTo_NullDateTimeZone_UsesSystemTime

Division_ByZero_ReturnsInfinityInsteadOfThrowingAnException

if the Expected Behavior is just "_Works: it can be omitted:

CompareTo_WithInstant

CompareTo_WithDateTime

CompareTo_WithLong

2009/11/17 Krzysztof Ko�mic <krzysztof.koz...@gmail.com>:

Jonathon Rossi wrote:

Inline

Inline.

While we are on naming/coding conventions. I would like to bring up the

"usings grouped and each group separated by a new line" comment in our

standards (http://www.castleproject.org/community/codingstandards.html). I

don't know of any project that has a new line between the groups, so I think

we should remove this from our standards; I don't think it helps anyway.

I actually do use it.. or at least I started recently, after I found out

about it, and updated our ReSharper coding settings file to obey it, but I

agree, we might ditch it if no one opposes. I'm +1 for that

2009/11/17 Krzysztof Ko�mic <krzysztof.koz...@gmail.com>

I think it was discussed some time ago, but I can't find that thread.

Did we set on a consistent naming standard for out projects files/ folder?

Currently each project has its own structure.

I didn't think that the structure was that different across projects.

If we did, please point me to the thread where we did.

If not, here's my proposition I would like to discuss.

Provided we have project "Castle.Foo" here's my suggested structure of

src folder

src\

� �Castle.Foo-vs2008.sln

� �Castle.Foo-vs2010.sln //eventually

� �Castle.Foo-Silverlight.sln

� �Foo\

ďż˝ ďż˝ ďż˝ Bar.cs

ďż˝ ďż˝ ďż˝ Baz.cs

ďż˝ ďż˝ ďż˝ Foo.csproj

ďż˝ ďż˝ ďż˝ Foo-Silverlight.csproj

� �Foo.Tests\

ďż˝ ďż˝ ďż˝ BarTestCase.cs

ďż˝ ďż˝ ďż˝ BazTestCase.cs

ďż˝ ďż˝ ďż˝ Foo.Tests.csproj

ďż˝ ďż˝ ďż˝ Foo.Tests-Silverlight.csproj

Most, if not all our csproj files have the full assembly name much closer to

the solution name.

I was actually suggesting this to avoid lengthy paths, but ok. I'm +1 for

naming Folders and .scproj files the full assembly name of the project.

I would like to point out that it would be nice to set on a common

naming suffix for test fixtures.

�From a very quick look I can see we have at least three at use:

ďż˝ ďż˝ James

--

You received this message because you are subscribed to the Google Groups "Castle Project Development List" group.
To post to this group, send email to castle-pro...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=.

---

Win 1 of 4 Sony home entertainment packs thanks to Yahoo!7. Enter now.

--

[Krzysztof Koźmic (2)]

I created a webpage in my personal Wiki (as Castle Confluence didn't
let me) where I wrote this down (http://wiki.kozmic.pl/Dynamic%20Proxy
%20Documentation.Castle-project-structure-standards.ashx), with few
changes. There are still some parts missing so please fill in the
blanks. Specifically.

- What's the purpose of the default.build and Castle.Foo.build files
that we have in each folder/subfolder - what's the distinction between
them?
- What are we ultimately gonna do about generation/not-generation of
assemblyinfo.cs?
- I assumed we're gonna have NAnt and NUnit if common files and
reference them in each project.
- I introduced a division between lib (where dependencies needed by
the project itself are to be kept) and tls (where dependencies needed
for project development are to be kept. I would like to have NAnt and
NUnit in that folder, but I'm not sure how well using svn:externals
here would play out).
- To mitigate confusion between various runtimes that we support I
suggested using standard postfixes for runtimes (instead of VS
versions) to discriminate between them. I also suggest we keep just
one mother version (for .NET 3.5) of the solution and generate all
other from it, with a tool that Julian Birch is developing for that
purpose. This way we don't have the issue of different versions not
being in sync with each other.
- I'm looking for feedback and discussion on this. Please edit the
wiki and expand lacking descriptions there. Once we sort out issues
with Confluence we'll move it there. If I missed something (which I'm
sure I did) please add missing pieces to the wiki.

Krzysztof

On 18 Lis, 08:04, Krzysztof Koźmic <krzysztof.koz...@gmail.com> wrote:
> John Simons wrote:
> > +1 to remove newline grouping in namespace

> > +1 for naming Folders and .scproj files the full assembly name of the
> > project.

> > +1 for James convention to name test methods, @Krzysztof this
> > convention comes from "The art of unit testing"
>

> I know it does, which does not make it the best choice in our scenario.> +1 for "Tests" naming suffix for test fixtures

>
> > And I would also like to vote to abolish naming variables starting
> > with underscore
>
> We don't name variables with underscores. There are some places that do
> have that, but it's an old code.
> Both Castle naming standards and resharper file contain this rule, which
> I'm of course +1 for.
>
> Krzysztof
>
>
>

> > Cheers John
>
> > On 17/11/2009, at 11:29 AM, Krzysztof Ko�mic (2) <krzysz...@kozmic.pl

> > <mailto:krzysz...@kozmic.pl>> wrote:
>
> >> @James,
> >> I don't like it.
> >> It has nice division into three parts, but you don't always want this,
> >> and this rigidity brings more headaches than advantages IMO.

> >> You don't always test a single method, for example  in DynamicProxy

> >>>>>    Castle.Foo-vs2008.sln
> >>>>>    Castle.Foo-vs2010.sln //eventually
> >>>>>    Castle.Foo-Silverlight.sln
> >>>>>    Foo\
> >>>>>       Bar.cs
> >>>>>       Baz.cs
> >>>>>       Foo.csproj
> >>>>>       Foo-Silverlight.csproj
> >>>>>    Foo.Tests\
> >>>>>       BarTestCase.cs
> >>>>>       BazTestCase.cs
> >>>>>       Foo.Tests.csproj

> >>>>>       Foo.Tests-Silverlight.csproj
>
> >>>> Most, if not all our csproj files have the full assembly name much
> >>>> closer to
> >>>> the solution name.
>
> >>>> I was actually suggesting this to avoid lengthy paths, but ok. I'm
> >>>> +1 for
> >>>> naming Folders and .scproj files the full assembly name of the project.
>
> >>>>> I would like to point out that it would be nice to set on a common
> >>>>> naming suffix for test fixtures.

> >>>>> <mailto:castle-pro...@googlegroups.com>.

> >>>>> For more options, visit this group at
> >>>>>http://groups.google.com/group/castle-project-devel?hl=.
>
> >>>> --
> >>>> Jono
>
> >>>> --
>
> >>>> You received this message because you are subscribed to the Google
> >>>> Groups
> >>>> "Castle Project Development List" group.
> >>>> To post to this group, send email to
> >>>> castle-pro...@googlegroups.com

> >>>> <mailto:castle-pro...@googlegroups.com>.

> >>>> For more options, visit this group at
> >>>>http://groups.google.com/group/castle-project-devel?hl=.
>
> >>>> --
>
> >>>> You received this message because you are subscribed to the Google
> >>>> Groups
> >>>> "Castle Project Development List" group.
> >>>> To post to this group, send email to
> >>>> castle-pro...@googlegroups.com

> >>>> <mailto:castle-pro...@googlegroups.com>.

> >>>> For more options, visit this group at
> >>>>http://groups.google.com/group/castle-project-devel?hl=.
>
> >>> --
> >>> Truth,

> >>>     James
>
> >> --
>
> >> You received this message because you are subscribed to the Google
> >> Groups "Castle Project Development List" group.
> >> To post to this group, send email to
> >> castle-pro...@googlegroups.com

> >> <mailto:castle-pro...@googlegroups.com>.

> >> For more options, visit this group at
> >>http://groups.google.com/group/castle-project-devel?hl=.
>

> > ------------------------------------------------------------------------

> > Win 1 of 4 Sony home entertainment packs thanks to Yahoo!7. Enter now

> > <http://us.lrd.yahoo.com/_ylc=X3oDMTJxN2x2ZmNpBF9zAzIwMjM2MTY2MTMEdG1f...>.

[John Simons]

@Krzysztof, not clear on the difference between tls and lib, aren't these the same? We would still need a copy of eg nunit.framework.dll in both the lib and tlb, right?

Also the difference between default.build and Castle.Foo.build is the first one is the new build solution file vs the later that is the old build file that is only used to build the trunk, I think the question is, when are we going to get rid of the trunk? So that then we can get rid of Castle.Foo.build.

Regarding generation of assemblyinfo, to me the auto generation really only matters on the build server which by the way I think the next version of team city will do this out of the box. On our own machines does it really matter if it is auto generated or not? My view is it doesn't matter because is not an official build.

Can we get this published once finished on the castle website instead, I think this will go hand in hand with http://www.castleproject.org/community/releaseguide.html

Cheers John

Krzysztof

Krzysztof

Cheers John

Krzysztof

MethodName_StateUnderTest_ExpectedBehavior()

Jonathon Rossi wrote:

Inline

Inline.

4. FooTestCase.cs

agreed.

Krzysztof

--

--
Jono

--

--

--
Truth,
James

--

--

--

To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.

__________________________________________________________________________________

Win 1 of 4 Sony home entertainment packs thanks to Yahoo!7.

Enter now: http://au.docs.yahoo.com/homepageset/

[Krzysztof Koźmic]

John Simons wrote:
> @Krzysztof, not clear on the difference between tls and lib, aren't these the same? We would still need a copy of eg nunit.framework.dll in both the lib and tlb, right?
>

No. lib are the .dlls the project in question needs to function. For
example in Windsor's case it would contain MicroKernel, Core, and
DynamicProxy.
tls on the other hand are all other dlls/tools that are used by
developers. That's the place to put things like NUnit Nant, Rhino.Mocks
or whatever tools that are used by us, but not redistributed in the
binary package of the project in question.
We use this division at work and it plays pretty nicely. Originally that
came from JP Boodhoo I think.

> Also the difference between default.build and Castle.Foo.build is the first one is the new build solution file vs the later that is the old build file that is only used to build the trunk, I think the question is, when are we going to get rid of the trunk? So that then we can get rid of Castle.Foo.build.
>

Aaaah ok - thanks for the clarification. I'm not the one to call the
shots on this but I'm +1 for phasing the trunk out.

> Regarding generation of assemblyinfo, to me the auto generation really only matters on the build server which by the way I think the next version of team city will do this out of the box. On our own machines does it really matter if it is auto generated or not? My view is it doesn't matter because is not an official build.
>
> Can we get this published once finished on the castle website instead, I think this will go hand in hand with http://www.castleproject.org/community/releaseguide.html
>

Yes, of course. I had created a page in Castle confluence first
yesterday
(http://using.castleproject.org/display/CASTLE/Project+structure+standards)
but when I started editing it, it woudn't allow me to save, saying there
are more users than allowed in the license. Hence I started writing it
elsewhere.

[John Simons]

I understand what you want to put in tls, I guess my problem is that
we are going to end up duplicating dlls because, the Nant in tls will
have nunit.framework.dll and you also need this dll in the lib folder
because that is where we reference assemblies from, right?

I mean to publish this in the www.castleproject.org website not in the
confluence.

In regards to tls, so are we going to make everyone that gets the
source code from svn for a single castle project get these aswell? I'm
against it, I much prefer to have these tools installed on my machine
and share them between all the castle + other OSS project. NAnt and
NUnit are pretty much the standard for all OSS projects, so why have
15+ copies of these on my system?


On Dec 3, 8:57 am, Krzysztof Koźmic <krzysztof.koz...@gmail.com>

wrote:
> John Simons wrote:
> > @Krzysztof, not clear on the difference between tls and lib, aren't these the same? We would still need a copy of eg nunit.framework.dll in both the lib and tlb, right?
>
> No. lib are the .dlls the project in question needs to function. For
> example in Windsor's case it would contain MicroKernel, Core, and
> DynamicProxy.
> tls on the other hand are all other dlls/tools that are used by
> developers. That's the place to put things like NUnit Nant, Rhino.Mocks
> or whatever tools that are used by us, but not redistributed in the
> binary package of the project in question.
> We use this division at work and it plays pretty nicely. Originally that
> came from JP Boodhoo I think.> Also the difference between default.build and Castle.Foo.build is the first one is the new build solution file vs the later that is the old build file that is only used to build the trunk, I think the question is, when are we going to get rid of the trunk? So that then we can get rid of Castle.Foo.build.
>
> Aaaah ok - thanks for the clarification. I'm not the one to call the
> shots on this but I'm +1 for phasing the trunk out.> Regarding generation of assemblyinfo, to me the auto generation really only matters on the build server which by the way I think the next version of team city will do this out of the box. On our own machines does it really matter if it is auto generated or not? My view is it doesn't matter because is not an official build.
>
> > Can we get this published once finished on the castle website instead, I think this will go hand in hand with http://www.castleproject.org/community/releaseguide.html
>
> Yes, of course. I had created a page in Castle confluence first
> yesterday

> (http://using.castleproject.org/display/CASTLE/Project+structure+stand...)

> but when I started editing it, it woudn't allow me to save, saying there
> are more users than allowed in the license. Hence I started writing it
> elsewhere.
>
>
>
> > Cheers John
>

> ...
>
> read more >>- Hide quoted text -
>
> - Show quoted text -

[Jonathon Rossi]

Confluence is now fixed.

All the spam users were eating up our license user quota. I'm going to follow up on the licensing and find out if an upgrade from a 2007 build is likely to reduce the spam.

2009/12/3 Krzysztof Koźmic <krzyszto...@gmail.com>

Yes, of course. I had created a page in Castle confluence first
yesterday
(http://using.castleproject.org/display/CASTLE/Project+structure+standards)
but when I started editing it, it woudn't allow me to save, saying there
are more users than allowed in the license. Hence I started writing it
elsewhere.

--
Jono

[Krzysztof Koźmic]

John Simons wrote:

I understand what you want to put in tls, I guess my problem is that
we are going to end up duplicating dlls because, the Nant in tls will
have nunit.framework.dll and you also need this dll in the lib folder
because that is where we reference assemblies from, right?
  

Not really. you keep NUnit in tools and both - test project and NAnt references it from there.
Rule of thumb that decides whether something goes to tools or libs - do we redistribute it? no - than tools it is.

I mean to publish this in the www.castleproject.org website not in the
confluence.
  

Ok, I'll migrate it there.

In regards to tls, so are we going to make everyone that gets the
source code from svn for a single castle project get these aswell? I'm
against it, I much prefer to have these tools installed on my machine
and share them between all the castle + other OSS project. NAnt and
NUnit are pretty much the standard for all OSS projects, so why have
15+ copies of these on my system?
  

To have the repository self contained. We've already had this conversation.
I for example never install NAnt nor NUnit and consider requiring that an antipattern. This has always brought more headache than good (failing tests/build because of version incompatibility anyone?)
Also remember that we have not only users like you or me, but also like this gentleman: http://stackoverflow.com/questions/1829776/help-building-castle-dynamic-proxy
for him builiding Castle as it stands now is a PITA nad I don't even want to think how many  f*cks he threw at us when dealing with this.
It's not like we have 8GB HDDs anymore so that we need to save every few MBs we can spare.

It's a matter of DX (developer experience) that people playing with Castle will have and the nicest there is is double-clicking ClickToBuild.cmd ended with nice "Build successful - have a great time playing with Castle" message.

Krzysztof

--

You received this message because you are subscribed to the Google Groups "Castle Project Development List" group.
To post to this group, send email to castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.


  

[John Simons]

Bump!

Can we please get more people votes/suggestions (specially PMC
members) on this so we can proceed?

Thanks
John

On Dec 4, 2:56 am, Krzysztof Koźmic <krzysztof.koz...@gmail.com>

wrote:
> John Simons wrote:
> > I understand what you want to put in tls, I guess my problem is that
> > we are going to end up duplicating dlls because, the Nant in tls will
> > have nunit.framework.dll and you also need this dll in the lib folder
> > because that is where we reference assemblies from, right?
>
> Not really. you keep NUnit in tools and both - test project and NAnt
> references it from there.
> Rule of thumb that decides whether something goes to tools or libs - do

> we redistribute it? no - than tools it is.> I mean to publish this in thewww.castleproject.orgwebsite not in the

> > confluence.
>
> Ok, I'll migrate it there.> In regards to tls, so are we going to make everyone that gets the
> > source code from svn for a single castle project get these aswell? I'm
> > against it, I much prefer to have these tools installed on my machine
> > and share them between all the castle + other OSS project. NAnt and
> > NUnit are pretty much the standard for all OSS projects, so why have
> > 15+ copies of these on my system?
>
> To have the repository self contained. We've already had this conversation.
> I for example never install NAnt nor NUnit and consider requiring that
> an antipattern. This has always brought more headache than good (failing
> tests/build because of version incompatibility anyone?)
> Also remember that we have not only users like you or me, but also like

> this gentleman:http://stackoverflow.com/questions/1829776/help-building-castle-dynam...

> ...
>
> read more >>

[Roelof Blom]

Regarding the NAnt/NUnit thing I am strongly in favor of keeping the project self-contained. ClickToBuild.bat should just work right after a fresh checkout.

2009/12/19 John Simons <johnsi...@yahoo.com.au>

[Krzysztof Koźmic]

great,

Any feedback on the structure and the rest of the stuff?

On 2009-12-20 10:45, Roelof Blom wrote:

Regarding the NAnt/NUnit thing I am strongly in favor of�keeping the project self-contained. ClickToBuild.bat should just work right after a fresh checkout.

2009/12/19 John Simons <johnsi...@yahoo.com.au>

Bump!

Can we please get more people votes/suggestions (specially PMC
members) on this so we can proceed?

Thanks
John

On Dec 4, 2:56 am, Krzysztof Ko�mic <krzysztof.koz...@gmail.com>

wrote:

> John Simons wrote:
> > I understand what you want to put in tls, I guess my problem is that
> > we are going to end up duplicating dlls because, the Nant in tls will
> > have nunit.framework.dll and you also need this dll in the lib folder
> > because that is where we reference assemblies from, right?
>
> Not really. you keep NUnit in tools and both - test project and NAnt
> references it from there.
> Rule of thumb that decides whether something goes to tools or libs - do

> we redistribute it? no - than tools it is.> I mean to publish this in thewww.castleproject.orgwebsite not in the

> > confluence.
>
> Ok, I'll migrate it there.> In regards to tls, so are we going to make everyone that gets the
> > source code from svn for a single castle project get these aswell? I'm
> > against it, I much prefer to have these tools installed on my machine
> > and share them between all the castle + other OSS project. NAnt and
> > NUnit are pretty much the standard for all OSS projects, so why have
> > 15+ copies of these on my system?
>
> To have the repository self contained. We've already had this conversation.
> I for example never install NAnt nor NUnit and consider requiring that
> an antipattern. This has always brought more headache than good (failing
> tests/build because of version incompatibility anyone?)
> Also remember that we have not only users like you or me, but also like

> this gentleman:http://stackoverflow.com/questions/1829776/help-building-castle-dynam...

> for him builiding Castle as it stands now is a PITA nad I don't even

> want to think how many �f*cks he threw at us when dealing with this.

> It's not like we have 8GB HDDs anymore so that we need to save every few
> MBs we can spare.
>
> It's a matter of DX (developer experience) that people playing with
> Castle will have and the nicest there is is double-clicking
> ClickToBuild.cmd ended with nice "Build successful - have a great time
> playing with Castle" message.
>
> Krzysztof
>
>
>

> > On Dec 3, 8:57 am, Krzysztof Ko�mic <krzysztof.koz...@gmail.com>

> > wrote:
>
> >> John Simons wrote:
>
> >>> @Krzysztof, not clear on the difference between tls and lib, aren't these the same? We would still need a copy of eg nunit.framework.dll in both the lib and tlb, right?
>
> >> No. lib are the .dlls the project in question needs to function. For
> >> example in Windsor's case it would contain MicroKernel, Core, and
> >> DynamicProxy.
> >> tls on the other hand are all other dlls/tools that are used by
> >> developers. That's the place to put things like NUnit Nant, Rhino.Mocks
> >> or whatever tools that are used by us, but not redistributed in the
> >> binary package of the project in question.
> >> We use this division at work and it plays pretty nicely. Originally that
> >> came from JP Boodhoo I think.> Also the difference between default.build and Castle.Foo.build is the first one is the new build solution file vs the later that is the old build file that is only used to build the trunk, I think the question is, when are we going to get rid of the trunk? So that then we can get rid of Castle.Foo.build.
>
> >> Aaaah ok - thanks for the clarification. I'm not the one to call the
> >> shots on this but I'm +1 for phasing the trunk out.> Regarding generation of assemblyinfo, to me the auto generation really only matters on the build server which by the way I think the next version of team city will do this out of the box. On our own machines does it really matter if it is auto generated or not? My view is it doesn't matter because is not an official build.
>

> >>> Can we get this published once finished on the castle website instead, I think this will go hand in hand with �http://www.castleproject.org/community/releaseguide.html

> >>> purpose. This way we don't have the issue of different �versions not

> >>> You don't always test a single method, for example �in DynamicProxy

> >>> � �Castle.Foo-vs2008.sln
> >>> � �Castle.Foo-vs2010.sln //eventually
> >>> � �Castle.Foo-Silverlight.sln
> >>> � �Foo\
> >>> ďż˝ ďż˝ ďż˝ Bar.cs
> >>> ďż˝ ďż˝ ďż˝ Baz.cs
> >>> ďż˝ ďż˝ ďż˝ Foo.csproj
> >>> ďż˝ ďż˝ ďż˝ Foo-Silverlight.csproj
> >>> � �Foo.Tests\
> >>> ďż˝ ďż˝ ďż˝ BarTestCase.cs
> >>> ďż˝ ďż˝ ďż˝ BazTestCase.cs

> >>> ďż˝ ďż˝ ďż˝ Foo.Tests.csproj
>

> ...
>
> read more >>

--

You received this message because you are subscribed to the Google Groups "Castle Project Development List" group.
To post to this group, send email to castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.

[Roelof Blom]

Here's my preference for the rest of the stuff, hope I've covered it all as this discussion is a bit messy:

• Naming Folders and .csproj files -> full assembly name of the project.
• Test fixtures -> FooTestCase.cs
• Test methods -> Some_are_named_like_this

I am in favor of the structure described on http://using.castleproject.org/display/CASTLE/Project+structure+standards. But isn't it missing a tools folder?

-- Roelof.