From rubyforge at foemmel.com  Sun Apr  1 16:18:28 2007
From: rubyforge at foemmel.com (Matthew Foemmel)
Date: Sun, 1 Apr 2007 15:18:28 -0500
Subject: [Raven-devel] Minor 2.0 patches
In-Reply-To: <fbdc6a970703311254r81d6f0fkd1bc7e7c09bfcace@mail.gmail.com>
References: <460E99D3.3060401@herzumsoftware.com>
	<fbdc6a970703311254r81d6f0fkd1bc7e7c09bfcace@mail.gmail.com>
Message-ID: <B0AC3694-0AEE-43D0-8487-8ABD9055AB94@foemmel.com>

Hi Matthieu,

I think we should switch to svn:external. When we first set up that  
vendor brach, JRuby was a lot buggier than it is now, and I was  
thinking we'd be trying out a lot more changes locally before  
submitting them to the JRuby team. But it's pretty stable now, and as  
you say they've been quite responsive in terms of getting patches  
applied, so I think just using svn:external makes sense.

Cheers,
Foemmel

On Mar 31, 2007, at 2:54 PM, Matthieu Riou wrote:

> Hi Jesse,
>
> I've just applied your fixes, they all make sense. Thanks a lot!
>
> JRuby is imported as a vendor branch (see the vendor directory  
> under to repository root). The goal was to be able to patch the  
> sources directly if we needed to fix something, as JRuby is still  
> not quite there. However they tend to be pretty responsive and  
> apply patches almost immediately so maybe we could transition to  
> svn:external. What do you think Matthew?
>
> Cheers,
> Matthieu
>
> On 3/31/07, jbouwman <jbouwman at herzumsoftware.com> wrote:
> Hello
>
> I've seen a few small issues on trunk, and had to make the following
> changes to get it working for me:
>
> 1. In javac_task.rb, had to push @destdir onto the class_dirs  
> channel in
> order for jar task to see it.  Is this code changing? The comment  
> above
> mentions this channel, so it seemed odd that it was missing.
>
> 2. In gem_task.rb, changed the :project attribute writer to :group,
> which seems to be the code's 'mavenistic' intention.
>
> 3. Also in gem_task, changed the task name from 'gem', since it  
> collides
> with a similarly named function in JRuby 0.9.8. Not sure what the best
> name would be here.
>
> 4. in java_tasks.rb, change to ignore both ".xyz" and "xyz~" filenames
> in raven/task directories on the load path, ir order to ignore emacs
> backup files.
>
> I do think it makes sense to use an svn external to pull in jruby-- 
> I was
> surprised not to see that, on looking at the sources for the first
> time.  I've attached diff output for the above things.
>
>
> Thanks!
>
>
> Jesse
>
>
>
> Index: raven/tasks/javac_task.rb
> ===================================================================
> --- raven/tasks/javac_task.rb   (revision 182)
> +++ raven/tasks/javac_task.rb   (working copy)
> @@ -87,6 +87,7 @@
>
>          # Add compiled classes dir to classpath and class_dirs  
> channels
>          channels.classpath << @destdir
> +        channels.class_dirs << @destdir
>        end
>
>        def build_path
> Index: raven/tasks/gem_task.rb
> ===================================================================
> --- raven/tasks/gem_task.rb     (revision 182)
> +++ raven/tasks/gem_task.rb     (working copy)
> @@ -22,7 +22,7 @@
>      # project/module directory structure. Otherwise, just set the
>      # <em>artifact</em> and <em>project</em> to any value that  
> suits you.
>      class GemTask < Rake::Task
> -      attr_writer :version, :artifact, :project
> +      attr_writer :version, :artifact, :group
>
>        def execute
>          super
> @@ -60,6 +60,6 @@
>    end
> end
>
> -def gem(args, &block)
> +def makegem(args, &block)
>    Raven::Tasks::GemTask.define_task(args, &block)
> end
> \ No newline at end of file
> Index: raven/java_tasks.rb
> ===================================================================
> --- raven/java_tasks.rb (revision 182)
> +++ raven/java_tasks.rb (working copy)
> @@ -19,11 +19,16 @@
> require 'set'
> require 'raven/tasks/matching_task'
>
> +# Exclude editor tempfiles
> +def excluded_task(task_filename)
> +  task_filename[0,1] == '.' || task_filename[-1,1] == '~'
> +end
> +
> # Load all files in the "raven/tasks" directory on the load path
> ($:).each do |base|
>    if FileTest.directory ?(base + '/raven/tasks')
>      Dir.foreach(base + '/raven/tasks') do |task|
> -      require 'raven/tasks/' + task unless task[0,1] == '.'
> +      require 'raven/tasks/' + task unless excluded_task(task)
>      end
>    end
> end
>
> _______________________________________________
> Raven-devel mailing list
> Raven-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/raven-devel
>
>
> _______________________________________________
> Raven-devel mailing list
> Raven-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/raven-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/raven-devel/attachments/20070401/c5da96cc/attachment.html 

From matthieu.riou at gmail.com  Mon Apr  2 23:37:22 2007
From: matthieu.riou at gmail.com (Matthieu Riou)
Date: Mon, 2 Apr 2007 20:37:22 -0700
Subject: [Raven-devel] Quick Q on Raven deps
In-Reply-To: <4611142E.4030708@herzumsoftware.com>
References: <20070330153618.260FD5240C64@rubyforge.org>
	<fbdc6a970703300905ofc5d780l6a74f9a61f490647@mail.gmail.com>
	<460D3A24.1010602@herzumsoftware.com>
	<fbdc6a970703311257s204e0371s27d3f154b7e1dbd@mail.gmail.com>
	<4611142E.4030708@herzumsoftware.com>
Message-ID: <fbdc6a970704022037w6af7cda0h59897adf11ceffff@mail.gmail.com>

Posting in raven-devel as well. Actually I thought it was from the
beginning, just didn't pay attention.

Hi Jesse,

No real design docs no, there's only my blog post that was sort of
introducing what I intended to do. But I can get a bit more into the
details.

- The first step of having transitive dependencies working is to be able to
build gems with the dependencies imported from Maven poms. This way you can
rely on gem dependency mechanism. I've started on this and most gems are now
built properly. There may be a few bugs left as I didn't check many gems but
it looked okay. You can have a look at repo_builder.rb, you'll see how gems
are built and how the Maven poms are parsed.

- Once you have the right gems, installing the gems it depends on is quite
easy as RubyGems does the job for you. However a couple of hooks are needed
to see what gets installed by ruby gems and to have an idea of what gets
pulled by what. I've added these hooks in gem_init.rb by redefining some of
the methods of the RemoteInstaller. It's far from ideal yet but that's a
start. Then the same hooks can be used to toggle the transitive dependencies
resolution on or off and to plug some sort of conflict resolution policies.

I've just committed these modifications so you can check them out. This is a
work in progress anyway so don't hesitate to ask questions, change things
and see how it goes. By using this with your project you'll probably find
several glitches and necessary adjustments. And I'll try to help you best I
can in the process.

Cheers,
Matthieu

On 4/2/07, jbouwman <jbouwman at herzumsoftware.com> wrote:
>
> Hi Matthieu,
>
> Yes, I'd be interested in trying to help here, as this feature would be
> important for a project I'm working on. I bet it would be a good
> candidate, since it's a large but reasonably well segmented component
> system--where, for instance, there's component that uses Hibernate,
> another that uses lots of quartz and calendars, etc.  Do you have any
> recommended starting points or design docs floating around?
>
> Best Regards
> Jesse Bouwman
>
> Matthieu Riou wrote:
> > Hi Jesse,
> >
> > I've started working on transitive dependencies but I've been pulled a
> > bit
> > to other stuff and haven't been able to work on it as much as I would
> > like.
> > But I'll have to get back to it soon. Would you be interested in
> > helping out
> > and contributing on this subject?
> >
> > Thanks,
> > Matthieu
> >
> > On 3/30/07, jbouwman <jbouwman at herzumsoftware.com> wrote:
> >>
> >> Super!--thanks for answering my questions so quickly--I'll build jruby.
> >> To that -- I see a vendor dir in SVN--are you periodically syncing
> jruby
> >> sources?  I'll peek at the devel list.
> >>
> >> I read a blog posting of yours on transitive dependencies, curious to
> >> know if you (or someone else) has been actively pursuing this.  Ivy's
> >> strategy is ..I think I'm getting this right.. to allow you to select a
> >> strategy to converge the versions of common root dependencies
> >> (xerces...), either by interpreting version sequences, or by pinning
> >> versions.  So you provide the minimum amount of information required to
> >> produce an unambiguous, conflict-free closure. Something like that
> >> anyways.
> >>
> >> Thanks again,
> >>
> >> Jesse
> >>
> >>
> >>
> >> Matthieu Riou wrote:
> >> > Hi Jesse,
> >> >
> >> > Raven's trunk is the future Raven 2.0 and yes, it requires JRuby.
> >> > However I
> >> > wouldn't recommend it for direct usage quite yet, it's still under
> >> > development and could break anytime.
> >> >
> >> > On the other hand the 1.x branch is more stable and doesn't require
> >> > JRuby.
> >> > You can just checkout:
> >> >
> >> > svn://rubyforge.org/var/svn/raven/branches/v1.x
> >> >
> >> > There's also a gem for easy install but I guess you're looking for
> the
> >> > source branch to hack around. Just try to contribute back your hacks
> >> > if some
> >> > of them can be useful to other ;)
> >> >
> >> > Cheers,
> >> > Matthieu
> >> >
> >> > On 3/30/07, Jesse Bouwman <jbouwman at herzumsoftware.com> wrote:
> >> >>
> >> >> Hi there,
> >> >>
> >> >>
> >> >>
> >> >> Been using raven 1.2.2 -- love it, thanks very much.
> >> >>
> >> >>
> >> >>
> >> >> Does raven's 'trunk' require running under jruby?  I see the first
> >> >> require
> >> >> line is 'java'.  Is trunk where I should be hacking around?
> >> >>
> >> >>
> >> >>
> >> >> Been using ant+ivy for build mgmt, very much would like to use
> >> something
> >> >> like raven as a replacement.  Accidentally looked at maven again
> last
> >> >> week... truly appalling.
> >> >>
> >> >>
> >> >>
> >> >> Best regards,
> >> >>
> >> >>
> >> >>
> >> >> Jesse
> >> >>
> >> >
> >>
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/raven-devel/attachments/20070402/98eb9422/attachment.html 

