Hi,
OK then, we'll set up a wiki page for future directions of RI configuration
(Robert, you may create a simple blank page as you think is fit, I'll add
content to that step by step), but, to keep the wiki from becoming too bloated,
I'd suggest that the wiki should refect
only the ideas that first gather some general consensus within the mailing list.
So by now I propose to just focus a little more and try out to figure out a good
API for configuring RI right away. For that matter, I'm sure that exposing
War::Configuration directly causes more trouble than it is worth, DSL or not.
In fact, The War::Configuration was never meant to be exposed and has served
well till now.
The new module could be War::Configuration::API as a place to store
'public methods', and maybe a War::Configuration::Internal to store what we
have now. I'm not proposing to 'forbid' War::Configuration::Internal,
only it must be used with some cautions.
What do you think?
Cheers
Fausto.
On 4/25/07, Robert Egglestone <[EMAIL PROTECTED]> wrote:
>
> In order to make Maven less visible, I'm wondering if we should drop the
> Maven library, and just have an optional group attribute on the JavaLibrary
> class.
> If the group and version are set, then it would have enough information to
> search the Maven repositories if needed.
>
> As far as the configuration goes, I see two problems:
>
> + The methods in War::Configuration are not good. Most methods were just
> quickly put in there, and not much thought has been given to what methods we
> really want to expose, what parameters should be optional, etc. In order
> words, we haven't clearly defined what should be in there, which is
> something that needs to happen if that class is directly exposed to users,
> and we have to start worrying about compatibility of the config files across
> versions.
>
> + Partially because of the previous point, the methods between the DSL and
> the configuration are inconsistent.
>
> So first, I think we should clearly define in the wiki the methods on the
> configuration class that we want to expose to users.
>
> After that, it all becomes a decision of which syntax people prefer.
> We could even support both syntaxes, and have the DSL autogenerate its
> keywords from the public methods on the config class, so we only need to
> change things in one place.
>
> Cheers,
> Robert
>
>
>
>
> Fausto Lelli wrote:
> Hi guys,
> thanks for these suggestions !
> Robert and I have already had some discussion about these topics,
> here's what came about:
>
> 1)
>
>
>
> config.libraries << JettyLibrary('mysql-connector-java',
> '5.0.5')
>
> That's what I'm heading too: internally we define three objects:
> JavaLibrary with attributes ' attr_accessor :config, :identifier,
> :locations, :versions'
> a MavenLibray < JavaLibrary (with some behavioural differences) and
> a JettyLibrary < MavenLibrary ( same as MavenLibrary?)
>
> Here's the JavaLibrary constructor, can interpretate this for yourself
> of course:
> def initialize(config, identifier, args = nil)
> @config = config
> @identifier = identifier
> @versions = args[:versions] if args and args[:versions].is_a?(Array)
> @versions = [args[:versions]]if args and args[:versions].is_a?(String)
> @versions ||= []
> @locations = args[:locations] if args and args[:locations].is_a?(Array)
> @locations = [args[:locations]] if args and args[:locations].is_a?(String)
> @locations ||= []
> @searcheable_locations = []
> end
>
> 2)
> DSL stuff. On the contrary I think dsl should *insulate* people from
> internal configuration
> changes. i.e:
>
>
>
> War::Configuration.define do |config|
> config.libraries << JettyLibrary('mysql-connector-java',
> '5.0.5')
> config.gems << "tzinfo"
> config.gems.delete_if {|l| l.name == "ActiveRecord-JDBC"}
> end
>
> reduces to :
>
> libraries << JettyLibrary('mysql-connector-java','5.0.5')
> gems << 'tzinfo'
> gems.delete_if....
>
> ----
> or even
>
> jetty_libraries << lib :mysql-connection, :versions => '5.0.5','5.0.4'
>
> ecc. since all config methods are public noone is keeping some to use
> directly the config api.
>
> 3)
>
>
> We could have the plugin's install.rb download files from the net,
> rather than bundling them.
>
> It is true that the local mave repo is used as a 'cache', and this is
> more of a side
> effect that a wanted feature. Problems is, where do we store these jars ?
>
> 4) I'd love to open a space to discuss about RI api-usability issues,
> what do you
> think is the most proficient way ? maybe a wiki page to gather all these
> ideas.
>
> Please express your opinions so we may get a better functionaly for
> everyone.
>
> Cheers,
> Fausto.
>
>
>
>
> On 4/24/07, Nick Sieger <[EMAIL PROTECTED]> wrote:
>
>
> On 4/24/07, Jon Tirsen <[EMAIL PROTECTED]> wrote:
>
>
> Ok, here's a better patch to solve the problem of needing richer
> control of the War::Configuration object than what is exposed by the
> "DSL" class.
>
> The new format looks something like this:
> War::Configuration.define do |config|
> config.add_jetty_library('mysql-connector-java', '5.0.5')
> config.add_jetty_library('jetty', '6.1.1', ['vendor/jetty'])
> config.add_jetty_library('jetty-naming', '6.1.1', ['vendor/jetty'])
> config.add_jetty_library('jetty-plus', '6.1.1', ['vendor/jetty'])
> config.add_jetty_library('jetty-util', '6.1.1', ['vendor/jetty'])
> config.add_jetty_library('servlet-api-2.5', '6.1.1', ['vendor/
> jetty'])
> config.add_jetty_library('start', '6.1.1', ['vendor/jetty']))
> config.remove_gem('ActiveRecord-JDBC') # we already have this in
> vendor
>
> config.jetty_port = '8081'
> config.jetty_java_opts = "-Xmx512m"
> end
>
> I like this quite a bit. What do you think of something like this:
>
> War::Configuration.define do |config|
> config.libraries << JettyLibrary('mysql-connector-java',
> '5.0.5')
> config.gems << "tzinfo"
> config.gems.delete_if {|l| l.name == "ActiveRecord-JDBC"}
> end
>
>
>
> (Btw, this is a neat way to remove dependency on a local maven
> repository. We simply check in the jar files so that our project is
> ready to run straight out of the Subversion repo.)
>
> Agree, we need to be more flexible here and not let any maven-isms leak
> through.
>
>
>
> It is still fully backwards compatible but I think it would be a good
> idea to remove the previous DSL stuff as this completely supersedes
> it. I can update the example applications if people point out which
> one needs to be updated.
>
> I agree, we're early in the adoption curve for rails-integration and
> could still make a few changes.
>
>
>
> I think it would be a great idea to distribute all the jar files
> (jruby, jetty and maybe derby or a mysql driver) required to get a
> Rails application up and running with the plugin. We do want it to be
> zero effort to get Rails up and running with JRuby. (Which is
> currently not the case.) This would also completely remove the Maven
> dependency, Rails people will want to install Maven.
>
> We could have the plugin's install.rb download files from the net,
> rather than bundling them.
>
> /Nick
> _______________________________________________
> Jruby-extras-devel mailing list
> [email protected]
> http://rubyforge.org/mailman/listinfo/jruby-extras-devel
>
>
> _______________________________________________
> Jruby-extras-devel mailing list
> [email protected]
> http://rubyforge.org/mailman/listinfo/jruby-extras-devel
>
>
> _______________________________________________
> Jruby-extras-devel mailing list
> [email protected]
> http://rubyforge.org/mailman/listinfo/jruby-extras-devel
>
_______________________________________________
Jruby-extras-devel mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/jruby-extras-devel
