[MAGNOLIA-1211] Generate TLD files Created: 15/Nov/06  Updated: 23/Jan/13  Resolved: 26/Mar/09

Status: Closed
Project: Magnolia
Component/s: taglibs
Affects Version/s: 3.0 Final
Fix Version/s: 4.1

Type: Improvement Priority: Major
Reporter: Magnolia International Assignee: Magnolia International
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File MAGNOLIA-1211-xdoclet.patch    
Issue Links:
dependency
depends upon MAGNOLIA-2327 ifEmpty, ifNotEmpty, ifExisting, ifNo... Closed
depends upon MAGNOLIA-2329 ContentNodeIterator could expose cont... Closed
relation
is related to MAGNOLIA-2491 Generate content2bean documentation Closed
is related to MAGNOLIA-1970 uuidLinkType has errors in the tld file Closed
is related to MAGNOLIA-2332 ImgTag could expose uuid,path,reposit... Closed
is related to MAGNOLIA-2328 set and setNode tags could expose the... Closed
is related to MAGNOLIA-1884 Review definition of all tags to ensu... Closed
is related to MAGNOLIA-2333 Update TLDs to jsp 2 schema Closed
Template:
Patch included:
Yes
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   
  • code and tld are guaranteed to be in synch
  • single place of change (as opposed to the duplicated information when writing the tld by hand)
  • self documenting

Can be done with xdoclet2+maven plugin
http://xdoclet.codehaus.org/



 Comments   
Comment by Fabrizio Giustina [ 15/Dec/06 ]

should I say that I am strongly against this?
having generated tld files:

  • makes working with an IDE a lot more difficult (you will have to run maven or configure xdoclet, etc)
  • makes tags documentation and java code less clean: at the moment tld are the source for generated documentation, and that's easier to write in a xml file instead that in javadoc comments
  • not everything can be done using xdoclet (not sure how BeanInfo classes could be handled)
  • and generally it makes build and site generation more complex...
Comment by Magnolia International [ 18/Dec/06 ]

> - makes working with an IDE a lot more difficult (you will have to run maven or configure xdoclet, etc)

I don't see why it would be a problem, at least in the context of Magnolia, since both our taglibs are separate modules.

> - makes tags documentation and java code less clean:
> at the moment tld are the source for generated documentation,

That will still be the case.

> and that's easier to write in a xml file instead that in javadoc comments

I don't see how.

> - not everything can be done using xdoclet (not sure how BeanInfo classes could be handled)

BeanInfo support could be implemented very easily if its not the case yet.
Any other request?

> - and generally it makes build and site generation more complex...
I don't see how, really.

Especially considering the advantage that

  • code and tld are guaranteed to be in synch
  • single place of change (as opposed to the duplicated information when writing the tld by hand)
  • self documenting
Comment by Fabrizio Giustina [ 19/Dec/06 ]

>> - makes working with an IDE a lot more difficult (you will have to run maven or configure xdoclet, etc)
> I don't see why it would be a problem, at least in the context of Magnolia, since both our taglibs are separate modules.

Well, using eclipse you usually load all the modules as linked project and classes/tld are loaded directly from the classes dir, without the need for building/installing a full jar... you only have to compile classes, without running maven or xdoclet. Maybe you are using IDEA or a different setup?

Comment by Magnolia International [ 19/Dec/06 ]

I'm using IDEA. Sure, if the module is clean, I wont have the tld either, but I dont think running maven once on just the taglib modules is a showstopper if you work on other modules ? (since there's not much else in the module itself that would require the tld ...)

I'm not trying to enforce the use of xdoclet here, I'm just bothered by duplicated information (java source and tld) and thus potential synch problems. xdoclet is not the most exciting piece of technology (although xd2 is a lot better/easier/faster in many respects than xd1), but tld are clearly "generate-me" shouting files

Comment by Jan Haderka [ 23/Nov/07 ]

In light of latest problems with strict jsp compilers (javelin/WL) and need of review out of sync tags/tlds (/MAGNOLIA-1884) I think we should reconsider this issue and try to implement it. We really need to make sure tags are in sync with TLD to guarantee that mgnolia can be deployed on containers with strict validation.
As for Eclipse, I don't see how this can be a problem. IDE automatically compiles classes and it is quite simple to add additional builder task to refresh/recreate tlds every time tag class changes and have to be recompiled.

Comment by Magnolia International [ 30/Jul/08 ]

I'd like to tackle this one of these days, and if results are encouraging (i.e generated files compare well to current one) I'd like to do this sooner than later, for I've noticed once more that the tld doc says that the taglib version is "3.5", which makes no sense.

Comment by Magnolia International [ 14/Aug/08 ]

All tag classes for magnolia-taglib-cms have just been xdoclet-tagged, and the comparison between generated tld and manually maintained tld yields zero difference.

I'll commit the changes to the build (usage of the xdoclet-plugin in pom.xml) as soon as the latest version of the xdoclet web-plugin is available. (currently built locally)

Comment by Magnolia International [ 19/Aug/08 ]

Same for magnolia-taglib-utility is done.

Comment by Magnolia International [ 26/Sep/08 ]

Will not have time to test latest snapshots and probably the release won't be made before we release 3.6.2. Attaching the patch for pom files. (repositories only necessary for snapshots)

I also have a little xmldiff script that shows the differences (none except the version, since i added and fixed all the tags)

Comment by Magnolia International [ 20/Jan/09 ]

Pushing this further once more; looks like the xdoclet 2.0.7 final release won't be ready in time for 4.0

Comment by Magnolia International [ 25/Mar/09 ]

linking to MAGNOLIA-2491, since both imply setting up xdoclet in our builds

Comment by Magnolia International [ 26/Mar/09 ]

Yay !

For the record, I compared our original TLDs with the generated ones using a custom little tool : http://svn.magnolia-cms.com/svn/internal/xml-diff/

Generated at Mon Feb 12 03:24:44 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.