Re: Discussion: Cleanup of Wiki Navigation
I have now changed the Navigation in the Wiki. Like Dan and you proposed I have restored the Mailing List and Jira Links. See: https://cwiki.apache.org/confluence/display/CXF/Navigation Greetings Christian Am 07.06.2010 23:18, schrieb Glen Mazza: Perhaps a few items can be removed from Developers (placed under subtopics), as a solid majority of CXF users will not be developing CXF so not as many top-level links are necessary. Having too many links there may also confuse people as they mistake "Developers" as Java coders using CXF instead of Java coders coding CXF directly. Agreed with Dan on the mailing lists, but also with the issues, I think that should remain a top-level item as well--it's not something you want people hunting for. Projects that keep the issue tracker listed at the top level also emphasize that they care very much about bug tracking. Glen dkulp wrote: I like all the changes EXCEPT the removal of the Mailing Lists.I really don't consider the mailing lists as a "support" thing as, at Apache, the mailing lists are a very important part of the entire community and is the primary way for people to be involved with the community. I would definitely prefer that link stays. I'm +1 for the rest of it though. :-) Dan On Saturday 05 June 2010 4:12:44 pm Christian Schneider wrote: Hi all, I think the Wiki Navigation of CXF has become a bit large. On my notebook (1600x900) it is not possible to see the whole navigation without scrolling. We currently have 38 lines of text (Headers and Links). My proposal below will only be 29 lines. I could not check if it will then fit the screen but it will surely help. So what do you think? Greetings Christian - h3. [Apache CXF|Index] - [Home|Index] - [Download] - [People] - [Project Status] - [Roadmap] - [Special Thanks] h3. Users - [User's Guide|http://cxf.apache.org/docs/index.html] - [Support] - [FAQ] - [Resources and Articles] h3. Developers - [Architecture Guide|http://cxf.apache.org/docs/cxf-architecture.html] - [Source Repository] - [Building] - [Testing-Debugging] - [Coding Guidelines] - [Getting Involved] - [Release Management] h3. Subprojects - [Distributed OSGi] - [XJC Utils] - [Build Utils] h3. ASF - [How Apache Works|http://www.apache.org/foundation/how-it-works.html] - [Foundation|http://www.apache.org/foundation/] - [Sponsor Apache|http://www.apache.org/foundation/sponsorship.html] - [Thanks|http://www.apache.org/foundation/thanks.html] -- Explanation of Changes: Reordered developers section to be in the order a new developer will probably do stuff. Deleted: Moved below support: Mailing lists Issues Moved to User´s Guide - [2.1 Migration Guide] - [2.2 Migration Guide] - [2.3 Migration Guide] Moved to developers or user´s guide: h3. API Documentation (Javadoc) - [Latest|http://cxf.apache.org/javadoc/latest/] - [Latest 2.1.x|http://cxf.apache.org/javadoc/latest-2.1.x/] - [Latest 2.0.x|http://cxf.apache.org/javadoc/latest-2.0.x/] Moved to building - [Setting up Eclipse] -- Daniel Kulp dk...@apache.org http://dankulp.com/blog -- http://www.liquid-reality.de
Re: Faster CXF builds and test ports....
OK. I've gone through pretty much all the system tests and have updated them
to use more dynamic ports. There are probably a few stragglers that I missed
and probably a couple places outside the system tests that also should use
dynamic ports (or the local transport instead), but for the most part, the
build now completely works in parallel mode.
I made one other change: it really only uses the dynamic ports when run from
Maven. When run from an IDE like eclipse, it just starts at 9000 and counts
up. Basic reason is to make it easier to debug by making it easier to find
data/traces in Wireshark and such.
Anyway, previously on my machine( Core i7 820QM, 4 cores, 8 threads), a
simple:
mvn -Pnochecks
would take about 26 minutes. (after a previous build or build done in eclipse
or something so pretty much just runs tests)
With the new stuff, I can do:
mvn -T 12 -Pnochecks
and get:
[INFO] Total time: 9:01.475s (Wall Clock)
Pretty impressive boost. :-)It definitely does a good job of keeping the
processors busy for the first 6 minutes or so. Then the various modules start
completing and what's pretty much left is the uncategorized systems tests, the
ws-* sys tests, and the jaxrs sys tests. We could even make things faster by
splitting those up some more to allow more parallelisms, but I'm pretty happy
with the results right now.:-)
Dan
On Thursday 03 June 2010 4:43:51 pm Daniel Kulp wrote:
> Actually, I discovered a better way to handle the dynamic ports:
>
> Since a LARGE LARGE majority of our tests that need ports go through the
> ClientServer infrastructure in testutils, it was fairly easy to add some
> level of dynamic port support to there.I've now converted all the
> systest/jaxws and systest/databinding tests to use dynamic ports using
> this and it seems to work fairly well.
>
> Basically, prior to calling the launchServer(...) stuff, the client makes a
> quick call to allocatePort(...) or TestUtils.getPortNumber(...) (the later
> if it doesn't subclass the ClientServerTestBase stuff) which will allocate
> the port and record it based on the information passed in. (I normally use
> the servers class as the name) In launchServer, the server that is
> forked gets all the allocated ports passed to it as system properties.
> Thus, when the server needs a port, it also calls the allocatePort thing
> using the same name and it gets back the value that the test produced.
>
> Also, since everything is stored in system properties, this works well with
> the Spring PropertyPlaceholderConfigurer. The beans.xml things that
> define the URL's can easily be updated to use the dynamic ports as well.
> Just add the configurer bean and then use something like:
>
> address="http://localhost:${testutil.ports.AegisJaxWsTest}/aegisJaxWs";
>
> to define the location.
>
> Anyway, as I mentioned, I now have all of jaxws and databinding system
> tests updated to use dynamic ports. I'll probably tackle the other
> systest things and the http-jetty transport module tomorrow. I'm not
> sure what else needs to be looked at. Probably the JMS transport.
>
> The JMS transport has another issue I'm not sure how to resolve yet.The
> jms:address extensor in the wsdl can contain the jndi url to the broker
> (jndiURL=tcp://localhost:61500) which would need to be updated somehow as
> well. I still need to figure that one out. :-(
>
>
> Dan
>
> On Thursday 03 June 2010 12:36:34 pm Daniel Kulp wrote:
> > As some of you may have noticed, I've been doing some commits to make
> > things work better with the Maven 3 betas. One reason is to achieve
> > faster builds. My new notebook has 4 cores (8 threads) and 12GB of RAM
> > and I'd like to get to a point where they are useful. :-)
> >
> > Maven 3 has a "parallel" mode (abbreviated // ) where it can build non-
> > dependent projects in parallel. That would allow better use of extra
> > cores and such. With my latest changes along with an update to the
> > Checkstyle plugin which I committed to Maven yesterday, (needs the
> > snapshot version which isn't deployed yet) I can now build CXF in //
> > mode as long as the tests are off:
> > mvn clean
> > mvn install -Dmaven.test.skip.exec=true -T 12
> >
> > The // mode cuts about a minute and a half off the install. (from 6.5
> > minutes down to 5 minutes) which is good. Subsequent "mvn
> > -Pfastinstall" builds drop from 43 seconds to 34 seconds. Also good.
> >
> > However, the real win will be if I can get the tests running in parallel
> > as well. The major problem with the tests is the port usage. We
> > pretty much use ports in the 9000-9100 range for everything with MANY
> > tests using the same ports. One reason is that we use the ports burned
> > into the wsdl's rather than overriding them as part of the test cases.
> > Thus, I'd like to start going through the tests and get them to
> > override the wsdl specified ports with unique ports
Re: Discussion: Cleanup of Wiki Navigation
Well done! Christian Schneider wrote: > > I have now changed the Navigation in the Wiki. Like Dan and you proposed > I have restored the Mailing List and Jira Links. > -- View this message in context: http://old.nabble.com/Discussion%3A-Cleanup-of-Wiki-Navigation-tp28791623p28824815.html Sent from the cxf-dev mailing list archive at Nabble.com.
[ANN] Apache CXF versions 2.2.9, 2.1.10 and 2.0.13 released
The Apache CXF team is proud to announce the availability of the latest patches for the fixes branches: 2.2.9, 2.1.10, and 2.0.13 Apache CXF is an open source services framework. CXF helps you build and develop services using front end programming APIs, like JAX-WS and JAX-RS. These services can speak a variety of protocols such as SOAP, XML/HTTP, RESTful HTTP, or CORBA and work over a variety of transports such as HTTP, JMS or JBI. These are mostly patch releases to fix problems and issues that users have encountered with over 20 JIRA issues resolved for 2.2.9. However, these patches fix a very important security vulnerability that will be publicly disclosed in the upcoming weeks. All users are STRONGLY encouraged to upgrade to these latest patches as soon as possible. Note: We've included patches for the 2.0.x and 2.1.x branches that only contain fixes for that vulnerability to make it easier for people using the older versions to migrate to a version that is safe. We don't anticipate any more updates to the 2.0.x and 2.1.x branches and strongly encourage users to upgrade to 2.2.9. For more information see: * Download: http://cxf.apache.org/download.html * Website: http://cxf.apache.org/ * Mailing lists: http://cxf.apache.org/mailing-lists.html If you have feedback, questions or would like to get involved in the CXF project please join the mailing lists and let us know your thoughts. The Apache CXF Team http://cxf.apache.org/ signature.asc Description: This is a digitally signed message part.
