fubumvcarchive / bottles Goto Github PK

Isn't doing any real harm, but it'll throw someone off if they look close.

May not be a problem, but let's consider this later.

Nice to do

You have to explicitly set a attribute
You have to explicitly add the

Make it "just work"

Anybody object? And while we're at it, make sure that this nuget is made with the right source of the Bottles.dll that ilmerges the Ionic.Zip.dll file? Strong name problems are still killing us with ripple local

Becomes obsolete as we move over to gem-ified bottles

Currently the bottle file structure is quite rigid, and should be more dynamic. However this is going to be a larger change that I think I want to happen as a part of the Bottles 2.0 push. It will stream line the code and allow more extensibility but I want to have a clear demarcation to help support people moving from old to new.

right now the folders are hard coded into easy to access for the programmer properties. I am thinking of easy ways that can be use to assist the programmer and the people that use them. I will put thoughts here as I ponder the issue.

Has problems right now.

Given the following command line:
``C:\hudson\workspace\StoryTeller>package\bottlerunner.exe deploy -profile assets -deployment package\deployment -override root:\blue-assets`

I want to say:
-override root:c:\blue-assets

but it fails because the code does a split on the : character.

A place to track the things that I want to do before 1.0

Causes a near infinite loop in some scenarios

This is ultimately caused by the fact that SettingsData uses a Cache which uses a Dictionary<string, object>
So currently, this data needs to be captured at the HostReader point of entry. I will report more as I dig deeper.

It's coming up way too often. Be nice to say: "I need to run before/after this other activator"

When you bottles link a project that uses the FubuModule assembly attribute the bottle gets double register which messes things up.

The expected behavior should be that the development link should override the FubuModule

Need to add the Bottles.Docs project back to the solution as well

Works like a charm without fail locally. Wasted too much time on this so far.

That way we can blow away existing installs in testing more easily.

if you put a CommandLineDeployer directive in a host file twice it doesn't work.
if you put a CommandLineDeployer directive in two host files named the same for different recipes it doesn't work.

This is causing more harm than good. With the duplicate package problem we've hit with [FubuModule], the ultimate fix includes making the assembly file explosion be lazy to make the linking a [FubuModule] work.

i.e. The files cannot be exploded until the last moment

Storyteller nuget doesn't exist yet, so no hurries

If you have a folder structure like so:

mybottle\
     .package-manifest
     \config\
           file1.txt
           file2.txt

And you run bottles create on that, you will end up with a mybottle.zip with the following structure:

mybottle.zip\
     .package-manifest
     \Config\
           \config\
               file1.txt
               file2.txt

(note the double "config" folder)

From what I understand, this is not desired behavior. The resulting Zip file should only have a single "Config" folder underneath it.

The '-target' option for the 'create' command in BottleRunner.exe only allows 'Debug' or 'Release', which means that other project configurations can't be targeted.

Ideally, any valid compilation target for the assemblies being packaged could be targeted.

This one is going to be tricky. This was caught by IPackageInfo not giving easy access to the ConfigFileSet. That is my real goal.

• need tests on the integration with the embedded resource PackageManifest
• need tests on AssemblyPackageManifestFactory
• need tests against the integration with BottleAttribute

Gonna be a lot of work, but still

I am attempting to utilize the multiple cores on our build machines to speed up out CI build time. In this attempt I tried to bottle up multiple features at a time run spooling up a number of threads for each processor that I have on those machines. This occasionally gives me an error because the .version file in the temporary directory is in use by another process.

I am interested in working on a fix for this, but didn't want to step on your toes if there was a deeper underlying reason to the way you've implemented it. My proposed solution is to create a nested temporary directory within the user's temp directory, and perform all bottle operations for the given run within that sandbox. I don't believe this would cause any conflicts with the current implementation, I would just like a confirmation before continuing.

Thanks,
Matt Smith

It's been almost 2 1/2 years since Bottles was written and I don't remember the exact reason we did this, but assemblies loaded by Bottles from outside the bin path are copied into the bin path. This is KILLING other functionality for FubuDocs and very likely hoses Serenity too.

Let's try to eliminate this.

NOTE: This is just the display, the deployment works correctly

When running this command:
C:\hudson\workspace\StoryTeller>package\bottlerunner.exe deploy -profile assets -deployment package\deployment -override root:\blue-assets

I see the following in the output:

Deploying profile assets
  from deployment directory package\deployment
  to target directory c:\DovetailSoftware
  ...

It proceeds to install to c:\blue-assets, which is correct. It's just the logging output that is incorrect

I think we need to consider this.

Too much noise

Add a command line command that will dump the config data to the terminal for analysis

It's generic and I found myself copying/pasting

Write a test that does an initialize on a new assembly, builds the bottles, attaches to an app, and can load the contents.

Just getting it ready for bottles bundle

Set up an assembly package with the default PackageManifest that excludes "data/.", but with no /data folder. Today this blows up.

Think about how to make this work well with any view engine.

I am thinking of prompting for options.

The Bottles command reference needs to be documented.