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

       

Mime
View raw message