Thanks for the input guys.  Any other votes?  I'll likely try to close this later this evening.

Scott O'Bryan

On November 6, 2013 at 2:43:33 PM, Blake Sullivan ( wrote:

+1 for me as well.  Presumably we won't run into this problem later since the tags are generated in impl and Enums showing up in their api should be in the api package.  We could have this problem if we added enum support to components, but the component generation has access to the component metadata, which knows that this is an enum case.

-- Blake Sullivan

On Nov 6, 2013, at 1:35 PM, Andy Schwartz wrote:

Hey Scott -

Great, thanks for tracking this down.  +1 for me then.


On Wed, Nov 6, 2013 at 12:55 PM, Scott O'Bryan <> wrote:
I'm changing my vote to +1.  I was able to fix this issue in the trinidad poms by adding:


To the maven-faces plugin definition in trinidad-impl.  So  I'll handle the ticket under trinidad and make sure its part of the next release.  The key was found in the maven class loading guide:

I noticed that the error was being issued in the impl package which should have had access to the api.  But the dependencies are only explicitly available to the javacc plugin or can be referenced manually by the mojo.  Our mojo doesn't handle dependencies, so the configuration is necessary.  Might be nice to add it at some point though.

Andy, does this work for you?

Scott O'Bryan

On November 6, 2013 at 8:32:00 AM, Scott O'Bryan ( wrote:


Yeah, I was seeing this too.  I was trying to track this as part of my work for the next Trinidad release, but I think your right.  This may be handled better in the plugin.  At the very least we should evaluate it.  What's happening here is a new check was added to test if a class for an attribute happens to be an enumeration.  In the case where we get the error, DateListProvider hasn't been built yet since the plugins generate the source BEFORE the plugins are built.

I'm going to generate a JIRA ticket and I for one think we need to fix this issue before releasing the plugins.  As such. my vote is a -1 pending this issue.
Scott O'Bryan

On November 6, 2013 at 7:42:03 AM, Andy Schwartz ( wrote:

Hey Scott -

I attempted to do a clean Trinidad build against the new plugins.  I happened to notice this exception during the build:

> [INFO] --- maven-faces-plugin:2.0.8:generate-jsp-taglibs (default) @ trinidad-impl ---
> [INFO] ClassNotFound error resolving type org.apache.myfaces.trinidad.model.DateListProvider
> java.lang.ClassNotFoundException: org.apache.myfaces.trinidad.model.DateListProvider
>     at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(
>     at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(
>     at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(
>     at java.lang.Class.forName0(Native Method)
>     at java.lang.Class.forName(
>     at org.apache.myfaces.trinidadbuild.plugin.faces.util.ClassLoaderUtils.loadClass(
>     at org.apache.myfaces.trinidadbuild.plugin.faces.util.ClassLoaderUtils.loadClass(
>     at org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractTagGenerator.resolveType(
>     at org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.TrinidadValidatorTagGenerator.writeSetProperty(
>     at org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractValidatorTagGenerator.writeSetProperties(
>     at org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractValidatorTagGenerator.generateTagHandler(
>     at org.apache.myfaces.trinidadbuild.plugin.faces.GenerateJspTaglibsMojo._generateTagHandlers(
>     at org.apache.myfaces.trinidadbuild.plugin.faces.GenerateJspTaglibsMojo.execute(
>     at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
>     at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(
>     at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(
>     at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(
>     at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(
>     at org.apache.maven.DefaultMaven.doExecute(
>     at org.apache.maven.DefaultMaven.execute(
>     at org.apache.maven.cli.MavenCli.execute(
>     at org.apache.maven.cli.MavenCli.doMain(
>     at org.apache.maven.cli.MavenCli.main(
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>     at java.lang.reflect.Method.invoke(
>     at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(
>     at org.codehaus.plexus.classworlds.launcher.Launcher.launch(
>     at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(
>     at org.codehaus.plexus.classworlds.launcher.Launcher.main(
> [INFO] Generated 145 JSP tag(s)

I have no idea whether this exception in new in 2.0.8.  Is this something that we should look at before rolling out the plugins release?


On Mon, Nov 4, 2013 at 4:29 PM, Scott O'Bryan <> wrote:
I was running the tasks needed to release the Trinidad Maven Plugins version 2.0.8 which is needed as a prerequisite to a Trinidad release.  I have compiled the Release Notes[1] for the 2.0.8 release.  

I have generated the tag [2] and have deployed the built artifacts to nexus [3].  Lastly I have included a source archive [4].  I've done preliminary testing and building, updated the plugins to comply with checkstyle, and made sure the build passed rat:check.

Please take a look at the Trinidad Maven Plugins 2.0.8 release artifacts now and vote.

Please note: 

This vote is "majority approval" with a minimum of three +1 votes (see [5]). 

[ ] +1 for community members who have reviewed the bits  
[ ] +0 
[ ] -1 for fatal flaws that should cause these bits not to be released, and why.............. 

  Scott O'Bryan