Castle Versioning
Paul Cowan
Hi all,
I think the following problem might be interesting to both Castle members and
horn members.
The splitting of castle into its various subprojects has inevitably led to some
problems with dependency versioning.
I am a big Castle fan and use the following items of the castle stack in my day
job:
Castle.Core
Castle.Components.Validator
Castle.DynamicProxy
Castle.Facilities.AutomaticTransactionManagement
Castle.Facilities.NhibernateIntegration
Castle.Facilities.WcfIntegration
Castle.Services.Transaction
Castle.Windsor
I am assuming this might be reasonably common amongst some castle users like
myself.
When Castle was 1 big monolithic solution, you could at least guarantee that every
castle subproject would be using the same version of other castle subprojects
or the solution would not compile.
As Castle has now split into the various subprojects, they will of course
naturally grow orthogonally without the same compiler checks in place to ensure
unity. I had sort of been hoping that
Castle might try and resolve the dependencies of the subprojects by compiling
the projects and copying the .dlls into the various lib folders during the CI
build or maybe use horn.
As you would expect, the projects and their castle dependencies are now failing
to compile together.
If we use the Castle.Facilities.WcfIntegration as an example, it had the
following dependencies section.
dependencies:dependency "castle.core" >> "Castle.Core"dependency "castle.windsor" >> "Castle.DynamicProxy2"dependency "castle.windsor" >> "Castle.MicroKernel"dependency "castle.windsor" >> "Castle.Windsor
You can
see that it has a dependency on the Castle Windsor project:
A couple of days ago, the WcfIntegration facility stopped compiling against the
latest MicroKernel dependency from Castle.Windsor. Something to do with a change to the Castle.MicroKernel.Proxy.ProxyOptions.
One of the horn contributors EmmeKappa kindly created a new 2.1 descriptor for
Castle.Windsor and updated the the WcfFacilitiy descriptor to the following.
dependencies:dependency "castle.core" >> "Castle.Core"dependency "castle.windsor" >> 2.1 >> "Castle.DynamicProxy2"dependency "castle.windsor" >> 2.1 >> "Castle.MicroKernel"dependency "castle.windsor" >> 2.1 >> "Castle.Windsor
Many thanks to him for doing this.
The problem is that this does not help my scenario. It would be fine if I was only using Windsor
and the WcfIntegration facility but I am not, as you can see from my list of
Castle bits I listed at the start of the post.
I can of course update all the descriptors with Windsor dependencies to point to
the 2.1 Windsor descriptor but what if I want a trunk build?
One of my original goals with horn is to get a trunk build without having to
mess around with nant, svn, git, msbuild and the rest. As the castle subprojects are now autonomous,
I would have to get each subproject from subversion and build them
individually, copying the output into each lib folder. A job horn can do if all the descriptors are
there. The same job without horn is a
serious pain and one that would be really off putting.
My fear is that Castle will turn into a contrived dependency maze with each
subproject having different versions of other castle subprojects in their
various lib folders.
I hope I am not speaking out of turn here but I really think Castle needs to
ensure that the subprojects do not turn into a maze of castle dependencies,
never mind throwing the rest of the .NET dependencies into the mix. I have a feeling it has already started to go
this way if care is not taken to ensure that strict versioning is adhered to.
It is obvious from the list of castle bits I detailed at the start of the post
that I am a huge fan of castle but I am starting to think that updating the stack
could be off putting for some users like myself.
As for horn, I am really in a quandary of how to manage this as lots of horn
descriptors reference the various castle bits.
The goal of horn is to have all you dependencies at the same level and just
download and copy them into your lib folder.
Thoughts please
Paul Cowan
Cutting-Edge Solutions (Scotland)
http://thesoftwaresimpleton.blogspot.com/
Michele Cantelli
dependency version, and if it doesn't not compile fall back to an
older version) could be a treatment for the symptom but if they
(castle committers) won't get a build in their CI which compile all
the stack they won't notice a breaking change and that is the problem.
Paul Cowan
I guess where I am coming from and I am of course not a castle contributor so it is very much my thoughts as a user, is that the castle pieces are linked together because I use various parts of the stack as I outlined in my post.
I need to ensure that the castle core binaries in WcfIntegration are the same binaries as are in Windsor etc. or all hell breaks loose.
I use a number of castle bits and I have to rely on castle to have the same versions of the castle binaries in the various lib folders. I think this is not going to happen without checks in place and you get into a .dll hell scenario which we already have in a grand scale in .net OSS as a whole.
As each project grows orthognally with breaking public interface changes then it becomes harder for me as a user to piece them back toghether and use them if I want to update to new versions or use the trunk. The upshot being I can only use the versioned releases which may or may not fit together or I am back to mucking about in svn, nant and making code changes myself.
This is not an enjoyable experience.
--
You received this message because you are subscribed to the Google Groups "HORN Development" group.
To post to this group, send email to horn-dev...@googlegroups.com.
To unsubscribe from this group, send email to horn-developme...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/horn-development?hl=en.
Johannes Gustafsson
Paul Cowan
I still have concerns (maybe unjustifiably) that there is still scope for the VERSIONED projects to have conflicting dependencies in their lib folders which will cause problems.
There are no checks in place to ensure this does not happen. I still think castle should be vaguely viewed as a whole as it is more usual to use different parts than just one subproject.
As I also stated, I am not a castle contributor and should perhaps mind my own business :-) but after a year or so of horn, I have seen how fragmented things are and how difficult it can be to pull it all together.
The situation I outlined with the WcfIntegration is a good example of the problem I am trying to explain.
Paul Cowan
Simone Busoli
Paul Cowan
I just get the impression that the OSS projects don't care about these things.
Krzysztof Koźmic (2)
the same time to some degree independent projects.
Different parts move at different speed (as their maintainers/users
find time to contribute).
We are painfully aware of the fact that updating things that everyone
depends on, like Core means all other projects need to
update the reference which takes some time to propagate. Also
Solution I think would be nice and beneficial to both - Castle and
Horn projects is the following
- Horn would have to track "last compatible version" between projects,
and as new changes are committed in Castle, probe the new code
and try to build it and projects depending on it, to see if there were
any breaking changes introduced.
if there are none, than trunk is the last compatible version. If there
are breaking changes, Horn would not upgrade its packages, and use
the previous version of the dependency unless a next compatible
version appears.
Since Horn would now build the entire grid of dependencies it would be
wasteful not to take advantage of that. It would be great if Horn
could
collect and expose information about all breaking changes introduced
in one project that affect other projects. Better yet if it could do
that including
other projects, from outside of Castle.
When working on DynamicProxy, I used to check out Rhino Mocks and MOQ
from time to time, to see if I didn't introduce any regression bugs by
any chance.
If horn could do this automatically and notify me when such issue
occurs that would be huge.
cheers,
Krzysztof
> >> 2010/1/20 Johannes Gustafsson <vedk...@gmail.com>
> >>>> 2010/1/20 Michele Cantelli <emmeka...@gmail.com>
> ...
>
> read more »
Paul Cowan
Thanks for the detailed answer. To me this does indeed sound like the next evolution of making horn useful.
Reporting is something we are not doing for the web and we should collect this information during the build EVERYTHING process.
Being able to work back to the last compatible build sounds like a great idea and also fun to code!!
Simone Busoli
Paul Cowan
It should be the OSS project's concern to ensure you can maintain a dependency stack without outside help.
That of course will never happen.
As previously stated, it should be a standard part of the CI build process to copy dependencies into the various lib folders.
Maybe we could make horn to do that also perhaps?
Simone Busoli
Gauthier Segay
all projects from their respective trunk
http://groups.google.com/group/castle-project-devel/browse_frm/thread/4e93e0e402d61f34
http://builds.castleproject.org/project.html?projectId=project36&tab=projectOverview
On Jan 21, 8:43 pm, Simone Busoli <simone.bus...@gmail.com> wrote:
> Yes, horn could definitely provide that, the basis for the feature is
> already there if I'm not mistaken.
>
> 2010/1/21 Paul Cowan <dag...@scotalt.net>
>
>
>
> > I know were you are coming from with that one Simone.
>
> > It should be the OSS project's concern to ensure you can maintain a
> > dependency stack without outside help.
>
> > That of course will never happen.
>
> > As previously stated, it should be a standard part of the CI build process
> > to copy dependencies into the various lib folders.
>
> > Maybe we could make horn to do that also perhaps?
>
> > Cheers
>
> > Paul Cowan
>
> > Cutting-Edge Solutions (Scotland)
>
> >http://thesoftwaresimpleton.blogspot.com/
>
> > 2010/1/21 Simone Busoli <simone.bus...@gmail.com>
>
> >> I like the idea too, although I'm not sold on the fact that it's
> >> something an external tool should provide. Of course if it does, then I'm
> >> fine :)
>
> >> 2010/1/21 Paul Cowan <dag...@scotalt.net>
>
> >>> Hi Krysztof,
>
> >>> Thanks for the detailed answer. To me this does indeed sound like the
> >>> next evolution of making horn useful.
>
> >>> Reporting is something we are not doing for the web and we should collect
> >>> this information during the build EVERYTHING process.
>
> >>> Being able to work back to the last compatible build sounds like a great
> >>> idea and also fun to code!!
>
> >>> Cheers
>
> >>> Paul Cowan
>
> >>> Cutting-Edge Solutions (Scotland)
>
> >>>http://thesoftwaresimpleton.blogspot.com/
>
> >>> 2010/1/21 Krzysztof Koźmic (2) <krzysz...@kozmic.pl>
> ...
>
> read more »
Paul Cowan
As much as I love Castle, I have started to think recently that if I did not use Castle or Rhino then I would not have the same update problems for getting bug fixes or new features.
If I just used Nhibernate and StructureMap/Autofac on their own then I really could cut down on the dependency madness I experience.
Simone Busoli
Krzysztof Koźmic (2)
Since no one really uses MicroKernel without Windsor, we plan to merge
Windsor/MicroKernel/Core/DynamicProxy (plus perhaps DictionaryAdapter)
into two assemblies.
Also logging facility and services are versioned together with these
projects now, which should also minimize potential clashes
porbability.
Krzysztof
On 26 Sty, 19:16, Simone Busoli <simone.bus...@gmail.com> wrote:
> I think unifying some assemblies in the Castle stack is something planned,
> but you can always ping the team about this, and actually the recent split
> of the projects was something ideally already in this direction.
>
> 2010/1/26 Paul Cowan <dag...@scotalt.net>
>
> > I think that is a sensible approach.
>
> > As much as I love Castle, I have started to think recently that if I did
> > not use Castle or Rhino then I would not have the same update problems for
> > getting bug fixes or new features.
>
> > If I just used Nhibernate and StructureMap/Autofac on their own then I
> > really could cut down on the dependency madness I experience.
>
> > Cheers
>
> > Paul Cowan
>
> > Cutting-Edge Solutions (Scotland)
>
> >http://thesoftwaresimpleton.blogspot.com/
>
> > 2010/1/25 Gauthier Segay <gauthier.se...@gmail.com>
>
> > just to point that Roelof Blom just set a teamcity project building
> >> all projects from their respective trunk
>
> >>http://groups.google.com/group/castle-project-devel/browse_frm/thread...
>
> >>http://builds.castleproject.org/project.html?projectId=project36&tab=...
> ...
>
> więcej »
tom
into DLL hell if you wanted to use multiple parts of the castle
stack!
> ...
>
> read more >>
Paul Cowan
Is anybody interested in taking on these tasks?
I don't have the time right now for various reasons but I can assist anyone who fancies a challenge.
Is anyone interested in this?
On Feb 1, 2010 8:30 PM, "tom" <tomm...@gmail.com> wrote:
I like where this is going. I got scared that it was going to turn
into DLL hell if you wanted to use multiple parts of the castle
stack!
On Jan 27, 8:39 am, Krzysztof Koźmic (2) <krzysz...@kozmic.pl> wrote: > Yes, there are plans to do ...
> ...
>
> read more >>
-- You received this message because you are subscribed to the Google Groups "HORN Development" gr...
Johannes Gustafsson
--
Simone Busoli
Paul Cowan
I do not mean building with ILmerge.
I mean horn's ability to revert back to the last build that did not break in the event of a breaking package.