Manfred, I agree the shared classes is the most important issue to focus on. I also agree -1 on repackaging them. We would live to regret that decision.
I agree that changing what's in the endorsed lib dir would fix the problem and ultimately when users have a problem with JBoss, etc. they go to the Wiki (or are referred there by our friendly user list) and realize the problem. I am leaning against the separate jar for a few reasons. One is that is makes tomahawk more cumbersome to use with the RI. Lots of people will be using the RI and now you need two jars to make it run instead of just tomahawk.jar. The second is that we are no longer consistent with the RI in terms of having just two jars for the implementation (myfaces-impl.jar and myfaces-api.jar.) Craig has lobbied strenuously for MyFaces to keep this easy to understand approach. I agree that everything is made easier if the implementations are consistent in terms of the number and naming of the jar files. Finally, compatability problems could become worse as a result of this solution instead of better. People will eventually forget to update myfaces-shared.jar and then they will be reporting bugs because they have the new tomahawk.jar but not a new myfaces-shared.jar. The problem we are trying to solve is an important one and we shouldn't give up thinking about possible solutions but so far, I haven't heard any that will make things better for the vast majority of users. sean On 10/24/05, Manfred Geiler <[EMAIL PROTECTED]> wrote: > Hi all, > This thread is a little bit overloaded with issues and suggestions in > the meantime. So I do not want to make thinks worse and only pick out > the (IMO) most important point, that really has a major impact on > future releases: the shared classes repackage issue. > Regarding shared classes: One idea or motive, that has not been > mentioned yet, is/was to have a set of convenient base classes and > utils for component development. So they actually do not only have the > purpose of reducing redundancy. They also serve as some kind of > "commons" classes for JSF. > This speaks against "tricks" like repackaging or something like that. > Releasing the shared classes in a separate jar would solve this > problem sufficiently. BTW, current releases are a bit grubby anyway: > the shared classes are currently contained in both myfaces-impl.jar > and tomahawk.jar. > Regarding JBoss: Replacing the shared classes with a newer version to > be able to use a nightly tomahawk could be solved by putting the > current "myfaces-shared.jar" into the endorsed dir, right? > > So, here is my > -1 for delivering shared classes twice in different Java namespaces > (i.e.packages) > +1 for releasing shared classes in their own jar > > Regards, > Manfred > > > 2005/10/24, Sean Schofield <[EMAIL PROTECTED]>: > > > Ok, so maybe this is the thread for these comments I have sitting on > > > for some time. > > > _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). > > > > A month is quick in Open Source development. We all have day jobs and > > we are spread out in several time zones. Each release must also pass > > the TCK which takes time. > > > > > 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. > > > > There is one important bug in the 1.1.1 release but there is an easy > > workaround. Other then that the release is very stable IMO. There > > are still lots of bugs being discovered and fixed and so depending on > > your issues, the nightly might be a better fit for you. But those > > fixes and changes can introduce new problems so I would disagree that > > the nightlies are more stable. At any point there could be serious > > new issues introduced in a nightly. > > > > But that's your call. You can do what you want and tell your clients > > whatever you want. > > > > > > > > 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. > > > > Are you crazy? How would this simplify things? We have enough > > trouble getting the combined release done. Its more then just > > executing a simple build script. > > > > > > > > > > > 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. > > > > I tend to agree with this one but others feel strongly about having > > the combined package. I don't see how this affects you if you don't > > want to use it. It doesn't really slow us down other then its one > > more jar that has to be tested, etc. Now that the sandbox is out of > > the myfaces-all.jar the process is simpler. > > > > > > > > > > > 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. > > > > Maven won't make it any easier then Ant. I don't think anyone can > > convince me of that. Maven might help slightly with the website > > publication and a few other things but we have very good Ant scripts > > that took a long time to write. At some point we can consider Maven > > but that will just delay the next release you are constantly looking > > for. Maven will be an investment that will take quite a bit of time > > and testing. > > > > As Martin said, automating the TCK is not really feasible. Believe > > me, we've automated most of what we can. Its just more complicated > > then you might realize. > > > > > > > > > > > 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. > > > > Sorry but a major -1 for this. I understand your frustration at the > > pace of the releases but nightly or weekly releases would be insane. > > I don't know of a single ASF project that does this. Ask yourself why > > this is the case? Is it because nobody has ever thought of this idea? > > Clearly not. It seems that other projects have rejected this on the > > same grounds that I have. All of your effort goes into builds and > > releases and nobody is using the same version anymore. > > > > There is a nightly build so in theory we are already releasing every > > night. What more do you need? > > > > > > > > > > > 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 -1. I don't like the RC either but people seem to hold off on > > using the nightlies and doing serious testing until we approach > > release time. If you give them an official RC they will test it > > because that is basically "last call" before the release. > > > > We're not going to do Maven repository releases for RC and if that's > > what you need to test a RC then you are out of luck. Most of us can > > test just fine without Maven. If you need Maven just create your own > > local library. > > > > The branch and RC process should increase stability of the builds. I > > think we are on the right track here. > > > > [snip] > > > > sean > > >
