Re: [Rails-devel] Changed setup of the rails repo

[brett l. <bre...@gm...>]

On Tue, Aug 9, 2011 at 9:21 AM, Stefan Frey <ste...@we...> wrote:
> For some files/folders I do not know exactly why they are created.
>
> * Folder rails:
> My preferred solution here is to create two directories src/ and unit/.
>

I'm okay with doing this. As we're getting more unit tests, it makes
sense to start organizing them.

> Then move the rails/ folder to src/ and over time mirror the directory
> structure of rails/ inside unit/ for unit tests.
>
> I do not really favor to mirror the full java package names in the folder
> structure, but I can live with any outcome.
>

The convention is primarily due to the way Java looks for classes
within the classpath. We've already got a custom class loader to
assist in locating classes outside of the classpath, which helps work
around or obfuscate this issue, depending on your perspective.

I don't really care what our package names are. I do think they should
align with the directory structure in order to help avoid classpath
search issues.

> * Folder test:
> I would like to keep the automated game tests (functional tests) under src/,
> as they are not unit tests and TestGame and TestGameBuilder could in principle
> be tested themselves by unit tests. UI tests and automated tests of revenue
> calculations would find their place there too.
> I do not know if the other classes inside test are used, otherwise I suggest
> removing them.

I disagree. The only thing under src should be actual game code. The
distinction between functional and unit tests may be important enough
to segregate the types of tests, but they should all be under the same
tree outside of src.

How about this:

- src/
- test/
--- unit/
--- functional/


>
> * File 18xx_autosave.rails
> Gets created automatically from a running game as eclipse uses the folder as
> the current working directory.  Should be either ignored or in a working
> directory outside of the repository.
>

Yup. This, the 18xx.log, and any other files created at runtime need
to be in the .git/info/exclude file.

> * File log4j.properties
> Stores the part of my.properties that have to do with logging and were not
> replaced by the new profile mechanism. Should be stored inside the repo to be
> available at the start of Rails.
>
> * File my.properties
> Legacy file to set configurations. Now replaced by the new profil mechanism.
> Can be removed.
>

Ok. Remove it.

> * File user.profiles
> Gets created automatically from a running Rails instance to store a map of
> profile names to the locations of the profile files for a user.
> Same as 18xx_autosave.rails

Yep. Exclude it from the repository, too.

---Brett.

>
> On Monday, August 08, 2011 09:20:29 pm Erik Vos wrote:
>> > Is it ok with you (Erik & Brett) to create an additional layer with src/
>>
>> and
>>
>> > junit/?
>>
>> I was actually wondering why Eclipse/Egit didn't let me create the src/
>> layer, so basically I'm all for it.
>> But what are the consequences? I don't hope I'll have to set it all up yet
>> another time.
>>
>> > EclEmma coverage tool reported an overall code coverage of 40.2% after
>> > running all automated game tests (which is not too bad given that UI and
>> > algorithm packages are not tested by construction, the rails/game package
>> > itself has 73.8% coverage).
>> >
>> > My preferred mock library is JMock, any comments/preferences for this?
>>
>> No.
>>
>> Erik.
>>
>>
>>
>> ---------------------------------------------------------------------------
>> --- BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
>> The must-attend event for mobile developers. Connect with experts.
>> Get tools for creating Super Apps. See the latest technologies.
>> Sessions, hands-on labs, demos & much more. Register early & save!
>> http://p.sf.net/sfu/rim-blackberry-1
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>