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 write the "release" scripts pretty much from scratch >> > anyway >> > >>>> so >> > >>>> we might as well do it in RAKE since as you pointed out there's no >> > need >> > >>>> to >> > >>>> have it run elsewhere than on the build server. >> >> > >>>> krzysztof >> >> > >>>> On 26/04/2011 10:49 PM, Roelof Blom wrote: >> >> > >>>> IMHO MSBuild is not really suitable for creating nuget, packaging, >> > >>>> releasing >> > >>>> to SF etc. >> > >>>> As these tasks are only executed by the TeamCity server and/or >> > >>>> committers >> > >>>> rake with Albacore will make this a lot easier and workable. >> > >>>> There are of course ways to get MSBuild to do this (like creating a >> > >>>> nuget >> > >>>> package with NuGet.MSBuild) it's really throwing in more and more XML >> > >>>> for no >> > >>>> apparent benefit. >> > >>>> A combination of "front-end" MSBuild scripts like we have now and a >> > >>>> "back-end" rake script looks best to me. >> > >>>> This way there's no barrier to open and build our projects locally >> > like >> > >>>> they can now, and the rest can just script and automate anything that >> > >>>> comes >> > >>>> to mind with a tool well suited for it. >> > >>>> -- Roelof. >> >> > >>>> 2011/4/25 Krzysztof Koźmic <[email protected]> >> >> > >>>>> I haven't looked beyond putting Nuget package for Windsor 2.5.3 out, >> > >>>>> something that was frequently requested. >> >> > >>>>> I would *love* to have the release process automated (to a point >> > where >> > >>>>> I >> > >>>>> git push to a new tag and our TeamCity recognizes that, and runs a >> > >>>>> release >> > >>>>> build that does everything, including release packaging, releasing to >> > >>>>> SF, >> > >>>>> nuget and OW, branching (if new branch is needed, that is it's not a >> > >>>>> point >> > >>>>> point release and few other things I forgot, like updating the >> > website >> > >>>>> in >> > >>>>> all 3 places.)) >> >> > >>>>> I *strongly* prefer giving MsBuild a fair shot before trying any >> > other >> > >>>>> build solution, mostly because MsBuild is out of the box, it's .NET >> > and >> > >>>>> many >> > >>>>> developers will flat refuse to install Ruby in order to build a .NET >> > >>>>> project. >> >> > >>>>> I think the scripts we have are really well and cleanly written and >> > >>>>> while >> > >>>>> I'm nowhere near as proficient at working with them as Roelof is, >> > I've >> > >>>>> been >> > >>>>> able to tweak them on several occasions, same as I'm sure everyone >> > else >> > >>>>> on >> > >>>>> the team would be. >> >> > >>>>> This however reminds me of another problem I've had, and we'll >> > continue >> > >>>>> having, that is keeping consistency in build scripts among projects. >> > >>>>> I've mostly worked with Core and Windsor and all changes and tweaks >> > >>>>> introduced in one project had to be manually copied to the other one. >> > >>>>> As we >> > >>>>> have many more projects I'm sure trying to deploy changes to build >> > >>>>> process >> > >>>>> all across the board would be nothing short of a nightmare. >> >> > >>>>> Can we please consider some options for automated sharing the build >> > >>>>> files >> > >>>>> among all of our projects so that we only change things once and that >> > >>>>> change >> > >>>>> gets propagated to every project? >> >> > >>>>> I think it might also be beneficial to have a wiki >> >> ... >> >> read more »- Hide quoted text - >> >> - Show quoted text - > > -- > 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. > > -- Cheers, hammett http://hammett.castleproject.org/ -- 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.