From nobody at rubyforge.org  Tue Apr  3 00:01:59 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Tue,  3 Apr 2007 00:01:59 -0400 (EDT)
Subject: [Raven-devel] [185] trunk/lib/raven: Transitive gems generation and
	a first step to transitive installs with RubyGems.
Message-ID: <20070403040159.CA0385240CD6@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/raven-devel/attachments/20070403/01b0c79f/attachment-0001.html 

From jbouwman at herzumsoftware.com  Tue Apr  3 18:07:13 2007
From: jbouwman at herzumsoftware.com (jbouwman)
Date: Tue, 03 Apr 2007 17:07:13 -0500
Subject: [Raven-devel] Some renaming [was: Re: Quick Q on Raven deps]
In-Reply-To: <fbdc6a970704022037w6af7cda0h59897adf11ceffff@mail.gmail.com>
References: <20070330153618.260FD5240C64@rubyforge.org>	
	<fbdc6a970703300905ofc5d780l6a74f9a61f490647@mail.gmail.com>	
	<460D3A24.1010602@herzumsoftware.com>	
	<fbdc6a970703311257s204e0371s27d3f154b7e1dbd@mail.gmail.com>	
	<4611142E.4030708@herzumsoftware.com>
	<fbdc6a970704022037w6af7cda0h59897adf11ceffff@mail.gmail.com>
Message-ID: <4612D011.60401@herzumsoftware.com>

Hi Matthieu,

A few initial questions on naming:

1. Could we perhaps rename the tests in raven/trunk/test to test_*.rb,
in line with rake's convention? Trying to keep in touch with what I
might be breaking.
2. Change maven_crap.rb to maven_repo (and eventually maven_pom.rb) to
keep clear the types of maven objects that we interact with.

Sort of a different question is, do you expect the 1...1 jar to gem
mapping to be stable?  More specifically, I'm curious about what the
addition of PLATFORM=java type to the Gem package implies, other than
constituent jars appearing under 'ext.'   I certainly realize that this
might not be settled yet. I'm thinking of 'wars' and 'ears' and other
complex 'payload types' that might appear

Cheers,
Jesse Bouwman


Matthieu Riou wrote:
> Posting in raven-devel as well. Actually I thought it was from the
> beginning, just didn't pay attention.


From matthieu.riou at gmail.com  Tue Apr  3 19:48:03 2007
From: matthieu.riou at gmail.com (Matthieu Riou)
Date: Tue, 3 Apr 2007 16:48:03 -0700
Subject: [Raven-devel] Some renaming [was: Re: Quick Q on Raven deps]
In-Reply-To: <4612D011.60401@herzumsoftware.com>
References: <20070330153618.260FD5240C64@rubyforge.org>
	<fbdc6a970703300905ofc5d780l6a74f9a61f490647@mail.gmail.com>
	<460D3A24.1010602@herzumsoftware.com>
	<fbdc6a970703311257s204e0371s27d3f154b7e1dbd@mail.gmail.com>
	<4611142E.4030708@herzumsoftware.com>
	<fbdc6a970704022037w6af7cda0h59897adf11ceffff@mail.gmail.com>
	<4612D011.60401@herzumsoftware.com>
Message-ID: <fbdc6a970704031648l2b06f070lbc205bf0bc87d131@mail.gmail.com>

> 1. Could we perhaps rename the tests in raven/trunk/test to test_*.rb,
> in line with rake's convention? Trying to keep in touch with what I
> might be breaking.


Wasn't aware of such a convention but if there is, so be it. Matthew any
objection?

2. Change maven_crap.rb to maven_repo (and eventually maven_pom.rb) to
> keep clear the types of maven objects that we interact with.


Yeah, good idea. I've named it that way on a bad day, after a lot of
Maven-induced pain but I guess these names would be better.

Sort of a different question is, do you expect the 1...1 jar to gem
> mapping to be stable?  More specifically, I'm curious about what the
> addition of PLATFORM=java type to the Gem package implies, other than
> constituent jars appearing under 'ext.'   I certainly realize that this
> might not be settled yet. I'm thinking of 'wars' and 'ears' and other
> complex 'payload types' that might appear


No I don't really expect it to stay as a 1-1 mapping forever. For now it's
the easiest way but if Raven works well enough, it would be much nicer if
projects started packaging their gems themselves in a more intelligent
manner. For examples projects with multiple jars (i.e. XDoclet, Spring)
could include several jars in the same gem. Wars and ears are also good
examples.

Cheers,
Matthieu

Cheers,
> Jesse Bouwman
>
>
> Matthieu Riou wrote:
> > Posting in raven-devel as well. Actually I thought it was from the
> > beginning, just didn't pay attention.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/raven-devel/attachments/20070403/3a7e3b98/attachment.html 

From jbouwman at herzumsoftware.com  Wed Apr  4 16:19:58 2007
From: jbouwman at herzumsoftware.com (jbouwman)
Date: Wed, 04 Apr 2007 15:19:58 -0500
Subject: [Raven-devel] Repository converter updates
Message-ID: <4614086E.6070508@herzumsoftware.com>

Hello,

I've run the M2 repository converter a few times now and it works pretty
well, crashing out occasionally on unresolvable entities in poms.  My
local version now looks at the pom file in order to pick out groupId,
artifactId, and so on, instead of deriving these from the filesystem
path.  Next thing is to pull out the deps.

Attached are a patch for 'maven_crap.rb', as well as a new file
'maven_pom.rb' for that.  I see a bunch of warnings on the console as
the "pom dom" gets built, so I have a feeling I might be failing to do
some kind of package initialization?

Cheers
Jesse Bouwman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: maven_crap.patch
Type: text/x-patch
Size: 13533 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/raven-devel/attachments/20070404/e561b51c/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: maven_pom.rb
Type: application/x-ruby
Size: 1327 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/raven-devel/attachments/20070404/e561b51c/attachment-0001.bin 

From nobody at rubyforge.org  Wed Apr  4 21:33:58 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Wed,  4 Apr 2007 21:33:58 -0400 (EDT)
Subject: [Raven-devel] [186] trunk/lib: Applying patch submitted by Jesse
	Bouwman.
Message-ID: <20070405013358.E25BB5240C21@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/raven-devel/attachments/20070404/62c0c18f/attachment-0001.html 

From nobody at rubyforge.org  Wed Apr  4 21:34:57 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Wed,  4 Apr 2007 21:34:57 -0400 (EDT)
Subject: [Raven-devel] [187] trunk/lib/raven: Renaming maven_crap.rb for a
	more suitable (well, say descriptive) name.
Message-ID: <20070405013457.E10B8524099D@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/raven-devel/attachments/20070404/d59a4690/attachment-0001.html 

From matthieu.riou at gmail.com  Wed Apr  4 21:38:21 2007
From: matthieu.riou at gmail.com (Matthieu Riou)
Date: Wed, 4 Apr 2007 18:38:21 -0700
Subject: [Raven-devel] Repository converter updates
In-Reply-To: <4614086E.6070508@herzumsoftware.com>
References: <4614086E.6070508@herzumsoftware.com>
Message-ID: <fbdc6a970704041838y63bc6300s34fc03001c2a3dce@mail.gmail.com>

Hi Jesse,

I've just applied your patch, thanks! Actually if Matthew is okay with it
I'd be more than happy to grant you commit rights. Matthew?

The warnings probably come from the poms. Sometimes they're missing or even
malformed XML (wtf?!). You just need to make sure the well-formed ones that
include dependencies have been correctly processed and that the produced
gems have the corresponding dependencies.

Cheers,
Matthieu

On 4/4/07, jbouwman <jbouwman at herzumsoftware.com> wrote:
>
> Hello,
>
> I've run the M2 repository converter a few times now and it works pretty
> well, crashing out occasionally on unresolvable entities in poms.  My
> local version now looks at the pom file in order to pick out groupId,
> artifactId, and so on, instead of deriving these from the filesystem
> path.  Next thing is to pull out the deps.
>
> Attached are a patch for 'maven_crap.rb', as well as a new file
> 'maven_pom.rb' for that.  I see a bunch of warnings on the console as
> the "pom dom" gets built, so I have a feeling I might be failing to do
> some kind of package initialization?
>
> Cheers
> Jesse Bouwman
>
> _______________________________________________
> Raven-devel mailing list
> Raven-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/raven-devel
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/raven-devel/attachments/20070404/84979512/attachment.html 

From behmannlist at gmail.com  Thu Apr  5 14:47:33 2007
From: behmannlist at gmail.com (Brian Ehmann)
Date: Thu, 5 Apr 2007 14:47:33 -0400
Subject: [Raven-devel] Building and Using Raven 2.0
Message-ID: <249F0874-0ACF-4260-9BB6-0094C352BEFC@gmail.com>

Hello Everyone,

Earlier today I joined the Raven-Devel mailing list so forgive me if  
this is a duplicate/dumb question.

1) I checked out the source tree and added raven/trunk/vendor/jruby/ 
bin to my path so that all ruby commands would be run off of this  
version. (no other version of ruby is on the path)
2) I built (using the included ant build file) jruby and installed  
the gems rake and antwrap
3) Next I built the raven gem with the command "rake gem" and  
installed the resulting raven-2.0.gem file into jruby (with "gem  
install raven-2.0.gem")
4) Finally I attempted to compile a simple project that compiled  
properly with raven-1.2.2 however I am receiving the following  
exception:

========= start error ===========
% rake compile
(in /Users/behmann/src/opensource/river)
/Users/behmann/src/opensource/raven/trunk/vendor/jruby/lib/ruby/gems/ 
1.8/gems/raven-2.0/lib/raven/gem_init.rb:107:Warning: require_gem is  
obsolete.  Use gem instead.
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/ 
tools/ant/launch/AntMain
========= end error ===========

Did I miss a step or should I download and add the jar which contains  
this class to my classpath?  I would very much like to help port  
functionality from ANT to Raven but I'm confused as to why I can not  
create a functional gem.

Thanks for your help,

- Brian Ehmann

