Project Model and Task Helpers - Simple Looking vs. Actual Representation

[Luke Bayes]

Hey Folks,

I'm hoping to have a discussion with everyone about a few issues that seem to consistently cause problems for new (and even experienced) users.

* Project Model: The original idea behind the project model, was that one could configure this entity and simply point compile tasks at it. As it turns out, we have at least one user having problems with the 'Stinkleton' nature of the current implementation, and most (if not all) users struggling to figure out which attributes are available on the Project Model, and which are not. I've been struggling to keep the PM interface up to date with MXMLC, and haven't even really attempted to keep it relevant for AS2, AIR, AsDoc, COMPC, etc.

* Task Helpers (debug, test, ci, deploy, document): I love how these things make our default rakefile *look* simple, but they seem to cause more confusion than they save. They basically hide complexity that seems to make it much more difficult to later understand what's going on.

Assuming other folks agree that these are in fact problems, I'd like to propose a few ideas:

* Backwards compatibility will remain a high priority and none of these changes will break existing build scripts.

* We keep the ProjectModel around to continue supporting our generators (which do use it), but minimize it's usage in default Rakefiles. Ultimately, I'd like to move away from the ProjectModel altogether, but I'm still struggling with how to configure generators. Perhaps another discussion?

* We deprecate the Task Helpers, and move our default rakefile to a more appropriate, full configuration.

* We introduce a new model that is mainly just for ToolTasks (mainly compilers). This model would be dynamic and the base tool task can check to see if there are any of these entities in it's prerequisites list. When found, it will compare it's own concrete params with those that have been set on the model, applying any that match. Of course, values found in the model can be overridden in the closure that's passed to the tool task instance.

I happen to have an initial implementation of just such a model in the latest release of the sprout gem (http://gemcutter.org/gems/sprout)

I also have a proposal for a new default rakefile here:

http://gist.github.com/221569

Please let me know any thoughts, concerns or questions you may have regarding these changes.

Thanks,

Luke

[Stray]

Hi Luke - this all looks like it's heading in the right direction to me.

I was going to do some work on RobotLegs / sprouts bundle and was planning on doing exactly what you mention - putting the tasks direct in the rake file so that the complexity isn't hidden.

I agree that deprecating the project model is a good idea - in my first couple of days of sprouts usage last weekend I found I was confused about what to put in the model and what to put in the task.. that confusion could be removed as you say.

Thanks for this!

[Luke Bayes]

Hey Stray,

While we work this out, you should feel free to use the gist that I posted as a starting point for your bundle.

Thanks!

Luke

[Stray]

Great - thanks, I've picked it up!