subject:"Solr and Maven"


 [ 
https://issues.apache.org/jira/browse/SOLR-4287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe updated SOLR-4287:
-

Attachment: SOLR-4287.patch

Patch removing apache- from all Ant-produced Solr artifact names.

I haven't tested it yet, this is just the result of find/replace.

Testing now.

 Maven artifact file names do not match dist/ file names
 ---

 Key: SOLR-4287
 URL: https://issues.apache.org/jira/browse/SOLR-4287
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 4.0
Reporter: Ryan Ernst
Priority: Minor
 Attachments: SOLR-4287.patch


 For the solr artifact, the war file name has the format solr-X.Y.Z.war.
 http://search.maven.org/#artifactdetails%7Corg.apache.solr%7Csolr%7C4.0.0%7Cwar
 However, when building from source or downloading the dist/ built war file, 
 it is named apache-solr-X.Y.Z.war.  This should really be the same...
 Preferably the apache- could just be removed, since the lucene build does 
 not appear to use the same convention.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4287) Maven artifact file names do not match dist/ file names

2013-01-11 Thread Robert Muir (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-4287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Muir updated SOLR-4287:
--

Attachment: SOLR-4287_alternative.patch

here's an alternative patch. Steve was doing it at the same time :)

 Maven artifact file names do not match dist/ file names
 ---

 Key: SOLR-4287
 URL: https://issues.apache.org/jira/browse/SOLR-4287
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 4.0
Reporter: Ryan Ernst
Priority: Minor
 Attachments: SOLR-4287_alternative.patch, SOLR-4287.patch


 For the solr artifact, the war file name has the format solr-X.Y.Z.war.
 http://search.maven.org/#artifactdetails%7Corg.apache.solr%7Csolr%7C4.0.0%7Cwar
 However, when building from source or downloading the dist/ built war file, 
 it is named apache-solr-X.Y.Z.war.  This should really be the same...
 Preferably the apache- could just be removed, since the lucene build does 
 not appear to use the same convention.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4287) Maven artifact file names do not match dist/ file names


[ 
https://issues.apache.org/jira/browse/SOLR-4287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13551389#comment-13551389
 ] 

Steve Rowe commented on SOLR-4287:
--

:)

Robert, I applied your patch to a different trunk checkout and did a recursive 
diff on the two.  There are no differences (other than .svn crap and IntelliJ 
config files).

 Maven artifact file names do not match dist/ file names
 ---

 Key: SOLR-4287
 URL: https://issues.apache.org/jira/browse/SOLR-4287
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 4.0
Reporter: Ryan Ernst
Priority: Minor
 Attachments: SOLR-4287_alternative.patch, SOLR-4287.patch


 For the solr artifact, the war file name has the format solr-X.Y.Z.war.
 http://search.maven.org/#artifactdetails%7Corg.apache.solr%7Csolr%7C4.0.0%7Cwar
 However, when building from source or downloading the dist/ built war file, 
 it is named apache-solr-X.Y.Z.war.  This should really be the same...
 Preferably the apache- could just be removed, since the lucene build does 
 not appear to use the same convention.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4287) Maven artifact file names do not match dist/ file names


[ 
https://issues.apache.org/jira/browse/SOLR-4287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13551393#comment-13551393
 ] 

Steve Rowe commented on SOLR-4287:
--

FYI: we both made the same decision about removing apache- from the Solr 
release archive names (a separate issue from the artifact names).

 Maven artifact file names do not match dist/ file names
 ---

 Key: SOLR-4287
 URL: https://issues.apache.org/jira/browse/SOLR-4287
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 4.0
Reporter: Ryan Ernst
Priority: Minor
 Attachments: SOLR-4287_alternative.patch, SOLR-4287.patch


 For the solr artifact, the war file name has the format solr-X.Y.Z.war.
 http://search.maven.org/#artifactdetails%7Corg.apache.solr%7Csolr%7C4.0.0%7Cwar
 However, when building from source or downloading the dist/ built war file, 
 it is named apache-solr-X.Y.Z.war.  This should really be the same...
 Preferably the apache- could just be removed, since the lucene build does 
 not appear to use the same convention.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4287) Maven artifact file names do not match dist/ file names

2013-01-11 Thread Robert Muir (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-4287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13551417#comment-13551417
 ] 

Robert Muir commented on SOLR-4287:
---

my smoker is happy:

{noformat}
 [exec] SUCCESS!
 [exec] 
   [delete] Deleting directory 
/home/rmuir/workspace/lucene-trunk/lucene/build/fakeRelease
   [delete] Deleting directory 
/home/rmuir/workspace/lucene-trunk/lucene/build/fakeReleaseTmp

BUILD SUCCESSFUL
Total time: 27 minutes 40 seconds
{noformat}

 Maven artifact file names do not match dist/ file names
 ---

 Key: SOLR-4287
 URL: https://issues.apache.org/jira/browse/SOLR-4287
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 4.0
Reporter: Ryan Ernst
Priority: Minor
 Attachments: SOLR-4287_alternative.patch, SOLR-4287.patch


 For the solr artifact, the war file name has the format solr-X.Y.Z.war.
 http://search.maven.org/#artifactdetails%7Corg.apache.solr%7Csolr%7C4.0.0%7Cwar
 However, when building from source or downloading the dist/ built war file, 
 it is named apache-solr-X.Y.Z.war.  This should really be the same...
 Preferably the apache- could just be removed, since the lucene build does 
 not appear to use the same convention.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4287) Maven artifact file names do not match dist/ file names


[ 
https://issues.apache.org/jira/browse/SOLR-4287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13551477#comment-13551477
 ] 

Steve Rowe commented on SOLR-4287:
--

Mine too (OS X 10.8.2):

{noformat}
 [exec] SUCCESS!
 [exec] 
   [delete] Deleting directory 
/Users/sarowe/svn/lucene/dev/trunk2/lucene/build/fakeRelease
   [delete] Deleting directory 
/Users/sarowe/svn/lucene/dev/trunk2/lucene/build/fakeReleaseTmp

BUILD SUCCESSFUL
Total time: 36 minutes 3 seconds
{noformat}



 Maven artifact file names do not match dist/ file names
 ---

 Key: SOLR-4287
 URL: https://issues.apache.org/jira/browse/SOLR-4287
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 4.0
Reporter: Ryan Ernst
Priority: Minor
 Attachments: SOLR-4287_alternative.patch, SOLR-4287.patch


 For the solr artifact, the war file name has the format solr-X.Y.Z.war.
 http://search.maven.org/#artifactdetails%7Corg.apache.solr%7Csolr%7C4.0.0%7Cwar
 However, when building from source or downloading the dist/ built war file, 
 it is named apache-solr-X.Y.Z.war.  This should really be the same...
 Preferably the apache- could just be removed, since the lucene build does 
 not appear to use the same convention.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4287) Maven artifact file names do not match dist/ file names


 [ 
https://issues.apache.org/jira/browse/SOLR-4287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe updated SOLR-4287:
-

Fix Version/s: 4.1
 Assignee: Steve Rowe
 Priority: Blocker  (was: Minor)

 Maven artifact file names do not match dist/ file names
 ---

 Key: SOLR-4287
 URL: https://issues.apache.org/jira/browse/SOLR-4287
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 4.0
Reporter: Ryan Ernst
Assignee: Steve Rowe
Priority: Blocker
 Fix For: 4.1

 Attachments: SOLR-4287_alternative.patch, SOLR-4287.patch


 For the solr artifact, the war file name has the format solr-X.Y.Z.war.
 http://search.maven.org/#artifactdetails%7Corg.apache.solr%7Csolr%7C4.0.0%7Cwar
 However, when building from source or downloading the dist/ built war file, 
 it is named apache-solr-X.Y.Z.war.  This should really be the same...
 Preferably the apache- could just be removed, since the lucene build does 
 not appear to use the same convention.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (SOLR-4287) Maven artifact file names do not match dist/ file names

2013-01-08 Thread Ryan Ernst (JIRA)

Ryan Ernst created SOLR-4287:


 Summary: Maven artifact file names do not match dist/ file names
 Key: SOLR-4287
 URL: https://issues.apache.org/jira/browse/SOLR-4287
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 4.0
Reporter: Ryan Ernst
Priority: Minor


For the solr artifact, the war file name has the format solr-X.Y.Z.war.
http://search.maven.org/#artifactdetails%7Corg.apache.solr%7Csolr%7C4.0.0%7Cwar

However, when building from source or downloading the dist/ built war file, it 
is named apache-solr-X.Y.Z.war.  This should really be the same...

Preferably the apache- could just be removed, since the lucene build does not 
appear to use the same convention.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (SOLR-3780) Maven builds regularly fail on ASF Jenkins

2012-09-02 Thread Steven Rowe (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-3780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steven Rowe resolved SOLR-3780.
---

   Resolution: Fixed
Fix Version/s: 5.0
   4.0

I committed the patch making solrj run its own tests to branch_4x and trunk.

bq. ERROR: [doc=one] unknown field 'meta:creation-date'

Robert Muir pointed out on dev@l.a.o that this is caused by branch_4x Maven 
Solr configuration depending on Tika 1.2, while the rest of branch_4x hasn't 
gotten the update yet (SOLR-3707).  I reverted the branch_4x dependency to Tika 
1.1, and branch_4x Maven just succeeded on ASF Jenkins.

I also committed a change to all Solr contribs removing the now unnecessary 
inclusion of solr-core test resources in their test classpaths.

 Maven builds regularly fail on ASF Jenkins
 --

 Key: SOLR-3780
 URL: https://issues.apache.org/jira/browse/SOLR-3780
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 4.0, 5.0
Reporter: Steven Rowe
Assignee: Steven Rowe
 Fix For: 4.0, 5.0

 Attachments: SOLR-3780.patch


 branch_4x and to a lesser extent trunk Maven builds on ASF Jenkins regularly 
 fail with these errors:
 {noformat}
 ERROR: [doc=one] unknown field 'meta:creation-date'
 Stack Trace:
 org.apache.solr.common.SolrException: ERROR: [doc=one] unknown field 
 'meta:creation-date'
   at 
 __randomizedtesting.SeedInfo.seed([564B8C2811E551FC:388DF7271220FAA9]:0)
   at 
 org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:306)
 {noformat}
 {noformat}
 ERROR: [doc=1000] multiple values encountered for non multiValued field 
 val_i: [10, 20]
 Stack Trace:
 org.apache.solr.common.SolrException: ERROR: [doc=1000] multiple values 
 encountered for non multiValued field val_i: [10, 20]
   at 
 __randomizedtesting.SeedInfo.seed([41D9D56849179839:C03F5B703E48F805]:0)
   at 
 org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:402)
 {noformat}
 I can't reproduce these errors locally.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (SOLR-3780) Maven builds regularly fail on ASF Jenkins

