-1 from me on dropping Maven artifacts.

I find it curious that on the verge of fixing the broken Maven artifacts situation (LUCENE-2657), there is a big push for a divorce.

Robert, I agree we should have a way to test the "magic" artifacts.  I'm working on it.  Your other objection is the work involved - you don't want to do it.  I will do the work.

We should not drop Maven support when there are committers willing to support it.  I obviously count myself in that camp.

Steve

Robert Muir <[EMAIL PROTECTED]> wrote:
On Sun, Jan 16, 2011 at 12:03 PM, Shai Erera <[EMAIL PROTECTED]> wrote:
> Hey
>
> Wearing on my rebel hat today, I'd like to propose we drop maven support
> from our release process / build system. I've always read about the maven
> artifacts never being produced right, and never working (or maybe never is a
> too harsh word).
>
> I personally don't understand why we struggle to support Maven. I'm
> perfectly fine if we say that "Lucene/Solr uses SVN, Ant and release a bunch
> of .jar files you can embed in your project". Who says we need to support
> Maven? And if so, why only Maven (I'm kidding !)?
>
> Are you with me? :)
>

I am, the last time i suggested releasing 3.1, a 99-email thread about
maven ensued that basically left me frustrated and not wanting to work
towards a release.

We still don't have a "test-maven" target that does even trivial
verification of these magical artifacts that most of us don't
understand... like any other functionality we have, we should have
tests so that the release manager can verify things are working before
the release.  If we have a "contrib" thats unmaintained with no tests,
would we let it block a release?

I don't think we should let the maven problems hold lucene releases hostage.

---------------------------------------------------------------------

Well ... you raise interesting points. So if a committer would be willing to
support GIT, RTC, and whatever (just making up scenarios), would we allow
all of those to exist within Lucene?

I think the reasonable solution is to have a modules/maven package, with
build.xml that generates whatever needs to be generated. Whoever cares about
maven should run the proper Ant targets, just like whoever cares about
Eclipse/IDEA can now run "ant eclipse/idea". We'd have an "ant maven". If
that's what you intend doing in 2657 then fine.

The release manager need not be concerned w/ Maven (or whatever) artifacts,
they are not officially published anywhere, and everyone's happy. As long as
all tests pass, the release is good to go.

Is that better?

Shai

On Sun, Jan 16, 2011 at 8:05 PM, Steven A Rowe <[EMAIL PROTECTED]> wrote:

> -1 from me on dropping Maven artifacts.
>
> I find it curious that on the verge of fixing the broken Maven artifacts
> situation (LUCENE-2657), there is a big push for a divorce.
>
> Robert, I agree we should have a way to test the "magic" artifacts.  I'm
> working on it.  Your other objection is the work involved - you don't want
> to do it.  I will do the work.
>
> We should not drop Maven support when there are committers willing to
> support it.  I obviously count myself in that camp.
>
> Steve
>
> Robert Muir <[EMAIL PROTECTED]> wrote:
>
>
> On Sun, Jan 16, 2011 at 12:03 PM, Shai Erera <[EMAIL PROTECTED]> wrote:
> > Hey
> >
> > Wearing on my rebel hat today, I'd like to propose we drop maven support
> > from our release process / build system. I've always read about the maven
> > artifacts never being produced right, and never working (or maybe never
> is a
> > too harsh word).
> >
> > I personally don't understand why we struggle to support Maven. I'm
> > perfectly fine if we say that "Lucene/Solr uses SVN, Ant and release a
> bunch
> > of .jar files you can embed in your project". Who says we need to support
> > Maven? And if so, why only Maven (I'm kidding !)?
> >
> > Are you with me? :)
> >
>
> I am, the last time i suggested releasing 3.1, a 99-email thread about
> maven ensued that basically left me frustrated and not wanting to work
> towards a release.
>
> We still don't have a "test-maven" target that does even trivial
> verification of these magical artifacts that most of us don't
> understand... like any other functionality we have, we should have
> tests so that the release manager can verify things are working before
> the release.  If we have a "contrib" thats unmaintained with no tests,
> would we let it block a release?
>
> I don't think we should let the maven problems hold lucene releases
> hostage.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

On 1/16/11 11:08 AM, Shai Erera wrote:
> I think the reasonable solution is to have a modules/maven package,
> with build.xml that generates whatever needs to be generated. Whoever
> cares about maven should run the proper Ant targets, just like whoever
> cares about Eclipse/IDEA can now run "ant eclipse/idea". We'd have an
> "ant maven". If that's what you intend doing in 2657 then fine.
>

The person "who cares about maven" is the one who puts a few lines of
xml into their ivy or maven config files, which downloads automatically
the specified version from a central repository.  It's a very convenient
thing and stopping to publish artifacts will require everyone who has
such a build system setup to change the way they get their Lucene jar files.

There is an impressive amount of tools available in maven repos, it'd
probably not be good if something as popular as Lucene was missing there.

I don't think any user needs the ability to run an ant target on
Lucene's sources to produce maven artifacts - what they want is
published artifacts in a central repo.

I personally don't need Lucene to be in such a repo, but I wanted to
point out why I think it can be very useful.

  Michael

---------------------------------------------------------------------

On 1/17/2011 at 1:53 AM, Michael Busch wrote:
> I don't think any user needs the ability to run an ant target on
> Lucene's sources to produce maven artifacts

I want to be able to make modifications to the Lucene source, install Maven snapshot artifacts in my local repository, then depend on those snapshots from other projects.  I doubt I'm alone.

Steve

On Mon, Jan 17, 2011 at 11:06 AM, Steven A Rowe <[EMAIL PROTECTED]> wrote:
> On 1/17/2011 at 1:53 AM, Michael Busch wrote:
>> I don't think any user needs the ability to run an ant target on
>> Lucene's sources to produce maven artifacts
>
> I want to be able to make modifications to the Lucene source, install Maven snapshot artifacts in my local repository, then depend on those snapshots from other projects.  I doubt I'm alone.
>

And personally I would be totally fine with this, where maven is in
/dev-tools, just like eclipse and idea configuration, and we can even
put a whole README.txt in there that says "these are tools for
developers and if they start rotting they will be deleted without a
second thought".

but requiring special artifacts is a different story, its my
understanding that in anything but a "hello world" maven project you
need your own local repository anyway. So such a person can simply
install their own artifacts with /dev-tools into their local
repository... problem solved.

---------------------------------------------------------------------

On 1/17/2011 at 11:25 AM, Robert Muir wrote:
> On Mon, Jan 17, 2011 at 11:06 AM, Steven A Rowe <[EMAIL PROTECTED]> wrote:
> > On 1/17/2011 at 1:53 AM, Michael Busch wrote:
> >> I don't think any user needs the ability to run an ant target on
> >> Lucene's sources to produce maven artifacts
> >
> > I want to be able to make modifications to the Lucene source, install
> > Maven snapshot artifacts in my local repository, then depend on those
> > snapshots from other projects.  I doubt I'm alone.
>
> And personally I would be totally fine with this, where maven is in
> /dev-tools, just like eclipse and idea configuration, and we can even
> put a whole README.txt in there that says "these are tools for
> developers and if they start rotting they will be deleted without a
> second thought".
>
> but requiring special artifacts is a different story

I have it wrong in LUCENE-2657.  It creates "special" artifacts intended for publishing via public Maven repositories.  But for the purposes of publishing (as opposed to locally modified sources), the artifacts published through public Maven repositories should be *exactly* the same ones produced by the Ant build, with the obvious exception of the POMs.  This is the model used by previous releases, and if we continue the tradition of publishing Maven artifacts (as we have since the 1.9.1 release), the model should not change.

Steve

On Jan 17, 2011, at 8:06 AM, Steven A Rowe wrote:

> On 1/17/2011 at 1:53 AM, Michael Busch wrote:
>> I don't think any user needs the ability to run an ant target on
>> Lucene's sources to produce maven artifacts
>
> I want to be able to make modifications to the Lucene source, install Maven snapshot artifacts in my local repository, then depend on those snapshots from other projects.  I doubt I'm alone.

+1, you're not. The only way I've ever used Lucene has been via a Maven dependency, and that was the original way I found it starting way back in lucene-core-2.0.0. If Lucene wasn't in Maven, it would be a HUGE disappointment, and an impediment towards using it.

Cheers,
Chris

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: [EMAIL PROTECTED]
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
---------------------------------------------------------------------

You're not alone. :)
But, I bet, much more people would like to skip that step and have
their artifacts downloaded from central.

On Mon, Jan 17, 2011 at 19:06, Steven A Rowe <[EMAIL PROTECTED]> wrote:
> On 1/17/2011 at 1:53 AM, Michael Busch wrote:
>> I don't think any user needs the ability to run an ant target on
>> Lucene's sources to produce maven artifacts
>
> I want to be able to make modifications to the Lucene source, install Maven snapshot artifacts in my local repository, then depend on those snapshots from other projects.  I doubt I'm alone.
>
> Steve
>

--
Kirill Zakharenko/Кирилл Захаренко ([EMAIL PROTECTED])
Phone: +7 (495) 683-567-4
ICQ: 104465785

---------------------------------------------------------------------

On Mon, Jan 17, 2011 at 11:17 AM, Earwin Burrfoot <[EMAIL PROTECTED]> wrote:
> You're not alone. :)
> But, I bet, much more people would like to skip that step and have
> their artifacts downloaded from central.

Maybe, but perhaps they will need to compromise and use jar files or
install into their local themselves, because currently they have to
use svn checkout since we are letting maven issues prevent us from
releasing.

I think its been too long since we had a release, I'm gonna forget
maven exists and start working towards a release. I'll cross my
fingers and hope that I can get 3 +1 votes.

---------------------------------------------------------------------

On 1/17/11 8:06 AM, Steven A Rowe wrote:
> On 1/17/2011 at 1:53 AM, Michael Busch wrote:
>> I don't think any user needs the ability to run an ant target on
>> Lucene's sources to produce maven artifacts
> I want to be able to make modifications to the Lucene source, install Maven snapshot artifacts in my local repository, then depend on those snapshots from other projects.  I doubt I'm alone.
>

This is something I would feel comfortable not supporting in Lucene
out-of-the-box, because if someone needs to use modified sources it's
not unreasonable to expect that they can also create their own pom files
for the modified jars.

I do think though that we should keep publishing "official" artifacts to
a central repo.

  Michael

---------------------------------------------------------------------

On 1/17/2011 at 3:05 PM, Michael Busch wrote:
> On 1/17/11 8:06 AM, Steven A Rowe wrote:
> > On 1/17/2011 at 1:53 AM, Michael Busch wrote:
> >> I don't think any user needs the ability to run an ant target on
> >> Lucene's sources to produce maven artifacts
> > I want to be able to make modifications to the Lucene source, install
> > Maven snapshot artifacts in my local repository, then depend on those
> > snapshots from other projects.  I doubt I'm alone.
> >
>
> This is something I would feel comfortable not supporting in Lucene
> out-of-the-box, because if someone needs to use modified sources it's
> not unreasonable to expect that they can also create their own pom files
> for the modified jars.

This makes zero sense to me - no one will ever make their own POMs, except maybe the empty shells Maven will auto-create for you when run the install:install-file goal.

The key thing that LUCENE-2657 provides is POMs that can be verified correct via Maven itself - when Maven performs a build, the POMs are checked for correctness, and if the build fails, you can tell something is wrong.  Anything short of that won't cut it long term.

Maybe from your perspective building the project with the POMs is unnecessary, but from mine it is a *requirement*.  

And, happily IMHO, users get local build/install for free.

Steve

On 1/17/11 12:27 PM, Steven A Rowe wrote:
> This makes zero sense to me - no one will ever make their own POMs

I did :) (for a different project though).
---------------------------------------------------------------------

Maven is a defacto package/dependency manager for Java. Like it or not.
All "better" tools out there, like Ant+Ivy, or SBT - support Maven repositories.
Lots of people rely on Maven or "better" tools for their builds and as
soon as you're on declarative dependency management train, it's a
bother to "just take a bunch of jars and stuff 'em into your project".
Development tools (Eclipse/IDEA) support auto-downloading and
attaching sources/javadocs for declared dependencies, and people use
this.

> Well ... you raise interesting points. So if a committer would be willing to
> support GIT, RTC, and whatever (just making up scenarios), would we allow
> all of those to exist within Lucene?
So, while having a wild contributor supporting .. dunno .. MacPorts
package for Lucene is a bit crazy, and in the end - nobody will ever
notice,
supporting Maven broadens your audience and makes it happy (even those
guys, who are not into Maven itself).

> I think the reasonable solution is to have a modules/maven package, with
> build.xml that generates whatever needs to be generated. Whoever cares about
> maven should run the proper Ant targets, just like whoever cares about
> Eclipse/IDEA can now run "ant eclipse/idea". We'd have an "ant maven". If
> that's what you intend doing in 2657 then fine.
That should be some person amongst the committers, be it a part of
default release process or not.
I believe publishing Maven artefact is somewhat nontrivial for a
person not related to the project in question.

> The release manager need not be concerned w/ Maven (or whatever) artifacts,
> they are not officially published anywhere, and everyone's happy. As long as
> all tests pass, the release is good to go.
>
> Is that better?
>
> Shai
>
> On Sun, Jan 16, 2011 at 8:05 PM, Steven A Rowe <[EMAIL PROTECTED]> wrote:
>>
>> -1 from me on dropping Maven artifacts.
>>
>> I find it curious that on the verge of fixing the broken Maven artifacts
>> situation (LUCENE-2657), there is a big push for a divorce.
>>
>> Robert, I agree we should have a way to test the "magic" artifacts. ��I'm
>> working on it.  Your other objection is the work involved - you don't want
>> to do it.  I will do the work.
>>
>> We should not drop Maven support when there are committers willing to
>> support it.  I obviously count myself in that camp.
>>
>> Steve
>>
>> Robert Muir <[EMAIL PROTECTED]> wrote:
>>
>>
>> On Sun, Jan 16, 2011 at 12:03 PM, Shai Erera <[EMAIL PROTECTED]> wrote:
>> > Hey
>> >
>> > Wearing on my rebel hat today, I'd like to propose we drop maven support
>> > from our release process / build system. I've always read about the
>> > maven
>> > artifacts never being produced right, and never working (or maybe never
>> > is a
>> > too harsh word).
>> >
>> > I personally don't understand why we struggle to support Maven. I'm
>> > perfectly fine if we say that "Lucene/Solr uses SVN, Ant and release a
>> > bunch
>> > of .jar files you can embed in your project". Who says we need to
>> > support
>> > Maven? And if so, why only Maven (I'm kidding !)?
>> >
>> > Are you with me? :)
>> >
>>
>> I am, the last time i suggested releasing 3.1, a 99-email thread about
>> maven ensued that basically left me frustrated and not wanting to work
>> towards a release.
>>
>> We still don't have a "test-maven" target that does even trivial
>> verification of these magical artifacts that most of us don't
>> understand... like any other functionality we have, we should have
>> tests so that the release manager can verify things are working before
>> the release.  If we have a "contrib" thats unmaintained with no tests,
>> would we let it block a release?
>>
>> I don't think we should let the maven problems hold lucene releases

Kirill Zakharenko/Кирилл Захаренко ([EMAIL PROTECTED])
Phone: +7 (495) 683-567-4
ICQ: 104465785

On Sun, Jan 16, 2011 at 3:34 PM, Earwin Burrfoot <[EMAIL PROTECTED]> wrote:
> Lots of people rely on Maven or "better" tools for their builds and as
> soon as you're on declarative dependency management train, it's a
> bother to "just take a bunch of jars and stuff 'em into your project".

Sure, and i bet its even more of a bother for them to 'svn checkout',
because again this whole maven crap seems be on the path to prevent us
from making a release.

At this point, I don't think maven artifacts or even a jar file is
required. All that is needed is a source .tar.gz with three +1 PMC
votes.

