lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: [DISCUSS] Build/deploy Maven artifacts outside of Lucene/Solr
Date Mon, 23 Apr 2012 22:49:00 GMT
On Mon, Apr 23, 2012 at 6:31 PM, Robert Muir <rcmuir@gmail.com> wrote:
> On Mon, Apr 23, 2012 at 6:28 PM, Dawid Weiss
> <dawid.weiss@cs.put.poznan.pl> wrote:
>>
>> The issue with such poms is that once you want to publish your stuff
>> to maven central it won't work (because all dependencies must be
>> available and there is no "local" repository).
>>
>
> This is the problem I am asking about.
>
> I don't care about local maven builds or any of that. I care about
> release artifacts.
>
> If we have a buggy dependency, i can easily tweak ant+ivy (even ant by
> itself) to download its source, patch it, and use it.
> I can generate lucene-4.0-src.tgz, solr-4.0-src.tgz, lucene-4.0.zip,
> etc etc with this.

If your build and release process creates a modified version of
xerces.jar with unmodified package names, and that jar file ends up on
www.apache.org/dist, there will be unhappiness. You can't have such a
thing in svn, you can't have it in your binary package, you can't have
it in a 'convenience binary bundle.' You can auto-download it from
non-Apache infrastructure. You could download it from Maven central,
but you can't officially, as a committee, put it there. If have a way
to get what you want with ant(+ivy) without breaking those rules,
please explain it to me again, and I'll endeavor to provide the maven
analog.

Ultimately, what makes people unhappy is pulling modified versions,
however improved, into users' classpaths under unmodified package
names. Doing this internally for your own development is no big deal,
but people find it rude for releases. It doesn't matter what tool is
being used to produce, release, or consume. If someone outside Apache
facilitates it, the unhappiness will merely come from users who get
all confused trying to deal with multiple versions of the item.

So, in my view, you really should rename the packages if you want
these things to be used in releases. Once you rename the packages, you
can incorporate the results in your release. You can either publish
jar files under clear names, or you can incorporate them in your own
jar files. You can do these things with or without maven. You can
publish them to maven central -- as an official act of the pmc.

Thus, I claim that this debate is fundamentally about package
renaming, not publication.

Shall I be maximally annoying and mention OSGi again?



>
> How will the stuff in the maven/ folder work? will it work at all?
>
> (for reference, here is a release candidate to see what i mean:
> http://people.apache.org/~rmuir/staging_area/lucene-solr-3.6RC1-rev1310449/)
>
>
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message