2012-09-01 Thread Steven Rowe (JIRA)

Steven Rowe created SOLR-3780:
-

 Summary: Maven builds regularly fail on ASF Jenkins
 Key: SOLR-3780
 URL: https://issues.apache.org/jira/browse/SOLR-3780
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 4.0, 5.0
Reporter: Steven Rowe
Assignee: Steven Rowe


branch_4x and to a lesser extent trunk Maven builds on ASF Jenkins regularly 
fail with these errors:

{noformat}
ERROR: [doc=one] unknown field 'meta:creation-date'

Stack Trace:
org.apache.solr.common.SolrException: ERROR: [doc=one] unknown field 
'meta:creation-date'
at 
__randomizedtesting.SeedInfo.seed([564B8C2811E551FC:388DF7271220FAA9]:0)
at 
org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:306)
{noformat}

{noformat}
ERROR: [doc=1000] multiple values encountered for non multiValued field val_i: 
[10, 20]

Stack Trace:
org.apache.solr.common.SolrException: ERROR: [doc=1000] multiple values 
encountered for non multiValued field val_i: [10, 20]
at 
__randomizedtesting.SeedInfo.seed([41D9D56849179839:C03F5B703E48F805]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:402)
{noformat}

I can't reproduce these errors locally.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-3780) Maven builds regularly fail on ASF Jenkins

2012-09-01 Thread Steven Rowe (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13446765#comment-13446765
 ] 

Steven Rowe commented on SOLR-3780:
---


On the dev@l.a.o mailing list, Yonik wrote:

{quote}
multiple values encountered for non multiValued field val_i: [10, 20]

This should be very deterministic (i.e. it should always fail if it
were actually a non multiValued field).
The *_i fields are multivalued according to schema.xml, so this
exception should not happen (the version=1.0 in schema.xml means
multiValued=true by default).

Off of the top of my head, the only thing I can figure is that the
maven based tests are somehow getting the wrong schema sometimes.
Maybe if there's some different with how solr homes are set between
ant and maven?
{quote}

Currently, under the Maven build, solr-core and solrj tests are run together 
under the solr-core module, because Maven can't handle the dependencies among 
solr-core, solr test-framework, and solrj.  As a result, both solr-core and 
solrj resources are co-mingled.  I think this is what's happening here: due to 
the apparently non-deterministic solr-home detection logic, in some 
environments, the wrong {{schema.xml}} file is used with some tests.


 Maven builds regularly fail on ASF Jenkins
 --

 Key: SOLR-3780
 URL: https://issues.apache.org/jira/browse/SOLR-3780
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 4.0, 5.0
Reporter: Steven Rowe
Assignee: Steven Rowe

 branch_4x and to a lesser extent trunk Maven builds on ASF Jenkins regularly 
 fail with these errors:
 {noformat}
 ERROR: [doc=one] unknown field 'meta:creation-date'
 Stack Trace:
 org.apache.solr.common.SolrException: ERROR: [doc=one] unknown field 
 'meta:creation-date'
   at 
 __randomizedtesting.SeedInfo.seed([564B8C2811E551FC:388DF7271220FAA9]:0)
   at 
 org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:306)
 {noformat}
 {noformat}
 ERROR: [doc=1000] multiple values encountered for non multiValued field 
 val_i: [10, 20]
 Stack Trace:
 org.apache.solr.common.SolrException: ERROR: [doc=1000] multiple values 
 encountered for non multiValued field val_i: [10, 20]
   at 
 __randomizedtesting.SeedInfo.seed([41D9D56849179839:C03F5B703E48F805]:0)
   at 
 org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:402)
 {noformat}
 I can't reproduce these errors locally.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-3780) Maven builds regularly fail on ASF Jenkins

2012-09-01 Thread Steven Rowe (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-3780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steven Rowe updated SOLR-3780:
--

Attachment: SOLR-3780.patch

This patch separates solrj testing under Maven so that it runs on its own, 
rather than with solr-core.

In order to do this, solrj needs to include solr-core source as test source, 
and include all solr-core dependencies as test dependencies.

All tests pass for me locally.

 Maven builds regularly fail on ASF Jenkins
 --

 Key: SOLR-3780
 URL: https://issues.apache.org/jira/browse/SOLR-3780
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 4.0, 5.0
Reporter: Steven Rowe
Assignee: Steven Rowe
 Attachments: SOLR-3780.patch


 branch_4x and to a lesser extent trunk Maven builds on ASF Jenkins regularly 
 fail with these errors:
 {noformat}
 ERROR: [doc=one] unknown field 'meta:creation-date'
 Stack Trace:
 org.apache.solr.common.SolrException: ERROR: [doc=one] unknown field 
 'meta:creation-date'
   at 
 __randomizedtesting.SeedInfo.seed([564B8C2811E551FC:388DF7271220FAA9]:0)
   at 
 org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:306)
 {noformat}
 {noformat}
 ERROR: [doc=1000] multiple values encountered for non multiValued field 
 val_i: [10, 20]
 Stack Trace:
 org.apache.solr.common.SolrException: ERROR: [doc=1000] multiple values 
 encountered for non multiValued field val_i: [10, 20]
   at 
 __randomizedtesting.SeedInfo.seed([41D9D56849179839:C03F5B703E48F805]:0)
   at 
 org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:402)
 {noformat}
 I can't reproduce these errors locally.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging

2012-04-27 Thread Robert Muir (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13263397#comment-13263397
 ] 

Robert Muir commented on SOLR-3405:
---

{quote}
 If we are worried about supporting the 1-off crazy patched jar, we can point 
it to something as crazy as:
{quote}

Really? Then you can also tell infra to disable the release mirroring system: 
hey its useless, we just have svn.

Somehow I don't think that would go over well: they would probably just delete 
the jar.

We still dont have:
* a way to handle patched dependencies for maven
* a way to handle dependencies that are not in maven
* a packaging system for maven consistent with our other packaging.

In other words: maven is out of control. 

I'm now with Mike, I think we have to get this out from under our PMC and do it 
some other way.
 

 maven artifacts should be equivalent to binary packaging
 

 Key: SOLR-3405
 URL: https://issues.apache.org/jira/browse/SOLR-3405
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
 Fix For: 4.1


 Lets take the commons-csv scenario: 
 * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
 anywhere,
   in fact it contains no third party jars (the stuff present in solr/lib) at 
 all.
 * binary distribution contains only the jars necessary for *solrj* and 
 *contrib plugins*, and a solr.war
 I think the maven artifacts should match whats in the binary release (no 
 third party jars 
 inside the .war are exposed, we just publish the .war itself). This exposes 
 a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging

2012-04-27 Thread Steven Rowe (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13263839#comment-13263839
 ] 

