RF-12802: page fragments repository moved here

[jhuska]

No description provided.

[bleathem]

I'd rather we not reformat the license header.

[bleathem]

this looks really good. IMO we should clean up the pom.xml formatting and then merge it. We are still in the Alpha stage with RichFaces 5, so we will have time to re-factor the fragments once we start playing.

One question about packaging: How will users consume these fragments? Are we packaging them in a separate jar? In the richfaces.jar?

[lfryc]

+1 separated JAR

I can foresee two solutions:

1. separated maven module, like richfaces5/build/page-fragments producing artifact richfaces-page-fragments (richfaces-page-fragments.jar)

2. source subfolder - like richfaces5/framework/src/main/page-fragments producing artifact richfaces:page-fragments (richfaces-page-fragments.jar)

(2) is actually solution for cyclic dependencies, which is I believe not our case at the moment, @jhuska ?

[jhuska]

I have updated the pull request according to your comments.

• formatted the build/pom.xml according to the JBoss rules
• moved page-fragments under build/page-fragments
• removed cyclic dependency of page-fragments to richfaces itself
• rebased against master

[lfryc]

I have reviewed the dependencies of the page-fragments and found out you suggest to add these dependencies:

joda-time:2.3
- DateTime

commons-lang:2.6
- Validate.isTrue
- StringEscapeUtils.unescapeJava

json-simple:1.1.1
- JSONParser

org.jodah:typetools:0.3.0
- TypeResolver.resolveRawArguments

I'm fine with DateTime, since it's going to be standardized - even though we may consider making it optional dependency and provide alternative in form of java.util.Date.

I didn't found reason to leave Validate.isTrue - this should be replaced by more verbose but dependency free code.

I did some googling for alternatives to StringEscapeUtils.unescapeJava and found out few suggestions for dependency free Java-unescaping.

JSONParser seems to be necessary (even though we don;t use it extensively yet), but I would favor standard APIs in form of JSR-353.

I believe TypeResolver can be re-written from scratch, but since it's one-class ASL dependency, we might consider shading it.

---

However I believe we are ready to merge page fragments with dependencies as they are and create an issue to address described shortcomings ^. Wdyt @bleathem ?

I have created this issue to address it: https://issues.jboss.org/browse/RF-13300

[lfryc]

I also believe you forgot to specify version for commons-lang.

Page fragment sources are also missing license headers:
https://issues.jboss.org/browse/RF-13299

Once merged, we should make sure we favor Page Fragments in Framework Tests (we may start to refactor newly introduced components so that we won't dive into any refactoring): https://issues.jboss.org/browse/RF-13301

[lfryc]

Merged to master in this commit: https://github.com/richfaces/richfaces/tree/8d11fe003fcb322b2d397114e648bddfac6ac4be

[lfryc]

Thanks Juraj for all your hard work on Page Fragments, this is huge achievement!