Re: Buildr 1.4.0RC2 is out
>> We have spec failures on Windows 7, and it looks like we might need to >> change packaging for that new OS. > > It would be good to know if the release actually works on Windows. It does not under the latest 64bit Windows with jruby 1.3.1 or jruby 1.5. Unfortunately I don't have access to a Windows box to track it down further. > I wouldn't want people running "gem update" on Windows and finding their > Buildr install broken. Whats even more annoying is that installing buildr 1.4 breaks buildr 1.3.6 as well. IIRC it installed an extra gem (rspec?) that had to be removed to get buildr 1.3.6 working again. -- Cheers, Peter Donald
Re: Overview of issues blocking 1.4.0 release
Applying the patch in BUILDR-447 would squash quite an annoying bug :) On Fri, May 28, 2010 at 7:18 PM, Pepijn Van Eeckhoudt wrote: > Which issues are still blocking the 1.4.0 release? I might have some time > available to work on some of them, so I would like to know what to tackle > first. > > Regards, > > Pepijn > -- Cheers, Peter Donald
Re: [VOTE] Buildr 1.4.0 release
On Sat, Jun 19, 2010 at 4:17 AM, Daniel Spiewak wrote: > Thanks again, Antoine, for all your hard work on this release! Agreed. Great work! -- Cheers, Peter Donald
Re: Ant 1.8.1 upgrade requires Antwrap changes
One thing I would like to see is an update to the dependency declaration of jruby-openssl either to an open ended version range or to the latest version. i.e. to either '>= 0.5.2' or '= 0.7'. I would add a jira issue but I seem to log on atm. On Fri, Jul 2, 2010 at 2:43 AM, Antoine Toulme wrote: > Cool! > > Here's the changelog so far: > > 1.4.1 (pending) > * Added: BUILDR-420 Support external compiler > * Added: BUILDR-425 Specify dev dependencies in .gemspec > * Change: BUILDR-459 Update gemspec to accept json_pure ~> 1.4.3 > * Fixed: BUILDR-455 cc_spec.rb l 160 depends on time and thus fails > intermittently > * Fixed: BUILDR-461 Packages with different ids collide > * Fixed: BUILDR-439 "The command line is too long" when running TestNG > tests > > I'll cut a RC tonight/tomorrow morning. > > On Thu, Jul 1, 2010 at 09:13, Alex Boisvert wrote: > >> On Wed, Jun 30, 2010 at 11:53 AM, Antoine Toulme >> wrote: >> >>> I was wrong, it's a dependency of junit. >>> >>> So we will need to upgrade junit to match with 1.8.1. >>> >>> For the time being, I reverted to 1.8.0. >>> >>> I have a few failures when running rake spec as the external compiler spec >>> changes the order of the compilers. I will fix that today. >>> >>> I am thinking of making a release this Friday. I'll bring up a changelog >>> this Friday and we can discuss if we feel like releasing ? >>> >> >> I think it's a good idea to release soon. BUILDR-459 (json_pure ~> 1.4.3) >> seems to be the driver. >> >> alex >> >> > -- Cheers, Peter Donald
Re: Functional testing harness
Hi, On Thu, Jul 22, 2010 at 2:45 AM, Antoine Toulme wrote: > I'm looking for volunteers to take a quick look at the patch attached to: > https://issues.apache.org/jira/browse/BUILDR-456 > > And tell me what they think. As a first cut it looks not bad. I would expect to see a library of assertions built up over time to make it easy to check the output and results of the builds. One thing I would like to see is a consistency between the spec tests and the functional tests in how they setup the environment. In both cases you are typically going to need to delete then create a scratch directory structure at start of test, configure (and populate) the maven repository. Both tests also may create some dirs and setup a build file (although in the spec tests it is done in memory while in the functional tests you are likely to be copying around files). At the end of the tests the scratch directory should be nuked. So extracting this into a common api would be great. It would also mean that it could be more easily used by outside people that are writing buildr plugins. I could imagine an api like # Put in test_helper/sepc_helper Buildr::Test.scratch_directory = File.basedir(__FILE__) + "/../tmp" Buildr::Test.clean_scratch_on_destroy = ENV["TEST_CLEAN_SCRATCH"].nil? ? true : ENV["TEST_CLEAN_SCRATCH"] == 'true' # called from setup Buildr::Test.init # # Called to copy artifact from local maven repo to maven repo in test Buildr::Test.install_artifact 'com.biz:my-widget:jar:2.0' Buildr::Test.install_artifact 'com.biz:my-other-widget:jar:2.0' # Example code to setup a functional test FileUtils.cp_r File.basedir(__FILE__) + "/../functional/" + test_name, Buildr::Test.project_directory # called from teardown Buildr::Test.destroy Thoughts? -- Cheers, Peter Donald
Artifacts and Repositories
Over the next little while I intend to put together some code that can
manage our artifacts more effectively and I thought I would ask the
list to see if it is something worth contributing back to the core of
buildr.
So we want to define the associated repositories with an artifact;
* release_to: An array of repositories that non snapshot releases are
uploaded to. (i.e. like repositories.release_to but an array)
* snapshot_to: An array of repositories that snapshots are uploaded
to. (i.e. like repositories.release_to but an array)
* download_from: An array of repositories that an artifact can be
downloaded from. (i.e. like repositories.remote)
* mirror_to: An array of repositories that can hold a copy of
artifacts. Typically this is checked first before going to
download_from. This repository definition includes information for
uploading and downloading. This allows for tools to be written that
will download from dowload_from and upload to mirror_to repos.
Somehow we need to associate metadata with each artifact so as to
select the appropriate repositories for each artifact. It seems
reasonable to have default values across the project as is currently
done in buildr and then override for exceptions.
One approach I had considered was attaching metadata to the spec
definition of the artifact. The approach would allow an arbitrary set
of key/value pairs at the end of the spec separated by a ; character.
So to use the default repositories you may do something like
'org.example:my-project:jar:1.0'
but to override the defaults you may use something like
'org.example:my-project:jar:1.0;upload_to=my_release_repo_key,my_other_release_repo;mirror_to='
and this would indicate that the artifact is not to be mirrored but
when a release occurs it should be released to the repos identified by
the keys "my_release_repo_key" and "my_other_release_repo". (Of course
there would need to be other code added to register repository
information under a key)
Rather than putting this in the spec you could also do it
programatically via something like the following in your buildfile
artifact('org.example:my-project:jar:1.0').tap do |a|
a.meta['upload_to'] = ...
end
The advantage of attaching it to the spec IMHO is that you can easily
do it in the build.yaml AND it makes it easier to use it in the future
if you wanted to write a custom resolver for specs.
So I guess my question is does this seem reasonable? Or do you have
any suggestions that would make it more likely to be incorporated in
buildr in the future. I was hoping to get some time over the next few
weeks and put together a buildr plugin on github to see if it works as
good in practice as it does in theory.
Thoughts?
--
Cheers,
Peter Donald
Re: [VOTE] Buildr 1.4.2
+1 (non binding). Good work! -- Cheers, Peter Donald
Re: Artifacts and Repositories
Any response to this? I am willing to do all the legwork to get this
done if some common approach can be worked out.
On Sun, Sep 19, 2010 at 1:51 PM, Peter Donald wrote:
> Over the next little while I intend to put together some code that can
> manage our artifacts more effectively and I thought I would ask the
> list to see if it is something worth contributing back to the core of
> buildr.
>
> So we want to define the associated repositories with an artifact;
> * release_to: An array of repositories that non snapshot releases are
> uploaded to. (i.e. like repositories.release_to but an array)
> * snapshot_to: An array of repositories that snapshots are uploaded
> to. (i.e. like repositories.release_to but an array)
> * download_from: An array of repositories that an artifact can be
> downloaded from. (i.e. like repositories.remote)
> * mirror_to: An array of repositories that can hold a copy of
> artifacts. Typically this is checked first before going to
> download_from. This repository definition includes information for
> uploading and downloading. This allows for tools to be written that
> will download from dowload_from and upload to mirror_to repos.
>
> Somehow we need to associate metadata with each artifact so as to
> select the appropriate repositories for each artifact. It seems
> reasonable to have default values across the project as is currently
> done in buildr and then override for exceptions.
>
> One approach I had considered was attaching metadata to the spec
> definition of the artifact. The approach would allow an arbitrary set
> of key/value pairs at the end of the spec separated by a ; character.
>
> So to use the default repositories you may do something like
>
> 'org.example:my-project:jar:1.0'
>
> but to override the defaults you may use something like
>
> 'org.example:my-project:jar:1.0;upload_to=my_release_repo_key,my_other_release_repo;mirror_to='
>
> and this would indicate that the artifact is not to be mirrored but
> when a release occurs it should be released to the repos identified by
> the keys "my_release_repo_key" and "my_other_release_repo". (Of course
> there would need to be other code added to register repository
> information under a key)
>
> Rather than putting this in the spec you could also do it
> programatically via something like the following in your buildfile
>
> artifact('org.example:my-project:jar:1.0').tap do |a|
> a.meta['upload_to'] = ...
> end
>
> The advantage of attaching it to the spec IMHO is that you can easily
> do it in the build.yaml AND it makes it easier to use it in the future
> if you wanted to write a custom resolver for specs.
>
> So I guess my question is does this seem reasonable? Or do you have
> any suggestions that would make it more likely to be incorporated in
> buildr in the future. I was hoping to get some time over the next few
> weeks and put together a buildr plugin on github to see if it works as
> good in practice as it does in theory.
>
> Thoughts?
>
> --
> Cheers,
>
> Peter Donald
>
--
Cheers,
Peter Donald
Re: Artifacts and Repositories
On Fri, Sep 24, 2010 at 9:08 AM, Alex Boisvert wrote:
> Hi Donald,
It is Peter :)
> 2) adding download_from to an Artifact; this could be useful if only
> one/some of many artifacts come from a different repo and we don't want to
> pay the latency tax by querying this repo for all artifacts.
Precisely the use case. Several of the dependencies I am working with
are located in only one repository so some of the projects I have
written with buildr have ~14 repository definitions.
> As for mirror_to, it seems to be largely duplicated by repositories.remoteor
> download_from (assuming we add it). Given the download information is
> typically in the same buildfile, I'm not sure when this would be useful.
The main thing it is useful for is automating mirroring. So we tend to
have a local web server repository that has all the artifacts mirrored
from the internet. I agree it is probably not as useful as the other
features given that some people manage their repositories using things
like nexus.
> I'm not clear on the value of uploading to different repositories. People
> who need artifacts replicated typically set up repositories such that they
> mirror (a subset or all) of each other. Granted, it doesn't add much
> complexity but it doesn't seem like a widely needed features. (People
> reading this, feel free to jump in if you think it's useful).
While it is a demand in my workplace I could imagine that it is not
widely useful ... then again it is not much more complex ;)
> Stepping back a little bit, I'm wondering if adding metadata to artifacts is
> a good approach. The alternative is to place artifacts in arrays or hashes
> and manage these as sets, e.g.,
>
> public_artifacts = [ list, of, artifacts, to, publish, to, public, repos ]
While this is possible I tend to store all dependencies in the
build.yaml file. This format is much more amenable to machine reading
and processing. So if there was a way to easily define groups of sets
of artifacts in this file then I could definitely be convinced to use
this approach.
> # This seemed to be another of your use-case
> task :replicate_artifacts do
> artifacts.each do |a|
> a.download :repository => 'http://bigco.com/repo' # not available today
> a.upload :url => 'http://example.com/repo', :username => 'foo'
> end
> end
I could imagine an approach like this being useful for packages - not
so sure about artifacts if they are managed in build.yaml. My instinct
would be to add them to the artifact base class or mixin (IIRC
ActsAsArtifact) so you could do something like the following
artifact(:mydep).download_from('http://example.com/internal')
project 'foo' do
compile.with :mydep
package(:jar).upload_to('http://example.com/repo')
end
> Have you considered this approach? I'd be curious to hear if/why you think
> using metadata is a better way to go.
I would be reasonably happy with that approach if you could define
groups of artifacts in build.yaml
I guess the main reason I was looking at metadata attributes is that
there is lots of other information that I want to store against an
artifact so I could automate other parts of the build process.
i.e. store a versioning policy and the last non snapshot version. That
way you could guess the next version based on whether the last release
is binary compatible with the current release. Ensure that the
artifact compiled against and tested against the last non snapshot
release of all the dependencies. Make sure the package adheres to
versioning policies (i.e. make sure the version does correct things
under OSGi). By keeping this information in build.yaml it easy to
write a release plugin that does all the magic required to automate
this and then updates build.yaml after a release occurs.
--
Cheers,
Peter Donald
Re: Artifacts and Repositories
On Sat, Sep 25, 2010 at 8:40 AM, Alex Boisvert wrote: > I haven't looked into this but I agree we should try to find a way to define > additional information on artifacts via build.yaml. Do you want to look > into it and suggest something? will do. > I'm open to adding metadata to artifacts (e.g. groups or tags) although I > would prefer to standardize common idioms. At this point download_from(), > upload_to() seem like they should be first-class idioms on artifacts. ok. > I would also prefer to keep snapshot_to as a global setting, similar to > release_to. I'm not opposed to using arrays where possible, to allow > multiple repositories, although the methods should also accept a single repo > as a convenience. > > How does that sound? Sonds good. I will have a play next week and see what I come up with. -- Cheers, Peter Donald
Re: Preparing for 1.4.3 release
Hi, > I'm preparing for a 1.4.3 release to be out towards the end of this week > (Friday-ish). The main driver is to (promptly) publish a release that > corrects the zipfile corruption bug introduced in 1.4.2. > > If you have bugs you absolutely want to see resolved in this release or > anything else you want to squeeze in before the build drops, please let me > know. I would really like to see BUILDR-535 resolved but I don't have time to investigate before then. So if you feel like doing it then go for it ;) -- Cheers, Peter Donald
Re: [VOTE] Buildr 1.4.3 release
+1 Great work on closing out those last remaining issues! On Thu, Oct 14, 2010 at 4:24 PM, Alex Boisvert wrote: > We're voting on the source distributions available here: > http://people.apache.org/~boisvert/buildr/1.4.3/dist/ > > Specifically: > http://people.apache.org/~boisvert/buildr/1.4.3/dist/buildr-1.4.3.tgz > http://people.apache.org/~boisvert/buildr/1.4.3/dist/buildr-1.4.3.zip > > The documentation generated for this release is available here: > http://people.apache.org/~boisvert/buildr/1.4.3/site/ > http://people.apache.org/~boisvert/buildr/1.4.3/site/buildr.pdf > > The official specification against which this release was tested: > http://people.apache.org/~boisvert/buildr/1.4.3/site/specs.html > > Test coverage report: > http://people.apache.org/~boisvert/buildr/1.4.3/site/coverage/index.html > > > The following changes were made since 1.4.2: > > * Added: BUILDR-514 New 'run' local task. > http://buildr.apache.org/more_stuff.html#run > * Added: BUILDR-518 Load _buildr.rb or .buildr.rb from same directory as > Buildfile > if they exist (Peter Donald) > * Added: BUILDR-519 Load repositories.release_to from build settings > (Peter Donald) > * Fixed: BUILDR-520 Scaladoc 2.8 no longer support -windowtitle, use > -doc-title instead. > * Fixed: BUILDR-512 Buildr::Util.ruby invokes non existent method (Peter > Donald) > * Fixed: BUILDR-513 --trace fails with NoMethodError : undefined method > `include?' for nil:NilClass > * Fixed: BUILDR-515 -update-snapshot doesn't work as expected > * Fixed: BUILDR-517 package(:jar).include(directory, :as=>"foo") produces > a corrupted jar > * Fixed: BUILDR-524 Optimized and more robust reading of jar MANIFEST.MF > (Hugues Malphettes) > * Fixed: BUILDR-525 Documentation refers to repositories.upload_to rather > than > repositories.release_to (Peter Donald) > * Fixed: BUILDR-526 Gracefully handle h2 sections with no id in > documentation (Peter Donald) > * Fixed: BUILDR-527 package(:war) if libs passed are files (instead of > artifacts) > * Fixed: BUILDR-528 Stop using deprecated method > Gem::Dependency.version_requirements correctly (Peter Donald) > * Fixed: BUILDR-529 Stop using gem name "foo" in tests as it is the name > of an actual gem (Peter Donald) > * Fixed: BUILDR-531 Improve error message when build requires gem that > can't be found in local/remote > gem repositories (Peter Donald) > * Fixed: BUILDR-532 package_as_source does not package resources (Tammo > van Lessen) > * Fixed: BUILDR-534 package_with_sources does not package source > artifacts if no sources but resources exist. > (Tammo Van Lessen) > * Fixed: BUILDR-535 Failing "checks" produce no meaningful errors on > JRuby > * Fixed: JavaRebel was previously not correctly detected. > -- Cheers, Peter Donald
Re: svn commit: r1023279 - /buildr/trunk/buildr.gemspec
Hi, It looks like this dependency needs to be installed on the Hudson/CI box. Also I notice that if any of the buildr CI jobs have a failing test they are marked as failed rather unstable ... is this deliberate? On Sun, Oct 17, 2010 at 12:13 AM, wrote: > Author: boisvert > Date: Sat Oct 16 13:13:47 2010 > New Revision: 1023279 > > URL: http://svn.apache.org/viewvc?rev=1023279&view=rev > Log: > Upgrade to rspec 2.0.0 > > Modified: > buildr/trunk/buildr.gemspec > > Modified: buildr/trunk/buildr.gemspec > URL: > http://svn.apache.org/viewvc/buildr/trunk/buildr.gemspec?rev=1023279&r1=1023278&r2=1023279&view=diff > == > --- buildr/trunk/buildr.gemspec (original) > +++ buildr/trunk/buildr.gemspec Sat Oct 16 13:13:47 2010 > @@ -62,7 +62,7 @@ for those one-off tasks, with a language > spec.add_dependency 'rjb', '1.2.5' if spec.platform.to_s > == 'ruby' > spec.add_dependency 'rjb', '1.2.5' if spec.platform.to_s > == 'x86-mswin32' > spec.add_dependency 'atoulme-Antwrap', '0.7.1' > - spec.add_dependency 'rspec', '>= 1.2.9' > + spec.add_dependency 'rspec', '2.0.0' > spec.add_dependency 'xml-simple', '1.0.12' > spec.add_dependency 'minitar', '0.5.3' > spec.add_dependency 'jruby-openssl', '>= 0.7' if spec.platform.to_s > == 'java' > > > -- Cheers, Peter Donald
Re: alias :project :define
> Although 'define' cannot be dropped, can we just allow the word 'project' be
> used to create a project by something like method alias?
In several of the projects that I work on I create method at the top
that defines a project with a bunch of defaults. It usually looks
something like the following. So I effectively get a define_project
method that works for me.
def define_iris_project(name, options = {}, &block)
options = options.dup
options[:layout] = ...
options[:base_dir] = ...
define(name, options) do
project.instance_eval &block
project.resources.from project._('src/resources') if File.exist?
project._('src/resources')
project.resources.exclude('**/*.java').exclude('**/*.form')
project.test.resources.exclude('**/*.java')
project.iml.local_repository_env_override = nil if project.iml?
project.clean { rm_rf _(:target, :generated) }
project
end
end
--
Cheers,
Peter Donald
Re: alias :project :define
On Tue, Nov 16, 2010 at 5:04 AM, Alex Boisvert wrote:
> The project method could be overloaded to not only return a project but also
> define a project if a block is given, e.g.,
>
> project :foo # => returns the project named :foo if it exists
>
> project :foo do
> ... # define the project
> end
>
> I feel it would be consistent with many of Rake's task constructors, such as
> file('/path/to/file') do ... end, so I'm open to the idea of allowing this
> provided it doesn't break backward compatibility.
works for me. I would presume that the project named :foo would be
returned from both methods.
> I've also been entertaining the idea (which we discussed this briefly with
> Antoine and Jim Weirich at GoGaRuCo) of aliasing Task.enhance to depends_on,
> accepting either a single task or a list of tasks,
>
> task(:foo).depends_on :bar
>
> task(:foo).depends_on :bar, :baz
+1
> and adding convenience methods such as first, and last:
>
> task(:foo).first do
> # block will be executed before 'enhance' blocks
> end
>
> task(:foo).last do
> # block will be executed after 'enhance' blocks
> end
Although the functionality seems nice, those method names are not
intuitive to me. I can't think of anything better off the top of my
head.
--
Cheers,
Peter Donald
Re: [VOTE] Buildr 1.4.4 release
I tested jruby 1.5.2 (and 1.5.1? I think) under OSX and Windows 7 and all works as epxected. +1 On Wed, Nov 17, 2010 at 12:37 PM, Alex Boisvert wrote: > We're voting on the source distributions available here: > http://people.apache.org/~boisvert/buildr/1.4.4/dist/ > > Specifically: > http://people.apache.org/~boisvert/buildr/1.4.4/dist/buildr-1.4.4.tgz > http://people.apache.org/~boisvert/buildr/1.4.4/dist/buildr-1.4.4.zip > > The documentation generated for this release is available here: > http://people.apache.org/~boisvert/buildr/1.4.4/site/ > http://people.apache.org/~boisvert/buildr/1.4.4/site/buildr.pdf > > The official specification against which this release was tested: > http://people.apache.org/~boisvert/buildr/1.4.4/site/specs.html > > Test coverage report: > http://people.apache.org/~boisvert/buildr/1.4.4/site/coverage/index.html > > > The following changes were made since 1.4.3: > > * Change: BUILDR-549 Upgrade to RJB 1.3.3 to address "Cannot create JVM" > issue with Java Update 3 > on Mac OS X. Win32 platform upgraded to RJB 1.3.2. > * Change: RSpec gem dependency ~> 1.3.1 > * Change: Upgrade to JtestR 0.6 > -- Cheers, Peter Donald
Re: alias :project :define
> I was initially thinking about do_first and do_last but though the "do" was > redundant with Ruby's do ... end notation. Do you think that's better? Not greatly. Maybe firstly and lastly? task(:foo).firstly do # block will be executed before 'enhance' blocks end task(:foo).lastly do # block will be executed after 'enhance' blocks end That way it does not double up the "do" word and doesn't look like an enumeration. -- Cheers, Peter Donald
Re: alias :project :define
Or maybe before/after ala task(:foo).before do # block will be executed before 'enhance' blocks end task(:foo).after do # block will be executed after 'enhance' blocks end On Wed, Nov 17, 2010 at 7:14 PM, Peter Donald wrote: >> I was initially thinking about do_first and do_last but though the "do" was >> redundant with Ruby's do ... end notation. Do you think that's better? > > Not greatly. Maybe firstly and lastly? > > task(:foo).firstly do > # block will be executed before 'enhance' blocks > end > > task(:foo).lastly do > # block will be executed after 'enhance' blocks > end > > That way it does not double up the "do" word and doesn't look like an > enumeration. > > -- > Cheers, > > Peter Donald > -- Cheers, Peter Donald
Re: alias :project :define
>> The idea is that they happen either before/after 'enhance' blocks, with no >> specified ordering between before blocks or after blocks. > > So how would "after" be different from "enhance"? You are right. I guess after is a synonym for enhance. I guess before prepends the block and the prepending happens in evaluation order? -- Cheers, Peter Donald
Re: [VOTE] Buildr 1.4.4 release
>> All gems pushed out, web site updated with new downloads. > > Thanks for the quick fix, Alex. yep - great work. -- Cheers, Peter Donald
Re: alias :project :define
> After mulling over this (and writing but not sending a long email about the > finer semantics I was originally thinking about), I think I'll simplify my > proposal down to, > > task.after [:foo, :bar] do > # ... > end > > which would be exactly like task.enhance, except it would also accept a > single task (i.e., non-array argument.) The block remains optional. > > And secondly, > > task.before [:foo, :bar] do > # ... > end > > would be equivalent to: > > task.enhance do > # ... > end > > task(:foo).enhance [task] > task(:bar).enhance [task] > > Hopefully this is clearer than my previous proposal and promotes better > design. (And I think that what some of you expected the first time around.) > > Makes sense? I think I now understand your intention. Mainly a simple way to enhance multiple tasks at the same time? I thought it was about providinga more fluent API. Have you considered something like the following that would fit more inline with rake terminology? decorate(:foo, :bar).enhance ["myprereq"] do # my after actions end or multi_enhance([:foo, :bar],["myprereq"]) do # my after actions end -- Cheers, Peter Donald
Re: Clojure support in buildr
Hi, On Tue, Dec 7, 2010 at 10:10 AM, Chris Dean wrote: > Anything I can do to help out with getting Clojure support into the > trunk? We still use it daily and would love to see it be in the > mainline code. > > There is a patch in https://issues.apache.org/jira/browse/BUILDR-259 I don't know much about Clojure but I can have a look at it. You could make it easier if you wanted to accelerate the process ;) Best way to do that is goto [1], fork buildr and apply the patches and then make sure that when you run "rake spec" no (extra) failures are caused by the patch. [1] https://github.com/apache/buildr -- Cheers, Peter Donald
Re: Clojure support in buildr
On Tue, Dec 7, 2010 at 11:25 AM, Chris Dean wrote: >> Best way to do that is goto [1], fork buildr and apply the patches and >> then make sure that when you run "rake spec" no (extra) failures are > > Yep, done all that and submitted a patch in BUILDR-259. Well if you could add a link to the github project then that would great. The way I can just merge it, run the tests and makes it much easier to work over it :) The only github project I see in the issue is not based of current version of buildr (It is based off a version from May) and it is by someone else (Daniel Spiewak) so you will need get him to ok the donation (just get him to add a note to the jira issue as he is already a buildr committer). -- Cheers, Peter Donald
Re: Clojure support in buildr
On Tue, Dec 7, 2010 at 12:07 PM, Chris Dean wrote: > Peter Donald writes: >> Well if you could add a link to the github project then that would >> great. The way I can just merge it, run the tests and makes it much >> easier to work over it :) > > Sure thing. There is a repo at > > https://github.com/ctdean/buildr > > But that is also from an older Buildr version. It doesn't match the > patch exactly as I have made a few additions to support the current > (tiny) user base. kool. If you could merge it with the current Buildr version that would be much appreciated. I am not sure how much change has happened in the last 4 months but enough :) -- Cheers, Peter Donald
Re: Buildr idea / idea7x failed on ruby 1.9.x -- String no long has method sort
The idea plugin in trunk has completely rewritten and may or may not suffer from this problem anymore. If you could checkout the latest version of buildr in trunk and try this to see if it is still a problem then that would be muh appreciated. On Wed, Jan 12, 2011 at 6:43 AM, Chiaming Hsu wrote: > I ran into an issue today where idea / idea7x project generations uses method > sort on String. This won't work for ruby 1.9.x: > > $ buildr idea7x > (in /home/camyhsu/code/bug-submit/buildr/ruby1.9-idea, development) > Writing > /home/camyhsu/code/bug-submit/buildr/ruby1.9-idea/ruby1.9-idea-test-7x.ipr > Writing > /home/camyhsu/code/bug-submit/buildr/ruby1.9-idea/subproject/ruby1.9-idea-test-subproject-7x.iml > > Buildr aborted! > NoMethodError : undefined method `sort' for "src/test/java":String > > (See full trace by running task with --trace) > $ > > > Is this a known issue? I saw a ticket for ruby 1.9 compatibility. Should I > add > a comment to that ticket or open a new bug under IDE integration? > > Cheers, > Chiaming Hsu > -- Cheers, Peter Donald
Re: Buildr 1.4.5 next week?
Hi, I tested it out on all our builds and only found one issue. JIRA is down for system maintenance right nowso I have attached a patch to address this but am away from the computer with the key to access svn atm. So if you could make sure this change gets in before release I am +1 for a release. The message for the commit should be something like Ensure that the IDEA module is generated correctly when the module contains no java files. Without this change the output directory would be the project root which would end up being excluded as a result. This problem was caused by the refactor of the plugin prior to migrating it into buildr core. On Fri, Jan 28, 2011 at 4:54 PM, Alex Boisvert wrote: > I'm thinking about releasing Buildr 1.4.5 towards end of next week. I want > to keep pushing regular releases out and I think we have a fair number of > issues/changes that would benefit our users. > > If you want to get anything else in this release or feel the timing isn't > right, please shout. -- Cheers, Peter Donald
Re: IntelliJ IDEA specs failing
> 1) Buildr::IntellijIdea Buildr::IntellijIdea::IdeaModule with
> local_repository_env_override = nil base_directory on different drive on
> windows generates relative paths correctly
> Failure/Error: @foo.iml.send(:resolve_path, "E:/foo").should
> eql('E:/foo')
>
> expected "E:/foo"
> got "$MODULE_DIR$/../../E:/foo"
>
> (compared using eql?)
> # ./spec/ide/idea_spec.rb:1030
>
> Is this something you can reproduce?
All of my testing has been done with jruby 1.5.2 or 1.5.6.RC1 on
windows 7 atm and I don't have access to a *nix box. I suspect it is
probably a difference between how the path is handled on *nix or
perhaps on the MRI. You could possible guard the spec with an "if
Buildr::Util.win_os?" if that is the case.
--
Cheers,
Peter Donald
sh fails under jruby 1.6.0.RC1
Hi, Unfortunately one of the hacks in sh implementation no longer works in the latest jruby due to $? variable being read only. A typical stack trace describing the error is; C:\dev\iris\trunk>buildr artifacts:sources --trace This build requires the gems buildr-iidea-0.0.10: do you want me to install them? [Y/n] Y Installing buildr-iidea-0.0.10 ... C:\Applications\jruby-1.6.0.RC1\bin\jruby -S gem install buildr-iidea -v 0.0.10 Fetching: buildr-iidea-0.0.10.gem (100%) Thanks for installing the Intellij IDEA extension for Buildr Successfully installed buildr-iidea-0.0.10 1 gem installed Buildr aborted! NameError : $? is a read-only variable C:/Applications/jruby-1.6.0.RC1/lib/ruby/gems/1.8/gems/buildr-1.4.4-java/lib/buildr/core/util.rb:487:in `sh' C:/Applications/jruby-1.6.0.RC1/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:1098:in `sh' C:/Applications/jruby-1.6.0.RC1/lib/ruby/gems/1.8/gems/buildr-1.4.4-java/lib/buildr/core/util.rb:65:in `ruby' C:/Applications/jruby-1.6.0.RC1/lib/ruby/gems/1.8/gems/buildr-1.4.4-java/lib/buildr/core/util.rb:181:in `command' C:/Applications/jruby-1.6.0.RC1/lib/ruby/gems/1.8/gems/buildr-1.4.4-java/lib/buildr/core/util.rb:167:in `install'org/jruby/RubyArray.java:1671:in `each' C:/Applications/jruby-1.6.0.RC1/lib/ruby/gems/1.8/gems/buildr-1.4.4-java/lib/buildr/core/util.rb:165:in `install' C:/Applications/jruby-1.6.0.RC1/lib/ruby/gems/1.8/gems/buildr-1.4.4-java/lib/buildr/core/application.rb:421:in `load_gems' C:/Applications/jruby-1.6.0.RC1/lib/ruby/gems/1.8/gems/buildr-1.4.4-java/lib/buildr/core/application.rb:215:in `load_buildfile' C:/Applications/jruby-1.6.0.RC1/lib/ruby/gems/1.8/gems/buildr-1.4.4-java/lib/buildr/core/application.rb:523:in `standard_exception_handling' C:/Applications/jruby-1.6.0.RC1/lib/ruby/gems/1.8/gems/buildr-1.4.4-java/lib/buildr/core/application.rb:213:in `load_buildfile' C:/Applications/jruby-1.6.0.RC1/lib/ruby/gems/1.8/gems/buildr-1.4.4-java/lib/buildr/core/application.rb:137:in `run' C:/Applications/jruby-1.6.0.RC1/lib/ruby/gems/1.8/gems/buildr-1.4.4-java/lib/buildr/core/application.rb:523:in `standard_exception_handling' C:/Applications/jruby-1.6.0.RC1/lib/ruby/gems/1.8/gems/buildr-1.4.4-java/lib/buildr/core/application.rb:135:in `run' C:/Applications/jruby-1.6.0.RC1/lib/ruby/gems/1.8/gems/buildr-1.4.4-java/bin/buildr:19:in `(root)'org/jruby/RubyKernel.java:1066:in `load' -- Cheers, Peter Donald
Re: [VOTE] Buildr 1.4.5 release
+1
Tested it out on all my local builds and it seems to all good.
On Tue, Feb 22, 2011 at 12:27 PM, Alex Boisvert wrote:
> We're voting on the source distributions available here:
> http://people.apache.org/~boisvert/buildr/1.4.5/dist/
>
> Specifically:
> http://people.apache.org/~boisvert/buildr/1.4.5/dist/buildr-1.4.5.tgz
> http://people.apache.org/~boisvert/buildr/1.4.5/dist/buildr-1.4.5.zip
>
> The documentation generated for this release is available here:
> http://people.apache.org/~boisvert/buildr/1.4.5/site/
> http://people.apache.org/~boisvert/buildr/1.4.5/site/buildr.pdf
>
> The official specification against which this release was tested:
> http://people.apache.org/~boisvert/buildr/1.4.5/site/specs.html
>
> Test coverage report:
> http://people.apache.org/~boisvert/buildr/1.4.5/site/coverage/index.html
>
>
> The following changes were made since 1.4.4:
>
> * Added: BUILDR-555 Add support for the jaxb binding compiler (Mark
> Petrovic)
> * Added: BUILDR-554 Add support for OSGi bundle packages by importing the
> buildr_bnd plugin
> * Added: BUILDR-125 Add support for in application.xml of
> EAR packaging (Mikael Amborn)
> * Added: BUILDR-550 Add support for groovydoc
> * Added: BUILDR-521: System tray notifications for Linux systems
> (via libnotify/notify-send)
> * Added: BUILDR-537 Shell tasks should use JAVA_OPTS by default
> * Added: BUILDR-538 Shell tasks should support passing :java_args
> * Added: BUILDR-544 Support ${groupId} in pom files (Chris Dean)
> * Added: BUILDR-552 Projects may now be defined using project(:name) and
> a block
> * Added: BUILDR-564 Add package(:scaladoc)
> * Added: Automatically add "require buildr/{groovy,scala}" when
> generating
> project if Groovy/Scala files are detected.
> * Change: BUILDR-540 Upgrade to rspec 2.1.0
> * Change: BUILDR-546 Upgrade to Rubyzip 0.9.4 (Michael Guymon)
> * Change: BUILDR-556 Merge buildr-iidea extension back into buildr.
> * Change: Upgrade default Scala compiler version to 2.8.1-final
> * Change: Upgrade to ScalaCheck 1.8
> * Change: Upgrade to ScalaTest 1.3
> * Change: Upgrade to Specs 1.6.6
> * Chagne: Upgrade to JRuby 1.5.6
> * Fixed: BUILDR-542 Release task: SVN tagging fails if parent tag
> directory
> does not exist yet (Gerolf Seitz)
> * Fixed: BUILDR-543 POMs are installed and uploaded twice when using
> artifacts
> with classifier
> * Fixed: BUILDR-522 Send notifications when continuous compilation
> succeeds/fails.
> * Fixed: BUILDR-551 Continuous compilation not working for project trees
> * Fixed: BUILDR-557 MD5 + SHA1 checksums are not Maven compliant (Tammo
> van Lessen)
> * Change: Upgrade to Groovy 1.7.5
> * Change: BUILDR-545 Add the ability to specify the description element in
> in
> application.xml contained within an ear.
> * Fixed: BUILDR-547 - Ensure ECJ compiler works when there is a space in
> the
> path of dependencies.
> * Fixed: BUILDR-558 Artifact uploads should show a progress bar (Tammo
> van Lessen)
> * Fixed: BUILDR-560 show a meaning full error message when POM cannot be
> parsed
> (Tammo van Lessen)
> * Fixed: BUILDR-562 WAR package isn't updated if files under
> src/main/webapp
> are updated
> * Fixed: BUILDR-569 Buildr fails under JRuby 1.6.0.RC1 due to read-only
> $? variable
> * Fixed: BUILDR-570 Buildr does not work with Rubygems 1.5.x
> * Fixed: Scaladoc task would cause build to exit prematurely
>
--
Cheers,
Peter Donald
Re: Maven SNAPSHOT timestamps
On Sat, Mar 12, 2011 at 12:11 PM, Alex Boisvert wrote: > So we got a nice > contribution<https://issues.apache.org/jira/browse/BUILDR-572>from > Brice Figureau to add timestamps when uploading Maven SNAPSHOT > artifacts. looks good. > I'm tempted to turn the feature on by default since I believe it's the right > thing to do (compatibility-wise) on Maven repos. However, it could be a > breaking change if people currently depend on SNAPSHOTs being updated > in-place instead of uploading a new artifact with a timestamp. > > Anybody has a strong opinion about this? I think we should do the "right" thing and be compatibile with Maven. -- Cheers, Peter Donald
Re: idea task
Hi, I am currently in the Himalayas - but I will apply the fix when I get back. Thanks! On Friday, March 18, 2011, Jean-Philippe Caruana wrote: > On 17/03/2011 15:32, Rhett Sutphin wrote: > > I didn't realize that IDEA supported dependency scope now. That's good to > know. (Apparently[1] it was added in IDEA 9.) > > To track this request, you should open an issue in buildr's JIRA. If you want > to supply a patch you attach it there. (This process is required by the ASF.) > I haven't looked at your patch, so I'm not sure if it's the right solution. > > > ok : my patch is attached to this email and to JIRA too : see > https://issues.apache.org/jira/browse/BUILDR-574 > > > Also, a remark. The CLI API changed : in the past, a simple "buildr idea" was > ok to generated idea files, but now we have to do a "buildr idea:generate". > This is inconsistent with the eclipse plugin (still "buildr eclipse"), makes > me think of the infamous "mvn eclipse:eclipse" (argh ! eclipse twice !) and > shows implementation details to the final user. What do you think about it ? > Should I file a bug for that too ? > > > I agree that it should be possible to do just "buildr idea". You should open > another issue for this request. > > > ok: https://issues.apache.org/jira/browse/BUILDR-575 > > > As a workaround (and this is what I've been doing), you can add an idea task > at the top level of your buildfile: > task :idea => "idea:generate" > > > I did the same :-) > > > Rhett > > > -- > Jean-Philippe Caruana > -- > sorry for the crap that will be appended here: > > > Ce message et toutes les pieces jointes (ci-apres le "message") sont > confidentiels et etablis a l'attention exclusive de ses destinataires. > Toute utilisation ou diffusion non autorisee est interdite. > Tout message electronique est susceptible d'alteration. Multimedia Business > Services decline > toute responsabilite au titre de ce message s'il a ete altere, deforme > ou falsifie. > Si vous n'etes pas destinataire de ce message, merci de le detruire > immediatement et d'avertir l'expediteur. > * > This message and any attachments (the "message") are confidential and > intended solely for the addressees. Any unauthorised use or > dissemination is prohibited. > Messages are susceptible to alteration. Multimedia Business Services shall > not be liable for the > message if altered, changed or falsified. > If you are not the intended addressee of this message, please cancel it > immediately and inform the sender.. > > -- Cheers, Peter Donald
Re: idea task
Hi, I think all the issues have been addressed. If I missed anything then just raise another issue - thanks! -- Cheers, Peter Donald
Re: Working on CI build again
Hi, On Tue, Jun 7, 2011 at 5:10 PM, Antoine Toulme wrote: > I was able to run successfully the build on the machine - I mean, the build > ran to the end, I'm not sure all specs pass. great work. It would be good to get some visibility into the build again ;) -- Cheers, Peter Donald
Re: Time for a release
On Sat, Jun 18, 2011 at 6:22 AM, Alex Boisvert wrote: > We've accumulated a number of bug fixes + changes since 1.4.5 and it seems > it's time for a release... Sounds good to me! -- Cheers, Peter Donald
Re: [VOTE] Buildr 1.4.6 release
Hi, +1 I ran all my builds using the new buildr and everything seems to be working all good. On Wed, Jun 22, 2011 at 7:40 AM, Alex Boisvert wrote: > We're voting on the source distributions available here: > http://people.apache.org/~boisvert/buildr/1.4.6/dist/ > > Specifically: > http://people.apache.org/~boisvert/buildr/1.4.6/dist/buildr-1.4.6.tgz > http://people.apache.org/~boisvert/buildr/1.4.6/dist/buildr-1.4.6.zip > > The documentation generated for this release is available here: > http://people.apache.org/~boisvert/buildr/1.4.6/site/ > http://people.apache.org/~boisvert/buildr/1.4.6/site/buildr.pdf > > The official specification against which this release was tested: > http://people.apache.org/~boisvert/buildr/1.4.6/site/specs.html > > Test coverage report: > http://people.apache.org/~boisvert/buildr/1.4.6/site/coverage/index.html > > IMPORTANT NOTE: This release includes JtestR support; the code is same as > for previous release except it was not tested during the release process. > Caveat emptor. Removal of JtestR support is currently under discussion on > dev@buildr.apache.org. > > The following changes were made since 1.4.5: > > * Added: Support for Scala 2.9.0+ (with help of Alexis Midon) > * Fixed: BUILDR-583 Update jruby install to use jruby version 1.6.1 > (Alexis Midon) > * Fixed: BUILDR-582 Revert the name change for the task to generate > Intellij > project files to 'idea' > * Change: BUILDR-579 Format generated IDEA project files to look more like > what > IntelliJ generates (Peter Royal) > * Change: BUILDR-574 Enhance idea task to generate test resources with > test scope > (Jean-Philippe Caruana) > * Change: BUILDR-576 Upgrade to JUnit 4.8.2 > * Change: Upgrade to JRuby 1.6.2 > * Change: Scala 2.9.0-1 is now default, along with ScalaCheck 1.9, > ScalaTest 1.6.1 > and Specs 1.6.8. > * Change: ScalaCheck, ScalaTest and Specs now default to sane versions > when using > older Scala versions. > * Fixed: BUILDR-571 Generated IDEA projects include resources multiple > times (Peter Royal) > * Fixed: BUILDR-573 HTTP upload PUT request with incorrect Content-Type > (Mathias Doenitz) > * Fixed: BUILDR-578 Tar task does not preserve uid/gid on folders > (Jean-Philippe Caruana) > * Fixed: BUILDR-251 Classifier not handled when downloading snapshot > artifacts (Ryan Fowler) > * Fixed: BUILDR-585 "TypeError : can't dup NilClass" when merging jars > * Fixed: BUILDR-586 ScalaTest uses deprecated ant task (Martin Partel) > * Fixed: BUILDR-584 eclipse plugin should use absolute path > * Fixed: BUILDR-587 ScalaTest uses deprecated reporter parameters > -- Cheers, Peter Donald
Re: [VOTE] Buildr 1.4.6 release
Actually looks like a bug was found. I need to apply BUILDR-591 before the release. On Wed, Jun 22, 2011 at 9:56 AM, Peter Donald wrote: > Hi, > > +1 > > I ran all my builds using the new buildr and everything seems to be > working all good. > > On Wed, Jun 22, 2011 at 7:40 AM, Alex Boisvert > wrote: >> We're voting on the source distributions available here: >> http://people.apache.org/~boisvert/buildr/1.4.6/dist/ >> >> Specifically: >> http://people.apache.org/~boisvert/buildr/1.4.6/dist/buildr-1.4.6.tgz >> http://people.apache.org/~boisvert/buildr/1.4.6/dist/buildr-1.4.6.zip >> >> The documentation generated for this release is available here: >> http://people.apache.org/~boisvert/buildr/1.4.6/site/ >> http://people.apache.org/~boisvert/buildr/1.4.6/site/buildr.pdf >> >> The official specification against which this release was tested: >> http://people.apache.org/~boisvert/buildr/1.4.6/site/specs.html >> >> Test coverage report: >> http://people.apache.org/~boisvert/buildr/1.4.6/site/coverage/index.html >> >> IMPORTANT NOTE: This release includes JtestR support; the code is same as >> for previous release except it was not tested during the release process. >> Caveat emptor. Removal of JtestR support is currently under discussion on >> dev@buildr.apache.org. >> >> The following changes were made since 1.4.5: >> >> * Added: Support for Scala 2.9.0+ (with help of Alexis Midon) >> * Fixed: BUILDR-583 Update jruby install to use jruby version 1.6.1 >> (Alexis Midon) >> * Fixed: BUILDR-582 Revert the name change for the task to generate >> Intellij >> project files to 'idea' >> * Change: BUILDR-579 Format generated IDEA project files to look more like >> what >> IntelliJ generates (Peter Royal) >> * Change: BUILDR-574 Enhance idea task to generate test resources with >> test scope >> (Jean-Philippe Caruana) >> * Change: BUILDR-576 Upgrade to JUnit 4.8.2 >> * Change: Upgrade to JRuby 1.6.2 >> * Change: Scala 2.9.0-1 is now default, along with ScalaCheck 1.9, >> ScalaTest 1.6.1 >> and Specs 1.6.8. >> * Change: ScalaCheck, ScalaTest and Specs now default to sane versions >> when using >> older Scala versions. >> * Fixed: BUILDR-571 Generated IDEA projects include resources multiple >> times (Peter Royal) >> * Fixed: BUILDR-573 HTTP upload PUT request with incorrect Content-Type >> (Mathias Doenitz) >> * Fixed: BUILDR-578 Tar task does not preserve uid/gid on folders >> (Jean-Philippe Caruana) >> * Fixed: BUILDR-251 Classifier not handled when downloading snapshot >> artifacts (Ryan Fowler) >> * Fixed: BUILDR-585 "TypeError : can't dup NilClass" when merging jars >> * Fixed: BUILDR-586 ScalaTest uses deprecated ant task (Martin Partel) >> * Fixed: BUILDR-584 eclipse plugin should use absolute path >> * Fixed: BUILDR-587 ScalaTest uses deprecated reporter parameters >> > > > > -- > Cheers, > > Peter Donald > -- Cheers, Peter Donald
Re: [VOTE] Buildr 1.4.6 release
Hi, 2011/6/22 Marc-André Laverdière : > I would like to see my patch for the SSH options to be included as well. :) Couldn't spot a jira issue for it? If you have a patch and testcase could you attach it to an issue (and tick the donate to apache box) and I will look at it before the release. -- Cheers, Peter Donald
Jira Spam
Hi, Sorry about the jira spam. I just moved all the resolved issues to closed. I expected Jira to ask if you did not want to send out emails (our local setup does this) so didn't mean to spam the list. Hopefully it has finished now ;) -- Cheers, Peter Donald
Re: [VOTE] Buildr 1.4.6 release
Hi, 2011/6/22 Marc-André Laverdière : > I had reported this to the mailing list a while back. > In my n00bness I forgot to have it into an issue. I just did that with my > patch. > > Its probably not the most optimal way of doing it :$ > > https://issues.apache.org/jira/browse/BUILDR-592 I applied a variant of this patch. If you could check it still works for you that would be great. Thanks! -- Cheers, Peter Donald
Jenkins Documentation?
Hi, Is there any documentation on how we manage the Buildr jenkins jobs? I wouldn't mind getting in and tackling the last few issues that are stopping us getting a clean build. -- Cheers, Peter Donald
Re: JSP Precompilation
Hi, On Fri, Jul 22, 2011 at 5:24 AM, Christopher Coco wrote: > I'm wondering if anyone has picked up this thread: > > > http://old.nabble.com/buildr-pre-compile-JSP-for-war--td17109370.html#a17109370 Not that I am aware of. It's more than 3 years old, but Buildr still seems to be lacking this > functionality. I wrote a JSP pre-compiler specific for my company, but would > be willing to try to abstract it. Again, being new to Ruby and Buildr, I'm > trying to figure out the best way to integrate this functionality. It's java > specific, and I had thought that a c ouple of possibilities could be to > a.) extend the java compiler functionality (though jsp compilation seems > like a stretch here), > b.) to extend the WAR packaging functionality (where I'm leaning), > c.) separate it completely like the scala plugin (make this is more > robust?), > d.) or even just drop it in as an add-on (not sure the pros/cons). > > I'm looking for some views or opinions on a best approach. Any thoughts? > My approach has always bee d) where possible - it allows you to rapidly evolve the plugin and share it between all the different projects that use it. It also makes it easy to write tests and validate it easily. If the plugin gets general enough and well tested enough you can always donate it back to this project. This is the approach I took with various plugins. For example [1] is a plugin I developed outside as an extension that eventually folded back into buildr while [2] is something that I never get around to cleaning up. You will notice that many of the extensions I have made actually call out to ant tasks or directly call command line apps. I think this is a perfectly reasonable way to approach things. [1] https://github.com/realityforge/buildr-bnd [2] https://github.com/realityforge/buildr-ipojo -- Cheers, Peter Donald
Cetralize Requires?
Hi, I would like to make the ordering of the requires of internal buildr files explicit. The aim being to simplify understanding and stop presenting the illusion that you ca require files in the depths of buildr and have things work. You can see the changeset as follows; https://github.com/realityforge/buildr/compare/trunk...unify-requires You will notice that almost all of the internal requires are ow in lib/buildr.rb - the only exceptions being the scala/closure/groovy support that still exist to make it possible to optionally load these. Requires that are common across the codebase were also pushed into this location. So what do you think? Is it worth applying? -- Cheers, Peter Donald
Updating to rubygems 1.8.6?
Hi, I am looking at upgrading buildrs dependency on rubygems to a later version and being more explicit about the version. i.e. Something like spec.add_dependency 'rubygems-update', '>= 1.8.6' However as I was going through this I noticed we are using a whole whackload of deprecated features that is planned to be remove from rubygems in the next few months, in particular "Gem:SourceIndex". We mostly use the plugin to ensure the build has necessary dependencies before it rus (i.e. if you have added it to build.yaml) and to install gems as part of :gem packaging. As both of these features were broken up until a few releases ago I would guess they are barely used. In some environments some of these features continue to be broken (in particular installing of gems). The ruby world seems to be going in a few different directions to manage dependencies (i.e. rvm, bundler, ...) but most of them involve the runtime managing them. So I propose that we remove all the usage of these features and just consider the rubygems library as a read-only interface. We could change the startup scanning of build.yaml and rather than trying to install missing dependencies just print an error on the console and exit. For the :install phase of gem package I think it would be best to let people manage it in a way that makes sense in their environment. We could add documentation to fill this gap. Thoughts? -- Cheers, Peter Donald
Re: Updating to rubygems 1.8.6?
On Wed, Jul 27, 2011 at 12:24 AM, Rhett Sutphin wrote: > > I am looking at upgrading buildrs dependency on rubygems to a later > version > > and being more explicit about the version. i.e. Something like > > > > spec.add_dependency 'rubygems-update', '>= 1.8.6' > > Good idea, though the gemspec line you want is something like this: > > s.required_rubygems_version = ">= 1.8.6" > oops - thanks! > Is 1.8.6 specifically required? I would ask that you try to make this as > loose as possible. Many releases in the 1.7 and 1.8 line have been broken or > unreasonably noisy, so I have been conservative about upgrading. (I'm still > mostly using 1.6.2.) > 1.6.2 was log enough ago that it does include all the deprecation warnings that I am wanting to fix. I tried playing around witha few versions in between but as you say many of them seemed buggy. 1.8.0 and 1.8.1 in particular seemed more bad than usual but 1.8.3 and 1.8.4 did not seem much better. Havig at the release timing of each version @ http://rubygems.org/gems/rubygems-update/versions would seem to support that idea. So far I have yet to find any bugs i 1.8.6 but I am doing some more comprehensive testing over the next week or so. So unless any bugs pop up I would prefer to keep it at 1.8.6 and if not roll back to 1.8.5. Thoughts? -- Cheers, Peter Donald
Jenkins Builds
Hi, The CI is now successfully building in all the different configurations except win32. I had to disable some tests on the jdk1.5 configuration as they use jdk 1.6 features. I wouldn't mind chasing up the win32 build but I am not sure how/where I go to try and find documentation for how to configure it. Any ideas? -- Cheers, Peter Donald
Re: Android extension (WIP)
Hi, On Tue, Aug 9, 2011 at 4:51 AM, Pepijn Van Eeckhoudt wrote: > 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. great. > 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. I don't do any development on android based stuff but I think it would be a great addition. The only issue would be keeping up development velocity. I would probably do what I did with the OSGI bundle extension to keep your own pace going. I initially developed it outside of buildr on github (https://github.com/realityforge/buildr-bnd) and packaged it as a gem. As it got settled down, documented and tested I eventually merged it back into mainline of buildr. This allowed me to do several releases of buildr-bnd as a gem without being tied to the release cycle of buildr. -- Cheers, Peter Donald
Re: New release ?
A release sounds good but there's a few addons I wouldn't mind putting into the release. Hopefully I will get to it by the end of next weekend On Sun, Oct 23, 2011 at 11:38 AM, Antoine Toulme wrote: > Hi folks, > > thanks for the hard work and keeping this up. I apologize I can't take as > much time as I'd like on Buildr. > > I looked up the changelog and it looks to me that we are ripe for a new > release - and I'm willing to help push it out. > > WDYT ? > > Antoine > -- Cheers, Peter Donald
Re: New release ?
I have added the set of addons for now. I have a whole slew of others I may add in after the release. On Mon, Oct 24, 2011 at 8:56 AM, Peter Donald wrote: > A release sounds good but there's a few addons I wouldn't mind putting > into the release. Hopefully I will get to it by the end of next > weekend > > On Sun, Oct 23, 2011 at 11:38 AM, Antoine Toulme > wrote: >> Hi folks, >> >> thanks for the hard work and keeping this up. I apologize I can't take as >> much time as I'd like on Buildr. >> >> I looked up the changelog and it looks to me that we are ripe for a new >> release - and I'm willing to help push it out. >> >> WDYT ? >> >> Antoine >> > > > > -- > Cheers, > > Peter Donald > -- Cheers, Peter Donald
Re: Experiences with transitive dependencies in buildr
Hi, On Sat, Oct 29, 2011 at 5:43 AM, Michael Guymon wrote: > The integration with buildr is crude and for some reason the rdoc is no > longer formated correct. I will update it to make it legible again. > > https://github.com/mguymon/buildr-resolver nice. > This is the ruby wrapper for the Aether java libs, which buildr-resolver > depends on > > https://github.com/mguymon/naether That is quite neat. I wonder if the core of buildr could move across to using (n)Aether and if there is much benefit from that? Last time I looked the project was still relatively volatile. What did you think of working with the library? The one advantage I see is that it would be using the same core as maven and thus guaranteed to be compatible (where as now we know there is scenarios where we are not quite right). -- Cheers, Peter Donald
Re: Experiences with transitive dependencies in buildr
Hi, On Thu, Nov 3, 2011 at 12:26 AM, Chiaming Hsu wrote: > If this becomes part of the core of buildr as Peter suggested, would there be > performance impact when not using transitive dependencies? I would hope not. I am not a huge fan of transitive closure across the builds when you can't lock it down to a specific set (like Gemfile.lock or what Ivy4r supports it seems). I don't object so much to the network chattiness but due to the un-reproducible of builds. Aether would mainly used as the API for interacting with Maven repos and for implementing transitive dependencies of maven artifacts. -- Cheers, Peter Donald
Re: Experiences with transitive dependencies in buildr
On Fri, Nov 4, 2011 at 10:16 AM, Michael Guymon wrote: > So based on the discussion, it sounds like the following solutions would > work well: > > Dependency Resolution > > * Dependency resolution is optional > * Resolve Transitive Dependencies for an artifact(s) > * Create/Rebuild a dependency file > * Lock dependencies based on the dependency file That sounds about right. > Maven interop > > * Generate a maven POM based on a Buildr project > * Create & deploy maven friendly artifacts based on a Buildr project That would be very useful. A couple of people I have talked to in the past would be extremely happy if we could generate the maven pom with enough information that would allow it to be uploaded to maven central. > Would there be any benefit for having Ivy interoperability as well? I haven't seen much use of it in the wild so I don't see it as a priority but others may disagree ;) -- Cheers, Peter Donald
Re: New release ?
Hi, I have added everything I wanted to for this release. On Wed, Nov 2, 2011 at 2:08 PM, Peter Donald wrote: > I have added the set of addons for now. I have a whole slew of others > I may add in after the release. > > On Mon, Oct 24, 2011 at 8:56 AM, Peter Donald wrote: >> A release sounds good but there's a few addons I wouldn't mind putting >> into the release. Hopefully I will get to it by the end of next >> weekend >> >> On Sun, Oct 23, 2011 at 11:38 AM, Antoine Toulme >> wrote: >>> Hi folks, >>> >>> thanks for the hard work and keeping this up. I apologize I can't take as >>> much time as I'd like on Buildr. >>> >>> I looked up the changelog and it looks to me that we are ripe for a new >>> release - and I'm willing to help push it out. >>> >>> WDYT ? >>> >>> Antoine >>> >> >> >> >> -- >> Cheers, >> >> Peter Donald >> > > > > -- > Cheers, > > Peter Donald > -- Cheers, Peter Donald
Re: Experiences with transitive dependencies in buildr
On Fri, Nov 11, 2011 at 3:21 AM, Michael Guymon wrote: > So there seems to be agreement on a initial solution. Should this be tracked > in Jira? Sounds good. > I plan on helping out, but work is eating all my spare time right now. On > top of that, I have a queue of patches I need to send out, so I will not be > able to produce anything in the near future. great ;) Anytime you do manage will be appreciated. -- Cheers, Peter Donald
Re: [VOTE] Buildr 1.4.7 RC1
It looks good so far but I plan on putting it through a larger suite of tests of Monday. Thanks for the good work! On Fri, Nov 18, 2011 at 6:06 PM, Antoine Toulme wrote: > Vote is opened for a week. > > We're voting on the source distributions available here: > http:/people.apache.org/~toulmean/buildr/1.4.7/dist/ > > Specifically: > http:/people.apache.org/~toulmean/buildr/1.4.7/dist/buildr-1.4.7.tgz > http:/people.apache.org/~toulmean/buildr/1.4.7/dist/buildr-1.4.7.zip > > The documentation generated for this release is available here: > http:/people.apache.org/~toulmean/buildr/1.4.7/site/ > http:/people.apache.org/~toulmean/buildr/1.4.7/site/buildr.pdf > > The official specification against which this release was tested: > http:/people.apache.org/~toulmean/buildr/1.4.7/site/specs.html > > Test coverage report: > http:/people.apache.org/~toulmean/buildr/1.4.7/site/coverage/index.html > > 1.4.7 (2011-11-17) > * Added: Add a Findbugs extension. > * Added: Add a Checkstyle extension. > * Added: Add a JavaNCSS extension. > * Added: Add a PMD extension. > * Added: MultiTest framework that allows combining multiple test frameworks > for a single project. > * Added: Scala Specs2 framework support. > * Added: Buildr.transitive() now accepts hash with :scopes, :optional and > :scopes_transitive parameters > * Added: Improved scala file change detection > (to avoid recompiling unnecessarily) > * Added: ScalaTest now automatically loads the Mockito library > * Added: Enhance the Intellij IDEA extension to support the addition of > "artifacts" > and "configurations" to the generated project file. > * Added: BUILDR-598 TestNG support for :groups and :excludegroups > (Christopher Coco) > * Added: BUILDR-616 Buildr development - If using rvm a default .rvmrc > file would be helpful (Russell Teabeault) > * Change: Scala Specs upgraded to 1.6.9 if using Scala 2.9.1 > * Change: Scala 2.9.1 is now default > * Change: Make it possible to parameterize the JDepend extension and > control the > projects that are included in the analysis and to enable support > for > loading a per project jdepend.properties. > * Change: Parameterize the the directory where the top level cobertura > tasks will generate > reports. Specify using Buildr::Cobertura.report_dir = '' > * Change: Stop pretty printing the Intellij IDEA project files to avoid > IDEA breaking > in the presence of non-normalized whitespace content. > * Change: Change the Intellij IDEA extension to always rebuild the project > files. > * Change: Upgrade to require atoulme-Antwrap 0.7.2 > * Change: Changed the default output directory for Intellij IDEA extension > to be > _(:target, :main, :idea, :classes) from _(:target, :main, :java) > and the > default test output directory to be _(:target, :test, :idea, > :classes) > from _(:target, :test, :java) > * Change: Upgrade to highline 1.6.2 > * Change: Upgrade to jekyll 0.11.0, jekylltask 1.1.0, RedCloth 4.2.7, rdoc > 3.8 for > generating documentation > * Change: Upgrade to require rubygems > 1.8.6 > * Change: BUILDR-603 Remove install/uninstall actions from :gem packaging > type > * Change: BUILDR-602 Fail the build when gem dependencies are missing > rather than > attempting to install the dependencies > * Change: BUILDR-601 Remove Buildr::Util::Gems > * Change: BUILDR-600 Centralize the common ad internal requires into one > location. > * Change: Upgrade to JRuby 1.6.2 > * Change: Move to Bundler to manage the project dependencies > * Change: BUILDR-548 Remove support for JTestR as it is no longer > maintained (Antoine Toulme) > * Change: BUILDR-614 Buildr development - Using rvm, bundler and OSX > installs the wrong rjb (Russell Teabeault) > * Change: Upgrade to RJB 1.3.7 > * Fixed: ArtifactNamespace fails when using artifacts with classfier. > * Fixed: Buildr.artifacts() should handle any object with :to_spec method > (i.e., any object that ActsAsArtifact) > * Fixed: Handle HTTP Unauthorized (501) result code when downloading > artifacts. > * Fixed: BUILDR-611 Buildr should not unnecessarily recompile Java files > explicitly added to compile.from > * Fixed: scaladoc generation with scala 2.9.x > * Fixed: Bnd Plugin: Add each artifact individually as a prerequisite to > bundle / package task when passed to classpath_element method > * Fixed: BUILDR-439 "The command line is too long" when running TestNG > tests (Tammo Van Lessen) > * Fixed: BUILDR-595 Add option to specifiy location of ca cert > * Fixed: BUILDR-596 Update installation notes to talk about the all-in-one > bundle > -- Cheers, Peter Donald
Re: [VOTE] Buildr 1.4.7 RC1
Hi, I attempted to get the packages at http:/people.apache.org/~toulmean/buildr/1.4.7/dist/ working but ran into some issues. I then did a blank rvm install and attempted again with no success. Here is what happened... $ wget http://people.apache.org/~toulmean/buildr/1.4.7/dist/buildr-1.4.7.gem $ rvm use ruby-1.8.7-p352 $ gem install buildr-1.4.7.gem ERROR: While executing gem ... (ArgumentError) Illformed requirement ["# 2.0.23"] $ wget http://people.apache.org/~toulmean/buildr/1.4.7/dist/buildr-1.4.7-java.gem $ rvm use jruby-1.6.3 $ gem install buildr-1.4.7-java.gemERROR: While executing gem ... (NoMethodError) undefined method `call' for nil:NilClass Any ideas? On Wed, Nov 23, 2011 at 10:27 AM, Antoine Toulme wrote: > Please let me know if it looks good on your end. It would be great to get > validation that it works for Scala projects (the new version brings in > support for 2.9.1). > > Cheers, > > Antoine > > On Fri, Nov 18, 2011 at 20:00, Peter Donald wrote: > >> It looks good so far but I plan on putting it through a larger suite >> of tests of Monday. >> >> Thanks for the good work! >> >> On Fri, Nov 18, 2011 at 6:06 PM, Antoine Toulme >> wrote: >> > Vote is opened for a week. >> > >> > We're voting on the source distributions available here: >> > http:/people.apache.org/~toulmean/buildr/1.4.7/dist/ >> > >> > Specifically: >> > http:/people.apache.org/~toulmean/buildr/1.4.7/dist/buildr-1.4.7.tgz >> > http:/people.apache.org/~toulmean/buildr/1.4.7/dist/buildr-1.4.7.zip >> > >> > The documentation generated for this release is available here: >> > http:/people.apache.org/~toulmean/buildr/1.4.7/site/ >> > http:/people.apache.org/~toulmean/buildr/1.4.7/site/buildr.pdf >> > >> > The official specification against which this release was tested: >> > http:/people.apache.org/~toulmean/buildr/1.4.7/site/specs.html >> > >> > Test coverage report: >> > http:/people.apache.org/~toulmean/buildr/1.4.7/site/coverage/index.html >> > >> > 1.4.7 (2011-11-17) >> > * Added: Add a Findbugs extension. >> > * Added: Add a Checkstyle extension. >> > * Added: Add a JavaNCSS extension. >> > * Added: Add a PMD extension. >> > * Added: MultiTest framework that allows combining multiple test >> frameworks >> > for a single project. >> > * Added: Scala Specs2 framework support. >> > * Added: Buildr.transitive() now accepts hash with :scopes, :optional >> and >> > :scopes_transitive parameters >> > * Added: Improved scala file change detection >> > (to avoid recompiling unnecessarily) >> > * Added: ScalaTest now automatically loads the Mockito library >> > * Added: Enhance the Intellij IDEA extension to support the addition of >> > "artifacts" >> > and "configurations" to the generated project file. >> > * Added: BUILDR-598 TestNG support for :groups and :excludegroups >> > (Christopher Coco) >> > * Added: BUILDR-616 Buildr development - If using rvm a default .rvmrc >> > file would be helpful (Russell Teabeault) >> > * Change: Scala Specs upgraded to 1.6.9 if using Scala 2.9.1 >> > * Change: Scala 2.9.1 is now default >> > * Change: Make it possible to parameterize the JDepend extension and >> > control the >> > projects that are included in the analysis and to enable support >> > for >> > loading a per project jdepend.properties. >> > * Change: Parameterize the the directory where the top level cobertura >> > tasks will generate >> > reports. Specify using Buildr::Cobertura.report_dir = '' >> > * Change: Stop pretty printing the Intellij IDEA project files to avoid >> > IDEA breaking >> > in the presence of non-normalized whitespace content. >> > * Change: Change the Intellij IDEA extension to always rebuild the >> project >> > files. >> > * Change: Upgrade to require atoulme-Antwrap 0.7.2 >> > * Change: Changed the default output directory for Intellij IDEA >> extension >> > to be >> > _(:target, :main, :idea, :classes) from _(:target, :main, :java) >> > and the >> > default test output directory to be _(:target, :test, :idea, >> > :classes) >> > from _(:target, :test, :java) >> > * Change: Upgrade to highline 1.6.2 >> > * Change: Upgrade to jekyll 0.11.0, jekylltask 1.1.0, RedCl
Re: Experiences with transitive dependencies in buildr
On Fri, Dec 30, 2011 at 11:00 AM, Michael Guymon wrote: > Yeah, did not even think of that. That makes a good argument for using a dsl > with the lock file, something along the lines of: I still really like the idea of a yml file because it is much easier to process in other programs. At one stage I was managing the dependencies externally and I have also played around with patching the yml file to achieve something similar to what the gump project used to do. I am not sure if this functionality would no longer be required if buildr had better dependency management. -- Cheers, Peter Donald
Re: Releasing 1.4.7 -- was: [VOTE] Buildr 1.4.7 RC1
On Thu, Feb 9, 2012 at 3:07 AM, Alex Boisvert wrote: > If you don't mind, I'll take up the release and get started this week. > We're far into overdue territory :) I just fixed a few issues with some addons I added so it may be a good idea to take trunk when doing the release :) -- Cheers, Peter Donald
Re: Time between releases
Hi, On Tue, May 15, 2012 at 6:53 AM, Russ Teabeault wrote: > I thought I had already sent this to the dev group but I don't see it in > the archives. So here it goes: > > I really like buildr and the sanity it has brought from using it to replace > maven. I would like to see it grow and prosper. One complaint I have is > how infrequent the releases are. It has been nearly a year since the last > minor patch release and over 5 months since the pre release of the next > minor patch release. It seems that if there are one or more bug fixes in > place then a minor patch release could be done every couple of weeks, every > week or even every couple of days. I think this is important to the long > term adoption and health of the project. I don't want to have to build and > host my own version of the gem while waiting months for an official > release. Now I understand that the maintainers have lives but doing a > release should be quick and simple, especially if it is a patch release. > > So, is there a good reason that buildr can't be released more often? I don't believe so. Nothing other than someone stepping up to do the release I think. So what needs to be done for the release? Do we have it documented somewhere? Is it as simple as getting the tests passing and pushing out changes to rubygems? -- Cheers, Peter Donald
Re: Time between releases
Hi, Okay so the next question, what versions of ruby do we plan on testing atm? I have run the tests on different ruby versions and at least some versions (i.e. 1.9.2) seem to have a lot of failing tests. My preference would be to aim for supporting/blessing * jruby-1.6.7 * ruby-1.9.2-p320 * ruby-1.8.7-p358 Thoughts? On Tue, May 15, 2012 at 9:57 AM, Alex Boisvert wrote: > On Mon, May 14, 2012 at 4:38 PM, Peter Donald wrote: > >> Hi, >> >> On Tue, May 15, 2012 at 6:53 AM, Russ Teabeault >> wrote: >> > I thought I had already sent this to the dev group but I don't see it in >> > the archives. So here it goes: >> > >> > I really like buildr and the sanity it has brought from using it to >> replace >> > maven. I would like to see it grow and prosper. One complaint I have is >> > how infrequent the releases are. It has been nearly a year since the >> last >> > minor patch release and over 5 months since the pre release of the next >> > minor patch release. It seems that if there are one or more bug fixes in >> > place then a minor patch release could be done every couple of weeks, >> every >> > week or even every couple of days. I think this is important to the long >> > term adoption and health of the project. I don't want to have to build >> and >> > host my own version of the gem while waiting months for an official >> > release. Now I understand that the maintainers have lives but doing a >> > release should be quick and simple, especially if it is a patch release. >> > >> > So, is there a good reason that buildr can't be released more often? >> >> I don't believe so. Nothing other than someone stepping up to do the >> release I think. >> >> So what needs to be done for the release? Do we have it documented >> somewhere? Is it as simple as getting the tests passing and pushing >> out changes to rubygems? >> > > The process is documented here: > https://cwiki.apache.org/confluence/display/BUILDR/Release+process > (could use some minor updating on specifics but the overall process is > still valid) > > The most challenging for me in the past was getting to a local setup where > all the tests passed on all platforms. Things have improved a bit with > bundler but I find it's still a bit challenging. > > alex -- Cheers, Peter Donald
Fwd: Time between releases
On Wed, May 16, 2012 at 4:27 AM, Alex Boisvert wrote: >> I am a big fan of buildr and I really want to see it thrive. I am willing >> to volunteer my time to help do whatever is needed to get buildr to that >> level of simplicity when releasing. > > Great! Please try the rake scripts for staging/releasing and send back any > suggestions/improvements you have. I would be thrilled to get back to a > simpler/fully-automated release process. (I've done most of the recent > releases and they have been too time-consuming). I also see a failures in our test suite if you want to have a bash at fixing them. Here are the results for a recent test run. http://dl.dropbox.com/u/27649951/Buildr/RSpec_1.8.7_results.html http://dl.dropbox.com/u/27649951/Buildr/RSpec_1.9.2_results.html Unfortunately I have just got called up for jury duty so I am going to be slow at getting the release out. But the plan is to have a bash at it immediately after and the failures need to be addressed before then. -- Cheers, Peter Donald -- Cheers, Peter Donald
Re: Time between releases
Hi, So I have done a little bit of work over the weekend to get Buildr built and passing all tests on OSX/Linux and ruby versions 1.9.2-p320, jruby-1.6.7 and 1.8.7-p358. So the only things I need to do for a release is make sure I can rsync things to apache infrastructure and get rubyforge account access and then start a vote? Alternatively if anyone else who already has it all setup feel free to go for it ;) Also ... I have started down the path of using RVM and plan on using veewee/vagrant/virtualbox to try and test the windows versions when I get around to it. -- Cheers, Peter Donald
Re: Time between releases
On Mon, May 21, 2012 at 12:34 AM, Russ Teabeault wrote: > I was going to take a look at using RVM as well. It should be possible to > run the tests for each supported ruby by using 'rvm exec'. > > You could do something like > > rvm 1.9.2-p320,1.8.7-p358,jruby-1.6.7 exec rake spec I think we had to go a bit further but the same sort of idea. I think the code does something like [[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"; rm Gemfile.lock; rvm 1.9.2-p320 exec rake bundle install; rvm 1.9.2-p320 exec rake bundle exec spec -- Cheers, Peter Donald
Re: Time between releases
On Wed, May 23, 2012 at 3:11 AM, Vincent Tencé wrote: > Now to my question. While migrating this maven project, I've noticed that > Buildr can't handle POM properties that depend on other POM properties > properties (in my case in hamcrest-1.3.RC2). Fortunately somebody already > submitted a patch with test cases: > > https://issues.apache.org/jira/browse/BUILDR-618 > > I'd like to know if you guys have plans for included this patch in this > release or in another pretty soon. Fix applied - easily done given it had associated tests ;) -- Cheers, Peter Donald
Re: Buildr 1.4.7 release candidate #1
fy using Buildr::Cobertura.report_dir = '' >> * Change: Stop pretty printing the Intellij IDEA project files to avoid >> IDEA breaking >> in the presence of non-normalized whitespace content. >> * Change: Change the Intellij IDEA extension to always rebuild the >> project files. >> * Change: Upgrade to require atoulme-Antwrap 0.7.2 >> * Change: Changed the default output directory for Intellij IDEA >> extension to be >> _(:target, :main, :idea, :classes) from _(:target, :main, >> :java) and the >> default test output directory to be _(:target, :test, :idea, >> :classes) >> from _(:target, :test, :java) >> * Change: Upgrade to highline 1.6.2 >> * Change: Upgrade to jekyll 0.11.0, jekylltask 1.1.0, RedCloth 4.2.7, >> rdoc 3.8 for >> generating documentation >> * Change: Upgrade to require rubygems > 1.8.6 >> * Change: BUILDR-603 Remove install/uninstall actions from :gem >> packaging type >> * Change: BUILDR-602 Fail the build when gem dependencies are missing >> rather than >> attempting to install the dependencies >> * Change: BUILDR-601 Remove Buildr::Util::Gems >> * Change: BUILDR-600 Centralize the common ad internal requires into one >> location. >> * Change: Upgrade to JRuby 1.6.2 >> * Change: Move to Bundler to manage the project dependencies >> * Change: BUILDR-548 Remove support for JTestR as it is no longer >> maintained (Antoine Toulme) >> * Change: BUILDR-614 Buildr development - Using rvm, bundler and OSX >> installs the wrong rjb (Russell Teabeault) >> * Change: Upgrade to RJB 1.3.7 >> * Fixed: ArtifactNamespace fails when using artifacts with classfier. >> * Fixed: Buildr.artifacts() should handle any object with :to_spec >> method >> (i.e., any object that ActsAsArtifact) >> * Fixed: Handle HTTP Unauthorized (501) result code when downloading >> artifacts. >> * Fixed: BUILDR-611 Buildr should not unnecessarily recompile Java files >> explicitly added to compile.from >> * Fixed: scaladoc generation with scala 2.9.x >> * Fixed: Bnd Plugin: Add each artifact individually as a prerequisite to >> bundle / package task when passed to classpath_element method >> * Fixed: BUILDR-439 "The command line is too long" when running TestNG >> tests (Tammo Van Lessen) >> * Fixed: BUILDR-595 Add option to specifiy location of ca cert >> * Fixed: BUILDR-596 Update installation notes to talk about the >> all-in-one bundle >> >> -- Cheers, Peter Donald
Re: Buildr 1.4.7 release candidate #1
On Mon, May 28, 2012 at 1:22 PM, Alex Boisvert wrote: > I've tested on Linux (Ubuntu 12.04) both CRuby 1.8.7 and JRuby 1.6.7 and > Windows 7. The only problem I've faced is compiling RJB on Windows due to > https://github.com/arton/rjb/issues/7 so I'm tempted to upgrade to RJB > 1.4.0 for the release. Any objections? Go for it. -- Cheers, Peter Donald
Re: [VOTE] Buildr 1.4.7 release
generating documentation > * Change: Upgrade to require rubygems > 1.8.6 > * Change: BUILDR-603 Remove install/uninstall actions from :gem packaging > type > * Change: BUILDR-602 Fail the build when gem dependencies are missing > rather than > attempting to install the dependencies > * Change: BUILDR-601 Remove Buildr::Util::Gems > * Change: BUILDR-600 Centralize the common ad internal requires into one > location. > * Change: Upgrade to JRuby 1.6.2 > * Change: Move to Bundler to manage the project dependencies > * Change: BUILDR-548 Remove support for JTestR as it is no longer > maintained (Antoine Toulme) > * Change: BUILDR-614 Buildr development - Using rvm, bundler and OSX > installs the wrong rjb (Russell Teabeault) > * Change: Upgrade to RJB 1.4.0 > * Fixed: ArtifactNamespace fails when using artifacts with classfier. > * Fixed: Buildr.artifacts() should handle any object with :to_spec method > (i.e., any object that ActsAsArtifact) > * Fixed: Handle HTTP Unauthorized (501) result code when downloading > artifacts. > * Fixed: BUILDR-611 Buildr should not unnecessarily recompile Java files > explicitly added to compile.from > * Fixed: scaladoc generation with scala 2.9.x > * Fixed: Bnd Plugin: Add each artifact individually as a prerequisite to > bundle / package task when passed to classpath_element method > * Fixed: BUILDR-439 "The command line is too long" when running TestNG > tests (Tammo Van Lessen) > * Fixed: BUILDR-595 Add option to specifiy location of ca cert > * Fixed: BUILDR-596 Update installation notes to talk about the > all-in-one bundle -- Cheers, Peter Donald
Re: svn commit: r1343392 - in /buildr/trunk: CHANGELOG buildr.gemspec
Hi,
I have yet to look into it but it seems like the RJB upgrade has
caused tests to start to fail (at least o OSX). eg.
peter-donalds-macbook-pro:buildr peter$ bundle exec rspec spec/java/pom_spec.rb
.F
Failures:
1) Buildr::POM should respect exclusions when computing transitive
dependencies when the pom includes properties
Failure/Error: pom.properties.should eql(specs)
expected: {"a.version"=>"1.1", "b.version"=>"1.1",
"project.groupId"=>"group", "pom.groupId"=>"group",
"groupId"=>"group", "project.artifactId"=>"app",
"pom.artifactId"=>"app", "artifactId"=>"app"}
got: {"a.version"=>"[\"1.1\"]", "b.version"=>"1.1",
"project.groupId"=>"group", "pom.groupId"=>"group",
"groupId"=>"group", "project.artifactId"=>"app",
"pom.artifactId"=>"app", "artifactId"=>"app"}
(compared using eql?)
Diff:
@@ -1,4 +1,4 @@
-"a.version" => "1.1",
+"a.version" => "[\"1.1\"]",
"artifactId" => "app",
"b.version" => "1.1",
"groupId" => "group",
# ./spec/java/pom_spec.rb:123:in `block (2 levels) in '
Finished in 2.35 seconds
2 examples, 1 failure
Failed examples:
rspec ./spec/java/pom_spec.rb:120 # Buildr::POM should respect
exclusions when computing transitive dependencies when the pom
includes properties
On Tue, May 29, 2012 at 7:15 AM, wrote:
> Author: boisvert
> Date: Mon May 28 21:15:38 2012
> New Revision: 1343392
>
> URL: http://svn.apache.org/viewvc?rev=1343392&view=rev
> Log:
> Upgrade to jekyll 0.11.2 (fix @substitutions@)
> Upgrade to RJB 1.4.0 (avoid compile issue on Windows)
>
> Modified:
> buildr/trunk/CHANGELOG
> buildr/trunk/buildr.gemspec
>
> Modified: buildr/trunk/CHANGELOG
> URL:
> http://svn.apache.org/viewvc/buildr/trunk/CHANGELOG?rev=1343392&r1=1343391&r2=1343392&view=diff
> ==
> --- buildr/trunk/CHANGELOG (original)
> +++ buildr/trunk/CHANGELOG Mon May 28 21:15:38 2012
> @@ -65,7 +65,7 @@
> * Change: Move to Bundler to manage the project dependencies
> * Change: BUILDR-548 Remove support for JTestR as it is no longer maintained
> (Antoine Toulme)
> * Change: BUILDR-614 Buildr development - Using rvm, bundler and OSX
> installs the wrong rjb (Russell Teabeault)
> -* Change: Upgrade to RJB 1.3.7
> +* Change: Upgrade to RJB 1.4.0
> * Fixed: ArtifactNamespace fails when using artifacts with classfier.
> * Fixed: Buildr.artifacts() should handle any object with :to_spec method
> (i.e., any object that ActsAsArtifact)
>
> Modified: buildr/trunk/buildr.gemspec
> URL:
> http://svn.apache.org/viewvc/buildr/trunk/buildr.gemspec?rev=1343392&r1=1343391&r2=1343392&view=diff
> ==
> --- buildr/trunk/buildr.gemspec (original)
> +++ buildr/trunk/buildr.gemspec Mon May 28 21:15:38 2012
> @@ -63,7 +63,7 @@ for those one-off tasks, with a language
> spec.add_dependency 'json_pure', '1.4.3'
> spec.add_dependency 'rubyforge', '2.0.3'
> spec.add_dependency 'hoe', '2.3.3'
> - spec.add_dependency 'rjb', '1.3.7' if ($platform.to_s ==
> 'x86-mswin32' || $platform.to_s == 'ruby')
> + spec.add_dependency 'rjb', '1.4.0' if ($platform.to_s ==
> 'x86-mswin32' || $platform.to_s == 'ruby')
> spec.add_dependency 'atoulme-Antwrap', '~> 0.7.2'
> spec.add_dependency 'diff-lcs', '1.1.3'
> spec.add_dependency 'rspec-expectations', '2.9.0'
> @@ -76,7 +76,7 @@ for those one-off tasks, with a language
>
> # The documentation is currently not generated whe building via jruby
> unless $platform.to_s == 'java'
> - spec.add_development_dependency 'jekyll', '0.11.0'
> + spec.add_development_dependency 'jekyll', '0.11.2'
> spec.add_development_dependency 'RedCloth', '4.2.9'
> spec.add_development_dependency 'jekylltask', '1.1.0'
> spec.add_development_dependency 'rdoc', '3.8'
>
>
--
Cheers,
Peter Donald
CI Builds
Hi, So you may have noticed I have spent a week or so intermittently fighting with the CI system. Unfortunately the Linux VMs that the CI runs on are old enough that they cause issues trying to get RVM to work. I have managed to get most of it working. For future reference this involved: * setting LD_LIBRARY_PATH to the packaged libraries in the RVM dir * adding begin/rescue around the doc tasks as the JRuby 1.6.7+ native ffi library links against a newer version of glibc than is on the box. (We in theory could recompile for the old ubuntu but it is easier just to not run using that library and avoid the documentation process under jruby) I believe there is still one intermittent failure (1 in 20 builds?) that I have yet to track down but I will look into it at some point later. So hopefully from now on if you see a build failure it actually means there is a build failure. :) Now I just need to figure out how to get the windows CI stuff working... -- Cheers, Peter Donald
1.4.8 Release?
Hi, So I think we are ready to do a release. The CI is building on both Linux hosts and win32 with 100% success rate and I just ran the tests through OSX locally and there seems to be no problems there either. I vaguely recall there being a document for the process somewhere? Anyone have any reason for us not to kick off the process? -- Cheers, Peter Donald
[VOTE] Buildr 1.4.8 release
We're voting on the source distributions available here: http://people.apache.org/~donaldp/buildr/1.4.8/dist/ Specifically: http://people.apache.org/~donaldp/buildr/1.4.8/dist/buildr-1.4.8.tgz http://people.apache.org/~donaldp/buildr/1.4.8/dist/buildr-1.4.8.zip The documentation generated for this release is available here: http://people.apache.org/~donaldp/buildr/1.4.8/site/ http://people.apache.org/~donaldp/buildr/1.4.8/site/buildr.pdf The following changes were made since 1.4.7: * Change: Revert to importing non-verbose FileUtils utility methods to match buildr 1.4.6 release and earlier. * Added: Experimental support for jacoco code coverage tool. * Fixed: BUILDR-655 - Support JDK1.7 under OSX * Change: Updated dependency versions; - builder (3.1.3) - highline (1.6.15) - rubyforge (2.0.4) - net-ssh (2.6.0) - hoe (3.1.0) - rjb (1.4.2) - rdoc (3.12) - xml-simple (1.1.1) - rspec-expectations (2.11.3) - rspec-mocks (2.11.3) - rspec-core (2.11.1) - rspec (2.11.0) - rubyzip (0.9.9) * Added: BUILDR-652 Generate buildfile from Eclipse workspace. (Niklaus Giger) * Fixed: BUILDR-627 Support explicitly listed source files in buildr cc task. (Christopher Tiwald) * Fixed: BUILDR-606 Transitive artifact resolution should not include artifacts in 'provided' scope in poms to match maven behaviour. (Julio Arias) * Change: BUILDR-640 Enable building jekyll and rdoc under more rubies. (Niklaus Giger) * Change: Mark Buildr:Bnd.remote_repository as deprecated as dependencies appear in maven central. * Added: BUILDR-654 Add the ability to configure the version of BND used by bnd addon. (Niklaus Giger) * Added: Create the git_auto_version addon that automatically specifies a version for a git project based on git describe. * Added: Integrate with Zinc (incremental compilation wrapper for scalac 2.9+) * Change: Default to Scala 2.9.2, ScalaTest 1.8, Scala Specs2 1.11, ScalaCheck 1.10.0. * Change: Scala artifact repository changed to http://oss.sonatype.org/content/repositories/releases * Added: BUILDR-645 Support Mercurial as a version control system (Tan Quach) * Fixed: BUILDR-646 TGZ files do not keep their permissions when extracted via Buildr::Unzip#extract * Added: Add add_exploded_ear_artifact and add_exploded_ejb_artifact to the idea project extension. * Change: Default to using Checkstyle 5.5 in the checkstyle addon. * Fixed: Fix the add_exploded_war_artifact method on the idea project by adding in missing method `partition_dependencies`. * Fixed: Fix the extension of the gwt plugin so that it can be required as an addon. * Fixed: Fix the undefined default_web_xml variable in the add_web_facet method on the idea project. -- Cheers, Peter Donald
Re: [VOTE] Buildr 1.4.8 release
Hi, Okay. Fixed and the fixed version has been re-uploaded to http://people.apache.org/~donaldp/buildr/1.4.8/dist/ It turns out we follow different rules regarding the "verbose" flag than rake. (Essentially we treat it as a tri-state where unset means verbose buildr tasks but non verbose file tasks) On Sun, Oct 28, 2012 at 2:10 AM, Alex Boisvert wrote: > Hi Peter, > > There seems to be a minor issue with output... we're missing task output, > e.g., > > $ buildr _1.4.7_ clean > (in /home/boisvert/tmp/buildr-example, development) > Cleaning buildr-example > Completed in 0.008s > > $ buildr _1.4.8_ clean > (in /home/boisvert/tmp/buildr-example, development) > > $ > > On Sat, Oct 27, 2012 at 3:09 AM, Peter Donald wrote: > >> We're voting on the source distributions available here: >> http://people.apache.org/~donaldp/buildr/1.4.8/dist/ >> >> Specifically: >> http://people.apache.org/~donaldp/buildr/1.4.8/dist/buildr-1.4.8.tgz >> http://people.apache.org/~donaldp/buildr/1.4.8/dist/buildr-1.4.8.zip >> >> The documentation generated for this release is available here: >> http://people.apache.org/~donaldp/buildr/1.4.8/site/ >> http://people.apache.org/~donaldp/buildr/1.4.8/site/buildr.pdf >> >> The following changes were made since 1.4.7: >> >> * Change: Revert to importing non-verbose FileUtils utility methods >> to match buildr 1.4.6 release and earlier. >> * Added: Experimental support for jacoco code coverage tool. >> * Fixed: BUILDR-655 - Support JDK1.7 under OSX >> * Change: Updated dependency versions; >> - builder (3.1.3) >> - highline (1.6.15) >> - rubyforge (2.0.4) >> - net-ssh (2.6.0) >> - hoe (3.1.0) >> - rjb (1.4.2) >> - rdoc (3.12) >> - xml-simple (1.1.1) >> - rspec-expectations (2.11.3) >> - rspec-mocks (2.11.3) >> - rspec-core (2.11.1) >> - rspec (2.11.0) >> - rubyzip (0.9.9) >> * Added: BUILDR-652 Generate buildfile from Eclipse workspace. >> (Niklaus Giger) >> * Fixed: BUILDR-627 Support explicitly listed source files in >> buildr cc task. (Christopher Tiwald) >> * Fixed: BUILDR-606 Transitive artifact resolution should not >> include artifacts in 'provided' scope in poms to >> match maven behaviour. (Julio Arias) >> * Change: BUILDR-640 Enable building jekyll and rdoc under more >> rubies. (Niklaus Giger) >> * Change: Mark Buildr:Bnd.remote_repository as deprecated as >> dependencies appear in maven central. >> * Added: BUILDR-654 Add the ability to configure the version of BND >> used by bnd addon. (Niklaus Giger) >> * Added: Create the git_auto_version addon that automatically >> specifies a version for a git project based >> on git describe. >> * Added: Integrate with Zinc (incremental compilation wrapper for >> scalac 2.9+) >> * Change: Default to Scala 2.9.2, ScalaTest 1.8, Scala Specs2 1.11, >> ScalaCheck 1.10.0. >> * Change: Scala artifact repository changed to >> http://oss.sonatype.org/content/repositories/releases >> * Added: BUILDR-645 Support Mercurial as a version control system (Tan >> Quach) >> * Fixed: BUILDR-646 TGZ files do not keep their permissions when >> extracted >> via Buildr::Unzip#extract >> * Added: Add add_exploded_ear_artifact and >> add_exploded_ejb_artifact to the idea project extension. >> * Change: Default to using Checkstyle 5.5 in the checkstyle addon. >> * Fixed: Fix the add_exploded_war_artifact method on the idea >> project by adding in missing method >> `partition_dependencies`. >> * Fixed: Fix the extension of the gwt plugin so that it can be >> required as an addon. >> * Fixed: Fix the undefined default_web_xml variable in the >> add_web_facet method on the idea project. >> >> -- >> Cheers, >> >> Peter Donald >> -- Cheers, Peter Donald
Re: [VOTE] Buildr 1.4.8 release
Hi, I can't seem to reproduce either of these under OSX/Linux so I will have a look later today when I get to a widows box. Thanks for the heads up! On Thu, Nov 1, 2012 at 12:42 AM, Tammo van Lessen wrote: > Hi, > > I'm perhaps to late, I haven't seen the thread earlier. I just tried > the new build on win7 and discovered two issues: > > First, the verbosity level for FileUtils seems still odd: > > C:\Users\vanto\dev\buildr-test\multi-java>buildr --version > Buildr 1.4.8 (JRuby 1.6.8) > > C:\Users\vanto\dev\buildr-test\multi-java>buildr clean > (in C:/Users/vanto/dev/buildr-test/multi-java, development) > Cleaning multi-java > rm -rf C:/Users/vanto/dev/buildr-test/multi-java/api/target > rm -rf C:/Users/vanto/dev/buildr-test/multi-java/api/reports > rm -rf C:/Users/vanto/dev/buildr-test/multi-java/api/reports > rm -rf C:/Users/vanto/dev/buildr-test/multi-java/impl/target > rm -rf C:/Users/vanto/dev/buildr-test/multi-java/impl/reports > rm -rf C:/Users/vanto/dev/buildr-test/multi-java/impl/target/test/classes > rm -rf C:/Users/vanto/dev/buildr-test/multi-java/impl/reports/junit > rm -rf C:/Users/vanto/dev/buildr-test/multi-java/target > rm -rf C:/Users/vanto/dev/buildr-test/multi-java/reports > rm -rf C:/Users/vanto/dev/buildr-test/multi-java/reports > rm -rf reports/junit > Completed in 0.045s > > IMO these commands should not be logged. > > Second, when I run buildr in an empty directory, the prompt to create > a new buildfile has some issues: > > C:\Users\vanto\dev\buildr-talk>buildr > Ignored > > when I then hit enter, Buildr appends the following line: > Ambiguous choice. Please choose one of ["1", "2", "3", "From eclipse > .project files", "From directory structure", "Cancel"]. > > I'm testing with jruby 1.6.8 (ruby-1.8.7-p357) (2012-09-18 1772b40) > (Java HotSpot(TM) Client VM 1.7.0_03) [Windows 7-x86-java] > > I didn't find the time to look into these issues, perhaps you have some ideas? > > Thanks, > Tammo > > On Mon, Oct 29, 2012 at 6:03 AM, Alex Boisvert > wrote: >> Confirmed fixed. Tested on Linux (Ubuntu 12.04) and OSX 10.6 (Snow >> Leopard). >> >> +1 for release. >> >> alex >> >> On Sat, Oct 27, 2012 at 2:52 PM, Peter Donald wrote: >> >>> Hi, >>> >>> Okay. Fixed and the fixed version has been re-uploaded to >>> http://people.apache.org/~donaldp/buildr/1.4.8/dist/ >>> >>> It turns out we follow different rules regarding the "verbose" flag >>> than rake. (Essentially we treat it as a tri-state where unset means >>> verbose buildr tasks but non verbose file tasks) >>> >>> On Sun, Oct 28, 2012 at 2:10 AM, Alex Boisvert >>> wrote: >>> > Hi Peter, >>> > >>> > There seems to be a minor issue with output... we're missing task output, >>> > e.g., >>> > >>> > $ buildr _1.4.7_ clean >>> > (in /home/boisvert/tmp/buildr-example, development) >>> > Cleaning buildr-example >>> > Completed in 0.008s >>> > >>> > $ buildr _1.4.8_ clean >>> > (in /home/boisvert/tmp/buildr-example, development) >>> > >>> > $ >>> > >>> > On Sat, Oct 27, 2012 at 3:09 AM, Peter Donald >> >wrote: >>> > >>> >> We're voting on the source distributions available here: >>> >> http://people.apache.org/~donaldp/buildr/1.4.8/dist/ >>> >> >>> >> Specifically: >>> >> http://people.apache.org/~donaldp/buildr/1.4.8/dist/buildr-1.4.8.tgz >>> >> http://people.apache.org/~donaldp/buildr/1.4.8/dist/buildr-1.4.8.zip >>> >> >>> >> The documentation generated for this release is available here: >>> >> http://people.apache.org/~donaldp/buildr/1.4.8/site/ >>> >> http://people.apache.org/~donaldp/buildr/1.4.8/site/buildr.pdf >>> >> >>> >> The following changes were made since 1.4.7: >>> >> >>> >> * Change: Revert to importing non-verbose FileUtils utility methods >>> >> to match buildr 1.4.6 release and earlier. >>> >> * Added: Experimental support for jacoco code coverage tool. >>> >> * Fixed: BUILDR-655 - Support JDK1.7 under OSX >>> >> * Change: Updated dependency versions; >>> >> - builder (3.1.3) >>> >> - highline (1.6.15) >>> >> - rubyforge (2.0.4) >>>
Re: [VOTE] Buildr 1.4.8 release
Hi, I identified and fixed the problems that you reported. Both are unfortunately in some of our dependencies. I have fixed the problems are re-uploaded the release proposal. If you could try the current version at [1] to verify the fixes, it would be much appreciated. [1] http://people.apache.org/~donaldp/buildr/1.4.8/dist/ Thanks! Peter Donald On Thu, Nov 1, 2012 at 12:42 AM, Tammo van Lessen wrote: > Hi, > > I'm perhaps to late, I haven't seen the thread earlier. I just tried > the new build on win7 and discovered two issues: > > First, the verbosity level for FileUtils seems still odd: > > C:\Users\vanto\dev\buildr-test\multi-java>buildr --version > Buildr 1.4.8 (JRuby 1.6.8) > > C:\Users\vanto\dev\buildr-test\multi-java>buildr clean > (in C:/Users/vanto/dev/buildr-test/multi-java, development) > Cleaning multi-java > rm -rf C:/Users/vanto/dev/buildr-test/multi-java/api/target > rm -rf C:/Users/vanto/dev/buildr-test/multi-java/api/reports > rm -rf C:/Users/vanto/dev/buildr-test/multi-java/api/reports > rm -rf C:/Users/vanto/dev/buildr-test/multi-java/impl/target > rm -rf C:/Users/vanto/dev/buildr-test/multi-java/impl/reports > rm -rf C:/Users/vanto/dev/buildr-test/multi-java/impl/target/test/classes > rm -rf C:/Users/vanto/dev/buildr-test/multi-java/impl/reports/junit > rm -rf C:/Users/vanto/dev/buildr-test/multi-java/target > rm -rf C:/Users/vanto/dev/buildr-test/multi-java/reports > rm -rf C:/Users/vanto/dev/buildr-test/multi-java/reports > rm -rf reports/junit > Completed in 0.045s > > IMO these commands should not be logged. > > Second, when I run buildr in an empty directory, the prompt to create > a new buildfile has some issues: > > C:\Users\vanto\dev\buildr-talk>buildr > Ignored > > when I then hit enter, Buildr appends the following line: > Ambiguous choice. Please choose one of ["1", "2", "3", "From eclipse > .project files", "From directory structure", "Cancel"]. > > I'm testing with jruby 1.6.8 (ruby-1.8.7-p357) (2012-09-18 1772b40) > (Java HotSpot(TM) Client VM 1.7.0_03) [Windows 7-x86-java] > > I didn't find the time to look into these issues, perhaps you have some > ideas? > > Thanks, > Tammo > >
Re: [VOTE] Buildr 1.4.8 release
Hi, It looks like the easiest option is to downgrade the library across the board until we can fix it on windows. So I have made the change and re-upped the release. On Thu, Nov 1, 2012 at 11:17 PM, Tammo van Lessen wrote: > Hi Peter, > > thanks for fixing it. While the verbose fileutils output is gone now, > the buildr gem is still fetching, installing and requiring the *.15 > version of highline under JRuby and thus still does not work as > expected. This is because $platform is 'java' on JRuby on Win7. > Perhaps you could use something like the following instead. > > require 'rbconfig' > /mswin|mingw/.match RbConfig::CONFIG['host_os'] > > I didn't provide a patch for that because I'm not entirely sure where > this information should be used as well (there are other deps to be > only included on windows, but I'm not sure if they would work with > JRuby). > > Thanks, > Tammo > > > On Thu, Nov 1, 2012 at 9:53 AM, Peter Donald > wrote: > > Hi, > > > > I identified and fixed the problems that you reported. Both are > > unfortunately in some of our dependencies. I have fixed the problems are > > re-uploaded the release proposal. If you could try the current version at > > [1] to verify the fixes, it would be much appreciated. > > > > [1] http://people.apache.org/~donaldp/buildr/1.4.8/dist/ > > > > Thanks! > > > > Peter Donald > > > > > > On Thu, Nov 1, 2012 at 12:42 AM, Tammo van Lessen >wrote: > > > >> Hi, > >> > >> I'm perhaps to late, I haven't seen the thread earlier. I just tried > >> the new build on win7 and discovered two issues: > >> > >> First, the verbosity level for FileUtils seems still odd: > >> > >> C:\Users\vanto\dev\buildr-test\multi-java>buildr --version > >> Buildr 1.4.8 (JRuby 1.6.8) > >> > >> C:\Users\vanto\dev\buildr-test\multi-java>buildr clean > >> (in C:/Users/vanto/dev/buildr-test/multi-java, development) > >> Cleaning multi-java > >> rm -rf C:/Users/vanto/dev/buildr-test/multi-java/api/target > >> rm -rf C:/Users/vanto/dev/buildr-test/multi-java/api/reports > >> rm -rf C:/Users/vanto/dev/buildr-test/multi-java/api/reports > >> rm -rf C:/Users/vanto/dev/buildr-test/multi-java/impl/target > >> rm -rf C:/Users/vanto/dev/buildr-test/multi-java/impl/reports > >> rm -rf > C:/Users/vanto/dev/buildr-test/multi-java/impl/target/test/classes > >> rm -rf C:/Users/vanto/dev/buildr-test/multi-java/impl/reports/junit > >> rm -rf C:/Users/vanto/dev/buildr-test/multi-java/target > >> rm -rf C:/Users/vanto/dev/buildr-test/multi-java/reports > >> rm -rf C:/Users/vanto/dev/buildr-test/multi-java/reports > >> rm -rf reports/junit > >> Completed in 0.045s > >> > >> IMO these commands should not be logged. > >> > >> Second, when I run buildr in an empty directory, the prompt to create > >> a new buildfile has some issues: > >> > >> C:\Users\vanto\dev\buildr-talk>buildr > >> Ignored > >> > >> when I then hit enter, Buildr appends the following line: > >> Ambiguous choice. Please choose one of ["1", "2", "3", "From eclipse > >> .project files", "From directory structure", "Cancel"]. > >> > >> I'm testing with jruby 1.6.8 (ruby-1.8.7-p357) (2012-09-18 1772b40) > >> (Java HotSpot(TM) Client VM 1.7.0_03) [Windows 7-x86-java] > >> > >> I didn't find the time to look into these issues, perhaps you have some > >> ideas? > >> > >> Thanks, > >> Tammo > >> > >> > > > > -- > Tammo van Lessen - http://www.taval.de > -- Cheers, Peter Donald
Re: [VOTE] Buildr 1.4.8 release
The vote passed with 4 +1's (3 binding) and no -1. Pushing the release to the mirrors ... On Sat, Nov 3, 2012 at 11:14 AM, Antoine Toulme wrote: > Here is my +1 (binding). Thanks for the hard work Peter! > > On Thu, Nov 1, 2012 at 6:13 AM, Tammo van Lessen >wrote: > > > Hi, > > > > awesome, this works like a charm. Thanks for fixing! > > > > I also noticed that > > http://people.apache.org/~donaldp/buildr/1.4.8/site/ does not include > > the updated changelog. > > > > Looking forward to the new release, a (non-binding) +1 from me. > > > > Thanks for your work! > > Tammo > > > > On Thu, Nov 1, 2012 at 1:34 PM, Peter Donald > > wrote: > > > Hi, > > > > > > It looks like the easiest option is to downgrade the library across the > > > board until we can fix it on windows. So I have made the change and > > > re-upped the release. > > > > > > > > > > > > On Thu, Nov 1, 2012 at 11:17 PM, Tammo van Lessen < > tvanles...@gmail.com > > >wrote: > > > > > >> Hi Peter, > > >> > > >> thanks for fixing it. While the verbose fileutils output is gone now, > > >> the buildr gem is still fetching, installing and requiring the *.15 > > >> version of highline under JRuby and thus still does not work as > > >> expected. This is because $platform is 'java' on JRuby on Win7. > > >> Perhaps you could use something like the following instead. > > >> > > >> require 'rbconfig' > > >> /mswin|mingw/.match RbConfig::CONFIG['host_os'] > > >> > > >> I didn't provide a patch for that because I'm not entirely sure where > > >> this information should be used as well (there are other deps to be > > >> only included on windows, but I'm not sure if they would work with > > >> JRuby). > > >> > > >> Thanks, > > >> Tammo > > >> > > >> > > >> On Thu, Nov 1, 2012 at 9:53 AM, Peter Donald > > >> wrote: > > >> > Hi, > > >> > > > >> > I identified and fixed the problems that you reported. Both are > > >> > unfortunately in some of our dependencies. I have fixed the problems > > are > > >> > re-uploaded the release proposal. If you could try the current > > version at > > >> > [1] to verify the fixes, it would be much appreciated. > > >> > > > >> > [1] http://people.apache.org/~donaldp/buildr/1.4.8/dist/ > > >> > > > >> > Thanks! > > >> > > > >> > Peter Donald > > >> > > > >> > > > >> > On Thu, Nov 1, 2012 at 12:42 AM, Tammo van Lessen < > > tvanles...@gmail.com > > >> >wrote: > > >> > > > >> >> Hi, > > >> >> > > >> >> I'm perhaps to late, I haven't seen the thread earlier. I just > tried > > >> >> the new build on win7 and discovered two issues: > > >> >> > > >> >> First, the verbosity level for FileUtils seems still odd: > > >> >> > > >> >> C:\Users\vanto\dev\buildr-test\multi-java>buildr --version > > >> >> Buildr 1.4.8 (JRuby 1.6.8) > > >> >> > > >> >> C:\Users\vanto\dev\buildr-test\multi-java>buildr clean > > >> >> (in C:/Users/vanto/dev/buildr-test/multi-java, development) > > >> >> Cleaning multi-java > > >> >> rm -rf C:/Users/vanto/dev/buildr-test/multi-java/api/target > > >> >> rm -rf C:/Users/vanto/dev/buildr-test/multi-java/api/reports > > >> >> rm -rf C:/Users/vanto/dev/buildr-test/multi-java/api/reports > > >> >> rm -rf C:/Users/vanto/dev/buildr-test/multi-java/impl/target > > >> >> rm -rf C:/Users/vanto/dev/buildr-test/multi-java/impl/reports > > >> >> rm -rf > > >> C:/Users/vanto/dev/buildr-test/multi-java/impl/target/test/classes > > >> >> rm -rf C:/Users/vanto/dev/buildr-test/multi-java/impl/reports/junit > > >> >> rm -rf C:/Users/vanto/dev/buildr-test/multi-java/target > > >> >> rm -rf C:/Users/vanto/dev/buildr-test/multi-java/reports > > >> >> rm -rf C:/Users/vanto/dev/buildr-test/multi-java/reports > > >> >> rm -rf reports/junit > > >> >> Completed in 0.045s > > >> >> > > >> >> IMO these commands should not be logged. > > >> >> > > >> >> Second, when I run buildr in an empty directory, the prompt to > create > > >> >> a new buildfile has some issues: > > >> >> > > >> >> C:\Users\vanto\dev\buildr-talk>buildr > > >> >> Ignored > > >> >> > > >> >> when I then hit enter, Buildr appends the following line: > > >> >> Ambiguous choice. Please choose one of ["1", "2", "3", "From > eclipse > > >> >> .project files", "From directory structure", "Cancel"]. > > >> >> > > >> >> I'm testing with jruby 1.6.8 (ruby-1.8.7-p357) (2012-09-18 1772b40) > > >> >> (Java HotSpot(TM) Client VM 1.7.0_03) [Windows 7-x86-java] > > >> >> > > >> >> I didn't find the time to look into these issues, perhaps you have > > some > > >> >> ideas? > > >> >> > > >> >> Thanks, > > >> >> Tammo > > >> >> > > >> >> > > >> > > >> > > >> > > >> -- > > >> Tammo van Lessen - http://www.taval.de > > >> > > > > > > > > > > > > -- > > > Cheers, > > > > > > Peter Donald > > > > > > > > -- > > Tammo van Lessen - http://www.taval.de > > > -- Cheers, Peter Donald
Re: svn commit: r1406490 - /buildr/trunk/rakelib/doc.rake
Hi, On Thu, Nov 8, 2012 at 6:28 AM, Alex Boisvert wrote: > Just wondering the reason behind removing the partial publish task ... it's > been useful in the past to make website updates (e.g. update installation > instructions) between releases. In hindsight it is a mistake. I did't release we still had release specific documentation on our website and thought it had been reduced to just HTML+PDF so I removed the task. However I have just reverted that change now that I realize/you pointed out we still have rdocs going up. -- Cheers, Peter Donald
[VOTE] Buildr 1.4.9 release
It looks like there was an intermittent bug that bit some people in the last release so I thought I would start the release process for a new release with the required fix. We're voting on the source distributions available here: http://people.apache.org/~donaldp/buildr/1.4.9/dist/ Specifically: http://people.apache.org/~donaldp/buildr/1.4.9/dist/buildr-1.4.9.tgz http://people.apache.org/~donaldp/buildr/1.4.9/dist/buildr-1.4.9.zip The documentation generated for this release is available here: http://people.apache.org/~donaldp/buildr/1.4.9/site/ http://people.apache.org/~donaldp/buildr/1.4.9/site/buildr.pdf The following changes were made since 1.4.8: * Fixed: Fixed the interaction with the FileUtils classes. The last release introduced a non-deterministic bug that sometimes caused logging preferences to be ignored and the install method to be inadvertently overwritten.
Re: [VOTE] Buildr 1.4.9 release
Hi, I actually found it quite hard to reproduce. It seems to depend on the order in which the gems are installed and I seemed to be able to reproduce it by random touch commands in gem directory. However, a symptom is present on non windows boxes if you do something like $ cat > buildfile task "X" do rm_rf "" end ^D $ buildr X and you see a line like "rm -rf XX" then there may be an issue. I also observed that some times there was also problems with "buildr install" on windows boxes. (You would receive a ArgumentError for calling the install method). On Fri, Nov 9, 2012 at 3:03 AM, Alex Boisvert wrote: > Hi Peter, > > How does one go about testing/replicating the issue that was fixed? Just > wondering if I can help confirm that it was fixed. > > alex > > On Thursday, November 8, 2012, Peter Donald wrote: > >> It looks like there was an intermittent bug that bit some people in the >> last >> release so I thought I would start the release process for a new release >> with the required fix. >> >> We're voting on the source distributions available here: >> http://people.apache.org/~donaldp/buildr/1.4.9/dist/ >> >> Specifically: >> http://people.apache.org/~donaldp/buildr/1.4.9/dist/buildr-1.4.9.tgz >> http://people.apache.org/~donaldp/buildr/1.4.9/dist/buildr-1.4.9.zip >> >> The documentation generated for this release is available here: >> http://people.apache.org/~donaldp/buildr/1.4.9/site/ >> http://people.apache.org/~donaldp/buildr/1.4.9/site/buildr.pdf >> >> The following changes were made since 1.4.8: >> >> * Fixed: Fixed the interaction with the FileUtils classes. The last >> release >> introduced a non-deterministic bug that sometimes caused >> logging >> preferences to be ignored and the install method to be >> inadvertently overwritten. >> -- Cheers, Peter Donald
Re: [VOTE] Buildr 1.4.9 release
The vote passed with 3 +1's (3 binding) and no -1. Pushing the release to the mirrors ... -- Cheers, Peter Donald
Re: ApacheCon / Thoughtworks TechRadar
Huya, On Sat, Nov 10, 2012 at 5:21 AM, Tammo van Lessen wrote: > First, I got a Buildr talk accepted at ApacheCon EU in Sinsheim, Germany, > which I held just yesterday. congrats! > I got a lot of positive feedback, people seem > to like the buildr idea although it also seems that Maven improved since > the inception of Buildr and some things are less worse. The most visible > argument against buildr was, however, that people are used to use Maven and > that, if they want to make their project accessible for a broad audience, > they think they'd need to stick to Maven. That does seem to be a common view. > I guess Gradle tries to address > this issue by providing a "gradle-wrapper", which is a small jar file along > a shell script that you can include into your project and that will > bootstrap a gradle installation automatically. I also figured, that still > many Java developers don't have rubies at hand and don't know how to easily > install a gem. And one stage, Antoine was working on the "all-in-one" distribution that essentially bundled a version of jruby with buildr and all it's dependencies in one easy installer. I wonder if we could work on this to ease adoption of buildr for the casual user. Where I work we use Chef (http://www.opscode.com/chef/) extensively and they release their tool in "omnibus" editions that are essentially a complete version of ruby for n-different platforms. They preinstall the chef gems in the ruby they distribute but they make sure that the only things that are added to the path are the che executables. I wonder if this would be a good thing for us to consider? > Second, I stumbled upon ThoughtWorks TechRadar [2]. In particular, I liked > the first paragraph of the Tools section ;) It is kinda neat. Possibly the best thing we can do is to increase awareness ... I think your approach to giving a talk is a good idea. -- Cheers, Peter Donald
Moving _(:target, :generated) to top level of project
Hi,
So I have been looking at a bunch of different projects (mostly
commercial) and how they use buildr. One thing I noticed is that a
large proportion of them move _(:target, :generated) to the top level
of the project. So a typical project may look like;
layout = Layout::Default.new
layout[:target, :generated] = "generated"
define "myproject", :layout => layout do
...
project.clean { rm_rf _(:target, :generated) }
end
The main reason for this seems to be ease of integration into IDEs.
I only really use IntelliJs IDEA but I know that at least for that IDE
we exclude the intermediate directory (i.e. _(:target) ) from the
project and this makes it impossible to view the generated source in
the IDE. So to enable development in the IDE they move it out of the
target hierarchy.
* Do you think we should make this the default?
* Alternatively, should we create an addon that makes this the
"default" behaviour?
--
Cheers,
Peter Donald
Add tasks to attach generation tasks to?
Hi, Another thing I noticed across a whole bunch of projects is that they usually create a per project task off which they can hang all the code generation tasks off. i.e. They add a task like "myproject:generate" that does all the source generation required for the project. Mostly this is so they can generate code and then do most of their development out of an IDE. However I notice that when I look at mavens lifecycle at [1] they actually include phases by the names * generate-sources: (Generate the main source code) * generate-resources: (Generate the main resources) * generate-test-sources: (Generate the test source code) * generate-test-resources: (Generate the test resources) I was thinking about trying to incorporate something similar into buildr. What do you think would be the best approach? * Add one "generate" task * Add the maven generate tasks * Add both tasks and have the generate task have all the maven generate taks as dependencies There would then be a process of updating all the addons to use this new approach. Thoughts? [1] http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html -- Cheers, Peter Donald
Release Soon?
Hi, Would it be useful to do a release sometime soon? A few useful bug fixes have gone in, even if there has not been any major changes. I know that the CI jobs are intermittently failing, but I think that is mostly todo with problems on the build server rather than with buildr as such. I have run the tests locally and they all seem fine - I will look into the failures in about 10 days and then start a release vote if no one has any objections. -- Cheers, Peter Donald
Re: Release Soon?
Hi, On Thu, Jan 24, 2013 at 8:53 AM, Alex Boisvert wrote: > HA! Looks like our emails crossed. I'm +1 for the release and happy if > you'd like to lead it. > I have nothing I need to add and wont get a chance to even start the release process till 5th or later so feel free to go for it. If you do go ahead then feel free to further refine the release scripts. I think I have got most of the things in place. However if you could also address BUILDR-634 at the same time that would be great ;) -- Cheers, Peter Donald
Re: Release Soon?
Hi, It may also be a good idea to update to rjb 1.4.6 as it has just been released with a few bug fixes that may impact us. See [1] [1] https://github.com/arton/rjb/commit/8168fb3d68fb1c6b0898636bb7018eb30a6c6e69 On Thu, Jan 24, 2013 at 12:26 PM, Alex Boisvert wrote: > Ok, I'll see if I can get started this weekend and tackle BUILDR-634. > > On Wed, Jan 23, 2013 at 2:06 PM, Peter Donald >wrote: > > > Hi, > > > > On Thu, Jan 24, 2013 at 8:53 AM, Alex Boisvert > >wrote: > > > > > HA! Looks like our emails crossed. I'm +1 for the release and happy > if > > > you'd like to lead it. > > > > > > > I have nothing I need to add and wont get a chance to even start the > > release process till 5th or later so feel free to go for it. > > > > If you do go ahead then feel free to further refine the release scripts. > I > > think I have got most of the things in place. However if you could also > > address BUILDR-634 at the same time that would be great ;) > > > > > > -- > > Cheers, > > > > Peter Donald > > > -- Cheers, Peter Donald
[VOTE] Buildr 1.4.10 release
We're voting on the source distributions available here: http://people.apache.org/~donaldp/buildr/1.4.10/dist/ Specifically: http://people.apache.org/~donaldp/buildr/1.4.10/dist/buildr-1.4.10.tgz http://people.apache.org/~donaldp/buildr/1.4.10/dist/buildr-1.4.10.zip The documentation generated for this release is available here: http://people.apache.org/~donaldp/buildr/1.4.10/site/ http://people.apache.org/~donaldp/buildr/1.4.10/site/buildr.pdf The following changes were made since 1.4.9: * Added: Support a single intermediate directory for each project hierarchy through an addon 'buildr/single_intermediate_layout'. * Fixed: BUILDR-660 possible build issue when using build.yaml and tasks/*.rake (Félix Enrique Llorente Pastora) * Added: Support the :dir option in the Java::Commands.java method. * Fixed: Scala 2.10 support - compiler now uses additional/separate jars introduced in 2.10 such as scala-reflect.jar and scala-actor.jar * Added: Add an addon for NSIS. * Change: BUILDR-612 - Support the TestNG 6.x versions and default to 6.8. * Added: BUILDR-599 - Support the passing of arguments to testng test runner. * Fixed: Observer the per-project source version when generating IDEA module files. * Change: Sort the components in IDEA project files in the same order the idea sorts them. * Fixed: Findbugs addon correctly handles String dependencies (vs task dependencies) * Fixed: Checkstyle addon correctly handles String dependencies (vs task dependencies) * Added: Created an addon 'buildr/wsgen' for generating wsdls from java and java from wsdls using the underlying wsgen tool. * Change: Defer the expansion of generated poms by wrapping the generation in a Proc. * Change: Rework Artifact.content(value) method to accept a Proc that will be called before the artifact is written rather than requiring a string. * Added: Create a 'buildr/gpg' addon that signs and uploads signatures when uploading artifacts. Inspired by a similar extension in the Apache ODE project by Tammo van Lessen. * Change: Updated dependency versions; - jruby-openssl (0.8.2) - atoulme-Antwrap (0.7.4) * Change: Require 'bundler/setup' as part of buildr startup to ensure that buildr always runs with up to date dependencies if a Gemfile is present. * Added: Add FrameworkDetectionExcludesConfiguration facet to Idea project file creation by default. * Fixed: In the IntelliJ extension, defer the materialization of the default_components until expansion time to avoid loss of sub- components added after an add_component call. * Fixed: BUILDR-633 - Remove hardcoded shebang lines in all-in-one release. * Added: Create a simple extension that modifies the project layout to place generated files at the top level. -- Cheers, Peter Donald
Re: [VOTE] Buildr 1.4.10 release
Hi, On Tue, Feb 12, 2013 at 6:17 AM, Antoine Toulme wrote: > It looks like the site is missing images ? Oops - it looks like they were there but had bad permissions. Fixed now. -- Cheers, Peter Donald
Re: [VOTE] Buildr 1.4.10 release
Hi, On Sun, Feb 17, 2013 at 3:13 AM, Alex Boisvert wrote: > Here's my +1 for the release (vote on source package). > > However, there's a minor issue on the .gem binaries ... I think the file > permissions are too restrictive which leads to this kind of problem after > install: ...snip... Eep. Fixed up the gems and re-uploaded them again. I will add a check into the rake staging task to verify that this does not happen again. -- Cheers, Peter Donald
Re: [VOTE] Buildr 1.4.10 release
Hi, On Wed, Feb 20, 2013 at 3:47 PM, Antoine Toulme wrote: > +1 for the release, thanks for the hard work! Great. So I have kicked off the start of the release but it looks like we can't update the website through the old mechanisms. So I have started the process of getting it into svnpubsub but it may take a day or two to get fully released.
Re: Migration to Apache CMS & svnpubsub
Hi, We have finally got our site into SvnPubSub so it should be relatively easy to update from now on. On Thu, Dec 13, 2012 at 4:58 AM, Alex Boisvert wrote: > Folks, > > The Apache infrastructure team are phasing out Confluence and rsync-based > website publishing by the end of the year. Related information can be > found at http://www.apache.org/dev/project-site.html. > > Correspondingly, I've created an infrastructure task to migrate our > Confluence content to Apache CMS and setup a SVN area for site publishing: > https://issues.apache.org/jira/browse/INFRA-5632 > > alex -- Cheers, Peter Donald
Re: [VOTE] Buildr 1.4.10 release
Hi, On Thu, Feb 21, 2013 at 9:49 AM, Peter Donald wrote: > On Wed, Feb 20, 2013 at 3:47 PM, Antoine Toulme > wrote: >> +1 for the release, thanks for the hard work! > > Great. So I have kicked off the start of the release but it looks like > we can't update the website through the old mechanisms. So I have > started the process of getting it into svnpubsub but it may take a day > or two to get fully released. So the latest release has finally gone out and the website updated. Unfortunately it was released with a break to the TestNG test infrastructure. Do you think it is doing another quick release to fix this or should be just leave it to accumulate changes until the next release roles round? -- Cheers, Peter Donald
Re: [VOTE] Buildr 1.4.10 release
Hi, On Thu, Mar 14, 2013 at 10:16 AM, Alex Boisvert wrote: > Is there a Jira for the TestNG issue? (Or is it already fixed?) It is already fixed. > I believe it's worth pushing a release to fix a non-trivial regression, yes. Ok. WIll kick start a release over the weekend and try to get the fix out there. If anyone else has time before then - feel free to press the go button. -- Cheers, Peter Donald
[VOTE] Buildr 1.4.11 release
We're voting on the source distributions available here: http://people.apache.org/~donaldp/buildr/1.4.11/dist/ Specifically: http://people.apache.org/~donaldp/buildr/1.4.11/dist/buildr-1.4.11.tgz http://people.apache.org/~donaldp/buildr/1.4.11/dist/buildr-1.4.11.zip The documentation generated for this release is available here: http://people.apache.org/~donaldp/buildr/1.4.11/site/ http://people.apache.org/~donaldp/buildr/1.4.11/site/buildr.pdf The following changes were made since 1.4.10: * Fixed: Multiple tests in TestNG 6.x versions were being incorrectly passed to the command line application. -- Cheers, Peter Donald
TravisCI for Buildr?
Hi, So a couple of days ago I played around with TravisCI. TravisCI for those not familiar is a ci as a service offering that will run tests against github repositories. I have been experimenting withit in my account and you can see a sample (failed) build at [1]. I was curious - what do you think of using this for our Linux builds? I tend to spend a lot of time trying to care and feed Apaches CI infrastructure given how old it is. This would avoid the scenario altogether ... thoughts? Also is any other Apache projects using TravisCI? [1] https://travis-ci.org/realityforge/buildr/builds/6326113 -- Cheers, Peter Donald
Buildr Release?
Hi, I was thinking about starting the ball rolling for a release this weekend. In particular, I would like to see BUILDR-666 released as soon as possible. This has managed to speed up a whole bunch of our builds. Any objections? -- Cheers, Peter Donald
[VOTE] Buildr 1.4.12 release
We're voting on the source distributions available here: http://people.apache.org/~donaldp/buildr/1.4.12/dist/ Specifically: http://people.apache.org/~donaldp/buildr/1.4.12/dist/buildr-1.4.12.tgz http://people.apache.org/~donaldp/buildr/1.4.12/dist/buildr-1.4.12.zip The documentation generated for this release is available here: http://people.apache.org/~donaldp/buildr/1.4.12/site/ http://people.apache.org/~donaldp/buildr/1.4.12/site/buildr.pdf The following changes were made since 1.4.11: * Added: BUILDR-648 Add new package(:test_jar) packaging type. Submitted by Mike Pettypiece. * Fixed: BUILDR-666 ZipFile.open modifies file regardless of usage. Reported by Pepijn Van Eeckhoudt, fix by Alex Boisvert. * Change: Moved to using TravisCI to test the Linux variants. * Added: Make the location of the wsdl in generated source configurable in the wsgen addon. * Added: When generating the GWT facet for Intellij IDEA modules, use the gwt-dev maven artifact dependency if present as the SDK, falling back to the existing behaviour if not possible. * Added: Improved support for auto-detection of VCS dirs when creating IDEA projects. * Added: Added support for SuperDevMode in gwt addon and upgraded to GWT 2.5.1 by default. * Change: BUILDR-664 Update Checkstyle addon so that extra_dependencies is empty by default. Submitted by Dieter Vrancken. * Fixed: BUILDR-663 require 'buildr' fails for Ruby 2.0.0. * Fixed: BUILDR-665 Java artifacts in build.yaml breaking ArchiveTask. Submitted by Antonio Pérez Barrero. * Fixed: BUILDR-662 reported time is much shorter than actual -- Cheers, Peter Donald
Ruby 2.0.0 support
Hi, As we were starting to get some bug reports from Ruby 2.0.0 through I decided that as a first step it was a good idea to go through and try and get the tests passing. They currently seem to run and pass under Ruby 2. I have also added a test run to the TravisCI build to verify the behaviour going forward. However, we don't yet use Ruby 2 in any of our projects so it is quite possible that I have missed some things. If anyone is using Ruby 2 and wants to give the current trunk version a go under that version of ruby and report back any failures then that would be Thanks, Peter Donald
Re: Contributing patches
Hi,
On Wed, Jul 24, 2013 at 9:48 PM, Marius Kjeldahl
wrote:
> I've now successfully added support for Kawa compilation using buildr.
great work.
> I've modelled the code on the existing Scala compilation support, basically
> added a kawa.rb and kawa/compiler.rb, with minor modifications to
> core/{compile,generate,run}.rb . Together with a proper buildfile I am now
> able to compile, package, install and run mixed language programs
> (java+scheme) on Android, although there is no Android specific code in the
> buildr contributions (only in the local buildfile), so it should support
> "generic Kawa" (non-Android) programs as well. I have not yet added support
> for unit testing or doc generation with kawa, but that should be fairly
> easy if needed.
excellent.
> I wouldn't mind contributing this code, but I am somewhat at a loss on how
> to do this. Ideally, I would have forked the public Github repo, but that
> looks stale, so it's obviously not that easy. Considering my kawa support
> is only a few days old, the kawa support should also be considered "alpha"
> quality, and there will probably be frequent fixes in the near future.
It would be awesome to have this contributed and forking the github
repo is an easy way to get it going. A few things to note;
* It looks like the github repo has an incorrect branch marked as the
primary branch. It should be trunk at
https://github.com/apache/buildr/tree/trunk - I will look into seeing
what is needed to get the github repository corrected so it shows the
trunk branch by default.
* the best way to get into core is to add tests for it. The more tests
that are added the more likely it will continue to be supported as
buildr evolves.
* Unfortunately Apache does not support pull requests as a mechanism
for integrating code into buildr. Once you have prepared a branch you
have to attach a patch to a jira issue and tick a box that assigns
copyright to the foundation. However working in a branch in your own
fork is actually fairly useful.
* It is up to you whether you want to incrementally or send a patch
when the support is complete. I would recommend incremental patches as
it is much easier to get feedback in small patches and it may be
easier to make it more consistent with the rest of buildr that way.
> Anyway, I'm not sure if or how I should contribute, or if I should just
> make a Github repo for myself and others (I'm sure there aren't that many
> yet..) containing the modifications.
I am jumping on a plane and heading out bush in a few hours but
hopefully will be back in range next week. I would love to have a look
at it then :)
--
Cheers,
Peter Donald
Re: Dependencies and build order
Hi, I don't use the scala plugin so this may be wrong but looking at the source, it seems that the scala compilers are responsible for compiling the java dependencies as well as the scala code. It seems that the only reason that the scala plugin also runs the javac compiler is to pick up java files that are not transitive dependencies of the scala code. Or thats what it looks like to me ... On Thu, Jul 25, 2013 at 6:14 PM, Marius Kjeldahl wrote: > In the process of adding tests to my kawa module for buildr, I'm struggling > with build order. The scala module that I've modelled my kawa module on > seems to simply build the scala code first, then the java code for mixed > mode compilation. The code can be found in scala/compiler.rb in the method > compile_with_scalac. > > One of the tests that comes with the module then defines a java package > Foo, and a scala package Bar, where Bar inherits from Foo. > > When I model my own compile_with_kawac method similar to the scala method, > this test fails. The reason it fails is because the java module Foo hasn't > been compiled when the kawa module Bar is being compiled. > > At first I suspected there might be something wrong in my compile_map code, > but after looking at it, it seems that the method does not even try to > figure out build order at all, only mapping from source file to class file. > > So how is build order decided in buildr? > > For this one test I added a workaround where I retry kawa compilation if it > fails the first time, but considering that I'm doing everything in a > simliar way and order as the scala module, there's got to be something I'm > missing. Worst case, the scala compiler handles such dependencies itself. > > Anyway, figured I would ask, hoping somebody could clue me in. > > Thanks, > > Marius Kjeldahl -- Cheers, Peter Donald
Fwd: svn commit: r1513707 - in /buildr/trunk: CHANGELOG addon/buildr/gwt.rb doc/packaging.textile lib/buildr.rb lib/buildr/core/assets.rb lib/buildr/ide/idea.rb lib/buildr/java/packaging.rb spec/java/
Hi,
I just committed some very basic support for web asset management within
buildr. We have been using several variants of this for the last year or so
and am interested to see if other people have the same sorts of
requirements.
The end goal is to integrate with other more modern javascript/css tools
(i.e. bower/grunt/npm/etc) but use buildr to drive the main workflow.
Anyhoo - I am just about to head out on a holiday but thought I would
commit add this before I left to see if anyone had better ideas which could
be implemented when I got back.
-- Forwarded message --
From:
Date: Wed, Aug 14, 2013 at 11:23 AM
Subject: svn commit: r1513707 - in /buildr/trunk: CHANGELOG
addon/buildr/gwt.rb doc/packaging.textile lib/buildr.rb
lib/buildr/core/assets.rb lib/buildr/ide/idea.rb
lib/buildr/java/packaging.rb spec/java/packaging_spec.rb
To: comm...@buildr.apache.org
Author: donaldp
Date: Wed Aug 14 01:23:28 2013
New Revision: 1513707
URL: http://svn.apache.org/r1513707
Log:
Initial support for simple integration of an asset pipeline.
See "Compiling Assets" section in the manual.
Added:
buildr/trunk/lib/buildr/core/assets.rb
Modified:
buildr/trunk/CHANGELOG
buildr/trunk/addon/buildr/gwt.rb
buildr/trunk/doc/packaging.textile
buildr/trunk/lib/buildr.rb
buildr/trunk/lib/buildr/ide/idea.rb
buildr/trunk/lib/buildr/java/packaging.rb
buildr/trunk/spec/java/packaging_spec.rb
Modified: buildr/trunk/CHANGELOG
URL:
http://svn.apache.org/viewvc/buildr/trunk/CHANGELOG?rev=1513707&r1=1513706&r2=1513707&view=diff
==
--- buildr/trunk/CHANGELOG (original)
+++ buildr/trunk/CHANGELOG Wed Aug 14 01:23:28 2013
@@ -1,4 +1,6 @@
1.4.13 (Pending)
+* Added: Initial support for simple integration of an asset pipeline.
+ See "Compiling Assets" section in the manual.
* Fixed: BUILDR-673 - Fix the option handling of the MultiTest test
framework to behave as documented. Only the framework specific
options are passed to the test. Submitted by John Roth.
Modified: buildr/trunk/addon/buildr/gwt.rb
URL:
http://svn.apache.org/viewvc/buildr/trunk/addon/buildr/gwt.rb?rev=1513707&r1=1513706&r2=1513707&view=diff
==
--- buildr/trunk/addon/buildr/gwt.rb (original)
+++ buildr/trunk/addon/buildr/gwt.rb Wed Aug 14 01:23:28 2013
@@ -105,6 +105,7 @@ module Buildr
end
task.enhance(dependencies)
task.enhance([project.compile])
+project.assets.paths << task
task
end
Modified: buildr/trunk/doc/packaging.textile
URL:
http://svn.apache.org/viewvc/buildr/trunk/doc/packaging.textile?rev=1513707&r1=1513706&r2=1513707&view=diff
==
--- buildr/trunk/doc/packaging.textile (original)
+++ buildr/trunk/doc/packaging.textile Wed Aug 14 01:23:28 2013
@@ -235,6 +235,35 @@ puts 'Artifacts included in WAR package:
puts package(:war).libs.map(&:to_spec)
{% endhighlight %}
+h3(#war_extra_assets). Compiling Assets
+
+In modern web applications, it is common to use tools that compile and
compress assets. i.e. "Coffeescript":http://coffeescript.org/ is compiled
into javascript and "Sass":http://sass-lang.com/ compiles into CSS. Buildr
provides support using a simple @assets@ abstraction. Directory or file
tasks can be added to the @assets.paths@ configuration variable for a
project and the contents will be included in the package.
+
+h4(#coffeescript). Integrating CoffeeScript
+
+{% highlight ruby %}
+target_dir = _(:target, :generated, "coffee/main/webapp")
+source_dir = _(:source, :main, :coffee)
+
+assets.paths << file(target_dir =>
[FileList["#{source_dir}/**/*.coffee"]]) do
+ puts "Compiling coffeescript"
+ sh "coffee --bare --compile --output #{target_dir} #{source_dir}"
+ touch target_dir
+end
+{% endhighlight %}
+
+h4(#sass). Integrating Sass
+
+{% highlight ruby %}
+target_dir = _(:target, :generated, "sass/main/webapp")
+source_dir = _(:source, :main, :sass)
+
+assets.paths << file(target_dir => [FileList["#{source_dir}/**/*.scss"]])
do
+ puts "Compiling scss"
+ sh "scss -q --update #{source_dir}:#{target_dir}"
+ touch target_dir
+end
+{% endhighlight %}
h2(#aar). Packaging AARs
Modified: buildr/trunk/lib/buildr.rb
URL:
http://svn.apache.org/viewvc/buildr/trunk/lib/buildr.rb?rev=1513707&r1=1513706&r2=1513707&view=diff
==
--- buildr/trunk/lib/buildr.rb (original)
+++ buildr/trunk/lib/buildr.rb Wed Aug 14 01:23:28 2013
@@ -42,6 +42,7 @@ require 'buildr/core/common'
require 'buildr/core/application'
require 'buildr/core/jrebel'
require 'buildr/core/project'
+require 'buildr/core/assets'
require 'buildr/core/environment'
require 'buildr/core/help'
require 'buildr/core/checks'
Added: buildr/trunk/lib/buildr/core/asset