Steven Rowe commented on SOLR-3405:
---

bq. I'm now with Mike, I think we have to get this out from under our PMC and 
do it some other way.

What changed your mind?  (Serious question)

 maven artifacts should be equivalent to binary packaging
 

 Key: SOLR-3405
 URL: https://issues.apache.org/jira/browse/SOLR-3405
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
 Fix For: 4.1


 Lets take the commons-csv scenario: 
 * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
 anywhere,
   in fact it contains no third party jars (the stuff present in solr/lib) at 
 all.
 * binary distribution contains only the jars necessary for *solrj* and 
 *contrib plugins*, and a solr.war
 I think the maven artifacts should match whats in the binary release (no 
 third party jars 
 inside the .war are exposed, we just publish the .war itself). This exposes 
 a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging

2012-04-27 Thread Robert Muir (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13263890#comment-13263890
 ] 

Robert Muir commented on SOLR-3405:
---

{quote}
What changed your mind? (Serious question)
{quote}

Seriously: I want our releases clean and bulletproof from problems.

People can say we only vote on the source release, but we can't pretend that we 
are not
responsible for binary/maven artifacts we produce too. The commons-csv issue 
showed that
as a PMC we get hassled about these things too!

So when we put stuff up in 
people.apache.org/~whoever/staging_area/lucene-solr-XXX.YYY,
I want everything in that folder to be packaged correctly, not illegal, not 
causing
problems to other projects, etc, etc.

Its unrelated to the benefits of maven. I just want this stuff clean.

So I got frustrated with some of the responses/suggestions here that seem like 
maybe 
people aren't taking this stuff as seriously as we should be.

We are held responsible for the stuff we put out, so if people feel anything 
goes
for the maven artifacts as long as they work, then I don't know how we as a PMC 
are
supposed to have any confidence at all that they are clean!

You can say i'm being overly anal or a policeman or whatever, but I feel I have 
to
be watching this maven stuff like a hawk right now (even though i dont really 
understand
it). 

So it starts to become clear to me, that not everyone cares so much about the 
maven
artifacts being proper and correct. With that being the case, *I* don't want to 
be 
responsible for it, I'd just as soon absolve myself of it, get back to working 
on
search engines, and let someone else (not our PMC) be held to the fire for it.



 maven artifacts should be equivalent to binary packaging
 

 Key: SOLR-3405
 URL: https://issues.apache.org/jira/browse/SOLR-3405
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
 Fix For: 4.1


 Lets take the commons-csv scenario: 
 * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
 anywhere,
   in fact it contains no third party jars (the stuff present in solr/lib) at 
 all.
 * binary distribution contains only the jars necessary for *solrj* and 
 *contrib plugins*, and a solr.war
 I think the maven artifacts should match whats in the binary release (no 
 third party jars 
 inside the .war are exposed, we just publish the .war itself). This exposes 
 a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging

2012-04-27 Thread Steven Rowe (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13264020#comment-13264020
]

Steven Rowe commented on SOLR-3405:
---

bq. So I got frustrated with some of the responses/suggestions here that seem
like maybe people aren't taking this stuff as seriously as we should be.

I'm taking this stuff seriously.

* patched dependencies: There is no patched-dependencies solution for Maven at
this point, but putting patched dependencies up as forked projects with
download jar links on github makes them exactly like other non-mavenized
dependencies, so if Lucene/Solr goes that route independent of Maven concerns,
then it isn't a separate issue for Maven.

* non-mavenized dependencies: the standard Maven-proponent answer (i.e. just
put them in Maven) may work some of the time, but it certainly isn't a
panacea, and Lucene/Solr needs to cover all bases. I think ivy-maven-plugin
could address most, and maybe all, of the cases where just put them in Maven
doesn't work.

* packaging: I would split this into two concerns:
** Maven binary jar/war artifacts should be identical (bit for bit) to the
official binary artifacts.
** Maven POMs should require the same dependencies that Solr ships with. In
other words, as I stated previously on this issue: POMs for Solr jars/war
published on Maven Central should never require (i.e., have a non-optional
dependency on) a third party artifact if that third party dependency is not
directly included in the binary package; the contents of the war don't count as
inclusion in the binary package.

This issue is supposed to be about this last point. I don't agree with the
idea myself.

Here's why: Maven POMs should list the dependencies required to use the
associated artifact. I seriously don't understand why it matters if this
differs from the 3rd party libraries shipped (directly, not in the war) with
the convenience binary package.

And, as Ryan has stated on this issue, what's included in the convenience
binary package is subject to change - we could just start including all 3rd
party libraries in the Solr convenience distribution. Why not?

maven artifacts should be equivalent to binary packaging

Key: SOLR-3405
URL: https://issues.apache.org/jira/browse/SOLR-3405
Project: Solr
Issue Type: Task
Components: Build
Reporter: Robert Muir
Fix For: 4.1

Lets take the commons-csv scenario:
* apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar
anywhere,
in fact it contains no third party jars (the stuff present in solr/lib) at
all.
* binary distribution contains only the jars necessary for *solrj* and
*contrib plugins*, and a solr.war
I think the maven artifacts should match whats in the binary release (no
third party jars
inside the .war are exposed, we just publish the .war itself). This exposes
a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging

2012-04-26 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13262650#comment-13262650
 ] 

David Smiley commented on SOLR-3405:


There is a lot of discussion here and I don't want to complicate anything.

What I do want to say, as a user of Maven and of Lucene/Solr's Maven artifacts 
specifically, is that it is *awesome* that I can have a maven based project 
that has a dependency on the Solr test framework and it just works thanks to 
all of the dependency resolution of Maven, and thanks to Maven and IDE 
integration, IntelliJ grabs all the source which helps tremendously -- its 
automatic.  My code can either be strictly a SolrJ client or it can extend 
Lucene or Solr.  I don't want this to go away.  Once upon a time it didn't work 
or the dependencies metadata declared were poor and I did my part in making it 
work well (and certainly Steve did too).

 maven artifacts should be equivalent to binary packaging
 

 Key: SOLR-3405
 URL: https://issues.apache.org/jira/browse/SOLR-3405
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
 Fix For: 4.1


 Lets take the commons-csv scenario: 
 * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
 anywhere,
   in fact it contains no third party jars (the stuff present in solr/lib) at 
 all.
 * binary distribution contains only the jars necessary for *solrj* and 
 *contrib plugins*, and a solr.war
 I think the maven artifacts should match whats in the binary release (no 
 third party jars 
 inside the .war are exposed, we just publish the .war itself). This exposes 
 a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging


[ 
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13262659#comment-13262659
 ] 

Robert Muir commented on SOLR-3405:
---

I don't care if maven can cook me dinner or get me a beer out of the fridge.

Thousands of people can comment on this issue about how great it is, no one 
cares.

The bottom line is that people are going to be uncomfortable with it being in 
our releases, 
and these threads will continue to pop up, as long as the *maven artifacts* are 
handled 
differently from the other packaging: its just that simple.

By making it consistent with the other packaging people are less likely to 
complain,
because then its not such a mystery and isnt a separate/different product.


 maven artifacts should be equivalent to binary packaging
 

 Key: SOLR-3405
 URL: https://issues.apache.org/jira/browse/SOLR-3405
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
 Fix For: 4.1


 Lets take the commons-csv scenario: 
 * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
 anywhere,
   in fact it contains no third party jars (the stuff present in solr/lib) at 
 all.
 * binary distribution contains only the jars necessary for *solrj* and 
 *contrib plugins*, and a solr.war
 I think the maven artifacts should match whats in the binary release (no 
 third party jars 
 inside the .war are exposed, we just publish the .war itself). This exposes 
 a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging

2012-04-26 Thread Dawid Weiss (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13262676#comment-13262676
 ] 

Dawid Weiss commented on SOLR-3405:
---

bq By making it consistent with the other packaging people are less likely to 
complain,
because then its not such a mystery and isnt a separate/different product.

I think that's the point David was making -- if you go with manual POM + 
released JARs packaging then things will actually be of poorer quality (and 
very likely broken) for lots of maven users.

 maven artifacts should be equivalent to binary packaging
 

 Key: SOLR-3405
 URL: https://issues.apache.org/jira/browse/SOLR-3405
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
 Fix For: 4.1


 Lets take the commons-csv scenario: 
 * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
 anywhere,
   in fact it contains no third party jars (the stuff present in solr/lib) at 
 all.
 * binary distribution contains only the jars necessary for *solrj* and 
 *contrib plugins*, and a solr.war
 I think the maven artifacts should match whats in the binary release (no 
 third party jars 
 inside the .war are exposed, we just publish the .war itself). This exposes 
 a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging


[ 
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13262680#comment-13262680
 ] 

Robert Muir commented on SOLR-3405:
---

