Nabble - Buildr - Dev

Re: Bundled Buildr + JRuby distribution

2009-11-10T14:59:29Z

Thanks, yes, I think I have solutions for both platforms now. Just need to
start VirtualBox to test the Windows part (which I should have done the
first time around).

And I've now removed all other scripts (jirb, jrubyc, ...) so they don't
conflict with other JRuby installs.

alex

On Tue, Nov 10, 2009 at 2:53 PM, Nick Sieger <nicksieger@...> wrote:

> Alex,
>
> For Windows, you can piggy back off our new native launcher in JRuby 1.4 by
> copying jruby.exe to buildr.exe. This effectively does the same as "jruby -S
> buildr" would do. The PATH issue is trickier admittedly. You really need the
> shebang in the "buildr" script to point to the copy of JRuby that was
> bundled, instead of "#!/usr/bin/env jruby".
>
> /Nick
>
>
> On Nov 10, 2009, at 16:42 , Alex Boisvert wrote:
>
> Hmmmm.... for a start there's two big issues with this distro. First, if
>> you already have jruby in your PATH, things get confused and basically
>> nothing works. Second, there's no buildr.bat so it's pretty useless for
>> Windows users. (Unless they are willing to run "jruby -S buildr")
>>
>> I'll do another take later. Thanks for listening ;)
>>
>> alex
>>
>>
>> On Tue, Nov 10, 2009 at 2:04 PM, Alex Boisvert <alex.boisvert@...
>> >wrote:
>>
>> Hi,
>>>
>>> I've created an experimental distribution of Buildr 1.3.5 and JRuby 1.4.0
>>> and made it available at:
>>> http://people.apache.org/~boisvert/buildr-1.3.5-jruby-1.4.0.zip<http://people.apache.org/%7Eboisvert/buildr-1.3.5-jruby-1.4.0.zip>
>>> <http://people.apache.org/%7Eboisvert/buildr-1.3.5-jruby-1.4.0.zip>
>>>
>>>
>>> The distro is 15M -- not too bad. I've trimmed the packaged JRuby of
>>> everything I could that didn't affect functionality, such as
>>> documentation
>>> and Ruby 1.9 support.
>>>
>>> To use it, simply
>>> 1) unzip in a directory,
>>> 2) set your PATH to point to the "bin" directory, and
>>> 3) run "buildr" as usual.
>>>
>>> Looking for feedback on how it works as a quick way to get yourself/other
>>> people started. If there's enough interest, it could become part of our
>>> supported distros.
>>>
>>> thanks,
>>> alex
>>>
>>>
>>>
>

Re: Bundled Buildr + JRuby distribution

2009-11-10T14:53:17Z

Alex,

For Windows, you can piggy back off our new native launcher in JRuby
1.4 by copying jruby.exe to buildr.exe. This effectively does the same
as "jruby -S buildr" would do. The PATH issue is trickier admittedly.
You really need the shebang in the "buildr" script to point to the
copy of JRuby that was bundled, instead of "#!/usr/bin/env jruby".

/Nick

On Nov 10, 2009, at 16:42 , Alex Boisvert wrote:

> Hmmmm.... for a start there's two big issues with this distro.
> First, if
> you already have jruby in your PATH, things get confused and basically
> nothing works. Second, there's no buildr.bat so it's pretty useless
> for
> Windows users. (Unless they are willing to run "jruby -S buildr")
>
> I'll do another take later. Thanks for listening ;)
>
> alex
>
>
> On Tue, Nov 10, 2009 at 2:04 PM, Alex Boisvert <alex.boisvert@...
> >wrote:
>
>> Hi,
>>
>> I've created an experimental distribution of Buildr 1.3.5 and JRuby
>> 1.4.0
>> and made it available at:
>> http://people.apache.org/~boisvert/buildr-1.3.5-jruby-1.4.0.zip<http://people.apache.org/%7Eboisvert/buildr-1.3.5-jruby-1.4.0.zip
>> >
>>
>> The distro is 15M -- not too bad. I've trimmed the packaged JRuby of
>> everything I could that didn't affect functionality, such as
>> documentation
>> and Ruby 1.9 support.
>>
>> To use it, simply
>> 1) unzip in a directory,
>> 2) set your PATH to point to the "bin" directory, and
>> 3) run "buildr" as usual.
>>
>> Looking for feedback on how it works as a quick way to get yourself/
>> other
>> people started. If there's enough interest, it could become part
>> of our
>> supported distros.
>>
>> thanks,
>> alex
>>
>>

Re: Bundled Buildr + JRuby distribution

2009-11-10T14:42:45Z

Hmmmm.... for a start there's two big issues with this distro. First, if
you already have jruby in your PATH, things get confused and basically
nothing works. Second, there's no buildr.bat so it's pretty useless for
Windows users. (Unless they are willing to run "jruby -S buildr")

I'll do another take later. Thanks for listening ;)

alex

On Tue, Nov 10, 2009 at 2:04 PM, Alex Boisvert <alex.boisvert@...>wrote:

> Hi,
>
> I've created an experimental distribution of Buildr 1.3.5 and JRuby 1.4.0
> and made it available at:
> http://people.apache.org/~boisvert/buildr-1.3.5-jruby-1.4.0.zip<http://people.apache.org/%7Eboisvert/buildr-1.3.5-jruby-1.4.0.zip>
>
> The distro is 15M -- not too bad. I've trimmed the packaged JRuby of
> everything I could that didn't affect functionality, such as documentation
> and Ruby 1.9 support.
>
> To use it, simply
> 1) unzip in a directory,
> 2) set your PATH to point to the "bin" directory, and
> 3) run "buildr" as usual.
>
> Looking for feedback on how it works as a quick way to get yourself/other
> people started. If there's enough interest, it could become part of our
> supported distros.
>
> thanks,
> alex
>
>

Bundled Buildr + JRuby distribution

2009-11-10T14:04:19Z

Hi,

