Re: [VOTE] Buildr 1.4.21 release
Since you're doing small incremental improvements, Antoine integrated a PR for Antwrap that gets rid of deprecation warnings when used with Juby. Buildr under JRuby also prints these warnings every time it's run. Might be nice to bump the Antwrap dependency to resolve this. Pepijn On 28/11/14 14:11, Peter Donald wrote: Hi, This release does not really include anything other than small incremental improvements but I thought it would be good to get a another release out. FWIW the tests are all green [1] and I have tested it with all our our local builds. [1] https://travis-ci.org/apache/buildr On Sat, Nov 29, 2014 at 12:09 AM, Peter Donald pe...@realityforge.org wrote: We're voting on the source distributions available here: http://people.apache.org/~donaldp/buildr/1.4.21/dist/ Specifically: http://people.apache.org/~donaldp/buildr/1.4.21/dist/buildr-1.4.21.tgz http://people.apache.org/~donaldp/buildr/1.4.21/dist/buildr-1.4.21.zip The documentation generated for this release is available here: http://people.apache.org/~donaldp/buildr/1.4.21/site/ http://people.apache.org/~donaldp/buildr/1.4.21/site/buildr.pdf The following changes were made since 1.4.20: * Change: Update the gwt addon to add the validation dependencies required for GWT compiles without requiring that the user specify the dependency. * Change: Update ipr.add_gwt_configuration method to support GWT 2.7 configuration parameters and IDEA 14 parameters. * Change: Upgrade jacoco to 0.7.2. Submitted by neher. * Change: Update checkstyle addon to use Checkstyle 6.0. * Added: Updated the gwt addon to support the upcoming GWT 2.7.x release. * Change: Enhance ipr.add_glassfish_configuration to support the ability to define the version of GlassFish in uses. Change the default to 4.1.0 as that is the latest supported variant. * Fixed: Change the name of the GlassFish install in ipr.add_glassfish_configuration to use the same convention that IDEA uses by default. i.e. Name the installation GlassFish 4.1.0 rather than Glassfish 4.1.0. * Change: Change the default version of the jdk in IDEA project files to 1.7. * Change: Change the default version of the IDEA project files created to the current release version 13. To revert to the older versions specify ipr.version = '12' in your buildfile. * Added: Enhance the IdeaFile class to easily support mixing in of custom components from either the filesystem or from an artifact. * Change: Update rjb to version 1.5.1. * Added: Update checkstyle addon to support downloading checkstyle checks as an artifact. * Added: Update checkstyle addon to supply checkstyle.config.dir property. * Added: Update pmd addon to support downloading rule files as an artifact. * Change: Update pmd addon to use pmd version 5.1.3. * Fixed: BUILDR-702 - Retain Unix permission flags when merging zip files into another zip or tar archive. Submitted by Pepijn Van Eeckhoudt.
Re: [VOTE] Buildr 1.4.20 release
On 2014-08-25 23:14, Peter Donald wrote: I merged in that pull request, tested it locally and pushed a new release candidate up. If you could verify the package works as expected that would be great.. Works perfectly for my projects. Pepijn On Mon, Aug 25, 2014 at 9:35 PM, Pepijn Van Eeckhoudt pep...@vaneeckhoudt.net wrote: Hi Peter, Is it too late to sneak https://github.com/apache/buildr/pull/14 in? Thanks, Pepijn On 2014-08-23 06:33, Peter Donald wrote: Hi, I would like to get this release out as soon as possible as the previous release has problems with the latest version of jruby which seems to have impacted a few people. I am also going offline after next Thursday and if possible it would be great to get a release out before then or have someone else pick up the release instead. Our CI builds [1] are looking much better and all green. But it would still be good to have people test this particular build across a number of environments. Thanks! [1] https://travis-ci.org/apache/buildr/builds/33342231 On Sat, Aug 23, 2014 at 2:29 PM, Peter Donald pe...@realityforge.org wrote: We're voting on the source distributions available here: http://people.apache.org/~donaldp/buildr/1.4.20/dist/ Specifically: http://people.apache.org/~donaldp/buildr/1.4.20/dist/buildr-1.4.20.tgz http://people.apache.org/~donaldp/buildr/1.4.20/dist/buildr-1.4.20.zip The documentation generated for this release is available here: http://people.apache.org/~donaldp/buildr/1.4.20/site/ http://people.apache.org/~donaldp/buildr/1.4.20/site/buildr.pdf The following changes were made since 1.4.19: * Fixed : Work around bug/feature of jruby 1.7.13 that caches Gem::Version objects based on constructor parameters that causes issues with Buildr as we mutate the version objects through monkey patching. * Change: Upgrade rjb dependency to 1.4.9. * Change: BUILDR-701 - Update to JUnit 4.11. Submitted by Jean-Philippe Caruana. * Added: Support the 'report_level' property on findbugs addon. * Change: Update the findbugs addon to use the 3.0.0 version of Findbugs. * Change: Update the findbugs addon to use the built-in findbugs stylesheet to generate the html report. * Fixed: Ensure that the 'source_paths' and 'extra_dependencies' properties in the findbugs addon does not contain arrays or nils. * Fixed: Ensure that the 'single_intermediate_layout' addon removes the top level target and reports directories during 'clean' phase. * Added: Enhance idea project generation of ejb facet by looking for ejb descriptors in location compatible with ejb-jars. * Fixed: Ensure that the 'source_paths' property in the pmd addon does not contain arrays or nils. -- Cheers, Peter Donald
Re: [VOTE] Buildr 1.4.20 release
Hi Peter, Is it too late to sneak https://github.com/apache/buildr/pull/14 in? Thanks, Pepijn On 2014-08-23 06:33, Peter Donald wrote: Hi, I would like to get this release out as soon as possible as the previous release has problems with the latest version of jruby which seems to have impacted a few people. I am also going offline after next Thursday and if possible it would be great to get a release out before then or have someone else pick up the release instead. Our CI builds [1] are looking much better and all green. But it would still be good to have people test this particular build across a number of environments. Thanks! [1] https://travis-ci.org/apache/buildr/builds/33342231 On Sat, Aug 23, 2014 at 2:29 PM, Peter Donald pe...@realityforge.org wrote: We're voting on the source distributions available here: http://people.apache.org/~donaldp/buildr/1.4.20/dist/ Specifically: http://people.apache.org/~donaldp/buildr/1.4.20/dist/buildr-1.4.20.tgz http://people.apache.org/~donaldp/buildr/1.4.20/dist/buildr-1.4.20.zip The documentation generated for this release is available here: http://people.apache.org/~donaldp/buildr/1.4.20/site/ http://people.apache.org/~donaldp/buildr/1.4.20/site/buildr.pdf The following changes were made since 1.4.19: * Fixed : Work around bug/feature of jruby 1.7.13 that caches Gem::Version objects based on constructor parameters that causes issues with Buildr as we mutate the version objects through monkey patching. * Change: Upgrade rjb dependency to 1.4.9. * Change: BUILDR-701 - Update to JUnit 4.11. Submitted by Jean-Philippe Caruana. * Added: Support the 'report_level' property on findbugs addon. * Change: Update the findbugs addon to use the 3.0.0 version of Findbugs. * Change: Update the findbugs addon to use the built-in findbugs stylesheet to generate the html report. * Fixed: Ensure that the 'source_paths' and 'extra_dependencies' properties in the findbugs addon does not contain arrays or nils. * Fixed: Ensure that the 'single_intermediate_layout' addon removes the top level target and reports directories during 'clean' phase. * Added: Enhance idea project generation of ejb facet by looking for ejb descriptors in location compatible with ejb-jars. * Fixed: Ensure that the 'source_paths' property in the pmd addon does not contain arrays or nils. -- Cheers, Peter Donald
JRuby specific system in core/util.rb
Does anyone remember why the jruby specific system workaround using FFI was done in core/util.rb? This has the annoying side effect on windows of bringing up a new console window for the subprocess everytime it is run. Seems to work fine with the non-jruby specific variant as well. Pepijn
JMock in java/tests.rb
The JUnit and TestNG support automatically pull in JMock without an option to disable this. Any idea why this is done? It seems rather arbitrary to pull in one specific testing library. This is causing problems in my builds because jmock pulls in hamcrest 1.1 while my unit tests depend on hamcrest 1.2. Anyone against removing this or at least making it optional? Pepijn
Re: Releasing 1.4.7 -- was: [VOTE] Buildr 1.4.7 RC1
On 08/02/2012 17:56, Antoine Toulme wrote: Please go ahead. Our son showed up last week and I'm busy changing diapers for the foreseeable future. Congratulations. I know the feeling. OS contributions grind to a halt when newborns arrive :) Pepijn: can you file an issue with the JRuby/Rubygems warning you're seeing? Just to make sure I can reproduce the same and address the issue. The cause of the warning was the usage of deprecated rubygems API. Peter Donald resolved this already as part of BUILDR-601/602. Application#listed_gems is using the non-deprecated API now. Pepijn
Android extension (WIP)
Hi all, I've made a buildr extension that provides an 'apk' package type that can be used for Android development. It's built on top of the standard Android SDK command line tools and supports (I think at least) most of what the Android Ant stuff supports. So far I've only tested it with my own limited set of projects though. Is there any interest in this? If so, would anyone care to review what I have so far? I would be happy to contribute this for integration in Buildr. Regards, Pepijn
Re: Packaging with sources
I would handle that by making a new package type. You can do that by implementing a package_as_type method. This method can create a preconfigured JarTask that includes both the clj source files and the class files by including both the target and source of the compile task. buildr/java/packaging.rb contains the package_as_jar implementation. That's probably the closest to what you want. Pepijn On 16 Jul 2010, at 08:20, Chris Dean ctd...@sokitomi.com wrote: I'm working on adding Clojure support and have a question about packaging. One common way to package up Clojure projects is put both the Clojure .clj source files and all the .class files in a single jar file. Can someone give me some pointers on how to do that? Cheers, Chris Dean
Re: Functional testing of RC4
Could you guys review this patch? This seems to solve both cases. I'll
attach it to the relvant issue if this is considered a good fix.
The patch adds a defined? method to Project. The post condition of
Project.project then becomes that Project.defined? will return true. A
project is considered defined if it's definition has been executed. What
is not guaranteed is that the definition of each sub project has been
executed. AFAICT this shouldn't be a problem and is most likely what we
want in the first place.
Pepijn
On 13/6/2010 19:14, Rhett Sutphin wrote:
Hi Pepijn,
On Jun 13, 2010, at 5:34 AM, Pepijn Van Eeckhoudt wrote:
I haven't checked yet but it seems as if project() is checking that all
projects in the hierarchy are defined (i.e., the define task has been invoked).
In a way -- it is invoking the associated rake task for each referenced
project. The project rake task executes #define and rake prevents any given
task from being executed more than once.
Wouldn't it be sufficient to only ensure the leaf of the path is defined and
ignore the state of any parents? That would solve the problem you're describing.
It would solve the particular example I laid out in the message, yes. It would not solve
the example in BUILDR-454, unless you also change the way buildr ensure[s] the leaf
of the path is defined.
Rhett
Pepijn
Op 13-jun-2010 om 05:12 heeft Rhett Sutphinrh...@detailedbalance.net het
volgende geschreven:\
Hi,
(Note: very long. Buildr committers: before you tl;dr, please consider the
section after the at the end.)
On Jun 12, 2010, at 2:26 PM, Pepijn Van Eeckhoudt wrote:
I suspected 399 might have something to do with the cycle stuff that's been
popping up. I still think the fix for 399 itself is correct though; the only
difference is cycles are now being correctly detected where they previously
might not have been.
I guess it depends on how you define correctly. The way buildr 1.4.0
behaves, it is more awkward/less clear to use subprojects as namespaces: you can't
express sibling dependencies by qualified name. The example I gave in BUILDR-454 was the
minimal one I could reproduce, but this alternative example might show better why this is
undesirable:
define psc do
define authentication do
define plugin-api do
end
define cas-plugin do
compile.with project(authentication:plugin-api)
end
end
define web do
compile.with project(authentication:plugin-api)
end
end
1.4.0 fails on loading this buildfile where 1.3.5 does not:
RuntimeError : Circular dependency detected: TOP = psc = psc:authentication =
psc:authentication:local-plugin = psc:authentication
There isn't actually a dependency from psc:authentication:local-plugin to
psc:authentication, though. psc:authentication doesn't even have any packages
or tasks, so it's nonsense (and therefore frustrating) for buildr to claim that
there is a circular dependency there.
As I indicated in the ticket for BUILDR-454, you can work around this by using
project.parent.project('plugin-api'), but that's awkward. You can also work
around it by defining cas-plugin like so:
define cas-plugin do
compile.with project(plugin-api)
end
which is less awkward (though still potentially unclear: what if there are
several plugin APIs in my project?), but it doesn't make sense that one works
and the other one doesn't. After all, they both resolve to the same project.
This could come across as a regression to a user of buildr though. Any idea how
to fix it?
Between BUILDR-454, BUILDR-320, and the problems Antoine referred to earlier in
the thread, it seems like buildr's circular dependency detection is flawed[1].
Last time I looked into it, it seemed like it was inherited from rake. Perhaps
its a mistake to have the projects themselves defined as separate rake tasks?
The alternative I've come up with is also flawed, but I'll describe it in case
if gives someone a better idea:
Instead of using rake tasks for #defines, build up a graph of project
instances. When a define is encountered:
* Add a disconnected node for it to the graph
* Evaluate its body (but not any included defines), turning #project references
into edges in the graph
- If the referenced project exists in the graph, return it
- If it doesn't, return a lazy proxy
* Perform a topological sort of the graph at this point to determine if any
cycles exist. (RGL[2] has an implementation.)
* If there are no cycles, recurse into the child defines and evaluate them the
same way
(Note in particular that the parent-child relationship does not become a graph edge in this scheme,
unless there's an explicit dependency from one to the other. However, that relationship would
still need to be separately maintained in order for things like project.projects(foo,
bar) to work.)
I see one flaw in this approach: it precludes meaningful[3] forward references
in #define. However, buildr already has problems
Re: Functional testing of RC4
Please disregard the first patch. I accidently attached my first attempt
at a fix which wasn't quite correct. Here's the correct patch that
actually matches what I described below. Sorry for the mixup.
Pepijn
On 14/6/2010 10:50, Pepijn Van Eeckhoudt wrote:
Could you guys review this patch? This seems to solve both cases. I'll
attach it to the relvant issue if this is considered a good fix.
The patch adds a defined? method to Project. The post condition of
Project.project then becomes that Project.defined? will return true. A
project is considered defined if it's definition has been executed. What
is not guaranteed is that the definition of each sub project has been
executed. AFAICT this shouldn't be a problem and is most likely what we
want in the first place.
Pepijn
Index: lib/buildr/core/project.rb
===
--- lib/buildr/core/project.rb (revision 946877)
+++ lib/buildr/core/project.rb (revision )
@@ -224,6 +224,11 @@
# Enhance the project using the definition block.
project.enhance { project.instance_exec project, block } if block
+ # Mark the project as defined
+ project.enhance do |project|
+project.send :defined
+ end
+
# Top-level project? Invoke the project definition. Sub-project? We
don't invoke
# the project definiton yet (allow project calls to establish order
of evaluation),
# but must do so before the parent project's definition is done.
@@ -254,7 +259,7 @@
end
project ||= @projects[name] # Not found in scope.
raise No such project #{name} unless project
-project.invoke
+project.invoke unless project.defined?
project
end
@@ -598,8 +603,16 @@
@calledback ||= {}
end
+def defined?
+ @defined
+end
+
protected
+def defined
+ @defined = true
+end
-
+
+
# :call-seq:
# base_dir = dir
#
Index: spec/core/project_spec.rb
===
--- spec/core/project_spec.rb (revision 919303)
+++ spec/core/project_spec.rb (revision )
@@ -83,8 +83,18 @@
Buildr.define('foo') { define('bar') { project('baz:bar') } }
lambda { project('foo') }.should raise_error(RuntimeError, /Circular
dependency/)
end
+
+ it 'should handle non-circular dependencies' do
+Buildr.define root do
+ define child do
+puts project('root')._('foo.resource')
-end
+ end
+end
+lambda { project('root') }.should_not raise_error
+ end
+end
+
describe Project, ' property' do
it 'should be set if passed as argument' do
define 'foo', 'version'='1.1'
Re: Functional testing of RC4
I haven't checked yet but it seems as if project() is checking that
all projects in the hierarchy are defined (i.e., the define task has
been invoked).
Wouldn't it be sufficient to only ensure the leaf of the path is
defined and ignore the state of any parents? That would solve the
problem you're describing.
Pepijn
Op 13-jun-2010 om 05:12 heeft Rhett Sutphin
rh...@detailedbalance.net het volgende geschreven:\
Hi,
(Note: very long. Buildr committers: before you tl;dr, please
consider the section after the at the end.)
On Jun 12, 2010, at 2:26 PM, Pepijn Van Eeckhoudt wrote:
I suspected 399 might have something to do with the cycle stuff
that's been popping up. I still think the fix for 399 itself is
correct though; the only difference is cycles are now being
correctly detected where they previously might not have been.
I guess it depends on how you define correctly. The way buildr
1.4.0 behaves, it is more awkward/less clear to use subprojects as
namespaces: you can't express sibling dependencies by qualified
name. The example I gave in BUILDR-454 was the minimal one I could
reproduce, but this alternative example might show better why this
is undesirable:
define psc do
define authentication do
define plugin-api do
end
define cas-plugin do
compile.with project(authentication:plugin-api)
end
end
define web do
compile.with project(authentication:plugin-api)
end
end
1.4.0 fails on loading this buildfile where 1.3.5 does not:
RuntimeError : Circular dependency detected: TOP = psc =
psc:authentication = psc:authentication:local-plugin =
psc:authentication
There isn't actually a dependency from psc:authentication:local-
plugin to psc:authentication, though. psc:authentication doesn't
even have any packages or tasks, so it's nonsense (and therefore
frustrating) for buildr to claim that there is a circular dependency
there.
As I indicated in the ticket for BUILDR-454, you can work around
this by using project.parent.project('plugin-api'), but that's
awkward. You can also work around it by defining cas-plugin like so:
define cas-plugin do
compile.with project(plugin-api)
end
which is less awkward (though still potentially unclear: what if
there are several plugin APIs in my project?), but it doesn't make
sense that one works and the other one doesn't. After all, they
both resolve to the same project.
This could come across as a regression to a user of buildr though.
Any idea how to fix it?
Between BUILDR-454, BUILDR-320, and the problems Antoine referred to
earlier in the thread, it seems like buildr's circular dependency
detection is flawed[1]. Last time I looked into it, it seemed like
it was inherited from rake. Perhaps its a mistake to have the
projects themselves defined as separate rake tasks?
The alternative I've come up with is also flawed, but I'll describe
it in case if gives someone a better idea:
Instead of using rake tasks for #defines, build up a graph of
project instances. When a define is encountered:
* Add a disconnected node for it to the graph
* Evaluate its body (but not any included defines), turning
#project references into edges in the graph
- If the referenced project exists in the graph, return it
- If it doesn't, return a lazy proxy
* Perform a topological sort of the graph at this point to
determine if any cycles exist. (RGL[2] has an implementation.)
* If there are no cycles, recurse into the child defines and
evaluate them the same way
(Note in particular that the parent-child relationship does not
become a graph edge in this scheme, unless there's an explicit
dependency from one to the other. However, that relationship would
still need to be separately maintained in order for things like
project.projects(foo, bar) to work.)
I see one flaw in this approach: it precludes meaningful[3] forward
references in #define. However, buildr already has problems with
those (see BUILDR-320) and no one but me is complaining, so maybe no
one uses them.
I haven't evaluated buildr itself to determine how hard this would
be to implement.
Now, having gone on at length about possible solutions, I'd like to
emphatically request that this not be solved before the next version
of buildr is released. Buildr has not worked with the current
version of rubygems for the last four months. As the developer of a
two public java projects that use buildr, it is difficult enough for
me to explain to people who want to compile them that there are
build tools other than ant/maven/eclipse. Since February, there's
been the additional complexity that I have to carefully explain to
them how to install ruby but not the current version of rubygems.
(And I'm not even mentioning the baroque RVM setup I have going
personally so I can use rubygems 1.3.7 with my ruby projects while
still using a released version of buildr
Re: Build failed in Hudson: Buildr-ci-build #11
/toulmean/buildr-gems/gems/rspec-1.2.9/lib/spec/example/example_group_methods.rb:103:in `run' /home/toulmean/buildr-gems/gems/rspec-1.2.9/lib/spec/runner/example_group_runner.rb:23:in `run' /home/toulmean/buildr-gems/gems/rspec-1.2.9/lib/spec/runner/example_group_runner.rb:22:in `each' /home/toulmean/buildr-gems/gems/rspec-1.2.9/lib/spec/runner/example_group_runner.rb:22:in `run' /home/toulmean/buildr-gems/gems/rspec-1.2.9/lib/spec/runner/options.rb:151:in `run_examples' /home/toulmean/buildr-gems/gems/rspec-1.2.9/lib/spec/runner/command_line.rb:9:in `run' /home/toulmean/buildr-gems/gems/rspec-1.2.9/bin/spec:5: Finished in 218.251337 seconds 1906 examples, 4 failures rake aborted! Command /usr/bin/ruby1.8 -Ilib /home/toulmean/buildr-gems/gems/rspec-1.2.9/bin/spec spec/groovy/bdd_spec.rb spec/groovy/compiler_spec.rb spec/addon/drb_spec.rb spec/java/commands_spec.rb spec/java/packaging_spec.rb spec/java/tests_spec.rb spec/java/bdd_spec.rb spec/java/emma_spec.rb spec/java/ant_spec.rb spec/java/cobertura_spec.rb spec/java/compiler_spec.rb spec/java/java_spec.rb spec/core/compile_spec.rb spec/core/common_spec.rb spec/core/cc_spec.rb spec/core/project_spec.rb spec/core/generate_spec.rb spec/core/checks_spec.rb spec/core/application_spec.rb spec/core/util_spec.rb spec/core/extension_spec.rb spec/core/transport_spec.rb spec/core/test_spec.rb spec/core/build_spec.rb spec/ide/idea7x_spec.rb spec/ide/eclipse_spec.rb spec/packaging/artifact_spec.rb spec/packaging/artifact_namespace_spec.rb spec/packaging/packaging_spec.rb spec/packaging/archive_spec.rb spec/version_requirement_spec.rb spec/scala/tests_spec.rb spec/scala/bdd_spec.rb spec/scala/compiler_spec.rb --format specdoc --format failing_examples:failed --format html:_reports/specs.html --backtrace failed (See full trace by running task with --trace) -- Pepijn Van Eeckhoudt - Project Leader T +32 16 23 95 91 F +32 16 29 34 22 | pepijn.vaneeckho...@luciad.com LUCIAD - high performance visualization Wetenschapspark Arenberg | Gaston Geenslaan 11 3001 Leuven | Belgium | www.luciad.com
Re: Build failed in Hudson: Buildr-ci-build #11
Fantastic news. So we're good to go for a 1.4 release? Or would you prefer another RC first just to be sure? Pepijn On 9/6/2010 17:36, Alex Boisvert wrote: Great! Glad to be back to 100% green. alex On Wed, Jun 9, 2010 at 7:51 AM, Antoine Toulme anto...@lunar-ocean.com mailto:anto...@lunar-ocean.com wrote: I also coded something right before bed time, and need to test it this morning before committing it. There was a SVN hiccup yesterday, but it looks like all builds are now green ! I fixed all the issues by: -using Dir.rmdir instead of File.delete for a folder -moved to Jruby 1.5.1 for bdd. On Wed, Jun 9, 2010 at 01:06, Pepijn Van Eeckhoudt pepijn.vaneeckho...@luciad.com mailto:pepijn.vaneeckho...@luciad.com wrote: Antoine, I'm not getting through to the apache jira instance right now, so I can't attach this patch just yet. It works for me locally, could you give this a try as well? Pepijn On 9/6/2010 08:54, Antoine Toulme wrote: Here goes: https://issues.apache.org/jira/browse/BUILDR-453 On Tue, Jun 8, 2010 at 23:51, Antoine Toulmeanto...@lunar-ocean.com mailto:anto...@lunar-ocean.com wrote: Oh yes! I wanted to file a bug to track this. On Tue, Jun 8, 2010 at 23:50, Pepijn Van Eeckhoudt pepijn.vaneeckho...@luciad.com mailto:pepijn.vaneeckho...@luciad.com wrote: Antoine, Would it be possible to get ci_reporter output from rspec on this box? That would make it a bit easier to go through the tests. Pepijn On 9/6/2010 08:05, Antoine Toulme wrote: OK, we now have a CI build with MRI. We have 4 failures... we need to fix them before we take it further. On Tue, Jun 8, 2010 at 22:51, Apache Hudson Server hud...@hudson.zones.apache.org mailto:hud...@hudson.zones.apache.org wrote: Seehttp://hudson.zones.apache.org/hudson/job/Buildr-ci-build/11/ -- [...truncated 2843 lines...] ARG_0 = ARG_1 = [0m [31m at org.scalatest.prop.Checkers$class.check(Checkers.scala:241) [0m [31m at StringSuite.check(StringSuite.scala:6) [0m [31m at org.scalatest.prop.Checkers$class.check(Checkers.scala:304) [0m [31m at StringSuite.check(StringSuite.scala:6) [0m [31m at org.scalatest.prop.Checkers$class.check(Checkers.scala:115) [0m [31m at StringSuite.check(StringSuite.scala:6) [0m [31m at StringSuite$$anonfun$3.apply(StringSuite.scala:17) [0m [31m at StringSuite$$anonfun$3.apply(StringSuite.scala:17) [0m [31m at org.scalatest.FunSuite$$anon$2.apply(FunSuite.scala:1158) [0m [31m at org.scalatest.Suite$class.withFixture(Suite.scala:1509) [0m [31m at StringSuite.withFixture(StringSuite.scala:6) [0m [31m at org.scalatest.FunSuite$class.runTest(FunSuite.scala:1155) [0m [31m at StringSuite.runTest(StringSuite.scala:6) [0m [31m at org.scalatest.FunSuite$$anonfun$runTests$1.apply(FunSuite.scala:1264) [0m [31m at org.scalatest.FunSuite$$anonfun$runTests$1.apply(FunSuite.scala:1255) [0m [31m at scala.List.foreach(List.scala:841) [0m [31m at org.scalatest.FunSuite$class.runTests(FunSuite.scala:1255) [0m [31m at StringSuite.runTests(StringSuite.scala:6) [0m [31m at org.scalatest.Suite$class.run(Suite.scala:1804) [0m [31m at StringSuite.org$scalatest$FunSuite$$super$run(StringSuite.scala:6) [0m [31m at org.scalatest.FunSuite$class.run(FunSuite.scala:1304) [0m [31m at StringSuite.run(StringSuite.scala:6) [0m [31m at org.scalatest.tools.SuiteRunner.run(SuiteRunner.scala:59) [0m [31m at org.scalatest.tools.Runner$$anonfun$doRunRunRunADoRunRun$3.apply(Runner.scala:1523) [0m [31m at org.scalatest.tools.Runner$$anonfun$doRunRunRunADoRunRun$3.apply(Runner.scala:1520) [0m [31m at scala.List.foreach(List.scala:841) [0m [31m at org.scalatest.tools.Runner$.doRunRunRunADoRunRun(Runner.scala:1520) [0m [31m at org.scalatest.tools.Runner$$anonfun$runOptionallyWithPassFailReporter$2.apply(Runner.scala:616) [0m [31m at org.scalatest.tools.Runner$$anonfun$runOptionallyWithPassFailReporter$2.apply(Runner.scala:615) [0m [31m at org.scalatest.tools.Runner$.withClassLoaderAndDispatchReporter(Runner.scala:1564) [0m [31m at org.scalatest.tools.Runner$.runOptionallyWithPassFailReporter(Runner.scala:614
Re: Windows issues
After some further investigation I've backtracked on my first fix attempt. I had assumed that utime to a time in the past was not working but in actuality it was utime on directories that was simply not working at all. I patched JRuby to fix this and have restarted my testing effort from scratch. I first wrote some specs to check that utime works on files, directories, in the past and in the future. Once those were working I reran all the specs and hooray most of them worked immediately. I've fixed a number of misc other things to get the remaining failing ones to work: - Disabled ZipTask:'should preserve file permissions' on windows as this cannot be implemented correctly yet. - Added URI.escape() around all file:// URLs in the specs to make sure directories with spaces are handled correctly - Patched FILE#real_path to return an unescaped version of the path so that we don't get %20 directories on the local FS - Allowed mode flags to be passed to Buildr#read. Due to CRLF to LF conversion the signature validation spec was failing. This spec now uses 'rb' as mode flags I'll attach all this stuff as a new patch to BUILDR-499. Antoine, could you revert the previous patch and apply the new one and then retest please? Regards, Pepijn On 1/6/2010 17:20, Pepijn Van Eeckhoudt wrote: JRUBY-4837 Op 1-jun-2010 om 17:13 heeft Antoine Toulme anto...@lunar-ocean.com het volgende geschreven:\ I'll give it a try today. We might be lucky and have your patch accepted for 1.5.1 - I'll chat with the JRuby team about it. Do you have the bug number ? On Tue, Jun 1, 2010 at 07:45, Pepijn Van Eeckhoudt pep...@vaneeckhoudt.netwrote: I've traced the directory utime issue back to the jnr-posix project which is used by JRuby. I've patched the bug and submitted the patch back to the JRuby guys. This means we'll have to wait for a new JRuby build before this can be resolved from a buildr point of view. Should this block the buildr 1.4 release or not? I've also created a bug in the buildr jira project with the spec patches attached. Could someone else give these a try? Pepijn -- Pepijn Van Eeckhoudt - Project Leader T +32 16 23 95 91 F +32 16 29 34 22 | pepijn.vaneeckho...@luciad.com LUCIAD - high performance visualization Wetenschapspark Arenberg | Gaston Geenslaan 11 3001 Leuven | Belgium | www.luciad.com
Re: Windows issues
JRUBY-4837 Op 1-jun-2010 om 17:13 heeft Antoine Toulme anto...@lunar-ocean.com het volgende geschreven:\ I'll give it a try today. We might be lucky and have your patch accepted for 1.5.1 - I'll chat with the JRuby team about it. Do you have the bug number ? On Tue, Jun 1, 2010 at 07:45, Pepijn Van Eeckhoudt pep...@vaneeckhoudt.netwrote: I've traced the directory utime issue back to the jnr-posix project which is used by JRuby. I've patched the bug and submitted the patch back to the JRuby guys. This means we'll have to wait for a new JRuby build before this can be resolved from a buildr point of view. Should this block the buildr 1.4 release or not? I've also created a bug in the buildr jira project with the spec patches attached. Could someone else give these a try? Pepijn
Fixing the specs on Windows
I've been going through the specs and up until now all failures are related to utime not behaving as expected on windows. I'm changing the specs so that they don't rely on utime but use sleeps instead. This makes the specs much more reliable (se linux doesn't allow mtime to be set in the past either IIRC), at the cost of slightly slower execution due to the sleeps. Is this acceptable? Pepijn
Windows/JRuby 1.5.0 spec fixes
I've been able to get the number of failing specs down to 11. The ones that still fail fall into two categories: - FileUtils.touch is not updating the mtime of directories correctly. I've reported this as JRUBY-4837 with an included spec. - File permission checking does not work on Windows. This causes the 'manifest 644' and 'ziptask should preserve permission' specs to fail I'm not sure how the second category can be resolved. I had a look at Ant's zip and tar tasks to see how it's supported there. Those tasks extend FileSet by allowing explicit uid,gid and perm values to be specified. Similar options should probably be added to the ArchiveTask#include methods. That way the perms in the final archive and the perms on the fs could be decoupled. Any thoughts on this? Pepijn
Re: Build failed in Hudson: Buildr CI on Windows #6
Ok. I've run the specs and I'm getting 31 failures now on Windows XP. I'll have a look at them next week. Pepijn On 28/5/2010 18:46, Antoine Toulme wrote: Win XP or Win 7 have failures. How much they overlap is yet to be determined... but if you get to fix _anything_ on Windows, that's a great step. We're not far from having everything in check. On Fri, May 28, 2010 at 09:41, Pepijn Van Eeckhoudt pepijn.vaneeckho...@luciad.com mailto:pepijn.vaneeckho...@luciad.com wrote: Still specific to Windows 7 or just Windows in general? Pepijn On 28/5/2010 18:01, Antoine Toulme wrote: I will install Scala on the Windows machine and will change the message to get the full build log. On Fri, May 28, 2010 at 00:08,anto...@lunar-ocean.com mailto:anto...@lunar-ocean.com wrote: Seehttp://192.168.1.42:/job/Buildr%20CI%20on%20Windows/6/changes Changes: [toulmean] partial fix for BUILDR-445: relax rspec dependency -- [...truncated 3862 lines...] D:/Documents and Settings/Administrator/.hudson/jobs/Buildr CI on Windows/workspace/lib/buildr/core/application.rb:629:in `invoke_with_call_chain' c:/intalio/ruby/lib/ruby/1.8/monitor.rb:242:in `synchronize' D:/Documents and Settings/Administrator/.hudson/jobs/Buildr CI on Windows/workspace/lib/buildr/core/application.rb:622:in `invoke_with_call_chain' D:/Documents and Settings/Administrator/.hudson/jobs/Buildr CI on Windows/workspace/lib/buildr/core/application.rb:617:in `invoke' D:/Documents and Settings/Administrator/.hudson/jobs/Buildr CI on Windows/workspace/lib/buildr/core/project.rb:325:in `local_task' D:/Documents and Settings/Administrator/.hudson/jobs/Buildr CI on Windows/workspace/lib/buildr/core/project.rb:350:in `[]' D:/Documents and Settings/Administrator/.hudson/jobs/Buildr CI on Windows/workspace/lib/buildr/core/project.rb:350:in `local_projects' D:/Documents and Settings/Administrator/.hudson/jobs/Buildr CI on Windows/workspace/lib/buildr/core/project.rb:350:in `each' D:/Documents and Settings/Administrator/.hudson/jobs/Buildr CI on Windows/workspace/lib/buildr/core/project.rb:350:in `local_projects' D:/Documents and Settings/Administrator/.hudson/jobs/Buildr CI on Windows/workspace/lib/buildr/core/project.rb:323:in `local_task' c:/intalio/ruby/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:636:in `call' c:/intalio/ruby/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:636:in `execute_without_a_record' c:/intalio/ruby/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:631:in `each' c:/intalio/ruby/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:631:in `execute_without_a_record' D:/Documents and Settings/Administrator/.hudson/jobs/Buildr CI on Windows/workspace/spec/spec_helpers.rb:144:in `execute' D:/Documents and Settings/Administrator/.hudson/jobs/Buildr CI on Windows/workspace/lib/buildr/core/application.rb:636:in `invoke_with_call_chain' c:/intalio/ruby/lib/ruby/1.8/monitor.rb:242:in `synchronize' D:/Documents and Settings/Administrator/.hudson/jobs/Buildr CI on Windows/workspace/lib/buildr/core/application.rb:622:in `invoke_with_call_chain' D:/Documents and Settings/Administrator/.hudson/jobs/Buildr CI on Windows/workspace/lib/buildr/core/application.rb:617:in `invoke' ./spec/packaging/packaging_spec.rb:646: D:/Documents and Settings/Administrator/.hudson/jobs/Buildr CI on Windows/workspace/spec/spec_helpers.rb:155:in `call' D:/Documents and Settings/Administrator/.hudson/jobs/Buildr CI on Windows/workspace/spec/spec_helpers.rb:155:in `matches?' c:/intalio/ruby/lib/ruby/gems/1.8/gems/rspec-1.2.9/lib/spec/expectations/handler.rb:11:in `handle_matcher' c:/intalio/ruby/lib/ruby/gems/1.8/gems/rspec-1.2.9/lib/spec/expectations/extensions/kernel.rb:27:in `should' ./spec/packaging/packaging_spec.rb:646: c:/intalio/ruby/lib/ruby/gems/1.8/gems/rspec-1.2.9/lib/spec/example/example_methods.rb:40:in `instance_eval' c:/intalio/ruby/lib/ruby/gems/1.8/gems/rspec-1.2.9/lib/spec/example/example_methods.rb:40:in `execute' c:/intalio/ruby/lib/ruby/1.8/timeout.rb:53
spec 'should not touch target directory unless running'?
First failure I checked was this one:
it 'should not touch target directory unless running' do
mkpath 'target' ; File.utime @early, @early, 'target'
@filter.from('src').into('target').exclude('*').run
File.mtime('target').should be_close(@early, 10)
end
Can this ever work? On many systems you're not allowed to set the mtime
of a file/dir to a time in the past. The pickaxe even states that utime
does not work on all systems. It's probably safer to read the mtime,
sleep, run the filter and then check the mtime again. How do you do
java.lang.Thread#sleep in ruby?
Pepijn
Re: 1.4, Windows 7, and a few news
On 20 May 2010, at 17:41, Charles Oliver Nutter wrote: On Thu, May 20, 2010 at 8:41 AM, Pepijn Van Eeckhoudt pepijn.vaneeckho...@luciad.com wrote: I've only used buildr on JRuby myself so sorry if this comes across as ignorant. What kind of issues are you guys getting with RJB? I glanced through the code quickly and it seems to basically consist of the necessary JNI calls to call into the JVM from ruby. I don't think the JVM gives you any alternatives to this, so I would expect any other approach to have the same set of limitations as RJB. You'll never be able to get the level of integration with Java you can get with JRuby through any wrapper. You might be able to make a nicer wrapper (for some definition of nicer) but actually running on the JVM is the way to go. I completely agree with you on this, but there seems to be some reluctance to drop MRI support. If you take MRI as a given, do you see any other options than starting a JVM via JNI and making calls into it via JNI. AFAIK, there aren't any other options. Since this seems to be exactly what RJB does, I was wondering what the limitations of this approach were from a buildr perspective. Does buildr currently do more than instantiate Java objects and call methods on them? What's missing in RJB that would make it 'nicer'? Pepijn
invoke_with_call_chain not restoring call chain correctly
I'm bumping into unpredictable behaviour related to the call chain
handling. It seems invoke_with_call_chain doesn't restore the call chain
correctly after calling invoke. Since this is in the core of buildr I
wanted to just check with you guys before creating an issue in jira.
invoke_with_call_chain currently does
begin
old_chain, Thread.current[:rake_chain] = Thread.current[:rake_chain],
new_chain
execute(task_args) if needed?
ensure
Thread.current[:rake_chain] = nil
end
The ensure block seems obviously incorrect. Shouldn't this be
Thread.current[:rake_chain] = old_chain?
The following spec shows when this causes things to go wrong:
describe Buildr do
it 'should restore call chain when invoke is called' do
task1 = Rake::Task.define_task('task1') do
end
task2 = Rake::Task.define_task('task2') do
chain1 = Thread.current[:rake_chain]
task1.invoke
chain2 = Thread.current[:rake_chain]
chain2.should == chain1
end
task2.invoke
end
end
So is this an issue or intentional?
Regards,
Pepijn
Re: Next release
Aha, that confirms what I suspected. I was about to check the JRuby
source code, so thanks for saving me some digging :)
Adding
ffi_lib c
before the attach_function does the trick. map_library_name maps this to
Platform::LIBC and then the attach works correctly.
Pepijn
On 1/3/2010 17:50, Antoine Toulme wrote:
See my comment on BUILDR-348.
On Mon, Mar 1, 2010 at 08:49, Pepijn Van Eeckhoudt
pepijn.vaneeckho...@luciad.com wrote:
Just tested that; nothing happens. I don't see the vim output and jirb is
no longer responding to input.
Pepijn
On 1/3/2010 17:37, Alex Boisvert wrote:
They may have fixed system() such that using FFI directly wouldn't be
necessary anymore. A simple test such as system 'vim' from jirb on
Windows would confirm.
alex
On Mon, Mar 1, 2010 at 8:16 AM, Antoine Toulmeanto...@lunar-ocean.com
wrote:
I can contact the jruby folks and see if a jruby update would help - JFFI
is
now 1.0 btw, while it was 0.4 in 1.4.0.
On Mon, Mar 1, 2010 at 08:12, Alex Boisvertalex.boisv...@gmail.com
wrote:
On Mon, Mar 1, 2010 at 3:00 AM, Pepijn Van Eeckhoudt
pepijn.vaneeckho...@luciad.com wrote:
It would be nice if BUILDR-348 could be resolved for 1.4.0. We are
planning
on using buildr as internally running on jruby 1.4. Right now this
issue
means I will either have to maintain a custom buildr build or have
every
developer patch the buildr installation by hand.
Any idea on the root cause of this problem? Does commenting out that
one
line have any other side effects?
The issue is that JRuby use{s,d} the JVM's System.exec() call to spawn
external processes, which isn't 100% equivalent to Unix system() call.
For
instance, if you spawned a process like 'vim' or a language shell like
'scala' or 'irb', then you wouldn't be able to interact with the
sub-process
correctly due to incomplete redirection of all terminal capabilities.
To solve this, we override the system() call to circumvent the JRuby's
system call and directly call the native system() using FFI.
I don't know what's the state of things on JRuby 1.4.0 + Windows but
some
internals seem to have changed which is why we're getting the error
described in BUILDR-348. Somebody needs to investigate what
works/doesn't
work on Windows -- the workaround I provided on BUILDR-348 simply
reverts
to
using the standard system() implementation, which works for most things
but
not shelling out to interactive apps.
alex
--
Pepijn Van Eeckhoudt - Project Leader
T +32 16 23 95 91
F +32 16 29 34 22 | pepijn.vaneeckho...@luciad.com
LUCIAD - high performance visualization
Wetenschapspark Arenberg | Gaston Geenslaan 9
3001 Leuven | Belgium | www.luciad.com
--
Pepijn Van Eeckhoudt - Project Leader
T +32 16 23 95 91
F +32 16 29 34 22 | pepijn.vaneeckho...@luciad.com
LUCIAD - high performance visualization
Wetenschapspark Arenberg | Gaston Geenslaan 9
3001 Leuven | Belgium | www.luciad.com
Re: Next release
Any ideas on how to test this thoroughly? I can't imagine this causing a
regression as the debugger now shows system is being loaded from msvcrt
which is exactly the method you want to load.
Pepijn
On 1/3/2010 18:17, Daniel Spiewak wrote:
Fix committed in r917597. Note that this only applies when
Buildr::Util::win_os? is true.
Daniel
On Mon, Mar 1, 2010 at 11:13 AM, Pepijn Van Eeckhoudt
pepijn.vaneeckho...@luciad.com wrote:
Or better yet just use LIBC directly instead :)
So ffi_lib FFI::Platform::LIBC
I'll add this as a comment to BUILDR-348
Pepijn
On 1/3/2010 18:05, Pepijn Van Eeckhoudt wrote:
Aha, that confirms what I suspected. I was about to check the JRuby source
code, so thanks for saving me some digging :)
Adding
ffi_lib c
before the attach_function does the trick. map_library_name maps this to
Platform::LIBC and then the attach works correctly.
Pepijn
On 1/3/2010 17:50, Antoine Toulme wrote:
See my comment on BUILDR-348.
On Mon, Mar 1, 2010 at 08:49, Pepijn Van Eeckhoudt
pepijn.vaneeckho...@luciad.com wrote:
Just tested that; nothing happens. I don't see the vim output and jirb
is
no longer responding to input.
Pepijn
On 1/3/2010 17:37, Alex Boisvert wrote:
They may have fixed system() such that using FFI directly wouldn't be
necessary anymore. A simple test such as system 'vim' from jirb on
Windows would confirm.
alex
On Mon, Mar 1, 2010 at 8:16 AM, Antoine Toulmeanto...@lunar-ocean.com
wrote:
I can contact the jruby folks and see if a jruby update would help -
JFFI
is
now 1.0 btw, while it was 0.4 in 1.4.0.
On Mon, Mar 1, 2010 at 08:12, Alex Boisvertalex.boisv...@gmail.com
wrote:
On Mon, Mar 1, 2010 at 3:00 AM, Pepijn Van Eeckhoudt
pepijn.vaneeckho...@luciad.comwrote:
It would be nice if BUILDR-348 could be resolved for 1.4.0. We are
planning
on using buildr as internally running on jruby 1.4. Right now this
issue
means I will either have to maintain a custom buildr build or have
every
developer patch the buildr installation by hand.
Any idea on the root cause of this problem? Does commenting out that
one
line have any other side effects?
The issue is that JRuby use{s,d} the JVM's System.exec() call to
spawn
external processes, which isn't 100% equivalent to Unix system()
call.
For
instance, if you spawned a process like 'vim' or a language shell
like
'scala' or 'irb', then you wouldn't be able to interact with the
sub-process
correctly due to incomplete redirection of all terminal capabilities.
To solve this, we override the system() call to circumvent the
JRuby's
system call and directly call the native system() using FFI.
I don't know what's the state of things on JRuby 1.4.0 + Windows but
some
internals seem to have changed which is why we're getting the error
described in BUILDR-348. Somebody needs to investigate what
works/doesn't
work on Windows -- the workaround I provided on BUILDR-348 simply
reverts
to
using the standard system() implementation, which works for most
things
but
not shelling out to interactive apps.
alex
--
Pepijn Van Eeckhoudt - Project Leader
T +32 16 23 95 91
F +32 16 29 34 22 | pepijn.vaneeckho...@luciad.com
LUCIAD - high performance visualization
Wetenschapspark Arenberg | Gaston Geenslaan 9
3001 Leuven | Belgium | www.luciad.com
--
Pepijn Van Eeckhoudt - Project Leader
T +32 16 23 95 91
F +32 16 29 34 22 | pepijn.vaneeckho...@luciad.com
LUCIAD - high performance visualization
Wetenschapspark Arenberg | Gaston Geenslaan 9
3001 Leuven | Belgium | www.luciad.com
--
Pepijn Van Eeckhoudt - Project Leader
T +32 16 23 95 91
F +32 16 29 34 22 | pepijn.vaneeckho...@luciad.com
LUCIAD - high performance visualization
Wetenschapspark Arenberg | Gaston Geenslaan 9
3001 Leuven | Belgium | www.luciad.com
Re: Improved Maven repository handling
On 24/2/2010 19:08, Alex Boisvert wrote: No easy answer here; you could parse the Ivy/Maven metadata to retrieve the information needed to bootstrap, or assume Ivy/Ant are already installed, or do like Ivy4r as you suggested. Partially parsing the ivy settings file to initialise repositories.remote and repositories.local is what I hand in mind as well; maybe I'll give that a go next. Ivy does allow a lot of flexibility so I'm a bit concerned I'll end up having to duplicate a lot of Ivy stuff (e.g., all the different types of resolvers, the different local caching options, ...) Pepijn
Improved Maven repository handling
Hi, I'm investigating how I can make build a better behaved citizen when it comes to uploading stuff to a maven repository. Specifically I would like to improve the handling of snapshot uploads. Right now these don't seem to get any special treatment. Instead I would like to make buildr upload timestamped builds and update the maven-metadata.xml file. I've been looking at different solutions and currently have the following list of options: - Derive the logic from the Maven source code and implement a work-alike in Ruby - Integrate the Maven ant tasks - Investigate if ivy4r can be used to provide this functionality The ivy4r route turned out to be a dead end as ivy doesn't seem to handle maven-metadata on uploads. By default it doesn't upload a pom.xml either. That leaves me with the first two options. I would like to get some more seasoned developer's opinion on this before I really start developing this. What would the 'preferred' implementation be? Are there any plans on the table to tackle this already? Regards, Pepijn
POM uploaded multiple times for attached artifacts
When executing 'buildr upload' on a simple java project with the following buildfile, the pom gets uploaded twice; once for each package define 'attachedartifacts' do project.group = attached project.version = 1.0 package(:jar) package(:sources) end This doesn't work when uploading to a 'release' maven2 repository as these often don't allow updating of files. In practice I'm trying to upload to a release repository on a Nexus server. Is this intentional behavior of buildr or is this a bug? Any idea how to work around this problem? If you guys can give me some pointers, I can work on a patch for this. I think to correct this the upload operation for each artifact should be a task itself as well. This would ensure upload is only invoked once for each pom. Pepijn
Re: POM uploaded multiple times for attached artifacts
How does this look? I've been programming Java for 9 years now, so there might be some java-isms in there... Pepijn On 11/2/2010 10:15, Antoine Toulme wrote: That's a bug. Look line 163 of artifact.rb. Instead of calling the upload method, you could encapsulate in a task and add it as a prerequisite, I guess. Make sure to use a task name that would work on the project. On Thu, Feb 11, 2010 at 01:09, Pepijn Van Eeckhoudt pepijn.vaneeckho...@luciad.com wrote: When executing 'buildr upload' on a simple java project with the following buildfile, the pom gets uploaded twice; once for each package define 'attachedartifacts' do project.group = attached project.version = 1.0 package(:jar) package(:sources) end This doesn't work when uploading to a 'release' maven2 repository as these often don't allow updating of files. In practice I'm trying to upload to a release repository on a Nexus server. Is this intentional behavior of buildr or is this a bug? Any idea how to work around this problem? If you guys can give me some pointers, I can work on a patch for this. I think to correct this the upload operation for each artifact should be a task itself as well. This would ensure upload is only invoked once for each pom. Pepijn -- Pepijn Van Eeckhoudt - Project Leader T +32 16 23 95 91 F +32 16 29 34 22 | pepijn.vaneeckho...@luciad.com LUCIAD - high performance visualization Wetenschapspark Arenberg | Gaston Geenslaan 9 3001 Leuven | Belgium | www.luciad.com uploadtask.patch Description: application/itunes-itlp
PackageGemTask methods not called
Hi,
I'm trying to package a buildr extension as a gem so I can distribute it
more easily. It seems the PackageGemTask#install method is never called
though.
I'm kind of new to Ruby so I'm not 100% sure what's going on, but I
think line 173 in buildr/packaging/package.rb ('package.extend
ActsAsArtifact') is to blame. By extending the package object with
ActsAsArtifact, the install, uninstall and upload methods get overridden
and so the Gem specific variants are never invoked.
I would like to patch this, but I'm not sure what would be the best way
would be to resolve this? Is there some Ruby idiom that would allow this?
Regards,
Pepijn Van Eeckhoudt
Re: PackageGemTask methods not called
Hi Antoine,
Rereadig my mail, I realize that I should have provided a bit more
context (and sorry for the double message BTW).
My buildfile essentially contains something like this:
define 'my-extension' do
package(:gem)
end
package will call pacakge_as_gem which in turn will create a
PackageGemTask. PackageGemTask has it's own install/uninstall/upload
implementations. package then takes the PackageGemTask instance and
extends it with ActsAsArtifact which overrides install/uninstall/upload
from PackageGemTask. The net effect of this is that
PackageGemTask#install is never called.
Given that observation I was wondering how to fix this and if it is
possible in the first place. In other words, it is possible for a
package to provide it's own versions of the methods defined in
ActsAsArtifact.
Regards,
Pepijn
On 10/2/2010 18:15, Antoine Toulme wrote:
Hi Pepjin,
to package a buildr extension you typically don't need to use Buildr itself.
You can create a .gemspec file, then do:
gem build gem.gemspec
gem push gem-1.0.gem
I might be missing something, but really the line you point at is not
related to gem building and is very important in Buildr - it helps Buildr
know how to handle packages as artifacts, so where to upload them for
example.
Thanks,
Antoine
On Wed, Feb 10, 2010 at 01:54, Pepijn Van Eeckhoudtpep...@vaneeckhoudt.net
wrote:
Hi,
I'm trying to package a buildr extension as a gem so I can distribute it
more easily. It seems the PackageGemTask#install method is never called
though.
I'm kind of new to Ruby so I'm not 100% sure what's going on, but I think
line 173 in buildr/packaging/package.rb ('package.extend ActsAsArtifact') is
to blame. By extending the package object with ActsAsArtifact, the install,
uninstall and upload methods get overridden and so the Gem specific variants
are never invoked.
I would like to patch this, but I'm not sure what would be the best way
would be to resolve this? Is there some Ruby idiom that would allow this?
Regards,
Pepijn Van Eeckhoudt
--
Pepijn Van Eeckhoudt - Project Leader
T +32 16 23 95 91
F +32 16 29 34 22 | pepijn.vaneeckho...@luciad.com
LUCIAD - high performance visualization
Wetenschapspark Arenberg | Gaston Geenslaan 9
3001 Leuven | Belgium | www.luciad.com
