[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985056#action_12985056
]
Steven Rowe commented on LUCENE-2657:
-------------------------------------
{quote}
bq. This should be fixed by converting the pom.xml files back into templates
(and renaming the files accordingly), so that the version in the POMs can be
modified during ant generate-maven-artifacts.
Wasn't the fact we were using templates part of the problem that spawned this
issue? I feel we've gone full circle here and are now back with maven templates
that may or may not be maintained.
{quote}
Since the POMs don't represent an official build, the number of people *using*
them to build will be small. It is this, IMHO, rather than whether the POMs
are stored as templates under {{dev-tools/maven/}}, that will directly affect
the quality/regularity of their maintenance.
In fact, I think whether the POMs are stored as templates under
{{dev-tools/maven/}} is really a non-issue, since they won't be used there.
The way it's set up right now, if you want to use the POMs to drive a build, is
that you run {{ant get-maven-poms}} to copy them over to their target
locations. The way it will be set up once I convert the POMs under
{{dev-tools/maven/}} to templates is that you run {{ant get-maven-poms}} to
copy them over to their target locations, as well as naming them to {{pom.xml}}
and interpolating the desired version. In other words, for the end-user, the
experience will be *exactly* the same: you run {{ant get-maven-poms}}, and then
you can use Maven to build/test/install artifacts.
Templating the POMs will not change usability of them at all, so neither the
number of people using them nor their effective maintenance will be affected by
this change.
All that said, I agree with you that maintenance is the big deal here, and I
welcome other suggestions about how to simplify and enable that process.
> 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-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, 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: [email protected]
For additional commands, e-mail: [email protected]