{quote}
then things will actually be of poorer quality (and very likely broken) for 
lots of maven users.
{quote}

I'm not sure 'lots' is the correct word here. I think the vast majority of solr 
users use it
as an application. The vocal ones here are the ones that are committers who 
PREFER to use maven,
but thats a vocal minority.

 maven artifacts should be equivalent to binary packaging
 

 Key: SOLR-3405
 URL: https://issues.apache.org/jira/browse/SOLR-3405
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
 Fix For: 4.1


 Lets take the commons-csv scenario: 
 * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
 anywhere,
   in fact it contains no third party jars (the stuff present in solr/lib) at 
 all.
 * binary distribution contains only the jars necessary for *solrj* and 
 *contrib plugins*, and a solr.war
 I think the maven artifacts should match whats in the binary release (no 
 third party jars 
 inside the .war are exposed, we just publish the .war itself). This exposes 
 a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging

2012-04-26 Thread Uwe Schindler (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13262683#comment-13262683
]

Uwe Schindler commented on SOLR-3405:
-

{quote}
bq. then things will actually be of poorer quality (and very likely broken) for
lots of maven users.

I'm not sure 'lots' is the correct word here. I think the vast majority of solr
users use it as an application. The vocal ones here are the ones that are
committers who PREFER to use maven, but thats a vocal minority.
{quote}

I completely agree with Robert here! Solr's only artifacts should we solrj and
the war file.

maven artifacts should be equivalent to binary packaging

Key: SOLR-3405
URL: https://issues.apache.org/jira/browse/SOLR-3405
Project: Solr
Issue Type: Task
Components: Build
Reporter: Robert Muir
Fix For: 4.1

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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging

2012-04-26 Thread Ryan McKinley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13262718#comment-13262718
 ] 

Ryan McKinley commented on SOLR-3405:
-

Again, solr is an API and an application -- the plugin structure is well 
advertised, promoted, and well used.

If anything, this discussion points me to think that the binary dist should 
include a solr-lib folder (though I don't really care)



 maven artifacts should be equivalent to binary packaging
 

 Key: SOLR-3405
 URL: https://issues.apache.org/jira/browse/SOLR-3405
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
 Fix For: 4.1


 Lets take the commons-csv scenario: 
 * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
 anywhere,
   in fact it contains no third party jars (the stuff present in solr/lib) at 
 all.
 * binary distribution contains only the jars necessary for *solrj* and 
 *contrib plugins*, and a solr.war
 I think the maven artifacts should match whats in the binary release (no 
 third party jars 
 inside the .war are exposed, we just publish the .war itself). This exposes 
 a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging


[ 
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13262739#comment-13262739
 ] 

Steven Rowe commented on SOLR-3405:
---

bq. If anything, this discussion points me to think that the binary dist should 
include a solr-lib folder (though I don't really care)

It already does - the folder is called {{dist/}}, and it includes all of the 
API .jars right there alongside the war.

 maven artifacts should be equivalent to binary packaging
 

 Key: SOLR-3405
 URL: https://issues.apache.org/jira/browse/SOLR-3405
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
 Fix For: 4.1


 Lets take the commons-csv scenario: 
 * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
 anywhere,
   in fact it contains no third party jars (the stuff present in solr/lib) at 
 all.
 * binary distribution contains only the jars necessary for *solrj* and 
 *contrib plugins*, and a solr.war
 I think the maven artifacts should match whats in the binary release (no 
 third party jars 
 inside the .war are exposed, we just publish the .war itself). This exposes 
 a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging


[ 
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13262744#comment-13262744
 ] 

Robert Muir commented on SOLR-3405:
---

it doesn't include their libs. unzip it and see!

 maven artifacts should be equivalent to binary packaging
 

 Key: SOLR-3405
 URL: https://issues.apache.org/jira/browse/SOLR-3405
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
 Fix For: 4.1


 Lets take the commons-csv scenario: 
 * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
 anywhere,
   in fact it contains no third party jars (the stuff present in solr/lib) at 
 all.
 * binary distribution contains only the jars necessary for *solrj* and 
 *contrib plugins*, and a solr.war
 I think the maven artifacts should match whats in the binary release (no 
 third party jars 
 inside the .war are exposed, we just publish the .war itself). This exposes 
 a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging


[ 
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13262747#comment-13262747
 ] 

Robert Muir commented on SOLR-3405:
---

like i said: this whole issue came out of third party dependency issues.

I've said it before, and I'll say it again (I might have to start copy/pasting 
myself?!):

You can unzip the binary release and see that third party
dependencies such as guava are not in it. Third party dependencies of solr 
are only inside the solr.war (treated as application).

However the maven release treats it as an API, exposing the innards of the 
solr.war
application and making us responsible for these addtl dependencies.


 maven artifacts should be equivalent to binary packaging
 

 Key: SOLR-3405
 URL: https://issues.apache.org/jira/browse/SOLR-3405
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
 Fix For: 4.1


 Lets take the commons-csv scenario: 
 * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
 anywhere,
   in fact it contains no third party jars (the stuff present in solr/lib) at 
 all.
 * binary distribution contains only the jars necessary for *solrj* and 
 *contrib plugins*, and a solr.war
 I think the maven artifacts should match whats in the binary release (no 
 third party jars 
 inside the .war are exposed, we just publish the .war itself). This exposes 
 a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging


[ 
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13262764#comment-13262764
 ] 

Robert Muir commented on SOLR-3405:
---

I'm just going to repeat the description of the issue, since people are having 
problems finding it:
{quote}
Lets take the commons-csv scenario:

* apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
anywhere,
  in fact it contains no third party jars (the stuff present in solr/lib) at 
all.
* binary distribution contains only the jars necessary for solrj and contrib 
plugins, and a solr.war

I think the maven artifacts should match whats in the binary release (no third 
party jars
inside the .war are exposed, we just publish the .war itself). This exposes a 
lot less surface area.
{quote}

 maven artifacts should be equivalent to binary packaging
 

 Key: SOLR-3405
 URL: https://issues.apache.org/jira/browse/SOLR-3405
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
 Fix For: 4.1


 Lets take the commons-csv scenario: 
 * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
 anywhere,
   in fact it contains no third party jars (the stuff present in solr/lib) at 
 all.
 * binary distribution contains only the jars necessary for *solrj* and 
 *contrib plugins*, and a solr.war
 I think the maven artifacts should match whats in the binary release (no 
 third party jars 
 inside the .war are exposed, we just publish the .war itself). This exposes 
 a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging

2012-04-26 Thread Ryan McKinley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13262779#comment-13262779
 ] 

Ryan McKinley commented on SOLR-3405:
-

right, so given the problem:

bq. binary distribution contains only the jars necessary for solrj and contrib 
plugins, and a solr.war

The solution is to add the dependencies for solr-core.jar to the binary 
distribution.

 maven artifacts should be equivalent to binary packaging
 

 Key: SOLR-3405
 URL: https://issues.apache.org/jira/browse/SOLR-3405
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
 Fix For: 4.1


 Lets take the commons-csv scenario: 
 * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
 anywhere,
   in fact it contains no third party jars (the stuff present in solr/lib) at 
 all.
 * binary distribution contains only the jars necessary for *solrj* and 
 *contrib plugins*, and a solr.war
 I think the maven artifacts should match whats in the binary release (no 
 third party jars 
 inside the .war are exposed, we just publish the .war itself). This exposes 
 a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging

2012-04-26 Thread David Smiley (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13262781#comment-13262781
]

David Smiley commented on SOLR-3405:

Ugh; I can't stay away from this soap opera train wreck.

I'm not on the PMC so perhaps I should bud out, but if a successful conclusion
to this JIRA issue means that dependencies such as commons-csv don't wind up in
maven central, thus preventing me from effectively utilizing Solr as an API
with Maven, I'm -1. All sorts of open-source dependencies are in maven central
published unofficially using coordinates of another project that needed it
there, customized or not. What's it to you?

I understand if Rob, Mike, etc. want nothing to do with Maven and I think
that's just fine. But please don't stand in Steve and I's way.

maven artifacts should be equivalent to binary packaging

Key: SOLR-3405
URL: https://issues.apache.org/jira/browse/SOLR-3405
Project: Solr
Issue Type: Task
Components: Build
Reporter: Robert Muir
Fix For: 4.1

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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging

[
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13262818#comment-13262818
]

Robert Muir commented on SOLR-3405:
---

{quote}
All sorts of open-source dependencies are in maven central published
unofficially using coordinates of another project that needed it there,
customized or not. What's it to you?
{quote}

I don't care. we shouldn't release other peoples code. Thats what got us into
trouble in the first place.

{quote}
I understand if Rob, Mike, etc. want nothing to do with Maven and I think
that's just fine. But please don't stand in Steve and I's way.
{quote}

A cavalier attitude about whats in our releases doesn't help increase our
confidence in this maven business.

maven artifacts should be equivalent to binary packaging

Key: SOLR-3405
URL: https://issues.apache.org/jira/browse/SOLR-3405
Project: Solr
Issue Type: Task
Components: Build
Reporter: Robert Muir
Fix For: 4.1

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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging

2012-04-26 Thread Michael McCandless (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13262884#comment-13262884
]

Michael McCandless commented on SOLR-3405:
--

bq. I understand if Rob, Mike, etc. want nothing to do with Maven and I think
that's just fine. But please don't stand in Steve and I's way.

It's not that I want to stand in your way.

I agree that many users want to consume Lucene/Solr from Maven's
central repository, and I agree that users want to to build their own
projects, depending on Lucene/Solr, using Maven. That's all great.

I want Lucene/Solr to be widely accessible/adopted and so pushing to
Maven central helps achieve that goal.

I just don't think it should be this PMC that votes on / pushes our
released artifacts to Maven.

Pushing to Maven has clear risks (we got in trouble for it), not
all PMC members understand the Maven policies/conventions, it's a
distraction (we are supposed to be focused on building great search
engines around here).

We don't push to all the other great repositories (apt, yum, FreeBSD,
etc.) out there. We don't understand their conventions either. The
PMC doesn't vote when a downstream package maintainer pushes our
artifacts into their repository. Why should Maven central be any
different from other repositories?

