[
https://issues.apache.org/jira/browse/AVRO-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202604#comment-13202604
]
Lars Francke commented on AVRO-1011:
------------------------------------
bq. I tend to place all of my dependency literals in one place in the parent
project for two reasons
I do that too for all dependencies that are shared but I personally find it
easier to have them as close to their actual usage as possible so if they are
only used in one submodule then I keep them there. That is very much a matter
of taste and past experience I think and you're definitely the Avro Maven
master so I don't object to any change that relates to this. I'm just used to
do it differently I guess.
{quote}You are right, the doc is wrong. We could move this to
dependencyManagement and have all children declare, but I do not foresee any
child that does not have these two dependencies. There may be a case (such as
tools) that doesn't directly use slf4j, but depends on other components that do
so there is an implicit dependency anyway.{quote}
* SLF4J API is not used by: avro-maven-plugin, avro-tools, avro-protobuf
* SLF4J-Simple shouldn't be used for anything that might be used as a library
anywhere else like avro-mapred. We're forcing an SLF4J implementation on users
(I know it's declared optional here) for no reason, the actual logging
implementation should always be up to the end-user so avro-tools and
avro-maven-plugin should probably be the only ones that have one? I'm not sure
how all projects are used actually so I might be wrong. And if it stays in it
is definitely the wrong scope, should be runtime instead of compile.
bq. Why re-declare dependencies in downstream modules?
That's the result of a mvn dependency:analyze and a Tattletale run.
Example from avro-protobuf:
{code}
[WARNING] Used undeclared dependencies found:
[WARNING] org.codehaus.jackson:jackson-mapper-asl:jar:1.8.6:compile
[WARNING] org.codehaus.jackson:jackson-core-asl:jar:1.8.6:compile
{code}
All those project are using classes from those specific JARs directly.
avro-protobuf for example has this:
{code}
import org.codehaus.jackson.JsonFactory;
import org.codehaus.jackson.JsonNode;
{code}
and they come from {{jackson-core}}. Thus we need to declare a dependency on
it. If {{jackson-mapper}} for any reason removed its dependency on
{{jackson-core}} later then the Avro build would fail even though we just
upgraded. To put it differently: That {{jackson-mapper}} depends on
{{jackson-core}} is an implementation detail of Jackson and can not be relied
upon.
That'd at least be my reasoning :) I've been bitten by this more than once and
I also find it nicer for documentation reasons for third party users.
About your concrete example: {{avro}} itself is using all kinds of Jackson
classes itself so even though it gets the dependency through {{avro-mapred}} it
still depends on them itself.
> Improve POM structure
> ---------------------
>
> Key: AVRO-1011
> URL: https://issues.apache.org/jira/browse/AVRO-1011
> Project: Avro
> Issue Type: Improvement
> Components: java
> Affects Versions: 1.6.1
> Reporter: Lars Francke
> Assignee: Lars Francke
> Priority: Minor
> Attachments: AVRO-1011.1.patch, AVRO-1011.2.patch
>
>
> I've gone through all the POM files and reworked them a bit:
> * Remove all tabs with spaces, remove whitespace from line ends
> * Reformat XML
> * All POM files are using a consistent order of elements
> * Remove extra autogenerated pom.xml in
> lang/java/archetypes/avro-service-archetype/src/main/resources/archetype-resources/
> * Include missing Jackson (and others) dependencies in the modules
> * Changed property names from foo-version to foo.version to be more consistent
> * Removed jopt-simple dependency from mapred package by removing unused
> imports from a test
> * Removed duplicate maven-enforcer-plugin definition
> * Remove unused repositories (apache.snapshots not needed and coming from
> parent, jboss stuff is in maven central)
--
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
