The build is failing

[Henry Conceição]

Hi guys,

As I said in the subject, the building is failing - at the brail view
engine tests - for some unknow reason. It's simply hanging on my
machine and appears to be hanging in the build server too.

When I reverted to rev 5206, the build went fine.

Has anybody else experienced this issue?

--
Cheers,
Henry Conceição

[Ayende Rahien]

Same for me, but I haven't digged into that yet.

[Hamilton Verissimo]

Reverted the revision below. All is good.

Revision: 5207
Author: enix
Message:
- Added additional path support to the view engine configuration

<viewEngine
viewPathRoot="views"
customEngine="ViewEngine.Type.Name, Assembly">

<additionalSources>
<assembly name="" namespace="" />
<path location="" />
</additionalSources>

</viewEngine>

Breaking change; the additional assembly sources property on
FileAssemblyViewSourceLoader is now named 'AssemblySources', the paths
are loaded into 'PathSources'

----
Modified : /trunk/MonoRail/Castle.MonoRail.Framework/Configuration/ViewEngineConfig.cs
Modified : /trunk/MonoRail/Castle.MonoRail.Framework/IViewSourceLoader.cs
Modified : /trunk/MonoRail/Castle.MonoRail.Framework/Views/FileAssemblyViewSourceLoader.cs
Modified : /trunk/MonoRail/Castle.MonoRail.Framework.Tests/Configuration/ViewEngineConfigTestCase.cs
Modified : /trunk/MonoRail/Castle.MonoRail.Framework.Tests/Services/FileAssemblyViewSourceLoaderTestCase.cs
Modified : /trunk/MonoRail/Castle.MonoRail.Framework.Tests/ViewEngines/ViewEngineBaseTestCase.cs
Modified : /trunk/MonoRail/Changes.txt
Modified : /trunk/MonoRail/monorail_configuration_ref.txt

--
Cheers,
hamilton verissimo
ham...@castlestronghold.com
http://www.castlestronghold.com/

[Roelof Blom]

I've fixed it, and added it back in r5210.

[Ernst Naezer]

Hi Roeloef,

thanks for taking the time to investigate and fix this. I've had some other troubles getting the brail engine running on my local machine so figured it was my setup that caused it to fail...

cheers,
ernst

[john teague]

The ActiveRecord build is failing for me. I reverted to 5207 and got
a clean build. I forgot the exact message, but something about
ActiveRecordMediator and the number of parameters. Sorry I don't know
enough yet to fix it.

On Jul 3, 2:32 am, "Ernst Naezer" <ernstnae...@gmail.com> wrote:
> Hi Roeloef,
>
> thanks for taking the time to investigate and fix this. I've had some other
> troubles getting the brail engine running on my local machine so figured it
> was my setup that caused it to fail...
>
> cheers,
> ernst
>

> >> hamm...@castlestronghold.com
> >>http://www.castlestronghold.com/

[Hamilton Verissimo]

might be due to the fact that my NH version is different. hmmm.. what to do?

--

[Roelof Blom]

We could either:
1. partially revert r5212,
2. upgrade to NH trunk instead of 2.0.x,
3. wonder why NH 2.0.x does not have EvictEntity(string entityName, object id);

For now I am in favor of partially reverting r5212 and fixing the build.

[Markus Zywitza]

I have a homegrown build-from-trunk-nant-script, which builds Castle
fine with NH trunk, so I'll opt for 2 until NH2 goes RTM.

After NH2 is released, we should stay with it at least until Castle
has it's next release (no matter whether it will 1.0 Final or 1.0
RC(n+1)).

-Markus

[Hamilton Verissimo]

+1

[Markus Zywitza]

Sadly, this won't work, as NH Trunk is now 2.1.x and contains breaking
changes compared to NH 2.0 :-(

Downgrading for production is counter-productive, so either Beta now
or no release until NH 2.1...

-Markus

[Hamilton Verissimo]

The only thing I know is that I need those Evict overloads :-\

[Markus Zywitza]

There is yet another option, but it means a lot of work and discipline.

1) Branch Castle 1.0 now, make it work with NH 2.0 and release it (as
a "this-time-really-RC-RC").
2) Fix any show stoppers in the branch and backport them to trunk.
3) Release Castle 1.0, ideally on the day NH2 is released.
4) Castle trunk (1.1 perhaps) will have NH trunk (2.1) complete with evict etc.

There are some downsides with it:
a) Castle 1.0 must be supported separately. No more "use trunk
instead". The PMC should elect a maintainer for it, who checks whether
patches for trunk are applicable to the release as bug fixes.
b) Open issues must be reviewed and decided whether they apply to 1.0 or not.
c) Documentation is still pending...

The upsides are:
a) Released, finally. This takes the pressure from the trunk and
allows for some experiments (MR2 etc.)
b) There is a final set of features for 1.0. That means, the number of
features that need to be documented or reviewed is now finite. I think
that this is important. Until now, by the time I figured out how a
feature functioned, two new have been committed to trunk. That cuts
down motivation to write documentation a lot.
c) Same as b) for open issues. Currently, most users that look into
source and fix bugs use trunk anyway, so our previous RCs where out of
support the day they were released. A final 1.0 with a fixed set of
features will hopefully draw more attention from expert
users/committers and allow for a small developer base that maintains
that release.

As far as it concerns me, I'm really thinking about using such a
release. Not running with the trunk anymore would give me more time to
concentrate on my applications. From my POV, Castle is currently
nearly feature complete. The same is true for NH2.
More important, as I don't plan to upgrade to VS2008 in the near
future, I'd be glad to have a released and supported development stack
that will continue to work with VS2005. It would be also easier to use
NH addons, which don't always build against NH trunk.

So what do you think about that?

-Markus