And I still assert that a stronger decoupling the PMC voting on the
true Lucene/Solr artifacts from pushing-to-Maven-central would
net/net be a win for Maven users. Eg, Lucene 3.4.0's Maven artifacts
were broken (SOLR-2770), and now apparently also 3.6.0's (SOLR-3411).
But if the two events were fully decoupled then the Maven POMs could
be re-pushed without this PMC being involved. And issues like this
(which jars/wars should be pushed into Maven central... solr.war
expanded or not) wouldn't be this PMC's business. The Maven experts
would be free to make such decisions.

Maybe... a possible compromise here would be to continue pushing to
Maven central, but as a downstream event (after a release) within this
project. Meaning, the PMC votes on the original sources/convenience
binaries, but then the Maven experts around here can separately (once
the vote passes) take that binary release, expand it, attach POMs,
etc., and push to Maven central. This would mean the PMC doesn't vote
on what's-pushed-to-Maven, but we continue using this project's
infrastructure (svn, continuous builds, Jira, etc.) to push to Maven
central. Could something like that work?

maven artifacts should be equivalent to binary packaging

Key: SOLR-3405
URL: https://issues.apache.org/jira/browse/SOLR-3405
Project: Solr
Issue Type: Task
Components: Build
Reporter: Robert Muir
Fix For: 4.1

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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging


[ 
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13263107#comment-13263107
 ] 

Steven Rowe commented on SOLR-3405:
---

{quote}
Lucene 3.4.0's Maven artifacts were broken (SOLR-2770), and now apparently also 
3.6.0's (SOLR-3411).
{quote}

I just resolved SOLR-3411 as Not a Problem.  The brokenness (from that 
issue's reporter's perspective) was an example of exactly the non-virality that 
you have been lobbying for, Mike.

 maven artifacts should be equivalent to binary packaging
 

 Key: SOLR-3405
 URL: https://issues.apache.org/jira/browse/SOLR-3405
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
 Fix For: 4.1


 Lets take the commons-csv scenario: 
 * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
 anywhere,
   in fact it contains no third party jars (the stuff present in solr/lib) at 
 all.
 * binary distribution contains only the jars necessary for *solrj* and 
 *contrib plugins*, and a solr.war
 I think the maven artifacts should match whats in the binary release (no 
 third party jars 
 inside the .war are exposed, we just publish the .war itself). This exposes 
 a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging


[ 
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13263116#comment-13263116
 ] 

Steven Rowe commented on SOLR-3405:
---

bq. But if the two events were fully decoupled then the Maven POMs could
be re-pushed without this PMC being involved.

Benson asserted elsewhere that if an ASF-external project wanted to push 
Lucene/Solr Maven artifacts, they would NOT be able to use 
org.apache.lucene/solr as the groupId for those artifacts.  I view that as a 
significant problem, if it is in fact true.

 maven artifacts should be equivalent to binary packaging
 

 Key: SOLR-3405
 URL: https://issues.apache.org/jira/browse/SOLR-3405
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
 Fix For: 4.1


 Lets take the commons-csv scenario: 
 * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
 anywhere,
   in fact it contains no third party jars (the stuff present in solr/lib) at 
 all.
 * binary distribution contains only the jars necessary for *solrj* and 
 *contrib plugins*, and a solr.war
 I think the maven artifacts should match whats in the binary release (no 
 third party jars 
 inside the .war are exposed, we just publish the .war itself). This exposes 
 a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Issue Comment Edited] (SOLR-3405) maven artifacts should be equivalent to binary packaging

[
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13263116#comment-13263116
]

Steven Rowe edited comment on SOLR-3405 at 4/26/12 8:38 PM:

bq. But if the two events were fully decoupled then the Maven POMs could be
re-pushed without this PMC being involved.

Benson asserted elsewhere that if an ASF-external project wanted to push
Lucene/Solr Maven artifacts, they would NOT be able to use
org.apache.lucene/solr as the groupId for those artifacts. I view that as a
significant problem, if it is in fact true.

was (Author: steve_rowe):
bq. But if the two events were fully decoupled then the Maven POMs could
be re-pushed without this PMC being involved.

maven artifacts should be equivalent to binary packaging

Key: SOLR-3405
URL: https://issues.apache.org/jira/browse/SOLR-3405
Project: Solr
Issue Type: Task
Components: Build
Reporter: Robert Muir
Fix For: 4.1

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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging


[ 
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13263121#comment-13263121
 ] 

Robert Muir commented on SOLR-3405:
---

Who enforces that?

Chris male had no problem putting up langdetect under com.cybozu.labs, and he 
has nothing to do with them :)

http://search.maven.org/remotecontent?filepath=com/cybozu/labs/langdetect/1.1-20120112/langdetect-1.1-20120112.pom

 maven artifacts should be equivalent to binary packaging
 

 Key: SOLR-3405
 URL: https://issues.apache.org/jira/browse/SOLR-3405
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
 Fix For: 4.1


 Lets take the commons-csv scenario: 
 * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
 anywhere,
   in fact it contains no third party jars (the stuff present in solr/lib) at 
 all.
 * binary distribution contains only the jars necessary for *solrj* and 
 *contrib plugins*, and a solr.war
 I think the maven artifacts should match whats in the binary release (no 
 third party jars 
 inside the .war are exposed, we just publish the .war itself). This exposes 
 a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging


[ 
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13263125#comment-13263125
 ] 

Steven Rowe commented on SOLR-3405:
---

{quote}
Maybe... a possible compromise here would be to continue pushing to
Maven central, but as a downstream event (after a release) within this
project. Meaning, the PMC votes on the original sources/convenience
binaries, but then the Maven experts around here can separately (once
the vote passes) take that binary release, expand it, attach POMs,
etc., and push to Maven central. This would mean the PMC doesn't vote
on what's-pushed-to-Maven, but we continue using this project's
infrastructure (svn, continuous builds, Jira, etc.) to push to Maven
central. Could something like that work?
{quote}

From the Apache board perspective, I suspect that this would be viewed as a 
distinction without a difference; that is, no matter whether the PMC votes on 
Maven artifacts, the fact that they would be hosted by the Lucene/Solr 
project, and for the foreseeable future anyway, published by a PMC member, the 
PMC will continue to carry responsibility for Mavenish things when they go 
wrong.

That said, I'd be fine with this.  The only (slight) snag: Maven artifacts have 
to be signed; for the .jars/.war that's not a problem - they can be taken from 
the binary distribution.  The POMs, by contrast, will have to be separately 
signed by a Lucene/Solr PMC member.

The PMC is supposed to only be voting on source releases anyway, right?

 maven artifacts should be equivalent to binary packaging
 

 Key: SOLR-3405
 URL: https://issues.apache.org/jira/browse/SOLR-3405
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
 Fix For: 4.1


 Lets take the commons-csv scenario: 
 * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
 anywhere,
   in fact it contains no third party jars (the stuff present in solr/lib) at 
 all.
 * binary distribution contains only the jars necessary for *solrj* and 
 *contrib plugins*, and a solr.war
 I think the maven artifacts should match whats in the binary release (no 
 third party jars 
 inside the .war are exposed, we just publish the .war itself). This exposes 
 a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging

2012-04-26 Thread JIRA

[
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13263195#comment-13263195
]

Jan Høydahl commented on SOLR-3405:
---

