I've been following Nu's progress and I'm really excited about what is coming out of it. I decided to give gem creation a shot by adding a gemspec for the Spark View Engine using a variety of posts:
My question revolves around dependencies. The current release of the Spark view engine (1.1.0.0) includes some 154 non-required dependencies. There are just under 10 DLLs required, depending on what language or framework you are utilizing. Based on that, those 10 DLLs would be placed in the *lib* directory, correct? How would I approach the dependencies in this case? Would I need to search rubygems.org for each dependency and add it if it was not there? That seems like a lot of work to add one gem so I'm hoping that I'm missing something. Forgive me if I'm overlooking something simple here - I'm new to the Ruby/Gem world.
Thanks for all your hard work on this project. I'm really excited about it and plan on blogging on the project once I get a more solid understanding of gem creation.
On Mon, Aug 9, 2010 at 6:50 AM, Danny Douglass <ddougl...@gmail.com> wrote: > Greetings,
> I've been following Nu's progress and I'm really excited about what is > coming out of it. I decided to give gem creation a shot by adding a gemspec > for the Spark View Engine using a variety of posts:
> My question revolves around dependencies. The current release of the Spark > view engine (1.1.0.0) includes some 154 non-required dependencies. There > are just under 10 DLLs required, depending on what language or framework you > are utilizing. Based on that, those 10 DLLs would be placed in the *lib* directory, > correct? How would I approach the dependencies in this case? Would I need > to search rubygems.org for each dependency and add it if it was not there? > That seems like a lot of work to add one gem so I'm hoping that I'm missing > something. Forgive me if I'm overlooking something simple here - I'm new to > the Ruby/Gem world.
> Thanks for all your hard work on this project. I'm really excited about it > and plan on blogging on the project once I get a more solid understanding of > gem creation.
> Just for context. What are the ~10 dlls that you need?
> -d
> On Mon, Aug 9, 2010 at 6:50 AM, Danny Douglass <ddougl...@gmail.com> wrote:
> > Greetings,
> > I've been following Nu's progress and I'm really excited about what is
> > coming out of it. I decided to give gem creation a shot by adding a gemspec
> > for the Spark View Engine using a variety of posts:
> > My question revolves around dependencies. The current release of the Spark
> > view engine (1.1.0.0) includes some 154 non-required dependencies. There
> > are just under 10 DLLs required, depending on what language or framework you
> > are utilizing. Based on that, those 10 DLLs would be placed in the *lib* directory,
> > correct? How would I approach the dependencies in this case? Would I need
> > to search rubygems.org for each dependency and add it if it was not there?
> > That seems like a lot of work to add one gem so I'm hoping that I'm missing
> > something. Forgive me if I'm overlooking something simple here - I'm new to
> > the Ruby/Gem world.
> > Thanks for all your hard work on this project. I'm really excited about it
> > and plan on blogging on the project once I get a more solid understanding of
> > gem creation.
So, I think I am confused. Which one is the 'view engine'?
I think based on our current thinking the 'Castle.MonoRail.Views.Spark.dll' would for sure go into some kind of optional folder. So if want to use the spark view engine in a console application that I am writing to build pretty html reports which dlls do I need?
On Mon, Aug 9, 2010 at 7:16 AM, Danny Douglass <ddougl...@gmail.com> wrote: > There are actually 8 *required* DLLs, depending on the language/ > framework you are utilizing:
> My understanding is that these are the components I'd be placing into > the *lib* directory.
> On Aug 9, 8:06 am, Dru Sellers <d...@drusellers.com> wrote: > > Just for context. What are the ~10 dlls that you need? > > -d
> > On Mon, Aug 9, 2010 at 6:50 AM, Danny Douglass <ddougl...@gmail.com> > wrote: > > > Greetings,
> > > I've been following Nu's progress and I'm really excited about what is > > > coming out of it. I decided to give gem creation a shot by adding a > gemspec > > > for the Spark View Engine using a variety of posts:
> > > My question revolves around dependencies. The current release of the > Spark > > > view engine (1.1.0.0) includes some 154 non-required dependencies. > There > > > are just under 10 DLLs required, depending on what language or > framework you > > > are utilizing. Based on that, those 10 DLLs would be placed in the > *lib* directory, > > > correct? How would I approach the dependencies in this case? Would I > need > > > to search rubygems.org for each dependency and add it if it was not > there? > > > That seems like a lot of work to add one gem so I'm hoping that I'm > missing > > > something. Forgive me if I'm overlooking something simple here - I'm > new to > > > the Ruby/Gem world.
> > > Thanks for all your hard work on this project. I'm really excited > about it > > > and plan on blogging on the project once I get a more solid > understanding of > > > gem creation.
Only the spark.dll. The other dlls are optional, based on the
language/framework you are utilizing. For example, if I'm creating an
ASP.NET MVC application and wish to utilize the Spark view engine
instead of the standard ASP.NET MVC view engine, I would include two
components: spark.dll and spark.web.mvc.dll.
As I'm talking this out I think I'm approaching this the wrong way.
The gem would be simply the spark.dll and the other dlls would be
optional components. Is that more of the approach I would want to
take? If so, how are optional components handled, if that feature is
even available at this point.
On Aug 9, 8:25 am, Dru Sellers <d...@drusellers.com> wrote:
> So, I think I am confused.
> Which one is the 'view engine'?
> I think based on our current thinking the 'Castle.MonoRail.Views.Spark.dll'
> would for sure go into some kind of optional folder. So if want to use the
> spark view engine in a console application that I am writing to build pretty
> html reports which dlls do I need?
> -d
> On Mon, Aug 9, 2010 at 7:16 AM, Danny Douglass <ddougl...@gmail.com> wrote:
> > There are actually 8 *required* DLLs, depending on the language/
> > framework you are utilizing:
> > My understanding is that these are the components I'd be placing into
> > the *lib* directory.
> > On Aug 9, 8:06 am, Dru Sellers <d...@drusellers.com> wrote:
> > > Just for context. What are the ~10 dlls that you need?
> > > -d
> > > On Mon, Aug 9, 2010 at 6:50 AM, Danny Douglass <ddougl...@gmail.com>
> > wrote:
> > > > Greetings,
> > > > I've been following Nu's progress and I'm really excited about what is
> > > > coming out of it. I decided to give gem creation a shot by adding a
> > gemspec
> > > > for the Spark View Engine using a variety of posts:
> > > > My question revolves around dependencies. The current release of the
> > Spark
> > > > view engine (1.1.0.0) includes some 154 non-required dependencies.
> > There
> > > > are just under 10 DLLs required, depending on what language or
> > framework you
> > > > are utilizing. Based on that, those 10 DLLs would be placed in the
> > *lib* directory,
> > > > correct? How would I approach the dependencies in this case? Would I
> > need
> > > > to search rubygems.org for each dependency and add it if it was not
> > there?
> > > > That seems like a lot of work to add one gem so I'm hoping that I'm
> > missing
> > > > something. Forgive me if I'm overlooking something simple here - I'm
> > new to
> > > > the Ruby/Gem world.
> > > > Thanks for all your hard work on this project. I'm really excited
> > about it
> > > > and plan on blogging on the project once I get a more solid
> > understanding of
> > > > gem creation.
Yeah, the spark.dll is teh main gem, and other things are optional. There is a thread about that optional stuff somewhere in the list. when I get to work I can help you find it. -d
On Mon, Aug 9, 2010 at 7:34 AM, Danny Douglass <ddougl...@gmail.com> wrote: > Only the spark.dll. The other dlls are optional, based on the > language/framework you are utilizing. For example, if I'm creating an > ASP.NET MVC application and wish to utilize the Spark view engine > instead of the standard ASP.NET MVC view engine, I would include two > components: spark.dll and spark.web.mvc.dll.
> As I'm talking this out I think I'm approaching this the wrong way. > The gem would be simply the spark.dll and the other dlls would be > optional components. Is that more of the approach I would want to > take? If so, how are optional components handled, if that feature is > even available at this point.
> On Aug 9, 8:25 am, Dru Sellers <d...@drusellers.com> wrote: > > So, I think I am confused. > > Which one is the 'view engine'?
> > I think based on our current thinking the > 'Castle.MonoRail.Views.Spark.dll' > > would for sure go into some kind of optional folder. So if want to use > the > > spark view engine in a console application that I am writing to build > pretty > > html reports which dlls do I need?
> > -d
> > On Mon, Aug 9, 2010 at 7:16 AM, Danny Douglass <ddougl...@gmail.com> > wrote: > > > There are actually 8 *required* DLLs, depending on the language/ > > > framework you are utilizing:
> > > My understanding is that these are the components I'd be placing into > > > the *lib* directory.
> > > On Aug 9, 8:06 am, Dru Sellers <d...@drusellers.com> wrote: > > > > Just for context. What are the ~10 dlls that you need? > > > > -d
> > > > On Mon, Aug 9, 2010 at 6:50 AM, Danny Douglass <ddougl...@gmail.com> > > > wrote: > > > > > Greetings,
> > > > > I've been following Nu's progress and I'm really excited about what > is > > > > > coming out of it. I decided to give gem creation a shot by adding > a > > > gemspec > > > > > for the Spark View Engine using a variety of posts:
> > > > > My question revolves around dependencies. The current release of > the > > > Spark > > > > > view engine (1.1.0.0) includes some 154 non-required dependencies. > > > There > > > > > are just under 10 DLLs required, depending on what language or > > > framework you > > > > > are utilizing. Based on that, those 10 DLLs would be placed in the > > > *lib* directory, > > > > > correct? How would I approach the dependencies in this case? > Would I > > > need > > > > > to search rubygems.org for each dependency and add it if it was > not > > > there? > > > > > That seems like a lot of work to add one gem so I'm hoping that > I'm > > > missing > > > > > something. Forgive me if I'm overlooking something simple here - > I'm > > > new to > > > > > the Ruby/Gem world.
> > > > > Thanks for all your hard work on this project. I'm really excited > > > about it > > > > > and plan on blogging on the project once I get a more solid > > > understanding of > > > > > gem creation.
Thanks Dru. I found a few threads discussing the optional components,
and form what I can tell I would structure my gem directory like the
following with optional components:
/lib
/.net-3.5
spark.dll
/opt
/spark.web.mvc.dll
/spark.web.mvc.ruby.dll
/docs
sparkviewengine.gemspec
VERSION
then in the gem install: nu install sparkviewengine -include ???
I saw a few different discussions on how optional components would be
handled, but didn't see anything that was decided. If this is going
down the right route, how would I include the ASP.Net MVC reference as
an optional component and *not* the ruby reference? Would all
optional components be installed regardless?
On Aug 9, 8:46 am, Dru Sellers <d...@drusellers.com> wrote:
> Yeah, the spark.dll is teh main gem, and other things are optional. There is
> a thread about that optional stuff somewhere in the list.
> when I get to work I can help you find it.
> -d
> On Mon, Aug 9, 2010 at 7:34 AM, Danny Douglass <ddougl...@gmail.com> wrote:
> > Only the spark.dll. The other dlls are optional, based on the
> > language/framework you are utilizing. For example, if I'm creating an
> > ASP.NET MVC application and wish to utilize the Spark view engine
> > instead of the standard ASP.NET MVC view engine, I would include two
> > components: spark.dll and spark.web.mvc.dll.
> > As I'm talking this out I think I'm approaching this the wrong way.
> > The gem would be simply the spark.dll and the other dlls would be
> > optional components. Is that more of the approach I would want to
> > take? If so, how are optional components handled, if that feature is
> > even available at this point.
> > On Aug 9, 8:25 am, Dru Sellers <d...@drusellers.com> wrote:
> > > So, I think I am confused.
> > > Which one is the 'view engine'?
> > > I think based on our current thinking the
> > 'Castle.MonoRail.Views.Spark.dll'
> > > would for sure go into some kind of optional folder. So if want to use
> > the
> > > spark view engine in a console application that I am writing to build
> > pretty
> > > html reports which dlls do I need?
> > > -d
> > > On Mon, Aug 9, 2010 at 7:16 AM, Danny Douglass <ddougl...@gmail.com>
> > wrote:
> > > > There are actually 8 *required* DLLs, depending on the language/
> > > > framework you are utilizing:
> > > > My understanding is that these are the components I'd be placing into
> > > > the *lib* directory.
> > > > On Aug 9, 8:06 am, Dru Sellers <d...@drusellers.com> wrote:
> > > > > Just for context. What are the ~10 dlls that you need?
> > > > > -d
> > > > > On Mon, Aug 9, 2010 at 6:50 AM, Danny Douglass <ddougl...@gmail.com>
> > > > wrote:
> > > > > > Greetings,
> > > > > > I've been following Nu's progress and I'm really excited about what
> > is
> > > > > > coming out of it. I decided to give gem creation a shot by adding
> > a
> > > > gemspec
> > > > > > for the Spark View Engine using a variety of posts:
> > > > > > My question revolves around dependencies. The current release of
> > the
> > > > Spark
> > > > > > view engine (1.1.0.0) includes some 154 non-required dependencies.
> > > > There
> > > > > > are just under 10 DLLs required, depending on what language or
> > > > framework you
> > > > > > are utilizing. Based on that, those 10 DLLs would be placed in the
> > > > *lib* directory,
> > > > > > correct? How would I approach the dependencies in this case?
> > Would I
> > > > need
> > > > > > to search rubygems.org for each dependency and add it if it was
> > not
> > > > there?
> > > > > > That seems like a lot of work to add one gem so I'm hoping that
> > I'm
> > > > missing
> > > > > > something. Forgive me if I'm overlooking something simple here -
> > I'm
> > > > new to
> > > > > > the Ruby/Gem world.
> > > > > > Thanks for all your hard work on this project. I'm really excited
> > > > about it
> > > > > > and plan on blogging on the project once I get a more solid
> > > > understanding of
> > > > > > gem creation.
So stage one, we just copy everything in the 'lib' folder over to the project. We are working on something more intelligent but right now all of my time is being spent on setting up the server. I would encourage you to try making the gem and then install it locally with
gem install spark.gem
and then run 'nu install spark'
and see what happens. you can uninstall with 'gem uninstall spark'
On Mon, Aug 9, 2010 at 8:17 AM, Danny Douglass <ddougl...@gmail.com> wrote: > Thanks Dru. I found a few threads discussing the optional components, > and form what I can tell I would structure my gem directory like the > following with optional components:
> then in the gem install: nu install sparkviewengine -include ???
> I saw a few different discussions on how optional components would be > handled, but didn't see anything that was decided. If this is going > down the right route, how would I include the ASP.Net MVC reference as > an optional component and *not* the ruby reference? Would all > optional components be installed regardless?
> On Aug 9, 8:46 am, Dru Sellers <d...@drusellers.com> wrote: > > Yeah, the spark.dll is teh main gem, and other things are optional. There > is > > a thread about that optional stuff somewhere in the list. > > when I get to work I can help you find it. > > -d
> > On Mon, Aug 9, 2010 at 7:34 AM, Danny Douglass <ddougl...@gmail.com> > wrote: > > > Only the spark.dll. The other dlls are optional, based on the > > > language/framework you are utilizing. For example, if I'm creating an > > > ASP.NET MVC application and wish to utilize the Spark view engine > > > instead of the standard ASP.NET MVC view engine, I would include two > > > components: spark.dll and spark.web.mvc.dll.
> > > As I'm talking this out I think I'm approaching this the wrong way. > > > The gem would be simply the spark.dll and the other dlls would be > > > optional components. Is that more of the approach I would want to > > > take? If so, how are optional components handled, if that feature is > > > even available at this point.
> > > On Aug 9, 8:25 am, Dru Sellers <d...@drusellers.com> wrote: > > > > So, I think I am confused. > > > > Which one is the 'view engine'?
> > > > I think based on our current thinking the > > > 'Castle.MonoRail.Views.Spark.dll' > > > > would for sure go into some kind of optional folder. So if want to > use > > > the > > > > spark view engine in a console application that I am writing to build > > > pretty > > > > html reports which dlls do I need?
> > > > -d
> > > > On Mon, Aug 9, 2010 at 7:16 AM, Danny Douglass <ddougl...@gmail.com> > > > wrote: > > > > > There are actually 8 *required* DLLs, depending on the language/ > > > > > framework you are utilizing:
> > > > > My understanding is that these are the components I'd be placing > into > > > > > the *lib* directory.
> > > > > On Aug 9, 8:06 am, Dru Sellers <d...@drusellers.com> wrote: > > > > > > Just for context. What are the ~10 dlls that you need? > > > > > > -d
> > > > > > On Mon, Aug 9, 2010 at 6:50 AM, Danny Douglass < > ddougl...@gmail.com> > > > > > wrote: > > > > > > > Greetings,
> > > > > > > I've been following Nu's progress and I'm really excited about > what > > > is > > > > > > > coming out of it. I decided to give gem creation a shot by > adding > > > a > > > > > gemspec > > > > > > > for the Spark View Engine using a variety of posts:
> > > > > > > My question revolves around dependencies. The current release > of > > > the > > > > > Spark > > > > > > > view engine (1.1.0.0) includes some 154 non-required > dependencies. > > > > > There > > > > > > > are just under 10 DLLs required, depending on what language or > > > > > framework you > > > > > > > are utilizing. Based on that, those 10 DLLs would be placed in > the > > > > > *lib* directory, > > > > > > > correct? How would I approach the dependencies in this case? > > > Would I > > > > > need > > > > > > > to search rubygems.org for each dependency and add it if it > was > > > not > > > > > there? > > > > > > > That seems like a lot of work to add one gem so I'm hoping > that > > > I'm > > > > > missing > > > > > > > something. Forgive me if I'm overlooking something simple here > - > > > I'm > > > > > new to > > > > > > > the Ruby/Gem world.
> > > > > > > Thanks for all your hard work on this project. I'm really > excited > > > > > about it > > > > > > > and plan on blogging on the project once I get a more solid > > > > > understanding of > > > > > > > gem creation.
At this stage of the game, and possibly carrying forward, nu will bring over everything in the lib folder. Then actually referencing what the developer wants becomes the decision process of that developer. I think that's a fair trade off and greatly simplifies things. If someone is using spark or nhibernate, they might want to learn what they should reference.
What we've talked about is adding an include switch so you could go down to a subdirectory of the gem to get components for like net-2.0 or net-3.5 instead of both and then deleting the one you don't need.
NuForVS which Michael is working on is going to help a little with the referencing aspect of dlls that you want to bring in. That's where we are going to prescribe a best practice to make that story of getting the optionals in as well even more rock solid.
On Mon, Aug 9, 2010 at 8:33 AM, Dru Sellers <d...@drusellers.com> wrote: > So stage one, we just copy everything in the 'lib' folder over to the > project. > We are working on something more intelligent but right now all of my time > is being spent on setting up the server. > I would encourage you to try making the gem and then install it locally > with
> gem install spark.gem
> and then run 'nu install spark'
> and see what happens. > you can uninstall with 'gem uninstall spark'
> wash rinse repeat until happy. :) > -d
> On Mon, Aug 9, 2010 at 8:17 AM, Danny Douglass <ddougl...@gmail.com>wrote:
>> Thanks Dru. I found a few threads discussing the optional components, >> and form what I can tell I would structure my gem directory like the >> following with optional components:
>> then in the gem install: nu install sparkviewengine -include ???
>> I saw a few different discussions on how optional components would be >> handled, but didn't see anything that was decided. If this is going >> down the right route, how would I include the ASP.Net MVC reference as >> an optional component and *not* the ruby reference? Would all >> optional components be installed regardless?
>> On Aug 9, 8:46 am, Dru Sellers <d...@drusellers.com> wrote: >> > Yeah, the spark.dll is teh main gem, and other things are optional. >> There is >> > a thread about that optional stuff somewhere in the list. >> > when I get to work I can help you find it. >> > -d
>> > On Mon, Aug 9, 2010 at 7:34 AM, Danny Douglass <ddougl...@gmail.com> >> wrote: >> > > Only the spark.dll. The other dlls are optional, based on the >> > > language/framework you are utilizing. For example, if I'm creating an >> > > ASP.NET MVC application and wish to utilize the Spark view engine >> > > instead of the standard ASP.NET MVC view engine, I would include two >> > > components: spark.dll and spark.web.mvc.dll.
>> > > As I'm talking this out I think I'm approaching this the wrong way. >> > > The gem would be simply the spark.dll and the other dlls would be >> > > optional components. Is that more of the approach I would want to >> > > take? If so, how are optional components handled, if that feature is >> > > even available at this point.
>> > > On Aug 9, 8:25 am, Dru Sellers <d...@drusellers.com> wrote: >> > > > So, I think I am confused. >> > > > Which one is the 'view engine'?
>> > > > I think based on our current thinking the >> > > 'Castle.MonoRail.Views.Spark.dll' >> > > > would for sure go into some kind of optional folder. So if want to >> use >> > > the >> > > > spark view engine in a console application that I am writing to >> build >> > > pretty >> > > > html reports which dlls do I need?
>> > > > -d
>> > > > On Mon, Aug 9, 2010 at 7:16 AM, Danny Douglass <ddougl...@gmail.com
>> > > wrote: >> > > > > There are actually 8 *required* DLLs, depending on the language/ >> > > > > framework you are utilizing:
>> > > > > My understanding is that these are the components I'd be placing >> into >> > > > > the *lib* directory.
>> > > > > On Aug 9, 8:06 am, Dru Sellers <d...@drusellers.com> wrote: >> > > > > > Just for context. What are the ~10 dlls that you need? >> > > > > > -d
>> > > > > > On Mon, Aug 9, 2010 at 6:50 AM, Danny Douglass < >> ddougl...@gmail.com> >> > > > > wrote: >> > > > > > > Greetings,
>> > > > > > > I've been following Nu's progress and I'm really excited about >> what >> > > is >> > > > > > > coming out of it. I decided to give gem creation a shot by >> adding >> > > a >> > > > > gemspec >> > > > > > > for the Spark View Engine using a variety of posts:
>> > > > > > > My question revolves around dependencies. The current release >> of >> > > the >> > > > > Spark >> > > > > > > view engine (1.1.0.0) includes some 154 non-required >> dependencies. >> > > > > There >> > > > > > > are just under 10 DLLs required, depending on what language or >> > > > > framework you >> > > > > > > are utilizing. Based on that, those 10 DLLs would be placed >> in the >> > > > > *lib* directory, >> > > > > > > correct? How would I approach the dependencies in this case? >> > > Would I >> > > > > need >> > > > > > > to search rubygems.org for each dependency and add it if it >> was >> > > not >> > > > > there? >> > > > > > > That seems like a lot of work to add one gem so I'm hoping >> that >> > > I'm >> > > > > missing >> > > > > > > something. Forgive me if I'm overlooking something simple >> here - >> > > I'm >> > > > > new to >> > > > > > > the Ruby/Gem world.
>> > > > > > > Thanks for all your hard work on this project. I'm really >> excited >> > > > > about it >> > > > > > > and plan on blogging on the project once I get a more solid >> > > > > understanding of >> > > > > > > gem creation.
On Mon, Aug 9, 2010 at 9:26 AM, Rob Reynolds <ferventco...@gmail.com> wrote: > At this stage of the game, and possibly carrying forward, nu will bring > over everything in the lib folder. Then actually referencing what the > developer wants becomes the decision process of that developer. I think > that's a fair trade off and greatly simplifies things. If someone is using > spark or nhibernate, they might want to learn what they should reference.
> What we've talked about is adding an include switch so you could go down to > a subdirectory of the gem to get components for like net-2.0 or net-3.5 > instead of both and then deleting the one you don't need.
> NuForVS which Michael is working on is going to help a little with the > referencing aspect of dlls that you want to bring in. That's where we are > going to prescribe a best practice to make that story of getting the > optionals in as well even more rock solid.
> On Mon, Aug 9, 2010 at 8:33 AM, Dru Sellers <d...@drusellers.com> wrote:
>> So stage one, we just copy everything in the 'lib' folder over to the >> project. >> We are working on something more intelligent but right now all of my time >> is being spent on setting up the server. >> I would encourage you to try making the gem and then install it locally >> with
>> gem install spark.gem
>> and then run 'nu install spark'
>> and see what happens. >> you can uninstall with 'gem uninstall spark'
>> wash rinse repeat until happy. :) >> -d
>> On Mon, Aug 9, 2010 at 8:17 AM, Danny Douglass <ddougl...@gmail.com>wrote:
>>> Thanks Dru. I found a few threads discussing the optional components, >>> and form what I can tell I would structure my gem directory like the >>> following with optional components:
>>> then in the gem install: nu install sparkviewengine -include ???
>>> I saw a few different discussions on how optional components would be >>> handled, but didn't see anything that was decided. If this is going >>> down the right route, how would I include the ASP.Net MVC reference as >>> an optional component and *not* the ruby reference? Would all >>> optional components be installed regardless?
>>> On Aug 9, 8:46 am, Dru Sellers <d...@drusellers.com> wrote: >>> > Yeah, the spark.dll is teh main gem, and other things are optional. >>> There is >>> > a thread about that optional stuff somewhere in the list. >>> > when I get to work I can help you find it. >>> > -d
>>> > On Mon, Aug 9, 2010 at 7:34 AM, Danny Douglass <ddougl...@gmail.com> >>> wrote: >>> > > Only the spark.dll. The other dlls are optional, based on the >>> > > language/framework you are utilizing. For example, if I'm creating >>> an >>> > > ASP.NET MVC application and wish to utilize the Spark view engine >>> > > instead of the standard ASP.NET MVC view engine, I would include two >>> > > components: spark.dll and spark.web.mvc.dll.
>>> > > As I'm talking this out I think I'm approaching this the wrong way. >>> > > The gem would be simply the spark.dll and the other dlls would be >>> > > optional components. Is that more of the approach I would want to >>> > > take? If so, how are optional components handled, if that feature is >>> > > even available at this point.
>>> > > On Aug 9, 8:25 am, Dru Sellers <d...@drusellers.com> wrote: >>> > > > So, I think I am confused. >>> > > > Which one is the 'view engine'?
>>> > > > I think based on our current thinking the >>> > > 'Castle.MonoRail.Views.Spark.dll' >>> > > > would for sure go into some kind of optional folder. So if want to >>> use >>> > > the >>> > > > spark view engine in a console application that I am writing to >>> build >>> > > pretty >>> > > > html reports which dlls do I need?
>>> > > > -d
>>> > > > On Mon, Aug 9, 2010 at 7:16 AM, Danny Douglass < >>> ddougl...@gmail.com> >>> > > wrote: >>> > > > > There are actually 8 *required* DLLs, depending on the language/ >>> > > > > framework you are utilizing:
>>> > > > > My understanding is that these are the components I'd be placing >>> into >>> > > > > the *lib* directory.
>>> > > > > On Aug 9, 8:06 am, Dru Sellers <d...@drusellers.com> wrote: >>> > > > > > Just for context. What are the ~10 dlls that you need? >>> > > > > > -d
>>> > > > > > On Mon, Aug 9, 2010 at 6:50 AM, Danny Douglass < >>> ddougl...@gmail.com> >>> > > > > wrote: >>> > > > > > > Greetings,
>>> > > > > > > I've been following Nu's progress and I'm really excited >>> about what >>> > > is >>> > > > > > > coming out of it. I decided to give gem creation a shot by >>> adding >>> > > a >>> > > > > gemspec >>> > > > > > > for the Spark View Engine using a variety of posts:
>>> > > > > > > My question revolves around dependencies. The current >>> release of >>> > > the >>> > > > > Spark >>> > > > > > > view engine (1.1.0.0) includes some 154 non-required >>> dependencies. >>> > > > > There >>> > > > > > > are just under 10 DLLs required, depending on what language >>> or >>> > > > > framework you >>> > > > > > > are utilizing. Based on that, those 10 DLLs would be placed >>> in the >>> > > > > *lib* directory, >>> > > > > > > correct? How would I approach the dependencies in this case? >>> > > Would I >>> > > > > need >>> > > > > > > to search rubygems.org for each dependency and add it if it >>> was >>> > > not >>> > > > > there? >>> > > > > > > That seems like a lot of work to add one gem so I'm hoping >>> that >>> > > I'm >>> > > > > missing >>> > > > > > > something. Forgive me if I'm overlooking something simple >>> here - >>> > > I'm >>> > > > > new to >>> > > > > > > the Ruby/Gem world.
>>> > > > > > > Thanks for all your hard work on this project. I'm really >>> excited >>> > > > > about it >>> > > > > > > and plan on blogging on the project once I get a more solid >>> > > > > understanding of >>> > > > > > > gem creation.
It's sometimes a little hard for newcomers - including myself - to distinguish what's being implemented right away from what is more futuristic. Do we have - or could we get - some sort of roadmap?
On Mon, Aug 9, 2010 at 7:26 AM, Rob Reynolds <ferventco...@gmail.com> wrote: > At this stage of the game, and possibly carrying forward, nu will bring over > everything in the lib folder. Then actually referencing what the developer > wants becomes the decision process of that developer. I think that's a fair > trade off and greatly simplifies things. If someone is using spark or > nhibernate, they might want to learn what they should reference. > What we've talked about is adding an include switch so you could go down to > a subdirectory of the gem to get components for like net-2.0 or net-3.5 > instead of both and then deleting the one you don't need. > NuForVS which Michael is working on is going to help a little with the > referencing aspect of dlls that you want to bring in. That's where we are > going to prescribe a best practice to make that story of getting the > optionals in as well even more rock solid. > ____ > Rob > "Be passionate in all you do"
> On Mon, Aug 9, 2010 at 8:33 AM, Dru Sellers <d...@drusellers.com> wrote:
>> So stage one, we just copy everything in the 'lib' folder over to the >> project. >> We are working on something more intelligent but right now all of my time >> is being spent on setting up the server. >> I would encourage you to try making the gem and then install it locally >> with
>> gem install spark.gem
>> and then run 'nu install spark'
>> and see what happens. >> you can uninstall with 'gem uninstall spark'
>> wash rinse repeat until happy. :) >> -d
>> On Mon, Aug 9, 2010 at 8:17 AM, Danny Douglass <ddougl...@gmail.com> >> wrote:
>>> Thanks Dru. I found a few threads discussing the optional components, >>> and form what I can tell I would structure my gem directory like the >>> following with optional components:
>>> then in the gem install: nu install sparkviewengine -include ???
>>> I saw a few different discussions on how optional components would be >>> handled, but didn't see anything that was decided. If this is going >>> down the right route, how would I include the ASP.Net MVC reference as >>> an optional component and *not* the ruby reference? Would all >>> optional components be installed regardless?
>>> On Aug 9, 8:46 am, Dru Sellers <d...@drusellers.com> wrote: >>> > Yeah, the spark.dll is teh main gem, and other things are optional. >>> > There is >>> > a thread about that optional stuff somewhere in the list. >>> > when I get to work I can help you find it. >>> > -d
>>> > On Mon, Aug 9, 2010 at 7:34 AM, Danny Douglass <ddougl...@gmail.com> >>> > wrote: >>> > > Only the spark.dll. The other dlls are optional, based on the >>> > > language/framework you are utilizing. For example, if I'm creating >>> > > an >>> > > ASP.NET MVC application and wish to utilize the Spark view engine >>> > > instead of the standard ASP.NET MVC view engine, I would include two >>> > > components: spark.dll and spark.web.mvc.dll.
>>> > > As I'm talking this out I think I'm approaching this the wrong way. >>> > > The gem would be simply the spark.dll and the other dlls would be >>> > > optional components. Is that more of the approach I would want to >>> > > take? If so, how are optional components handled, if that feature is >>> > > even available at this point.
>>> > > On Aug 9, 8:25 am, Dru Sellers <d...@drusellers.com> wrote: >>> > > > So, I think I am confused. >>> > > > Which one is the 'view engine'?
>>> > > > I think based on our current thinking the >>> > > 'Castle.MonoRail.Views.Spark.dll' >>> > > > would for sure go into some kind of optional folder. So if want to >>> > > > use >>> > > the >>> > > > spark view engine in a console application that I am writing to >>> > > > build >>> > > pretty >>> > > > html reports which dlls do I need?
>>> > > > -d
>>> > > > On Mon, Aug 9, 2010 at 7:16 AM, Danny Douglass >>> > > > <ddougl...@gmail.com> >>> > > wrote: >>> > > > > There are actually 8 *required* DLLs, depending on the language/ >>> > > > > framework you are utilizing:
>>> > > > > My understanding is that these are the components I'd be placing >>> > > > > into >>> > > > > the *lib* directory.
>>> > > > > On Aug 9, 8:06 am, Dru Sellers <d...@drusellers.com> wrote: >>> > > > > > Just for context. What are the ~10 dlls that you need? >>> > > > > > -d
>>> > > > > > On Mon, Aug 9, 2010 at 6:50 AM, Danny Douglass >>> > > > > > <ddougl...@gmail.com> >>> > > > > wrote: >>> > > > > > > Greetings,
>>> > > > > > > I've been following Nu's progress and I'm really excited >>> > > > > > > about what >>> > > is >>> > > > > > > coming out of it. I decided to give gem creation a shot by >>> > > > > > > adding >>> > > a >>> > > > > gemspec >>> > > > > > > for the Spark View Engine using a variety of posts:
>>> > > > > > > My question revolves around dependencies. The current >>> > > > > > > release of >>> > > the >>> > > > > Spark >>> > > > > > > view engine (1.1.0.0) includes some 154 non-required >>> > > > > > > dependencies. >>> > > > > There >>> > > > > > > are just under 10 DLLs required, depending on what language >>> > > > > > > or >>> > > > > framework you >>> > > > > > > are utilizing. Based on that, those 10 DLLs would be placed >>> > > > > > > in the >>> > > > > *lib* directory, >>> > > > > > > correct? How would I approach the dependencies in this case? >>> > > Would I >>> > > > > need >>> > > > > > > to search rubygems.org for each dependency and add it if it >>> > > > > > > was >>> > > not >>> > > > > there? >>> > > > > > > That seems like a lot of work to add one gem so I'm hoping >>> > > > > > > that >>> > > I'm >>> > > > > missing >>> > > > > > > something. Forgive me if I'm overlooking something simple >>> > > > > > > here - >>> > > I'm >>> > > > > new to >>> > > > > > > the Ruby/Gem world.
>>> > > > > > > Thanks for all your hard work on this project. I'm really >>> > > > > > > excited >>> > > > > about it >>> > > > > > > and plan on blogging on the project once I get a more solid >>> > > > > understanding of >>> > > > > > > gem creation.
> It's sometimes a little hard for newcomers - including myself - to > distinguish what's > being implemented right away from what is more futuristic. Do we have - or > could > we get - some sort of roadmap?
> Charlie
> On Mon, Aug 9, 2010 at 7:26 AM, Rob Reynolds <ferventco...@gmail.com> > wrote: > > At this stage of the game, and possibly carrying forward, nu will bring > over > > everything in the lib folder. Then actually referencing what the > developer > > wants becomes the decision process of that developer. I think that's a > fair > > trade off and greatly simplifies things. If someone is using spark or > > nhibernate, they might want to learn what they should reference. > > What we've talked about is adding an include switch so you could go down > to > > a subdirectory of the gem to get components for like net-2.0 or net-3.5 > > instead of both and then deleting the one you don't need. > > NuForVS which Michael is working on is going to help a little with the > > referencing aspect of dlls that you want to bring in. That's where we are > > going to prescribe a best practice to make that story of getting the > > optionals in as well even more rock solid. > > ____ > > Rob > > "Be passionate in all you do"
> > On Mon, Aug 9, 2010 at 8:33 AM, Dru Sellers <d...@drusellers.com> wrote:
> >> So stage one, we just copy everything in the 'lib' folder over to the > >> project. > >> We are working on something more intelligent but right now all of my > time > >> is being spent on setting up the server. > >> I would encourage you to try making the gem and then install it locally > >> with
> >> gem install spark.gem
> >> and then run 'nu install spark'
> >> and see what happens. > >> you can uninstall with 'gem uninstall spark'
> >> wash rinse repeat until happy. :) > >> -d
> >> On Mon, Aug 9, 2010 at 8:17 AM, Danny Douglass <ddougl...@gmail.com> > >> wrote:
> >>> Thanks Dru. I found a few threads discussing the optional components, > >>> and form what I can tell I would structure my gem directory like the > >>> following with optional components:
> >>> then in the gem install: nu install sparkviewengine -include ???
> >>> I saw a few different discussions on how optional components would be > >>> handled, but didn't see anything that was decided. If this is going > >>> down the right route, how would I include the ASP.Net MVC reference as > >>> an optional component and *not* the ruby reference? Would all > >>> optional components be installed regardless?
> >>> On Aug 9, 8:46 am, Dru Sellers <d...@drusellers.com> wrote: > >>> > Yeah, the spark.dll is teh main gem, and other things are optional. > >>> > There is > >>> > a thread about that optional stuff somewhere in the list. > >>> > when I get to work I can help you find it. > >>> > -d
> >>> > On Mon, Aug 9, 2010 at 7:34 AM, Danny Douglass <ddougl...@gmail.com> > >>> > wrote: > >>> > > Only the spark.dll. The other dlls are optional, based on the > >>> > > language/framework you are utilizing. For example, if I'm creating > >>> > > an > >>> > > ASP.NET MVC application and wish to utilize the Spark view engine > >>> > > instead of the standard ASP.NET MVC view engine, I would include > two > >>> > > components: spark.dll and spark.web.mvc.dll.
> >>> > > As I'm talking this out I think I'm approaching this the wrong way. > >>> > > The gem would be simply the spark.dll and the other dlls would be > >>> > > optional components. Is that more of the approach I would want to > >>> > > take? If so, how are optional components handled, if that feature > is > >>> > > even available at this point.
> >>> > > On Aug 9, 8:25 am, Dru Sellers <d...@drusellers.com> wrote: > >>> > > > So, I think I am confused. > >>> > > > Which one is the 'view engine'?
> >>> > > > I think based on our current thinking the > >>> > > 'Castle.MonoRail.Views.Spark.dll' > >>> > > > would for sure go into some kind of optional folder. So if want > to > >>> > > > use > >>> > > the > >>> > > > spark view engine in a console application that I am writing to > >>> > > > build > >>> > > pretty > >>> > > > html reports which dlls do I need?
> >>> > > > -d
> >>> > > > On Mon, Aug 9, 2010 at 7:16 AM, Danny Douglass > >>> > > > <ddougl...@gmail.com> > >>> > > wrote: > >>> > > > > There are actually 8 *required* DLLs, depending on the > language/ > >>> > > > > framework you are utilizing:
> >>> > > > > My understanding is that these are the components I'd be > placing > >>> > > > > into > >>> > > > > the *lib* directory.
> >>> > > > > On Aug 9, 8:06 am, Dru Sellers <d...@drusellers.com> wrote: > >>> > > > > > Just for context. What are the ~10 dlls that you need? > >>> > > > > > -d
> >>> > > > > > > I've been following Nu's progress and I'm really excited > >>> > > > > > > about what > >>> > > is > >>> > > > > > > coming out of it. I decided to give gem creation a shot by > >>> > > > > > > adding > >>> > > a > >>> > > > > gemspec > >>> > > > > > > for the Spark View Engine using a variety of posts:
> >>> > > > > > > My question revolves around dependencies. The current > >>> > > > > > > release of > >>> > > the > >>> > > > > Spark > >>> > > > > > > view engine (1.1.0.0) includes some 154 non-required > >>> > > > > > > dependencies. > >>> > > > > There > >>> > > > > > > are just under 10 DLLs required, depending on what language > >>> > > > > > > or > >>> > > > > framework you > >>> > > > > > > are utilizing. Based on that, those 10 DLLs would be > placed > >>> > > > > > > in the > >>> > > > > *lib* directory, > >>> > > > > > > correct? How would I approach the dependencies in this > case? > >>> > > Would I > >>> > > > > need > >>> > > > > > > to search rubygems.org for each dependency and add it if > it > >>> > > > > > > was > >>> > > not > >>> > > > > there? > >>> > > > > > > That seems like a lot of work to add one gem so I'm hoping > >>> > > > > > > that > >>> > > I'm > >>> > > > > missing > >>> > > > > > > something. Forgive me if I'm overlooking something simple > >>> > > > > > > here - > >>> > > I'm > >>> > > > > new to > >>> > > > > > > the Ruby/Gem world.
> >>> > > > > > > Thanks for all your hard work on this project. I'm really > >>> > > > > > > excited > >>> > > > > about it > >>> > > > > > > and plan on blogging on the project once I get a more solid > >>> > > > > understanding of > >>> > > > > > > gem creation.
> Charlie, > That's a great idea. Let me see if I can get something up on the wiki this > week.
> On Mon, Aug 9, 2010 at 9:50 AM, Charlie Poole <charliepo...@gmail.com>wrote:
>> Hi Rob,
>> It's sometimes a little hard for newcomers - including myself - to >> distinguish what's >> being implemented right away from what is more futuristic. Do we have - or >> could >> we get - some sort of roadmap?
>> Charlie
>> On Mon, Aug 9, 2010 at 7:26 AM, Rob Reynolds <ferventco...@gmail.com> >> wrote: >> > At this stage of the game, and possibly carrying forward, nu will bring >> over >> > everything in the lib folder. Then actually referencing what the >> developer >> > wants becomes the decision process of that developer. I think that's a >> fair >> > trade off and greatly simplifies things. If someone is using spark or >> > nhibernate, they might want to learn what they should reference. >> > What we've talked about is adding an include switch so you could go down >> to >> > a subdirectory of the gem to get components for like net-2.0 or net-3.5 >> > instead of both and then deleting the one you don't need. >> > NuForVS which Michael is working on is going to help a little with the >> > referencing aspect of dlls that you want to bring in. That's where we >> are >> > going to prescribe a best practice to make that story of getting the >> > optionals in as well even more rock solid. >> > ____ >> > Rob >> > "Be passionate in all you do"
>> > On Mon, Aug 9, 2010 at 8:33 AM, Dru Sellers <d...@drusellers.com> wrote:
>> >> So stage one, we just copy everything in the 'lib' folder over to the >> >> project. >> >> We are working on something more intelligent but right now all of my >> time >> >> is being spent on setting up the server. >> >> I would encourage you to try making the gem and then install it locally >> >> with
>> >> gem install spark.gem
>> >> and then run 'nu install spark'
>> >> and see what happens. >> >> you can uninstall with 'gem uninstall spark'
>> >> wash rinse repeat until happy. :) >> >> -d
>> >> On Mon, Aug 9, 2010 at 8:17 AM, Danny Douglass <ddougl...@gmail.com> >> >> wrote:
>> >>> Thanks Dru. I found a few threads discussing the optional components, >> >>> and form what I can tell I would structure my gem directory like the >> >>> following with optional components:
>> >>> then in the gem install: nu install sparkviewengine -include ???
>> >>> I saw a few different discussions on how optional components would be >> >>> handled, but didn't see anything that was decided. If this is going >> >>> down the right route, how would I include the ASP.Net MVC reference as >> >>> an optional component and *not* the ruby reference? Would all >> >>> optional components be installed regardless?
>> >>> On Aug 9, 8:46 am, Dru Sellers <d...@drusellers.com> wrote: >> >>> > Yeah, the spark.dll is teh main gem, and other things are optional. >> >>> > There is >> >>> > a thread about that optional stuff somewhere in the list. >> >>> > when I get to work I can help you find it. >> >>> > -d
>> >>> > On Mon, Aug 9, 2010 at 7:34 AM, Danny Douglass <ddougl...@gmail.com
>> >>> > wrote: >> >>> > > Only the spark.dll. The other dlls are optional, based on the >> >>> > > language/framework you are utilizing. For example, if I'm >> creating >> >>> > > an >> >>> > > ASP.NET MVC application and wish to utilize the Spark view engine >> >>> > > instead of the standard ASP.NET MVC view engine, I would include >> two >> >>> > > components: spark.dll and spark.web.mvc.dll.
>> >>> > > As I'm talking this out I think I'm approaching this the wrong >> way. >> >>> > > The gem would be simply the spark.dll and the other dlls would be >> >>> > > optional components. Is that more of the approach I would want to >> >>> > > take? If so, how are optional components handled, if that feature >> is >> >>> > > even available at this point.
>> >>> > > On Aug 9, 8:25 am, Dru Sellers <d...@drusellers.com> wrote: >> >>> > > > So, I think I am confused. >> >>> > > > Which one is the 'view engine'?
>> >>> > > > I think based on our current thinking the >> >>> > > 'Castle.MonoRail.Views.Spark.dll' >> >>> > > > would for sure go into some kind of optional folder. So if want >> to >> >>> > > > use >> >>> > > the >> >>> > > > spark view engine in a console application that I am writing to >> >>> > > > build >> >>> > > pretty >> >>> > > > html reports which dlls do I need?
>> >>> > > > -d
>> >>> > > > On Mon, Aug 9, 2010 at 7:16 AM, Danny Douglass >> >>> > > > <ddougl...@gmail.com> >> >>> > > wrote: >> >>> > > > > There are actually 8 *required* DLLs, depending on the >> language/ >> >>> > > > > framework you are utilizing:
>> >>> > > > > My understanding is that these are the components I'd be >> placing >> >>> > > > > into >> >>> > > > > the *lib* directory.
>> >>> > > > > On Aug 9, 8:06 am, Dru Sellers <d...@drusellers.com> wrote: >> >>> > > > > > Just for context. What are the ~10 dlls that you need? >> >>> > > > > > -d
>> >>> > > > > > > I've been following Nu's progress and I'm really excited >> >>> > > > > > > about what >> >>> > > is >> >>> > > > > > > coming out of it. I decided to give gem creation a shot >> by >> >>> > > > > > > adding >> >>> > > a >> >>> > > > > gemspec >> >>> > > > > > > for the Spark View Engine using a variety of posts:
>> >>> > > > > > > My question revolves around dependencies. The current >> >>> > > > > > > release of >> >>> > > the >> >>> > > > > Spark >> >>> > > > > > > view engine (1.1.0.0) includes some 154 non-required >> >>> > > > > > > dependencies. >> >>> > > > > There >> >>> > > > > > > are just under 10 DLLs required, depending on what >> language >> >>> > > > > > > or >> >>> > > > > framework you >> >>> > > > > > > are utilizing. Based on that, those 10 DLLs would be >> placed >> >>> > > > > > > in the >> >>> > > > > *lib* directory, >> >>> > > > > > > correct? How would I approach the dependencies in this >> case? >> >>> > > Would I >> >>> > > > > need >> >>> > > > > > > to search rubygems.org for each dependency and add it if >> it >> >>> > > > > > > was >> >>> > > not >> >>> > > > > there? >> >>> > > > > > > That seems like a lot of work to add one gem so I'm >> hoping >> >>> > > > > > > that >> >>> > > I'm >> >>> > > > > missing >> >>> > > > > > > something. Forgive me if I'm overlooking something simple >> >>> > > > > > > here - >> >>> > > I'm >> >>> > > > > new to >> >>> > > > > > > the Ruby/Gem world.
>> >>> > > > > > > Thanks for all your hard work on this project. I'm really >> >>> > > > > > > excited >> >>> > > > > about it >> >>> > > > > > > and plan on blogging on the project once I get a more >> solid >> >>> > > > > understanding of >> >>> > > > > > > gem creation.
Thanks guys - I like that direction as well. I saw no problem with
everything being included, but I wanted to make sure I wasn't
"polluting" the gem, so to speak. I'll definitely work on creating
the Spark package tonight after work. I'm really excited to
contribute to this project in any way that I can. I'll keep an eye on
the youtrack site on codebetter as well.
> you can always look athttp://youtrack.codebetter.comas well for now too.
> right now its all about getting the server stood up.
> -d
> On Mon, Aug 9, 2010 at 10:04 AM, Rob Reynolds <ferventco...@gmail.com>wrote:
> > Charlie,
> > That's a great idea. Let me see if I can get something up on the wiki this
> > week.
> > On Mon, Aug 9, 2010 at 9:50 AM, Charlie Poole <charliepo...@gmail.com>wrote:
> >> Hi Rob,
> >> It's sometimes a little hard for newcomers - including myself - to
> >> distinguish what's
> >> being implemented right away from what is more futuristic. Do we have - or
> >> could
> >> we get - some sort of roadmap?
> >> Charlie
> >> On Mon, Aug 9, 2010 at 7:26 AM, Rob Reynolds <ferventco...@gmail.com>
> >> wrote:
> >> > At this stage of the game, and possibly carrying forward, nu will bring
> >> over
> >> > everything in the lib folder. Then actually referencing what the
> >> developer
> >> > wants becomes the decision process of that developer. I think that's a
> >> fair
> >> > trade off and greatly simplifies things. If someone is using spark or
> >> > nhibernate, they might want to learn what they should reference.
> >> > What we've talked about is adding an include switch so you could go down
> >> to
> >> > a subdirectory of the gem to get components for like net-2.0 or net-3.5
> >> > instead of both and then deleting the one you don't need.
> >> > NuForVS which Michael is working on is going to help a little with the
> >> > referencing aspect of dlls that you want to bring in. That's where we
> >> are
> >> > going to prescribe a best practice to make that story of getting the
> >> > optionals in as well even more rock solid.
> >> > ____
> >> > Rob
> >> > "Be passionate in all you do"
> >> > On Mon, Aug 9, 2010 at 8:33 AM, Dru Sellers <d...@drusellers.com> wrote:
> >> >> So stage one, we just copy everything in the 'lib' folder over to the
> >> >> project.
> >> >> We are working on something more intelligent but right now all of my
> >> time
> >> >> is being spent on setting up the server.
> >> >> I would encourage you to try making the gem and then install it locally
> >> >> with
> >> >> gem install spark.gem
> >> >> and then run 'nu install spark'
> >> >> and see what happens.
> >> >> you can uninstall with 'gem uninstall spark'
> >> >> On Mon, Aug 9, 2010 at 8:17 AM, Danny Douglass <ddougl...@gmail.com>
> >> >> wrote:
> >> >>> Thanks Dru. I found a few threads discussing the optional components,
> >> >>> and form what I can tell I would structure my gem directory like the
> >> >>> following with optional components:
> >> >>> then in the gem install: nu install sparkviewengine -include ???
> >> >>> I saw a few different discussions on how optional components would be
> >> >>> handled, but didn't see anything that was decided. If this is going
> >> >>> down the right route, how would I include the ASP.Net MVC reference as
> >> >>> an optional component and *not* the ruby reference? Would all
> >> >>> optional components be installed regardless?
> >> >>> On Aug 9, 8:46 am, Dru Sellers <d...@drusellers.com> wrote:
> >> >>> > Yeah, the spark.dll is teh main gem, and other things are optional.
> >> >>> > There is
> >> >>> > a thread about that optional stuff somewhere in the list.
> >> >>> > when I get to work I can help you find it.
> >> >>> > -d
> >> >>> > On Mon, Aug 9, 2010 at 7:34 AM, Danny Douglass <ddougl...@gmail.com
> >> >>> > wrote:
> >> >>> > > Only the spark.dll. The other dlls are optional, based on the
> >> >>> > > language/framework you are utilizing. For example, if I'm
> >> creating
> >> >>> > > an
> >> >>> > > ASP.NET MVC application and wish to utilize the Spark view engine
> >> >>> > > instead of the standard ASP.NET MVC view engine, I would include
> >> two
> >> >>> > > components: spark.dll and spark.web.mvc.dll.
> >> >>> > > As I'm talking this out I think I'm approaching this the wrong
> >> way.
> >> >>> > > The gem would be simply the spark.dll and the other dlls would be
> >> >>> > > optional components. Is that more of the approach I would want to
> >> >>> > > take? If so, how are optional components handled, if that feature
> >> is
> >> >>> > > even available at this point.
> >> >>> > > On Aug 9, 8:25 am, Dru Sellers <d...@drusellers.com> wrote:
> >> >>> > > > So, I think I am confused.
> >> >>> > > > Which one is the 'view engine'?
> >> >>> > > > I think based on our current thinking the
> >> >>> > > 'Castle.MonoRail.Views.Spark.dll'
> >> >>> > > > would for sure go into some kind of optional folder. So if want
> >> to
> >> >>> > > > use
> >> >>> > > the
> >> >>> > > > spark view engine in a console application that I am writing to
> >> >>> > > > build
> >> >>> > > pretty
> >> >>> > > > html reports which dlls do I need?
> >> >>> > > > -d
> >> >>> > > > On Mon, Aug 9, 2010 at 7:16 AM, Danny Douglass
> >> >>> > > > <ddougl...@gmail.com>
> >> >>> > > wrote:
> >> >>> > > > > There are actually 8 *required* DLLs, depending on the
> >> language/
> >> >>> > > > > framework you are utilizing:
> >> >>> > > > > My understanding is that these are the components I'd be
> >> placing
> >> >>> > > > > into
> >> >>> > > > > the *lib* directory.
> >> >>> > > > > On Aug 9, 8:06 am, Dru Sellers <d...@drusellers.com> wrote:
> >> >>> > > > > > Just for context. What are the ~10 dlls that you need?
> >> >>> > > > > > -d
> >> >>> > > > > > > My question revolves around dependencies. The current
> >> >>> > > > > > > release of
> >> >>> > > the
> >> >>> > > > > Spark
> >> >>> > > > > > > view engine (1.1.0.0) includes some 154 non-required
> >> >>> > > > > > > dependencies.
> >> >>> > > > > There
> >> >>> > > > > > > are just under 10 DLLs required, depending on what
> >> language
> >> >>> > > > > > > or
> >> >>> > > > > framework you
> >> >>> > > > > > > are utilizing. Based on that, those 10 DLLs would be
> >> placed
> >> >>> > > > > > > in the
> >> >>> > > > > *lib* directory,
> >> >>> > > > > > > correct? How would I approach the dependencies in this
> >> case?
> >> >>> > > Would I
> >> >>> > > > > need
> >> >>> > > > > > > to search rubygems.org for each dependency and add it if
> >> it
> >> >>> > > > > > > was
> >> >>> > > not
> >> >>> > > > > there?
> >> >>> > > > > > > That seems like a lot of work to add one gem so I'm
> >> hoping
> >> >>> > > > > > > that
> >> >>> > > I'm
> >> >>> > > > > missing
> >> >>> > > > > > > something. Forgive me if I'm overlooking something simple
> >> >>> > > > > > > here -
> >> >>> > > I'm
> >> >>> > > > > new to
> >> >>> > > > > > > the Ruby/Gem world.
> >> >>> > > > > > > Thanks for all your hard work on this project. I'm really
> >> >>> > > > > > > excited
> >> >>> > > > > about it
> >> >>> > > > > > > and plan on blogging on the project once I get a more
> >> solid
> >> >>> > > > > understanding of
> >> >>> > > > > > > gem creation.
One question I have is that when installing the sparkviewengine nu
package, my docs directory is not installed. I assume this is
intentional since I already have it installed in my ruby gems
directory. Am I correct in that assumption?
Also, I wasn't sure how samples were handled, so instead of adding n-
level of recursion in the docs directory I simply zipped up the
samples and dropped them into docs.
On Aug 9, 12:37 pm, Danny Douglass <ddougl...@gmail.com> wrote:
> Thanks guys - I like that direction as well. I saw no problem with
> everything being included, but I wanted to make sure I wasn't
> "polluting" the gem, so to speak. I'll definitely work on creating
> the Spark package tonight after work. I'm really excited to
> contribute to this project in any way that I can. I'll keep an eye on
> the youtrack site on codebetter as well.
> > On Mon, Aug 9, 2010 at 10:04 AM, Rob Reynolds <ferventco...@gmail.com>wrote:
> > > Charlie,
> > > That's a great idea. Let me see if I can get something up on the wiki this
> > > week.
> > > On Mon, Aug 9, 2010 at 9:50 AM, Charlie Poole <charliepo...@gmail.com>wrote:
> > >> Hi Rob,
> > >> It's sometimes a little hard for newcomers - including myself - to
> > >> distinguish what's
> > >> being implemented right away from what is more futuristic. Do we have - or
> > >> could
> > >> we get - some sort of roadmap?
> > >> Charlie
> > >> On Mon, Aug 9, 2010 at 7:26 AM, Rob Reynolds <ferventco...@gmail.com>
> > >> wrote:
> > >> > At this stage of the game, and possibly carrying forward, nu will bring
> > >> over
> > >> > everything in the lib folder. Then actually referencing what the
> > >> developer
> > >> > wants becomes the decision process of that developer. I think that's a
> > >> fair
> > >> > trade off and greatly simplifies things. If someone is using spark or
> > >> > nhibernate, they might want to learn what they should reference.
> > >> > What we've talked about is adding an include switch so you could go down
> > >> to
> > >> > a subdirectory of the gem to get components for like net-2.0 or net-3.5
> > >> > instead of both and then deleting the one you don't need.
> > >> > NuForVS which Michael is working on is going to help a little with the
> > >> > referencing aspect of dlls that you want to bring in. That's where we
> > >> are
> > >> > going to prescribe a best practice to make that story of getting the
> > >> > optionals in as well even more rock solid.
> > >> > ____
> > >> > Rob
> > >> > "Be passionate in all you do"
> > >> > On Mon, Aug 9, 2010 at 8:33 AM, Dru Sellers <d...@drusellers.com> wrote:
> > >> >> So stage one, we just copy everything in the 'lib' folder over to the
> > >> >> project.
> > >> >> We are working on something more intelligent but right now all of my
> > >> time
> > >> >> is being spent on setting up the server.
> > >> >> I would encourage you to try making the gem and then install it locally
> > >> >> with
> > >> >> gem install spark.gem
> > >> >> and then run 'nu install spark'
> > >> >> and see what happens.
> > >> >> you can uninstall with 'gem uninstall spark'
> > >> >> On Mon, Aug 9, 2010 at 8:17 AM, Danny Douglass <ddougl...@gmail.com>
> > >> >> wrote:
> > >> >>> Thanks Dru. I found a few threads discussing the optional components,
> > >> >>> and form what I can tell I would structure my gem directory like the
> > >> >>> following with optional components:
> > >> >>> then in the gem install: nu install sparkviewengine -include ???
> > >> >>> I saw a few different discussions on how optional components would be
> > >> >>> handled, but didn't see anything that was decided. If this is going
> > >> >>> down the right route, how would I include the ASP.Net MVC reference as
> > >> >>> an optional component and *not* the ruby reference? Would all
> > >> >>> optional components be installed regardless?
> > >> >>> On Aug 9, 8:46 am, Dru Sellers <d...@drusellers.com> wrote:
> > >> >>> > Yeah, the spark.dll is teh main gem, and other things are optional.
> > >> >>> > There is
> > >> >>> > a thread about that optional stuff somewhere in the list.
> > >> >>> > when I get to work I can help you find it.
> > >> >>> > -d
> > >> >>> > On Mon, Aug 9, 2010 at 7:34 AM, Danny Douglass <ddougl...@gmail.com
> > >> >>> > wrote:
> > >> >>> > > Only the spark.dll. The other dlls are optional, based on the
> > >> >>> > > language/framework you are utilizing. For example, if I'm
> > >> creating
> > >> >>> > > an
> > >> >>> > > ASP.NET MVC application and wish to utilize the Spark view engine
> > >> >>> > > instead of the standard ASP.NET MVC view engine, I would include
> > >> two
> > >> >>> > > components: spark.dll and spark.web.mvc.dll.
> > >> >>> > > As I'm talking this out I think I'm approaching this the wrong
> > >> way.
> > >> >>> > > The gem would be simply the spark.dll and the other dlls would be
> > >> >>> > > optional components. Is that more of the approach I would want to
> > >> >>> > > take? If so, how are optional components handled, if that feature
> > >> is
> > >> >>> > > even available at this point.
> > >> >>> > > On Aug 9, 8:25 am, Dru Sellers <d...@drusellers.com> wrote:
> > >> >>> > > > So, I think I am confused.
> > >> >>> > > > Which one is the 'view engine'?
> > >> >>> > > > I think based on our current thinking the
> > >> >>> > > 'Castle.MonoRail.Views.Spark.dll'
> > >> >>> > > > would for sure go into some kind of optional folder. So if want
> > >> to
> > >> >>> > > > use
> > >> >>> > > the
> > >> >>> > > > spark view engine in a console application that I am writing to
> > >> >>> > > > build
> > >> >>> > > pretty
> > >> >>> > > > html reports which dlls do I need?
> > >> >>> > > > -d
> > >> >>> > > > On Mon, Aug 9, 2010 at 7:16 AM, Danny Douglass
> > >> >>> > > > <ddougl...@gmail.com>
> > >> >>> > > wrote:
> > >> >>> > > > > There are actually 8 *required* DLLs, depending on the
> > >> language/
> > >> >>> > > > > framework you are utilizing:
> > >> >>> > > > > My understanding is that these are the components I'd be
> > >> placing
> > >> >>> > > > > into
> > >> >>> > > > > the *lib* directory.
> > >> >>> > > > > On Aug 9, 8:06 am, Dru Sellers <d...@drusellers.com> wrote:
> > >> >>> > > > > > Just for context. What are the ~10 dlls that you need?
> > >> >>> > > > > > -d
> One question I have is that when installing the sparkviewengine nu > package, my docs directory is not installed. I assume this is > intentional since I already have it installed in my ruby gems > directory. Am I correct in that assumption?
> Also, I wasn't sure how samples were handled, so instead of adding n- > level of recursion in the docs directory I simply zipped up the > samples and dropped them into docs.
> On Aug 9, 12:37 pm, Danny Douglass <ddougl...@gmail.com> wrote: > > Thanks guys - I like that direction as well. I saw no problem with > > everything being included, but I wanted to make sure I wasn't > > "polluting" the gem, so to speak. I'll definitely work on creating > > the Spark package tonight after work. I'm really excited to > > contribute to this project in any way that I can. I'll keep an eye on > > the youtrack site on codebetter as well.
> > > On Mon, Aug 9, 2010 at 10:04 AM, Rob Reynolds <ferventco...@gmail.com > >wrote:
> > > > Charlie, > > > > That's a great idea. Let me see if I can get something up on the > wiki this > > > > week.
> > > > On Mon, Aug 9, 2010 at 9:50 AM, Charlie Poole < > charliepo...@gmail.com>wrote:
> > > >> Hi Rob,
> > > >> It's sometimes a little hard for newcomers - including myself - to > > > >> distinguish what's > > > >> being implemented right away from what is more futuristic. Do we > have - or > > > >> could > > > >> we get - some sort of roadmap?
> > > >> Charlie
> > > >> On Mon, Aug 9, 2010 at 7:26 AM, Rob Reynolds < > ferventco...@gmail.com> > > > >> wrote: > > > >> > At this stage of the game, and possibly carrying forward, nu will > bring > > > >> over > > > >> > everything in the lib folder. Then actually referencing what the > > > >> developer > > > >> > wants becomes the decision process of that developer. I think > that's a > > > >> fair > > > >> > trade off and greatly simplifies things. If someone is using spark > or > > > >> > nhibernate, they might want to learn what they should reference. > > > >> > What we've talked about is adding an include switch so you could > go down > > > >> to > > > >> > a subdirectory of the gem to get components for like net-2.0 or > net-3.5 > > > >> > instead of both and then deleting the one you don't need. > > > >> > NuForVS which Michael is working on is going to help a little with > the > > > >> > referencing aspect of dlls that you want to bring in. That's where > we > > > >> are > > > >> > going to prescribe a best practice to make that story of getting > the > > > >> > optionals in as well even more rock solid. > > > >> > ____ > > > >> > Rob > > > >> > "Be passionate in all you do"
> > > >> > On Mon, Aug 9, 2010 at 8:33 AM, Dru Sellers <d...@drusellers.com> > wrote:
> > > >> >> So stage one, we just copy everything in the 'lib' folder over to > the > > > >> >> project. > > > >> >> We are working on something more intelligent but right now all of > my > > > >> time > > > >> >> is being spent on setting up the server. > > > >> >> I would encourage you to try making the gem and then install it > locally > > > >> >> with
> > > >> >> gem install spark.gem
> > > >> >> and then run 'nu install spark'
> > > >> >> and see what happens. > > > >> >> you can uninstall with 'gem uninstall spark'
> > > >> >> On Mon, Aug 9, 2010 at 8:17 AM, Danny Douglass < > ddougl...@gmail.com> > > > >> >> wrote:
> > > >> >>> Thanks Dru. I found a few threads discussing the optional > components, > > > >> >>> and form what I can tell I would structure my gem directory like > the > > > >> >>> following with optional components:
> > > >> >>> then in the gem install: nu install sparkviewengine -include ???
> > > >> >>> I saw a few different discussions on how optional components > would be > > > >> >>> handled, but didn't see anything that was decided. If this is > going > > > >> >>> down the right route, how would I include the ASP.Net MVC > reference as > > > >> >>> an optional component and *not* the ruby reference? Would all > > > >> >>> optional components be installed regardless?
> > > >> >>> On Aug 9, 8:46 am, Dru Sellers <d...@drusellers.com> wrote: > > > >> >>> > Yeah, the spark.dll is teh main gem, and other things are > optional. > > > >> >>> > There is > > > >> >>> > a thread about that optional stuff somewhere in the list. > > > >> >>> > when I get to work I can help you find it. > > > >> >>> > -d
> > > >> >>> > On Mon, Aug 9, 2010 at 7:34 AM, Danny Douglass < > ddougl...@gmail.com
> > > >> >>> > wrote: > > > >> >>> > > Only the spark.dll. The other dlls are optional, based on > the > > > >> >>> > > language/framework you are utilizing. For example, if I'm > > > >> creating > > > >> >>> > > an > > > >> >>> > > ASP.NET MVC application and wish to utilize the Spark view > engine > > > >> >>> > > instead of the standard ASP.NET MVC view engine, I would > include > > > >> two > > > >> >>> > > components: spark.dll and spark.web.mvc.dll.
> > > >> >>> > > As I'm talking this out I think I'm approaching this the > wrong > > > >> way. > > > >> >>> > > The gem would be simply the spark.dll and the other dlls > would be > > > >> >>> > > optional components. Is that more of the approach I would > want to > > > >> >>> > > take? If so, how are optional components handled, if that > feature > > > >> is > > > >> >>> > > even available at this point.
> > > >> >>> > > On Aug 9, 8:25 am, Dru Sellers <d...@drusellers.com> wrote: > > > >> >>> > > > So, I think I am confused. > > > >> >>> > > > Which one is the 'view engine'?
> > > >> >>> > > > I think based on our current thinking the > > > >> >>> > > 'Castle.MonoRail.Views.Spark.dll' > > > >> >>> > > > would for sure go into some kind of optional folder. So if > want > > > >> to > > > >> >>> > > > use > > > >> >>> > > the > > > >> >>> > > > spark view engine in a console application that I am > writing to > > > >> >>> > > > build > > > >> >>> > > pretty > > > >> >>> > > > html reports which dlls do I need?
> > > >> >>> > > > -d
> > > >> >>> > > > On Mon, Aug 9, 2010 at 7:16 AM, Danny Douglass > > > >> >>> > > > <ddougl...@gmail.com> > > > >> >>> > > wrote: > > > >> >>> > > > > There are actually 8 *required* DLLs, depending on the > > > >> language/ > > > >> >>> > > > > framework you are utilizing:
