avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Francke (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AVRO-1011) Improve POM structure
Date Tue, 07 Feb 2012 18:36:59 GMT

    [ 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

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:
[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

All those project are using classes from those specific JARs directly. avro-protobuf for example
has this:
import org.codehaus.jackson.JsonFactory;
import org.codehaus.jackson.JsonNode;
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


View raw message