+1 to continue publishing to mvn-repositories

It's a huge benefit for many users and downstream professionals. We have at
least 2 committers willing to maintain this, and we're getting better at it
each time. I think that's all it takes.

It seems actually that the commons-csv issue - which was *not* a Maven issue -
has actually helped us clean up a lot of mess in our sources, build system,
dependency structure etc. It's been too easy to include questionable libs or
non-released libs, and that's the real problem if you ask me. So publishing to
mvn-repo actually keeps us accountable in legally being good Apache citizens as
well as shipping higher quality, more stable stuff. It's a Good Thing™ that
Noggit got its release. It will be a good thing if/when commons-csv ships a
release that we can depend on without patching.

Regarding hiding stuff in our binary .jars or .war - that won't solve
anything. Some people actually run more than Solr in their app-server, add
their own plugins etc. So the risk of package name clash or slf4j binding
incompatibilities actually increases, the more things we throw into the .war. I
just had a project with a webapp using SolrJ needed slf4j 1.5.8, which crashed
with SolrJ's jcl-over-slf4j (1.6.1) dependency. The solution was simply to
exclude the 1.6.1 dep and things worked fine. If SolrJ was just one huge .jar
with all deps melted together that would not be an option.

I'm also +1 for including all required deps in the binary release of Solr.

maven artifacts should be equivalent to binary packaging

Key: SOLR-3405
URL: https://issues.apache.org/jira/browse/SOLR-3405
Project: Solr
Issue Type: Task
Components: Build
Reporter: Robert Muir
Fix For: 4.1

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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging


[ 
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13263202#comment-13263202
 ] 

Robert Muir commented on SOLR-3405:
---

{quote}
It seems actually that the commons-csv issue - which was not a Maven issue 
{quote}

Really? then explain this.

Thanks.

{noformat}
$ unzip -l apache-solr-3.5.0.zip | grep commons-csv
$ 
{noformat}

But,

http://search.maven.org/#artifactdetails|org.apache.solr|solr-commons-csv|3.5.0|jar

 maven artifacts should be equivalent to binary packaging
 

 Key: SOLR-3405
 URL: https://issues.apache.org/jira/browse/SOLR-3405
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
 Fix For: 4.1


 Lets take the commons-csv scenario: 
 * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
 anywhere,
   in fact it contains no third party jars (the stuff present in solr/lib) at 
 all.
 * binary distribution contains only the jars necessary for *solrj* and 
 *contrib plugins*, and a solr.war
 I think the maven artifacts should match whats in the binary release (no 
 third party jars 
 inside the .war are exposed, we just publish the .war itself). This exposes 
 a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging

2012-04-26 Thread Dawid Weiss (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13263205#comment-13263205
 ] 

Dawid Weiss commented on SOLR-3405:
---

I still think this is a misunderstanding of what a maven release is by the 
board. I mean the POM states clearly:
{noformat}
  groupIdorg.apache.solr/groupId
  artifactIdsolr-commons-csv/artifactId
  nameSolr Specific Commons CSV/name
  version3.5.0/version
  descriptionSolr Specific Commons CSV v1.0-SNAPSHOT-r966014/description
{noformat}
So it's not commons-csv. It's solr-*SPECIFIC*-commons-csv. Maven folks don't 
just download jars from maven central, they use pom dependencies. If you depend 
on the above, it's hard to call it an official commons-csv release...


 maven artifacts should be equivalent to binary packaging
 

 Key: SOLR-3405
 URL: https://issues.apache.org/jira/browse/SOLR-3405
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
 Fix For: 4.1


 Lets take the commons-csv scenario: 
 * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
 anywhere,
   in fact it contains no third party jars (the stuff present in solr/lib) at 
 all.
 * binary distribution contains only the jars necessary for *solrj* and 
 *contrib plugins*, and a solr.war
 I think the maven artifacts should match whats in the binary release (no 
 third party jars 
 inside the .war are exposed, we just publish the .war itself). This exposes 
 a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging

[
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13263207#comment-13263207
]

Robert Muir commented on SOLR-3405:
---

{quote}
It's been too easy to include questionable libs or non-released libs, and
that's the real problem if you ask me.
So publishing to mvn-repo actually keeps us accountable in legally being good
Apache citizens as well as shipping higher quality, more stable stuff.
{quote}

Thats bullshit. Being in maven repositories doesn't make anything more legal.

Requiring that all dependencies be in maven harms software projects:
* it prevents good features from being added, for example the most popular Tika
issue (outlook support) is just hung on this stupid stuff (TIKA-623)
* it encourages buggy software. Perhaps its conventional that software
projects just pass the blame down along, but if we have bugs that break our
release we should make our release work instead of passing blame.

{quote}
It's a Good Thing™ that Noggit got its release.
{quote}

I agree. I upload my patch to start using it nearly a month ago. Its too bad no
maven supporters
have done anything to make it accessible via maven.

The fact its a real release is good, and the patch is good. Its time to commit
it.

maven artifacts should be equivalent to binary packaging

Key: SOLR-3405
URL: https://issues.apache.org/jira/browse/SOLR-3405
Project: Solr
Issue Type: Task
Components: Build
Reporter: Robert Muir
Fix For: 4.1

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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging

2012-04-26 Thread Michael McCandless (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13263208#comment-13263208
]

Michael McCandless commented on SOLR-3405:
--

bq. I just resolved SOLR-3411 as Not a Problem.

OK thanks Steve. I'm glad it's not a real problem.

bq. From the Apache board perspective, I suspect that this would be viewed as a
distinction without a difference;

True, but I think that's OK. It's a compromise.

bq. The PMC is supposed to only be voting on source releases anyway, right?

Legally, yes, but in practice, we are also testing and pushing out the
convenience binaries (and, Maven's artifacts) at the same time. They
are all read-only once published.

maven artifacts should be equivalent to binary packaging

Key: SOLR-3405
URL: https://issues.apache.org/jira/browse/SOLR-3405
Project: Solr
Issue Type: Task
Components: Build
Reporter: Robert Muir
Fix For: 4.1

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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging

2012-04-26 Thread JIRA

[
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13263220#comment-13263220
]

Jan Høydahl commented on SOLR-3405:
---

{quote}
bq. It's been too easy to include questionable libs or non-released libs, and
that's the real problem if you ask me. So publishing to mvn-repo actually keeps
us accountable in legally being good Apache citizens as well as shipping higher
quality, more stable stuff.

Thats bullshit. Being in maven repositories doesn't make anything more legal.
{quote}

I'm not saying that. I'm saying that *a positive side effect* of publishing
*all* our release artifacts to a broader public is that it helps detect bad and
hacky practices in our own code. If we feel we need to hide the truth about our
dependencies or build artifacts then it is better to put a bright light on why
than shuffling things underneath a carpet.

Once in a while we judge that it may still be more gain than pain to include
some unreleased lib or a patched version of a lib in our distro (after having
first tried to get it fixed upstream) and that's fine with me; if repackaging
properly under new namespace and include this as a (temporary) custom
dependency, both in our binary distro and therefore also in maven-repos. But we
should try to replace these custom deps by official release versions when
possible.

maven artifacts should be equivalent to binary packaging

Key: SOLR-3405
URL: https://issues.apache.org/jira/browse/SOLR-3405
Project: Solr
Issue Type: Task
Components: Build
Reporter: Robert Muir
Fix For: 4.1

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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging


[ 
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13263225#comment-13263225
 ] 

Robert Muir commented on SOLR-3405:
---

But you need to realize a lot of software has official releases, they just dont 
care about maven.

A great example of that is the noggit release. Again i've had a patch up for a 
month, and I think
it makes our release more clean to depend on this real release, than to have 
code copied from apache labs.

But i've waited so long in the hopes someone will step up and put the thing in 
maven, i've detailed
out the reasons on SOLR-3296. 

In this case, maven is making things *less* legal. I hope everyone sees that!


 maven artifacts should be equivalent to binary packaging
 

 Key: SOLR-3405
 URL: https://issues.apache.org/jira/browse/SOLR-3405
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
 Fix For: 4.1


 Lets take the commons-csv scenario: 
 * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
 anywhere,
   in fact it contains no third party jars (the stuff present in solr/lib) at 
 all.
 * binary distribution contains only the jars necessary for *solrj* and 
 *contrib plugins*, and a solr.war
 I think the maven artifacts should match whats in the binary release (no 
 third party jars 
 inside the .war are exposed, we just publish the .war itself). This exposes 
 a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging

2012-04-26 Thread JIRA

[
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13263318#comment-13263318
]

Jan Høydahl commented on SOLR-3405:
---

bq. But you need to realize a lot of software has official releases, they just
dont care about maven.
bq. A great example of that is the noggit release. Again i've had a patch up
for a month, and I think it makes our release more clean to depend on this real
release, than to have code copied from apache labs.

I don't think Noggit is a good example. It is written by Yonik and prohibited
from releasing anything since it's part of Apache Labs, so probably noone knows
about it. If it rather had started its life as part of Lucene's source code and
later been spawned out as its own project, it would have gotten more love and
care, would have had Javadocs, some documentation etc. So having Noggit
distributed to Maven is as close as asking your colleague to publish it.

I would rather state that most Java libraries *do* care about Maven.

maven artifacts should be equivalent to binary packaging

Key: SOLR-3405
URL: https://issues.apache.org/jira/browse/SOLR-3405
Project: Solr
Issue Type: Task
Components: Build
Reporter: Robert Muir
Fix For: 4.1

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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging

2012-04-26 Thread Ryan McKinley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13263343#comment-13263343
 ] 

