The main issue with package management is the amount of "breakage" you get from using it, which stops user in their tracks immediately. As Horn is trying to assemble binaries from a bunch of trunk versions of code, it's no surprise that a lot of the time these things break, taking a *long* time to update your stack.
I see Horn as a package builder, not a package management system. There's still hope that Horn could be the unified way for building software, I don't know. What I know is that I won't be covering the build part of things (aka not provide any automated or convention- based way), and let people writing the code decide how they want the package. The mailing list is at http://groups.google.com/group/openwrap-devel As for the differences with Bricks, we chatted about it with Jono at the time he announced Bricks, and we do very similar things, but it's my understanding that OpenWrap had a wider scope. We discussed about combining efforts from existing codebases, I wanted to wait until we got both systems at their first release before deciding on anything, as I didn't (and still haven't) have the time to both develop the concepts and coordinate a merge. Not sure what the state of Bricks is. What I can tell you is what OpenWrap does: 1. Everything works through commands, with those commands running from the command line in a noun / verb fashion (a copycat of powershell commands), but should also easily be usable in an upcoming VS plugin, all in XCopy environment. Commands from your project are also included, so you can deploy all your commands as part of packages with your solution. 2. Dependencies are resolved from a dependency descriptor, and the correct references are added transparently, so both MSBuild and VS are none the wiser of the treachery and happily compile 3. Dependency resolving follows platform compatibility rules, so a package can contain binaries targetting .net2, .net3, .net3.5, and MSIL, x86, x64. Platform graphs will let the system be easily able to change the probing mechanism to quickly add new profiles (such as silverlight, mono etc). The binaries are selected at the time of the assembly resolve, so at build time it'll select the correct ddls, and provided you use openwrap for assembly resolving at runtime it'll be supported to. 4. Packages are not only dll's, they are whatever is needed to be packaged. Each area of a package is called an export, processed by an export manager, which itself will be part of a package. 5. StructureMap and OpenRasta are going to be packaged in OpenWrap by their respective authors, so there's some pledged adoption planned in the next iterations of those products, and iMeta is providing us with the hosting space for the first official openwrap package repository. Doesn't mean it's good, just means people have a desire to see stuff happen. That's just a quick overview of why I think OpenWrap has a good chance of getting somewhere. Any feedback more than welcome, but if it's just about OpenWrap i'd invite people to follow the conversation on openwrap-devel http://groups.google.com/group/openwrap-devel. Seb On Jun 26, 8:49 am, Krzysztof Koźmic <[email protected]> wrote: > Thanks for the info Seb, > > Could you (and Jono perhaps could give us his POV) elaborate on OpenWrap > and Jono's Bricks project, and how they're different? > > Krzysztof. > > PS > > I'm keeping my fingers crossed this (Bricks and OW) will work this time > and not end up like Horn, or one of dozens of similar projects. > > On 26/06/2010 5:42 PM, SerialSeb wrote: > > > Hi guys, > > > as we get quite close to a first release, i've open a development > > mailing list for OpenWrap. > > > I'll have forksof projects on github for the changes that are required > > for each of the castle components to be pushed on the package server. > > If you want to discuss those changes, let me know. > > > For those not aware of it, OpenWrap is a package management and > > distribution system for .net that's been in the work for a while, and > > is what OpenRasta and StructureMap are standardizing on in the next > > couple of weeks. > > > Seb -- 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