From jbouwman at herzumsoftware.com  Thu Apr  5 15:10:49 2007
From: jbouwman at herzumsoftware.com (jbouwman)
Date: Thu, 05 Apr 2007 14:10:49 -0500
Subject: [Raven-devel] Building and Using Raven 2.0
In-Reply-To: <249F0874-0ACF-4260-9BB6-0094C352BEFC@gmail.com>
References: <249F0874-0ACF-4260-9BB6-0094C352BEFC@gmail.com>
Message-ID: <461549B9.6030503@herzumsoftware.com>

Hi Brian,

I've found it useful to put Ant into the CLASSPATH environment variable,
something like:

    LOCAL_LIB=/usr/local/lib/java
    COMPILER_CP=$LOCAL_LIB/jdk1.5.0/lib/tools.jar
    ANT_CP=$LOCAL_LIB/apache-ant-1.6.5/lib/ant.jar:$LOCAL_LIB/apache-ant-1.6.5/lib/ant-launcher.jar
    export CLASSPATH=$COMPILER_CP:$ANT_CP


This seem to do it.  I'm quite new to jruby, so I inferred this from
looking at trunk/test/run. Some of the load path semantics are still a
little hazy...hope this helps?

Regards,
Jesse

Brian Ehmann wrote:
> Hello Everyone,
>
> Earlier today I joined the Raven-Devel mailing list so forgive me if  
> this is a duplicate/dumb question.
>
> 1) I checked out the source tree and added raven/trunk/vendor/jruby/ 
> bin to my path so that all ruby commands would be run off of this  
> version. (no other version of ruby is on the path)
> 2) I built (using the included ant build file) jruby and installed  
> the gems rake and antwrap
> 3) Next I built the raven gem with the command "rake gem" and  
> installed the resulting raven-2.0.gem file into jruby (with "gem  
> install raven-2.0.gem")
> 4) Finally I attempted to compile a simple project that compiled  
> properly with raven-1.2.2 however I am receiving the following  
> exception:
>
> ========= start error ===========
> % rake compile
> (in /Users/behmann/src/opensource/river)
> /Users/behmann/src/opensource/raven/trunk/vendor/jruby/lib/ruby/gems/ 
> 1.8/gems/raven-2.0/lib/raven/gem_init.rb:107:Warning: require_gem is  
> obsolete.  Use gem instead.
> Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/ 
> tools/ant/launch/AntMain
> ========= end error ===========
>
> Did I miss a step or should I download and add the jar which contains  
> this class to my classpath?  I would very much like to help port  
> functionality from ANT to Raven but I'm confused as to why I can not  
> create a functional gem.
>
> Thanks for your help,
>
> - Brian Ehmann
> _______________________________________________
> Raven-devel mailing list
> Raven-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/raven-devel
>   


From behmannlist at gmail.com  Thu Apr  5 16:46:59 2007
From: behmannlist at gmail.com (Brian Ehmann)
Date: Thu, 5 Apr 2007 16:46:59 -0400
Subject: [Raven-devel] Building and Using Raven 2.0
In-Reply-To: <461549B9.6030503@herzumsoftware.com>
References: <249F0874-0ACF-4260-9BB6-0094C352BEFC@gmail.com>
	<461549B9.6030503@herzumsoftware.com>
Message-ID: <8BABEBF9-8E28-4976-88E9-790D3FAB04AD@gmail.com>

Thanks Jesse, that was it.

Ok, another noob question. (forgive me)

Way the hell back in revision 49 the libs=(l) method was removed from  
the DependencyTask class in deps_tasks.rb.  As a result, the  
following, although documented in the rdoc, fails with an undefined  
method exception for libs=

dependency 'compile_deps' do |t|
     t.libs = Dir.glob('lib/**/*.jar')
end

If the libs= method is returned everything works as expected.  Was  
this method removal intended?  Is the "gem" way of using jars  
expected to be the only way of adding dependencies?

- Brian

On Apr 5, 2007, at 3:10 PM, jbouwman wrote:

> Hi Brian,
>
> I've found it useful to put Ant into the CLASSPATH environment  
> variable,
> something like:
>
>     LOCAL_LIB=/usr/local/lib/java
>     COMPILER_CP=$LOCAL_LIB/jdk1.5.0/lib/tools.jar
>     ANT_CP=$LOCAL_LIB/apache-ant-1.6.5/lib/ant.jar:$LOCAL_LIB/ 
> apache-ant-1.6.5/lib/ant-launcher.jar
>     export CLASSPATH=$COMPILER_CP:$ANT_CP
>
>
> This seem to do it.  I'm quite new to jruby, so I inferred this from
> looking at trunk/test/run. Some of the load path semantics are still a
> little hazy...hope this helps?
>
> Regards,
> Jesse
>
> Brian Ehmann wrote:
>> Hello Everyone,
>>
>> Earlier today I joined the Raven-Devel mailing list so forgive me if
>> this is a duplicate/dumb question.
>>
>> 1) I checked out the source tree and added raven/trunk/vendor/jruby/
>> bin to my path so that all ruby commands would be run off of this
>> version. (no other version of ruby is on the path)
>> 2) I built (using the included ant build file) jruby and installed
>> the gems rake and antwrap
>> 3) Next I built the raven gem with the command "rake gem" and
>> installed the resulting raven-2.0.gem file into jruby (with "gem
>> install raven-2.0.gem")
>> 4) Finally I attempted to compile a simple project that compiled
>> properly with raven-1.2.2 however I am receiving the following
>> exception:
>>
>> ========= start error ===========
>> % rake compile
>> (in /Users/behmann/src/opensource/river)
>> /Users/behmann/src/opensource/raven/trunk/vendor/jruby/lib/ruby/gems/
>> 1.8/gems/raven-2.0/lib/raven/gem_init.rb:107:Warning: require_gem is
>> obsolete.  Use gem instead.
>> Exception in thread "main" java.lang.NoClassDefFoundError: org/ 
>> apache/
>> tools/ant/launch/AntMain
>> ========= end error ===========
>>
>> Did I miss a step or should I download and add the jar which contains
>> this class to my classpath?  I would very much like to help port
>> functionality from ANT to Raven but I'm confused as to why I can not
>> create a functional gem.
>>
>> Thanks for your help,
>>
>> - Brian Ehmann
>> _______________________________________________
>> Raven-devel mailing list
>> Raven-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/raven-devel
>>
>


From jbouwman at herzumsoftware.com  Thu Apr  5 17:01:02 2007
From: jbouwman at herzumsoftware.com (Jesse Bouwman)
Date: Thu, 05 Apr 2007 16:01:02 -0500
Subject: [Raven-devel] Building and Using Raven 2.0
In-Reply-To: <8BABEBF9-8E28-4976-88E9-790D3FAB04AD@gmail.com>
References: <249F0874-0ACF-4260-9BB6-0094C352BEFC@gmail.com>	<461549B9.6030503@herzumsoftware.com>
	<8BABEBF9-8E28-4976-88E9-790D3FAB04AD@gmail.com>
Message-ID: <4615638E.1070109@herzumsoftware.com>

Hi Brian,

I don't know enough about that code to be sure, but I suspect that the
method removal was unintentional, so I suggest you restore it and send
the patch to this list

I have been working on dependencies for, oh, about a day now, and I'm
inclined to think that they should be addable both locally and
repository resolution.  I'm doing a few things with maven interaction
right now  (import, transitivity), and have been on this list for about
a week, but I'll do the best I can with any other questions you have?

Regards
Jesse Bouwman

Brian Ehmann wrote:
> Thanks Jesse, that was it.
>
> Ok, another noob question. (forgive me)
>
> Way the hell back in revision 49 the libs=(l) method was removed from  
> the DependencyTask class in deps_tasks.rb.  As a result, the  
> following, although documented in the rdoc, fails with an undefined  
> method exception for libs=
>
> dependency 'compile_deps' do |t|
>      t.libs = Dir.glob('lib/**/*.jar')
> end
>
> If the libs= method is returned everything works as expected.  Was  
> this method removal intended?  Is the "gem" way of using jars  
> expected to be the only way of adding dependencies?
>
> - Brian
>
> On Apr 5, 2007, at 3:10 PM, jbouwman wrote:
>
>   
>> Hi Brian,
>>
>> I've found it useful to put Ant into the CLASSPATH environment  
>> variable,
>> something like:
>>
>>     LOCAL_LIB=/usr/local/lib/java
>>     COMPILER_CP=$LOCAL_LIB/jdk1.5.0/lib/tools.jar
>>     ANT_CP=$LOCAL_LIB/apache-ant-1.6.5/lib/ant.jar:$LOCAL_LIB/ 
>> apache-ant-1.6.5/lib/ant-launcher.jar
>>     export CLASSPATH=$COMPILER_CP:$ANT_CP
>>
>>
>> This seem to do it.  I'm quite new to jruby, so I inferred this from
>> looking at trunk/test/run. Some of the load path semantics are still a
>> little hazy...hope this helps?
>>
>> Regards,
>> Jesse
>>
>> Brian Ehmann wrote:
>>     
>>> Hello Everyone,
>>>
>>> Earlier today I joined the Raven-Devel mailing list so forgive me if
>>> this is a duplicate/dumb question.
>>>
>>> 1) I checked out the source tree and added raven/trunk/vendor/jruby/
>>> bin to my path so that all ruby commands would be run off of this
>>> version. (no other version of ruby is on the path)
>>> 2) I built (using the included ant build file) jruby and installed
>>> the gems rake and antwrap
>>> 3) Next I built the raven gem with the command "rake gem" and
>>> installed the resulting raven-2.0.gem file into jruby (with "gem
>>> install raven-2.0.gem")
>>> 4) Finally I attempted to compile a simple project that compiled
>>> properly with raven-1.2.2 however I am receiving the following
>>> exception:
>>>
>>> ========= start error ===========
>>> % rake compile
>>> (in /Users/behmann/src/opensource/river)
>>> /Users/behmann/src/opensource/raven/trunk/vendor/jruby/lib/ruby/gems/
>>> 1.8/gems/raven-2.0/lib/raven/gem_init.rb:107:Warning: require_gem is
>>> obsolete.  Use gem instead.
>>> Exception in thread "main" java.lang.NoClassDefFoundError: org/ 
>>> apache/
>>> tools/ant/launch/AntMain
>>> ========= end error ===========
>>>
>>> Did I miss a step or should I download and add the jar which contains
>>> this class to my classpath?  I would very much like to help port
>>> functionality from ANT to Raven but I'm confused as to why I can not
>>> create a functional gem.
>>>
>>> Thanks for your help,
>>>
>>> - Brian Ehmann
>>> _______________________________________________
>>> Raven-devel mailing list
>>> Raven-devel at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/raven-devel
>>>
>>>       
>
> _______________________________________________
> Raven-devel mailing list
> Raven-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/raven-devel
>   