I've created an experimental distribution of Buildr 1.3.5 and JRuby 1.4.0
and made it available at:
http://people.apache.org/~boisvert/buildr-1.3.5-jruby-1.4.0.zip

The distro is 15M -- not too bad. I've trimmed the packaged JRuby of
everything I could that didn't affect functionality, such as documentation
and Ruby 1.9 support.

To use it, simply
1) unzip in a directory,
2) set your PATH to point to the "bin" directory, and
3) run "buildr" as usual.

Looking for feedback on how it works as a quick way to get yourself/other
people started. If there's enough interest, it could become part of our
supported distros.

thanks,
alex

New Committer: Daniel Spiewak

2009-04-23T17:54:37Z

Builders and shakers,

I'm happy to announce that Daniel Spiewak has been elected as committer for
Apache Buildr.

Daniel has been an active contributor for some time now. He's fixed bugs,
scratched his own itch, worked on various features (some of them already
integrated, some of them still experimental but likely to eventually be
integrated), he's been active on the mailing lists and written some good
usage and advocacy posts on his blog. In short, he's been doing awesome
work and we're ecstatic to have him join our project!

Welcome Daniel!

A little too terse...

2009-02-26T22:29:42Z

This recent change,

Running svn diff -r735809:744045 lib/buildr/core/application.rb
r744045 | assaf | 2009-02-13 01:13:42 -0800 (Fri, 13 Feb 2009) | 3 lines

Setting RakeFileUtils.verbose_flag to false prevents the annoying messages
in every FileUtils method and sh call.
Failure in test framework is now reported and the test allowed to fail
properly, rather than miserably.
Fixed failing tests in transport_spec.rb.
Index: lib/buildr/core/application.rb
===================================================================
--- lib/buildr/core/application.rb (revision 735809)
+++ lib/buildr/core/application.rb (revision 744045)
@@ -263,6 +263,7 @@

standard_buildr_options.each { |args| opts.on(*args) }
parsed_argv = opts.parse(ARGV)
+ RakeFileUtils.verbose_flag = options.trace
parsed_argv
end

... has shut up much more than FileUtils operations on my system; I don't
see messages such as:

Building ode-axis215
Compiling ode-axis215:utils into /home/boisvert/git/pxe/utils/target/classes
Compiling ode-axis215:utils:test into
/home/boisvert/git/pxe/utils/target/test/classes
...

anymore and I still see messages such as:

rm -rf
/home/boisvert/git/pxe/axis2/target

rm -rf
/home/boisvert/git/pxe/axis2/reports

rm -rf
/home/boisvert/git/pxe/bpel-api/target

rm -rf
/home/boisvert/git/pxe/bpel-api/reports

rm -rf
/home/boisvert/git/pxe/utils/target

rm -rf /home/boisvert/git/pxe/utils/reports

during cleaning.

Is is just my system, or is there a better way?

alex

The Eclipse IP process ...

2009-02-18T09:39:57Z

... looks very similar to the Apache IP process(*), at least judging from
this cartoon:

http://www.eclipse.org/projects/dev_process/ip-process-in-cartoons.php

(*) True, Buildr uses JIRA and not Bugzilla, we don't involve legal in every
single release, we're trying to offload patches to Git, but by and large I
think we achieve the same annoy factor as Eclipse

February Board Report

2009-02-13T10:55:44Z

Hi,

I wrote a draft of our February Board Report which is due by Sunday:
http://cwiki.apache.org/confluence/display/BUILDR/February+2009+Board+Report

Please comment or edit by tomorrow (Saturday) if you think I've missed
anything.

thanks,
alex

BUILDR-246

2009-02-09T19:47:54Z

Has anyone happened to look at the potential bug I posted?

https://issues.apache.org/jira/browse/BUILDR-246

In summary, the symptom is this:

