Mailing-List: contact dev-help@avro.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@avro.apache.org
Date: Tue, 7 Feb 2012 18:15:01 +0000 (UTC)
From: "Scott Carey (Issue Comment Edited) (JIRA)" <jira@apache.org>
To: dev@avro.apache.org
Message-ID: 
 <352664220.9387.1328638501772.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1197646834.871.1327684210493.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Issue Comment Edited] (AVRO-1011) Improve POM structure
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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