---------------------------------------------------------------------

Hello Lucene/Solr developers,

Speaking from Lucene/Solr user - potential contributor perspective, my
votes are:

-1 for dropping maven artifacts (even +1 for extending number of maven
artifacts https://issues.apache.org/jira/browse/SOLR-1218 )

+1 for using maven as build tool

Regards,
Stevo.

On Sun, Jan 16, 2011 at 9:49 PM, Robert Muir <[EMAIL PROTECTED]> wrote:
> On Sun, Jan 16, 2011 at 3:34 PM, Earwin Burrfoot <[EMAIL PROTECTED]> wrote:
>> Lots of people rely on Maven or "better" tools for their builds and as
>> soon as you're on declarative dependency management train, it's a
>> bother to "just take a bunch of jars and stuff 'em into your project".
>
> Sure, and i bet its even more of a bother for them to 'svn checkout',
> because again this whole maven crap seems be on the path to prevent us
> from making a release.
>
> At this point, I don't think maven artifacts or even a jar file is
> required. All that is needed is a source .tar.gz with three +1 PMC
> votes.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------

uggg -- sorry to see this thread flare up again -- especially since
Steve is actively making great progress on better maven support --
including integration tests and all that jazz.  (LUCENE-2657)

I *think* the consensus from the last thread was:
 1. the release manager does not need to worry about maven
 2. someone else (from lucene) may post maven artifacts
    2a. if the process becomes easy enough, the RM *may* post the artifacts.
 3. There needs to be some test to check if the artifacts are OK.

With Steve's work on LUCENE-2657, things are looking for for #2a and #3

ryan

---------------------------------------------------------------------

On Sun, Jan 16, 2011 at 4:47 PM, Ryan McKinley <[EMAIL PROTECTED]> wrote:
> uggg -- sorry to see this thread flare up again -- especially since
> Steve is actively making great progress on better maven support --
> including integration tests and all that jazz.  (LUCENE-2657)
>
> I *think* the consensus from the last thread was:
>  1. the release manager does not need to worry about maven
>  2. someone else (from lucene) may post maven artifacts
>    2a. if the process becomes easy enough, the RM *may* post the artifacts.
>  3. There needs to be some test to check if the artifacts are OK.
>
> With Steve's work on LUCENE-2657, things are looking for for #2a and #3
>

I think its more complicated than that, someone else (from lucene) may
post artifacts? who votes on these separate maven artifacts?
are you saying that I can pipe /dev/null to some large files and post
them as maven artifacts without 3 +1 votes?

Personally I think we should keep our artifacts to a minimum. Shipping
jars is enough trouble if only source code is really whats needed.

---------------------------------------------------------------------

I don't understand what's so complicated about having an "ant maven" target
in a modules/maven package that generates whatever artifacts are needed. It
can be used by whoever wants to use Maven. Why do we need to "release" those
artifacts? If maven is so important to people, then let's keep it under
modules/maven and give people the right build tools to generate the
artifacts.

Release-wise though, as long as running "ant test" from top-level dir ends
with "BUILD SUCCESSFUL", the release should be good to go. We should publish
the Source, Javadocs and .Jar files. While I agree the latter is not
strictly mandatory, I think it's more widely used (than say Maven) and it
makes consuming Lucene much easier.

Shai

On Mon, Jan 17, 2011 at 12:03 AM, Robert Muir <[EMAIL PROTECTED]> wrote:

> On Sun, Jan 16, 2011 at 4:47 PM, Ryan McKinley <[EMAIL PROTECTED]> wrote:
> > uggg -- sorry to see this thread flare up again -- especially since
> > Steve is actively making great progress on better maven support --
> > including integration tests and all that jazz.  (LUCENE-2657)
> >
> > I *think* the consensus from the last thread was:
> >  1. the release manager does not need to worry about maven
> >  2. someone else (from lucene) may post maven artifacts
> >    2a. if the process becomes easy enough, the RM *may* post the
> artifacts.
> >  3. There needs to be some test to check if the artifacts are OK.
> >
> > With Steve's work on LUCENE-2657, things are looking for for #2a and #3
> >
>
> I think its more complicated than that, someone else (from lucene) may
> post artifacts? who votes on these separate maven artifacts?
> are you saying that I can pipe /dev/null to some large files and post
> them as maven artifacts without 3 +1 votes?
>
> Personally I think we should keep our artifacts to a minimum. Shipping
> jars is enough trouble if only source code is really whats needed.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

On Jan 16, 2011, at 11:21 PM, Shai Erera wrote:
>
> Release-wise though, as long as running "ant test" from top-level dir ends with "BUILD SUCCESSFUL", the release should be good to go. We should publish the Source, Javadocs and .Jar files. While I agree the latter is not strictly mandatory, I think it's more widely used (than say Maven) and it makes consuming Lucene much easier.
>

Agreed. Jars are just plain good for Lucene. When you tell the users that they have to build a release from source, that is a serious usage downer based on any experience I've managed to build up. Technically, you can release very lightly due to the 3 votes thing. But really, Lucene has always been about consensus more than the bare minimum rules. There has always been consensus about jars IMO (until Robert is now rocking the boat ;) ), but to my knowledge, there has never been consensus about Maven.

Personally, I still like the idea of Maven being handled down stream from Lucene with an interested committer placing the poms on apaches servers as his part of that downstream group.

Short of that, I'm still fairly fine with what Ryan said - lets do this release and not think about Maven - if others have it ready when we release, then so be it.

And FYI - the parallel maven build setup still scares me personally :)

- Mark
---------------------------------------------------------------------

Hey

Wearing on my rebel hat today, I'd like to propose we drop maven support
from our release process / build system. I've always read about the maven
artifacts never being produced right, and never working (or maybe never is a
too harsh word).

I personally don't understand why we struggle to support Maven. I'm
perfectly fine if we say that "Lucene/Solr uses SVN, Ant and release a bunch
of .jar files you can embed in your project". Who says we need to support
Maven? And if so, why only Maven (I'm kidding !)?

Are you with me? :)

Shai

On Sun, Jan 16, 2011 at 12:03 PM, Shai Erera <[EMAIL PROTECTED]> wrote:
> Hey
>
> Wearing on my rebel hat today, I'd like to propose we drop maven support
> from our release process / build system. I've always read about the maven
> artifacts never being produced right, and never working (or maybe never is a
> too harsh word).
>
> I personally don't understand why we struggle to support Maven. I'm
> perfectly fine if we say that "Lucene/Solr uses SVN, Ant and release a bunch
> of .jar files you can embed in your project". Who says we need to support
> Maven? And if so, why only Maven (I'm kidding !)?
>
> Are you with me? :)
>

I am, the last time i suggested releasing 3.1, a 99-email thread about
maven ensued that basically left me frustrated and not wanting to work
towards a release.

We still don't have a "test-maven" target that does even trivial
verification of these magical artifacts that most of us don't
understand... like any other functionality we have, we should have
tests so that the release manager can verify things are working before
the release.  If we have a "contrib" thats unmaintained with no tests,
would we let it block a release?

I don't think we should let the maven problems hold lucene releases hostage.

---------------------------------------------------------------------

Hi,

the developers list may not be the right place to find strong maven
supporters. All developers know lucene from inside out and are perfectly fine
to install lucene from whatever artifact.
Those people using maven are your end users, that propably don't even
subscribe to users@.

Thomas Koch, http://www.koch.ro

---------------------------------------------------------------------

On Tue, Jan 18, 2011 at 9:33 AM, Thomas Koch <[EMAIL PROTECTED]> wrote:
> Hi,
>
> the developers list may not be the right place to find strong maven
> supporters. All developers know lucene from inside out and are perfectly fine
> to install lucene from whatever artifact.
> Those people using maven are your end users, that propably don't even
> subscribe to users@.

big +1 for this comment! I have to admit that I am not a big maven fan
and each time I have to use it its a pain in the ass but it is the
de-facto standard for the majority of java projects on this planet so
really there is not much of an option in my opinion. A project like
lucene has to release maven artifacts even if its a pain.

