aquarium 0.5.1 → 0.7.1

data/README

@@ -7,6 +7,18 @@ Aquarium is a toolkit for Aspect-Oriented Programming (AOP) whose goals include:
 * A user-friendly DSL.
 * Support for advising Java types through JRuby.
 
+=== SOMEBODY ADOPT ME!!
+
+While I've enjoyed working on Aquarium, I no longer do Ruby development. I just don't have the time to keep updating Aquarium as Ruby evolves. There are plenty of deprecation warnings now when you build Aquarium and JRuby support has been spotty since Aquarium v0.6.0.
+
+=== Supported Ruby Versions (and Caveats)
+
+Aquarium v0.7.0 was tested with Ruby 2.6.3p62 (2019-04-16 revision 67580) and JRuby 9.2.7.0 (Ruby 2.5.3) 2019-04-09 8a269e3. There are many deprecation warnings about constants that have been renamed, all of which appear to be in old libraries still used by Aquarium.
+
+Aquarium v0.6.0 supports only Ruby 2.0.0p247. JRuby 1.7.4 (Ruby 1.9.3p392) does *not* currently pass all the custom Java specs in the `jruby/spec` directory, which specifically test working with Java classes. However, JRuby does pass all the Ruby specs in the `spec` directory. I didn't want to release v0.6.0 with the Java-specific specs not working, but I didn't have time to resolve the issues. Patches are welcome.
+
+If you need support for even earlier versions of Ruby and JRuby, use Aquarium v0.5.0.
+
 === Why Is an AOP Framework Useful in Ruby?
 
 Ruby's metaprogramming facilities already provide some of the capabilities for which static-language AOP toolkits like AspectJ are typically used. With Ruby, you can easily add new methods and attributes to existing classes and objects. You can alias and redefine existing methods, which provides the method interception and "wrapping" needed to extend or modify existing behavior.
@@ -35,7 +47,6 @@ Only around advice can prevent execution of the join point, except for the speci
 * You cannot advice "String", "Symbol" or instances there of, because trying to specify either one will be confused with naming a type.
 * Concurrent advice on type AND advice on objects of the type can't be removed cleanly.
 * The pointcut language is still limited, compared to AspectJ's. See also the comparison with AspectJ behavior next.
-* The API and wrapper DSL will probably evolve until the 1.0.0 release. Backwards compatibility will be maintained between releases as much as possible. When it is necessary to break backwards compatibility, translation tools will be provided, if possible.
 * There are limitations when advising Java types through JRuby. The separate RSpec suite in the "jruby" directory documentations the details on how to use Aquarium with JRuby-wrapped Java types and the limitations thereof. Here we summarize what works and what doesn't:
   * Aquarium advice on a method in a Java type will only be invoked when the method is called directly from Ruby.
   * To have the advice invoked when the method is called from either Java or Ruby, it is necessary to create a subclass of the Java type in Ruby and an override of the method, which can just call "super". Note that it will be necessary for instances of this Ruby type to be used throughout, not instances of a Java parent type.
@@ -51,19 +62,19 @@ The goal of Aquarium is to provide a superset of the functionality provided by t
 === Differences With AspectJ Behavior
 
 Many of AspectJ's features are not currently supported by Aquarium, but some of them are planned for future releases.
- 
-* Attribute reading and writing join points are not supported. The :attributes and :attributes_options parameters (and their synonyms) for Aspect.new are actually "syntactic sugar" for the corresponding accessor methods. 
+
+* Attribute reading and writing join points are not supported. The :attributes and :attributes_options parameters (and their synonyms) for Aspect.new are actually "syntactic sugar" for the corresponding accessor methods.
 * More advanced AspectJ pointcut language features are not supported, such as the runtime pointcut designators like "if" conditionals and "cflow" (context flow) and the compile time "within" and "withincode" designators. Most of AspectJ pointcut language features are planned, however.
 * While AspectJ provides "intertype declaration" capabilities (i.e., adding state and behavior to existing classes), Ruby's native metaprogramming support satisfies this need. There may be convenience hooks added in a future release, however.