Invalid argument
c:/ruby/1.8.7/lib/ruby/gems/1.8/gems/buildr-1.3.3/lib/buildr/java/tests.rb:62:in
`new'

when my tests are run. There are no problems (apparently) in
compiling the source or JUnit tests. I'm using a custom directory
structure for an existing project. I haven't tried to alter the
existing structure to buildr's preferred determine if that is a
contributing factor.

Any thoughts?

Re: checkstyle integration with buildr

2009-01-20T21:07:23Z

Haritha Reddy-2 wrote:

I am trying to create an addon for generation of checkstyle reports into
buildr. The attached checkstyle.rb contains checkstyle:html ( xsl_file=?
config_file=?) and checkstyle:xml (config_file=?)tasks to create checkstyle
reports.

If the command line arguments are not provided for xsl_file and config_file
, it expects that checkstyle_checks.xml and checkstyle.xsl files are present
in the folder where buildfile is located.

Is there a better way to handle the default case?

Thanks

Haritha

checkstyle.rb

Re: Board report for January

2009-01-07T14:17:27Z

On Wed, Jan 7, 2009 at 7:52 AM, Matthieu Riou <matthieu@...>wrote:

> We missed the report last month so don't forget to report to the board
> before Sunday.

Here's my first shot:
http://cwiki.apache.org/confluence/display/BUILDR/January+2009+Board+Report

alex

Lots of issues piling up...

2009-01-07T14:06:59Z

Buildrs,

Lots of issues have been piling up on the 1.3.4 target. It's a good sign
that the project is gathering momentum.

I think it would be healthy to have a 1.3.4 release in the January
timeframe. For this to happen, I'm planning to shuffle the issues around to
remove any issues that are not critical _and_ don't have proposed
patches. For the remaining bugs that are either critical or have patches,
I'd like to solicit further contribution to take these issues down the last
mile of commit into our codebase. Some issues will need proper testing,
some just need a little review and some will need a motivated volunteer to
make it happen.

If there's no objections, I'll do a first clean up tomorrow.

alex

Re: Board report for January

2009-01-07T11:38:34Z

On Wed, Jan 7, 2009 at 10:15 AM, Alex Boisvert <boisvert@...> wrote:

> I can take a first shot at it.
>
> Is this something we should publish on our wiki?
> http://cwiki.apache.org/confluence/display/BUILDR/Index
>

Sure, as long as what's discuss in there is public (and it is 99% of the
time).

>
>
> On Wed, Jan 7, 2009 at 7:52 AM, Matthieu Riou <matthieu@...
> >wrote:
>
> > Hey guys,
> >
> > We missed the report last month so don't forget to report to the board
> > before Sunday.
> >
> > Thanks,
> > Matthieu
> >
>

Re: Board report for January

2009-01-07T10:15:17Z

I can take a first shot at it.

Is this something we should publish on our wiki?
http://cwiki.apache.org/confluence/display/BUILDR/Index

On Wed, Jan 7, 2009 at 7:52 AM, Matthieu Riou <matthieu@...>wrote:

> Hey guys,
>
> We missed the report last month so don't forget to report to the board
> before Sunday.
>
> Thanks,
> Matthieu
>

Board report for January

2009-01-07T07:52:44Z

Hey guys,

We missed the report last month so don't forget to report to the board
before Sunday.

Thanks,
Matthieu

Re: transitive project dependencies

2008-12-10T20:33:18Z

Stephen Bannasch wrote:

>> This method only works for artifacts you're downloading from the Maven
>> repository, not for anything created with Buildr.
>>
>> Full transitive dependency support is planned for 1.4.
>>
>> Assaf
>
> Is this still planned for version 1.4?
>
> The #transitive method in lib/buildr/packaging/artifact.rb doesn't
> have any rdoc and isn't mentioned on the web site or pdf. The method
> itself hasn't changed since it was checked in over a year ago.
>
> In https://issues.apache.org:443/jira/browse/BUILDR-206 Assaf writes:
>
> "Transitive is for people who work with POMs and eager to use
> something until we work out transitive dependency support in the
> framework."
>
> Is there any documentation for this feature?
>
> I'm trying to evaluate buildr for a project with a large number of
> artifacts and transitive dependencies?
>
> It's not clear to me if this is the kind of build task buildr is
> intended for [1].
>
> [1]
> http://www.codecommit.com/blog/java/buildr-still-not-ready-for-prime-time,
> May 2008

While I love Buildr, this is one of its weak points. The #transitive
method does not work well, for example, it doesn't do any version
resolution (tried transitive on 'xom:xom:jar:1.1' and it downloaded xom
1.0b3 also...)

However, if working on a large project, I think you'll get a lot of
benefit from Buildr's flexibility and task oriented approach. With the
problem above it took me ~5 minutes to just list the transitive
dependencies in buildfile and continue working.

Anyone tried using the maven ant tasks (or maybe MavenEmbedder and the
dependency plugin) from Buildr?

(Note that, transitive dependencies is not a good idea for compiling (if
A depends on B for compiling, C may depend on A without needing B unless
using it directly)).

Ittay

--
--
Ittay Dror <ittay.dror@...>

Re: transitive project dependencies

2008-12-10T12:51:06Z

>This method only works for artifacts you're downloading from the Maven
>repository, not for anything created with Buildr.
>
>Full transitive dependency support is planned for 1.4.
>
>Assaf

Is this still planned for version 1.4?

The #transitive method in lib/buildr/packaging/artifact.rb doesn't
have any rdoc and isn't mentioned on the web site or pdf. The method
itself hasn't changed since it was checked in over a year ago.

In https://issues.apache.org:443/jira/browse/BUILDR-206 Assaf writes:

"Transitive is for people who work with POMs and eager to use
something until we work out transitive dependency support in the
framework."

Is there any documentation for this feature?

I'm trying to evaluate buildr for a project with a large number of
artifacts and transitive dependencies?

It's not clear to me if this is the kind of build task buildr is
intended for [1].

[1]
http://www.codecommit.com/blog/java/buildr-still-not-ready-for-prime-time,
May 2008

Re: Release task

2008-12-10T08:17:09Z

On Wed, Dec 10, 2008 at 3:24 AM, Hervé Giraud <hgiraud@...> wrote:

> Hi
>
> Alex Boisvert a écrit :
>
>> On Tue, Dec 9, 2008 at 2:36 AM, Herv� Giraud <hgiraud@...> wrote:
>>
>> > I have the following "problems" with the release task.
>> >
>> > The repo_url is defined like this :
>> >
>> > def repo_url
>> > svn('info').scan(/URL: (.*)/)[0][0]
>> > end
>> >
>> > On my system, "svn info" gives me "URL : http://..." : there is a space
>> > after "URL".
>> > A better regexp could be : /URL\s?: (.*)/
>>
>>
>> For reference, could you provide the output of "svn -version" and "svn
>> info" ?
>>
>>
> I have a french version of Windows XP (I know, never a good idea not using
> english version).

mais quelle idee aussi!.. ;)

>
> I'm using Msys or dos.
>
> svn, version 1.5.4 (r33841)
> compilé Oct 24 2008, 15:51:42
>
> $ svn info
> Chemin : .
> URL : https://...
> Racine du dépôt : https://...
> UUID du dépôt : bb6581bd-5aa3-46da-a306-7108957c620c
> Révision : 208
> Type de noeud : répertoire
> Tâche programmée : normale
> Auteur de la dernière modification : ...
> Révision de la dernière modification : 206
> Date de la dernière modification: 2008-12-09 10:00:24 +0100 (mar. 09 déc.
> 2008)
>
>> Next, our commit messages have a special format (we start with keywords),
>> > and
>> > we cannot use the buildr release without modifications.
>> > I can patch the Release class in my buildfile, but perhaps something
>> > similar to
>> > the release attribute in buildr 1.3.3 would be possible, like in the
>> > following exemple ?
>> >
>> > Release.tag_name = lambda { |ver| "foo-#{ver}" }
>> > Release.commit_format = lambda { |msg| "ADD: #{msg}" }
>>
>>
>> I think this would be a welcome enhancement. Do you want to submit a
>> patch?
>>
>>
> Awesome, somebody did it already !! Thank you.
>
>> Last point, it seems there is a problem with the 1.5.x version of the svn
>> > client.
>> > I'm using the command line svn client (1.5.4), and the scn.copy does not
>> > work.
>> >
>> > I think this message explains it :
>> >
>> http://www.nabble.com/Error-when-creating-tags-from-working-copy-td19913357.html
>> > I did what they recommend, and it worked when I modify the "tag_release"
>> > method and I do a update just before the copy
>>
>>
>> I'm not sure if you're just sharing this information, or asking if this
>> should become standard in Buildr. It seems like a bug on Subversion's
>> side
>> and doing a "svn update" before tagging, as opposed to earlier in the
>> build
>> process, seems to be wrong... It creates a race condition and I wouldn't
>> want to tag different content than what was used during the release.
>>
>> alex
>>
>>
> Sorry if I'm not clear : I'm just sharing this info because I wasn't aware
> of it.
> You're right it's a bug in svn but it's the only way I know today if I
> wan't to use the release task (of course, nobody should do a commit during
> this release).
>
> Herve
>
>

Re: Release task

2008-12-10T07:47:11Z

On Wed, Dec 10, 2008 at 3:24 AM, Hervé Giraud <hgiraud@...> wrote:

> Alex Boisvert a écrit :
>
>> On Tue, Dec 9, 2008 at 2:36 AM, Herv� Giraud <hgiraud@...> wrote:
>>
>> > I have the following "problems" with the release task.
>> >
>> > The repo_url is defined like this :
>> >
>> > def repo_url
>> > svn('info').scan(/URL: (.*)/)[0][0]
>> > end
>> >
>> > On my system, "svn info" gives me "URL : http://..." : there is a space
>> > after "URL".
>> > A better regexp could be : /URL\s?: (.*)/
>>
>>
>> For reference, could you provide the output of "svn -version" and "svn
>> info" ?
>>
>>
> I have a french version of Windows XP (I know, never a good idea not using
> english version).
> I'm using Msys or dos.
>
> svn, version 1.5.4 (r33841)
> compilé Oct 24 2008, 15:51:42
>
> $ svn info
> Chemin : .
> URL : https://...
> Racine du dépôt : https://...
> UUID du dépôt : bb6581bd-5aa3-46da-a306-7108957c620c
> Révision : 208
> Type de noeud : répertoire
> Tâche programmée : normale
> Auteur de la dernière modification : ...
> Révision de la dernière modification : 206
> Date de la dernière modification: 2008-12-09 10:00:24 +0100 (mar. 09 déc.
> 2008)

I think this makes a good case for using "svn info --xml" instead of the
human-readable output so we are not subject to any localization differences
between versions.

I've created https://issues.apache.org/jira/browse/BUILDR-226

alex

Re: Release task

2008-12-10T03:24:31Z

Hi

Alex Boisvert a écrit :

> On Tue, Dec 9, 2008 at 2:36 AM, Herv� Giraud <hgiraud@...> wrote:
>
> > I have the following "problems" with the release task.
> >
> > The repo_url is defined like this :
> >
> > def repo_url
> > svn('info').scan(/URL: (.*)/)[0][0]
> > end
> >
> > On my system, "svn info" gives me "URL : http://..." : there is a space
> > after "URL".
> > A better regexp could be : /URL\s?: (.*)/
>
>
> For reference, could you provide the output of "svn -version" and "svn
> info" ?
>

I have a french version of Windows XP (I know, never a good idea not
using english version).
I'm using Msys or dos.

svn, version 1.5.4 (r33841)
compilé Oct 24 2008, 15:51:42

$ svn info
Chemin : .
URL : https://...
Racine du dépôt : https://...
UUID du dépôt : bb6581bd-5aa3-46da-a306-7108957c620c
Révision : 208
Type de noeud : répertoire
Tâche programmée : normale
Auteur de la dernière modification : ...
Révision de la dernière modification : 206
Date de la dernière modification: 2008-12-09 10:00:24 +0100 (mar. 09
déc. 2008)

> Next, our commit messages have a special format (we start with keywords),
> > and
> > we cannot use the buildr release without modifications.
> > I can patch the Release class in my buildfile, but perhaps something
> > similar to
> > the release attribute in buildr 1.3.3 would be possible, like in the
> > following exemple ?
> >
> > Release.tag_name = lambda { |ver| "foo-#{ver}" }
> > Release.commit_format = lambda { |msg| "ADD: #{msg}" }
>
>
> I think this would be a welcome enhancement. Do you want to submit a
> patch?
>

Awesome, somebody did it already !! Thank you.

> Last point, it seems there is a problem with the 1.5.x version of the svn
> > client.
> > I'm using the command line svn client (1.5.4), and the scn.copy does not
> > work.
> >
> > I think this message explains it :
> > http://www.nabble.com/Error-when-creating-tags-from-working-copy-td19913357.html
> > I did what they recommend, and it worked when I modify the "tag_release"
> > method and I do a update just before the copy
>
>
> I'm not sure if you're just sharing this information, or asking if this
> should become standard in Buildr. It seems like a bug on Subversion's side
> and doing a "svn update" before tagging, as opposed to earlier in the build
> process, seems to be wrong... It creates a race condition and I wouldn't
> want to tag different content than what was used during the release.
>
> alex
>

Sorry if I'm not clear : I'm just sharing this info because I wasn't
aware of it.
You're right it's a bug in svn but it's the only way I know today if I
wan't to use the release task (of course, nobody should do a commit
during this release).

Herve

Re: Release task

2008-12-09T16:40:04Z

On Tue, Dec 9, 2008 at 2:36 AM, Hervé Giraud <hgiraud@...> wrote:

> Hi,
>
> I have the following "problems" with the release task.
>
> The repo_url is defined like this :
>
> def repo_url
> svn('info').scan(/URL: (.*)/)[0][0]
> end
>
> On my system, "svn info" gives me "URL : http://..." : there is a space
> after "URL".
> A better regexp could be : /URL\s?: (.*)/
>
>
> Next, our commit messages have a special format (we start with keywords),
> and
> we cannot use the buildr release without modifications.
> I can patch the Release class in my buildfile, but perhaps something
> similar to
> the release attribute in buildr 1.3.3 would be possible, like in the
> following exemple ?
>
> Release.tag_name = lambda { |ver| "foo-#{ver}" }
> Release.commit_format = lambda { |msg| "ADD: #{msg}" }

Jira created https://issues.apache.org/jira/browse/BUILDR-223
Patch included in BUILDR-222

>
>
>
> Last point, it seems there is a problem with the 1.5.x version of the svn
> client.
> I'm using the command line svn client (1.5.4), and the scn.copy does not
> work.
>
> I think this message explains it :
> http://www.nabble.com/Error-when-creating-tags-from-working-copy-td19913357.html
> I did what they recommend, and it worked when I modify the "tag_release"
> method and I do a update just before the copy :
>
> def tag_release
> version = extract_version
> info "Tagging release #{version}"
> url = tag_url Svn.repo_url, version
> Svn.remove url, 'Removing old copy' rescue nil
> Svn.svn 'update' # BUG here in 1.5.x ?
> Svn.copy Dir.pwd, url, "Release #{version}"
> end
>
>

Re: [jira] Commented: (BUILDR-222) Support Git as a version control system

2008-12-09T14:08:17Z

Thanks Assaf.
I'm improving the patch.

Alexis

On Tue, Dec 9, 2008 at 1:57 PM, Assaf Arkin <arkin@...> wrote:

> On Tue, Dec 9, 2008 at 1:39 PM, Alexis Midon <alexismidon@...>
> wrote:
> > On Tue, Dec 9, 2008 at 11:55 AM, Assaf Arkin (JIRA) <jira@...>
> wrote:
> >
> >>
> >> [
> >>
> https://issues.apache.org/jira/browse/BUILDR-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654926#action_12654926
> ]
> >>
> >> Assaf Arkin commented on BUILDR-222:
> >> ------------------------------------
> >>
> >> Awesome. A few comments:
> >>
> >> When you call Git.commit, it supers into a "common" commit (but only for
> >> SVN and Git, not Hg) which then subs through a bin method to perform the
> >> actual command, which doesn't mean the same thing in all VCS. In terms
> of
> >> readability, there's more code to deal with than if the commit method
> was
> >> never shared.
> >
> >
> > ok, I will push down the super implementation.
> >
> >
> >>
> >> Git.commit is sometimes commit, but sometimes it's pushes, which happens
> to
> >> be closer in spirit to an SVN commit, which just means the method name
> is
> >> not self-describing.
> >
> >
> > any suggestions?
> >
> >
> >
> >>
> >> Vcs::Base.execute requires 8 lines (!) to deal with the :nofail option,
> >> which in turn is only used once by Git's uncommitted_files method.
> Everybody
> >> gets to share that code path, though. Much simpler is to have
> >> uncommited_files deal with its own personal issues, changing its first
> line
> >> to:
> >>
> >> status = `git status`
> >>
> >
> > Actually I evaluated this option and found it not so great for testing. I
> > can't see how to mock this shell call. I'm a bit uncomfortable with that.
>
> You can define a method specifically for stubbing, that's different
> from overloading execute. Other options:
>
> - open('|git status').read
> - mock command line executable, point to it by setting ENV['PATH'] =
> Dir.pwd
>
> >> Git.applies_to? should look for .git (or .git/config) in the current
> >> directory instead of running git branch. As a result of this change,
> you'll
> >> only be able to make a release from a buildfile at the root of the
> project,
> >> a good restriction to have.
> >>
> >
> > Same issue for me here: testing/mocking. And the restriction you
> mentioned
> > will not be valid for Svn.
>
> To mock you just need to create a .git/config file in the current
> working directory. You can do anything you want there, it's a
> temporary directory created only to run the test
>
> If you check that the URL returned from svn info ends in /trunk or
> /branch/name, you're limiting release to the project root. svn info on
> a sub-directory will return a different URL.
>
> Assaf
>
> >
> >
> >
> >>
> >> Are both vcs and guess_vcs method necessary?
> >
> >
> > Actually not. I will merge them.
> >
> >
> >>
> >> > Support Git as a version control system
> >> > ---------------------------------------
> >> >
> >> > Key: BUILDR-222
> >> > URL: https://issues.apache.org/jira/browse/BUILDR-222
> >> > Project: Buildr
> >> > Issue Type: Improvement
> >> > Components: Core features
> >> > Reporter: Alexis Midon
> >> > Attachments: BUILDR-222-0001-git-support-for-release.txt
> >> >
> >> >
> >> > The Release task uses Subversion to check for uncommitted files and
> tag
> >> the source repository.
> >> > Of course this fails when your project does not use Subversion but Git
> >> for instance.
> >> > The improvement could be to provide a VCS abstraction with 2
> >> implementations: Subversion and Git.
> >> > A method could instantiate the proper implementation.
> >>
> >> --
> >> This message is automatically generated by JIRA.
> >> -
> >> You can reply to this email to add a comment to the issue online.
> >>
> >>
> >
>

Re: [jira] Commented: (BUILDR-222) Support Git as a version control system

2008-12-09T13:57:08Z

On Tue, Dec 9, 2008 at 1:39 PM, Alexis Midon <alexismidon@...> wrote:

> On Tue, Dec 9, 2008 at 11:55 AM, Assaf Arkin (JIRA) <jira@...> wrote:
>
>>
>> [
>> https://issues.apache.org/jira/browse/BUILDR-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654926#action_12654926]
>>
>> Assaf Arkin commented on BUILDR-222:
>> ------------------------------------
>>
>> Awesome. A few comments:
>>
>> When you call Git.commit, it supers into a "common" commit (but only for
>> SVN and Git, not Hg) which then subs through a bin method to perform the
>> actual command, which doesn't mean the same thing in all VCS. In terms of
>> readability, there's more code to deal with than if the commit method was
>> never shared.
>
>
> ok, I will push down the super implementation.
>
>
>>
>> Git.commit is sometimes commit, but sometimes it's pushes, which happens to
>> be closer in spirit to an SVN commit, which just means the method name is
>> not self-describing.
>
>
> any suggestions?
>
>
>
>>
>> Vcs::Base.execute requires 8 lines (!) to deal with the :nofail option,
>> which in turn is only used once by Git's uncommitted_files method. Everybody
>> gets to share that code path, though. Much simpler is to have
>> uncommited_files deal with its own personal issues, changing its first line
>> to:
>>
>> status = `git status`
>>
>
> Actually I evaluated this option and found it not so great for testing. I
> can't see how to mock this shell call. I'm a bit uncomfortable with that.

You can define a method specifically for stubbing, that's different
from overloading execute. Other options:

- open('|git status').read
- mock command line executable, point to it by setting ENV['PATH'] = Dir.pwd

>> Git.applies_to? should look for .git (or .git/config) in the current
>> directory instead of running git branch. As a result of this change, you'll
>> only be able to make a release from a buildfile at the root of the project,
>> a good restriction to have.
>>
>
> Same issue for me here: testing/mocking. And the restriction you mentioned
> will not be valid for Svn.

To mock you just need to create a .git/config file in the current
working directory. You can do anything you want there, it's a
temporary directory created only to run the test

If you check that the URL returned from svn info ends in /trunk or
/branch/name, you're limiting release to the project root. svn info on
a sub-directory will return a different URL.

Assaf

>
>
>
>>
>> Are both vcs and guess_vcs method necessary?
>
>
> Actually not. I will merge them.
>
>
>>
>> > Support Git as a version control system
>> > ---------------------------------------
>> >
>> > Key: BUILDR-222
>> > URL: https://issues.apache.org/jira/browse/BUILDR-222
>> > Project: Buildr
>> > Issue Type: Improvement
>> > Components: Core features
>> > Reporter: Alexis Midon
>> > Attachments: BUILDR-222-0001-git-support-for-release.txt
>> >
>> >
>> > The Release task uses Subversion to check for uncommitted files and tag
>> the source repository.
>> > Of course this fails when your project does not use Subversion but Git
>> for instance.
>> > The improvement could be to provide a VCS abstraction with 2
>> implementations: Subversion and Git.
>> > A method could instantiate the proper implementation.
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>>
>

Re: [jira] Commented: (BUILDR-222) Support Git as a version control system

2008-12-09T13:56:19Z

Alexis

On Tue, Dec 9, 2008 at 1:39 PM, Alexis Midon <alexismidon@...> wrote:

>
> On Tue, Dec 9, 2008 at 11:55 AM, Assaf Arkin (JIRA) <jira@...>wrote:
>
>>
>> [
>> https://issues.apache.org/jira/browse/BUILDR-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654926#action_12654926]
>>
>> Assaf Arkin commented on BUILDR-222:
>> ------------------------------------
>>
>> Awesome. A few comments:
>>
>> When you call Git.commit, it supers into a "common" commit (but only for
>> SVN and Git, not Hg) which then subs through a bin method to perform the
>> actual command, which doesn't mean the same thing in all VCS. In terms of
>> readability, there's more code to deal with than if the commit method was
>> never shared.
>
>
> ok, I will push down the super implementation.
>
>
>>
>> Git.commit is sometimes commit, but sometimes it's pushes, which happens
>> to be closer in spirit to an SVN commit, which just means the method name is
>> not self-describing.
>
>
> any suggestions?
>
>
>
>>
>> Vcs::Base.execute requires 8 lines (!) to deal with the :nofail option,
>> which in turn is only used once by Git's uncommitted_files method. Everybody
>> gets to share that code path, though. Much simpler is to have
>> uncommited_files deal with its own personal issues, changing its first line
>> to:
>>
>> status = `git status`
>>
>
> Actually I evaluated this option and found it not so great for testing. I
> can't see how to mock this shell call. I'm a bit uncomfortable with that.
>
>
>>
>> Git.applies_to? should look for .git (or .git/config) in the current
>> directory instead of running git branch. As a result of this change, you'll
>> only be able to make a release from a buildfile at the root of the project,
>> a good restriction to have.
>>
>
> Same issue for me here: testing/mocking. And the restriction you mentioned
> will not be valid for Svn.
>
>

read "the restriction you mentioned *will be* valid for Svn."

Re: [jira] Commented: (BUILDR-222) Support Git as a version control system

2008-12-09T13:39:24Z

On Tue, Dec 9, 2008 at 11:55 AM, Assaf Arkin (JIRA) <jira@...> wrote:

>
> [
> https://issues.apache.org/jira/browse/BUILDR-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654926#action_12654926]
>
> Assaf Arkin commented on BUILDR-222:
> ------------------------------------
>
> Awesome. A few comments:
>
> When you call Git.commit, it supers into a "common" commit (but only for
> SVN and Git, not Hg) which then subs through a bin method to perform the
> actual command, which doesn't mean the same thing in all VCS. In terms of
> readability, there's more code to deal with than if the commit method was
> never shared.

ok, I will push down the super implementation.

>
> Git.commit is sometimes commit, but sometimes it's pushes, which happens to
> be closer in spirit to an SVN commit, which just means the method name is
> not self-describing.

any suggestions?

>
> Vcs::Base.execute requires 8 lines (!) to deal with the :nofail option,
> which in turn is only used once by Git's uncommitted_files method. Everybody
> gets to share that code path, though. Much simpler is to have
> uncommited_files deal with its own personal issues, changing its first line
> to:
>
> status = `git status`
>

Actually I evaluated this option and found it not so great for testing. I
can't see how to mock this shell call. I'm a bit uncomfortable with that.

>
> Git.applies_to? should look for .git (or .git/config) in the current
> directory instead of running git branch. As a result of this change, you'll
> only be able to make a release from a buildfile at the root of the project,
> a good restriction to have.
>

Same issue for me here: testing/mocking. And the restriction you mentioned
will not be valid for Svn.

>
> Are both vcs and guess_vcs method necessary?

Actually not. I will merge them.

>
> > Support Git as a version control system
> > ---------------------------------------
> >
> > Key: BUILDR-222
> > URL: https://issues.apache.org/jira/browse/BUILDR-222
> > Project: Buildr
> > Issue Type: Improvement
> > Components: Core features
> > Reporter: Alexis Midon
> > Attachments: BUILDR-222-0001-git-support-for-release.txt
> >
> >
> > The Release task uses Subversion to check for uncommitted files and tag
> the source repository.
> > Of course this fails when your project does not use Subversion but Git
> for instance.
> > The improvement could be to provide a VCS abstraction with 2
> implementations: Subversion and Git.
> > A method could instantiate the proper implementation.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>

Re: Release task

2008-12-09T09:37:13Z

Alexis

On Tue, Dec 9, 2008 at 8:00 AM, Alex Boisvert <boisvert@...> wrote:

> On Tue, Dec 9, 2008 at 2:36 AM, Hervé Giraud <hgiraud@...> wrote:
>
> > I have the following "problems" with the release task.
> >
> > The repo_url is defined like this :
> >
> > def repo_url
> > svn('info').scan(/URL: (.*)/)[0][0]
> > end
> >
> > On my system, "svn info" gives me "URL : http://..." : there is a space
> > after "URL".
> > A better regexp could be : /URL\s?: (.*)/
>
>
> For reference, could you provide the output of "svn -version" and "svn
> info" ?
>
> Next, our commit messages have a special format (we start with keywords),
> > and
> > we cannot use the buildr release without modifications.
> > I can patch the Release class in my buildfile, but perhaps something
> > similar to
> > the release attribute in buildr 1.3.3 would be possible, like in the
> > following exemple ?
> >
> > Release.tag_name = lambda { |ver| "foo-#{ver}" }
> > Release.commit_format = lambda { |msg| "ADD: #{msg}" }
>
>
> I think this would be a welcome enhancement. Do you want to submit a
> patch?
>

yep, this could be easily added along with BUILDR-222.
I could provide a patch, the iron is still hot.

https://issues.apache.org/jira/browse/BUILDR-222

>
> Last point, it seems there is a problem with the 1.5.x version of the svn
> > client.
> > I'm using the command line svn client (1.5.4), and the scn.copy does not
> > work.
> >
> > I think this message explains it :
> >
> http://www.nabble.com/Error-when-creating-tags-from-working-copy-td19913357.html
> > I did what they recommend, and it worked when I modify the "tag_release"
> > method and I do a update just before the copy
>
>
> I'm not sure if you're just sharing this information, or asking if this
> should become standard in Buildr. It seems like a bug on Subversion's side
> and doing a "svn update" before tagging, as opposed to earlier in the build
> process, seems to be wrong... It creates a race condition and I wouldn't
> want to tag different content than what was used during the release.
>
> alex
>

Re: Release task

2008-12-09T08:00:32Z

On Tue, Dec 9, 2008 at 2:36 AM, Hervé Giraud <hgiraud@...> wrote:

> I have the following "problems" with the release task.
>
> The repo_url is defined like this :
>
> def repo_url
> svn('info').scan(/URL: (.*)/)[0][0]
> end
>
> On my system, "svn info" gives me "URL : http://..." : there is a space
> after "URL".
> A better regexp could be : /URL\s?: (.*)/

For reference, could you provide the output of "svn -version" and "svn
info" ?

Next, our commit messages have a special format (we start with keywords),
> and
> we cannot use the buildr release without modifications.
> I can patch the Release class in my buildfile, but perhaps something
> similar to
> the release attribute in buildr 1.3.3 would be possible, like in the
> following exemple ?
>
> Release.tag_name = lambda { |ver| "foo-#{ver}" }
> Release.commit_format = lambda { |msg| "ADD: #{msg}" }

I think this would be a welcome enhancement. Do you want to submit a
patch?

Last point, it seems there is a problem with the 1.5.x version of the svn
> client.
> I'm using the command line svn client (1.5.4), and the scn.copy does not
> work.
>
> I think this message explains it :
> http://www.nabble.com/Error-when-creating-tags-from-working-copy-td19913357.html
> I did what they recommend, and it worked when I modify the "tag_release"
> method and I do a update just before the copy

I'm not sure if you're just sharing this information, or asking if this
should become standard in Buildr. It seems like a bug on Subversion's side
and doing a "svn update" before tagging, as opposed to earlier in the build
process, seems to be wrong... It creates a race condition and I wouldn't
want to tag different content than what was used during the release.

alex

Release task

2008-12-09T02:36:56Z

Hi,

I have the following "problems" with the release task.

The repo_url is defined like this :

def repo_url
svn('info').scan(/URL: (.*)/)[0][0]
end

On my system, "svn info" gives me "URL : http://..." : there is a space
after "URL".
A better regexp could be : /URL\s?: (.*)/

Next, our commit messages have a special format (we start with
keywords), and
we cannot use the buildr release without modifications.
I can patch the Release class in my buildfile, but perhaps something
similar to
the release attribute in buildr 1.3.3 would be possible, like in the
following exemple ?

Release.tag_name = lambda { |ver| "foo-#{ver}" }
Release.commit_format = lambda { |msg| "ADD: #{msg}" }

Last point, it seems there is a problem with the 1.5.x version of the
svn client.
I'm using the command line svn client (1.5.4), and the scn.copy does not
work.

I think this message explains it :
http://www.nabble.com/Error-when-creating-tags-from-working-copy-td19913357.html
I did what they recommend, and it worked when I modify the "tag_release"
method and I do a update just before the copy :

def tag_release
version = extract_version
info "Tagging release #{version}"
url = tag_url Svn.repo_url, version
Svn.remove url, 'Removing old copy' rescue nil
Svn.svn 'update' # BUG here in 1.5.x ?
Svn.copy Dir.pwd, url, "Release #{version}"
end

@lock.synchronize

2008-12-06T13:21:18Z

Hi,

I wanted to share my findings about @lock.synchronize, used in
invoke_with_call_chain.

This method is implemented as

def mon_synchronize
mon_enter
begin
yield
ensure
mon_exit
end
end

The downside here is that creating a block requires resources and since
the body of this particular block creates a potentially large recursion
(esp. in Buildr), this can end up waisting a lot of memory. In my case,
replacing:
@lock.synchronize do
...
end

with
begin
@lock.mon_enter
....
ensure
@lock.mon_exit
end

made the difference between a segmentation fault and a successful build.

ittay

--
--
Ittay Dror <ittay.dror@...>

Re: Snapshot update support to Buildr? (Was: Where in the Buildr codebase does it determine that it needs to start retrieving a dependency jar?)

2008-12-02T08:56:05Z

On Tue, Dec 2, 2008 at 8:41 AM, Timo Rantalaiho <Timo.Rantalaiho@...>wrote:

> On Tue, 02 Dec 2008, Alex Boisvert wrote:
> > As far as I know, there's no support for timestamp version right now
> because
> > we don't support snapshots.
> >
> > But you can use a given timestamped version by explicitly providing it in
> > the artifact version.
>
> OK, my goal is really to get the snapshot support working.
> It seems that actually the snapshot downloading logic,
> including getting the correct URL, is already in artifact.rb .
> It's just that if the version without the timestamp is found,
> it wins over the timestamped versions.
>
> So just removing the non-timestamped versions from the
> repositories that have timestamped versions would probably
> help, though support for timestamped versions winning over
> the non-timestamped versions would be nice.

Understood and I agree with you supporting timestamped versions is just as
important.

alex

Re: Snapshot update support to Buildr? (Was: Where in the Buildr codebase does it determine that it needs to start retrieving a dependency jar?)

2008-12-02T08:41:06Z

On Tue, 02 Dec 2008, Alex Boisvert wrote:
> As far as I know, there's no support for timestamp version right now because
> we don't support snapshots.
>
> But you can use a given timestamped version by explicitly providing it in
> the artifact version.

OK, my goal is really to get the snapshot support working.
It seems that actually the snapshot downloading logic,
including getting the correct URL, is already in artifact.rb .
It's just that if the version without the timestamp is found,
it wins over the timestamped versions.

So just removing the non-timestamped versions from the
repositories that have timestamped versions would probably
help, though support for timestamped versions winning over
the non-timestamped versions would be nice.

Best wishes,
Timo

--
Timo Rantalaiho
Reaktor Innovations Oy <URL: http://www.ri.fi/ >

Re: Snapshot update support to Buildr? (Was: Where in the Buildr codebase does it determine that it needs to start retrieving a dependency jar?)

2008-12-02T08:14:43Z

As far as I know, there's no support for timestamp version right now because
we don't support snapshots.

But you can use a given timestamped version by explicitly providing it in
the artifact version.

alex

On Tue, Dec 2, 2008 at 7:53 AM, Timo Rantalaiho <Timo.Rantalaiho@...>wrote:

> Hello again,
>
> Talking about snapshot support...
>
>
> http://www.wicketstuff.org/maven/repository/org/apache/wicket/wicket/1.4-SNAPSHOT/
>
> I think that Buildr probably doesn't recognise the timestamped
> versions but just gets the ones without the timestamp in the
> version number, in this case dating from 30 June.
>
> Does anyone know if this is indeed the current behavior, of
> if there should be some existing support for the timestamp
> strings in snapshots?
>
> Best wishes,
> Timo
>
> --
> Timo Rantalaiho
> Reaktor Innovations Oy <URL: http://www.ri.fi/ >
>

Re: Snapshot update support to Buildr? (Was: Where in the Buildr codebase does it determine that it needs to start retrieving a dependency jar?)

2008-12-02T07:53:00Z

Hello again,

Talking about snapshot support...

http://www.wicketstuff.org/maven/repository/org/apache/wicket/wicket/1.4-SNAPSHOT/

I think that Buildr probably doesn't recognise the timestamped
versions but just gets the ones without the timestamp in the
version number, in this case dating from 30 June.

Does anyone know if this is indeed the current behavior, of
if there should be some existing support for the timestamp
strings in snapshots?

Best wishes,
Timo

--
Timo Rantalaiho
Reaktor Innovations Oy <URL: http://www.ri.fi/ >

Snapshot update support to Buildr? (Was: Where in the Buildr codebase does it determine that it needs to start retrieving a dependency jar?)

2008-12-01T04:30:21Z

On Fri, 28 Nov 2008, Timo Rantalaiho wrote:
> Unfortunately my ruby skills only got me so far, so it would be
> great to get some help in this
>
> https://issues.apache.org/jira/browse/BUILDR-212

I uploaded another, improved version of the patch today and
the functionality is now pretty good. The specs need still
to be written and the code cleaned up (and these would need
more Ruby expertise than what I currently have).

Is there a chance of getting this to 1.3.4?

Best wishes,
Timo

--
Timo Rantalaiho
Reaktor Innovations Oy <URL: http://www.ri.fi/ >

Re: Where in the Buildr codebase does it determine that it needs to start retrieving a dependency jar?

2008-11-27T20:07:23Z

On Thu, 27 Nov 2008, Victor Hugo Borja wrote:
> The Artifact class inherits Rake::FileCreationTask, so I guess its actions
> only get called
> if its needed? method returns true ( rake.rb:794 returns !File.exist?(name)
> )
> So if the artifact exists on your local repo, then its actions/prerequisites
> are not executed.

Cheers! This was exactly the missing piece that I needed to
get forward. Overriding FileCreationTask.needed? was the hook
I was looking for.

Unfortunately my ruby skills only got me so far, so it would be
great to get some help in this

https://issues.apache.org/jira/browse/BUILDR-212

Best wishes,
Timo

--
Timo Rantalaiho
Reaktor Innovations Oy <URL: http://www.ri.fi/ >