From matthieu.riou at gmail.com  Thu Apr  5 17:03:10 2007
From: matthieu.riou at gmail.com (Matthieu Riou)
Date: Thu, 5 Apr 2007 14:03:10 -0700
Subject: [Raven-devel] Building and Using Raven 2.0
In-Reply-To: <8BABEBF9-8E28-4976-88E9-790D3FAB04AD@gmail.com>
References: <249F0874-0ACF-4260-9BB6-0094C352BEFC@gmail.com>
	<461549B9.6030503@herzumsoftware.com>
	<8BABEBF9-8E28-4976-88E9-790D3FAB04AD@gmail.com>
Message-ID: <fbdc6a970704051403jf5e6156h263d4d15dc3aa802@mail.gmail.com>

Hi Brian,

Actually the libs method has been changed to return an array, just like for
deps, instead of being a direct accessor. This gives you more freedom on the
way you can add libraries. For example you can do any of these:

t.libs << 'lib/ant.jar'
t.libs << ['lib/ant.jar', 'lib/xerces.jar']    (the libs array is flattened)
t.libs[1] = 'lib/ant.jar'
....

Sorry for the breakage, the 2.0 release is probably going to be a bit
disruptive for 1.x users but I'll try to come up with some basic migration
instructions at that time.

Cheers,
Matthieu

On 4/5/07, Brian Ehmann <behmannlist at gmail.com> wrote:
>
> Thanks Jesse, that was it.
>
> Ok, another noob question. (forgive me)
>
> Way the hell back in revision 49 the libs=(l) method was removed from
> the DependencyTask class in deps_tasks.rb.  As a result, the
> following, although documented in the rdoc, fails with an undefined
> method exception for libs=
>
> dependency 'compile_deps' do |t|
>      t.libs = Dir.glob('lib/**/*.jar')
> end
>
> If the libs= method is returned everything works as expected.  Was
> this method removal intended?  Is the "gem" way of using jars
> expected to be the only way of adding dependencies?
>
> - Brian
>
> On Apr 5, 2007, at 3:10 PM, jbouwman wrote:
>
> > Hi Brian,
> >
> > I've found it useful to put Ant into the CLASSPATH environment
> > variable,
> > something like:
> >
> >     LOCAL_LIB=/usr/local/lib/java
> >     COMPILER_CP=$LOCAL_LIB/jdk1.5.0/lib/tools.jar
> >     ANT_CP=$LOCAL_LIB/apache-ant-1.6.5/lib/ant.jar:$LOCAL_LIB/
> > apache-ant-1.6.5/lib/ant-launcher.jar
> >     export CLASSPATH=$COMPILER_CP:$ANT_CP
> >
> >
> > This seem to do it.  I'm quite new to jruby, so I inferred this from
> > looking at trunk/test/run. Some of the load path semantics are still a
> > little hazy...hope this helps?
> >
> > Regards,
> > Jesse
> >
> > Brian Ehmann wrote:
> >> Hello Everyone,
> >>
> >> Earlier today I joined the Raven-Devel mailing list so forgive me if
> >> this is a duplicate/dumb question.
> >>
> >> 1) I checked out the source tree and added raven/trunk/vendor/jruby/
> >> bin to my path so that all ruby commands would be run off of this
> >> version. (no other version of ruby is on the path)
> >> 2) I built (using the included ant build file) jruby and installed
> >> the gems rake and antwrap
> >> 3) Next I built the raven gem with the command "rake gem" and
> >> installed the resulting raven-2.0.gem file into jruby (with "gem
> >> install raven-2.0.gem")
> >> 4) Finally I attempted to compile a simple project that compiled
> >> properly with raven-1.2.2 however I am receiving the following
> >> exception:
> >>
> >> ========= start error ===========
> >> % rake compile
> >> (in /Users/behmann/src/opensource/river)
> >> /Users/behmann/src/opensource/raven/trunk/vendor/jruby/lib/ruby/gems/
> >> 1.8/gems/raven-2.0/lib/raven/gem_init.rb:107:Warning: require_gem is
> >> obsolete.  Use gem instead.
> >> Exception in thread "main" java.lang.NoClassDefFoundError: org/
> >> apache/
> >> tools/ant/launch/AntMain
> >> ========= end error ===========
> >>
> >> Did I miss a step or should I download and add the jar which contains
> >> this class to my classpath?  I would very much like to help port
> >> functionality from ANT to Raven but I'm confused as to why I can not
> >> create a functional gem.
> >>
> >> Thanks for your help,
> >>
> >> - Brian Ehmann
> >> _______________________________________________
> >> Raven-devel mailing list
> >> Raven-devel at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/raven-devel
> >>
> >
>
> _______________________________________________
> Raven-devel mailing list
> Raven-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/raven-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/raven-devel/attachments/20070405/bfbf7769/attachment-0001.html 

From behmannlist at gmail.com  Thu Apr  5 21:41:06 2007
From: behmannlist at gmail.com (Brian Ehmann)
Date: Thu, 5 Apr 2007 21:41:06 -0400
Subject: [Raven-devel] PATCH: JavacTask
In-Reply-To: <fbdc6a970704051403jf5e6156h263d4d15dc3aa802@mail.gmail.com>
References: <249F0874-0ACF-4260-9BB6-0094C352BEFC@gmail.com>
	<461549B9.6030503@herzumsoftware.com>
	<8BABEBF9-8E28-4976-88E9-790D3FAB04AD@gmail.com>
	<fbdc6a970704051403jf5e6156h263d4d15dc3aa802@mail.gmail.com>
Message-ID: <4A8EE7FD-F4FD-43D1-814B-8C323291F753@gmail.com>

t.libs << [Dir.glob('lib/**/*.jar')]

Cool, that works....

Ok, first patch.  I'm still figuring out the code, so it's not one of  
the open issues.  Instead it's a "it works like this in ANT" patch.   
Changes are:

1) added a :dest_dir symbol to attr_accessor in the javac task so the  
user can specify the name of their compiled output dir
2) changed require_gem to simply gem on line 104 of gem_init.rb so  
that the annoying "Warning: require_gem is obsolete" message goes away.

Hope you like it.

- Brian

PS.  One other thing... When running the test "run" script, it fails  
on the all_tests.rb "require 'leafcutter.jar'" statement since the  
leafcutter.jar file is not in the same directory.  Once the  
leafcutter.jar file was relocated to the same test directory the  
tests ran without issue.  Is this the desired resolution?

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: JavacDestDir_patch.txt
Url: http://rubyforge.org/pipermail/raven-devel/attachments/20070405/80995fd9/attachment.txt 
-------------- next part --------------


On Apr 5, 2007, at 5:03 PM, Matthieu Riou wrote:

> Hi Brian,
>
> Actually the libs method has been changed to return an array, just  
> like for deps, instead of being a direct accessor. This gives you  
> more freedom on the way you can add libraries. For example you can  
> do any of these:
>
> t.libs << 'lib/ant.jar'
> t.libs << ['lib/ant.jar', 'lib/xerces.jar']    (the libs array is  
> flattened)
> t.libs[1] = 'lib/ant.jar'
> ....
>
> Sorry for the breakage, the 2.0 release is probably going to be a  
> bit disruptive for 1.x users but I'll try to come up with some  
> basic migration instructions at that time.
>
> Cheers,
> Matthieu
>


From rubyforge at foemmel.com  Fri Apr  6 15:22:52 2007
From: rubyforge at foemmel.com (Matthew Foemmel)
Date: Fri, 6 Apr 2007 14:22:52 -0500
Subject: [Raven-devel] Some renaming [was: Re: Quick Q on Raven deps]
In-Reply-To: <fbdc6a970704031648l2b06f070lbc205bf0bc87d131@mail.gmail.com>
References: <20070330153618.260FD5240C64@rubyforge.org>
	<fbdc6a970703300905ofc5d780l6a74f9a61f490647@mail.gmail.com>
	<460D3A24.1010602@herzumsoftware.com>
	<fbdc6a970703311257s204e0371s27d3f154b7e1dbd@mail.gmail.com>
	<4611142E.4030708@herzumsoftware.com>
	<fbdc6a970704022037w6af7cda0h59897adf11ceffff@mail.gmail.com>
	<4612D011.60401@herzumsoftware.com>
	<fbdc6a970704031648l2b06f070lbc205bf0bc87d131@mail.gmail.com>
Message-ID: <0D2F2EE7-E29E-4B40-AE83-0032352D0D18@foemmel.com>

I'm definitely OK with renaming the tests to make them more standard.

On Apr 3, 2007, at 6:48 PM, Matthieu Riou wrote:

>
> 1. Could we perhaps rename the tests in raven/trunk/test to test_*.rb,
> in line with rake's convention? Trying to keep in touch with what I
> might be breaking.
>
> Wasn't aware of such a convention but if there is, so be it.  
> Matthew any objection?
>
> 2. Change maven_crap.rb to maven_repo (and eventually maven_pom.rb) to
> keep clear the types of maven objects that we interact with.
>
> Yeah, good idea. I've named it that way on a bad day, after a lot  
> of Maven-induced pain but I guess these names would be better.
>
> Sort of a different question is, do you expect the 1...1 jar to gem
> mapping to be stable?  More specifically, I'm curious about what the
> addition of PLATFORM=java type to the Gem package implies, other than
> constituent jars appearing under 'ext.'   I certainly realize that  
> this
> might not be settled yet. I'm thinking of 'wars' and 'ears' and other
> complex 'payload types' that might appear
>
> No I don't really expect it to stay as a 1-1 mapping forever. For  
> now it's the easiest way but if Raven works well enough, it would  
> be much nicer if projects started packaging their gems themselves  
> in a more intelligent manner. For examples projects with multiple  
> jars ( i.e. XDoclet, Spring) could include several jars in the same  
> gem. Wars and ears are also good examples.
>
> Cheers,
> Matthieu
>
> Cheers,
> Jesse Bouwman
>
>
> Matthieu Riou wrote:
> > Posting in raven-devel as well. Actually I thought it was from the
> > beginning, just didn't pay attention.
>
>
> _______________________________________________
> Raven-devel mailing list
> Raven-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/raven-devel


