[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fop-dev
Subject:    [jira] [Reopened] (FOP-3088) Jar packaging duplicates classes on classpath
From:       "Simon Steiner (Jira)" <jira () apache ! org>
Date:       2022-08-17 12:16:00
Message-ID: JIRA.13477025.1660643172000.169040.1660738560036 () Atlassian ! JIRA
[Download RAW message or body]


     [ https://issues.apache.org/jira/browse/FOP-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel \
]

Simon Steiner reopened FOP-3088:
--------------------------------

> Jar packaging duplicates classes on classpath
> ---------------------------------------------
> 
> Key: FOP-3088
> URL: https://issues.apache.org/jira/browse/FOP-3088
> Project: FOP
> Issue Type: Bug
> Reporter: Skip de Groot
> Assignee: Simon Steiner
> Priority: Major
> Fix For: trunk
> 
> 
> I have a gradle project where we import apache fop with the following:
> {code:java}
> implementation("org.apache.xmlgraphics:fop:2.6") {code}
> Which results in the following dependencies being loaded on the classpath (I have \
> removed the sub dependencies for simplicity) {code:java}
> org.apache.xmlgraphics:fop -> 2.6
> +--- org.apache.xmlgraphics:fop-util:2.6
> +--- org.apache.xmlgraphics:fop-events:2.6
> \--- org.apache.xmlgraphics:fop-core:2.6 {code}
> So far so good and everything works most of the time. I suspect any maven project \
> would import in the same way. However, most classes are duplicated in fop-2.6.jar \
> and their respective sub module. For instance, the org.apache.fop.apps.FOUserAgent \
> class is packaged both in fop and fop-core.  All classes from the fop-events module \
> in org.apache.fop.events package are also duplicated, but not from the \
> org.apache.fop.tools package from the fop-events module (For instance \
> org.apache.fop.tools.EventProducerCollector), making this also inconsistent \
> somehow. Luckily both implementations seem the same but it is bad practice to have \
> duplicate classes on the classpath, and package sizes are also doubled. 
> Depending on the implementation choice I would either expect a fatty jar with all \
> the classes packaged which does not import anything or an somewhat empty root fop \
> jar with all classes imported by the sub modules. As it stands now it seems to be a \
> combination of both and not a completely consistant one either. Which one is the \
> prefered solution of this project?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[prev in list] [next in list] [prev in thread] [next in thread]