Simon
>
> Thomas Koch, http://www.koch.ro
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------

Out of curiosity, how did the Maven people integrate Lucene before we had
Maven artifacts. To the best of my understanding, we never had proper Maven
artifacts (Steve is working on that in LUCENE-2657).

Shai

On Tue, Jan 18, 2011 at 11:03 AM, Simon Willnauer <
[EMAIL PROTECTED]> wrote:

> On Tue, Jan 18, 2011 at 9:33 AM, Thomas Koch <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > the developers list may not be the right place to find strong maven
> > supporters. All developers know lucene from inside out and are perfectly
> fine
> > to install lucene from whatever artifact.
> > Those people using maven are your end users, that propably don't even
> > subscribe to users@.
>
> big +1 for this comment! I have to admit that I am not a big maven fan
> and each time I have to use it its a pain in the ass but it is the
> de-facto standard for the majority of java projects on this planet so
> really there is not much of an option in my opinion. A project like
> lucene has to release maven artifacts even if its a pain.
>
> Simon
> >
> > Thomas Koch, http://www.koch.ro
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>

Somehow, they were made available since 2.0
-> http://repo2.maven.org/maven2/org/apache/lucene/lucene-core/

The pom's are minimal, sans dependencies, so eg if your project
depends on lucene-spellchecker, lucene-core won't be transitively
included and your build is gonna fail (you therefore had to add
dependency on the core to your project yourself).
But they were enough to download and link jars/sources/javadocs.

On Tue, Jan 18, 2011 at 12:40, Shai Erera <[EMAIL PROTECTED]> wrote:
> Out of curiosity, how did the Maven people integrate Lucene before we had
> Maven artifacts. To the best of my understanding, we never had proper Maven
> artifacts (Steve is working on that in LUCENE-2657).
>
> Shai
>
> On Tue, Jan 18, 2011 at 11:03 AM, Simon Willnauer
> <[EMAIL PROTECTED]> wrote:
>>
>> On Tue, Jan 18, 2011 at 9:33 AM, Thomas Koch <[EMAIL PROTECTED]> wrote:
>> > Hi,
>> >
>> > the developers list may not be the right place to find strong maven
>> > supporters. All developers know lucene from inside out and are perfectly
>> > fine
>> > to install lucene from whatever artifact.
>> > Those people using maven are your end users, that propably don't even
>> > subscribe to users@.
>>
>> big +1 for this comment! I have to admit that I am not a big maven fan
>> and each time I have to use it its a pain in the ass but it is the
>> de-facto standard for the majority of java projects on this planet so
>> really there is not much of an option in my opinion. A project like
>> lucene has to release maven artifacts even if its a pain.
>>
>> Simon
>> >
>> > Thomas Koch, http://www.koch.ro
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>
>

--
Kirill Zakharenko/Кирилл Захаренко ([EMAIL PROTECTED])
Phone: +7 (495) 683-567-4
ICQ: 104465785

---------------------------------------------------------------------

+1 indeed.

I am a long time Lucene user and as long as I remember I consumed Lucene  
as maven artifact.

I even didn't knew that there is such a huge discussion around it within  
the Lucene
dev community. I always took it as given that any bigger open source  
project releases maven
artifacts ourdays.
As pointed out, maven is a de-facto standard at the moment. Not
publishing maven artifacts will cause an outcry amongst the end users.

It also means that someone outside the dev community will at some stage  
create some
pom files and upload the artifact to a (semi-) public repository.
Is it not preferable to control what gets published? If there are errors  
with the published artifacts
it will not affect the person who uploaded it, but everyone will blame the  
Lucene devs.

--Hardy
On Tue, 18 Jan 2011 10:03:50 +0100, Simon Willnauer  
<[EMAIL PROTECTED]> wrote:

> On Tue, Jan 18, 2011 at 9:33 AM, Thomas Koch <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> the developers list may not be the right place to find strong maven
>> supporters. All developers know lucene from inside out and are  
>> perfectly fine
>> to install lucene from whatever artifact.
>> Those people using maven are your end users, that propably don't even
>> subscribe to users@.
>
> big +1 for this comment! I have to admit that I am not a big maven fan
> and each time I have to use it its a pain in the ass but it is the
> de-facto standard for the majority of java projects on this planet so
> really there is not much of an option in my opinion. A project like
> lucene has to release maven artifacts even if its a pain.
>
> Simon

---------------------------------------------------------------------

On Tue, Jan 18, 2011 at 5:29 AM, Hardy Ferentschik <[EMAIL PROTECTED]> wrote:

> It also means that someone outside the dev community will at some stage
> create some
> pom files and upload the artifact to a (semi-) public repository.

This sounds great! this is how open source works, those who care about
it, will make it happen!

---------------------------------------------------------------------

More than one build tools is not way to go, I believe everyone agrees
on that, and that it's not an issue.

Have you guys at least considered making a switch to a build tool that
knows to produce maven artifacts (or enhancing exiting one to take
care of that)? E.g. ant+ivy, gradle, maven itself.

IMO making a switch to a modern build tool or enhancing existing one
to produce maven artifacts at the moment is out of best interest for
any open source project including this one, it will be out of benefit
for projec users/contributors, developers, and project as a whole:
- official project binaries will (continue to) be available to as
large as possible user base so you'll get more potential testers/bug
reporters, and more potential contributors, and more potential
commercial/paying customers which will raise project quality, bring
new ideas, and finance future development
- modern build tools have declarative dependency management so it will
be easier to develop and contribute, at least one won't have to wait
for dependency libs to get downloaded together with sources every time
project is checked out and you will not have to manually download
new/updated 3rd party dependencies, just change build script/metadata
- modern build tools try to be and mostly are non intrusive, and
promote good proven solutions like standard project structure/layout
so it's easier to get started and productive on such projects compared
to projects with custom layout;
- modern build tools are better integrated with current development
infrastructure tools, like IDEs, and continuous integration servers.

This switch would also make it easier to maintain project metadata, to
keep metadata DRY, so that publishing Maven artifacts even if decided
not to be part of main release process, can be done with not much
effort and enough credibility.

If who cares about project maven artifact consumers regardless of size
of that community attitude is accepted and official project stand, and
project community size is not considered as project asset, I don't
understand why project is being published under open source license.

Regards,
Stevo.
On Tue, Jan 18, 2011 at 11:50 AM, Robert Muir <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 18, 2011 at 5:29 AM, Hardy Ferentschik <[EMAIL PROTECTED]> wrote:
>
>> It also means that someone outside the dev community will at some stage
>> create some
>> pom files and upload the artifact to a (semi-) public repository.
>
> This sounds great! this is how open source works, those who care about
> it, will make it happen!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------

On Tue, Jan 18, 2011 at 6:56 AM, Stevo Slavić <[EMAIL PROTECTED]> wrote:
> More than one build tools is not way to go, I believe everyone agrees
> on that, and that it's not an issue.
>
> Have you guys at least considered making a switch to a build tool that
> knows to produce maven artifacts (or enhancing exiting one to take
> care of that)? E.g. ant+ivy, gradle, maven itself.
>

I think its important to look at the build system as supporting
development too, but most features being developed today are against
lucene's core: which has no dependencies at all.

For example, our ant build supports rapidly running the core tests
(splitting them across different jvms in parallel: i've looked at the
support for parallel testing in other build systems like maven and I
think ours is significantly better for our tests).

This compile-test-debug lifecycle is important, for the lucene core
tests its very fast.

So while I might agree with you that for something like Solr
development, perhaps ant+ivy is something worth considering, I think
its overkill and would be a step backwards for lucene, we would only
slow down development.

---------------------------------------------------------------------

