+1 for OW as dependency management I did a spike together with Seb as a branch and OW is pretty solid as far as I'm concerned. Currently I am using nuget packages for everything (on develop), but I'm going to move to OW as soon as I can set build versions through the command line. That it both can consume packages from nuget and generate nuget packages is a really good reason also. Furthermore, it's very easy to switch target frameworks with OW, which is a big plus.
On Apr 30, 2:42 am, John Simons <[email protected]> wrote: > +1 to use/encourage/promote the usage of OW > > I'm of the opinion that we should use OW as our primary dependency management > tool. > I think we have much better chances of getting something changed or a patch > committed into OR then Nuget. > Nuget is as much open source as ASP.NET MVC is! Has anyone ever tried to get > a patch accepted! > > Hamilton, > Have u looked at bottles? > Seehttp://groups.google.com/group/fubumvc-devel/browse_thread/thread/931... > I think this is exactly what you are talking about. > > ________________________________ > From: hammett <[email protected]> > To: [email protected] > Sent: Saturday, 30 April 2011 4:11 AM > Subject: Re: Our build scripts, nuget, openwrap and related stuff > > Thanks, Seb. It makes sense to support both, and I think we should aim > at that. That said, I feel we - castle - should encourage OW over > nuget as a community driven effort. > > I also want to include some built-in support for package > (design/runtime) into MR+++ and obviously don't want to build it > myself. I wonder if extensibility is a goal for OW, so products can > use it to create their own package mechanism with custom deployments. > > > > > > > > On Fri, Apr 29, 2011 at 12:48 AM, SerialSeb <[email protected]> wrote: > > Rafael, > > > OpenWrap 1.0 has no VS integration support, because it doesn't need it > > to function. > > > In 1.1 we're extending the concept of project and system commands to > > IDEs, so you can expect to see some preliminary UI support, both for > > VS2008 and VS2010. For this releas however, I'm only committing to a > > "current packages" toolwindow that exposes the current config and > > which projects get what projects, as well as an "Enable OpenWrap" on > > the project node. > > > The rest of the UI integration work will be in 1.2, based on requests > > and feedback, and on contributors joining the project to drive this if > > they have the wish to do so. > > > I'm fully aware that the integration of NuGet in VS makes people doubt > > the value of an other package manager in the ecosystem. At the end of > > the day, the same can be said about MonoRails / MVC. > > > I'd recommend users to to make a commitment to a package manager or > > another based on featureset and not on marketing dollars spent by MS. > > Attetion shifts and what is a priority for them now won't necessarily > > be in a year. Their commitment to the health of the OSS ecosystem is > > also very much in doubt considering how NuGet came into existence, so > > that's also for contributors to decide where they stand. > > > I certainly wouldn't recommend for castle to only have one or the > > other package format for users, maintaining two sets of packages is > > perfectly doable, be it that you decide for yourself to use openwrap > > or nuget for your dependencies as you build the stack. > > > On Apr 28, 1:06 pm, Rafael Teixeira <[email protected]> wrote: > >> The great thing about NuGet is that it broke the "barrier" to > >> find-and-deploy dependencies, and a big part of that is just the "Add > >> Package Reference" item in the context menu of projects in VS, that can > >> make > >> people whose never thought of trying something like Castle easily try it > >> and > >> adopt. > > >> Does OpenWrap integrate so easily in VS? Installing NuGet support in VS2010 > >> is a snap, and using it afterwards also is. More importantly MS (Haack/Ebbo > >> mostly) has been evangelizing about it everywhere, and it is gaining > >> momentum... > > >> So we probably should follow the "easier-for-our-adopters" path, which I > >> think currently means NuGet. > > >> @SerialSeb, please can you tell us about the state/roadmap of OW-VS > >> integration, so that we can try to settle this and move forward to really > >> adopting some packaging strategy. > > >> Regards, > > >> Rafael "Monoman" Teixeira > >> --------------------------------------- > >> "The most exciting phrase to hear in science, the one that heralds new > >> discoveries, is not 'Eureka!' (I found it!) but 'That's funny ...'" > >> Isaac Asimov > >> US science fiction novelist & scholar (1920 - 1992) > > >> On Wed, Apr 27, 2011 at 10:05 PM, hammett <[email protected]> wrote: > >> > Hmm.. tough one. At least OW supports Nuget repositories. Not sure > >> > about the other way round.. > > >> > On Wed, Apr 27, 2011 at 4:59 PM, John Simons <[email protected]> > >> > wrote: > >> > > Does this mean we need to decide to use either nuget or ow? > >> > > Is there a good comparison of both? > > >> > > ________________________________ > >> > > From: Krzysztof Koźmic <[email protected]> > >> > > To: [email protected] > >> > > Sent: Thursday, 28 April 2011 9:24 AM > >> > > Subject: Re: Our build scripts, nuget, openwrap and related stuff > > >> > > Oh, hi Cristian :) > > >> > > Go for it mate. > > >> > > Krzysztof > > >> > > On 28/04/2011 9:23 AM, Cristian Prieto wrote: > > >> > > I raise my hand... > >> > > Cristian Prieto > > >> > > On Thu, Apr 28, 2011 at 6:05 AM, Hammett <[email protected]> wrote: > > >> > > I like the idea. Who's stepping in to make it real, though? > > >> > > On 2011-04-27, at 5:32 AM, Rafael Teixeira <[email protected]> wrote: > > >> > > Just to cross-share some experience from Mono packaging for > >> > > Debian/Ubuntu > >> > > into Castle. Mirco Bauer just blogged on the reasoning for "The Big > >> > > Split" > >> >http://www.meebey.net/posts/the_big_split_mono_2.10_debian_packaging/. > >> > > Summarizing it, Mono will be packaged from now on, on the basis of "ONE > >> > > managed library per package" so that independently from the set of > >> > managed > >> > > apps that you install no "surplus" dlls and related dependency trees > >> > > (managed and native) are installed because they were packaged together > >> > with > >> > > something that was needed, obviously there are meta-packages like > >> > > mono-complete which install all the packages and the packagers do build > >> > > everything from an specific snapshot of the whole source tree for Mono > >> > and > >> > > each managed app. > >> > > To the practical point, with NuGet (or OpenWrap) we can package things > >> > very > >> > > granularly, and have the dependencies sort things for the user > >> > (programmer), > >> > > and we already do kind of it, but we need to use it ourselves, breaking > >> > the > >> > > ties from referencing directly lots of projects in one solution and > >> > > referencing released versions of our own packages (or test versions > >> > > from > >> > a > >> > > NuGet repo tied to Team City). > >> > > With that we will lose the ability to make big refactorings across the > >> > whole > >> > > stack, but that may be, in essence, a GOOD thing, so that we are more > >> > > conscious on API/Semantics breakages. That leeds to what really will > >> > remain > >> > > complex, dependency versioning, or how to set MaxVersion on > >> > > dependencies > >> > > (MinVersion is trivial). > >> > > My suggestion: to adopt an even more strict policy on version numbers > >> > versus > >> > > API/Semantics breakage: Change the Minor and/or Major version when > >> > > API/Semantics change, so set MaxVersion to an arbitrary high release > >> > number > >> > > on (build numbers should never matter) . Example: > >> > > Castle.Windsor (3.0) depends on Castle.Core (3.0.0 to 3.0.1000). > >> > > If you need to change a signature method on some Castle.Core > >> > > interface/public class (even specifying optional parameters/default > >> > values, > >> > > or changing parameter names, now qualify as such) them you bump to > >> > > 3.1.0 > >> > and > >> > > have to build new dependent versions of up-in-the-stack libraries . The > >> > > remaining question is if some client library isn't affected by that API > >> > > breakage (lots of test coverage needed to assert that), if we just > >> > compile a > >> > > new version extending the version range on the dependency bumping just > >> > the > >> > > release number, or we have to bump the minor, because of cascading > >> > > dependencies breakage. Example > >> > > Castle.Windsor (3.0) depends on Castle.Core (3.0.0 to 3.1.1000). > >> > > -- or -- > >> > > Castle.Windsor (3.1) depends on Castle.Core (3.1.0 to 3.1.1000). > >> > > What NuGet lacks is some kind of smart-updates, it is all-or-nothing > >> > about > >> > > updates, which keeps this decision messy... > >> > > Anyway what I'm saying is: we have to use NuGet-dependency ourselves to > >> > make > >> > > it work well for our users, too. > >> > > Just my 2 inflated-cents, > >> > > Rafael "Monoman" Teixeira > >> > > --------------------------------------- > >> > > "The most exciting phrase to hear in science, the one that heralds new > >> > > discoveries, is not 'Eureka!' (I found it!) but 'That's funny ...'" > >> > > Isaac Asimov > >> > > US science fiction novelist & scholar (1920 - 1992) > > >> > > On Tue, Apr 26, 2011 at 8:56 PM, John Simons > >> > > <[email protected] > > >> > > wrote: > > >> > > The reason we run into this issues is because the project separation is > >> > > really only separate VS solutions for each main project. > > >> > > If we go the next step and completely unmarry the projects from each > >> > other, > >> > > this means not looking at Castle as a package but instead looking at > >> > > Windsor, AR, ... on their own, maybe then we do not run into this > >> > > issue. > >> > > But then what is Castle? > > >> > > Maybe the solution is to have combined releases + doco? > > >> > > Cheers, John > > >> > > On 27/04/2011, at 9:27, Henry Conceição <[email protected]> > >> > wrote: > > >> > >> It has some pro and cons. > > >> > >> The isolation is good when you think that you're not tied to the other > >> > >> projects, specially for releases. But when you try to put all the > >> > >> pieces together, it sucks due dll version hell issues. > > >> > >> Cheers, > >> > >> Henry Conceição > > >> > >> On Tue, Apr 26, 2011 at 6:37 PM, hammett <[email protected]> wrote: > >> > >>> Isn't this a good time to also make an assessment of the project > >> > >>> separations? Specifically having all project separated in github. > >> > >>> Does > >> > >>> it make life harder/easier? > > >> > >>> 2011/4/26 Krzysztof Koźmic <[email protected]>: > >> > >>>> That sounds good to me, > > >> > >>>> We'd need to > > ... > > 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 [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.
