[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983768#action_12983768
]
Grant Ingersoll commented on LUCENE-2657:
-----------------------------------------
Here's my suggestion: Let's put the stuff in and do a release. I am pretty
sure that we have enough PMC members who want Maven that they can vote on said
artifacts w/o those who don't want Maven to have to bother (even though they
are the same artifacts). Also, Robert, I would specifically ask you, once
Steve has done the work, assuming you are the RM, to honestly evaluate whether
the production of the artifacts is a burden for you. If you don't want to,
then I would suggest you do all the main RM work and you let one of us handle
producing the artifacts to be released/voted on at the same time. If it really
is a burden, then we can move it to dev-tools or external.
And, for the record, there are more than two camps for Maven besides "die maven
die" and "maven or die": I personally think distributing artifacts via the
central repository and the explicit requirement to list out dependencies and
their versions is a great service and significantly increases uptake of
artifacts, but I can live just fine without the day to day crap that is the
result of running "mvn XXXX" (where XXXX is not equal to one of the simpler
things like compile or test). Let's not be confused about what we are doing
when we say we are supporting Maven. We are just using it to publish
artifacts. The only time that should ever need to be run is during a release
(hence it doesn't slow down us deciding to do a release, it just slows down,
marginally, the actual release process.)
I totally agree we don't want two build systems and I am totally against
switching to Maven as a build for all the reasons Robert is (parallel tests,
etc.). All I have ever wanted is reliable published artifacts and I think we
have enough support amongst committers to do that and we have strong enough
interest in the community to warrant it.
> Replace Maven POM templates with full POMs, and change documentation
> accordingly
> --------------------------------------------------------------------------------
>
> Key: LUCENE-2657
> URL: https://issues.apache.org/jira/browse/LUCENE-2657
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Build
> Affects Versions: 3.1, 4.0
> Reporter: Steven Rowe
> Assignee: Steven Rowe
> Fix For: 3.1, 4.0
>
> Attachments: LUCENE-2657-branch_3x.patch, LUCENE-2657.patch,
> LUCENE-2657.patch, LUCENE-2657.patch, LUCENE-2657.patch, LUCENE-2657.patch,
> LUCENE-2657.patch, LUCENE-2657.patch, LUCENE-2657.patch, LUCENE-2657.patch,
> LUCENE-2657.patch, LUCENE-2657.patch, LUCENE-2657.patch, LUCENE-2657.patch,
> LUCENE-2657.patch, LUCENE-2657.patch
>
>
> The current Maven POM templates only contain dependency information, the bare
> bones necessary for uploading artifacts to the Maven repository.
> The full Maven POMs in the attached patch include the information necessary
> to run a multi-module Maven build, in addition to serving the same purpose as
> the current POM templates.
> Several dependencies are not available through public maven repositories. A
> profile in the top-level POM can be activated to install these dependencies
> from the various {{lib/}} directories into your local repository. From the
> top-level directory:
> {code}
> mvn -N -Pbootstrap install
> {code}
> Once these non-Maven dependencies have been installed, to run all Lucene/Solr
> tests via Maven's surefire plugin, and populate your local repository with
> all artifacts, from the top level directory, run:
> {code}
> mvn install
> {code}
> When one Lucene/Solr module depends on another, the dependency is declared on
> the *artifact(s)* produced by the other module and deposited in your local
> repository, rather than on the other module's un-jarred compiler output in
> the {{build/}} directory, so you must run {{mvn install}} on the other module
> before its changes are visible to the module that depends on it.
> To create all the artifacts without running tests:
> {code}
> mvn -DskipTests install
> {code}
> I almost always include the {{clean}} phase when I do a build, e.g.:
> {code}
> mvn -DskipTests clean install
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
