On Sat, Jun 21, 2008 at 10:20 AM, simon <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2008-06-19 at 14:14 -0500, Leonardo Uribe wrote:
>
> > On Thu, Jun 19, 2008 at 2:00 PM, simon <[EMAIL PROTECTED]> I'm
> > a bit puzzled about the new tomahawk1.2 stuff. It looks like some
> > "unpack" goal is being run using myfaces-builder-plugin but I
> > cannot
> > find any code in the myfaces-builder-plugin project for this.
> > Where is
> > it?
> >
> > look the package on myfaces builder plugin:
> >
> > org.apache.myfaces.buildtools.maven2.plugin.builder.unpack
>
> Aha. Thank you.
>
> I have a few more questions:
>
> There is a orderModelIds property for BuildMetaDataMojo. Is it really
> needed? Why would it make a difference to tomahawk-sandbox if the
> myfaces-api metadata was loaded before or after myfaces-tomahawk
> metadata?
>
>
This was some stuff created by historical reasons, trying the
chaining procedure of metadatas (what allow to have the metadata of a
jar). Really this could be removed. The original idea was that if some
change on
myfaces api related to its metadata, the next build of sandbox if this
metadata
has precedence the change is applied. But after thinking better this, it
become useless, because this can be controlled building the projects in
some specific way.
Curiously, this hack was replaced with the hack mentioned below.
>
> What are these properties used for?
> * replacePackagePrefixTagFrom
> * replacePackagePrefixTagTo
>
>
On tomahawk, this properties are necessary on this execution:
<execution>
<!-- A hierarchy of different tag classes must be created,
because this classes are not part of the public api. The
generation of all html package is the same. Please note that
we need only a subset -->
<configuration>
<replacePackagePrefixTagFrom>org.apache.myfaces.taglib</replacePackagePrefixTagFrom>
<replacePackagePrefixTagTo>org.apache.myfaces.shared_tomahawk.taglib</replacePackagePrefixTagTo>
</configuration>
<goals>
<goal>build-metadata</goal>
</goals>
</execution>
The utility of this properties is generate all necessary base tag classes
which tomahawk components inherits, based
on the metadata of myfaces-api. For do that, it is necessary to tell the
builder plugin during the
build of its metadata, that replace the package name from:
org.apache.myfaces.taglib
to
org.apache.myfaces.shared_tomahawk.taglib
in order to avoid duplicate class exceptions when executing tomahawk and
myfaces core together.
I tried several hacks to do this and this hack probed to be the most easy to
understand and implements.
But maybe is not the only one. Suggestions are welcome!!!!
>
> Why does each project need to define the templates itself? It is getting
> rather annoying (and error-prone) to keep them all synchronized. I can
> understand having the *option* to override the template, but would it be
> ok if it defaulted to using a template from the myfaces-builder-plugin,
> or is there a good reason not to?
>
The problem is what happen if a error occur on the template and a fix is
needed. It is more easy to
modify a file inside the project that has the error that run a full release
of the plugin (in this
case myfaces-builder-plugin).
Theorically, the default templates for everything should be tomahawk
templates (myfaces templates has
some special hacks and I want the archetype for custom plugins). But for now
I'm using a diff tool to move
changes and keep all of them synchronized. (myfaces core, tomhahawk, sandbox
and myfaces commons).
The plugin is very intelligent in this case. First it try to found the
template on the project, then
on the classpath of the plugin.
regards
Leonardo Uribe
> Cheers,
> Simon
> >
>
>