From rubyforge at foemmel.com  Fri Apr  6 16:07:44 2007
From: rubyforge at foemmel.com (Matthew Foemmel)
Date: Fri, 6 Apr 2007 15:07:44 -0500
Subject: [Raven-devel] Repository converter updates
In-Reply-To: <fbdc6a970704041838y63bc6300s34fc03001c2a3dce@mail.gmail.com>
References: <4614086E.6070508@herzumsoftware.com>
	<fbdc6a970704041838y63bc6300s34fc03001c2a3dce@mail.gmail.com>
Message-ID: <8F955B59-79F6-40C2-A728-6217610CE704@foemmel.com>

+1 on making Jesse a commiter. Welcome!

On Apr 4, 2007, at 8:38 PM, Matthieu Riou wrote:

> Hi Jesse,
>
> I've just applied your patch, thanks! Actually if Matthew is okay  
> with it I'd be more than happy to grant you commit rights. Matthew?
>
> The warnings probably come from the poms. Sometimes they're missing  
> or even malformed XML (wtf?!). You just need to make sure the well- 
> formed ones that include dependencies have been correctly processed  
> and that the produced gems have the corresponding dependencies.
>
> Cheers,
> Matthieu
>
> On 4/4/07, jbouwman <jbouwman at herzumsoftware.com> wrote:
> Hello,
>
> I've run the M2 repository converter a few times now and it works  
> pretty
> well, crashing out occasionally on unresolvable entities in poms.  My
> local version now looks at the pom file in order to pick out groupId,
> artifactId, and so on, instead of deriving these from the filesystem
> path.  Next thing is to pull out the deps.
>
> Attached are a patch for 'maven_crap.rb', as well as a new file
> 'maven_pom.rb' for that.  I see a bunch of warnings on the console as
> the "pom dom" gets built, so I have a feeling I might be failing to do
> some kind of package initialization?
>
> Cheers
> Jesse Bouwman
>
> _______________________________________________
> Raven-devel mailing list
> Raven-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/raven-devel
>
>
>
> _______________________________________________
> Raven-devel mailing list
> Raven-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/raven-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/raven-devel/attachments/20070406/b11a4987/attachment.html 

From matthieu.riou at gmail.com  Fri Apr  6 16:17:37 2007
From: matthieu.riou at gmail.com (Matthieu Riou)
Date: Fri, 6 Apr 2007 13:17:37 -0700
Subject: [Raven-devel] Repository converter updates
In-Reply-To: <8F955B59-79F6-40C2-A728-6217610CE704@foemmel.com>
References: <4614086E.6070508@herzumsoftware.com>
	<fbdc6a970704041838y63bc6300s34fc03001c2a3dce@mail.gmail.com>
	<8F955B59-79F6-40C2-A728-6217610CE704@foemmel.com>
Message-ID: <fbdc6a970704061317o2e1998d7ld60efe52f3057caf@mail.gmail.com>

Perfect! Do you have Rubyforge account Jesse, so I can add you on the
project?

On 4/6/07, Matthew Foemmel <rubyforge at foemmel.com> wrote:
>
> +1 on making Jesse a commiter. Welcome!
> On Apr 4, 2007, at 8:38 PM, Matthieu Riou wrote:
>
> Hi Jesse,
>
> I've just applied your patch, thanks! Actually if Matthew is okay with it
> I'd be more than happy to grant you commit rights. Matthew?
>
> The warnings probably come from the poms. Sometimes they're missing or
> even malformed XML (wtf?!). You just need to make sure the well-formed ones
> that include dependencies have been correctly processed and that the
> produced gems have the corresponding dependencies.
>
> Cheers,
> Matthieu
>
> On 4/4/07, jbouwman <jbouwman at herzumsoftware.com> wrote:
> >
> > Hello,
> >
> > I've run the M2 repository converter a few times now and it works pretty
> > well, crashing out occasionally on unresolvable entities in poms.  My
> > local version now looks at the pom file in order to pick out groupId,
> > artifactId, and so on, instead of deriving these from the filesystem
> > path.  Next thing is to pull out the deps.
> >
> > Attached are a patch for 'maven_crap.rb', as well as a new file
> > 'maven_pom.rb' for that.  I see a bunch of warnings on the console as
> > the "pom dom" gets built, so I have a feeling I might be failing to do
> > some kind of package initialization?
> >
> > Cheers
> > Jesse Bouwman
> >
> > _______________________________________________
> > Raven-devel mailing list
> > Raven-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/raven-devel
> >
> >
> >
> _______________________________________________
> Raven-devel mailing list
> Raven-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/raven-devel
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/raven-devel/attachments/20070406/ceb92f76/attachment.html 

From caleb.powell at gmail.com  Fri Apr  6 23:58:12 2007
From: caleb.powell at gmail.com (Caleb Powell)
Date: Fri, 6 Apr 2007 23:58:12 -0400
Subject: [Raven-devel] Antwrap Classpath
Message-ID: <ecebefa10704062058v7232aac8qdb9f0f96722ab893@mail.gmail.com>

Hi,

I was thinking of modifying the Antwrap library to dynamically load
the Ant jar files at runtime. My idea is that the AntProject instance
can be passed an ant_home parameter (by default, it would use
ENV['ANT_HOME'].  Something like this;

@ant = AntProject.new(:ant_home => '/Users/caleb/apache-ant-1.7.0')

This would save people the trouble of having to setup their Classpath
before using the library. In the case of Raven, you could include the
Ant jar files with the gem and everything would be seamless.

Would this cause any problems for anyone on the Raven project? Does it
seem worthwhile?

Cheers!

-- 
Caleb

From nobody at rubyforge.org  Sat Apr  7 21:55:11 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Sat,  7 Apr 2007 21:55:11 -0400 (EDT)
Subject: [Raven-devel] [188] trunk: added eclipse project
Message-ID: <20070408015511.CA6D45240D82@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/raven-devel/attachments/20070407/d9d5e0db/attachment-0001.html 

From rubyforge at foemmel.com  Sat Apr  7 22:44:31 2007
From: rubyforge at foemmel.com (Matthew Foemmel)
Date: Sat, 7 Apr 2007 21:44:31 -0500
Subject: [Raven-devel] Minor 2.0 patches
In-Reply-To: <B0AC3694-0AEE-43D0-8487-8ABD9055AB94@foemmel.com>
References: <460E99D3.3060401@herzumsoftware.com>
	<fbdc6a970703311254r81d6f0fkd1bc7e7c09bfcace@mail.gmail.com>
	<B0AC3694-0AEE-43D0-8487-8ABD9055AB94@foemmel.com>
Message-ID: <0DBD9240-62F2-4C22-8280-CCF6B8B75782@foemmel.com>

Actually, should we just scrap the vendor/jruby directory altogether?  
Everyone would have to download JRuby separately (and define a   
JRUBY_HOME environment variable or something so we can find it) but  
I'm using JRuby for a few other projects right now, and it would be  
nice to have them all point to the same JRuby instance. Since we're  
not associating Raven with a specific version of JRuby any more, I  
think this makes sense. Any objections?

On Apr 1, 2007, at 3:18 PM, Matthew Foemmel wrote:

> Hi Matthieu,
>
> I think we should switch to svn:external. When we first set up that  
> vendor brach, JRuby was a lot buggier than it is now, and I was  
> thinking we'd be trying out a lot more changes locally before  
> submitting them to the JRuby team. But it's pretty stable now, and  
> as you say they've been quite responsive in terms of getting  
> patches applied, so I think just using svn:external makes sense.
>
> Cheers,
> Foemmel
>
> On Mar 31, 2007, at 2:54 PM, Matthieu Riou wrote:
>
>> Hi Jesse,
>>
>> I've just applied your fixes, they all make sense. Thanks a lot!
>>
>> JRuby is imported as a vendor branch (see the vendor directory  
>> under to repository root). The goal was to be able to patch the  
>> sources directly if we needed to fix something, as JRuby is still  
>> not quite there. However they tend to be pretty responsive and  
>> apply patches almost immediately so maybe we could transition to  
>> svn:external. What do you think Matthew?
>>
>> Cheers,
>> Matthieu
>>
>> On 3/31/07, jbouwman <jbouwman at herzumsoftware.com> wrote:
>> Hello
>>
>> I've seen a few small issues on trunk, and had to make the following
>> changes to get it working for me:
>>
>> 1. In javac_task.rb, had to push @destdir onto the class_dirs  
>> channel in
>> order for jar task to see it.  Is this code changing? The comment  
>> above
>> mentions this channel, so it seemed odd that it was missing.
>>
>> 2. In gem_task.rb, changed the :project attribute writer to :group,
>> which seems to be the code's 'mavenistic' intention.
>>
>> 3. Also in gem_task, changed the task name from 'gem', since it  
>> collides
>> with a similarly named function in JRuby 0.9.8. Not sure what the  
>> best
>> name would be here.
>>
>> 4. in java_tasks.rb, change to ignore both ".xyz" and "xyz~"  
>> filenames
>> in raven/task directories on the load path, ir order to ignore emacs
>> backup files.
>>
>> I do think it makes sense to use an svn external to pull in jruby-- 
>> I was
>> surprised not to see that, on looking at the sources for the first
>> time.  I've attached diff output for the above things.
>>
>>
>> Thanks!
>>
>>
>> Jesse
>>
>>
>>
>> Index: raven/tasks/javac_task.rb
>> ===================================================================
>> --- raven/tasks/javac_task.rb   (revision 182)
>> +++ raven/tasks/javac_task.rb   (working copy)
>> @@ -87,6 +87,7 @@
>>
>>          # Add compiled classes dir to classpath and class_dirs  
>> channels
>>          channels.classpath << @destdir
>> +        channels.class_dirs << @destdir
>>        end
>>
>>        def build_path
>> Index: raven/tasks/gem_task.rb
>> ===================================================================
>> --- raven/tasks/gem_task.rb     (revision 182)
>> +++ raven/tasks/gem_task.rb     (working copy)
>> @@ -22,7 +22,7 @@
>>      # project/module directory structure. Otherwise, just set the
>>      # <em>artifact</em> and <em>project</em> to any value that  
>> suits you.
>>      class GemTask < Rake::Task
>> -      attr_writer :version, :artifact, :project
>> +      attr_writer :version, :artifact, :group
>>
>>        def execute
>>          super
>> @@ -60,6 +60,6 @@
>>    end
>> end
>>
>> -def gem(args, &block)
>> +def makegem(args, &block)
>>    Raven::Tasks::GemTask.define_task(args, &block)
>> end
>> \ No newline at end of file
>> Index: raven/java_tasks.rb
>> ===================================================================
>> --- raven/java_tasks.rb (revision 182)
>> +++ raven/java_tasks.rb (working copy)
>> @@ -19,11 +19,16 @@
>> require 'set'
>> require 'raven/tasks/matching_task'
>>
>> +# Exclude editor tempfiles
>> +def excluded_task(task_filename)
>> +  task_filename[0,1] == '.' || task_filename[-1,1] == '~'
>> +end
>> +
>> # Load all files in the "raven/tasks" directory on the load path
>> ($:).each do |base|
>>    if FileTest.directory ?(base + '/raven/tasks')
>>      Dir.foreach(base + '/raven/tasks') do |task|
>> -      require 'raven/tasks/' + task unless task[0,1] == '.'
>> +      require 'raven/tasks/' + task unless excluded_task(task)
>>      end
>>    end
>> end
>>
>> _______________________________________________
>> Raven-devel mailing list
>> Raven-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/raven-devel
>>
>>
>> _______________________________________________
>> Raven-devel mailing list
>> Raven-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/raven-devel
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/raven-devel/attachments/20070407/3380e7a9/attachment.html 

From matthieu.riou at gmail.com  Sun Apr  8 11:42:24 2007
From: matthieu.riou at gmail.com (Matthieu Riou)
Date: Sun, 8 Apr 2007 08:42:24 -0700
Subject: [Raven-devel] Minor 2.0 patches
In-Reply-To: <0DBD9240-62F2-4C22-8280-CCF6B8B75782@foemmel.com>
References: <460E99D3.3060401@herzumsoftware.com>
	<fbdc6a970703311254r81d6f0fkd1bc7e7c09bfcace@mail.gmail.com>
	<B0AC3694-0AEE-43D0-8487-8ABD9055AB94@foemmel.com>
	<0DBD9240-62F2-4C22-8280-CCF6B8B75782@foemmel.com>
Message-ID: <fbdc6a970704080842i5ff94891p1ed15f06d16fb738@mail.gmail.com>

Nope.

On 4/7/07, Matthew Foemmel <rubyforge at foemmel.com> wrote:
>
> Actually, should we just scrap the vendor/jruby directory altogether?
> Everyone would have to download JRuby separately (and define a  JRUBY_HOME
> environment variable or something so we can find it) but I'm using JRuby for
> a few other projects right now, and it would be nice to have them all point
> to the same JRuby instance. Since we're not associating Raven with a
> specific version of JRuby any more, I think this makes sense. Any
> objections?
>
> On Apr 1, 2007, at 3:18 PM, Matthew Foemmel wrote:
>
> Hi Matthieu,
> I think we should switch to svn:external. When we first set up that vendor
> brach, JRuby was a lot buggier than it is now, and I was thinking we'd be
> trying out a lot more changes locally before submitting them to the JRuby
> team. But it's pretty stable now, and as you say they've been quite
> responsive in terms of getting patches applied, so I think just using
> svn:external makes sense.
>
> Cheers,
> Foemmel
> On Mar 31, 2007, at 2:54 PM, Matthieu Riou wrote:
>
> Hi Jesse,
>
> I've just applied your fixes, they all make sense. Thanks a lot!
>
> JRuby is imported as a vendor branch (see the vendor directory under to
> repository root). The goal was to be able to patch the sources directly if
> we needed to fix something, as JRuby is still not quite there. However they
> tend to be pretty responsive and apply patches almost immediately so maybe
> we could transition to svn:external. What do you think Matthew?
>
> Cheers,
> Matthieu
>
> On 3/31/07, jbouwman <jbouwman at herzumsoftware.com> wrote:
> >
> > Hello
> >
> > I've seen a few small issues on trunk, and had to make the following
> > changes to get it working for me:
> >
> > 1. In javac_task.rb, had to push @destdir onto the class_dirs channel in
> > order for jar task to see it.  Is this code changing? The comment above
> > mentions this channel, so it seemed odd that it was missing.
> >
> > 2. In gem_task.rb, changed the :project attribute writer to :group,
> > which seems to be the code's 'mavenistic' intention.
> >
> > 3. Also in gem_task, changed the task name from 'gem', since it collides
> >
> > with a similarly named function in JRuby 0.9.8. Not sure what the best
> > name would be here.
> >
> > 4. in java_tasks.rb, change to ignore both ".xyz" and "xyz~" filenames
> > in raven/task directories on the load path, ir order to ignore emacs
> > backup files.
> >
> > I do think it makes sense to use an svn external to pull in jruby--I was
> > surprised not to see that, on looking at the sources for the first
> > time.  I've attached diff output for the above things.
> >
> >
> > Thanks!
> >
> >
> > Jesse
> >
> >
> >
> > Index: raven/tasks/javac_task.rb
> > ===================================================================
> > --- raven/tasks/javac_task.rb   (revision 182)
> > +++ raven/tasks/javac_task.rb   (working copy)
> > @@ -87,6 +87,7 @@
> >
> >          # Add compiled classes dir to classpath and class_dirs channels
> >          channels.classpath << @destdir
> > +        channels.class_dirs << @destdir
> >        end
> >
> >        def build_path
> > Index: raven/tasks/gem_task.rb
> > ===================================================================
> > --- raven/tasks/gem_task.rb     (revision 182)
> > +++ raven/tasks/gem_task.rb     (working copy)
> > @@ -22,7 +22,7 @@
> >      # project/module directory structure. Otherwise, just set the
> >      # <em>artifact</em> and <em>project</em> to any value that suits
> > you.
> >      class GemTask < Rake::Task
> > -      attr_writer :version, :artifact, :project
> > +      attr_writer :version, :artifact, :group
> >
> >        def execute
> >          super
> > @@ -60,6 +60,6 @@
> >    end
> > end
> >
> > -def gem(args, &block)
> > +def makegem(args, &block)
> >    Raven::Tasks::GemTask.define_task(args, &block)
> > end
> > \ No newline at end of file
> > Index: raven/java_tasks.rb
> > ===================================================================
> > --- raven/java_tasks.rb (revision 182)
> > +++ raven/java_tasks.rb (working copy)
> > @@ -19,11 +19,16 @@
> > require 'set'
> > require 'raven/tasks/matching_task'
> >
> > +# Exclude editor tempfiles
> > +def excluded_task(task_filename)
> > +  task_filename[0,1] == '.' || task_filename[-1,1] == '~'
> > +end
> > +
> > # Load all files in the "raven/tasks" directory on the load path
> > ($:).each do |base|
> >    if FileTest.directory ?(base + '/raven/tasks')
> >      Dir.foreach(base + '/raven/tasks') do |task|
> > -      require 'raven/tasks/' + task unless task[0,1] == '.'
> > +      require 'raven/tasks/' + task unless excluded_task(task)
> >      end
> >    end
> > end
> >
> > _______________________________________________
> > Raven-devel mailing list
> > Raven-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/raven-devel
> >
> >
> _______________________________________________
> Raven-devel mailing list
> Raven-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/raven-devel
>
>
>
>
> _______________________________________________
> Raven-devel mailing list
> Raven-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/raven-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/raven-devel/attachments/20070408/4d8bb548/attachment.html 

From twa at post.com  Sun Apr  8 14:10:14 2007
From: twa at post.com (Tom Ayerst)
Date: Sun, 08 Apr 2007 19:10:14 +0100
Subject: [Raven-devel] Minor 2.0 patches
In-Reply-To: <0DBD9240-62F2-4C22-8280-CCF6B8B75782@foemmel.com>
References: <460E99D3.3060401@herzumsoftware.com>	<fbdc6a970703311254r81d6f0fkd1bc7e7c09bfcace@mail.gmail.com>	<B0AC3694-0AEE-43D0-8487-8ABD9055AB94@foemmel.com>
	<0DBD9240-62F2-4C22-8280-CCF6B8B75782@foemmel.com>
Message-ID: <46193006.7040608@post.com>

Works for me

Matthew Foemmel wrote:
> Actually, should we just scrap the vendor/jruby directory altogether? 
> Everyone would have to download JRuby separately (and define a  
> JRUBY_HOME environment variable or something so we can find it) but 
> I'm using JRuby for a few other projects right now, and it would be 
> nice to have them all point to the same JRuby instance. Since we're 
> not associating Raven with a specific version of JRuby any more, I 
> think this makes sense. Any objections?
>
> On Apr 1, 2007, at 3:18 PM, Matthew Foemmel wrote:
>
>> Hi Matthieu,
>>
>> I think we should switch to svn:external. When we first set up that 
>> vendor brach, JRuby was a lot buggier than it is now, and I was 
>> thinking we'd be trying out a lot more changes locally before 
>> submitting them to the JRuby team. But it's pretty stable now, and as 
>> you say they've been quite responsive in terms of getting patches 
>> applied, so I think just using svn:external makes sense.
>>
>> Cheers,
>> Foemmel
>>
>> On Mar 31, 2007, at 2:54 PM, Matthieu Riou wrote:
>>
>>> Hi Jesse,
>>>
>>> I've just applied your fixes, they all make sense. Thanks a lot!
>>>
>>> JRuby is imported as a vendor branch (see the vendor directory under 
>>> to repository root). The goal was to be able to patch the sources 
>>> directly if we needed to fix something, as JRuby is still not quite 
>>> there. However they tend to be pretty responsive and apply patches 
>>> almost immediately so maybe we could transition to svn:external. 
>>> What do you think Matthew?
>>>
>>> Cheers,
>>> Matthieu
>>>
>>> On 3/31/07, jbouwman <jbouwman at herzumsoftware.com> wrote:
>>> Hello
>>>
>>> I've seen a few small issues on trunk, and had to make the following
>>> changes to get it working for me:
>>>
>>> 1. In javac_task.rb, had to push @destdir onto the class_dirs 
>>> channel in
>>> order for jar task to see it.  Is this code changing? The comment above
>>> mentions this channel, so it seemed odd that it was missing.
>>>
>>> 2. In gem_task.rb, changed the :project attribute writer to :group,
>>> which seems to be the code's 'mavenistic' intention.
>>>
>>> 3. Also in gem_task, changed the task name from 'gem', since it 
>>> collides
>>> with a similarly named function in JRuby 0.9.8. Not sure what the best
>>> name would be here.
>>>
>>> 4. in java_tasks.rb, change to ignore both ".xyz" and "xyz~" filenames
>>> in raven/task directories on the load path, ir order to ignore emacs
>>> backup files.
>>>
>>> I do think it makes sense to use an svn external to pull in jruby--I 
>>> was
>>> surprised not to see that, on looking at the sources for the first
>>> time.  I've attached diff output for the above things.
>>>
>>>
>>> Thanks!
>>>
>>>
>>> Jesse
>>>
>>>
>>>
>>> Index: raven/tasks/javac_task.rb
>>> ===================================================================
>>> --- raven/tasks/javac_task.rb   (revision 182)
>>> +++ raven/tasks/javac_task.rb   (working copy)
>>> @@ -87,6 +87,7 @@
>>>
>>>          # Add compiled classes dir to classpath and class_dirs 
>>> channels
>>>          channels.classpath << @destdir
>>> +        channels.class_dirs << @destdir
>>>        end
>>>
>>>        def build_path
>>> Index: raven/tasks/gem_task.rb
>>> ===================================================================
>>> --- raven/tasks/gem_task.rb     (revision 182)
>>> +++ raven/tasks/gem_task.rb     (working copy)
>>> @@ -22,7 +22,7 @@
>>>      # project/module directory structure. Otherwise, just set the
>>>      # <em>artifact</em> and <em>project</em> to any value that 
>>> suits you.
>>>      class GemTask < Rake::Task
>>> -      attr_writer :version, :artifact, :project
>>> +      attr_writer :version, :artifact, :group
>>>
>>>        def execute
>>>          super
>>> @@ -60,6 +60,6 @@
>>>    end
>>> end
>>>
>>> -def gem(args, &block)
>>> +def makegem(args, &block)
>>>    Raven::Tasks::GemTask.define_task(args, &block)
>>> end
>>> \ No newline at end of file
>>> Index: raven/java_tasks.rb
>>> ===================================================================
>>> --- raven/java_tasks.rb (revision 182)
>>> +++ raven/java_tasks.rb (working copy)
>>> @@ -19,11 +19,16 @@
>>> require 'set'
>>> require 'raven/tasks/matching_task'
>>>
>>> +# Exclude editor tempfiles
>>> +def excluded_task(task_filename)
>>> +  task_filename[0,1] == '.' || task_filename[-1,1] == '~'
>>> +end
>>> +
>>> # Load all files in the "raven/tasks" directory on the load path
>>> ($:).each do |base|
>>>    if FileTest.directory ?(base + '/raven/tasks')
>>>      Dir.foreach(base + '/raven/tasks') do |task|
>>> -      require 'raven/tasks/' + task unless task[0,1] == '.'
>>> +      require 'raven/tasks/' + task unless excluded_task(task)
>>>      end
>>>    end
>>> end
>>>
>>> _______________________________________________
>>> Raven-devel mailing list
>>> Raven-devel at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/raven-devel
>>>
>>>
>>> _______________________________________________
>>> Raven-devel mailing list
>>> Raven-devel at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/raven-devel
>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Raven-devel mailing list
> Raven-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/raven-devel
>   

From nobody at rubyforge.org  Sun Apr  8 14:50:19 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Sun,  8 Apr 2007 14:50:19 -0400 (EDT)
Subject: [Raven-devel] [189] trunk/bin: User must now specify a JRUBY_HOME
	environment variable for the scripts to work.
Message-ID: <20070408185019.E2D785240A96@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/raven-devel/attachments/20070408/177164de/attachment.html 

From nobody at rubyforge.org  Sun Apr  8 14:53:46 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Sun,  8 Apr 2007 14:53:46 -0400 (EDT)
Subject: [Raven-devel] [190] trunk/vendor/jruby/: deleted the vendor/jruby
	directory (use JRUBY_HOME instead)
Message-ID: <20070408185346.1FB1B5240A96@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/raven-devel/attachments/20070408/9c5f1615/attachment.html 

From jbouwman at herzumsoftware.com  Mon Apr  9 09:47:31 2007
From: jbouwman at herzumsoftware.com (Jesse Bouwman)
Date: Mon, 09 Apr 2007 08:47:31 -0500
Subject: [Raven-devel] Repository converter updates
In-Reply-To: <fbdc6a970704061317o2e1998d7ld60efe52f3057caf@mail.gmail.com>
References: <4614086E.6070508@herzumsoftware.com>	
	<fbdc6a970704041838y63bc6300s34fc03001c2a3dce@mail.gmail.com>	
	<8F955B59-79F6-40C2-A728-6217610CE704@foemmel.com>
	<fbdc6a970704061317o2e1998d7ld60efe52f3057caf@mail.gmail.com>
Message-ID: <461A43F3.4020607@herzumsoftware.com>

Hi,

Yes--and thanks!--under the username 'jbouwman'. I have a few fixes to
put in (most embarrassingly, packing up the pom rather than the jar)

Regards,
Jesse Bouwman

Matthieu Riou wrote:
> Perfect! Do you have Rubyforge account Jesse, so I can add you on the
> project?
>
> On 4/6/07, Matthew Foemmel <rubyforge at foemmel.com> wrote:
>>
>> +1 on making Jesse a commiter. Welcome!
>> On Apr 4, 2007, at 8:38 PM, Matthieu Riou wrote:
>>
>> Hi Jesse,
>>
>> I've just applied your patch, thanks! Actually if Matthew is okay
>> with it
>> I'd be more than happy to grant you commit rights. Matthew?
>>
>> The warnings probably come from the poms. Sometimes they're missing or
>> even malformed XML (wtf?!). You just need to make sure the
>> well-formed ones
>> that include dependencies have been correctly processed and that the
>> produced gems have the corresponding dependencies.
>>
>> Cheers,
>> Matthieu
>>
>> On 4/4/07, jbouwman <jbouwman at herzumsoftware.com> wrote:
>> >
>> > Hello,
>> >
>> > I've run the M2 repository converter a few times now and it works
>> pretty
>> > well, crashing out occasionally on unresolvable entities in poms.  My
>> > local version now looks at the pom file in order to pick out groupId,
>> > artifactId, and so on, instead of deriving these from the filesystem
>> > path.  Next thing is to pull out the deps.
>> >
>> > Attached are a patch for 'maven_crap.rb', as well as a new file
>> > 'maven_pom.rb' for that.  I see a bunch of warnings on the console as
>> > the "pom dom" gets built, so I have a feeling I might be failing to do
>> > some kind of package initialization?
>> >
>> > Cheers
>> > Jesse Bouwman
>> >
>> > _______________________________________________
>> > Raven-devel mailing list
>> > Raven-devel at rubyforge.org
>> > http://rubyforge.org/mailman/listinfo/raven-devel
>> >
>> >
>> >
>> _______________________________________________
>> Raven-devel mailing list
>> Raven-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/raven-devel
>>
>>
>>
>


From matthieu.riou at gmail.com  Mon Apr  9 10:45:40 2007
From: matthieu.riou at gmail.com (Matthieu Riou)
Date: Mon, 9 Apr 2007 07:45:40 -0700
Subject: [Raven-devel] Repository converter updates
In-Reply-To: <461A43F3.4020607@herzumsoftware.com>
References: <4614086E.6070508@herzumsoftware.com>
	<fbdc6a970704041838y63bc6300s34fc03001c2a3dce@mail.gmail.com>
	<8F955B59-79F6-40C2-A728-6217610CE704@foemmel.com>
	<fbdc6a970704061317o2e1998d7ld60efe52f3057caf@mail.gmail.com>
	<461A43F3.4020607@herzumsoftware.com>
Message-ID: <fbdc6a970704090745y5fa5016p1a2b08aacacc974d@mail.gmail.com>

You should be able to commit now. Welcome!

On 4/9/07, Jesse Bouwman <jbouwman at herzumsoftware.com> wrote:
>
> Hi,
>
> Yes--and thanks!--under the username 'jbouwman'. I have a few fixes to
> put in (most embarrassingly, packing up the pom rather than the jar)
>
> Regards,
> Jesse Bouwman
>
> Matthieu Riou wrote:
> > Perfect! Do you have Rubyforge account Jesse, so I can add you on the
> > project?
> >
> > On 4/6/07, Matthew Foemmel <rubyforge at foemmel.com> wrote:
> >>
> >> +1 on making Jesse a commiter. Welcome!
> >> On Apr 4, 2007, at 8:38 PM, Matthieu Riou wrote:
> >>
> >> Hi Jesse,
> >>
> >> I've just applied your patch, thanks! Actually if Matthew is okay
> >> with it
> >> I'd be more than happy to grant you commit rights. Matthew?
> >>
> >> The warnings probably come from the poms. Sometimes they're missing or
> >> even malformed XML (wtf?!). You just need to make sure the
> >> well-formed ones
> >> that include dependencies have been correctly processed and that the
> >> produced gems have the corresponding dependencies.
> >>
> >> Cheers,
> >> Matthieu
> >>
> >> On 4/4/07, jbouwman <jbouwman at herzumsoftware.com> wrote:
> >> >
> >> > Hello,
> >> >
> >> > I've run the M2 repository converter a few times now and it works
> >> pretty
> >> > well, crashing out occasionally on unresolvable entities in poms.  My
> >> > local version now looks at the pom file in order to pick out groupId,
> >> > artifactId, and so on, instead of deriving these from the filesystem
> >> > path.  Next thing is to pull out the deps.
> >> >
> >> > Attached are a patch for 'maven_crap.rb', as well as a new file
> >> > 'maven_pom.rb' for that.  I see a bunch of warnings on the console as
> >> > the "pom dom" gets built, so I have a feeling I might be failing to
> do
> >> > some kind of package initialization?
> >> >
> >> > Cheers
> >> > Jesse Bouwman
> >> >
> >> > _______________________________________________
> >> > Raven-devel mailing list
> >> > Raven-devel at rubyforge.org
> >> > http://rubyforge.org/mailman/listinfo/raven-devel
> >> >
> >> >
> >> >
> >> _______________________________________________
> >> Raven-devel mailing list
> >> Raven-devel at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/raven-devel
> >>
> >>
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/raven-devel/attachments/20070409/b82743b0/attachment.html 

From nobody at rubyforge.org  Mon Apr  9 12:52:54 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Mon,  9 Apr 2007 12:52:54 -0400 (EDT)
Subject: [Raven-devel] [191] trunk/test: Use same path and classpath values
	as $RAVEN_HOME/bin/raven -- require $JRUBY_HOME
Message-ID: <20070409165254.B818352409FB@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/raven-devel/attachments/20070409/55ec7884/attachment.html 

From rubyforge at foemmel.com  Fri Apr 27 17:39:07 2007
From: rubyforge at foemmel.com (Matthew Foemmel)
Date: Fri, 27 Apr 2007 16:39:07 -0500
Subject: [Raven-devel] rake-less prototype
Message-ID: <DE888E0E-0001-4CC2-B7E1-3F10BF4BA94B@foemmel.com>

Hi all,

I came up with a little hack the other day, and I'd like to get  
people's feedback on it. I've been growing a bit frustrated trying to  
get build channels and multi-project stuff all working cleanly with  
Rake (which has required a fair bit of monkey-patching) so out of  
curiousity I decided to see what I could come up with given a "clean  
slate" i.e. without using any Rake code. I'm not suggesting Raven  
should switch to this model, but I kind of like the way it turned  
out, and would be interested in hearing if anyone thinks there are  
ideas here worth pursuing. I've attached a file with some sample code  
- it doesn't rely on any existing code (it doesn't do much, in fact)  
so you should be able to just download and run it with vanilla ruby.

Here's an example of what a build script looks like with the prototype:

     MainCompile = Javac.new {
         @classpath << "foo.jar"
     }

     TestCompile = Javac.new(MainCompile, JUnit::Classpath) {
         @srcdir = "target/test/java"
     }

     Test = JUnit::Run.new(TestCompile)

The main differences between the prototype and the current raven2  
code are:

* Unlike Rake, there is no conceptual difference between a task  
*instance* and a task *class* - you can call "new" on any task to  
create an extension of that task
* Tasks are objects that the build script must keep track of (usually  
by storing them in constants e.g. "MainCompile" above) unlike Rake  
where they are kept in a hashtable and looked up by name
* The @ symbol can be used to define build attributes (I've been  
calling these build "channels" before, but given the new syntax i  
think "attribute" is more appropriate)

Build attributes are handled as follows:

* A task can extend any other task (by calling "new" on it) in which  
case build attributes are automatically passed from the child to the  
parent
* A task can depend on other tasks, in which case the build  
attributes for the latter are merged together and passed into the  
former (the same way that Raven works now)

Here's a quick walkthough:


=== Creating Tasks ===

The obligatory hello world script looks like this:

     Hello = Task.new {
         log_info "Hello, World!"
     }

Here we're just creating a new Task object with a single log  
statement. Calling "build Hello" would print out "Hello, World!"  
obviously.


=== Extending Tasks ===

Now, let's say we wanted to make this task more generic, so that you  
could optionally pass in the name of the person we want to greet. We  
could do this like so:

     Hello = Task.new {
         @name ||= "World"
         log_info "Hello, #{@name}!"
     }

In this case, calling "build Hello" would do the same thing as in the  
previous example (since we set the default value for "@name" to be  
"World" in the Hello task). However, we can now also define a task to  
greet "Homer":

     GreetHomer = Hello.new {
         @name = "Homer"
     }

Here we're extending the Hello task, by calling "new" on it and  
passing in a block. (Hello isn't a class, it just happens to have a  
method called "new"). So calling "new" on the Task class returns a  
new Task object, on which you can call "new" again, and so on. So  
from the user's point of view there's no real difference between a  
task class and a task instance. They're all just tasks.

When the GreetHomer task is executed, its block is run (where we set  
the value of @name to be "Homer") then its parent block is run (where  
we print out the greeting). The build attribute "@name" is  
automatically passed from the child to the parent through a bit of  
metaprogramming magic. In a sense this is like inheritance, except we  
don't need to specify which method we're overloading, and we don't  
need to explicitly call "super".


=== Dependencies ===

Dependencies can be declared by passing other tasks as arguments to  
the "new" method. For example, let's say we wanted to set up our  
classpath, then call Javac:

     Classpath = Task.new { @classpath = ["foo.jar"] }

     Compile = Javac.new(Classpath)

Build attributes are passed up the same way they are currently in  
Raven (i.e. the @classpath attribute defined in MainClasspath will be  
visible in MainCompile).

Note that I had to scrap the "=>" notation that rake uses to  
declaring dependencies, since the name of the task is no longer  
passed into the task constructor.


=== Anonymous Tasks ===

Sometimes you want to group tasks together, but don't necessarily  
want to define a separate top-level task w/associated dependencies  
for each one. The "call" command lets you run tasks from within other  
tasks. For example, say we want to compile some files and copy some  
resources over in a single build target:

     Compile = Task.new {
         call Javac.new {
             @srcdir = "src/main/java"
             @destdir = "target/main"
         }
         call Copy.new {
             @srcdir = "src/main/resources";
             @destdir = "target/main"
             @include = "**/*.properties"
         }
     }


=== Modules ===

The use of capitalize names for tasks may seems strange, but I've  
done that so that they can be treated as module constants, and  
therefore be referred to from other modules. This takes the place of  
Rake namespaces. For example:

     module Jdk
         Javac = Task.new {
             ...
         }
         Jar = Task.new {
             ...
         }
         Javadoc = Task.new {
             ...
         }
     end

     module MyApp

         # Here we use the fully qualified name
         MainCompile = Jdk::Javac {
             ...
         }

         # Here we include the module and use the short name
         include Jdk
         TestCompile = Jdk::Javac(MainCompile) {
             ...
         }
	
     end


=== Gems ===

The nice thing about using modules instead of Rake namespaces is that  
we can now bundle up sets of tasks (and their associated files) and  
distribute them as gems. For example, we could wrap all the JDK tasks  
up in a gem and use it like this:

     require_gem 'jdk'

     MainCompile =  Jdk::Javac {
         @srcdir = "mysrc"
     }

For tools like JUnit (or XDoclet, or Antlr, etc) we might want to  
provide two tasks: one to set up the classpath, and one for the  
actual tool itself. This would be fairly easy:

     module JUnit
         Classpath = Task.new {
             @classpath = "junit.jar"
          }

         Run = Task.new {
             # execute the junit tests
             ...
         }
     end

Then if you wanted to use JUnit from your build script you could do  
something like this:

     require_gem 'junit'

     CompileTests = Javac.new(JUnit::Classpath) {
         ...
     }

     RunTests = JUnit::Run.new {
         ...
     }


=== Code ===

I've attached some sample code showing how this might work - let me  
know what you think...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: build.rb
Type: text/x-ruby-script
Size: 2065 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/raven-devel/attachments/20070427/fec98e30/attachment-0001.bin 
-------------- next part --------------

Cheers,
Foemmel

From sasha.ov at gmail.com  Fri Apr 27 22:36:14 2007
From: sasha.ov at gmail.com (sasha.ov at gmail.com)
Date: Fri, 27 Apr 2007 19:36:14 -0700
Subject: [Raven-devel] bump#1: Running on Windows -- path not absolute
Message-ID: <4632B31E.1050305@gmail.com>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/raven-devel/attachments/20070427/6a9d1e3d/attachment.html 

From matthieu.riou at gmail.com  Sat Apr 28 11:40:51 2007
From: matthieu.riou at gmail.com (Matthieu Riou)
Date: Sat, 28 Apr 2007 08:40:51 -0700
Subject: [Raven-devel] bump#1: Running on Windows -- path not absolute
In-Reply-To: <4632B31E.1050305@gmail.com>
References: <4632B31E.1050305@gmail.com>
Message-ID: <fbdc6a970704280840h5947baedn9c399d9f1a2dc134@mail.gmail.com>

Hi Sasha,

Raven is mostly ready to use but starting with the trunk is maybe not a good
idea if you want a painless experience. Most functionalities work right now
but are are untested on several environments (like Windows) and we're
probably going to break things as development goes on.

So for now I'd recommend sticking with Raven 1.x until the 2.x branch (the
trunk at this moment) is stable enough.

Cheers,
Matthieu

On 4/27/07, sasha.ov at gmail.com <sasha.ov at gmail.com> wrote:
>
>  Dear all --
>
> Tired of continious wrestling with  Maven, I  decided to see how Raven can
> help.
>
> Here's my first bump: `raven import` error:
>
> Successfully built RubyGem
>   Name: xml-apis-xml-apis
>   Version: 1.0.b2
>   File: xml-apis-xml-apis-1.0.b2-java.gem
>           [root] Failed to construct POM: install directory "C:\\Documents
> and Settings\\Sasha/.raven/gems/xml-apis-xml-apis-1.0.b2-java" not
> absolute
>
> Tried simple things like hard-linking "C:/home" to "C:\Documents and
> Settings" and passing  the former to raven as -m (raven ignores this
> parameter :-( ).
>
> Using jRuby 0.9.9 and trunk Raven r191.
>
> Also would appreciate your feedback on whether it is worth trying Raven at
> this point. My Maven projects are not especially complex but sometimes
> contain little twists, like Java code signing or Flash components.
>
> Thanks in advance,
> -- Sasha
>
>
> _______________________________________________
> Raven-devel mailing list
> Raven-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/raven-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/raven-devel/attachments/20070428/3efef526/attachment.html 

From sasha.ov at gmail.com  Sat Apr 28 12:04:51 2007
From: sasha.ov at gmail.com (sasha.ov at gmail.com)
Date: Sat, 28 Apr 2007 09:04:51 -0700
Subject: [Raven-devel] bump#1: Running on Windows -- path not absolute
In-Reply-To: <fbdc6a970704280840h5947baedn9c399d9f1a2dc134@mail.gmail.com>
References: <4632B31E.1050305@gmail.com>
	<fbdc6a970704280840h5947baedn9c399d9f1a2dc134@mail.gmail.com>
Message-ID: <463370A3.3040808@gmail.com>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/raven-devel/attachments/20070428/caf970ea/attachment.html