It seems to me that if we have a fix for the things that ail our Maven support (Steve's work), that it isn't then the reason for holding up a release and we should just keep them as there are a significant number of users who consume Lucene that way (via the central repository).  I agree that we should not switch our build system,  but supporting the POMs is no different than supporting the IntelliJ/Eclipse generation tools (they are both problematic since they are not automated)  
On Jan 18, 2011, at 7:48 AM, Robert Muir wrote:

> On Tue, Jan 18, 2011 at 6:56 AM, Stevo Slavić <[EMAIL PROTECTED]> wrote:
>> More than one build tools is not way to go, I believe everyone agrees
>> on that, and that it's not an issue.
>>
>> Have you guys at least considered making a switch to a build tool that
>> knows to produce maven artifacts (or enhancing exiting one to take
>> care of that)? E.g. ant+ivy, gradle, maven itself.
>>
>
> I think its important to look at the build system as supporting
> development too, but most features being developed today are against
> lucene's core: which has no dependencies at all.
>
> For example, our ant build supports rapidly running the core tests
> (splitting them across different jvms in parallel: i've looked at the
> support for parallel testing in other build systems like maven and I
> think ours is significantly better for our tests).
>
> This compile-test-debug lifecycle is important, for the lucene core
> tests its very fast.
>
> So while I might agree with you that for something like Solr
> development, perhaps ant+ivy is something worth considering, I think
> its overkill and would be a step backwards for lucene, we would only
> slow down development.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

--------------------------
Grant Ingersoll
http://www.lucidimagination.com
---------------------------------------------------------------------

On Tue, Jan 18, 2011 at 8:54 AM, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
> It seems to me that if we have a fix for the things that ail our Maven support (Steve's work), that it isn't then the reason for holding up a release and we should just keep them as there are a significant number of users who consume Lucene that way (via the central repository).  I agree that we should not switch our build system,  but supporting the POMs is no different than supporting the IntelliJ/Eclipse generation tools (they are both problematic since they are not automated)
>

its totally different in every way! we don't release the
intellij/eclipse stuff, its for internal use only.
additionally, there are no release artifacts generated by these.

---------------------------------------------------------------------

On Tue, Jan 18, 2011 at 17:00, Robert Muir <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 18, 2011 at 8:54 AM, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
>> It seems to me that if we have a fix for the things that ail our Maven support (Steve's work), that it isn't then the reason for holding up a release and we should just keep them as there are a significant number of users who consume Lucene that way (via the central repository).  I agree that we should not switch our build system,  but supporting the POMs is no different than supporting the IntelliJ/Eclipse generation tools (they are both problematic since they are not automated)
>>
>
> its totally different in every way! we don't release the
> intellij/eclipse stuff, its for internal use only.
> additionally, there are no release artifacts generated by these
Latest code from LUCENE-2657 does not generate any new artifacts. It
uploads those you already have (built via ant) to the repo.
--
Kirill Zakharenko/Кирилл Захаренко ([EMAIL PROTECTED])
Phone: +7 (495) 683-567-4
ICQ: 104465785

---------------------------------------------------------------------

On Tue, Jan 18, 2011 at 9:10 AM, Earwin Burrfoot <[EMAIL PROTECTED]> wrote:
> Latest code from LUCENE-2657 does not generate any new artifacts. It
> uploads those you already have (built via ant) to the repo.
>

yep, thats releasing artifacts. thats the whole point of this email
thread (read the title, thanks)

the intellij/eclipse stuff is just unreleased stuff that sits in our
SVN. it doesnt get uploaded anywhere.

---------------------------------------------------------------------

I still don't see why you care so much.  You have people willing to maintain it and it is no sweat off your back and it is used by a pretty large chunk of downstream users.  And don't tell me it is what holds up releases b/c it simply isn't true.
On Jan 18, 2011, at 9:12 AM, Robert Muir wrote:

> On Tue, Jan 18, 2011 at 9:10 AM, Earwin Burrfoot <[EMAIL PROTECTED]> wrote:
>> Latest code from LUCENE-2657 does not generate any new artifacts. It
>> uploads those you already have (built via ant) to the repo.
>>
>
> yep, thats releasing artifacts. thats the whole point of this email
> thread (read the title, thanks)
>
> the intellij/eclipse stuff is just unreleased stuff that sits in our
> SVN. it doesnt get uploaded anywhere.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

---------------------------------------------------------------------

On Tue, Jan 18, 2011 at 10:53 AM, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
> I still don't see why you care so much.  You have people willing to maintain it and it is no sweat off your back and it is used by a pretty large chunk of downstream users.  And don't tell me it is what holds up releases b/c it simply isn't true.
>

it is what holds up releases. the last time i brought up releasing, it
was totally destroyed because of maven.

the RM shouldn't have to deal with 2 build systems, packaging systems,
and repository hell, and that's what maven artifacts require.

If there is a large chunk of downstream users, then they can handle
this downstream, it doesn't need to be in lucene, just like we don't
deal with other packaging systems.

Unfortunately there is a very loud minority that care about maven,
most of us that think the situation is ridiculous have totally given
up arguing about it, except me, i don't want to put out a shitty
release with broken maven artifacts like in the past, i'd rather let
some downstream project deal with maven instead.

---------------------------------------------------------------------

On Jan 18, 2011, at 11:12 AM, Robert Muir wrote:

>
> there is a very loud minority that care about maven,
> most of us that think the situation is ridiculous have totally given
> up arguing about it, except me, i don't want to put out a shitty
> release with broken maven artifacts like in the past, i'd rather let
> some downstream project deal with maven instead.

+1. What a fantastic idea for an apache extra's project :)

I'll open my arms to first class maven the first time it sees the light of consensus ;)

- Mark
---------------------------------------------------------------------

On Tue, Jan 18, 2011 at 11:27 AM, Mark Miller <[EMAIL PROTECTED]> wrote:
> I'll open my arms to first class maven the first time it sees the light of consensus ;)

thats the main thing missing from releasing maven artifacts... looking
at previous threads I don't really see consensus that we need to do
this.

---------------------------------------------------------------------

On 1/18/2011 at 11:34 AM, Robert Muir wrote:
> On Tue, Jan 18, 2011 at 11:27 AM, Mark Miller <[EMAIL PROTECTED]>
> wrote:
> > I'll open my arms to first class maven the first time it sees the light
> > of consensus ;)
>
> thats the main thing missing from releasing maven artifacts... looking
> at previous threads I don't really see consensus that we need to do
> this.

I think there is consensus that the RM does not have to release Maven artifacts.

There clearly is no consensus for removing Maven support from Lucene.  

> Unfortunately there is a very loud minority that care about maven

I would wager that there is a sizable silent *majority* of users who literally depend on Lucene's Maven artifacts.

Steve

On Tue, Jan 18, 2011 at 12:03 PM, Steven A Rowe <[EMAIL PROTECTED]> wrote:
>
> There clearly is no consensus for removing Maven support from Lucene.

and see there is my problem, there was no consensus to begin with, now
suddenly its "de-facto" required. Maven is quite an insidious computer
virus.

>
>> Unfortunately there is a very loud minority that care about maven
>
> I would wager that there is a sizable silent *majority* of users who literally depend on Lucene's Maven artifacts.

I can't help but remind myself, this is the same argument Oracle
offered up for the whole reason hudson debacle
(http://hudson-labs.org/content/whos-driving-thing)

Declaring that I have a secret pocket of users that want XYZ isn't
open source consensus.

---------------------------------------------------------------------

On 1/18/11 9:13 AM, Robert Muir wrote:
> I can't help but remind myself, this is the same argument Oracle
> offered up for the whole reason hudson debacle
> (http://hudson-labs.org/content/whos-driving-thing)
>
> Declaring that I have a secret pocket of users that want XYZ isn't
> open source consensus.

Well everyone using ant+ivy or maven as their build system likely
consumes artifacts from maven repos.

I'm surprised you're so much against keeping to publish.  I too really
really want to keep ant as Lucene's build tool.  Maven has made me
suicidal in the past.  But I don't want to stop publishing artifacts
to commonly used repos.

I guess we could try to figure out how many people download the
artifacts from m2 repos.  Maybe they have download statistics?
But then what?  What number would justify stopping to publish?

  Michael

---------------------------------------------------------------------

On Jan 18, 2011, at 12:30 PM, Michael Busch wrote:
>
> I guess we could try to figure out how many people download the
> artifacts from m2 repos.  Maybe they have download statistics?
> But then what?  What number would justify stopping to publish?
>
> Michael

Realistically, I would expect that Maven artifacts would still be published, even if we kick them out of the Lucene project to Apache extras.
If some of the people care as much as they say they do, they will figure out how to make poms and whatever downstream, and a Committer into Maven will put them on the official Apache repo. It will just more truly not be a concern to the rest of us.

- Mark
---------------------------------------------------------------------

On Tue, Jan 18, 2011 at 20:13, Robert Muir <[EMAIL PROTECTED]> wrote:
>>> Unfortunately there is a very loud minority that care about maven
>>
>> I would wager that there is a sizable silent *majority* of users who literally depend on Lucene's Maven artifacts.
>
> I can't help but remind myself, this is the same argument Oracle
> offered up for the whole reason hudson debacle
> (http://hudson-labs.org/content/whos-driving-thing)
>
> Declaring that I have a secret pocket of users that want XYZ isn't
> open source consensus.

There is proof of existance for some unknown part of this secret pool.

http://www.google.com/search?q=%22artifactid+lucene-core%22
Please, don't look at "About NNN results", these are known to be
veeery approximate.
Just page through. Some of the pages are Lucene poms themselves. Many
of them are poms for the projects depending on lucene.
--
Kirill Zakharenko/Кирилл Захаренко ([EMAIL PROTECTED])
Phone: +7 (495) 683-567-4
ICQ: 104465785

---------------------------------------------------------------------

On 1/18/2011 at 12:14 PM, Robert Muir wrote:
> On Tue, Jan 18, 2011 at 12:03 PM, Steven A Rowe <[EMAIL PROTECTED]> wrote:
> >
> > There clearly is no consensus for removing Maven support from Lucene.
>
> and see there is my problem, there was no consensus to begin with, now
> suddenly its "de-facto" required. Maven is quite an insidious computer
> virus.

So you think you personally have the power to remove functionality from Lucene that has the support of multiple committers?

> >> Unfortunately there is a very loud minority that care about maven
> >
> > I would wager that there is a sizable silent *majority* of users who
> literally depend on Lucene's Maven artifacts.
>
> I can't help but remind myself, this is the same argument Oracle
> offered up for the whole reason hudson debacle
> (http://hudson-labs.org/content/whos-driving-thing)
>
> Declaring that I have a secret pocket of users that want XYZ isn't
> open source consensus.

In summary: you claim a silent majority (of devs) in favor of your position, and I claim a silent majority (of users) in favor of mine.  Your move: my majority, of which I have no proof, has no standing.  Sweet.

I dunno - why are we at war?  Why is it so damn important that you *remove* functionality that devs care about and will support?

Steve

On Jan 18, 2011, at 12:28 PM, Steven A Rowe wrote:

> On 1/18/2011 at 12:14 PM, Robert Muir wrote:
>> On Tue, Jan 18, 2011 at 12:03 PM, Steven A Rowe <[EMAIL PROTECTED]> wrote:
>>>
>>> There clearly is no consensus for removing Maven support from Lucene.
>>
>> and see there is my problem, there was no consensus to begin with, now
>> suddenly its "de-facto" required. Maven is quite an insidious computer
>> virus.
>
> So you think you personally have the power to remove functionality from Lucene that has the support of multiple committers?

If he thought that, he would have removed maven from svn by now!

From my point of view, but perhaps I misremember:

At some point, Grant or someone put in some Maven poms. I don't think anyone else really paid attention. Later, as we did releases, and saw and dealt with these poms, most of us commented against Maven support. It just feels to me like it slipped in - and really its the type of thing that should have been more discussed and thought out, and perhaps voted upon. Maven snuck into Lucene IMO. To my knowledge, the majority of core developers do not want maven in the build and/or frown on dealing with Maven. We could always have a little vote to gauge numbers - I just have not wanted to rush to another vote thread myself ;) Users are important too - but they don't get official votes - it's up to each of us to consider the User feelings/vote in our opinions/votes as we see fit IMO.

- Mark
---------------------------------------------------------------------

On 1/18/11 10:44 AM, Mark Miller wrote:
>  From my point of view, but perhaps I misremember:
>
> At some point, Grant or someone put in some Maven poms.
I did. :) It was a ton of work and especially getting the
maven-ant-tasks to work was a nightmare!

> I don't think anyone else really paid attention.

All those patches were attached to a jira issue, and the issue was open
for a while, with people asking for published maven artifacts.

> Later, as we did releases, and saw and dealt with these poms, most of us commented against Maven support.

So can you explain what the problem with the maven support is?  Isn't it
enough to just call the ant target and copying the generated files
somewhere?  When I did releases I never thought it made the release any
harder.  Just two additional easy steps.

> It just feels to me like it slipped in - and really its the type of thing that should have been more discussed and thought out, and perhaps voted upon. Maven snuck into Lucene IMO. To my knowledge, the majority of core developers do not want maven in the build and/or frown on dealing with Maven. We could always have a little vote to gauge numbers - I just have not wanted to rush to another vote thread myself ;) Users are important too - but they don't get official votes - it's up to each of us to consider the User feelings/vote in our opinions/votes as we see fit IMO.
>
> - Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------

On Jan 18, 2011, at 2:41 PM, Michael Busch wrote:

>
> So can you explain what the problem with the maven support is?  Isn't it enough to just call the ant target and copying the generated files somewhere?  When I did releases I never thought it made the release any harder.  Just two additional easy steps.
>

Robert and I have gone over this a fair amount in previous exchanges I think, if you really want to know particulars. Suffice it to say, the problems so far have not been large, it feels like the likelihood of future larger problems is growing, if you ask people that seem to like/care about Maven support, the problems are probably not really a problem or easily addressable, if you ask people that dislike/don't want Maven, the problems are probably just not worth ever having to run into when we are still convinced this could be handled downstream.

If I remember right, a large reason Robert is against is that he doesn't want to sign/support/endorse something he doesn't understand or care about as a Release Manager? But thats probably a major simplification of his previous arguments. And the pro Maven team has offered their counters to that.
- Mark
---------------------------------------------------------------------

On 1/18/11 11:57 AM, Mark Miller wrote:
> On Jan 18, 2011, at 2:41 PM, Michael Busch wrote:
>
>> So can you explain what the problem with the maven support is?  Isn't it enough to just call the ant target and copying the generated files somewhere?  When I did releases I never thought it made the release any harder.  Just two additional easy steps.
>>
> Robert and I have gone over this a fair amount in previous exchanges I think, if you really want to know particulars. Suffice it to say, the problems so far have not been large, it feels like the likelihood of future larger problems is growing, if you ask people that seem to like/care about Maven support, the problems are probably not really a problem or easily addressable, if you ask people that dislike/don't want Maven, the problems are probably just not worth ever having to run into when we are still convinced this could be handled downstream.

This seems weird to me.  If there haven't been large problems so far,
why do we need to change anything now?  Not sure why the "likelihood is
growing".
> If I remember right, a large reason Robert is against is that he doesn't want to sign/support/endorse something he doesn't understand or care about as a Release Manager? But thats probably a major simplification of his previous arguments. And the pro Maven team has offered their counters to that.
>

I'm not sure what's so complicated or mysterious about maven artifacts.  
A maven artifact consists of normal jar file(s) plus a POM file
containing some metadata, like the artifact name and group.

> - Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------

On Tue, Jan 18, 2011 at 3:11 PM, Michael Busch <[EMAIL PROTECTED]> wrote:
> I'm not sure what's so complicated or mysterious about maven artifacts.  A
> maven artifact consists of normal jar file(s) plus a POM file containing
> some metadata, like the artifact name and group.

its the POM files that cause problems and reported bugs. i don't think
they are simple at all, in fact i think they are more complicated than
ant build.xml files!

---------------------------------------------------------------------

On Tue, Jan 18, 2011 at 2:57 PM, Mark Miller <[EMAIL PROTECTED]> wrote:

> If I remember right, a large reason Robert is against is that he doesn't want to sign/support/endorse something he doesn't understand or care about as a Release Manager? But thats probably a major simplification of his previous arguments. And the pro Maven team has offered their counters to that.
>

Well, i definitely don't want to produce a jacked-up release. And I
listed in the last 99-email maven thread, a reference to how many of
the previous releases have had various bugs/problems with maven. The
problem is, as it is in our code now, there is no way to verify these
magical files will actually work. and yet we all just ignore the fact
we are probably shipping broken artifacts and go with the release
anyway?

(separately, for reference i know that Uwe has the releasing down to
an art and is probably the sole person here that could actually do a
release without having maven jacked up, so he isn't included)

But for the rest of us, we don't understand maven. why can't it be
handled downstream?
And it sets a tone for future things, for instance *the most popular
issue* in lucene, its not flexible indexing, its not realtime search,
its not column stride fields, its... make Lucene an OSGI bundle?

https://issues.apache.org/jira/browse/LUCENE?report=com.atlassian.jira.plugin.system.project:popularissues-panel

Anyway i think we are making a search engine library, and if someone
else can deal with these hassles, they should. we should focus on
search engine stuff and getting out solid releases.

---------------------------------------------------------------------

On 1/18/2011 at 1:45 PM, Mark Miller wrote:
> At some point, Grant or someone put in some Maven poms. I don't think
> anyone else really paid attention. Later, as we did releases, and saw and
> dealt with these poms, most of us commented against Maven support. It just
> feels to me like it slipped in - and really its the type of thing that
> should have been more discussed and thought out, and perhaps voted upon.
> Maven snuck into Lucene IMO.

Lucene's policy is commit-then-review, and lazy consensus is the rule, right?

On Jan 18, 2011, at 2:37 PM, Steven A Rowe wrote:

> On 1/18/2011 at 1:45 PM, Mark Miller wrote:
>> At some point, Grant or someone put in some Maven poms. I don't think
>> anyone else really paid attention. Later, as we did releases, and saw and
>> dealt with these poms, most of us commented against Maven support. It just
>> feels to me like it slipped in - and really its the type of thing that
>> should have been more discussed and thought out, and perhaps voted upon.
>> Maven snuck into Lucene IMO.
>
> Lucene's policy is commit-then-review, and lazy consensus is the rule, right?

Right - clearly this is not some sneaky or underhanded thing that happened. Certainly this is how a lot of legit things happen.

The only reason I feel it was more of a Maven sneaking in thing is that in IRC I have learned how many active core devs really didn't want Maven in the build at a later time. I think we just didn't really know what was happening / paid attention. I don't mean to characterize incorrectly. If you asked me back then, I prob would not have understood the consequences whatsoever and said, please go ahead! Patches welcome.

People's opinions have shifted though - we have more committers now - perhaps the Maven support side is larger than the against now.

Just stating things as I roughly knew them - happy to see things cleared up, fined tuned.

- Mark
---------------------------------------------------------------------

To follow up Steven:

Yes - Maven is part of Lucene now - it got in with lazy consensus or whatever method - and now it's basically a first class citizen. I would have to get consensus to drop it much more than you would have to get consensus to keep it. This is exactly why I don't want it to stick around or grow when it could be a downstream project. All of this continued Maven work just looks more stuff we will have maintain/support in the future it seems to me.

Honestly though - if it looks like the majority are for Maven - I drop my objection.

- Mark
On Jan 18, 2011, at 2:45 PM, Mark Miller wrote:

>
> On Jan 18, 2011, at 2:37 PM, Steven A Rowe wrote:
>
>> On 1/18/2011 at 1:45 PM, Mark Miller wrote:
>>> At some point, Grant or someone put in some Maven poms. I don't think
>>> anyone else really paid attention. Later, as we did releases, and saw and
>>> dealt with these poms, most of us commented against Maven support. It just
>>> feels to me like it slipped in - and really its the type of thing that
>>> should have been more discussed and thought out, and perhaps voted upon.
>>> Maven snuck into Lucene IMO.
>>
>> Lucene's policy is commit-then-review, and lazy consensus is the rule, right?
>
> Right - clearly this is not some sneaky or underhanded thing that happened. Certainly this is how a lot of legit things happen.
>
> The only reason I feel it was more of a Maven sneaking in thing is that in IRC I have learned how many active core devs really didn't want Maven in the build at a later time. I think we just didn't really know what was happening / paid attention. I don't mean to characterize incorrectly. If you asked me back then, I prob would not have understood the consequences whatsoever and said, please go ahead! Patches welcome.
>
> People's opinions have shifted though - we have more committers now - perhaps the Maven support side is larger than the against now.
>
> Just stating things as I roughly knew them - happy to see things cleared up, fined tuned.
>
> - Mark
---------------------------------------------------------------------

On Jan 18, 2011, at 12:13 PM, Robert Muir wrote:

> I can't help but remind myself, this is the same argument Oracle
> offered up for the whole reason hudson debacle
> (http://hudson-labs.org/content/whos-driving-thing)
>
> Declaring that I have a secret pocket of users that want XYZ isn't
> open source consensus.

You were very quick to cite your own secret pocket of users when you called those who support it the "vocal minority".  So, if you want to continue baiting the discussion we can, but as I see it, we have committers willing to support it, so what's the big deal?
---------------------------------------------------------------------

On Tue, Jan 18, 2011 at 3:49 PM, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
>
>
> On Jan 18, 2011, at 12:13 PM, Robert Muir wrote:
>
>> I can't help but remind myself, this is the same argument Oracle
>> offered up for the whole reason hudson debacle
>> (http://hudson-labs.org/content/whos-driving-thing)
>>
>> Declaring that I have a secret pocket of users that want XYZ isn't
>> open source consensus.
>
>
>
> You were very quick to cite your own secret pocket of users when you called those who support it the "vocal minority".  So, if you want to continue baiting the discussion we can, but as I see it, we have committers willing to support it, so what's the big deal?

I don't think they are that secret, you can look at the last maven
discussion and see several other committers who spoke up against it.
they are just sick of the discussion i gather and have given up
fighting it.

The problem again, is the magical special artifacts.

I dont see consensus here for maven... when you have it, get back to me.

---------------------------------------------------------------------

Why not vote for or against 'maven artifacts'?

http://www.doodle.com/2qp35b42vstivhvx

I'm using lucene+solr a lot times via maven.
Elasticsearch uses lucene via gradle.
Solandra uses lucene via ivy and so on ;)
So maven artifacts are not only very handy for maven folks.
But I think no artifacts would be better than broken ones.

Why not trying to 'switch' to ivy build system? It's ant but handles
dependencies better IMO.

Regards,
Peter.

> On Tue, Jan 18, 2011 at 3:49 PM, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
>>
>> On Jan 18, 2011, at 12:13 PM, Robert Muir wrote:
>>
>>> I can't help but remind myself, this is the same argument Oracle
>>> offered up for the whole reason hudson debacle
>>> (http://hudson-labs.org/content/whos-driving-thing)
>>>
>>> Declaring that I have a secret pocket of users that want XYZ isn't
>>> open source consensus.
>>
>>
>> You were very quick to cite your own secret pocket of users when you called those who support it the "vocal minority".  So, if you want to continue baiting the discussion we can, but as I see it, we have committers willing to support it, so what's the big deal?
> I don't think they are that secret, you can look at the last maven
> discussion and see several other committers who spoke up against it.
> they are just sick of the discussion i gather and have given up
> fighting it.
>
> The problem again, is the magical special artifacts.
>
> I dont see consensus here for maven... when you have it, get back to me.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------

On Jan 18, 2011, at 3:55 PM, Robert Muir wrote:

> On Tue, Jan 18, 2011 at 3:49 PM, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
>>
>>
>> On Jan 18, 2011, at 12:13 PM, Robert Muir wrote:
>>
>>> I can't help but remind myself, this is the same argument Oracle
>>> offered up for the whole reason hudson debacle
>>> (http://hudson-labs.org/content/whos-driving-thing)
>>>
>>> Declaring that I have a secret pocket of users that want XYZ isn't
>>> open source consensus.
>>
>>
>>
>> You were very quick to cite your own secret pocket of users when you called those who support it the "vocal minority".  So, if you want to continue baiting the discussion we can, but as I see it, we have committers willing to support it, so what's the big deal?
>
> I don't think they are that secret, you can look at the last maven
> discussion and see several other committers who spoke up against it.
> they are just sick of the discussion i gather and have given up
> fighting it.

Wow, so who is the vocal minority now?  

>
> The problem again, is the magical special artifacts.
>
> I dont see consensus here for maven... when you have it, get back to me.

As I see, it you have you, Shai and Miller (and Yonik, likely from the last go around).  On the Maven side, you have me, Steve, McKinley and Busch, plus some users/contributors.

In other words, I don't see consensus for dropping it.  When you have it, get back to me.  
---------------------------------------------------------------------

On Tue, Jan 18, 2011 at 4:06 PM, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
>
> In other words, I don't see consensus for dropping it.  When you have it, get back to me.

Thats not how things are "added" to the release process.
So currently, maven is not included in the release process.

I don't care if your poll on the users list has 100% of users checking
maven, you biased your poll already by mentioning that its because we
are considering dropping maven support at the start of the email, so
its total garbage.

There's a lot of totally insane things I could poll the user list and
get lots of responses for, that I think the devs would disagree with.

---------------------------------------------------------------------

On Jan 18, 2011, at 4:10 PM, Robert Muir wrote:

> On Tue, Jan 18, 2011 at 4:06 PM, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
>>
>> In other words, I don't see consensus for dropping it.  When you have it, get back to me.
>
> Thats not how things are "added" to the release process.
> So currently, maven is not included in the release process.
>
> I don't care if your poll on the users list has 100% of users checking
> maven, you biased your poll already by mentioning that its because we
> are considering dropping maven support at the start of the email, so
> its total garbage.

Sorry, I'm not a professional poll writer.  Even if I didn't include it, it would take all of a half of a second for someone to figure it out.  As you can see by the responses, though, I think people are simply answering it.

It's just software and we have people willing to maintain the Maven stuff.  I simply don't get what the big deal is in keeping something that people find useful and has (enough) committer support.
---------------------------------------------------------------------

On Tue, Jan 18, 2011 at 4:38 PM, Grant Ingersoll <[EMAIL PROTECTED]> wrote:

> It's just software and we have people willing to maintain the Maven stuff.  I simply don't get what the big deal is in keeping something that people find useful and has (enough) committer support.

Why not call a committer vote then?

[] <-- maintain maven ourselves instead of working on search features,
and slower releases.
[] <-- let others maintain maven downstream, instead we work on search
features, and faster releases.

---------------------------------------------------------------------

On Jan 18, 2011, at 4:41 PM, Robert Muir wrote:

> On Tue, Jan 18, 2011 at 4:38 PM, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
>
>> It's just software and we have people willing to maintain the Maven stuff.  I simply don't get what the big deal is in keeping something that people find useful and has (enough) committer support.
>
> Why not call a committer vote then?
>
> [] <-- maintain maven ourselves instead of working on search features,
> and slower releases.

Wow, so having Maven releases is why we take 6-10 months to release?  Give me a break.  The only thing that is slower (arguably) is the building of the release itself.   We have had Maven support for a long time and it has never been brought up until you did that it was the cause.  The cause is, was and always will be that we innovate at a pretty rapid pace and always have the mindset to get "just one more" set of features/fixes into the next release.
> [] <-- let others maintain maven downstream, instead we work on search
> features, and faster releases.
---------------------------------------------------------------------

On Tue, Jan 18, 2011 at 4:50 PM, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
>
> On Jan 18, 2011, at 4:41 PM, Robert Muir wrote:
>
>> On Tue, Jan 18, 2011 at 4:38 PM, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
>>
>>> It's just software and we have people willing to maintain the Maven stuff.  I simply don't get what the big deal is in keeping something that people find useful and has (enough) committer support.
>>
>> Why not call a committer vote then?
>>
>> [] <-- maintain maven ourselves instead of working on search features,
>> and slower releases.
>
> Wow, so having Maven releases is why we take 6-10 months to release? ��Give me a break.  The only thing that is slower (arguably) is the building of the release itself.   We have had Maven support for a long time and it has never been brought up until you did that it was the cause.  The cause is, was and always will be that we innovate at a pretty rapid pace and always have the mindset to get "just one more" set of features/fixes into the next release.
>

In my opinion it is just a part of it, i think i detailed this here:
http://www.lucidimagination.com/search/document/474564645f673fbb/discussion_about_release_frequency

(This discussion was subsequently sidetracked and dominated completely
by maven, so I gave up, until Shai brought up the idea again recently
of trying to do a release)

I think that the release process is too complicated, and doing things
to simplify it, such as pushing maven downstream would help a lot.

Furthermore I had this to say about maven once it completely took over
the discussion:

since i have been around, it seems the "maven" is wrong in nearly every
release[1] including even bugfix releases.
if i am going to be the one making artifacts, i want them to be right.

[1]:
Lucene/Solr 3.x, 4.0: SOLR-2041, SOLR-2055
Solr 1.4.1: SOLR-1977
Solr 1.4: SOLR-981
Lucene 2.9.1, 3.0: LUCENE-2107
Lucene 2.9.0:  LUCENE-1927
Lucene 2.4: LUCENE-1525

---------------------------------------------------------------------

It's sad how aggressive these discussions get.  There's really no reason.

On 1/18/11 1:10 PM, Robert Muir wrote:
> On Tue, Jan 18, 2011 at 4:06 PM, Grant Ingersoll<[EMAIL PROTECTED]>  wrote:
>> In other words, I don't see consensus for dropping it.  When you have it, get back to me.
> Thats not how things are "added" to the release process.
> So currently, maven is not included in the release process.
>
> I don't care if your poll on the users list has 100% of users checking
> maven, you biased your poll already by mentioning that its because we
> are considering dropping maven support at the start of the email, so
> its total garbage.
>
> There's a lot of totally insane things I could poll the user list and
> get lots of responses for, that I think the devs would disagree with.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------

On Tue, Jan 18, 2011 at 3:49 PM, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
>
>
> On Jan 18, 2011, at 12:13 PM, Robert Muir wrote:
>
>> I can't help but remind myself, this is the same argument Oracle
>> offered up for the whole reason hudson debacle
>> (http://hudson-labs.org/content/whos-driving-thing)
>>
>> Declaring that I have a secret pocket of users that want XYZ isn't
>> open source consensus.
>
>
>
> You were very quick to cite your own secret pocket of users when you called those who support it the "vocal minority".  So, if you want to continue baiting the discussion we can, but as I see it, we have committers willing to support it, so what's the big deal?

http://www.lucidimagination.com/search/document/474564645f673fbb/discussion_about_release_frequency

You can look there, and see the responses of several other committers
about maven.

I think i like Yonik's comment best: Maven is not a part of the
release process, if you think it should be, maybe you should call a
vote?

---------------------------------------------------------------------

On Jan 18, 2011, at 11:12 AM, Robert Muir wrote:

> On Tue, Jan 18, 2011 at 10:53 AM, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
>> I still don't see why you care so much.  You have people willing to maintain it and it is no sweat off your back and it is used by a pretty large chunk of downstream users.  And don't tell me it is what holds up releases b/c it simply isn't true.
>>
>
> it is what holds up releases. the last time i brought up releasing, it
> was totally destroyed because of maven.

I'll grant you it held up the last release _ONCE WE DECIDED TO RELEASE_, but don't act like it is why we don't release very often, because it isn't.

>
> the RM shouldn't have to deal with 2 build systems, packaging systems,
> and repository hell, and that's what maven artifacts require.

And Steve has said he would fix it and it won't require two build systems, so your main complaint is solved.
---------------------------------------------------------------------