avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Carey (Issue Comment Edited) (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (AVRO-1011) Improve POM structure
Date Tue, 07 Feb 2012 18:15:01 GMT

    [ https://issues.apache.org/jira/browse/AVRO-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202582#comment-13202582
] 

Scott Carey edited comment on AVRO-1011 at 2/7/12 6:13 PM:
-----------------------------------------------------------

I tend to place all of my dependency literals in one place in the parent project for two reasons:
* It is easier to locate the versions when they need to change and review in bulk.
* If only one child uses a dependency, it is often temporary.  Sibling projects have a habit
of spawning or adding dependencies from other siblings leading to mismatches over time (e.g.
how we got different versions in the archetype modules)

The unused imports should be changed, I thought it was an unrelated change and therefore for
a different ticket.  I see it is in the description, I missed that.

{quote}
There's one thing I didn't change in this patch because I didn't have the time to think it
through fully. The dependencies (SLF4J + JUnit) declared in lang/java/pom.xml have a comment
saying that children can just exclude them. 
{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.


This brings up another discussion:

Why re-declare dependencies in downstream modules?  For example, you added explicit dependencies
on jackson-core-asl and jackson-mapper-asl to several projects in what is IMO an unnecessary
duplication of the implicit dependency from the avro module.  In addition, jackson-mapper-asl
depends on jackson-core-asl, so it is redundant to list jackson-core-asl.  I have always seen
this as a violation of the DRY principle (it is listed in 'avro', 'avro-mapred' depends on
'avro', therefore already depends on it), but it does seem to be common maven practice to
list all jars that are referenced directly and not depend on implicit dependencies.  I figure
the compile and test process ensures correctness.

What are the arguments for this approach?  I can go either way, the duplication factor is
not that high in Avro and is mostly related to Jackson and how we expose it in the Avro Schema
API rather than hide it.



                
      was (Author: scott_carey):
    I tend to place all of my dependency literals in one place in the parent project for two
reasons:
* It is easier to locate the versions when they need to change and review in bulk.
* If only one child uses a dependency, it is often temporary.  Sibling projects have a habit
of spawning or adding dependencies from other siblings leading to mismatches over time (e.g.
how we got different versions in the archetype branch)

The unused imports should be changed, I thought it was an unrelated change and therefore for
a different ticket.  I see it is in the description, I missed that.

{quote}
There's one thing I didn't change in this patch because I didn't have the time to think it
through fully. The dependencies (SLF4J + JUnit) declared in lang/java/pom.xml have a comment
saying that children can just exclude them. 
{quote}

You are right, the doc is wrong.  We could move this to dependencyManagement and have all
children declare, but I do not forsee 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 implicity dependency anyway.


This brings up another discussion:

Why re-declare dependencies in downstream modules?  For example, you added explicit dependencies
on jackson-core-asl and jackson-mapper-asl to several projects in what is IMO an unnecessary
duplication of the implicit dependency from the avro module.  In addition, jackson-mapper-asl
depends on jackson-core-asl, so it is redundant to list jackson-core-asl.  I have always seen
this as a violation of the DRY principle (it is listed in 'avro', 'avro-mapred' depends on
'avro', therefore already depends on it), but it does seem to be common maven practice to
list all jars that are referenced directly and not depend on implicit dependencies.  I figure
the compile and test process ensures correctness.

What are the arguments for this approach?  I can go either way, the duplication factor is
not that high in Avro and is mostly related to Jackson and how we expose it in the Avro Schema
API rather than hide it.



                  
> 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