I'm really ambivalent about Maven. Having just converted Mahout to
it, am using it for some other projects and used it quite a bit in the
past, I am still on the fence (although I am mostly happy w/ it for
Mahout). I keep being lured in by the promise of it (dep. management,
convention ov
On Fri, Apr 10, 2009 at 02:25, Chris Hostetter wrote:
> Or just make it trivial to get all jars that fit a given profile w/o
> actually merging those jars into an uber-jar ... does maven's
> dependency management have any like "bundles" or "virtual packages" so
> we could publish a "lucene-all-ana
: If there are any serious moves to reorganize things, we should at least
: consider the benefits of maven.
+1
we can certainly do a lot to improve things just by refacting stuff from
core into contrib, and improving the visibility of contribs and
documentation about contribs -- but if we're
: We've been doing this using just one source tree (like in Lucene), and
: instead ensuring the separation using the build system. We did not, like you
I think you are missunderstanding my previous comment ... Lucene-Java does
not currenlty have one source tree in the sense that someone else
su
: Then during build we can package up certain combinations. I think
: there should be sub-kitchen-sink jars by area, eg a jar that contains
: all analyzers/tokenstreams/filters, all queries/filters, etc.
Or just make it trivial to get all jars that fit a given profile w/o
actually merging those
I haven't paid attention, as I looked first for the build.xml on trunk
as we already are using maven, Ryan's approach is the way to go, IMHO
On Wed, Apr 1, 2009 at 7:00 PM, Earwin Burrfoot wrote:
> Lucene is in fact already available through maven. poms do exist, all
> what is left is to fi
Lucene is in fact already available through maven. poms do exist, all
what is left is to find who manages them and releases.
On Thu, Apr 2, 2009 at 01:40, Douglas Campos wrote:
> +1 on maven, and I volunteer to aid in the creation of the maven project
> files (pom's)
>
> On Wed, Apr 1, 2009 at 11
+1 on maven, and I volunteer to aid in the creation of the maven project
files (pom's)
On Wed, Apr 1, 2009 at 11:02 AM, Ryan McKinley wrote:
>
>> we can have fine grained modularity w/o having second class citizens, and
>> we can achieve it without needing to make radical changes -- but putting
we can have fine grained modularity w/o having second class
citizens, and
we can achieve it without needing to make radical changes -- but
putting
more stuff into "core" isn't going to help us get there.
I totally agree.
However, just to stir the pot (and assuming you are well rested), I
On Mon, Mar 30, 2009, Chris Hostetter wrote about "Re: Modularization":
> code isolation (by directory hierarchy) is hte best way i've seen to
> ensure modularization, and protect against inadvertent dependency
> bleeding.
>...
> it's certainly possible to
On Mon, Mar 30, 2009 at 7:31 PM, Chris Hostetter
wrote:
> code isolation (by directory hierarchy) is hte best way i've seen to
> ensure modularization, and protect against inadvertent dependency
> bleeding.
OK I agree this (divorced top-level directories) is a great way to
enfo
ypes of analyzers,
> etc...)
> - still need to deal with contribs that have external dependencies
> - still need to deal with contribs that require future versions of
> langauge (Java1.7 when core is still 1.5 compat)
> - users need better guidance about "why" something is a c
On 3/31/09 1:31 AM, Chris Hostetter wrote:
code isolation (by directory hierarchy) is hte best way i've seen to
ensure modularization, and protect against inadvertent dependency
bleeding.
+1. That's actually what I meant with "one-to-one mapping between the
packaging and the
something is a contrib
(additional functionality, alternate functionality, example of use, tool,
etc...)
- while we should maintain/increase modularization, documentation should
make features of contribs more promonent without stressing the isolation
resulting from code modularization.
- we shoul
On 23-Mar-09, at 2:41 PM, Michael McCandless wrote:
I agree, but at least we need some clear criteria so the future
decision process is more straightforward. Towards that... it seems
like there are good reasons why something should be put into contrib:
* It uses a version of JDK higher than
>> I think we are considering this for Lucene 3.0 (should be the
>> release after next) which will allow Java 1.5.
>
> So where are you going to put 1.6 and 1.7 contribs?
This is a good point: core Lucene must remain on "old" JREs, but we
should not force all contrib packages to do so.
> - contri
On Mon, Mar 23, 2009 at 22:13, Mark Miller wrote:
> Earwin Burrfoot wrote:
>>>
>>> - contrib has always had a lower bar and stuff was committed under
>>> that lower bar - there should be no blanket promotion.
>>> - contrib items may have different dependencies... putting it all
>>> under the same
Earwin Burrfoot wrote:
- contrib has always had a lower bar and stuff was committed under
that lower bar - there should be no blanket promotion.
- contrib items may have different dependencies... putting it all
under the same source root can make a developers job harder
- many contrib items are l
> - contrib has always had a lower bar and stuff was committed under
> that lower bar - there should be no blanket promotion.
> - contrib items may have different dependencies... putting it all
> under the same source root can make a developers job harder
> - many contrib items are less related to
Are you arguing for no change Yonik? I agree with all of your points in
any case.
What appeals to me most so far is:
Take the best of contrib and up its status to something like "modules".
Equal to core, different requirements, dependencies, etc. Perhaps take
queryparser out of core, but fran
On Mon, Mar 23, 2009 at 11:10 AM, Michael McCandless
wrote:
> 4. Move contrib/* under src/java/*, updating the javadocs to state
> back compatibility promises per class/package.
- contrib has always had a lower bar and stuff was committed under
that lower bar - there should be no blanket
Michael Busch wrote:
>> And I don't think the sudden separation of "core" vs "contrib"
>> should be so prominent (or even visible); it's really a detail of
>> how we manage source control.
>
>> When looking at the website I'd like read that Lucene can do hit
>> highlighting, powerful query parsin
On 3/21/09 1:36 PM, Michael McCandless wrote:
And I don't think the sudden separation of "core" vs "contrib" should
be so prominent (or even visible); it's really a detail of how we
manage source control.
When looking at the website I'd like read that Lucene can do hit
highlighting, powerful que
On Mar 21, 2009, at 7:23 AM, Grant Ingersoll wrote:
On Mar 21, 2009, at 11:26 AM, Michael McCandless wrote:
What if (maybe for 3.0, since we can mix in 1.5 sources at that
point?) we change how Lucene is bundled, such that core queries and
contrib/query/* are in one JAR (lucene-query-3.0.jar)
> Maybe he actually ends up buying LIA(2) :)
LIA/2 suffers the same false dichotomy, and it drives me crazy there
too: we put all "contrib" packages in a different chapter, even though
it'd make much more sense to cover all analyzers in one chapter, all
queries in one chapter, etc.
I find myself
On 3/21/09 11:26 AM, Michael McCandless wrote:
I think we are mixing up source code modularity with
bundling/packaging.
Honestly, I would not mind much where the source code lives in svn, so
long as a developer, upon downloading Lucene 2.9, can go to *one*
place (javadocs) for Lucene's "queries
On Mar 21, 2009, at 11:26 AM, Michael McCandless wrote:
What if (maybe for 3.0, since we can mix in 1.5 sources at that
point?) we change how Lucene is bundled, such that core queries and
contrib/query/* are in one JAR (lucene-query-3.0.jar)? And
lucene-analyzers-3.0.jar would include contrib/a
> Honestly, I would not mind much where the source code lives in svn, so
> long as a developer, upon downloading Lucene 2.9, can go to *one*
> place (javadocs) for Lucene's "queries & filters" and see
> {Int,Long}NumberRangeFilter in there.
>
> We are not there today: a developer must first reali
I think we are mixing up source code modularity with
bundling/packaging.
Honestly, I would not mind much where the source code lives in svn, so
long as a developer, upon downloading Lucene 2.9, can go to *one*
place (javadocs) for Lucene's "queries & filters" and see
{Int,Long}NumberRangeFilter i
On 3/21/09 12:27 AM, Michael Busch wrote:
+1. I'd love to see Lucene going into such a direction.
However, I'm a little worried about contrib's reputation. I think it
contains components with differing levels of activity, maturity and
support.
So maybe instead of moving things from core into c
30 matches
Mail list logo
