Mailing-List: contact users-help@buildr.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@buildr.apache.org
Received-SPF: pass (nike.apache.org: domain of alex.boisvert@gmail.com
 designates 209.85.220.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <201207220110.20969.niklaus.giger@member.fsf.org>
References: <201207220110.20969.niklaus.giger@member.fsf.org>
Date: Mon, 23 Jul 2012 09:29:27 -0700
Message-ID: 
 <CAHuk3y7BpyAMBWLNxnx87AhoL5wnEs_u=tW6sAL+NWmKZx9R+g@mail.gmail.com>
Subject: Re: RFC: Generate buildfile from Eclipse workspace
From: Alex Boisvert <alex.boisvert@gmail.com>
To: users@buildr.apache.org
Content-Type: multipart/alternative; boundary=20cf307ac81fe06a1504c581bfce

--20cf307ac81fe06a1504c581bfce
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Jul 21, 2012 at 4:10 PM, Niklaus Giger <niklaus.giger@member.fsf.org
> wrote:

> The attached patch adds a new menu choice for "buildr generate" to
> generate a
> buildfile from the eclipse projects present in the workspace.
>
> Contrary to the existing Eclipse extension it considers the existing
> Eclipse
> files to be master and trying to create a buildfile based on the extracted
> values.
>
> It needs some polishing before a final submission, but is already capable
> of
> - detecting eclipse project (which may be anywhere in a subdir)
> - project-names from eclipse .project-files override directory names
> - uses default eclipse values ('src','bin') for layout[:source,:target]
> - get the project version from MANIFEST.MF
> - adds dependencies between project
> - adds hints for all plugin
> - skips fragments (would need buildr4osgi to handle them correctly)
>

Sweet!   You may also consider using the Eclipse compiler (ECJ) by default
by adding require 'buildr/java/ecj' to the top of the generated buildfile
for consistency between buildr/eclipse builds.

There are quite a few specs (including some pendings, which reflect the
> task I
> would like to accomplish in the next few months).
>
> I would be happy if you could review the patch. I will try to improve it
> based
> on your suggestions.
>

I haven't really looked at the details so just some quick
superficial/cosmetic comments...

1) Try to be consistent with method naming following Ruby conventions
(e.g. isEclipseProjet -> is_eclipse_project?),

2) Try to use functional/non-mutating methods where possible (e.g.  string
= string.gsub(/.../) in lieu of string.sub!(/.../); especially try not to
modify any arguments passed into a method).

3) Other miscelaneous Ruby idioms:  use "unless" instead of "if
!condition", use "find" instead of "each" and returning inside the block,
etc.

But don't worry too much about these... we can help you clean up the code
once you have working code + specs!


> For me it is a first step for a to provide a simple, yet powerful way which
> should convince 'hardcore' Eclipse GUI developers that for continuos
> integration buildr.apache.org provides a simple, powerful way for
> headless,
> aka command line based builds.
>
> Attached is a generated buildfile (generated in the subdirectory src of a
> git
> clone https://github.com/zdavatz/elexis).
>
> Please let me know about necessary changes to get my patch accepted.
>


As Peter said.   And if you intend to iterate quickly in the coming weeks,
it may be simpler to open a pull request on github (with a tracking branch)
and attach the resulting work to Jira only after you're done with
development and we're done with the reviewing.    But either approaches
work fine.

alex

--20cf307ac81fe06a1504c581bfce--