_Please_ don't be offended, we _do_ appreciate the work and the results of the MyFaces contributors and the whole community.
But you definitely have a release problem.
3 anecdotal examples: the ages it took from 1.0.9 to a next release, the problems introduced from a stable nightly to 1.1.0, and the ages it is taking to release 1.1.1 to replace the broken 1.1.0 (a "quick" bugfix release was planned over a month ago).
We now have 3 products deployed using MyFaces, and each is deployed using a nightly. And we are definitely not alone in this. We communicate to our clients at this time that official MyFaces releases should be avoided! Most nightlies are more stable.
Here are some humble suggestions from our experience:
1) Split the release schedules for the different parts
myfaces-api, myfaces-impl, and indeed, myfaces-shared, and tomahawk, need to be on different release tracks, and have different version numbers. You are now in a situation that one release is waiting for the other, almost in deadlock. This poses no difficulties for developers. This makes it easier for developers. This also makes it easy to make different contributors responsible for the releases and other issues of the different parts, distributing the work and responsibility.
2) Drop the combined package
This again makes releases harder, and there is no need for that. Tomahawk is a separate product anyway: it also works (or should work in the near future) with other JSF implementations. Developers will appreciate the clarity.
3) Automate the release procedure; use maven
Yes, I know this was discussed 3 months ago. But it is clear that the release procedure is manual now, that there are problems automating it. With maven, most of the work is done already, and you will be able to spend the time you spend now on duplicating maven functionality in ant, to automate the missing parts, like running the JSF compatibility tests.
4) Don't be afraid of a new release.
E.g., take 1.1.0. This release is obviously broken, and there are over 80 fixes in the repo since then already. But, no release. _Each_ of those 80 fixes warranted a new release. _Each_ of those releases would have helped a number of people that were fighting a bug in 1.1.0.
If this means that there is a new release every day, in the extreme, that's ok. If the release procedure is automatic, that doesn't take any effort, and it is feasible for developers to track progress (is my bug fixed in this release or not). Now, everybody in development is working with nightlies, which introduces terrible uncertainty which is almost impossible to defend to project managers or clients.
And it doesn't stay that way. In the first days after 1.1.0, it would have meant a daily bugfix release, yes. After a week, it would go down to a release every 3 days, and by now, we would probably have 1.1.21. That's ok. Developers _can_ count past 10.
If this goes to far for you, for bugfix releases (kudos for the separate 1.1 branch), reverse the issue: in the first weeks, set a release schedule: a new release every friday 00:00h. The fixes that are in the branch make the release, the rest is for next week. If there are blocking issues at that time, branch the branch, and fix them asap. Again, this stabilizes after a while, when there simply are no new commits in the branch since last friday. I promise it does!
Developers see the trend in the release schedule. After a while, the curve flattens, and we all know that we reached a certain stability. We don't want to use a .0 version in deployment; we know there are bugs in .0 versions of _every_ product. If we have a feeling about the release schedule, we will use earlier versions, if our deadline is far enough in the future, so you will have testers.
5) Forget the RC-approach.
For one, given the experience of the last few weeks, this approach obviously isn't
working. Just depend on the stabilising nature of frequent, consecutive bugfix releases. You will have more testers this way than with the RC's which are impossible to find (e.g., no maven repo release). I know of nobody in production that will go through the effort of working with an RC.
Again, kudos for the development work and all-round effort to the entire MyFaces team. I'm eager for the opinions on these issues of other people on the list.
On 22 Oct 2005, at 20:59, Martin Marinschek wrote:
It is a realistic scenario if you think about JBoss including MyFaces<x-tad-smaller>Met vriendelijke groeten,
(the implementation) 1.1.0 as a standard somewhere in the server - and
you want to upgrade to 1.1.1 in your webapp for the newest and best in
the tomahawk components.
regards,
Martin
On 10/22/05, Keijo Nurmes <[EMAIL PROTECTED]> wrote:
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.Met vriendelijke groeten,
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.Thanks for the segue, Martin. :-)
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 ;)
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 commons are absolute base libs, but there always is a huge
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.
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
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
--
http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German
Jan Dockx
</x-tad-smaller><x-tad-smaller>
PeopleWare NV - Head Office</x-tad-smaller><x-tad-smaller>
Cdt.Weynsstraat 85
B-2660 Hoboken
Tel: +32 3 448.33.38
Fax: +32 3 448.32.66 </x-tad-smaller><x-tad-bigger>
</x-tad-bigger><x-tad-smaller>
PeopleWare NV - Branch Office Geel</x-tad-smaller><x-tad-smaller>
Kleinhoefstraat 5
B-2440 Geel
Tel: +32 14 57.00.90
Fax: +32 14 58.13.25</x-tad-smaller><x-tad-bigger>
</x-tad-bigger><x-tad-smaller>
http://www.peopleware.be/
</x-tad-smaller><x-tad-smaller>http://www.mobileware.be/</x-tad-smaller>
smime.p7s
Description: S/MIME cryptographic signature
