Granted but is it a realistic scenario?
Does someone want to deploy in same container for example
myfaces-api.jar 1.1.0
myfaces-impl.jar 1.1.0
tomahawk.jar 1.1.1
would't it be safer just compile custom build from sources.
I dont know, newer happened to me.
It just seemed the most natural approach to the MYFACES-663 issue for me. :)
Alltogether this is not so important to me. I can live with all of
these suggestions.
How about that release number stuff in jar names.
Regards, Keijo
Martin Marinschek wrote:
It's not quite the same.
with John's approach, you can use the tomahawk library in whatever
version with whatever version of the implementation you would like to
use. Partticularly, the shared library can co-exist in two different
versions peacefully.
With Keijo's approach, you are locked in to _one_ special version of share.
regards,
Martin
On 10/22/05, ir. ing. Jan Dockx <[EMAIL PROTECTED]> wrote:
hear hear! (or is it here here? ;-) )
On 22 Oct 2005, at 12:51, Keijo Nurmes wrote:
Greetings to everyone.
There is also a third choice . One could separate shared code to its
own jar . (myfaces-shared.jar)
In that way users can decide what to use.
a) All in one
myfaces-all.jar (Contains tomahawk, impl, api, shared and optionally
sandbox)
b) Separated pure myfaces
myfaces-api.jar
myfaces-impl.jar
myfaces-shared.jar
tomahawk.jar
(sandbox.jar)
c) Tomahawk with other implementation
myfaces-shared.jar
tomahawk.jar
(sandbox.jar) other-implementation jars
If the shared code is meant to be shared in myfaces project, the
duplication is mistake. (My opinion)
Automatic repackaging always duplicates the runtime and working
with such a code is difficult
with modern IDE:s
This is already done in
http://issues.apache.org/jira/browse/MYFACES-663
I would also prefer release number added in jar-names like
myfaces-api-1.1.1RC3.jar
and I can provide patches for this. (with or without separating shared
:) )
Regards Keijo
John Fallows wrote:
Hi Everyone,
On 10/19/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
Well, if we could do b) somewhat automatically, this would be great.
John Fallows had proposed something like this for the shared classes
of Apache MyFaces - to make sure that Tomahawk and the impl always
use
the correct implementation of the shared classes.
John - I think this is the time at which you could convince us of
your
suggestion ;)
Thanks for the segue, Martin. :-)
The Apache MyFaces shared codebase is currently duplicated in both
MyFaces runtime implementation and the MyFaces Tomahawk extensions.
The major reason for duplicating is to allow the MyFaces Tomahawk
extensions to have all the classes they need when executing on a
non-MyFaces Runtime, such as the RI. Otherwise, MyFaces Tomahawk
would only run in MyFaces Runtime, which would be a non-starter.
However, since there is duplication, then upgrading either of these
(Runtime / Tomahawk) in a deployed environment independently would
cause the shared classes to be upgraded as well, for both of the
projects. This assumes the classpath is setup to place the newest JAR
last, which might not be the case. This problem leads to a "version
conflict" for the duplicated shared code.
It seems there are at least two possible resolutions to this problem.
1) repackage the shared code in each project to eliminate the impact
of independent upgrades
2) require a specific version combination of MyFaces Runtime /
MyFaces Tomahawk to ensure the same shared code is present in both
projects, making classpath ordering unimportant
As far as I know, we currently use #2. However, this places MyFaces
Runtime at an unnecessary disadvantage compared to the RI. For
example, any version of MyFaces Tomahawk can run on any version of the
RI (assuming TCK passes!) However, each version of MyFaces Tomahawk
is guaranteed to run on (and not adversely impact) exactly one version
of the MyFaces Runtime.
Therefore, I would recommend that we investigate solution #1 in the
short term to eliminate these concerns. The same approach can be
applied for other dependencies that we decide to duplicate in our
codebase as discussed in this thread.
In general, we should minimize (not eliminate) dependencies, and
(automatically?) duplicate code only when we decide that a particular
dependency has shown a track record of being sufficiently incompatible
across releases. Once that dependency stabilizes, we can stop the
duplication and establish the (now reliable) dependency.
As far as reporting dependencies is concerned, it might be useful to
deliver a built-in MyFaces ViewHandler that can serve an XML document
describing the Classpath and other useful debugging information. Then
end-users can include that information when filing issues in JIRA, or
by request on the mailing list.
Kind Regards,
John Fallows.
On 10/19/05, Werner Punz <[EMAIL PROTECTED]> wrote:
Simon Kitching wrote:
Hi guys,
Well, you should check out some of the email discussions held on
commons-dev about this. The general conclusion was that even
commons
components should avoid dependencies on other commons components
where
feasable.
Well commons are absolute base libs, but there always is a huge
issue if
you have too much deps, because other stuff has those deps as well
and
you might end up in a conflict once you try to merge myfaces into
other
subsystems. Even commons does not manage it to be outside of
commons deps.
But as others have stated, there is no sanity in having a copy
paste of
commons classes into the core codebase, because you end up in a
maintenment mess bigger than Mount Everest.
There are two ways:
a) Try to keep the number of deps as small as possible and
restricted to
the absolut core libs. Commons Lang is probably save, while
commons-httpclient would be probably a different issue.
b) Push the commons stuff into its own safe namespace so that it
does
not conflict with external namespaces of the same namespace.
(I did that recently by pushing a httpclient and its dependency
into a
supportive.org.apache.xxx namespaces)
This can be done relatively easy via refactoring tools but it is a
huge
codeupdate. Sun for instance did that as well with their own Xerces
bundle which they have bundled with JDK 5.0.
(They pushed it into sun.org.apache.xerces or something similar)
A total independence of external libs would be good bug only b)
would
allow that in a sane manner and still it is sort of a maintenance
nightmare, because with every release you have to do the refactoring
cycle all over again.
--
http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German
Met vriendelijke groeten,
Jan Dockx
PeopleWare NV - Head Office
Cdt.Weynsstraat 85
B-2660 Hoboken
Tel: +32 3 448.33.38
Fax: +32 3 448.32.66
PeopleWare NV - Branch Office Geel
Kleinhoefstraat 5
B-2440 Geel
Tel: +32 14 57.00.90
Fax: +32 14 58.13.25
http://www.peopleware.be/
http://www.mobileware.be/
--
http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German
