With the refactoring, we made sure that Tomahawk is not in disadvantage against other component frameworks, which would work with any version of the implementation. So the change was heavily discussed, but finally regarded as a wise step.
regards,
Martin
Thanks for the response :)
I looked previously for a sources zip, but found only for 1.1.1. If they are to be included in the next nightly build, that solves my problem.
About maven... Imagine the process: configure SVN to get through our corporate proxy, find the correct module (which is not documented on the website or elsewhere, and cannot be found browsing through the repository), download the sources, browse through them until understanding that there is no other option than installing maven, download maven, configure it to get through our corporate proxy, launch maven, get a exception (enclosed beneath this post). I run out of time for the task and started looking for alternatives :)
The library version problem mentioned here seems the same that you may have with Apache Commons or any jar included in a JBoss bundle (the infamous log4j version change comes to mind). It's like upgrading to a servlet 2.4 engine inside weblogic 8.1. You cannot. You have to upgrade the container.
Please note that this is not a rant. MyFaces is working nice, and I have solved mi particular hiccup. It's just that this problem seems common, and other projects seem to have chosen not to solve it.
Thanks for the help :)
===
[INFO] Using default encoding to copy filtered resources.
Downloading: https://maven-repository.dev.java.net/nonav/repository/javax.servlet.jsp/poms/jsp-api-2.1.pom
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).
Reason: Error getting POM for 'javax.servlet.jsp:jsp-api' from the repository: Error transferring file
javax.servlet.jsp:jsp-api:pom:2.1
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
java.net ( https://maven-repository.dev.java.net/nonav/repository),
apache-maven-snapshots (http://cvs.apache.org/maven-snapshot-repository),
myfaces-repo (http://myfaces.zones.apache.org/dist/maven-repository)
De: Martin Marinschek [mailto:[EMAIL PROTECTED]]
Enviado el: martes, 20 de junio de 2006 14:17
Para: MyFaces Discussion; Catalin Kormos
Asunto: Re: Why the "shared" package renaming?
Hi Coloma,
this step was done to ensure that you can use different versions of MyFaces' implementation and it's component library in the same container, without fearing incompatibility problems. Imagine you would have a class which had changed a method signature between versions, and the component library would not be able to reference the class that the implementation loads - you couldn't work around this except changing the implementation in the container. If you weren't allowed to to this, you would be stuck. This is more of a problem in the future, as JSF will be part of the JEE5 containers.
I wonder why you can't use our sources, though - if you call mvn clean install once, you should be able to attach the source directories of the shared project to your jars - I think that in the nightly builds and the next release, this will even work directly out of the box (correct me if I'm wrong here, Catalin)
regards,
MartinOn 6/20/06, Coloma Escribano, Ignacio <[EMAIL PROTECTED]> wrote:
Is the extra jar in the lib really an annoyance? Hibernate alone has 10+ jars, and a standard project has bigger problems than an extra jar. But right now if I want to create a custom component tag class, to choose the parent class (ctrl + spc) the following options are available:
- HtmlInputTextTag (from two sources, taglib.html and taglib.html.ext) which inherits from HtmlInputTextTagBase
- HtmlInputTextTagBase (from myfaces.shared_impl and myfaces.shared_tomahawk).
The real showstopper here is that I cannot browse the sources for the shared classes inside Eclipse (because the binaries and the sources package names do not match), and am forced to do it by hand. This is really an annoyance, because a standard project integrates more than ten frameworks; if a couple of them did the same, my performance would drop to a crawl.
Are you sure that the package renaming gives Tomahawk more independence? I would understand it if we were talking about separating layers and using interfaces, but how does the package name isolate changes?
Sorry if I sound inquisitive :)
De: Cagatay Civici [mailto:[EMAIL PROTECTED]]
Enviado el: martes, 20 de junio de 2006 13:08
Para: MyFaces Discussion
Asunto: Re: Why the "shared" package renaming?
Hi,
To get rid of another shared jar in the lib actually, also make the tomahawk more independent from the implementation.
Cagatay,On 6/20/06, Coloma Escribano, Ignacio <[EMAIL PROTECTED]> wrote:
Does anybody know why the shared package gets renamed for tomahawk and core?
I'm trying to use the myfaces jar in a project and link the sources to the jar (standard procedure, prepare a zip with the corresponding sources and attach it to the jar so that framework debugging is possible), but since the package names do not match I have to install/launch maven to obtain the correct package names, and repeat the procedure for each new release.
Anybody knows the rationale behind the package rename? Just asking here :)
-------------------------------------------------------------------------------------------------------------------
Este correo electrónico y, en su caso, cualquier fichero anexo al mismo, contiene información de carácter confidencial exclusivamente dirigida a su destinatario o destinatarios. Queda prohibida su divulgación, copia o distribución a terceros sin la previa autorización escrita de Indra. En el caso de haber recibido este correo electrónico por error, se ruega notificar inmediatamente esta circunstancia mediante reenvío a la dirección electrónica del remitente. POR FAVOR, ANTES DE IMPRIMIR ESTE CORREO ELECTRÓNICO CONSIDERE SU APORTACIÓN A LA CONSERVACIÓN DEL MEDIO AMBIENTE POR LA REDUCCIÓN DE CONSUMO DE PAPEL.
The information in this e-mail and in any attachments is confidential and solely for the attention and use of the named addressee(s). You are hereby notified that any dissemination, distribution or copy of this communication is prohibited without the prior written consent of Indra. If you have received this communication in error, please, notify the sender by reply e-mail. PLEASE CONSIDER YOUR ENVIRONMENTAL RESPONSIBILITY BEFORE PRINTING THIS E-MAIL.
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces-------------------------------------------------------------------------------------------------------------------
Este correo electrónico y, en su caso, cualquier fichero anexo al mismo, contiene información de carácter confidencial exclusivamente dirigida a su destinatario o destinatarios. Queda prohibida su divulgación, copia o distribución a terceros sin la previa autorización escrita de Indra. En el caso de haber recibido este correo electrónico por error, se ruega notificar inmediatamente esta circunstancia mediante reenvío a la dirección electrónica del remitente. POR FAVOR, ANTES DE IMPRIMIR ESTE CORREO ELECTRÓNICO CONSIDERE SU APORTACIÓN A LA CONSERVACIÓN DEL MEDIO AMBIENTE POR LA REDUCCIÓN DE CONSUMO DE PAPEL.
The information in this e-mail and in any attachments is confidential and solely for the attention and use of the named addressee(s). You are hereby notified that any dissemination, distribution or copy of this communication is prohibited without the prior written consent of Indra. If you have received this communication in error, please, notify the sender by reply e-mail. PLEASE CONSIDER YOUR ENVIRONMENTAL RESPONSIBILITY BEFORE PRINTING THIS E-MAIL.
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