-* User defined advice precedence is not supported. However, advice precedence is unambiguous; the last aspects created while modules are loaded at runtime have higher precedence than earlier aspects. Ensuring a particular order is not always easy, of course. 
+* User defined advice precedence is not supported. However, advice precedence is unambiguous; the last aspects created while modules are loaded at runtime have higher precedence than earlier aspects. Ensuring a particular order is not always easy, of course.
 
 However, Aquarium does have a few advantages over AspectJ, especially when advising Java types when running in JRuby.
 
 * Aquarium can add and remove advice dynamically, at runtime.
 * Aquarium can advise individual objects, not just classes.
 * Aquarium can advise JDK classes. AspectJ can also do this, but not by default.
-* Aquarium supports named advice that can be defined separately from the aspects that use the advice. 
-* Aquarium can advise ancestor (parent) types, not just derived (descendent) types of specified types. 
+* Aquarium supports named advice that can be defined separately from the aspects that use the advice.
+* Aquarium can advise ancestor (parent) types, not just derived (descendent) types of specified types.
 
 Note: at the time of this writing (V0.4.0 release), there is an important limitation of Aquarium when used with java code; it appears that advice is only invoked if an advised method is called directly from Ruby code. If the advised method is called by other Java code, the advice is *not* invoked. Whether or not this limitation can be removed is under investigation.
 
@@ -134,7 +145,7 @@ If you use the DSL inside a class and omit the :type(s) and :object(s) options,
 It is important to note that aspect "instances" usually behave like class (static) variables, in terms of the lifetime of their effects. In the example shown, class Foo is permanently modified to do the print statements shown for all "critical methods", unless you save the result of calling "around" to a variable, e.g., critical_operation_logging, and you explicitly call "critical_operation_logging.unadvise" at some future time. Put another way, the effects scope just like changes made when you reopen a class or module.
 
 A common mistake is to create an aspect in an initialize method and assign it to an attribute. This usually means that you are creating long-lived, redundant aspects every time an instance of your class is created. The aspect modifications remain in effect even when the instances themselves are garbage collected!
- 
+
 Here are some more succinct examples, illustrating the API (using the DSL methods) and some of the various synonyms for methods, types, etc.
 
 You can pass in pointcuts defined elsewhere:
@@ -147,8 +158,8 @@ As a convenience, since a JoinPoint is a Pointcut with one element, you can pass
 
 my_join_point1 = JoinPoint.new :type => Foo::Bar, :method => do_this
 my_join_point2 = JoinPoint.new :type => Foo::Bar, :method => do_that
-around :pointcuts => my_join_point1 do |jp, obj, *args| ...         
-around :pointcuts => [my_join_point1, my_join_point2, ...] do |jp, obj, *args| ...  
+around :pointcuts => my_join_point1 do |jp, obj, *args| ...
+around :pointcuts => [my_join_point1, my_join_point2, ...] do |jp, obj, *args| ...
 
 You can specify a single type, a type name, a type regular expression, or an array of the same. Note that :type and :types are synonymous. Use the singular form for better readability when you are specifying just one type. Other synonyms include :on_types, :within_types, and :in_types, plus the singular forms.
 
@@ -189,8 +200,8 @@ Some of the synonyms:
 	around :calls_to => :all_methods, :in_types_and_ancestors = A, ...
 	around :calls_to => :all_methods, :within_types_and_ancestors = A, ...
 	and similarly for descendents
-	
-You can specify a single object or an array of objects. As for :types, you can use :object, :objects, :on_objects, :within_object, :in_objects, and the singular forms synonymously. 
+
+You can specify a single object or an array of objects. As for :types, you can use :object, :objects, :on_objects, :within_object, :in_objects, and the singular forms synonymously.
 
 	a1 = A.new
 	a2 = A.new
@@ -208,7 +219,7 @@ If no types or objects are specified, the object defaults to "self". However, th
 	class MyClass
 		include Aquarium::DSL
 		def doit; ...; end
-	
+
 		around :method => doit, ...   # Implicit :object => self, i.e., MyClass
 	end
 
@@ -232,15 +243,15 @@ You can specify method options. By default, public instance methods only are mat
 
 	around :methods = /foo/, :method_options => [:instance], ...  # match instance methods (default)
 	around :methods = /foo/, :method_options => [:class], ...     # match class methods
