[
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
