[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985849#action_12985849
]
Steven Rowe commented on LUCENE-2657:
-
{quote}
bq. 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.
FWIW, I'll start using the generated POMs for my builds (aside from my use of
IntelliJ for day to day development). If there are ever problems then I'll of
course report/fix them. Thanks so much Steven for creating this alternative
build system (one that I prefer).
{quote}
Cool! The more the merrier.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985730#action_12985730
]
David Smiley commented on LUCENE-2657:
--
bq. 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.
FWIW, I'll start using the generated POMs for my builds (aside from my use of
IntelliJ for day to day development). If there are ever problems then I'll of
course report/fix them. Thanks so much Steven for creating this alternative
build system (one that I prefer).
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985065#action_12985065
]
Steven Rowe commented on LUCENE-2657:
-
Rather than post a patch attachment for this change, I'll put the diffs here.
I'll commit these shortly.
First, all {{pom.xml}} files under {{dev-tools/maven/}} will be renamed to
{{pom.xml.template}}.
Second, all {{pom.xml.template}} files will get this change (a representative
version of it is given here - different original version for trunk's
{{build.xml}} of course):
{noformat}
- 3.1-SNAPSHOT
+ @version@
{noformat}
Third, the top-level {{build.xml}} gets this change (different version for
trunk's {{build.xml}} of course):
{noformat}
@@ -39,10 +39,15 @@
+
+
+
+
+
{noformat}
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985014#action_12985014
]
Chris Male commented on LUCENE-2657:
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 fall circle here and are now back with maven
templates that may or may not be maintained.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984333#action_12984333
]
Robert Muir commented on LUCENE-2657:
-
+1, patch looks good.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983827#action_12983827
]
Steven Rowe commented on LUCENE-2657:
-
A chat on IRC confirms that Robert is okay with my proposal: adding a new
{{get-maven-poms}} target in the Ant build to copy the POMs from {{dev-tools/}}
to their target locations under {{lucene/}}, {{modules/}} [trunk only] and
{{solr/}}; adding {{svn:ignore}} properties for {{pom.xml}} in their target
locations; keeping {{generate-maven-artifacts}} in the Ant build; and making
{{generate-maven-artifacts}} depend on {{get-maven-poms}}).
I'll work up modified patches for trunk and branch_3x along these lines.
> 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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983783#action_12983783
]
Robert Muir commented on LUCENE-2657:
-
Steven, i totally dont mind if we change the whole way the ant build works with
regards to maven, to depend on the dev-tools scenario.
For example, you could have 'ant maven' that:
1. copies the stuff from /dev-tools wherever it needs to be to make maven happy.
2. does whatever is necessary (invoke maven, whatever) to make the artifacts.
Or you could have 'ant maven' that only does part #1, but 'ant maven-artifacts'
that does part #2, and depends on part #1.
i just want it to be in /dev-tools, because if i see build.xml in a directory,
i think its supported by Ant. If i see Makefile
in a directory, I think its supported by Make, pom.xml by Maven, and so on.
we could also add pom.xml to the svn:ignore for all the directories too, so
that there are no problems with people
using the maven framework in dev-tools.
> 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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983782#action_12983782
]
Steven Rowe commented on LUCENE-2657:
-
I'm sensitive to the two-build-systems problem. While I like being able to
produce local Maven artifacts, I agree that mixed build systems for new users
will be confusing.
I'm okay with putting the POMs themselves under {{dev-tools/}}. But I want the
{{generate-maven-artifacts}} target to stay in Ant's build, not under
{{dev-tools/}}, and a new target {{get-maven-poms}} added to the top-level
{{build.xml}}; {{generate-maven-artifacts}} would depend on {{get-maven-poms}}.
All {{pom.xml}}'s would be added to {{svn:ignore}} entries where they are
placed by {{get-maven-poms}}.
Robert, would you agree to keeping {{generate-maven-artifacts}} and adding
{{get-maven-poms}}?
> 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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983774#action_12983774
]
Robert Muir commented on LUCENE-2657:
-
bq. If it really is a burden, then we can move it to dev-tools or external.
Please re-read my comment above.
I won't stand for two build systems to deal with during development. If all you
care about is reliable published artifacts, then its not an issue
if the stuff to generate that is in /dev-tools or mixed in with the code.
I feel this is the maven users trying to sneak maven in as a fully supported
build system, if not to then sneak it in as the only build system.
I will do everything possible to stop this.
> 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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
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 " (where 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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983749#action_12983749
]
Robert Muir commented on LUCENE-2657:
-
David: sounds perfect to me, great idea.
> 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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983748#action_12983748
]
David Smiley commented on LUCENE-2657:
--
Perhaps a compromise would be to put them in /dev-tools and have an ant task
that will copy (or symbolically link them when possible) to where Maven wants
them? Developers opposed to maven stuff can choose to never invoke this ant
task and thus leave the maven stuff hidden.
> 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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983746#action_12983746
]
Robert Muir commented on LUCENE-2657:
-
Sorry, but introducing a parallel build system (somehow such that maven can
"sneak" its way into being a 2nd supported build) is not acceptable to me.
I feel this will slow down development.
Putting it in /dev-tools clarifies the level of support: i don't want someone
telling me "I broke the build" because these poms dont work if i refactor
something.
So I am -1 to the patch, unless it is in /dev-tools.
if maven cannot work with its files in /dev-tools, perhaps a patch to maven
itself is needed instead.
> 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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983739#action_12983739
]
Ryan McKinley commented on LUCENE-2657:
---
bq. i really think the patches need to be against /dev-tools
Sadly, given the way maven works, that is not possible. (without reinventing a
crazy wheel)
Previous attempts at fakey fakey pom generation have not been so good -- this
approach is better since it is testable and works well with core maven tools.
> 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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983730#action_12983730
]
Robert Muir commented on LUCENE-2657:
-
as I said before... i really think the patches need to be against /dev-tools
> 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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983729#action_12983729
]
Steven Rowe commented on LUCENE-2657:
-
I plan on committing these patches tomorrow.
> 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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983247#action_12983247
]
Chris A. Mattmann commented on LUCENE-2657:
---
+1 for Steve's patch, great work and you beat me to 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.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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983234#action_12983234
]
Ryan McKinley commented on LUCENE-2657:
---
Steve, great work with this patch -- it takes care of all the previous concerns
about our problematic maven support.
With this patch, we now have:
* testable maven artifacts
* easy repo distribution
* ant is still *the* build system
The RM can choose to ignore the generate-maven-artifacts target and let someone
else push the artifacts.
As with most religious conflicts -- I hope the resolution is not conversion,
rather something that lets everyone to live (work) in peace.
> 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.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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983163#action_12983163
]
Chris Male commented on LUCENE-2657:
Ant does many things too and we use it in a specific way so I see no problem
defining what we intend our maven support to be for.
So I'm feeling some consensus (fortunately I spoke too soon before) that if we
target this toward being a development tool which is not
forced upon any users / release managers.
Is this okay with you Steven?
A README.txt describing the scope of the dev-tools sounds appropriate
irrespective of what happens here. I certainly wasn't aware of what
their maintenance plan was.
> 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.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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983162#action_12983162
]
Earwin Burrfoot commented on LUCENE-2657:
-
Thanks, but I'm not the one confused here. : )
> 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.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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983161#action_12983161
]
Robert Muir commented on LUCENE-2657:
-
Chris: well thats the problem with maven, it tries to be too many things, a
dependency management tool,
a packaging system, a build system, ...
So, thats why I said we have to just be very clear about which exact scope of
maven we are discussing.
If the patch presented here is against /dev-tools, and is to assist developers
who like maven, then as
I said before I am totally ok with this, but I'm only speaking for myself.
Because maven is so many things, and due to Earwin's confusion, I think it
would be good in general to
add a README.txt to dev-tools anyway, that states what exactly it is (tools to
assist lucene/solr developers,
that aren't supported, its not bugs if they stop working, and will be deleted
if they rot).
Separately what you said about other code in trunk is totally true... for
example its my opinion that there is
a lot of code in lucene's contrib that should be moved out to something like
apache-extras... currently lucene's
contrib has to compile and pass tests or the build fails... there is definitely
some stuff in there that is more
"sandboxy", slows down lucene core development, but itself isnt getting much
maintenance other than devs
doing the minimum work to make them pass tests... and we should be keep other
options in mind for stuff like this.
> 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.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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983160#action_12983160
]
Earwin Burrfoot commented on LUCENE-2657:
-
bq. we need to be very clear and it has no effect on artifacts
I feel something was missed in the heat of debate. Eg:
bq. The latest patch on this release uses the Ant artifacts directly.
bq. This patch uses the Ant-produced artifacts to prepare for Maven artifact
publishing.
bq. Maven itself is not invoked in the process. An Ant plugin handles the
artifact deployment.
I will now try to decipher these quotes.
It seems the patch takes the artifacts produced by Ant, as a part of our usual
(and only) build process, and shoves it down Maven repository's throat along
with a bunch of pom-descriptors.
Nothing else is happening.
Also, after everything that has been said, I think nobody in his right mind
will *force* anyone to actually use the Ant target in question as a part of
release. But it's nice to have it around, in case some user-friendly commiter
would like to push (I'd like to reiterate - ant generated) artifacts into Maven.
> 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.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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983158#action_12983158
]
Chris Male commented on LUCENE-2657:
That was basically what I was getting at (perhaps not clearly enough).
Would a satisfactory compromise be to view this patch as adding development
support for maven, which is not to do with whether maven artifacts are released
or not?
The discussion about release process, artifacts and build system flamewars can
then happen outside of this.
> 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.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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983153#action_12983153
]
Robert Muir commented on LUCENE-2657:
-
bq. I am amazed at how idea/eclipse ant tasks managed to get into trunk.
I already stated on the "maven thread", that I have no problem with something
like this patch being committed to dev-tools/
alongside the eclipse and idea support... some others might object, but
personally I see no problem.
we already agreed these folders are simply developer tools, and if they start
to rot, we will just delete them.
my problem is with the release process and artifacts... so if we do this we
need to be very clear that we are
agreeing to put the maven support in dev-tools/ as "developer-support", but its
not a build system, and it has
no effect on artifacts... we don't release dev-tools, its just checked into svn
to help developers.
> 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.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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983152#action_12983152
]
Earwin Burrfoot commented on LUCENE-2657:
-
I am *amazed* at how idea/eclipse ant tasks managed to get into trunk.
No, really, emacs is just enough for Lucene development, as proven by one of
our most seasoned developers.
So why the hell are those extras polluting main tree?
> 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.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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983151#action_12983151
]
Chris Male commented on LUCENE-2657:
I can appreciate the need to keep our trunk lean and mean and I hope that your
assertion that that'll mean more frequent releases holds true.
I hope we also shine the light on other code in the trunk to see if it belongs
there or could be spun off.
I do continue to support the committing of this code but as you rightly pointed
out, there won't be any consensus on the issue so I'll leave it at that.
> 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.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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983146#action_12983146
]
Robert Muir commented on LUCENE-2657:
-
{quote}
What if this were committed so that those of us who do understand maven and do
like using it, could?
This issue about whether maven artifacts need to then be released or not can be
part of a greater discussion (as is already taking place).
By committing this we then make it easier for someone else outside of the
project to create the correct artifacts which are then available from the
central maven repository, if thats the decision thats made which is also the
one you support.
{quote}
Why does it need to be committed to *our* trunk? why can't it be on e.g.
apache-extras and do all of this.
This way, we can continue to evolve lucene (e.g. merge lucene and solr better),
maintaining only *ONE* build system,
and hopefully! release more often... if downstream maven support falls behind,
it falls behind, but it shouldn't
slow us down.
> 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.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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983141#action_12983141
]
Chris Male commented on LUCENE-2657:
Alright I can appreciate your concern. I think comparing Maven to RPM or
FreeBSD ports is going a little far, but I can understand the point you're
making.
What if this were committed so that those of us who do understand maven and do
like using it, could?
This issue about whether maven artifacts need to then be released or not can be
part of a greater discussion (as is already taking place).
By committing this we then make it easier for someone else outside of the
project to create the correct artifacts which are then available from the
central maven repository, if thats the decision thats made which is also the
one you support.
> 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.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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983139#action_12983139
]
Robert Muir commented on LUCENE-2657:
-
bq. Is your issue that this patch introduces things that get in your way
somehow with using ant to do builds? or are you against committing this due to
your general concerns with Maven?
Personally I don't care for maven, but I would be bringing up these same
objections if we proposed
building Redhat RPMs or FreeBSD ports. I would say, its best for us to stay out
of the business
of building packages for various systems, instead let the people that work with
those packaging
systems do it themselves, they will do a better job and supporting N
build/packaging systems is
too expensive for us. It makes releasing more complicated to deploy these
special packages
to the various repositories where they want to be, it forces the release
manager to know about
N packaging systems instead of concentrating on releasing the source code to an
open
source search engine library, which is what we should be doing.
> 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.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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983135#action_12983135
]
Chris Male commented on LUCENE-2657:
I'm a little lost at what this patch introduces that is imposing? Ant itself
has maven support as part of its trunk code base so its clearly not too
imposing for them.
Is your issue that this patch introduces things that get in your way somehow
with using ant to do builds? or are you against committing this due to your
general concerns with Maven?
> 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.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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983130#action_12983130
]
Robert Muir commented on LUCENE-2657:
-
bq. I'd rather not. The Lucene project has published Maven artifacts since the
1.9.1 release. I think we should continue to do that.
Well I disagree, and I definitely don't think we should have 2 build systems.
As I stated before, I don't think we are going to see consensus on this issue,
because maven is too "imposing" on people
who don't care about it... it seems maven users are only happy if every project
they depend on is itself a maven project.
> 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.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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983123#action_12983123
]
Steven Rowe commented on LUCENE-2657:
-
bq. Can we put this code in a separate project, that takes care of maven
support for lucene?
I'd rather not. The Lucene project has published Maven artifacts since the
1.9.1 release. I think we should continue to do that.
bq. The only way for maven to survive, is for the users that care about it, to
support itself, just like other packaging systems such as debian, redhat rpm,
freebsd/mac ports, etc etc that we lucene, don't deal with.
OK, those are pretty obviously red herrings. Can we concentrate on the actual
issue here without dragging in those extraneous things? Maven artifacts, not
those other things, have been provided by Lucene since the 1.9.1 release. We
obviously *do* deal with Maven.
bq. They can't continue to whine to people like me, who don't give a shit about
it, to support it and produce its crazy ass complicated artifacts.
The latest patch on this release uses the Ant artifacts directly. POMs are
provided. You know, just like it has been since the 1.9.1 release.
bq. Instead the people who care about these packaging systems, and know how to
make them work must deal with them.
Um, like the patch on this issue is doing?
bq. Basically, the ant build system is our build. I think it needs to be able
to fully build lucene for a release without involving any other build systems
such as Make or Maven.
This patch uses the Ant-produced artifacts to prepare for Maven artifact
publishing. Maven itself is not invoked in the process. An Ant plugin handles
the artifact deployment.
I seriously do not understand why this is such a big deal. Why can't we just
keep publishing Maven artifacts? You know, like we have for the past 15-20
releases.
> 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.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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983113#action_12983113
]
Robert Muir commented on LUCENE-2657:
-
bq. I think this patch is ready to be committed to trunk.
Well first of all, you obviously worked hard on this, but we need to think this
one through before committing.
Can we put this code in a separate project, that takes care of maven support
for lucene?
The problem is there are two camps "die maven die" and "maven or die". There
will *never* be consensus.
The only way for maven to survive, is for the users that care about it, to
support itself, just like other packaging systems
such as debian, redhat rpm, freebsd/mac ports, etc etc that we lucene, don't
deal with.
They can't continue to whine to people like me, who don't give a shit about it,
to support it and produce its crazy ass
complicated artifacts.
Instead the people who care about these packaging systems, and know how to make
them work must deal with them.
Personally I really don't like:
* Having two build systems
* Having one build system (ant) rely upon the other (maven) to create release
artifacts.
Basically, the ant build system is our build. I think it needs to be able to
fully build lucene for a
release without involving any other build systems such as Make or Maven.
> 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.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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982797#action_12982797
]
Chris A. Mattmann commented on LUCENE-2657:
---
Hey Guys,
I've set this up on some other Apache projects (Nutch, Tika [NetCDF4] and SIS
so far), and basically it involved:
1. moddin'g build.xml according to Sonatype's guide (see build.xml section)
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide
2. adding pom.xmls for each artifact to be published
I'll throw together a patch for this and see if I can't make this process a bit
easier.
Thanks.
Cheers,
Chris
> 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.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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979635#action_12979635
]
Steven Rowe commented on LUCENE-2657:
-
bq. IIUC, this will be a parallel build system to ant. The build and test is
independent of anything the ant build does.
Yes, except that the two systems share build output directories.
bq. If we take this route, we should probably drop the -pom.xml.templates and
the and --generate-maven-artifacts target.
I agree.
The -pom.xml.templates have never been fully correct (e.g. missing
dependencies) and are unmaintained.
I'm working on replacing generate-maven-artifacts.
> 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.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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979606#action_12979606
]
Ryan McKinley commented on LUCENE-2657:
---
This is looking good!
IIUC, this will be a parallel build system to ant. The build and test is
independent of anything the ant build does.
If we take this route, we should probably drop the -pom.xml.templates and the
and --generate-maven-artifacts target.
> 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.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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[ https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12919252#action_12919252 ] Steven Rowe commented on LUCENE-2657: - bq. icu4j was missing from solr/contrib/extraction/pom.xml See SOLR-1813 for details. > 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.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. > Full Maven POMs will include the information necessary to run a multi-module > Maven build, in addition to serving the same purpose as the current POM > templates. -- 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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12917750#action_12917750
]
Steven Rowe commented on LUCENE-2657:
-
bq. What failure are you seeing?
Two apparently unrelated errors:
# {{JettyWebappTest.testJSP()}} returns an HTTP 500 error as soon as it
attempts to connect to the Jetty {{Server}} instantiated in {{setUp()}}, on
line #88. I haven't figured out how to set Jetty Logging up so that I have
visibility on what's happening yet. I see a call setting the
{{solr.solr.home}} property in setUp() on line #49, so maybe that value is not
in sync with the current directory I transferred from the Ant configuration.
# {{solr/contrib/extraction}}'s
{{ExtractingRequestHandlerTest.testArabicPDF()}} test fails because no result
is found containing the extracted Arabic term (line #353). I have traced
content extraction up through plain text extraction from the PDF, and that
seems to be working, so I don't think it's a classpath issue with Tika or
PDFBox. I need to keep tracing to see happens after the text extraction.
> 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.patch, LUCENE-2657.patch
>
>
> The current Maven POM templates only contain dependency information, the bare
> bones necessary for uploading artifacts to the Maven repository.
> Full Maven POMs will include the information necessary to run a multi-module
> Maven build, in addition to serving the same purpose as the current POM
> templates.
--
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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12917720#action_12917720
]
Robert Muir commented on LUCENE-2657:
-
bq. I dropped in the ICU4J 4.4.2 jar, and everything compiled and all tests
succeeded under Maven except for the same two tests, which continued to fail.
Well it wasn't the icu issue then, but we needed to upgrade anyway for the
bugfixes, no loss.
What failure are you seeing? When prototyping the the ant system refactor
(SOLR-2002 / SOLR-2002_merged.patch), i had a few issues
with some tests but I don't remember the details. I remember it was really
important to get the CWD of the junit run correct, e.g. in that patch its:
{noformat}
and later invoked as junit's dir="${tests.userdir}" attribute
{noformat}
> 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.patch, LUCENE-2657.patch
>
>
> The current Maven POM templates only contain dependency information, the bare
> bones necessary for uploading artifacts to the Maven repository.
> Full Maven POMs will include the information necessary to run a multi-module
> Maven build, in addition to serving the same purpose as the current POM
> templates.
--
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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12917636#action_12917636
]
Steven Rowe commented on LUCENE-2657:
-
{quote}
bq. Except for two Solr tests, all tests pass. The two tests that fail for me
(on Win Vista 64, Sun JDK 1.6.0_13) are: JettyWebAppTest and Solr Cell's
ExtractingRequestHandlerTest.testArabicPDF().
maybe it is an icu classpath issue. modules/analysis and
solr/contrib/extraction both use different, out of date versions.
i opened LUCENE-2683
{quote}
I dropped in the ICU4J 4.4.2 jar, and everything compiled and all tests
succeeded under Maven except for the same two tests, which continued to fail.
> 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.patch, LUCENE-2657.patch
>
>
> The current Maven POM templates only contain dependency information, the bare
> bones necessary for uploading artifacts to the Maven repository.
> Full Maven POMs will include the information necessary to run a multi-module
> Maven build, in addition to serving the same purpose as the current POM
> templates.
--
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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[ https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12917448#action_12917448 ] Steven Rowe commented on LUCENE-2657: - bq. Would system scope dependencies be an alternative way? I thought of that, and it probably makes sense for most of them. But a jar like tika-parsers-0.8-SNAPSHOT.jar, with 10 or 15 dependencies, would be even messier to deal with as a system dependency than as a locally installed artifact. We would have to go look at the POM for it (contained conveniently within the jar, as it happens), compare the dependencies against the versions of the local dependencies (which would have previously had to be transferred to the both the Solr Cell and the DIH Extras POMs) and make changes in both places. > 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.patch > > > The current Maven POM templates only contain dependency information, the bare > bones necessary for uploading artifacts to the Maven repository. > Full Maven POMs will include the information necessary to run a multi-module > Maven build, in addition to serving the same purpose as the current POM > templates. -- 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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[ https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12917438#action_12917438 ] Chris Male commented on LUCENE-2657: Hi Steven, bq. The following script, which installs non-mavenized artifacts into the user's local Maven repository Would system scope dependencies be an alternative way? Then we can specify the systemPath to where the jars are in the lib folders. Reason I suggest this is that if someone replaces one of those jar (which will happen I'm sure) or simply adds another, then we cannot simply update the appropriate pom. We'd also need to install the jars locally (possibly again). > 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.patch > > > The current Maven POM templates only contain dependency information, the bare > bones necessary for uploading artifacts to the Maven repository. > Full Maven POMs will include the information necessary to run a multi-module > Maven build, in addition to serving the same purpose as the current POM > templates. -- 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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[ https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12917368#action_12917368 ] Robert Muir commented on LUCENE-2657: - bq. Except for two Solr tests, all tests pass. The two tests that fail for me (on Win Vista 64, Sun JDK 1.6.0_13) are: JettyWebAppTest and Solr Cell's ExtractingRequestHandlerTest.testArabicPDF(). maybe it is an icu classpath issue. modules/analysis and solr/contrib/extraction both use different, out of date versions. i opened LUCENE-2683 > 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 >Reporter: Steven Rowe >Assignee: Steven Rowe > Fix For: 3.1, 4.0 > > Attachments: LUCENE-2657.patch > > > The current Maven POM templates only contain dependency information, the bare > bones necessary for uploading artifacts to the Maven repository. > Full Maven POMs will include the information necessary to run a multi-module > Maven build, in addition to serving the same purpose as the current POM > templates. -- 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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[
https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914112#action_12914112
]
Steven Rowe commented on LUCENE-2657:
-
{quote}
bq. Full Maven POMs will include the information necessary to run a
multi-module Maven build
That sort of sounds like a parallel build process (i.e. you would be able to
build lucene/solr itself with maven). Is it?
We've avoided that type of thing in the past.
{quote}
Yes, it constitutes a parallel build process, but the Ant build process would
remain the official build. For example, the artifacts produced by the Maven
build will not be exactly the same as those produced by the Ant build process,
and so cannot be used as release artifacts.
It has been noted elsewhere that a Maven build has never been produced for
Lucene. I hope in this issue to provide that, so that the discussion about
whether or not to include it in the source tree has a concrete reference point.
> 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
>Reporter: Steven Rowe
>Assignee: Steven Rowe
> Fix For: 3.1, 4.0
>
>
> The current Maven POM templates only contain dependency information, the bare
> bones necessary for uploading artifacts to the Maven repository.
> Full Maven POMs will include the information necessary to run a multi-module
> Maven build, in addition to serving the same purpose as the current POM
> templates.
--
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
[jira] Commented: (LUCENE-2657) Replace Maven POM templates with full POMs, and change documentation accordingly
[ https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914104#action_12914104 ] Yonik Seeley commented on LUCENE-2657: -- bq. Full Maven POMs will include the information necessary to run a multi-module Maven build That sort of sounds like a parallel build process (i.e. you would be able to build lucene/solr itself with maven). Is it? We've avoided that type of thing in the past. > 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 >Reporter: Steven Rowe >Assignee: Steven Rowe > Fix For: 3.1, 4.0 > > > The current Maven POM templates only contain dependency information, the bare > bones necessary for uploading artifacts to the Maven repository. > Full Maven POMs will include the information necessary to run a multi-module > Maven build, in addition to serving the same purpose as the current POM > templates. -- 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