Ryan McKinley commented on SOLR-3405:
-

We are a bit lost on what we are talking about -- I don't expect we will all 
agree on the best maven strategy.

Something mentioned over an over in this thread is concern that sonatype maven 
central is somehow *the* repository.  That is nonsense, there is no reason to 
do crazy plugins to try to pretend stuff is there when we can just add (or 
suggest adding) other potential repositories.  If we are worried about 
supporting the 1-off crazy patched jar, we can point it to something as crazy 
as:
{code:xml}
pluginRepositories
   pluginRepository
 idmaven-timestamp/id
 
urlhttp://maven-timestamp-plugin.googlecode.com/svn/trunk/repository/url
   /pluginRepository
/pluginRepositories
{code}

but I feel like i am just adding more noise to an issue without focus

 maven artifacts should be equivalent to binary packaging
 

 Key: SOLR-3405
 URL: https://issues.apache.org/jira/browse/SOLR-3405
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
 Fix For: 4.1


 Lets take the commons-csv scenario: 
 * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
 anywhere,
   in fact it contains no third party jars (the stuff present in solr/lib) at 
 all.
 * binary distribution contains only the jars necessary for *solrj* and 
 *contrib plugins*, and a solr.war
 I think the maven artifacts should match whats in the binary release (no 
 third party jars 
 inside the .war are exposed, we just publish the .war itself). This exposes 
 a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging

2012-04-25 Thread Dawid Weiss (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261352#comment-13261352
 ] 

Dawid Weiss commented on SOLR-3405:
---

bq. Re: maven-antivirus-plugin - looks like it's already been built: 
http://evgeny-goldin.com/wiki/Ivy-maven-plugin

Interesting find, Steve. It won't allow you to declare regular dependencies 
though, will it? I mean -- I tried to write a plugin that would fetch a JAR and 
declare a system dependency on it locally but even validation phase is 
performed after dependency resolution so this failed. Didn't try the above 
plugin but from the description I see it attaches jars directly to reactor's 
classpath, bypassing regular dependency resolution?

 maven artifacts should be equivalent to binary packaging
 

 Key: SOLR-3405
 URL: https://issues.apache.org/jira/browse/SOLR-3405
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
 Fix For: 4.0


 Lets take the commons-csv scenario: 
 * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
 anywhere,
   in fact it contains no third party jars (the stuff present in solr/lib) at 
 all.
 * binary distribution contains only the jars necessary for *solrj* and 
 *contrib plugins*, and a solr.war
 I think the maven artifacts should match whats in the binary release (no 
 third party jars 
 inside the .war are exposed, we just publish the .war itself). This exposes 
 a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging


[ 
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261647#comment-13261647
 ] 

Steven Rowe commented on SOLR-3405:
---

bq. Didn't try the above plugin but from the description I see it attaches jars 
directly to reactor's classpath, bypassing regular dependency resolution?

I haven't tried it yet either, but yes, I too think it's bypassing regular 
dependency resolution.  However, it's hooking into Ivy's capabilities, which 
makes me think this could be a long term solution for Lucene/Solr.

 maven artifacts should be equivalent to binary packaging
 

 Key: SOLR-3405
 URL: https://issues.apache.org/jira/browse/SOLR-3405
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
 Fix For: 4.0


 Lets take the commons-csv scenario: 
 * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
 anywhere,
   in fact it contains no third party jars (the stuff present in solr/lib) at 
 all.
 * binary distribution contains only the jars necessary for *solrj* and 
 *contrib plugins*, and a solr.war
 I think the maven artifacts should match whats in the binary release (no 
 third party jars 
 inside the .war are exposed, we just publish the .war itself). This exposes 
 a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging


[ 
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261650#comment-13261650
 ] 

Steven Rowe commented on SOLR-3405:
---

From the description
bq. binary distribution contains only the jars necessary for solrj and contrib 
plugins, and a solr.war

This is plainly false: all Solr jars, including solr-core and 
solr-test-framework, are included in the 3.6 binary distribution *outside of 
the war*.

 maven artifacts should be equivalent to binary packaging
 

 Key: SOLR-3405
 URL: https://issues.apache.org/jira/browse/SOLR-3405
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
 Fix For: 4.0


 Lets take the commons-csv scenario: 
 * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
 anywhere,
   in fact it contains no third party jars (the stuff present in solr/lib) at 
 all.
 * binary distribution contains only the jars necessary for *solrj* and 
 *contrib plugins*, and a solr.war
 I think the maven artifacts should match whats in the binary release (no 
 third party jars 
 inside the .war are exposed, we just publish the .war itself). This exposes 
 a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging


[ 
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261651#comment-13261651
 ] 

Robert Muir commented on SOLR-3405:
---

Its really not, I am talking about third-party jars.

Like i said: binary distribution doesnt expose these third party jars, nor even 
list what they are.
maven distribution requires these to be published.

Just look at the zip! There is no guava.jar or any of those other solr/lib
dependencies included in the zip, however maven exposes these dependencies that 
are impl details of the war.

The only third party dependencies included are:
* solrj_lib (the very few the client library needs to work)
* solr contrib plugins (since they are plugins and need these to work)


 maven artifacts should be equivalent to binary packaging
 

 Key: SOLR-3405
 URL: https://issues.apache.org/jira/browse/SOLR-3405
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
 Fix For: 4.0


 Lets take the commons-csv scenario: 
 * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
 anywhere,
   in fact it contains no third party jars (the stuff present in solr/lib) at 
 all.
 * binary distribution contains only the jars necessary for *solrj* and 
 *contrib plugins*, and a solr.war
 I think the maven artifacts should match whats in the binary release (no 
 third party jars 
 inside the .war are exposed, we just publish the .war itself). This exposes 
 a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging

[
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261652#comment-13261652
]

Steven Rowe commented on SOLR-3405:
---

bq. Its really not, I am talking about third-party jars.

It really is. You are also talking about the difference between an app an and
api. If the api jars are included, then the binary dist is not exclusively an
app.

maven artifacts should be equivalent to binary packaging

Key: SOLR-3405
URL: https://issues.apache.org/jira/browse/SOLR-3405
Project: Solr
Issue Type: Task
Components: Build
Reporter: Robert Muir
Fix For: 4.0

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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging


[ 
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261657#comment-13261657
 ] 

Robert Muir commented on SOLR-3405:
---

But these inner dependencies are not exposed as APIs.

Now you can see why the commons-csv thing was surprising to us. Because we 
package it inside the war only,
as an implementation detail.

If someone wants to use solr-core.jar and needs commons-csv, its up to them to 
get it: we werent PUBLISHING IT!

On the other hand: maven distribution was!


 maven artifacts should be equivalent to binary packaging
 

 Key: SOLR-3405
 URL: https://issues.apache.org/jira/browse/SOLR-3405
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
 Fix For: 4.0


 Lets take the commons-csv scenario: 
 * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
 anywhere,
   in fact it contains no third party jars (the stuff present in solr/lib) at 
 all.
 * binary distribution contains only the jars necessary for *solrj* and 
 *contrib plugins*, and a solr.war
 I think the maven artifacts should match whats in the binary release (no 
 third party jars 
 inside the .war are exposed, we just publish the .war itself). This exposes 
 a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging


[ 
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261661#comment-13261661
 ] 

Steven Rowe commented on SOLR-3405:
---

Robert,

Call me crazy, but I've read your comments on this issue as claiming that we 
should not publish solr-core (etc.) on Maven Central, because we don't do that 
in the binary dist.  Well, we *do* do that in the binary dist.

So, this time without avoiding the question: why should we not publish 
solr-core on Maven Central?



 maven artifacts should be equivalent to binary packaging
 

 Key: SOLR-3405
 URL: https://issues.apache.org/jira/browse/SOLR-3405
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
 Fix For: 4.0


 Lets take the commons-csv scenario: 
 * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
 anywhere,
   in fact it contains no third party jars (the stuff present in solr/lib) at 
 all.
 * binary distribution contains only the jars necessary for *solrj* and 
 *contrib plugins*, and a solr.war
 I think the maven artifacts should match whats in the binary release (no 
 third party jars 
 inside the .war are exposed, we just publish the .war itself). This exposes 
 a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging

[
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261665#comment-13261665
]

Robert Muir commented on SOLR-3405:
---

{quote}
So, this time without avoiding the question: why should we not publish
solr-core on Maven Central?
{quote}

Because maven requires that its dependencies are also in maven, whereas the
binary distribution does not:
it exposes its innards.

Let's talk about how we can make some concrete process on this issue, throwing
aside *COMPLETELY* the whole
.war-third-party-exposure, and the fact that we are releasing as an
application one way and as an api another way.
Lets just table that for a second, since we will probably end up disagreeing on
it anyway :)

I think the maven artifacts should not be built from the source tree, they
should instead be built from
the binary release (e.g. unzipping the .zip + augmenting with poms). If we
build them this way, this has
a number of advantages:
# exact same jar files etc are put into the maven/ folder that are in the
binary release. they are just
augmented with poms.
# we can now easily validate, that maven/ folders don't contain anything
(besides pom.xmls etc), that
aren't found by unzip -l binary release. we can also test that these jar
files are exactly the same.

I think this would be a good, non-controversial step to improving the
situation. Such a check would have
detected the commons-csv situation, no? It also gives us some more faith in the
maven artifacts, since
they are the exact same jar files we are testing in the binary package.

We could do this with lucene, too.

maven artifacts should be equivalent to binary packaging

Key: SOLR-3405
URL: https://issues.apache.org/jira/browse/SOLR-3405
Project: Solr
Issue Type: Task
Components: Build
Reporter: Robert Muir
Fix For: 4.0

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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging


[ 
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261669#comment-13261669
 ] 

Robert Muir commented on SOLR-3405:
---

And in the idea above, obviously -sources.jar and -javadocs.jar are exempt, 
as they
are maven-specific and not in the binary packaging. Thats fine: I'm talking 
about
the actual binary jars. Our checking script would exclude those.

I think currently these are the same in the sense that
they are built from the same code, but currently have timestamp differences as 
they
are pulled from build/. 

On the non-maven side there are improvements like this as well: for example I 
think
the lucene jars used by solr are rebuilt in the process. But i think it would 
be
more ideal if solr 'prepare-release', when populating the jar, populated these 
lucene
jars from lucene's binary release in dist/ the same way: so they are the exact 
same
jars that were released in the lucene binary distribution.

I dont think this stuff has to be done immediately, and i know its complicated 
and being
really pedantic, but I think it would be a good step.


 maven artifacts should be equivalent to binary packaging
 

 Key: SOLR-3405
 URL: https://issues.apache.org/jira/browse/SOLR-3405
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
 Fix For: 4.0


 Lets take the commons-csv scenario: 
 * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
 anywhere,
   in fact it contains no third party jars (the stuff present in solr/lib) at 
 all.
 * binary distribution contains only the jars necessary for *solrj* and 
 *contrib plugins*, and a solr.war
 I think the maven artifacts should match whats in the binary release (no 
 third party jars 
 inside the .war are exposed, we just publish the .war itself). This exposes 
 a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging


[ 
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261670#comment-13261670
 ] 

Steven Rowe commented on SOLR-3405:
---

{quote}
bq. So, this time without avoiding the question: why should we not publish 
solr-core on Maven Central?

Because maven requires that its dependencies are also in maven, whereas the 
binary distribution does not: it exposes its innards.
{quote}

This is an argument against Maven generally, not exclusively the Solr 
artifacts; I view it as a thinly veiled re-assertion that Lucene/Solr should 
not support Maven at all.  Again: -1.

The fix here is not to stop publishing on Maven Central, but rather as you say 
on the issue: make the Maven Central artifacts like the binary artifacts.  
Using your logic, excluding solr-core from the Maven Central artifacts would 
make the two not the same, and hence would be WRONG!!!



 maven artifacts should be equivalent to binary packaging
 

 Key: SOLR-3405
 URL: https://issues.apache.org/jira/browse/SOLR-3405
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
 Fix For: 4.0


 Lets take the commons-csv scenario: 
 * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
 anywhere,
   in fact it contains no third party jars (the stuff present in solr/lib) at 
 all.
 * binary distribution contains only the jars necessary for *solrj* and 
 *contrib plugins*, and a solr.war
 I think the maven artifacts should match whats in the binary release (no 
 third party jars 
 inside the .war are exposed, we just publish the .war itself). This exposes 
 a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging

[
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261673#comment-13261673
]

Steven Rowe commented on SOLR-3405:
---

bq. I think the maven artifacts should not be built from the source tree, they
should instead be built from the binary release (e.g. unzipping the .zip +
augmenting with poms).

+1, I've looked at doing this in the past but didn't see a quick way to do it.

{quote}
And in the idea above, obviously -sources.jar and -javadocs.jar are exempt,
as they
are maven-specific and not in the binary packaging. Thats fine: I'm talking
about
the actual binary jars. Our checking script would exclude those.

I think currently these are the same in the sense that
they are built from the same code, but currently have timestamp differences as
they
are pulled from build/.

On the non-maven side there are improvements like this as well: for example I
think
the lucene jars used by solr are rebuilt in the process. But i think it would
be
more ideal if solr 'prepare-release', when populating the jar, populated these
lucene
jars from lucene's binary release in dist/ the same way: so they are the exact
same
jars that were released in the lucene binary distribution.

I dont think this stuff has to be done immediately, and i know its complicated
and being
really pedantic, but I think it would be a good step.
{quote}

+1 to all of these ideas.

maven artifacts should be equivalent to binary packaging

Key: SOLR-3405
URL: https://issues.apache.org/jira/browse/SOLR-3405
Project: Solr
Issue Type: Task
Components: Build
Reporter: Robert Muir
Fix For: 4.0

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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging

[
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261678#comment-13261678
]

Robert Muir commented on SOLR-3405:
---

{quote}
This is an argument against Maven generally, not exclusively the Solr
artifacts; I view it as a thinly veiled re-assertion that Lucene/Solr should
not support Maven at all. Again: -1.
{quote}

Its really not that: and though i've asserted this before (especially when
maven had no tests, but now it does), when
did I do this on the recent thread? I have stated that I think we shouldn't
release maven if its different than our
other packaging because I think that causes it to be more of a mystery. I
opened this issue to *improve* the situation,
not to have an issue to argue about maven. you can s/maven/rpm/ and i feel the
same way about all of this: these are
just different packaging formats but I think the underlying products we release
should be *the same*.

I'm upset about the maven packaging on this issue because in my opinion, it
packages solr up like an API which is
different than our binary release: which packages it up to be used as an
application. Frankly you really can't
do much else with the solr binary packaging except use it as an application:
those solr-core.jar's etc do you
absolutely no good unless you hunt down all the jars (or yank em out of
solr.war/WEB_INF, maybe some IDEs do that),
yourself.

{quote}
+1, I've looked at doing this in the past but didn't see a quick way to do it.
{quote}

I also don't think we should do it for 4.0, its too risky. But we should look
at it for the future. A few things to think about:

* its annoying when releasing lucene/solr that you cant do it all with one
command line. So I think we would add a top-level prepare-release to
trunk/build.xml that would simply invoke solr/ prepare-release. And solr's
prepare-release would depend on lucene's. That would be nice as we have one
single command for this.
* since solr prepare-release now knows that lucene's is also built, I think it
would be easier for it to use the jars from the lucene release. easier, not
easy.

thats just the non-maven parts, the maven stuff is more blurry to me.

maven artifacts should be equivalent to binary packaging

Key: SOLR-3405
URL: https://issues.apache.org/jira/browse/SOLR-3405
Project: Solr
Issue Type: Task
Components: Build
Reporter: Robert Muir
Fix For: 4.0

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

[jira] [Updated] (SOLR-3405) maven artifacts should be equivalent to binary packaging


 [ 
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Muir updated SOLR-3405:
--

Fix Version/s: (was: 4.0)
   4.1

 maven artifacts should be equivalent to binary packaging
 

 Key: SOLR-3405
 URL: https://issues.apache.org/jira/browse/SOLR-3405
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
 Fix For: 4.1


 Lets take the commons-csv scenario: 
 * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar 
 anywhere,
   in fact it contains no third party jars (the stuff present in solr/lib) at 
 all.
 * binary distribution contains only the jars necessary for *solrj* and 
 *contrib plugins*, and a solr.war
 I think the maven artifacts should match whats in the binary release (no 
 third party jars 
 inside the .war are exposed, we just publish the .war itself). This exposes 
 a lot less surface area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging