Hi Jan, The jar size will depend upon exactly what jvm it was built with. We set the "source" and "target" properties so that whatever compiler is used we get the right bytecode version. But if you compile with a different javac version, then of course there is no guarantee of getting exactly the same output.
Here's the contents of META-INF/MANIFEST.MF from the downloadable tomahawk-1.1.6.jar: Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Built-By: mgeiler Build-Jdk: 1.4.2_13 So it was built with a real java1.4.2 environment. You'd really need to rebuild with the same jdk to completely duplicate the jar. For example, here are the disassembled versions of the same class from the original and my newly rebuilt version: real/org/apache/myfaces/webapp/filter/MultipartRequestWrapper.class -rw-r--r-- 1 simon simon 7290 2007-06-12 15:28 new/org/apache/myfaces/webapp/filter/MultipartRequestWrapper.class -rw-r--r-- 1 simon simon 7326 2008-08-25 21:17 So they are different in size. Let's have a look at the disassembly: $ javap -c -classpath real org.apache.myfaces.webapp.filter.MultipartRequestWrapper > mrw1.txt $ javap -c -classpath new org.apache.myfaces.webapp.filter.MultipartRequestWrapper > mrw2.txt $ diff mrw1.txt mrw2.txt | more 79,87c79,88 < 22: astore_2 < 23: aload_2 < 24: ifnonnull 29 < 27: aconst_null < 28: areturn < 29: aload_2 < 30: iconst_0 < 31: aaload < 32: areturn --- > 22: checkcast #59; //class "[Ljava/lang/String;" > 25: astore_2 > 26: aload_2 > 27: ifnonnull 32 > 30: aconst_null > 31: areturn > 32: aload_2 > 33: iconst_0 > 34: aaload > 35: areturn 101c102,103 < 22: areturn --- > 22: checkcast #59; //class "[Ljava/lang/String;" > 25: areturn These differences are just due to the different javac version used to compile them, not to any change in the source. In addition, it appears that the original jar was built on a Windows machine; the text files all have \r\n linefeeds. If you checked-out and built on a Unix machine, then the files will be different size. This would actually make the "original" slightly larger than the "rebuilt" one, which is not what you see. But I am sure there are other similar sorts of differences that can affect a rebuild. And things like the MANIFEST.MF file can depend upon the Maven version. This is a little sad, but maven provides no easy way to lock down the versions of all the "default" plugins that maven uses. So there is potential for minor differences here. The file ClassUtils has had import org.apache.commons.el.Logger since at least Jan 2005. So it certainly isn't a new dependency. And the shared pom declares that dependency correctly since at least Jan 2006 (it's not easy to trace back further due to svn reorganisations). And I see that tomahawk-1.1.6.pom file in the main maven repo indeed declares commons-el as a compile-time dependency. So this all seems ok from this end. I rebuilt tomahawk 1.1.6 locally (after clearing my local cache to ensure it builds from clean inputs) and all worked fine. Inside my .m2/repository directory, a tomahawk-1.1.6.pom file was created, and that declares the commons-el dependency as expected. Inside the created jarfile, META-INF/maven/*/pom.xml also specifies commons-el as a dependency. I don't know why you are getting "NoClassDefFound". That doesn't indicate a missing commons-el anyway (that would be "ClassNotFoundException"). This indicates that something commons-el depends on is not present. So it looks to me rather like something is weird in your environment, and that the tomahawk stuff does rebuild ok. I may be missing something, but it all looks ok to me. In short, I would go with your rebuilt version as a base for your patch, and not worry. Regards, Simon On Sun, 2008-08-24 at 17:17 -0600, Jan Nielsen wrote: > Performing an "mvn clean install" of the following: > > URL: http://svn.apache.org/repos/asf/myfaces/shared/branches/2_0_6 > Revision: 687859 > Last Changed Author: manolito > Last Changed Rev: 546805 > Last Changed Date: 2007-06-13 04:18:00 -0600 (Wed, 13 Jun 2007) > > URL: http://svn.apache.org/repos/asf/myfaces/tomahawk/branches/1_1_6/core > Revision: 688558 > Last Changed Author: manolito > Last Changed Rev: 546521 > Last Changed Date: 2007-06-12 09:19:07 -0600 (Tue, 12 Jun 2007) > > with these tools: > > Maven version: 2.0.9 > Java version: 1.6.0_06 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" > > produces: > > myfaces-shared-core-2.0.6.jar of size 218,118 > tomahawk-1.1.6.jar of size 2,942,611 > > The official distribution from, say: > > http://download.nextag.com/apache/myfaces/binaries/tomahawk-1.1.6-bin.zip > > has a tomahawk-1.1.6.jar of size 2,941,389. > > So, my build (of what I believe to be purely 1.1.6) produces a > different JAR than the official distribution. It's possible the > difference in size is because of a JDK or Maven difference from the > official build. Running my application with my rebuilt version of > Tomahawk I get the following initialization error: > > java.lang.NoClassDefFoundError: org/apache/commons/el/Logger > at > org.apache.myfaces.shared_tomahawk.util.ClassUtils.<clinit>(ClassUtils.java:44) > at > org.apache.myfaces.shared_tomahawk.config.MyfacesConfig.<clinit>(MyfacesConfig.java:94) > at > org.apache.myfaces.renderkit.html.util.ExtensionsPhaseListener.writeCodeBeforeBodyEnd(ExtensionsPhaseListener.java:129) > at > org.apache.myfaces.renderkit.html.util.ExtensionsPhaseListener.getCodeBeforeBodyEnd(ExtensionsPhaseListener.java:104) > at > org.apache.myfaces.renderkit.html.util.ExtensionsPhaseListener.getJavaScriptCodeAndStoreInRequest(ExtensionsPhaseListener.java:94) > at > org.apache.myfaces.renderkit.html.util.ExtensionsPhaseListener.afterPhase(ExtensionsPhaseListener.java:70) > at com.sun.faces.portlet.LifecycleImpl.phase(LifecycleImpl.java:356) > at com.sun.faces.portlet.LifecycleImpl.render(LifecycleImpl.java:266) > at > com.sun.faces.portlet.FacesPortlet.renderFaces(FacesPortlet.java:358) > at com.sun.faces.portlet.FacesPortlet.doView(FacesPortlet.java:286) > at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:235) > at javax.portlet.GenericPortlet.render(GenericPortlet.java:163) > at > com.liferay.portal.kernel.servlet.PortletServlet.service(PortletServlet.java:102) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:831) > at > org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411) > at > org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:855) > at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:703) > at > org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:660) > at > org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:578) > at com.liferay.portlet.CachePortlet._invoke(CachePortlet.java:408) > at com.liferay.portlet.CachePortlet.render(CachePortlet.java:251) > at > org.apache.jsp.html.portal.render_005fportlet_jsp._jspService(render_005fportlet_jsp.java > from :1323) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:93) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:831) > at > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:373) > at > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:470) > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:364) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:831) > at > org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411) > at > org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:855) > at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:703) > at > org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:660) > at > org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:578) > at > com.liferay.portal.util.PortalUtil.renderPortlet(PortalUtil.java:1862) > at > com.liferay.portlet.layoutconfiguration.util.RuntimePortletUtil.processPortlet(RuntimePortletUtil.java:165) > at > com.liferay.portlet.layoutconfiguration.util.RuntimePortletUtil.processPortlet(RuntimePortletUtil.java:102) > at > com.liferay.portlet.layoutconfiguration.util.RuntimePortletUtil.processTemplate(RuntimePortletUtil.java:270) > at > com.liferay.portlet.layoutconfiguration.util.RuntimePortletUtil.processTemplate(RuntimePortletUtil.java:189) > at > org.apache.jsp.html.portal.layout.view.portlet_jsp._jspService(portlet_jsp.java > from :784) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:93) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:831) > at > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:373) > at > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:470) > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:364) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:831) > at > org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411) > at > org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:855) > at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:703) > at > org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:660) > at > org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:578) > at > com.liferay.portal.action.LayoutAction.includeLayoutContent(LayoutAction.java:308) > at > com.liferay.portal.action.LayoutAction.execute(LayoutAction.java:185) > at > org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) > at > org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) > at > com.liferay.portal.struts.PortalRequestProcessor.process(PortalRequestProcessor.java:158) > at > org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) > at > org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:718) > at > com.liferay.portal.servlet.MainServlet.callParentService(MainServlet.java:401) > at > com.liferay.portal.servlet.MainServlet.service(MainServlet.java:630) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:831) > at > org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:317) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198) > at > com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:98) > at > com.liferay.portal.servlet.filters.virtualhost.VirtualHostFilter.doFilter(VirtualHostFilter.java:149) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198) > at > com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:98) > at > com.liferay.portal.servlet.filters.sessionid.SessionIdFilter.doFilter(SessionIdFilter.java:81) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198) > at > org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:853) > at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:703) > at > org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:542) > at > org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:474) > at > org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:366) > at > com.liferay.portal.servlet.FriendlyURLServlet.service(FriendlyURLServlet.java:137) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:831) > at > org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:317) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198) > at > com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:98) > at com.liferay.filters.strip.StripFilter.doFilter(StripFilter.java:88) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198) > at > com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:98) > at > com.liferay.filters.compression.CompressionFilter.doFilter(CompressionFilter.java:118) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198) > at > com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:98) > at > com.liferay.filters.secure.SecureFilter.doFilter(SecureFilter.java:150) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198) > at > com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:98) > at > com.liferay.filters.doubleclick.DoubleClickFilter.doFilter(DoubleClickFilter.java:132) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198) > at > com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:98) > at > com.liferay.portal.servlet.filters.layoutcache.LayoutCacheFilter.doFilter(LayoutCacheFilter.java:190) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198) > at > com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:98) > at > com.liferay.portal.servlet.filters.autologin.AutoLoginFilter.doFilter(AutoLoginFilter.java:108) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198) > at > com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:98) > at > com.liferay.portal.servlet.filters.virtualhost.VirtualHostFilter.doFilter(VirtualHostFilter.java:173) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198) > at > com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:98) > at > com.liferay.portal.servlet.filters.sessionid.SessionIdFilter.doFilter(SessionIdFilter.java:81) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:288) > at > org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:202) > at > org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632) > at > org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577) > at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206) > at > org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632) > at > org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577) > at > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571) > at > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150) > at > org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632) > at > org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577) > at > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571) > at > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080) > at > org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272) > at > com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637) > at > com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568) > at > com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813) > at > com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341) > at > com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263) > at > com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214) > at > com.sun.enterprise.web.portunif.PortUnificationPipeline$PUTask.doTask(PortUnificationPipeline.java:380) > at > com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265) > at > com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106) > Caused by: java.lang.ClassNotFoundException: org.apache.commons.el.Logger > at > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1498) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > ... 140 more > > Interestingly, > org\apache\myfaces\renderkit\html\util\ExtensionsPhaseListener.java > most recent history looks like: > > r546421 | manolito | 2007-06-12 02:43:59 -0600 (Tue, 12 Jun 2007) | 1 line > > Renamed 1.1.5.1 to 1.1.6 > ------------------------------------------------------------------------ > r546416 | manolito | 2007-06-12 02:37:34 -0600 (Tue, 12 Jun 2007) | 1 line > > preparing the tomahawk 1.1.6 security fix > ------------------------------------------------------------------------ > r521015 | manolito | 2007-03-21 15:57:20 -0600 (Wed, 21 Mar 2007) | 1 line > > [maven-scm] copy for tag 1_1_5 > ------------------------------------------------------------------------ > r521007 | manolito | 2007-03-21 15:41:18 -0600 (Wed, 21 Mar 2007) | 1 line > > Created temporary work branch for preparing the tomahawk release branch 1.1.5 > ------------------------------------------------------------------------ > r472792 | grantsmith | 2006-11-08 23:34:47 -0700 (Wed, 08 Nov 2006) | 2 lines > > MYFACES-1488: License headers (Part 13) > > > No sure what to make of this at this point. > > > -Jan > > > On Sun, Aug 24, 2008 at 1:59 PM, simon <[EMAIL PROTECTED]> wrote: > > It would certainly be disturbing if a release could not be recreated. > > I'm pretty sure I'm speaking for all myfaces comitters when I say that > > repeatable builds are considered very important indeed. > > > > What exactly were the incompatibilities you discovered? > > > > The two parts that we need to have in order to have a repeatable build > > are the tomahawk-module tag, and the shared-module tag. > > > > Tomahawk was released on 13 June 2007, as shown by the news page: > > http://myfaces.apache.org/index.html > > and by the dates on the jars in the maven repo: > > http://repo1.maven.org/maven2/org/apache/myfaces/tomahawk/tomahawk/1.1.6/ > > > > Oddly, in svn tomahawk/tags/1_1_6 was created in Nov 2007. > > > > <log> > > ------------------------------------------------------------------------ > > r598615 | baranda | 2007-11-27 13:38:42 +0100 (Tue, 27 Nov 2007) | 1 > > line > > Changed paths: > > A /myfaces/tomahawk/tags/1_1_6 > > (from /myfaces/tomahawk/branches/1_1_6:598614) > > > > Tagged tomahawk 1.1.6 getting it from the corresponding branch > > </log> > > > > It looks like the release manager for some older releases made release > > branches, but did not make release tags. That does seem like a bad idea > > to me, but not fatal. Looking at the commits to the > > "tomahawk/branches/1_1_6" dir, the last one was on 12 Jun, ie the day > > before the release. So that is clearly the code that was in the official > > release. And that's exactly the code that baranda later put into the > > proper "tags" dir, so although "delayed", that tomahawk 1.1.6 tag looks > > correct to me, ie should correspond to the actually-released binary. > > > > > > Here are the important bits from the branches dir: > > > > <log> > > ------------------------------------------------------------------------ > > r546805 | manolito | 2007-06-13 12:18:00 +0200 (Wed, 13 Jun 2007) | 2 > > lines > > Changed paths: > > > > M > > /myfaces/shared/branches/2_0_6/core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlRendererUtils.java > > > > TOMAHAWK-983 > > TOMAHAWK-1021 > > > > ------------------------------------------------------------------------ > > r546402 | manolito | 2007-06-12 09:15:37 +0200 (Tue, 12 Jun 2007) | 1 > > line > > Changed paths: > > M /myfaces/shared/branches/2_0_6 > > M /myfaces/shared/branches/2_0_6/core > > M /myfaces/shared/branches/2_0_6/core/pom.xml > > M /myfaces/shared/branches/2_0_6/pom.xml > > D /myfaces/shared/branches/2_0_6/release.properties > > M /myfaces/shared/branches/2_0_6/shared-impl > > M /myfaces/shared/branches/2_0_6/shared-impl/pom.xml > > M /myfaces/shared/branches/2_0_6/shared-tomahawk > > M /myfaces/shared/branches/2_0_6/shared-tomahawk/pom.xml > > > > shared 2.0.6 preparation > > > > ------------------------------------------------------------------------ > > r546054 | manolito | 2007-06-11 11:10:55 +0200 (Mon, 11 Jun 2007) | 1 > > line > > Changed paths: > > A /myfaces/shared/branches/2_0_6 > > (from /myfaces/shared/branches/2_0_5:546053) > > > > </log> > > > > I'm pretty confident that my initial guess is right, ie that the > > "shared/branches/2_0_6" code holds the "shared" code used to build the > > tomahawk 1.1.6 release. I just can't see how the release could have been > > prepared any other way. > > > > So this seems ok: a release preparation branch was made, then the pom > > updated to contain the new version numbers, and then a couple of bugs > > fixed. And no changes made after the actual release date. > > > > > > > > I'll try to build tomahawk from fresh checkouts of these, but apart from > > some failure to officially tag the head of the release-preparation > > branch I cannot see anything wrong here. > > > > > > Regards, > > Simon > > > > > > > > > > > > On Sat, 2008-08-23 at 18:04 -0600, Jan Nielsen wrote: > >> Unfortunately, on closer inspection, my attempted rebuild of tomahawk > >> 1.1.6, while successful and runnable, does not re-create the 1.1.6 > >> release; it introduces some transitive dependencies which make it > >> unusable in my environment. At this point, I am left with > >> de-compilation and patching the Tomahawk JAR - very ugly. > >> > >> It's worrisome to me that a released MyFaces artifact cannot be easily > >> reproduce. Perhaps, there is a way, but I can't seem to find it, and > >> it sounds like the dev list can, either. In my experience, a simple, > >> reproducible build system pays-back many fold to a project (and part > >> of that includes a simple and well thought-out source-repository > >> structure. I'd be happy to open bugs on these issues if you like, but > >> it's unlikely I'll be able to implement these changes, even if the > >> developers approves them. Let me know. > >> > >> Best Wishes, > >> > >> -Jan > >> > >> On Thu, Aug 21, 2008 at 6:28 PM, Jan Nielsen > >> <[EMAIL PROTECTED]> wrote: > >> > Thank you, Simon! With a checkout of the branch and install of the > >> > artifact, the Tomahawk 1.1.6 tag builds and works. With this build of > >> > Tomahawk 1.1.6, I have validated Rodrigo Macedo's patch for > >> > TOMAHAWK-1249. > >> > > >> > Thanks, again! > >> > > >> > -Jan > >> > > >> > > >> > On Thu, Aug 21, 2008 at 1:27 AM, [EMAIL PROTECTED] > >> > <[EMAIL PROTECTED]> wrote: > >> >> [EMAIL PROTECTED] schrieb: > >> >>> > >> >>> Jan Nielsen schrieb: > >> >>>> > >> >>>> To get a bug fix into 1.1.6, I would like to recreate the Tomahawk > >> >>>> 1.1.6 build. I grabbed the code at: > >> >>>> > >> >>>> http://svn.apache.org/repos/asf/myfaces/tomahawk/tags/1_1_6 > >> >>>> > >> >>>> and tried to build that with "mvn -Djsf=12 -Dtomahawk=12 clean > >> >>>> package" but it fails to resolve the dependency on > >> >>>> myfaces-shared-tomahawk 2.0.6: > >> >>>> > >> >>>> org.apache.myfaces.shared:myfaces-shared-tomahawk:jar:2.0.6 > >> >>>> > >> >>>> Reviewing a couple of repositories, it looks like 2.0.x releases are > >> >>>> there, /except/ for 2.0.6. I'm fine with building it myself but it > >> >>>> also looks like the 2.0.6 is missing from subversion: > >> >>>> > >> >>>> http://svn.apache.org/repos/asf/myfaces/shared/tags > >> >>>> > >> >>>> So, can the Tomahawk 1.1.6 build be reproduced? Is there a recipe, a > >> >>>> wiki, a script, or a spot in subversion from which the Tomahawk 1.1.6 > >> >>>> release can be built? > >> >>>> > >> >>>> > >> >>> > >> >>> Hmm..that is weird indeed. I'll check the email archives. > >> >>> > >> >>> Tomahawk 1.1.6 does indeed depend on shared-2.0.6, and as you say there > >> >>> appears to be neither a tag nor a released jar for shared-2.0.6. > >> >>> > >> >>> The jsf1.2 "flavour" of tomahawk has only been added *after* the 1.1.6 > >> >>> tomahawk release. So the "-Djsf=12 -Dtomahawk=12" options are not > >> >>> valid when > >> >>> building the 1.1.6 release. Note that normal tomahawk 1.1.x runs fine > >> >>> on > >> >>> both JSF1.1 and JSF1.2. However there are some optimisations that can > >> >>> be > >> >>> added by building against JSF1.2, hence the new "flavour". But that > >> >>> doesn't > >> >>> change the fact that shared-2.0.6 is missing. > >> >> > >> >> I see there is a 2.0.6 dir in > >> >> http://svn.apache.org/repos/asf/myfaces/shared/branches > >> >> > >> >> And the pom there has the released version number. > >> >> > >> >> So I would guess that whoever did the release did a "mvn install" from > >> >> that > >> >> branch dir, then build the final release of tomahawk but forgot to: > >> >> * move the branch to the tags dir > >> >> * deploy the shared jar to the release repo > >> >> > >> >> So to rebuild tomahawk 1.1.6, you should be able to check out that > >> >> branch > >> >> dir, do "mvn install" locally then build tomahawk 1.1.6. > >> >> > >> >> In some ways it *is* a little odd to deploy the shared jar to the > >> >> release > >> >> repo, as nobody will actually ever use it - except people like yourself > >> >> who > >> >> want to rebuild the official release. But for tidiness it probably > >> >> *should* > >> >> be done. And certainly an svn copy should have existed in the tag dir, > >> >> not > >> >> just "branches" (although there is technically no difference when using > >> >> svn). > >> >> > >> >> Regards, > >> >> Simon > >> >> > >> >> > >> > > > > >
