You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Yonik Seeley <yo...@apache.org> on 2007/02/14 18:20:56 UTC
[VOTE] release Lucene 2.1
Release artifacts for review are at
http://people.apache.org/~yonik/staging_area/lucene/
Please vote to officially release these packages as Lucene 2.1.
-Yonik
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [VOTE] release Lucene 2.1
Posted by Michael Busch <bu...@gmail.com>.
+1
Michael
Yonik Seeley wrote:
> Release artifacts for review are at
> http://people.apache.org/~yonik/staging_area/lucene/
> Please vote to officially release these packages as Lucene 2.1.
>
> -Yonik
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [VOTE] release Lucene 2.1
Posted by Doron Cohen <DO...@il.ibm.com>.
>
> : Please vote to officially release these packages as Lucene 2.1.
>
> +0
>
> the inability to build several contribs in the source release because the
> jars they depend on are excluded (and there's no docs on what they are
for
> people to download them manually) seems pretty bad ...
I think this is solved easily with
http://issues.apache.org/jira/browse/LUCENE-804
> but i don't know
> that i like the idea of increasing the source dist size that much to
> include them.
Actually the current src dist that included gdata/ext-libs instead
of gdata/lib, and was 8.9 MB. After fixing this it drops to 6.8 MB.
>
> i don't have any particular suggestion on how to proceed ... after
> spending so much time scrutinizing and tweaking the initial Solr release,
> the Lucene Java release artifacts/mechanisms seem fairly flawed -- but
the
> that doesn't mean we'd be better off *not* having a release just to spend
> a bunch of time retooling the packaging.
>
>
>
>
> -Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [VOTE] release Lucene 2.1
Posted by Chris Hostetter <ho...@fucit.org>.
: Please vote to officially release these packages as Lucene 2.1.
+0
the inability to build several contribs in the source release because the
jars they depend on are excluded (and there's no docs on what they are for
people to download them manually) seems pretty bad ... but i don't know
that i like the idea of increasing the source dist size that much to
include them.
i don't have any particular suggestion on how to proceed ... after
spending so much time scrutinizing and tweaking the initial Solr release,
the Lucene Java release artifacts/mechanisms seem fairly flawed -- but the
that doesn't mean we'd be better off *not* having a release just to spend
a bunch of time retooling the packaging.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Maven builds
Posted by Yonik Seeley <yo...@apache.org>.
On 2/16/07, Sami Siren <ss...@gmail.com> wrote:
> 2007/2/15, Yonik Seeley <yo...@apache.org>:
> >
> > My first impression of maven:
> > Pretty websites as part of the build system - cool! And it's
> > *great* for starting
> > a new project... unit tests automatically run, website is built,
> > automatic packaging, jar/war build, everything you need!
> > But, it all seems like magic to me... if I want to do something different,
> > even a minor little change, I don't know where to start. If I want to add
> > an
> > additional compile flag, where does that go??? I have no idea. To change
> > the
> > behavior (like using Java5 source) I need to google and find the magic
> > incantation.
>
>
> Are you saying that the first time you tried ant everything was immediately
> clear to you - no need to vistit ant.apache.org ?
I didn't start with my own ant file, but had to modify an existing one.
But, things mapped pretty close from "make"... there were targets and
dependencies,
and the targets had tasks in them. It was easy for me to figure out
how to create some new targets to do some extra stuff.
I did have to google for "what's the name of the task to do x", or
"what parameters does task x accept". That's a bit different from my
first-time experience with maven, which appears more declarative than
procedural, and at a much higher level.
Don't get me wrong, I'm definitely not against maven... just pointing
out that in a nutshell to me, it looked like you got a lot more out of
the box, but the learning curve was steeper (conversely many simple
projects may need to learn less with mvn because it does so much for
them by default.)
-Yonik
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Maven builds
Posted by karl wettin <ka...@gmail.com>.
16 feb 2007 kl. 11.17 skrev Sylvain Wallez:
> Ant + Ivy [1] are as powerful and infinitely more flexible.
If you have the time and knowledge, feel free to do something with
it. Perhaps demonstrate the dependency stuff from Ivy with gdata, the
benchmarker or so. I don't mind evaluating multiple automation tools
as we are at it.
--
karl
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Maven builds
Posted by karl wettin <ka...@gmail.com>.
Just out of curiosity, did you try using Maven for more than
building? As I see it, the killer application is the development
environment intergration combined with release management and
dependency automation. These are the features that I hope will bring
people to the dark side.
I ended up doing other stuff this weekend. Will give it another try
the next.
--
karl
17 feb 2007 kl. 00.31 skrev Chris Hostetter:
>
> My investigations into maven2 have led me to similar conclusions that
> other's seem to have expressed: great tool, looks perfect for people
> starting from scratch - solves lots of problems, most of which we've
> already solved other ways ... training users to use the maven ways
> instead
> of our existing ways probably isn't worth what little benefit is left.
>
> I think the best idea might be to start by pursuing the maven Antlib
> Michael Wechner mentioned, to deal with the fetching dependencies
> needed
> by contribs and publishing release jars to the maven repository --
> using a
> new pom.xml to declare the project metadata and dependencies (which
> according to the docs can be accessed from the build.xml as
> properties)
>
> that sounds like it would be a good starting point towrads "fixing"
> some
> of the biggest percieved advantages to using maven -- and might
> serve as a
> good gateway to migrating the whole build process later.
>
> : very much agreed, whereas as an alternative one might want to use
> :
> : ant + http://maven.apache.org/ant-tasks.html
> : (maven-artifact-ant-2.0.4-dep.jar)
>
>
>
>
> -Hoss
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Maven builds
Posted by Chris Hostetter <ho...@fucit.org>.
My investigations into maven2 have led me to similar conclusions that
other's seem to have expressed: great tool, looks perfect for people
starting from scratch - solves lots of problems, most of which we've
already solved other ways ... training users to use the maven ways instead
of our existing ways probably isn't worth what little benefit is left.
I think the best idea might be to start by pursuing the maven Antlib
Michael Wechner mentioned, to deal with the fetching dependencies needed
by contribs and publishing release jars to the maven repository -- using a
new pom.xml to declare the project metadata and dependencies (which
according to the docs can be accessed from the build.xml as properties)
that sounds like it would be a good starting point towrads "fixing" some
of the biggest percieved advantages to using maven -- and might serve as a
good gateway to migrating the whole build process later.
: very much agreed, whereas as an alternative one might want to use
:
: ant + http://maven.apache.org/ant-tasks.html
: (maven-artifact-ant-2.0.4-dep.jar)
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Maven builds
Posted by Michael Wechner <mi...@wyona.com>.
Sylvain Wallez wrote:
>Sami Siren wrote:
>
>
>>2007/2/15, Yonik Seeley <yo...@apache.org>:
>>
>>
>>>My first impression of maven:
>>> Pretty websites as part of the build system - cool! And it's
>>>*great* for starting
>>>a new project... unit tests automatically run, website is built,
>>>automatic packaging, jar/war build, everything you need!
>>>But, it all seems like magic to me... if I want to do something
>>>different,
>>>even a minor little change, I don't know where to start. If I want
>>>to add
>>>an
>>>additional compile flag, where does that go??? I have no idea. To
>>>change
>>>the
>>>behavior (like using Java5 source) I need to google and find the magic
>>>incantation.
>>>
>>>
>>Are you saying that the first time you tried ant everything was
>>immediately
>>clear to you - no need to vistit ant.apache.org ?
>>
>>
>
>[chiming in as one of those that were hurt badly trying to setup a
>complex project with Maven]
>
>Actually that's the exact truth. If you ever were in contact with a
>build system that has "targets" (e.g. Make), Ant seems very natural, and
>understanding a simple build.xml is quite straightforward. Of course,
>when you write your own Ant files you have to look a the docs. But then
>again, it's quite straightforward.
>
>Maven is black magic. Very nice when it works, but so head-banging when
>it doesn't or when you want to do something that doesn't fit in the
>"maven way".
>
>Maven repositories are a nice thing, but you don't have to change your
>build to Maven to produce Maven artifacts, nor to use the repositories.
>Unfortunately, people often think that one cannot come without the other.
>
>Ant + Ivy [1] are as powerful and infinitely more flexible.
>
>
very much agreed, whereas as an alternative one might want to use
ant + http://maven.apache.org/ant-tasks.html
(maven-artifact-ant-2.0.4-dep.jar)
HTH
Michi
>My 0.02 euros
>
>Sylvain
>
>[1] http://incubator.apache.org/ivy/
>
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
+41 44 272 91 61
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Maven builds
Posted by Sylvain Wallez <sy...@apache.org>.
Sami Siren wrote:
> 2007/2/15, Yonik Seeley <yo...@apache.org>:
>>
>> My first impression of maven:
>> Pretty websites as part of the build system - cool! And it's
>> *great* for starting
>> a new project... unit tests automatically run, website is built,
>> automatic packaging, jar/war build, everything you need!
>> But, it all seems like magic to me... if I want to do something
>> different,
>> even a minor little change, I don't know where to start. If I want
>> to add
>> an
>> additional compile flag, where does that go??? I have no idea. To
>> change
>> the
>> behavior (like using Java5 source) I need to google and find the magic
>> incantation.
>
>
> Are you saying that the first time you tried ant everything was
> immediately
> clear to you - no need to vistit ant.apache.org ?
[chiming in as one of those that were hurt badly trying to setup a
complex project with Maven]
Actually that's the exact truth. If you ever were in contact with a
build system that has "targets" (e.g. Make), Ant seems very natural, and
understanding a simple build.xml is quite straightforward. Of course,
when you write your own Ant files you have to look a the docs. But then
again, it's quite straightforward.
Maven is black magic. Very nice when it works, but so head-banging when
it doesn't or when you want to do something that doesn't fit in the
"maven way".
Maven repositories are a nice thing, but you don't have to change your
build to Maven to produce Maven artifacts, nor to use the repositories.
Unfortunately, people often think that one cannot come without the other.
Ant + Ivy [1] are as powerful and infinitely more flexible.
My 0.02 euros
Sylvain
[1] http://incubator.apache.org/ivy/
--
Sylvain Wallez - http://bluxte.net
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Maven builds
Posted by Sami Siren <ss...@gmail.com>.
2007/2/15, Yonik Seeley <yo...@apache.org>:
>
> My first impression of maven:
> Pretty websites as part of the build system - cool! And it's
> *great* for starting
> a new project... unit tests automatically run, website is built,
> automatic packaging, jar/war build, everything you need!
> But, it all seems like magic to me... if I want to do something different,
> even a minor little change, I don't know where to start. If I want to add
> an
> additional compile flag, where does that go??? I have no idea. To change
> the
> behavior (like using Java5 source) I need to google and find the magic
> incantation.
Are you saying that the first time you tried ant everything was immediately
clear to you - no need to vistit ant.apache.org ?
Maybe the benefits of maven pay off over the long run, but as one
> casual/newbie user, it just seemed like too much of a black box that I
> can't quickly hack to get it to do what I want.
I have been "forced" to use m2 for the past year or so, but at this point I
have to say
thath I kind of like it (pervert me).
Even my spine seems to like it, more than once I have tried to build various
Lucene projects
with mvn install or run unit tests with mvn clean test ;)
--
Sami Siren
Re: Maven builds (was: [VOTE] release Lucene 2.1)
Posted by Lukas Vlcek <lu...@gmail.com>.
Ah... I can see that the war fire has been set on on parallel thread :-)
On 2/16/07, Lukas Vlcek <lu...@gmail.com> wrote:
>
> Hi,
>
> As far as I remember, there has already been discussions about possible
> port of Lucene (and/or Nutch) to Maven in the past. I don't want to
> discourage you but I am afraid that it won't be that easy to do this port
> without significant effort and community support. I don't consider myself
> Maven expert but I think that it would be correct to break up the Lucene
> source to several projects (I am thinking at least of contrib content as
> extra projects - the same would apply to Nutch plugins - yes, and Hadoop is
> another candidate).
>
> Anyway, I am convinced that porting Lucene and Nutch to Maven would be a
> huge benefit (from my experience I can compare what it is like to over-take
> project without any building script, with ant script and with maven script -
> and maven simply wins). On the other hand, I am a bit sceptical about this
> move because maven is imho more then just a building script. What if it
> requires community to adapt different practices/approach? Would community be
> happy about this? I don't want anybody to take it personally but my
> speculation is that majority of Lucene/Nutch commiters haven't been exposed
> to maven yet (because if they were then they would already use it :-)
>
> BTW: Are you thinking about Maven or M2 (maven 2)? (I am sorry for my
> ignorance here if you have made the decision [M/M2] in previous emails - I
> am jumping into this thread like a barbarian). I would love to help with
> maven but I don't have hands-on experience with m2.
>
> Regards,
> Lukas
>
> On 2/15/07, karl wettin <ka...@gmail.com> wrote:
> >
> >
> > 15 feb 2007 kl. 20.27 skrev Erik Hatcher:
> > > On Feb 15, 2007, at 12:10 PM, karl wettin wrote:
> > >> I would not mind introducing Maven builds in Lucene. It would
> > >> solve /at least/ this problem. And it would merge so great with my
> > >> other projects. :) I'd be happy to help out , but there are some
> > >> wicked anting going on in a lot of build.xml:s so I would probably
> > >> need a lot of help from the contributors understanding whats going
> > >> on.
> > >>
> > >> Most of the build scripts could be halfway housed using maven-
> > >> antrun-plugin.
> > >
> > > I'm open to Maven builds, for the record. I'll do what I can to
> > > help with understanding any of the wicked anting in there, but I
> > > don't know Maven so the best I'll be able to do is explain what is
> > > going on. The main complexity we have is the contrib area, oh and
> > > JavaCC... the rest is straightforward stuff.
> >
> > I'll see what I can do this weekend.
> >
> >
> > +++
> > ATH
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: java-dev-help@lucene.apache.org
> >
> >
>
Re: Maven builds (was: [VOTE] release Lucene 2.1)
Posted by Lukas Vlcek <lu...@gmail.com>.
Hi,
As far as I remember, there has already been discussions about possible port
of Lucene (and/or Nutch) to Maven in the past. I don't want to discourage
you but I am afraid that it won't be that easy to do this port without
significant effort and community support. I don't consider myself Maven
expert but I think that it would be correct to break up the Lucene source to
several projects (I am thinking at least of contrib content as extra
projects - the same would apply to Nutch plugins - yes, and Hadoop is
another candidate).
Anyway, I am convinced that porting Lucene and Nutch to Maven would be a
huge benefit (from my experience I can compare what it is like to over-take
project without any building script, with ant script and with maven script -
and maven simply wins). On the other hand, I am a bit sceptical about this
move because maven is imho more then just a building script. What if it
requires community to adapt different practices/approach? Would community be
happy about this? I don't want anybody to take it personally but my
speculation is that majority of Lucene/Nutch commiters haven't been exposed
to maven yet (because if they were then they would already use it :-)
BTW: Are you thinking about Maven or M2 (maven 2)? (I am sorry for my
ignorance here if you have made the decision [M/M2] in previous emails - I
am jumping into this thread like a barbarian). I would love to help with
maven but I don't have hands-on experience with m2.
Regards,
Lukas
On 2/15/07, karl wettin <ka...@gmail.com> wrote:
>
>
> 15 feb 2007 kl. 20.27 skrev Erik Hatcher:
> > On Feb 15, 2007, at 12:10 PM, karl wettin wrote:
> >> I would not mind introducing Maven builds in Lucene. It would
> >> solve /at least/ this problem. And it would merge so great with my
> >> other projects. :) I'd be happy to help out , but there are some
> >> wicked anting going on in a lot of build.xml:s so I would probably
> >> need a lot of help from the contributors understanding whats going
> >> on.
> >>
> >> Most of the build scripts could be halfway housed using maven-
> >> antrun-plugin.
> >
> > I'm open to Maven builds, for the record. I'll do what I can to
> > help with understanding any of the wicked anting in there, but I
> > don't know Maven so the best I'll be able to do is explain what is
> > going on. The main complexity we have is the contrib area, oh and
> > JavaCC... the rest is straightforward stuff.
>
> I'll see what I can do this weekend.
>
>
> +++
> ATH
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
Re: Maven builds
Posted by Lukas Vlcek <lu...@gmail.com>.
Hi,
I don't want to disturb other folks from their meditation but I am all for
experimental maven build process for Lucene. If we are talking about mvn
(maven2) then I won't be able to help much (as I have hands-on experience
with maven1.x - btw is it possible to use Jelly in mvn? As far as I know it
is not - what a pitty).
Regards,
Lukas
On 2/16/07, Doug Cutting <cu...@apache.org> wrote:
>
> karl wettin wrote:
> > However, I don't think that the Buddha defined Nivana as "good enough".
>
> http://en.wikipedia.org/wiki/Nirvana, "It is a mode of being that is
> free from mind-contaminants (Kilesa) such as lust, anger or craving."
>
> That's not far from "good enough".
>
> Doug
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
Re: Maven builds
Posted by Grant Ingersoll <gs...@apache.org>.
I think a POM for Lucene core and demo is pretty trivial, since there
are no dependencies, although I haven't tried Maven 2 yet. Contrib
modules w/ dependencies is a little bit harder and getting them all
to work together is a bit more on top of that.
We made the switch to Maven 1 at CNLP over two years ago and I can't
say I've ever wanted to go back to writing ANT build files. We have
completely automated our build/release mechanism (which includes
compilation, jar, SVN tagging, Unit testing, etc., email
announcements, updating bugzilla versions, site publication, etc.)
and I think it is safe to say the whole process would be a lot harder
to do in ANT (not that it couldn't be done). Just like Solr removes
much of the messiness of setting up Lucene and puts it into config
files, so does Maven when it comes to project mgmt. For the most
part, the magic is pretty well documented and straightforward to find
(but not always)
So, I'm +1 for seeing experimenting, as Doug suggested.
On Feb 15, 2007, at 4:20 PM, karl wettin wrote:
>
> 15 feb 2007 kl. 21.24 skrev Yonik Seeley:
>
>> But, it all seems like magic to me... if I want to do something
>> different,
>> even a minor little change, I don't know where to start. If I
>> want to add an
>> additional compile flag, where does that go??? I have no idea. To
>> change the
>> behavior (like using Java5 source) I need to google and find the
>> magic
>> incantation.
>
> I felt the same way until I registred the POM schema in my editor.
> As always
> there was a threadshold to pass before getting used to it. Now my
> general
> opinion is that maven(2) is a very mature and highly configurable
> but still
> easy to use build system that takes care of everything for me. I'm
> especially
> fond of the surefire test plugin, the in depth dependency handling
> and how
> it creates the project in my development environment.
>
>
> --
> karl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
--------------------------
Grant Ingersoll
Center for Natural Language Processing
http://www.cnlp.org
Read the Lucene Java FAQ at http://wiki.apache.org/jakarta-lucene/
LuceneFAQ
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Maven builds
Posted by karl wettin <ka...@gmail.com>.
15 feb 2007 kl. 21.24 skrev Yonik Seeley:
> But, it all seems like magic to me... if I want to do something
> different,
> even a minor little change, I don't know where to start. If I want
> to add an
> additional compile flag, where does that go??? I have no idea. To
> change the
> behavior (like using Java5 source) I need to google and find the magic
> incantation.
I felt the same way until I registred the POM schema in my editor. As
always
there was a threadshold to pass before getting used to it. Now my
general
opinion is that maven(2) is a very mature and highly configurable but
still
easy to use build system that takes care of everything for me. I'm
especially
fond of the surefire test plugin, the in depth dependency handling
and how
it creates the project in my development environment.
--
karl
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Maven builds
Posted by Yonik Seeley <yo...@apache.org>.
My first impression of ant:
Ok, the syntax is a little funky, and I can't re-use my knowledge of command
line options to tools w/o doing an exec... I need to learn the "ant" parameters
for all the different tasks now. I can look at a build.xml and tweak/fix it
because there isn't too much "magic" involved... it's fairly straight
forward do-this
then do-that, specified in portable XML.
My first impression of maven:
Pretty websites as part of the build system - cool! And it's
*great* for starting
a new project... unit tests automatically run, website is built,
automatic packaging, jar/war build, everything you need!
But, it all seems like magic to me... if I want to do something different,
even a minor little change, I don't know where to start. If I want to add an
additional compile flag, where does that go??? I have no idea. To change the
behavior (like using Java5 source) I need to google and find the magic
incantation.
Maybe the benefits of maven pay off over the long run, but as one
casual/newbie user, it just seemed like too much of a black box that I
can't quickly hack to get it to do what I want.
-Yonik
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Maven builds
Posted by Doug Cutting <cu...@apache.org>.
karl wettin wrote:
> However, I don't think that the Buddha defined Nivana as "good enough".
http://en.wikipedia.org/wiki/Nirvana, "It is a mode of being that is
free from mind-contaminants (Kilesa) such as lust, anger or craving."
That's not far from "good enough".
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Maven builds
Posted by Robert Koberg <ro...@koberg.com>.
On Thu, 15 Feb 2007 18:58:00 -0500, karl wettin <ka...@gmail.com>
wrote:
>
> 16 feb 2007 kl. 00.37 skrev Slava Imeshev:
>
>> My personal opinion is that Ant is good enough and that Java has
>> reached build automation
>> nirvana with it, just like C/C++ with make.
>
> Did I start yet another tech-religous war thread now? Sorry about that.
>
> However, I don't think that the Buddha defined Nivana as "good enough".
Do you only read websites that validate to XHTML 1.0 strict?
who is the buddha?
:)
>
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Maven builds
Posted by karl wettin <ka...@gmail.com>.
16 feb 2007 kl. 00.37 skrev Slava Imeshev:
> My personal opinion is that Ant is good enough and that Java has
> reached build automation
> nirvana with it, just like C/C++ with make.
Did I start yet another tech-religous war thread now? Sorry about that.
However, I don't think that the Buddha defined Nivana as "good enough".
--
karl
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Maven builds
Posted by Slava Imeshev <vi...@viewtier.com>.
Parabuild is build-tool agnostic, nor Viewtier has any tool preferences.
The open source projects that we are currently supporting at http://parabuild.viewtier.com:8080
vary in use of builds tools. Our experience with setting up that projects has shown that
Ant-based ones have been somewhat easier to set up. Maybe that's because with
Ant it is possible to quickly figure out what you get.
My personal opinion is that Ant is good enough and that Java has reached build automation
nirvana with it, just like C/C++ with make. But as far as understand Apache requires you to
move, so it's not really your call.
If I had a voice I'd vote for multi-threaded indexing in Lucene instead of implementing
Maven builds.
----- Original Message -----
From: "Grant Ingersoll" <gs...@apache.org>
To: <ja...@lucene.apache.org>
Sent: Thursday, February 15, 2007 2:55 PM
Subject: Re: Maven builds
> These articles are over 3 years old or more, I think the large
> community that uses Maven says it is a worthwhile thing. I'm
> curious, Slava, how many of ViewTier's Parabuild clients use Maven,
> since your website says you support it?
Regards,
Slava Imeshev
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Maven builds
Posted by Grant Ingersoll <gs...@apache.org>.
These articles are over 3 years old or more, I think the large
community that uses Maven says it is a worthwhile thing. I'm
curious, Slava, how many of ViewTier's Parabuild clients use Maven,
since your website says you support it?
I'm not saying Maven is the be all end all, but it works pretty well
IMO. Having said that, we have most everything we need in the ANT
scripts we already have, except, maybe automated releases and nice
project metadata like the POM provides, so I'm not that compelled to
switch. In light of our prior discussions of having more frequent
releases, I think having more automated releases is needed.
-Grant
On Feb 15, 2007, at 5:19 PM, Slava Imeshev wrote:
> Here is a couple of alternative points of view on Maven. Make
> sure your kids are not reading this:
>
> http://www.jroller.com/page/fate/?anchor=why_maven_sucks
> http://www.jroller.com/page/fate/?anchor=maven_refresher_course
>
> ----- Original Message -----
> From: "karl wettin" <ka...@gmail.com>
> To: <ja...@lucene.apache.org>
> Sent: Thursday, February 15, 2007 2:05 PM
> Subject: Re: Maven builds
>
>
>>
>> 15 feb 2007 kl. 23.03 skrev Steven Rowe:
>>
>>>> I'll see what I can do this weekend.
>>>
>>> "Maven" refers to two very different products. Which version to use
>>> ought to be a serious consideration.
>>>
>>> Karl, do you mean to use Maven 1.X or Maven2?
>>
>> Maven2. mvn.
>>
>> --
>> karl
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
--------------------------
Grant Ingersoll
Center for Natural Language Processing
http://www.cnlp.org
Read the Lucene Java FAQ at http://wiki.apache.org/jakarta-lucene/
LuceneFAQ
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Maven builds
Posted by Slava Imeshev <vi...@viewtier.com>.
Here is a couple of alternative points of view on Maven. Make
sure your kids are not reading this:
http://www.jroller.com/page/fate/?anchor=why_maven_sucks
http://www.jroller.com/page/fate/?anchor=maven_refresher_course
----- Original Message -----
From: "karl wettin" <ka...@gmail.com>
To: <ja...@lucene.apache.org>
Sent: Thursday, February 15, 2007 2:05 PM
Subject: Re: Maven builds
>
> 15 feb 2007 kl. 23.03 skrev Steven Rowe:
>
> >> I'll see what I can do this weekend.
> >
> > "Maven" refers to two very different products. Which version to use
> > ought to be a serious consideration.
> >
> > Karl, do you mean to use Maven 1.X or Maven2?
>
> Maven2. mvn.
>
> --
> karl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Maven builds
Posted by karl wettin <ka...@gmail.com>.
15 feb 2007 kl. 23.03 skrev Steven Rowe:
>> I'll see what I can do this weekend.
>
> "Maven" refers to two very different products. Which version to use
> ought to be a serious consideration.
>
> Karl, do you mean to use Maven 1.X or Maven2?
Maven2. mvn.
--
karl
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Maven builds
Posted by Steven Rowe <sa...@syr.edu>.
karl wettin wrote:
>
> 15 feb 2007 kl. 20.27 skrev Erik Hatcher:
>> On Feb 15, 2007, at 12:10 PM, karl wettin wrote:
>>> I would not mind introducing Maven builds in Lucene. It would solve
>>> /at least/ this problem. And it would merge so great with my other
>>> projects. :) I'd be happy to help out , but there are some wicked
>>> anting going on in a lot of build.xml:s so I would probably need a
>>> lot of help from the contributors understanding whats going on.
>>>
>>> Most of the build scripts could be halfway housed using
>>> maven-antrun-plugin.
>>
>> I'm open to Maven builds, for the record. I'll do what I can to help
>> with understanding any of the wicked anting in there, but I don't know
>> Maven so the best I'll be able to do is explain what is going on.
>> The main complexity we have is the contrib area, oh and JavaCC... the
>> rest is straightforward stuff.
>
> I'll see what I can do this weekend.
"Maven" refers to two very different products. Which version to use
ought to be a serious consideration.
Karl, do you mean to use Maven 1.X or Maven2? Maven 1.X (which I use)
seems not to be all that well maintained (e.g., Maven 1.1 has been in
beta for 20 months now), and Maven2 is fairly new (first released 16
months ago), so probably has a smaller user base. The Maven site docs
encourage new adopters to take the Maven2 route.
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Maven builds
Posted by karl wettin <ka...@gmail.com>.
15 feb 2007 kl. 20.44 skrev karl wettin:
> I'll see what I can do this weekend.
Should I do everything to keep the same file structure as now? It
would be easier if nobody have any opinions about restructuring to
Maven-style. Perhaps a script that set it up from the current?
--
karl
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Maven builds
Posted by Doug Cutting <cu...@apache.org>.
There are cultural issues as well as technical issues to adopting Maven.
Most folks involved with Lucene are familiar with using Ant and
maintaining an Ant-based build system. So merely converting Lucene to
be built by Maven will not cause everyone who currently works on Lucene
to become willing and able to to use Maven on a daily basis.
Long-term, we probably should not attempt to maintain two official build
systems. But, short-term, it would be useful for developers to be able
to evaluate Maven, then discussion can begin about whether the project
should switch to Maven as its primary build system.
Doug
karl wettin wrote:
>
> 15 feb 2007 kl. 20.27 skrev Erik Hatcher:
>> On Feb 15, 2007, at 12:10 PM, karl wettin wrote:
>>> I would not mind introducing Maven builds in Lucene. It would solve
>>> /at least/ this problem. And it would merge so great with my other
>>> projects. :) I'd be happy to help out , but there are some wicked
>>> anting going on in a lot of build.xml:s so I would probably need a
>>> lot of help from the contributors understanding whats going on.
>>>
>>> Most of the build scripts could be halfway housed using
>>> maven-antrun-plugin.
>>
>> I'm open to Maven builds, for the record. I'll do what I can to help
>> with understanding any of the wicked anting in there, but I don't know
>> Maven so the best I'll be able to do is explain what is going on.
>> The main complexity we have is the contrib area, oh and JavaCC... the
>> rest is straightforward stuff.
>
> I'll see what I can do this weekend.
>
>
> +++
> ATH
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Maven builds (was: [VOTE] release Lucene 2.1)
Posted by karl wettin <ka...@gmail.com>.
15 feb 2007 kl. 20.27 skrev Erik Hatcher:
> On Feb 15, 2007, at 12:10 PM, karl wettin wrote:
>> I would not mind introducing Maven builds in Lucene. It would
>> solve /at least/ this problem. And it would merge so great with my
>> other projects. :) I'd be happy to help out , but there are some
>> wicked anting going on in a lot of build.xml:s so I would probably
>> need a lot of help from the contributors understanding whats going
>> on.
>>
>> Most of the build scripts could be halfway housed using maven-
>> antrun-plugin.
>
> I'm open to Maven builds, for the record. I'll do what I can to
> help with understanding any of the wicked anting in there, but I
> don't know Maven so the best I'll be able to do is explain what is
> going on. The main complexity we have is the contrib area, oh and
> JavaCC... the rest is straightforward stuff.
I'll see what I can do this weekend.
+++
ATH
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [VOTE] release Lucene 2.1
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Feb 15, 2007, at 12:10 PM, karl wettin wrote:
> I would not mind introducing Maven builds in Lucene. It would
> solve /at least/ this problem. And it would merge so great with my
> other projects. :) I'd be happy to help out , but there are some
> wicked anting going on in a lot of build.xml:s so I would probably
> need a lot of help from the contributors understanding whats going on.
>
> Most of the build scripts could be halfway housed using maven-
> antrun-plugin.
I'm open to Maven builds, for the record. I'll do what I can to help
with understanding any of the wicked anting in there, but I don't
know Maven so the best I'll be able to do is explain what is going
on. The main complexity we have is the contrib area, oh and
JavaCC... the rest is straightforward stuff.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [VOTE] release Lucene 2.1
Posted by karl wettin <ka...@gmail.com>.
15 feb 2007 kl. 17.42 skrev Yonik Seeley:
> Recap:
> - some contrib modules can't be built without the user downloading
> more jars themselves
I would not mind introducing Maven builds in Lucene. It would solve /
at least/ this problem. And it would merge so great with my other
projects. :) I'd be happy to help out , but there are some wicked
anting going on in a lot of build.xml:s so I would probably need a
lot of help from the contributors understanding whats going on.
Most of the build scripts could be halfway housed using maven-antrun-
plugin.
--
karl
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [VOTE] release Lucene 2.1
Posted by Doron Cohen <DO...@il.ibm.com>.
+1.
(also since releases are going to be more frequent.)
Grant Ingersoll <gs...@apache.org> wrote on 15/02/2007 08:49:33:
> +1. Out the door is good, esp. since there haven't been complaints
> about it in the past.
>
> Thanks for doing this Yonik!
>
>
> On Feb 15, 2007, at 11:42 AM, Yonik Seeley wrote:
>
> > Recap:
> > - some contrib modules can't be built without the user downloading
> > more jars themselves
> > - the "demo" in the binary package currently needs to be built by the
> > user, and needs a special build.xml that doesn't rely on lucene source
> > code (oops). I just verified that this was also broken in the 2.0.0
> > release.
> >
> > My opinion:
> > - things aren't worse than in past releases
> > - people can always use the binary release to get pre-built jars
> > - people can always get the source for any version out of our
> > subversion repository
> > - most people's use of the source jar is not to build Lucene, but to
> > study the source and/or point their IDE at it.
> > - not all contrib modules are equal... some like highlighting and
> > stemmers are often used, while others like gdata shouldn't even be
> > rev'd at the same time as lucene.
> >
> > So, given that these aren't code quality issues, I think the biggest
> > benefit to users would be to get this out the door as is, and work on
> > the output of "ant dist src-dist" going forward to tighten things up.
> >
> > -Yonik
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [VOTE] release Lucene 2.1
Posted by Grant Ingersoll <gs...@apache.org>.
+1. Out the door is good, esp. since there haven't been complaints
about it in the past.
Thanks for doing this Yonik!
On Feb 15, 2007, at 11:42 AM, Yonik Seeley wrote:
> Recap:
> - some contrib modules can't be built without the user downloading
> more jars themselves
> - the "demo" in the binary package currently needs to be built by the
> user, and needs a special build.xml that doesn't rely on lucene source
> code (oops). I just verified that this was also broken in the 2.0.0
> release.
>
> My opinion:
> - things aren't worse than in past releases
> - people can always use the binary release to get pre-built jars
> - people can always get the source for any version out of our
> subversion repository
> - most people's use of the source jar is not to build Lucene, but to
> study the source and/or point their IDE at it.
> - not all contrib modules are equal... some like highlighting and
> stemmers are often used, while others like gdata shouldn't even be
> rev'd at the same time as lucene.
>
> So, given that these aren't code quality issues, I think the biggest
> benefit to users would be to get this out the door as is, and work on
> the output of "ant dist src-dist" going forward to tighten things up.
>
> -Yonik
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
--------------------------
Grant Ingersoll
Center for Natural Language Processing
http://www.cnlp.org
Read the Lucene Java FAQ at http://wiki.apache.org/jakarta-lucene/
LuceneFAQ
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [VOTE] release Lucene 2.1
Posted by Yonik Seeley <yo...@apache.org>.
Recap:
- some contrib modules can't be built without the user downloading
more jars themselves
- the "demo" in the binary package currently needs to be built by the
user, and needs a special build.xml that doesn't rely on lucene source
code (oops). I just verified that this was also broken in the 2.0.0
release.
My opinion:
- things aren't worse than in past releases
- people can always use the binary release to get pre-built jars
- people can always get the source for any version out of our
subversion repository
- most people's use of the source jar is not to build Lucene, but to
study the source and/or point their IDE at it.
- not all contrib modules are equal... some like highlighting and
stemmers are often used, while others like gdata shouldn't even be
rev'd at the same time as lucene.
So, given that these aren't code quality issues, I think the biggest
benefit to users would be to get this out the door as is, and work on
the output of "ant dist src-dist" going forward to tighten things up.
-Yonik
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [VOTE] release Lucene 2.1
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
I vote for release of 2.1 as-is... no one really uses that demo stuff
anyway. I'll tackle the binary custom demo build.xml file as soon as
I can and commit that. When folks complain, we can point them to the
new build.xml file and they'll just plop that into a 2.1 binary
release and it'll work.
Erik
On Feb 15, 2007, at 11:21 AM, Yonik Seeley wrote:
> On 2/15/07, Grant Ingersoll <gs...@apache.org> wrote:
>> What's weird, is I don't think much has changed build wise from the
>> last release, yet we all of a sudden noticed all these things.
>
> Yes, I just verified that things are pretty much in the same shape in
> the 2.0.0 release.
> contrib/(ant, lucli, regex) fail to build from the src dist.
>
> -Yonik
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [VOTE] release Lucene 2.1
Posted by Yonik Seeley <yo...@apache.org>.
On 2/15/07, Grant Ingersoll <gs...@apache.org> wrote:
> What's weird, is I don't think much has changed build wise from the
> last release, yet we all of a sudden noticed all these things.
Yes, I just verified that things are pretty much in the same shape in
the 2.0.0 release.
contrib/(ant, lucli, regex) fail to build from the src dist.
-Yonik
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [VOTE] release Lucene 2.1
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Feb 15, 2007, at 6:50 AM, Grant Ingersoll wrote:
>
> On Feb 15, 2007, at 2:55 AM, Chris Hostetter wrote:
>
>>
>> : > I'm not exactly sure if this is show stopper, but when I get the
>> : > binary, the build.xml that is included is not usable b/c it is
>> : > missing common-build.xml.
>>
>> : Oops... I think we should fix this for the release if at all
>> : possible. It is handy for folks to be able to pull down a
>> buildable
>> : archive and rest assured that they are getting something built
>> at the
>> : same time the binary was made.
>>
>> I'm confused ... the binary builds don't even include src/java/ so
>> it's
>> not a buildable archive by any strech of hte imagination -- how would
>> having the common-build.xml help assure people of anything?
>>
>> i'm not even sure why we inlcude the build.xml in the binary
>> releases.
>>
>
> Yeah, I'm not sure we need the build included for binary releases
> either, I just think it should work if it is included.
>
> What's weird, is I don't think much has changed build wise from the
> last release, yet we all of a sudden noticed all these things.
Sorry, I was thinking by "binary" you meant the -src.(zip|tar.gz)
"binary" and that is where the build was failing. The -src
distributions should be buildable, the purely binary releases should,
of course, be only the .jar files and LICENSE files and such, but no
source (except perhaps the demo code?).
I should shut up and go try the darn build and see what happens since
I had my hands in there once up on a time. Ok.... off to see what's
up first hand....
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [VOTE] release Lucene 2.1
Posted by Grant Ingersoll <gs...@apache.org>.
On Feb 15, 2007, at 2:55 AM, Chris Hostetter wrote:
>
> : > I'm not exactly sure if this is show stopper, but when I get the
> : > binary, the build.xml that is included is not usable b/c it is
> : > missing common-build.xml.
>
> : Oops... I think we should fix this for the release if at all
> : possible. It is handy for folks to be able to pull down a buildable
> : archive and rest assured that they are getting something built at
> the
> : same time the binary was made.
>
> I'm confused ... the binary builds don't even include src/java/ so
> it's
> not a buildable archive by any strech of hte imagination -- how would
> having the common-build.xml help assure people of anything?
>
> i'm not even sure why we inlcude the build.xml in the binary releases.
>
Yeah, I'm not sure we need the build included for binary releases
either, I just think it should work if it is included.
What's weird, is I don't think much has changed build wise from the
last release, yet we all of a sudden noticed all these things.
-Grant
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [VOTE] release Lucene 2.1
Posted by Chris Hostetter <ho...@fucit.org>.
: > I'm not exactly sure if this is show stopper, but when I get the
: > binary, the build.xml that is included is not usable b/c it is
: > missing common-build.xml.
: Oops... I think we should fix this for the release if at all
: possible. It is handy for folks to be able to pull down a buildable
: archive and rest assured that they are getting something built at the
: same time the binary was made.
I'm confused ... the binary builds don't even include src/java/ so it's
not a buildable archive by any strech of hte imagination -- how would
having the common-build.xml help assure people of anything?
i'm not even sure why we inlcude the build.xml in the binary releases.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [VOTE] release Lucene 2.1
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Feb 14, 2007, at 2:18 PM, Grant Ingersoll wrote:
> I'm not exactly sure if this is show stopper, but when I get the
> binary, the build.xml that is included is not usable b/c it is
> missing common-build.xml.
>
> It may not be a big deal, b/c you don't necessarily need to build
> anything since it is a binary release, yet, the first thing I tried
> was ant -projecthelp
>
> So, +1, but we may want to do something about it for the next release.
Oops... I think we should fix this for the release if at all
possible. It is handy for folks to be able to pull down a buildable
archive and rest assured that they are getting something built at the
same time the binary was made.
> Otherwise, I really like how Yonik approached this release by
> putting it up in a staging area for us to try out before making it
> official.
yonik++
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [VOTE] release Lucene 2.1
Posted by Grant Ingersoll <gs...@apache.org>.
I'm not exactly sure if this is show stopper, but when I get the
binary, the build.xml that is included is not usable b/c it is
missing common-build.xml.
It may not be a big deal, b/c you don't necessarily need to build
anything since it is a binary release, yet, the first thing I tried
was ant -projecthelp
So, +1, but we may want to do something about it for the next release.
Otherwise, I really like how Yonik approached this release by putting
it up in a staging area for us to try out before making it official.
-Grant
On Feb 14, 2007, at 1:48 PM, Michael McCandless wrote:
>
> +1
>
> I pulled down the zip & src zip, was able to build the core/demo jars
> from sources, pass all unit tests (clean), and run the
> IndexFiles/SearchFiles demos. I also confirmed the md5's & asc's on
> all 4.
>
> Mike
>
> On Wed, 14 Feb 2007 12:20:56 -0500, "Yonik Seeley" <yo...@apache.org>
> said:
>> Release artifacts for review are at
>> http://people.apache.org/~yonik/staging_area/lucene/
>> Please vote to officially release these packages as Lucene 2.1.
>>
>> -Yonik
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
--------------------------
Grant Ingersoll
Center for Natural Language Processing
http://www.cnlp.org
Read the Lucene Java FAQ at http://wiki.apache.org/jakarta-lucene/
LuceneFAQ
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [VOTE] release Lucene 2.1
Posted by Michael McCandless <lu...@mikemccandless.com>.
+1
I pulled down the zip & src zip, was able to build the core/demo jars
from sources, pass all unit tests (clean), and run the
IndexFiles/SearchFiles demos. I also confirmed the md5's & asc's on
all 4.
Mike
On Wed, 14 Feb 2007 12:20:56 -0500, "Yonik Seeley" <yo...@apache.org>
said:
> Release artifacts for review are at
> http://people.apache.org/~yonik/staging_area/lucene/
> Please vote to officially release these packages as Lucene 2.1.
>
> -Yonik
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [VOTE] release Lucene 2.1
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Feb 15, 2007, at 8:10 AM, DM Smith wrote:
> I don't think that one should ever expect to build from a binary
> package. Even if one could.
Here's the hitch... the demo code that comes with Lucene, as sad as
it is :(, gets shipped as source code in the binary distribution.
This makes sense. What I've just seen is that we distribute
build.xml but not common-build.xml and thus the build doesn't work,
but even copying common-build.xml to that directory the build still
fails as its trying to build Lucene itself without source code. We
need a custom build.xml for the demo code, I think. I can whip
something like that up, but it'll take me a week or so to squeeze it
in. I don't think we should hold up a release for this issue - I
suspect we shipped Lucene 2.0 like this as well.
On the positive side, the source distribution works fine (from trunk):
~/dev/lucene/dist/src/lucene-2.2-dev erik$ ant
Buildfile: build.xml
javacc-uptodate-check:
javacc-notice:
init:
clover.setup:
clover.info:
[echo]
[echo] Clover not found. Code coverage reports disabled.
[echo]
clover:
common.compile-core:
[mkdir] Created dir: /Users/erik/dev/lucene/dist/src/lucene-2.2-
dev/build/classes/java
[javac] Compiling 204 source files to /Users/erik/dev/lucene/
dist/src/lucene-2.2-dev/build/classes/java
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
compile-core:
[rmic] RMI Compiling 1 class to /Users/erik/dev/lucene/dist/src/
lucene-2.2-dev/build/classes/java
jar-core:
[jar] Building jar: /Users/erik/dev/lucene/dist/src/lucene-2.2-
dev/build/lucene-core-2.2-dev.jar
default:
BUILD SUCCESSFUL
Total time: 5 seconds
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [VOTE] release Lucene 2.1
Posted by DM Smith <dm...@gmail.com>.
I've been reading this thread and here is my take as I will be
updating jpackage for a 2.1 release.
The content of a binary distribution differs widely as to what is
included in it. It obviously needs to have one or more jar files that
represent the product. Beyond that I have never really cared. Some
include the source; others the javadoc; others readme, licenses,
changes and the like; etc.
I don't think that one should ever expect to build from a binary
package. Even if one could.
What is necessary for JPackage (or any other build system) is the
pristine SOURCE package from which the jars, javadoc, readmes,
licenses and the like can be generated or obtained.
For JPackage, I have needed to patch the source so that it can build
(e.g. JPackage 1.6 and 1.7 are Java 1.4.2 distributions and the Java
5 specific stuff needs to be excuded or modified).
So for me, the question of a release is whether I can package the
source package for JPackage and whether I can use the binary package
as is when I don't grab it from JPackage.
From this thread, I gather Lucene 2.1 is ready enough for me.
On Feb 14, 2007, at 12:20 PM, Yonik Seeley wrote:
> Release artifacts for review are at
> http://people.apache.org/~yonik/staging_area/lucene/
> Please vote to officially release these packages as Lucene 2.1.
>
> -Yonik
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
RE: [VOTE] release Lucene 2.1
Posted by Steven Parkes <st...@esseff.org>.
Okay, +1
Had no problem verifying anything else on either Gentoo or Windows XP
Pro, both x64.
I'll create a JIRA to get the files in. Even if we don't distribute the
raw file (which I couldn't find any other projects which do, though I
didn't look too hard), I did notice that other projects always add the
files to their META-INF.
-----Original Message-----
From: yseeley@gmail.com [mailto:yseeley@gmail.com] On Behalf Of Yonik
Seeley
Sent: Wednesday, February 14, 2007 12:05 PM
To: java-dev@lucene.apache.org
Subject: Re: [VOTE] release Lucene 2.1
OK, I've removed the raw jar, and a maven release will have to wait
until someone fixes things up. The normal release can proceed.
I promised to be release-manager-lite... I'll do the release
mechanics, but I don't currently have time to do much else.
-Yonik
On 2/14/07, Steven Parkes <st...@esseff.org> wrote:
> I'm new to the release process, so I'm trying to understand it at the
> same time as checking out the candidate.
>
> One thing I noticed is that the raw jar doesn't contain LICENSE or
> NOTICE files, a la http://www.apache.org/dev/release.html. To wit:
>
> Can I Distribute A Raw Artifact?
>
> ASF distributions typically contain additional material
together
> with the artifacts. This material may include documentation concerning
> the release but must contain LICENSE and NOTICE files.
>
> Raw artifacts may be distributed if they contain LICENSE and
> NOTICE files. For example, the java artifact format is based on a
> compressed directory structure and those projects wishing to
distribute
> raw jars place LICENSE and NOTICE files in the META-INF directory
within
> the jar.
>
>
> I was also wondering about highlighting the impact of the index file
> format change somewhere obvious ... though I don't now where that
would
> be. Perhaps in the release announcement?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [VOTE] release Lucene 2.1
Posted by Yonik Seeley <yo...@apache.org>.
OK, I've removed the raw jar, and a maven release will have to wait
until someone fixes things up. The normal release can proceed.
I promised to be release-manager-lite... I'll do the release
mechanics, but I don't currently have time to do much else.
-Yonik
On 2/14/07, Steven Parkes <st...@esseff.org> wrote:
> I'm new to the release process, so I'm trying to understand it at the
> same time as checking out the candidate.
>
> One thing I noticed is that the raw jar doesn't contain LICENSE or
> NOTICE files, a la http://www.apache.org/dev/release.html. To wit:
>
> Can I Distribute A Raw Artifact?
>
> ASF distributions typically contain additional material together
> with the artifacts. This material may include documentation concerning
> the release but must contain LICENSE and NOTICE files.
>
> Raw artifacts may be distributed if they contain LICENSE and
> NOTICE files. For example, the java artifact format is based on a
> compressed directory structure and those projects wishing to distribute
> raw jars place LICENSE and NOTICE files in the META-INF directory within
> the jar.
>
>
> I was also wondering about highlighting the impact of the index file
> format change somewhere obvious ... though I don't now where that would
> be. Perhaps in the release announcement?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
RE: [VOTE] release Lucene 2.1
Posted by Steven Parkes <st...@esseff.org>.
I'm new to the release process, so I'm trying to understand it at the
same time as checking out the candidate.
One thing I noticed is that the raw jar doesn't contain LICENSE or
NOTICE files, a la http://www.apache.org/dev/release.html. To wit:
Can I Distribute A Raw Artifact?
ASF distributions typically contain additional material together
with the artifacts. This material may include documentation concerning
the release but must contain LICENSE and NOTICE files.
Raw artifacts may be distributed if they contain LICENSE and
NOTICE files. For example, the java artifact format is based on a
compressed directory structure and those projects wishing to distribute
raw jars place LICENSE and NOTICE files in the META-INF directory within
the jar.
I was also wondering about highlighting the impact of the index file
format change somewhere obvious ... though I don't now where that would
be. Perhaps in the release announcement?
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [VOTE] release Lucene 2.1
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
+1
On Feb 14, 2007, at 12:20 PM, Yonik Seeley wrote:
> Release artifacts for review are at
> http://people.apache.org/~yonik/staging_area/lucene/
> Please vote to officially release these packages as Lucene 2.1.
>
> -Yonik
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [VOTE] release Lucene 2.1
Posted by Chris Hostetter <ho...@fucit.org>.
: Unless expected out-of-the-box behavior for the source pack
: includes compilable contrib/*.
contrib/*/lib is explicitly excluded from srource distributions in the
build.xml ...
<patternset id="src.dist.patterns"
includes="src/,build.xml,*build*.xml,docs/,*.txt,contrib/,"
excludes="contrib/*/lib/,src/site/build/"
...this really suprises me, since i thought the source releases are
suppose to inlcude everything you need to build with (there isn't even any
info on what jars the user needs to download to make the contribs work)
but it appears to be the "expected" behavior.
: > 1 file only in 507610:
: > index.html
the top level index.html file should *not* be in any releases
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [VOTE] release Lucene 2.1
Posted by Doron Cohen <DO...@il.ibm.com>.
+1
Unless expected out-of-the-box behavior for the source pack
includes compilable contrib/*.
So I'm not sure if this is a stopper... more details below...
---------------------------------------------------
> Checking md5's and asc's of 3 of the files was OK.
> lucene-2.1.0-src.zip
> lucene-2.1.0.zip
> lucene-core-2.1.0.jar
Also, all tests pass on Win32/XP, JDK HotSpot 1.5.0_06.
Also, tests pass when the core jar is used (instead of
classes). This is of less importance now since it was already
decided not to include the core jar in this release. However
if future releases would include the jar, it would probably
make sense to have a test target that is using the core-jar.
> Comparing the content of lucene-2.1.0-src.zip with revision 507610
> 6 folders and files only in 507610:
> [1] contrib/ant/lib
> [4] contrib/benchmark/lib
> [9] contrib/gdata-server/lib
> [1] contrib/lucli/lib
> [1] contrib/regex/lib index.html
> 1 file only in 507610:
> index.html
>
> As result of these differences the following are
> passing in 507610 but fail in 2.1.0 (src):
>
> "ant compile" from contrib/benchmark (after "ant clean: from trunk).
> "ant" from contrib/gdata (after "ant clean: from trunk)
> (actually it failed in 507610 too, but later, because I used jdk
> 1.4.)
In fact I used jdk 1.5, and contrib/gdata failed to compile because it
depends in contrib/ant. (That is, it now fails even if the missing lib
and jars are manually added, and even if built with "ant
-Djavac.source=1.5".)
> "ant" from contrib/lucli (after "ant clean: from trunk)
> "ant" from contrib/regexp (after "ant clean: from trunk)
Bottom line, if expected out-of-the-box behavior for the source pack
includes compilable contrib/*, seems this is not the case now. I am
not sure if this is a stopper or not.
> yseeley@gmail.com wrote on 14/02/2007 09:20:56:
>
> > Release artifacts for review are at
> > http://people.apache.org/~yonik/staging_area/lucene/
> > Please vote to officially release these packages as Lucene 2.1.
> >
> > -Yonik
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [VOTE] release Lucene 2.1
Posted by Doron Cohen <DO...@il.ibm.com>.
Checking md5's and asc's of 3 of the files was OK.
lucene-2.1.0-src.zip
lucene-2.1.0.zip
lucene-core-2.1.0.jar
Comparing the content of lucene-2.1.0-src.zip with revision 507610
shows some differences:
3 folders and files only in 2.1.0:
[1] contrib/db/bdb/lib
[2] contrib/db/bdb-je/lib
[9] contrib/gdata-server/ext-libs
6 folders and files only in 507610:
[1] contrib/ant/lib
[4] contrib/benchmark/lib
[9] contrib/gdata-server/lib
[1] contrib/lucli/lib
[1] contrib/regex/lib index.html
1 file only in 507610:
index.html
As result of these differences the following are
passing in 507610 but fail in 2.1.0 (src):
"ant compile" from contrib/benchmark (after "ant clean: from trunk).
"ant" from contrib/gdata (after "ant clean: from trunk)
(actually it failed in 507610 too, but later, because I used jdk
1.4.)
"ant" from contrib/lucli (after "ant clean: from trunk)
"ant" from contrib/regexp (after "ant clean: from trunk)
Is this something that should be fixed before the release?
Doron
yseeley@gmail.com wrote on 14/02/2007 09:20:56:
> Release artifacts for review are at
> http://people.apache.org/~yonik/staging_area/lucene/
> Please vote to officially release these packages as Lucene 2.1.
>
> -Yonik
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org