-	around :methods = /foo/, :method_options => [:public, :protected, :private], ... 
+	around :methods = /foo/, :method_options => [:public, :protected, :private], ...
 		# match public, protected, and private instance methods
 	around :methods = /foo/, :method_options => [:singleton], ... # match singleton methods
-	around :methods = /foo/, :method_options => [:exclude_ancestor_methods], ... 
-		# ignore methods defined in ancestors, inherited classes and included modules 
+	around :methods = /foo/, :method_options => [:exclude_ancestor_methods], ...
+		# ignore methods defined in ancestors, inherited classes and included modules
 
 With synonyms:
 
-	around :calls_to = /foo/, :restricting_methods_to => [:singleton_methods], ... 
+	around :calls_to = /foo/, :restricting_methods_to => [:singleton_methods], ...
 
 You can specify attributes, which are actually convenience methods for the attribute accessors. They work very much like the :method options. Note that :all is NOT supported in this case. The available synonyms are slightly more complicated, as shown in these examples.
 
@@ -248,11 +259,11 @@ You can specify attributes, which are actually convenience methods for the attri
 	around :attributes = :foo, ...                                 # the same
 	around :accessing  = :foo, ...                                 # the same
 
-	around :attribute = :foo, :attribute_options => [:readers]...  # only matches #foo 
+	around :attribute = :foo, :attribute_options => [:readers]...  # only matches #foo
 	around :reading   = :foo                                       # the same
-	
-	
-	around :attribute = :foo, :attribute_options => [:writers]...  # only matches #foo= 
+
+
+	around :attribute = :foo, :attribute_options => [:writers]...  # only matches #foo=
 	around :writing   = :foo                                       # the same
 
 	around :attributes = [:foo, :bar, :baz], ...
@@ -282,10 +293,10 @@ in an around advice aspect will match all of them:
 
 	around :named_pointcuts => { :constants_matching => :STATE_CHANGE, :in_types => /App::.*/ } ...
 
-For the type specification, which is required, any valid option for the TypeFinder class is allowed. 
+For the type specification, which is required, any valid option for the TypeFinder class is allowed.
 
 You can also match on class variables, using ":class_variables_matching". To match on either kind of definition, use just
-":matching". If no :*matching is specified, then any class constant or variable Pointcut found will be matched. 
+":matching". If no :*matching is specified, then any class constant or variable Pointcut found will be matched.
 
 Here are the variaus :*matching options and their synonyms:
 
@@ -314,7 +325,7 @@ You can also use the following synonyms for :named_pointcuts:
 	around :on_named_pointcuts => {...}
 	around :in_named_pointcuts => {...}
 	around :within_named_pointcuts => {...}
-	
+
 You can specifically exclude particular pointcuts, join points, types, objects, methods, or attributes. This is useful when you specify a list or regular expression of "items" to match and you want to exclude some of the items.
 Note that there is an open bug (#15202) that appears to affect advising types, unadvising the types, then advising objects of the same types. (This is not likely to happen a lot in real applications, but it shows up when running Aquarium's specs.)
 
@@ -347,21 +358,21 @@ You can advice methods after returning successfully (i.e., no exceptions were ra
 
 	after_returning :types => ...
 	after_returning_from :types => ...	# synonym
-	
+
 You can advice methods after raising exceptions:
 
 	after_raising :types => ...              # After any exception is thrown
 	after_raising_within :types => ...       # synonym
 	after_raising => MyError, :types => ...  # Only invoke advice if "MyError" is raised.
-	after_raising => [MyError1, MyError2], :types => ...  
+	after_raising => [MyError1, MyError2], :types => ...
 		# Only invoke advice if "MyError1" or "MyError2" is raised.
-	 
+
 You can advice methods after returning successfully or raising exceptions. (You can't specify
 a set of exceptions in this case.):
 
 	after :types => ...
 	after_raising_within_or_returning_from : types =>	# synonym
-	
+
 You can advice methods both before after. This is different from around advice, where the around advice has to explicitly invoke the join point (using JoinPoint#proceed). Instead, the before-and-after methods are convenience wrappers around the creation of separate before advice and the corresponding after advice.
 
 	before_and_after :types =>, ...
@@ -371,10 +382,10 @@ You can advice methods both before after. This is different from around advice,
 	before_and_after_raising_within :types =>, ...	# synonym
 	before_and_after_raising_within_or_returning_from :types =>, ...	# synonym
 
-If you pass a block to Aspect.new, it will be the advice. When invoked, the advice will be passed the following three arguments, 
-	1) the JoinPoint, which will contain a JoinPoint::Context object with useful context information, 
-	2) the object being sent the current message, and 
-	3) the parameters passed with the original message. 
+If you pass a block to Aspect.new, it will be the advice. When invoked, the advice will be passed the following three arguments,
+	1) the JoinPoint, which will contain a JoinPoint::Context object with useful context information,
+	2) the object being sent the current message, and
+	3) the parameters passed with the original message.
 Recall that a Proc doesn't check the number of arguments (while lambdas do), so if you don't care about any of the trailing parameters, you can leave them out of the parameter list. Recall that the other difference between the two is that a return statement in a Proc returns from the method that contains it. As rule, do NOT use return statements in advices!
 
 	around :type => [...], :methods => :all do |join_point, object, *args|
