Wednesday, 19 May 2010

Why I haven’t blogged about OpenWrap yet.

Because it’s not ready and I haven’t announced it yet.

I showed the state of the code-base at the progressive.net workshop, to gather feedback from smart people. There was good feedback, and the latest architectural change happened the night before, so I’m still coding.

I’m doing it in the open, you can have a look at the code but I won’t link to it.

But please, please, to some of you, get off my back! If you think your package manager is better, good, I’m glad you found a tool you like.  If you think the project is a bad idea because yours is better, please commit some code and show us the money.

Until I’ve officially announced the project, I’d be quite happy not dealing with all the negativity that has come my way since Rob’s post.

Kthxbye.

4 comments:

Barry said...

Personally I think this could make things a great deal easier for me so keep up the good work. Do you think success will really hinge on the ability to get a critical mass of projects on board?

I've been doing a few experiments in other languages lately and found I really miss this concept when coming back to .Net land. Here's the ones I've been using...

Ruby - Gems.
Clojure - Leiningen.
Node.js - Kiwi.

F Quednau said...

Hi there, funny enough I was putting down my thoughts regarding distribution of .NEt binaries, my code is at github.com/flq/bin4net . I'd love to get in touch with you as it's kinda pointless (especially in this case) to have 2 solutions, and I'd like to see how you are setting pu the process vs. what I was thinking. I am sending this to you through github as well, maybe you feel like responding.
Cheers
FQ

Morgan said...

Hi,
I really needed a module dependency system for our environment at work and could not find any mature stuff in the .Net world, so I had to pick a java library which is really neat: Ant Ivy (http://ant.apache.org/ivy/).
It is really well thought and nicely integrated in Ant, so I had to provide an ant front end to my builds that would call into other msbuild scripts when I had to.
Also, Ivy has a plugin for Hudson, a continuous build environment, that can use the dependencies to automatically trigger child projects.
Finally, Ivy provides an interesting report that explains how the modules where resolved, which version was picked up and how versioning conflicts were resolved.
Morgan

Timothy Herrera said...

Could you provide some context or a reference to Rob's post?

Post a Comment