It is both intuitive and automatic. you take build/build.xml and call the target dist-all. That's it.
Anyways, it would be great if someone starts introducing Maven - then we can compare and finally decide which one is better. The thing is that none of us has too much experience with Maven so far - and none of us has too much time free to be spent on release and build work right now. I agree with Jan Dockx on this - how releases work currently is painful for everyone. regards, Martin On 10/23/05, John Fallows <[EMAIL PROTECTED]> wrote: > On 10/22/05, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > what if you would prepare something like this for inclusion in the > > build process for us to try it out? > > Before I sign up for that, can you tell me how to get started actually > building MyFaces? > > It didn't seem intuitive or automatic. > > Perhaps we could have a general rework of the build to use Maven2 and > make this part of it? > > tc, > -john. > > > On 10/21/05, John Fallows <[EMAIL PROTECTED]> 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 > > > > > > > > > > > > > > > > -- > > > > 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
