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
