Thanks, <br> A patch (attached to <a href="https://jira.jboss.org/jira/browse/GTNPORTAL-25" target="_blank">https://jira.jboss.org/jira/browse/GTNPORTAL-25</a>) using maven resource filtering is being tested by mwringe.<br>
Dimitri BAELI - eXo Platform SAS<br>
<br><br><div class="gmail_quote">On Tue, Oct 6, 2009 at 7:33 PM, Matt Wringe <span dir="ltr"><<a href="mailto:mwringe@redhat.com" target="_blank">mwringe@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>On Tue, 2009-10-06 at 19:20 +0200, Dimitri BAELI wrote:<br>
> ../../deploy/exoplatform.ear/pc-portlet-2.1.0-Beta01.jar has three<br>
> main issues:<br>
> * ../../deploy : hard coded path<br>
> * exoplatform.ear : hard coded ear name<br>
> * pc-portlet-2.1.0-Beta01.jar : hardcoded version<br>
><br>
> We can at least use the resource filtering of maven to generate the<br>
> server-patch jar<br>
> * Ideally with ${<a href="http://ear.name" target="_blank">ear.name</a>} and ${org.gatein.pc.version} from<br>
> gatein-parent pom.<br>
><br>
> Please fill an issue on that in GTNPORTAL<br>
<br>
</div><a href="https://jira.jboss.org/jira/browse/GTNPORTAL-25" target="_blank">https://jira.jboss.org/jira/browse/GTNPORTAL-25</a><br>
<div><div></div><div><br>
> , I'll have a look, but using the maven tooling is better imho (as<br>
> exobuild is slowly migrating to maven).<br>
><br>
> Dimitri BAELI - eXo Platform SAS<br>
><br>
><br>
> On Tue, Oct 6, 2009 at 5:35 PM, Matt Wringe <<a href="mailto:mwringe@redhat.com" target="_blank">mwringe@redhat.com</a>><br>
> wrote:<br>
> On Tue, 2009-10-06 at 17:08 +0200, Julien Viet wrote:<br>
> > On Oct 6, 2009, at 4:59 PM, Matt Wringe wrote:<br>
> ><br>
> > > Portlet TLDs on the JBoss AS version of GateIn was not<br>
> working, so I<br>
> > > had<br>
> > > to renable the patch to specify the portlet war which<br>
> contains the<br>
> > > portlet TLDs. [I don't know why the patch was missing, if<br>
> there was a<br>
> > > reason for its absence please let me know]<br>
> > ><br>
> ><br>
> > It works differently in tomcat (to not say more<br>
> conveniently), as<br>
> > tomcat takes any TLD that it finds in the lib directory.<br>
><br>
><br>
> yeah, I like how with tomcat it will find and use all tlds on<br>
> the<br>
> classpath.<br>
><br>
> > > This means we have a patch to the<br>
> deployers/jbossweb.deployers/web.xml<br>
> > > to specify the jar containing the tlds (see<br>
> > > <a href="http://www.jboss.org/community/wiki/GlobalTLDs" target="_blank">http://www.jboss.org/community/wiki/GlobalTLDs</a>)<br>
> ><br>
> > it would be nice in JBoss AS to have a better way to add<br>
> global TLD<br>
> > that do not require a patch of a file because we also have<br>
> to keep the<br>
> > web.xml file in our JBoss patch directory. Would it be<br>
> possible to<br>
> > have something that goes in that direction, like a<br>
> deployment<br>
> > descriptor that would be found by JBoss deployers and we<br>
> would only<br>
> > have to have the correct declaration in the JBoss patch<br>
> directory.<br>
><br>
><br>
> We can create a custom jboss deployer that could do this for<br>
> us (and we<br>
> could just use the portlet.xml file as the triggering<br>
> deployment<br>
> descriptor).<br>
> I already have one that was designed for now abandoned JBoss<br>
> AS5 version<br>
> of JBoss Portal. What this deployer does is modify the web.xml<br>
> of the<br>
> portlet to do the exact same thing as the patch. JBoss<br>
> deployers are<br>
> really limited at this point when it comes to modify things<br>
> other than<br>
> deployment descriptors.<br>
> There are a lot of things we can do with a JBoss deployer, we<br>
> wouldn't<br>
> even need to use the container specific wci implementation<br>
> since the<br>
> deployer can easily add the servlets to the web.xml.<br>
><br>
> I am not sure if we want to go this route (and we would need<br>
> to update<br>
> exobuild to allow deployment to the deployers directory<br>
> instead of the<br>
> deploy directory).<br>
><br>
> Thoughts on this?<br>
><br>
> > ><br>
> > >> <init-param><br>
> > >> <description>Portlet standard tlds</description><br>
> > >> <param-name>tagLibJar2</param-name><br>
> > >><br>
> <param-value>../../deploy/exoplatform.ear/pc-portlet-2.1.0-<br>
> > >> Beta1.jar</param-value><br>
> > >> </init-param><br>
> > ><br>
> > > Can we change the jar name to be unversioned so that when<br>
> the version<br>
> > > changes it doesn't break this?<br>
> ><br>
> > you mean as a deploy time facility ?<br>
> ><br>
> > as this jar contains code, maybe it would be best to copy<br>
> the TLD in<br>
> > another jar file at deploy time that would have a constant<br>
> name.<br>
><br>
><br>
> hmm, I guess we could do that and just have it as an exploded<br>
> war in the<br>
> patch. If we want to be able to deploy an actual war from the<br>
> maven<br>
> repo, we would still need to figure out how remove the<br>
> versioning from<br>
> its name (I don't know if exopackaging can do that or not).<br>
><br>
><br>
> > > Or can we specify a token instead of<br>
> > > hardcoding the jar name?<br>
> > ><br>
> > > Or does anyone know a better way to add the tlds to the<br>
> portlets on<br>
> > > JBoss AS?<br>
> > ><br>
> > > _______________________________________________<br>
> > > gatein-dev mailing list<br>
> > > <a href="mailto:gatein-dev@lists.jboss.org" target="_blank">gatein-dev@lists.jboss.org</a><br>
> > > <a href="https://lists.jboss.org/mailman/listinfo/gatein-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/gatein-dev</a><br>
> ><br>
><br>
> _______________________________________________<br>
> gatein-dev mailing list<br>
> <a href="mailto:gatein-dev@lists.jboss.org" target="_blank">gatein-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/gatein-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/gatein-dev</a><br>
><br>
><br>
<br>
</div></div></blockquote></div><br>