Leonardo Uribe schrieb: > Hi > > The problem with xml files to make faces-plugin test work is now fixed.
Great. > > I have a question about how myfaces-metadata works. > > The idea is have one file per jar, and when the model is readed, it > should scan every artifact and merge it with the generated > myfaces-metadata.xml. I'm right or wrong (This is what I'm doing right > now, and in my opinion is the preferred way)? I'm not quite clear what your description above means. I think we are talking about the same thing, but just to be clear this is how I would see it working: == for goal build-metadata: start with an empty model for each jarfile containing a META-INF/myfaces-metadata.xml file read that myfaces-metadata.xml file add the resulting objects into the model[1] run the ModelBuilder for the current project, which adds more objects to the model save the model into META-INF/myfaces-metadata.xml in the current project An alternative would be to do the merging just at the xml level, then build a model from the resulting merged xml file. That also seems reasonable. == for other goals (eg generate faces.xml, generate tag classes): start with an empty model read META-INF/myfaces-metadata.xml for the current project only add the resulting objects to the model pass the model object to the appropriate generator class[3] [1] Hmm..might need to somehow detect and handle duplicate data. In particular, tomahawk will depend on both myfaces-api and myfaces-impl. But the META-INF/myfaces-metadata.xml file will have a copy of all the data from the myfaces-metadata.xml contained in myfaces-api jarfile. So if *all* jars in the classpath are processed, the data from myfaces-api.jar will be processed twice. Options I see are (a) don't worry; the data will just be identical (b) check that if a model object is being overwritten, the new data is identical (c) have the plugin configured with an explicit list of jars to process metadata from. Then in the pom it must be configured so that myfaces-impl is processed and myfaces-api is ignored. Then make it an error for the same model object to be defined twice. (d) have a myfaces-metadata.xml file *not* include data inherited from parent projects. That's cleaner in a way, but means that when processing other goals we cannot just load the metadata file from the local project but need to merge in all the ancestor projects too. Ecch. (e) in the myfaces-metadata.xml, somehow mark entries with the jarfile they came from. Option (c) is probably the safest..and not too complicated. [2] eg something that executes a velocity template against the model Regards, Simon
