JPPF Issue Tracker
star_faded.png
Please log in to bookmark issues
feature_request_small.png
CLOSED  Feature request JPPF-261  -  Refactor the jar packaging in the JPPF distribution
Posted May 11, 2014 - updated Aug 07, 2014
action_vote_minus_faded.png
0
Votes
action_vote_plus_faded.png
icon_info.png This issue has been closed with status "Closed" and resolution "RESOLVED".
Issue details
  • Type of issue
    Feature request
  • Status
     
    Closed
  • Assigned to
     lolo4j
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
     lolo4j
  • Owned by
    Not owned by anyone
  • Category
    Core
  • Resolution
    RESOLVED
  • Priority
    Normal
  • Targetted for
    icon_milestones.png JPPF 5.0
Issue description
Currently, the way we package the JPPF jars and the dependencies for the JPPF components is a mess. For instance:
  • jppf-common-node is a dependency for all components, even those that do not need the node code. It also contains all the utility classes that could/should be in a separate module and/or jar file.
  • jppf-common contains client-side package names
  • jppf-server contains node-side code along with the server-side code
  • some package names can be found in multiple modules, that's messy
  • a large part of jppf-admin contains code that should be reorganized as a separate library, with more meaningful names (i.e. the "Options" APIs to generate Swing components from XML documents)
What we propose is to reorganize the packaging, and possibly the SCM repository to achieve something more consistent, easier to build and to install.