@@ -388,10 +399,10 @@ Recall that a Proc doesn't check the number of arguments (while lambdas do), so
 In the example, we show that you must be careful to return the correct value, usually the value returned by "proceed" or a value created by the block itself.
 
 Note, prior to V0.2.0, the advice argument list was |join_point, *args|. Aquarium will look for such obsolete signatures (by looking at the arity of the proc) and raise an exception, if found. This check will be removed in a future release.
- 
+
 Rather than passing a block as the advice, you can pass a previously-created Proc:
-	
-	around :type => [...], :methods => :all, :advice => advice 
+
+	around :type => [...], :methods => :all, :advice => advice
 	around :type => [...], :methods => :all, :advise_with => advice  # synonym for advice. Note the "s"!
 	around :type => [...], :methods => :all, :call => advice         # synonym for advice.
 	around :type => [...], :methods => :all, :invoke => advice       # synonym for advice.
@@ -420,12 +431,19 @@ The simplest approach is to install the gem:
 
 If you prefer to build the gem locally, clone from GitHub,
 
-    git clone git://github.com/deanwampler/Aquarium.git 
+    git clone git://github.com/deanwampler/Aquarium.git
 
 Then do the following:
 
-    rake gem
-    gem install pkg/aquarium-x.y.z.gem   # sudo may be required
+    rake install
+
+This builds the gem file, pkg/aquarium-x.y.z.gem, and installs it locally.
+
+If you are a maintainer and want to upload a new version to RubyGems.org, first see [this page](https://guides.rubygems.org/make-your-own-gem/) for creating a `~/.gem/credentials` file, then run this command to publish a new version.
+
+    gem push pkg/aquarium-0.7.0.gem
+
+At this time, with the demise of RubyForge, the docs and home page are temporarily hosted at https://deanwampler.github.io/open-source/aquarium/index.html. I'll move them to a better location soon. I build them by running `rake website`, then copying the entire output of `../doc/aquarium/out/` to my GitHub site under the `open-source/Aquarium` directory. TBD - move somewhere better!
 
 == Running Aquarium's RSpec Specs
 
@@ -433,14 +451,14 @@ In order to run Aquarium's full suite of specs (rake pre_commit) you must instal
 
 * rake          # Runs the build script
 * rspec         # Used instead of Test::Unit for TDD
-* rcov          # Verifies that the code is 100% covered by specs
+* rcov          # For running coverage checks
 * webgen        # Generates the static HTML website
+* bundler       # Gem manager
 * coderay       # Required by webgen
 * diff-lcs      # Required if you use the --diff switch
 * win32console  # Required by the --colour switch if you're on Windows
-* meta_project  # Required in order to make releases at RubyForge
 * heckle        # Required if you use the --heckle switch
-* jruby         # Required if run the separate spec suite in the "jruby" directory (v1.3+)
+* jruby         # Required if run the separate spec suite in the "jruby" directory
 
 Once those are all installed, you should be able to run the suite with the following steps:
 
@@ -452,13 +470,13 @@ or
 
 Note that Aquarium itself - once built - doesn't have any dependencies outside the Ruby core and stdlib.
 
-If you want to run the tests for the JRuby support, you must also have JRuby 1.1RC2 or later installed. To run the specs for JRuby, use the command
+If you want to run the tests for the JRuby support, you must also have JRuby installed (see version information above). To run the specs for JRuby, use the command
 
 * rake verify_jruby
 
 This command runs the standard Aquarium specs using JRuby instead of MRI, then runs a separate set of specs in the "jruby/spec" directory which test Aquarium with Java classes inside JRuby.
 
-See http://aquarium.rubyforge.org for further documentation.
+> **WARNING:** Currently, not all JRuby-specific specs pass!
 
 === Acknowledgments
 
@@ -468,5 +486,4 @@ The RSpec team, in particular David Chelimsky, have really inspired my thinking
 
 Keita Yamaguchi contributed some key patches that enabled Ruby 1.9.3 and JRuby 1.6.7 support, in addition to the prior support for Ruby 1.8.7. These patches allowed me to final release version 0.5.X. Thank you!
 
-Finally, a number of users have contributed valuable feedback. In particular, thanks to Brendan L., Matthew F., and Mark V. 
- 
+Finally, a number of users have contributed valuable feedback. In particular, thanks to Brendan L., Matthew F., and Mark V.

data/RELEASE-PLAN

@@ -6,26 +6,26 @@ Mostly bug fixes and enhancements. Only "minor" breakages of backwards compatibi
 
 === Versions 0.2
 
-Change the argument list for advice to |join_point, object, *args| from |join_point, *args|, 
-where "*args" are the arguments passed to the invoked join point (method). Since nontrivial 
-advice usually needs the object being advised, it became clear that having to call 
-"join_point.context.advised_object" is too tedious. 
+Change the argument list for advice to |join_point, object, *args| from |join_point, *args|,
+where "*args" are the arguments passed to the invoked join point (method). Since nontrivial
+advice usually needs the object being advised, it became clear that having to call
+"join_point.context.advised_object" is too tedious.
 
 This change will obvious break existing aspects.
 
 === Versions 0.3+
 
-More refinements and simplifications to the API and functionality, including much-needed 
+More refinements and simplifications to the API and functionality, including much-needed
 redundancy reduction. I haven't used mocks much in the specs, but they would help improve the
-performance of the RSpec runs. 
+performance of the RSpec runs.
 
-The main thrust of new feature work will be expanding the pointcut language to include 
-conditionals and stack context constructs, as well as more intuitive ways of expressing sets of 
-types, such as types nested arbitrarily deep in module "namespaces" (e.g., #13403), etc. 
+The main thrust of new feature work will be expanding the pointcut language to include
+conditionals and stack context constructs, as well as more intuitive ways of expressing sets of
+types, such as types nested arbitrarily deep in module "namespaces" (e.g., #13403), etc.
 
 I'm also thinking about an alternative syntax for the DSL. Instead of just this:
 
-	Aspect.new :around :pointcuts => [pc1, pc2, ...] do |jp, object, *args| 
+	Aspect.new :around :pointcuts => [pc1, pc2, ...] do |jp, object, *args|
 		# advise
 	end
 
@@ -33,12 +33,12 @@ How about something like the following?
 
 	around do
  		pointcuts pc1 or pc2
- 		advise_with do |jp, object, *args| 
+ 		advise_with do |jp, object, *args|
 			# advise
 		end
 	end
 
-I'm not sure it adds much (at this stage of thinking about it...) except that it could make 
+I'm not sure it adds much (at this stage of thinking about it...) except that it could make
 composition of complex pointcuts easier.
 
 I also want to ensure full support for running in JRuby. In particular, you should be able to
@@ -47,13 +47,13 @@ advise Java types!
 === Version 0.5
 
 My goals for this release include more performance improvements (#19321) and investigating some ideas
-for a real DSL, meaning declarative statements in blocks, rather than method arguments. It will be 
+for a real DSL, meaning declarative statements in blocks, rather than method arguments. It will be
 redundant somewhat with the existing "method-argument form", as it exists today, but it will set
 the stage for much more complex aspect definitions than would be convenient with the current form.
 
 Another big change is to make pointcut evaluation and advice application happen continuous at runtime,
 rather than only when the aspect is defined. This would eliminate subtle problems related to the order
-of loading and also makes the declarative nature of aspects more fully realized. For example, if I 
+of loading and also makes the declarative nature of aspects more fully realized. For example, if I
 declare an aspect for all types in a module namespace, it should still apply to nested types defined
 or loaded after the aspect is defined. This enhancement will also make it easier to define reusable
 and "abstract" aspects, where they aren't applied immediately, but only when extended by "concrete"
@@ -64,16 +64,14 @@ simpler aspects.
 
 Finally, this release will finally support Ruby 1.9.X and the latest JRuby at the time of the release.
 
-=== Version 0.6+
+=== Version 0.6.X and 0.7.X
+
+These releases updated to the latest with Ruby and JRuby versions without other significant changes.
+
+=== Version 1.0+
 
 I have been thinking about higher-order abstractions that work above the "Pointcut + Advice
-Model" of Aquarium (and AspectJ...) today. I consider the pointcut + advice model to be an 
+Model" of Aquarium (and AspectJ...) today. I consider the pointcut + advice model to be an
 important, maybe essential, building block of AOP, but if that's all AOP is, then we've probably
-already hit the limit of what we can expect AOP to do. That doesn't seem right to me, but it's 
+already hit the limit of what we can expect AOP to do. That doesn't seem right to me, but it's
 not at all clear what the higher-order abstractions should be.
-	
-=== Version 1.0.0
-
-Reasonably stable and full-featured API and DSL. Also, to justify Aquarium's existence ;), I want
-to produce some non-trivial examples of refactoring known APIs and demonstrating improved clarity,
-productivity, modularity, etc., etc.

data/Rakefile

@@ -1,9 +1,9 @@
 $:.unshift('lib')
 require 'rubygems'
 require 'rake'
-require 'rake/gempackagetask'
-require 'rake/contrib/rubyforgepublisher'
 require 'rake/clean'
+require "bundler/gem_tasks"
+require 'rake/packagetask'
 require 'rdoc/task'
 require 'aquarium/version'
 
@@ -20,8 +20,8 @@ PKG_VERSION   = Aquarium::VERSION::STRING
 PKG_FILE_NAME = "#{PKG_NAME}-#{PKG_VERSION}"
 PKG_FILES = FileList[
   '[A-Z]*',
-  'lib/**/*.rb', 
-  'spec/**/*.rb', 
+  'lib/**/*.rb',
+  'spec/**/*.rb',
   'examples/**/*.rb',
   'rake_tasks/**/*.rake'
 ]
@@ -29,71 +29,20 @@ FileUtils.touch(File.dirname(__FILE__) + '/previous_failures.txt')
 
 IS_WINDOWS = (RUBY_VERSION == "1.8.7" ? PLATFORM : RUBY_PLATFORM) =~ /mswin/
 
-task :default => :spec  
+WEBSITE_ROOT = "../doc/aquarium"
+
+task :default => :spec
 
 desc "Run all specs"
 RSpec::Core::RakeTask.new do |t|
   t.rspec_opts = ['--color', '--format progress', '--profile']
 end
 
-# desc "Run all specs and store html output in doc/aquarium/out/report.html"
-# RSpec::Core::RakeTask.new('spec_html') do |t|
-#   t.rspec_opts = ['--format html:../doc/aquarium/out/report.html','--backtrace']
-# end
-
-desc 'Generate HTML documentation for website'
-task :webgen do
-  Dir.chdir '../doc/aquarium' do
-    output = nil
-    IO.popen('rake webgen 2>&1') do |io|
-      output = io.read
-    end
-    raise "ERROR while running webgen: #{output}" if output =~ /ERROR/n || $? != 0
-  end
-end
-
-desc 'Generate RDoc'
-rd = Rake::RDocTask.new do |rdoc|
-  rdoc.rdoc_dir = '../doc/aquarium/out/rdoc'
-  rdoc.options << '--title' << 'Aquarium' << '--line-numbers' << '--inline-source' << '--main' << 'README'
-  rdoc.rdoc_files.include('README', 'CHANGES', 'MIT_LICENSE', 'examples/**/*.rb', 'UPGRADE', 'lib/**/*.rb') # 'EXAMPLES.rd'
-end
-
-# desc "Generate EXAMPLES.rb"
-# task :rdoc do
-#   core.rdoc
-# end
-
-aquarium = Gem::Specification.new do |s|
-  s.name = PKG_NAME
-  s.version = PKG_VERSION
-  s.summary = Aquarium::VERSION::DESCRIPTION
-  s.description = <<-EOF
-    Aquarium is a full-featured Aspect-Oriented Programming (AOP) framework for Ruby that is 
-    designed to provide an intuitive syntax and support for large-scale, dynamic aspects.
-  EOF
-
-  s.files = PKG_FILES.to_a
-  s.require_path = 'lib'
-
-  s.has_rdoc = true
-  s.rdoc_options = rd.options
-  s.extra_rdoc_files = rd.rdoc_files.reject { |fn| fn =~ /\.rb$|^EXAMPLES.rd$/ }.to_a
-  
-  s.autorequire = 'aquarium'
-  s.bindir = 'bin'
-  s.executables = []
-  s.default_executable = ''
-  s.authors = ["Aquarium Development Team"]
-  s.email = "aquarium-devel@rubyforge.org"
-  s.homepage = "http://aquarium.rubyforge.org"
-  s.rubyforge_project = "aquarium"
-end
-
-Rake::GemPackageTask.new(aquarium) do |pkg|
-  pkg.need_zip = true
-  pkg.need_tar = true
-end
+Rake::PackageTask.new("aquarium", "#{Aquarium::VERSION::STRING}") do |p|
+   p.need_zip = true
+   p.need_tar = true
+   p.package_files = `git ls-files`.split("\n")
+ end
 
 def egrep(pattern)
   Dir['**/*.rb'].each do |fn|
@@ -115,12 +64,15 @@ task :todo do
 end
 
 task :clobber do
-  rm_rf '../doc/aquarium/out'
-  rm_rf '../doc/aquarium/webgen.cache'
+  rm_rf "#{WEBSITE_ROOT}/out"
+  rm_rf "#{WEBSITE_ROOT}/webgen/out"
+  rm_rf "#{WEBSITE_ROOT}/webgen/tmp"
   rm_rf 'translated_specs'
 end
 
-task :release => [:clobber, :verify_committed, :verify_user, :spec, :publish_packages, :tag, :publish_website, :publish_news]
+task :release => [:clobber, :verify_committed, :verify_user, :spec, :package_release]
+
+task :package_release => [:website, :install, :package, :publish_packages, :tag, :publish_website, :publish_news]
 
 # TODO!
 desc "Verifies that there is no uncommitted code"
@@ -132,37 +84,55 @@ task :verify_committed do
   end
 end
 
-# TODO!
 desc "Creates a tag in git"
 task :tag do
-end
+  `git tag #{Aquarium::VERSION::TAG}`
+end
+
+# desc "Creates a tag in svn (obsolete)"
+# task :svntag do
+#   from = `svn info #{File.dirname(__FILE__)}`.match(/URL: (.*)\/aquarium/n)[1]
+#   to = from.gsub(/trunk/, "tags/#{Aquarium::VERSION::TAG}")
+#   tag_cmd = "svn cp #{from} #{to} -m \"Tag release #{Aquarium::VERSION::FULL_VERSION}\""
+#   raise "Can't tag to the same place: #{tag_cmd}" if to == from
+#   puts "Creating tag in SVN"
+#   `#{tag_cmd}`
+#   raise "Tagging failed" unless $? == 0
+# end
 
-desc "Creates a tag in svn (obsolete)"
-task :svntag do
-  from = `svn info #{File.dirname(__FILE__)}`.match(/URL: (.*)\/aquarium/n)[1]
-  to = from.gsub(/trunk/, "tags/#{Aquarium::VERSION::TAG}")
-  tag_cmd = "svn cp #{from} #{to} -m \"Tag release #{Aquarium::VERSION::FULL_VERSION}\""
-  raise "Can't tag to the same place: #{tag_cmd}" if to == from
-  puts "Creating tag in SVN"
-  `#{tag_cmd}`
-  raise "Tagging failed" unless $? == 0
+desc "Build the website, but do not publish it"
+task :website => [:clobber, :rdoc, :webgen, :stage_website]
+
+desc 'Generate HTML documentation for website'
+task :webgen do
+  puts "In #{WEBSITE_ROOT}, running 'rake webgen':"
+  Dir.chdir "#{WEBSITE_ROOT}" do
+    output = nil
+    IO.popen('rake webgen 2>&1') do |io|
+      output = io.read
+    end
+    if $? != 0
+      puts "ERROR while running webgen: #{output}"
+      raise "ERROR while running webgen"
+    end
+  end
 end
 
-# TODO: adapt from rspec.
-# desc "Run this task before you commit. You should see 'OK TO COMMIT'"
-# task :pre_commit => [
-#   :website,
-#   :examples
-# ]
+desc 'Generate RDoc'
+rd = Rake::RDocTask.new do |rdoc|
+  rdoc.rdoc_dir = "#{WEBSITE_ROOT}/out/rdoc"
+  rdoc.options << '--title' << 'Aquarium' << '--line-numbers' << '--main' << 'README'
+  rdoc.rdoc_files.include('README', 'CHANGES', 'MIT_LICENSE', 'examples/**/*.rb', 'UPGRADE', 'lib/**/*.rb') # 'EXAMPLES.rd'
+end
 
-desc "Build the website, but do not publish it"
-task :website => [:clobber, :rdoc, :webgen] # :spec_html, :verify_jruby, :verify_rcov,
+task :stage_website do
+  # Hack so that cp_r works correctly:
+  mv "#{WEBSITE_ROOT}/out/", "#{WEBSITE_ROOT}/out-tmp/"
+  puts "cp_r #{WEBSITE_ROOT}/webgen/out, #{WEBSITE_ROOT}/out"
+  cp_r "#{WEBSITE_ROOT}/webgen/out", "#{WEBSITE_ROOT}/out"
+  mv "#{WEBSITE_ROOT}/out-tmp/rdoc", "#{WEBSITE_ROOT}/out"
+  rmdir "#{WEBSITE_ROOT}/out-tmp/"
 
-task :rdoc_rails do
-  Dir.chdir '../aquarium_on_rails' do
-    rake = IS_WINDOWS ? "rake.cmd" : "rake"
-    `#{rake} rdoc`
-  end
 end
 
 desc "Verify that the Aquarium specs run under JRuby and that JRuby can advise Java types. If this task fails, try running 'jruby -S rake' separately."
@@ -173,7 +143,7 @@ task :verify_jruby do
     sh "jruby -S #{rake}"
   end
 end
-    
+
 
 task :verify_user do
   raise "RUBYFORGE_USER environment variable not set!" unless ENV['RUBYFORGE_USER']
@@ -189,7 +159,7 @@ task :do_publish_website do
     publisher = Rake::SshDirPublisher.new(
       "#{host}",
       "/var/www/gforge-projects/#{PKG_NAME}",
-      "../doc/aquarium/out"
+      "#{WEBSITE_ROOT}/out"
     )
     publisher.upload
   else
@@ -204,7 +174,7 @@ task :archive_website => [:verify_user, :website] do
   publisher = Rake::SshDirPublisher.new(
     "#{host}",
     "/var/www/gforge-projects/#{PKG_NAME}/#{Spec::VERSION::TAG}",
-    "../doc/aquarium/out"
+    "#{WEBSITE_ROOT}/out"
   )
   publisher.upload
 end
@@ -241,7 +211,7 @@ task :publish_packages => [:verify_user, :package] do
       *release_files
     )
     publisher.upload
-    
+
     puts "UPLADED THE FOLLOWING FILES:"
     release_files.each do |file|
       name = file.match(/pkg\/(.*)/)[1]