Mailing List Archive: Lucene: Java-Dev

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

1 2 3 4

View All

Index | Next | Previous | View Threaded

jira at apache

Apr 26, 2012, 3:14 PM

Post #76 of 88 (87 views)
Permalink

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

[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
>
>
> 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-unsubscribe [at] lucene
For additional commands, e-mail: dev-help [at] lucene

jira at apache

Apr 26, 2012, 3:24 PM

Post #77 of 88 (90 views)
Permalink

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

[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-unsubscribe [at] lucene
For additional commands, e-mail: dev-help [at] lucene

jira at apache

Apr 26, 2012, 3:30 PM

Post #78 of 88 (87 views)
Permalink

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

[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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}
<groupId>org.apache.solr</groupId>
<artifactId>solr-commons-csv</artifactId>
<name>Solr Specific Commons CSV</name>
<version>3.5.0</version>
<description>Solr 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-unsubscribe [at] lucene
For additional commands, e-mail: dev-help [at] lucene

jira at apache

Apr 26, 2012, 3:36 PM

Post #79 of 88 (88 views)
Permalink

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

[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
>
>
> 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-unsubscribe [at] lucene
For additional commands, e-mail: dev-help [at] lucene

jira at apache

Apr 26, 2012, 3:36 PM

Post #80 of 88 (87 views)
Permalink

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

[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
>
>
> 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-unsubscribe [at] lucene
For additional commands, e-mail: dev-help [at] lucene

jira at apache

Apr 26, 2012, 3:56 PM

Post #81 of 88 (90 views)
Permalink

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

[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
>
>
> 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-unsubscribe [at] lucene
For additional commands, e-mail: dev-help [at] lucene

jira at apache

Apr 26, 2012, 4:00 PM

Post #82 of 88 (86 views)
Permalink

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

[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-unsubscribe [at] lucene
For additional commands, e-mail: dev-help [at] lucene

jira at apache

Apr 26, 2012, 8:05 PM

Post #83 of 88 (91 views)
Permalink

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

[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
>
>
> 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-unsubscribe [at] lucene
For additional commands, e-mail: dev-help [at] lucene

jira at apache

Apr 26, 2012, 10:00 PM

Post #84 of 88 (89 views)
Permalink

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

[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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>
<id>maven-timestamp</id>
<url>http://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-unsubscribe [at] lucene
For additional commands, e-mail: dev-help [at] lucene

jira at apache

Apr 26, 2012, 11:34 PM

Post #85 of 88 (87 views)
Permalink

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

[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-unsubscribe [at] lucene
For additional commands, e-mail: dev-help [at] lucene

jira at apache

Apr 27, 2012, 10:56 AM

Post #86 of 88 (87 views)
Permalink

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

[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-unsubscribe [at] lucene
For additional commands, e-mail: dev-help [at] lucene

jira at apache

Apr 27, 2012, 12:04 PM

Post #87 of 88 (90 views)
Permalink

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

[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-unsubscribe [at] lucene
For additional commands, e-mail: dev-help [at] lucene

jira at apache

Apr 27, 2012, 3:04 PM

Post #88 of 88 (88 views)
Permalink

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

[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-unsubscribe [at] lucene
For additional commands, e-mail: dev-help [at] lucene

1 2 3 4

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads