My $0.02 from the sidelines, Maven sucks as a *build* tool. I dislike
it with a passion, or rather, I'm all about Ant myself.
Regarding Mahout, I think it makes sense to let Sean to set up and
maintain his area with Ant and simply have Maven call to it for
packaging. I'm not active with Mahout personally, but if I were, I'd
not enjoy using Maven. I don't like Maven anywhere. But then again,
I don't rely on "repositories" either, and just prefer a built in
directory full of .jar files. I'm a caveman like that. *grunt*
Erik
On Mar 15, 2009, at 7:38 PM, Sean Owen wrote:
On Sun, Mar 15, 2009 at 7:30 PM, Grant Ingersoll
<[email protected]> wrote:
The first time is often slower than the rest.
~5 minutes the second time which is a lot better indeed -- not
something I want to run except when releasing but indeed that's mostly
what it's for.
I point IntelliJ at my POM and say "Import Project". Then, I use
IntelliJ's
compilation and tests almost all the time. The only time I don't
is right
before check in, when I want to make sure I didn't mess anything up.
Am I right in viewing Maven as more of a packaging and release
management system rather than build tool? sure it happens to do
compilation but seems like it's a higher-level tool than Ant for
instance. Ant provides primitives for doing small, custom things but
little support for larger tasks and concepts.
I have seen many projects use Ant for all of these tasks of course.
When you add in IntelliJ, sure, it can be configured to delegate all
the build, test and deploy mechanics to Ant targets. In practice
though one still maintains some level of project configuration in the
IDE project itself. So it is still kind of a two-part build system.
So bring in Maven instead of Ant -- it's perhaps clear it's harder to
do the fine-grained / custom work with Maven (by design). But it makes
sense to use the IDE for that stuff. So I shouldn't feel bad about
using both Maven and the IDE tools -- there are two roles to fill.
But we can't really depend on IntelliJ since not everyone uses it. So
where we need to distribute an automated system to do custom bits of
work, Ant seems like the natural substitute for this role.
That's a long way to go to say what perhaps everyone already agrees
on, that it's OK to use an Ant script here and there if it is
necessary.
I think we can make the taste-web work w/ the POM. What is it that
you see
as lacking in there now? Try doing "mvn package". I get a WAR
file now
that works, so long as I set my recommender.properties.
What I don't think we have a great solution for just yet is the
Grouplens
example.
Will go back and try -- perhaps something wasn't installed and that's
why I could not build a WAR.
The thing is, the reason that the GroupLens example doesn't work will
make this bit of fun not work for anybody's code. I feel it's
important enough to include rather than drop for reasons of build
system not liking it. I think the issue is that we need to package a
custom .jar file in the .war and it's hard to do? (Or if that can be
done I imagine that solves the last problem that was encountered on
the mailing list.)
On the other hand I do have a complete patch ready to go here that
makes it all work -- via Ant that is. The patch also cleans out the
Ant cruft from trunk/core BTW since it is exactly this stuff that
needs to move. I'd suggest it's worth going this way to keep things
working and move ahead with 0.1. My patch removed pom.xml but can put
it back if it's needed for packaging purposes -- just trying to avoid
duplicating within it some build logic.
Happy to hear someone else has an alternate solution but would suggest
it may not be worthing banging heads against walls for too much.
Er perhaps I should open a JIRA issue to cover this, plus my draft
patch.
