Split up framework into minimal pieces

[kiesel]

Scope of Change

The collection of classes delivered with the framework will be shrinked to an absolute minimum. Classes required for bootstrapping and very basic and common operations will be shipped as the "XP Framework Core", others will be available as separate library.

Rationale

The XP Framework today comes with a collection of standard implementations forming the whole classbase; this includes, for example, scriptlet package as the foundation for HTTP processing, rdbms to perform database queries, img for image manipulation.

While they're very frequently used, they don't form the very base of the framework. Separating them is supposed to support

• implementation variance
• separate release cycles
• shrinking the size of XP applications (only include what's required)
• ...

Functionality

Split

The following packages will remain in core:

• lang
• io
• peer
• util
• text, including:
  • text.encode
  • text.format
  • text.regex
  • text.util
  • classes text.CSVGenerator, text.StringUtil

The following packages will become separate modules:

• gui
• img
• math
• rdbms
• remote
• scriptlet
• security
• text.csv
• text.doclet
• text.parser
• text.spelling
• unittest
• webservices
• xml

Modules provided by the XP Framework as a stable and reliable base continue to be hosted within the XP Framework organisation at GitHub.

Release

The framework and modules will not share a release cycle; their version numbers, will diverge, consequently. In order make that clear, the following applies to their versioning:

• XP Framework Core will continue to carry its current version number
• all modules will be reset to version 1.0.0

Dependencies

All modules depend on XP Framework Core, but modules may also depend on another module (such as webservices) depend on xml. Thus, to efficiently manage this, a dependency management should be used.

Core modules should have no external dependencies - it should be self contained.

Security considerations

Speed impact

Speed impact by adding more paths to an include_path is expected; if that develops to be grave, effort must be spent to build packaging forms that counterwork that effect (eg. building uber-xars).

Dependencies

Related documents

• RFC XP 6 #172 - XP 6

[mrosoiu]

+1 looks good to me

[kiesel]

• Changed the versioning of modules & core.

[iigorr]

+1

[thekid]

As discussed with @kiesel - let's see if we can somehow manage to make our dependency management solveable by composer

[mrosoiu]

xp-maven-plugin is already able to manage dependencies (actually Maven is doing that):

• you define in pom.xml the direct dependencies that your project relies upon
• when you 'make test', direct and transient dependencies are downloaded into ~/.m2/repository and an entry for each one is added in the generated [/path/to/project]/target/project.pth before executing the unittest runner
• if you 'mvn package -Dxp.package.packDependencies', all dependencies are packed (merged or XAR inside XAR) in the resulting artifact

For local development, we can add a new goal (say 'mvn generate-pth'), that will:

• download all XAR dependencies (direct and transient) to [/path/to/project]/lib
• generate/update the [/path/to/project]/project.pth file with references to all downloaded dependencies

[kiesel]

Dependencies from new core to the rest - needs to be resolved:

• io.archive.zip.ZipCipher -> math.BigInt
• peer.mail.InternetAddress -> text.encode.QuotedPrintable
• peer.mail.InternetAddress -> text.encode.Base64
• peer.mail.transport.MailTransport -> text.encode.QuotedPrintable
• util.collections.Queue / Stack -> text.String
• util.log.LogObserver -> rdbms.DBObserver
• util.Properties -> text.TextTokenizer
• util.semaphore.SessionSemaphore -> scriptlet.HttpSession

[thekid]

io.archive could be extracted into a new module "archives" or even io.archive.zip to "zip-archive".

[thekid]

The dependency util.collections.Queue / Stack -> text.String was a false positive, see xp-framework/xp-framework@8222f1d

[thekid]

Maybe the text package should remain in the minimal package except text.csv, text.parser, text.doclet and text.spelling, each of which would be extracted into its own module.

$ xp -r text
@lang.FileSystemClassLoader<F:\...\xp.public\core\src\main\php\>
package text {
  package text.csv
  package text.doclet
  package text.encode
  package text.format
  package text.parser
  package text.regex
  package text.spelling
  package text.util

  public abstract class text.Tokenizer
  public class text.CSVGenerator
  public class text.Collator
  public class text.DateFormat
  public class text.StreamTokenizer
  public class text.StringTokenizer
  public class text.StringUtil
  public class text.TextTokenizer
}

The package text.util should go to the security package:

$ xp -r text.util
@lang.FileSystemClassLoader<F:\...\xp.public\core\src\main\php\>
package text.util {

  public class text.util.RandomCodeGenerator
  public class text.util.RandomPasswordGenerator
}

The package text.format has been deprecated for a while IIRC.

[iigorr]

• util can be decomposed into smaller speciallized packages or at least some aspects should be extracted.
• "extracted" packages should be cut less along technological boundaries but more along logical ones. e.g. LogObserver might just belong in rdbms.log.

[kiesel]

Split up text package as proposed in @thekid's comment.

[thekid]

Oh, and text.CSVGenerator (deprecated) and text.StringUtil (swiss army knife antipattern) could both be put to rest I think.

[thekid]

The resulting filesystem of a development checkout may look as follows:

/path/to/xp
^- core     # Minimal framework, maybe named "skeleton"? - from xp-framework/xp-framework
|   ^- boot.pth
|   |- tools [ class.php web.php xar.php lang.base.php ]
|   |- src/main/php [ lang io peer util text xp ]
|   `- src/test/php [ ... ]
|
|- rdbms     # Database drivers - xp-framework/rdbms
|  ^- module.pth
|  |- src/main/php [ sybase mysql mssql pgsql sqlite criteria ]
|  `- src/test/php [ ... ]
|
|- unittest  # Unittest API - xp-framework/unittest
|  ^- module.pth
|  |- src/main/php [ unittest ]
|  `- src/test/php [ ... ]
|
|- scriptlet # Scriptlets (required for "rest" module) - xp-framework/scriptlet
|  ^- module.pth
|  |- src/main/php [ scriptlet ]
|  `- src/test/php [ ... ]
|
|- xml       # XML Support (required for "rest" module) - xp-framework/xml
|  ^- module.pth
|  |- src/main/php [ xml ]
|  `- src/test/php [ ... ]
|
|- rest      # REST Webservices - JSON and XML - xp-framework/rest
|  ^- module.pth
|  |- src/main/php [ webservices.rest webservices.json ]
|  `- src/test/php [ ... ]
|
|- lang      # XP Language - xp-framework/xp-language
|  ^- compiler.pth
|  |- src/main/php [ xp ]
|  `- src/test/php [ ... ]
| 
`- stomp     # STOMP Protocol - xp-forge/stomp
   ^- module.pth
   |- src/main/php [ unittest ]
   `- src/test/php [ ... ]

So we'll end up with lots of use entries, and then lots of class loaders being registered (16 in the above case, plus .).