Best unofficial Apache Server developers community |
Release candidate for 2.1.1-unstable (dev release)
| |||||
| Jun 2, 2010 | |||||
 Leif Hedstrom |
|
||||
| Tags: | |||||
Similar Threads
Re: ANNOUNCE: Puppet 2.6.0 - Release Candidate 1 available!
2010/7/10 Jesús M. Navarro <jesus.### @andago.com> Hi: On Saturday 10 July 2010 19:11:12 Patrick Mohr wrote: > On Jul 10, 2010, at 7:57 AM, Peter Meier wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 07/10/2010 04:54 PM, Patrick Mohr wrote: > >> On Jul 9, 2010, at 11:58 PM, James Turnbull wrote: > >>> Certificates cleaned with puppetca (or puppet cert) are now also > >>> revoked. > >> > >> Is there some way to clean a cert (using puppet cert) without > >> revoking it? Something like "puppet cert --clean hostname.domain > >> --no-revoke". > > > > afaik, not. But could be a feature request. On the other hand, what's > > the use case? > > This isn't my usecase so I don't care, but since you ask... > > Suppose you have machines that: > *) Don't get any sensitive information through puppet. > *) Are re-imaged often using PXE+preseeding or PXE+kickstart > *) All the computers have names in the form of "lab-client-*.domainname" > > Someone said that in this case you can put "puppetca --clean > lab-client-*.domainname" as a cron job, and put "lab-client-*.domainname" > in autosign.conf. > > Again, I don't do this, so don't do it for me. I don't see that to be a use case in need of a "no-revoke" option. Once you delete the old machine and re-image it with "PXE+preseeding or PXE+kickstart" it won't get the old certkey so it'll need to be resigned anyway: to all practical purposes it's a new machine, so no benefit on not revoking the old one. But I was saying clean out all client certs and private keys (for clients in this group) off the server once per hour. Meaning you are running clean while the client exists and has a valid cert/key combo. I guess you would always do the same thing with two "rm" statements in the cron job instead.
Re: Re: ANNOUNCE: Puppet 2.6.0 - Release Candidate 2 available!
OK, will start filing bugs right now..
First bug filed, still 2 more questions before I will file more bugs
since I'm not to sure it's by design or a bug.
1) Do external nodes don't accept parameters anymore? (Not a big deal
for us since we are deprecating those anyway but still different
behavior)
Master error:
err: Failed when searching for node cs-ops001b.intern.marktplaats.nl:
undefined method `parameters=' for #<Puppet::Node:0xb6f2b8ac>
Client error:
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Failed when searching for node
cs-ops001b.intern.marktplaats.nl: undefined method `parameters=' for
#<Puppet::Node:0xb6f2b8ac>
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
Stripped YAML Output:
--- %YAML:1.0
"classes": ["cs-ops"]
"parameters":
"cmdb_generated": 1
"company": "CustomerSupport"
"vendor": "Dell"
2) In the output of the client when using puppetd --test I see more
output then previous versions, for example:
cs-ops001b:/home/seedpimp/rc3# puppetd --test
info: Retrieving plugin
info: /File[/var/lib/puppet/lib]: Setting mode to 493
info: /File[/var/lib/puppet/lib]: Storing newly-audited value for content
info: /File[/var/lib/puppet/lib/facter]: Setting mode to 493
info: /File[/var/lib/puppet/lib/facter/conterm.rb]: Setting mode to 420
info: /File[/var/lib/puppet/lib/facter/conterm.rb]: Setting content to
{md5}2d189bceaac522ae1f78d171b8e45531
info: Loading facts in conterm
info: Loading facts in conterm
info: Caching catalog for cs-ops001b.intern.marktplaats.nl
info: Applying configuration version 'ref="refs/heads/master"
commit=212f99a4bce8f2b9edc5254d05d16573a2a84057'
info: /Stage[main]/Nginx/File[/etc/nginx/nginx.conf]: Setting content
to {md5}481ca4ffd65e9c8ae3268b38cfaabfa2
info: /Stage[main]/Nginx/File[/etc/nginx/cert.key]: Setting content to
{md5}9351a9b772c885c8e295541fe11a1c04
info: /Stage[main]/Nginx/File[/etc/nginx/cert.pem]: Setting content to
{md5}48bad668bd52b934aaa7be007be55ead
info: /Stage[main]/Nginx/File[/etc/nginx/sites-available/nginx_status]:
Setting content to {md5}9b3770d588ff756612471634ecf7c1e2
info: /Stage[main]/Cacti/File[/var/cache/debconf/cacti.seed]: Setting
content to {md5}71d829ca1c120c8c98a45299941f6af6
info: /Stage[main]/Nscd/File[/etc/nscd.conf]: Setting content to
{md5}2e06eeb94b8fe8085d8cbd0af118f93e
info: /Stage[main]/Nginx/File[/etc/nginx/sites-available/default]:
Setting content to {md5}e732b889d790c1000c3a1c1c39be000
Those Setting content to lines keep returning every run, and are
exactly the same.
ANNOUNCE: Puppet 2.6.0 - Release Candidate 4 available!
Welcome back again to the Puppet release cycle with really truly next to final release candidate 4. The 2.6.0 release is a major feature release and includes a huge variety of new features, fixes, updates and enhancements. These include the complete cut-over from XMLRPC to the REST API, numerous language enhancements, a complete rewrite of the events and reporting system, an internal Ruby DSL, a single binary, Windows support, a new HTTP report processor, and a myriad of other enhancements. As a result of the bucket-load of new features and enhancements we also need lots of help testing it. Please run up the release candidate in your test environment or using VMs and test it as extensively as possible. We've include release notes below that you can also see at: http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes" rel="nofollow" target="_blank">http://projects.puppetlabs.com/projec...iki/Release_Notes The release candidate is available for download at: http://puppetlabs.com/downloads/puppe...t-2.6.0rc4.tar.gz Please note that all final releases of Puppet are signed with the Puppet Labs key (we'll sign the production release with the new, improved Puppet Labs key). See the Verifying Puppet Download section at http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet" rel="nofollow" target="_blank">http://projects.puppetlabs.com/projec...ownloading_Puppet Please test this release candidate and report feedback via the Puppet Labs Redmine site: http://projects.puppetlabs.com Please select an affected version of 2.6.0rc4. RELEASE NOTES Language Support for parameterised classes The 2.6.0 release provides an extension to the existing class syntax to allow parameters to be passed to classes. This brings classes more in line with definitions, with the significant difference that definitions have multiple instances whilst classes remain singletons. To create a class with parameters you can now specify: class apache($version) { ... class contents ... } Classes with parameters are NOT added using the include function but rather the resulting class can then be included more like a definition: node webserver { class { apache: version => "1.3.13" } } Like definitions, you can also specify default parameter values in your class like so: class apache($version="1.3.13",$home="/var/www") { ... class contents ... } New relationship syntax You can now specify relationships directly in the language: File[/foo] -> Service[bar] Specifies a normal dependency while: File[/foo] ~> Service[bar] Specifies a subscription. You can also do relationship chaining, specifying multiple relationships on a single line: File[/foo] -> Package[baz] -> Service[bar] Note that while it’s confusing, you don’t have to have all of the arrows be the same direction: File[/foo] -> Service[bar] <~ Package[baz] This can provide some succinctness at the cost of readability. You can also specify full resources, rather than just resource references: file { "/foo": ensure => present } -> package { bar: ensure => installed } But wait! There’s more! You can also specify a subscription on either side of the relationship marker: yumrepo { foo: .... } package { bar: provider => yum, ... } Yumrepo <| |> -> Package <| provider == yum |> This, finally, provides easy many to many relationships in Puppet, but it also opens the door to massive dependency cycles. This last feature is a very powerful stick, and you can considerably hurt yourself with it. Run Stages Run Stages are a way for you to provide coarse-grained ordering in your manifests without having to specify relationships to every resource you want in a given order. It’s most useful for setup work that needs to be done before the vast majority of your catalog even works – things like configuring yum repositories so your package installs work. Run Stages are currently (intentionally) a bit limited – you can only put entire classes into a run stage, you can’t put individual resources there. There’s a main stage that resources all exist in by default; if you don’t use run stages, everything’s in this, but it doesn’t matter to you. You can define new stages via the new stage resource type: stage { pre: before => Stage[main] } Here we’ve used the before metaparameter but you could also use after, require, etc to establish the necessary relationships between stages. Now you just specify that your class belongs in your new run stage: class yum { ... } class redhat { ... class { yum: stage => pre } } This will make sure that all of the resources in the yum are applied before the main stage is applied. Note that we’re using the new parameterized classes here – this is necessary because of the class-level limitations of Run Stages. These limitations are present because of the complication of trying to untangle resource dependencies across stage boundaries if we allowed arbitrary resources to specify stages. On a related note, if you specify a stage for a given class, you should specify as few as possible explicit relationships to or from that class. Otherwise you risk a greater chance of dependency cycles. This can all be visualized relatively easily using the —graph option to puppetd and opening the graphs in OmniGraffle or GraphViz. Specifying the ordering of Run Stages also works much better when specified using the new relationship syntax, too: stage { [pre, post]: } Stage[pre] -> Stage[main] -> Stage[post] This way it’s very easy to see at a glance exactly how the stages are ordered. Support for hashes in the DSL This brings a new container syntax to the Puppet DSL: hashes. Hashes are defined like Ruby Hashes: { key1 => val1, ... } The Hash keys are strings but hash values can be any possible right values admitted in Puppet DSL (i.e. a function call or a variable) Currently it is possible: * to assign hashes to a variable $myhash = { key1 => "myval", key2 => $b } * to access hash members (recursively) from a variable containing a hash (works for array too): $myhash = { key => { subkey => "b" }} notice($myhash[key][subkey]] * to use hash member access as resource title * to use hash in default definition parameter or resource parameter if the type supports it (known for the moment). It is not possible to use an hash as a resource title. This might be possible once we support compound resource title. Support for an elsif syntax Allows use of an elsif construct: if $server == 'mongrel' { include mongrel } elsif $server == 'nginx' { include nginx } else { include thin } Case and Selectors now support undef The case and selector statements now support the undef syntax (see #2818). Pure Ruby Manifests Puppet now supports pure Ruby manifests as equivalent to Puppet’s custom language. That is, you can now have Ruby programs along side your Puppet manifests. As is our custom, it’s a limited first version, but it covers most of the specification functionality of the current language. For instance, here’s a simple ssh class: hostclass :ssh do package "ssh", :ensure => :present file "/etc/ssh/sshd_config", :source => "puppet:///ssh/sshd_config", :require => "Package[ssh]" service :sshd, :ensure => :running, :require => "File[/etc/ssh/sshd_config]" end Similar to the ‘hostclass’ construct here, you can specify defined resource types: define "apache::vhost", :ip, :docroot, :modperl => false do file "/etc/apache2/sites-enabled/#{@name}.conf", :content => template("apache/vhost.erb") end As you can see from this code, the parameters for the resources become instance variables inside of the defined resource types (and classes, now that we support parameterized classes). We can do nodes, too: node “mynode” do include “apache” end Ruby has become a first-class citizen alongside the existing external DSL. That means anywhere you can put a manifest, you should be able to put Ruby code and have it behave equivalently. So, the ‘ssh’ class above could be put into ‘$modules/ssh/manifests/init.rb’, the apache vhost type should be placed in ‘$modules/apache/manifests/vhost.rb’, and the node should probably be in your ‘site.pp’ file. You can also apply Ruby manifests directly with puppet: puppet -e mystuff.rb Note that the Ruby support does not yet cover all of the functionality in Puppet’s language. For instance, there is not yet support for overrides or defaults, nor for resource collections. Virtual and exported resources are done using a separate method: virtual file("/my/file", :content => "something") All of the standard functions are also pulled into Ruby and should work fine — e.g., ‘include’, ‘template’, and ‘require’. Stored Configuration Support is now added for using Oracle databases as a back-end for your stored configuration. Facts There are three new facts available in manifests: $clientcert – the name of the client certificate $module_name – the name of the current module (see #1545) $caller_module_name – the name of the calling module (see #1545) In addition all puppet.conf configuration items are now available as facts in your manifests. These can be accessed using the structure: $settings::setting_name Where setting_name is the name of the configuration option you’d like to retrieve. Types and Providers A new provider for pkg has been added to support Solaris and OpenSolaris (pkgadd). A new package provider has been added to support AIX package management. The augeas type has added the ‘incl’ and ‘lens’ parameters. These parameters allow loading a file anywhere on the filesystem; using them also greatly speeds up processing the resource. Binaries and Configuration Single Binary Puppet is now available as a single binary with sub-arguments for the functions previously provided by the seperate binaries (the existing binaries remain for backwards compatibility). This includes renaming several Puppet functions to better fit an overall model. List of binary changes puppetmasterd –> puppet master puppetd –> puppet agent puppet –> puppet apply puppetca –> puppet cert ralsh –> puppet resource puppetrun –> puppet kick puppetqd –> puppet queue filebucket –> puppet filebucket puppetdoc –> puppet doc pi –> puppet describe This also results in a change in the puppet.conf configuration file. The sections, previously things like [puppetd], now should be renamed to match the new binary names. So [puppetd] becomes [agent]. You will be prompted to do this when you start Puppet with a log message for each section that needs to be renamed. This is merely a warning - existing configuration file will work unchanged. New options A new option is available, ca_name, to specify the name to use for the Certificate Authority certificate. It defaults to the value of the certname option (see http://projects.reductivelabs.com/issues/1507). A new option, dbconnections, is now available that specifies a limit for the number of database connections made to remote databases (postgreSQL, MySQL). A new option, dbport, is now available that specifies the database port for remote database connections. There’s also a new option/feature that lets the puppet client use HTTP compression (—http_compression): Allow http compression in REST communication with the master. This setting might improve performance for agent –> master communications over slow WANs. Your puppetmaster needs to support compression (usually by activating some settings in a reverse-proxy in front of the puppetmaster, which rules out webrick). It is harmless to activate this settings if your master doesn’t support compression, but if it supports it, this setting might reduce on high-speed LANs. Binary changes The puppetd (or puppet agent) binary now supports the --detailed-exitcodes option available in the puppet binary. Certificates cleaned with puppetca (or puppet cert) are now also revoked. The puppetca (puppet cert) and puppetd (puppet agent) binaries now have support for certificate fingerprinting and support for specifying digest algorithms. To display the fingerprint of a client certificate use: $ puppetd --fingerprint or $ puppet agent --fingerprint To specify a particular digest algorithm use --digest DIGESTNAME. To fingerprint a certificate with puppetca use: $ puppetca --fingerprint host.example.com or $ puppet cert --fingerprint host.example.com Also supported is the --digest option. The puppetdoc binary now documents inheritance between nodes, shows classes added via the require function and resources added via the realize function. Functions The regsubst function now takes arrays as input (see #2491). Reports There is a new report type called http. If you specify: reports = http Then the new report processor will make a HTTP POST of the report in YAML format to a specified URL. By default this URL is the report import URL for a local Puppet Dashboard installation. You can override this with the new reporturl setting. reports = http reporturl = http://yoururl/post/ CHANGELOG since RC3 cf597d7 [#4233] Ruby regexps are not multiline by default, but Resource titles can be multilined6cbb21 Fix for #4234 -- ruby DSL fails on second resource 4822de3 Fix for #4236 -- Only interpolate $ if followed by a variable b509032 Fix #4238 - if should match undef as '' 8c8c146 Minimal fix for #4243 -- import isn't thread safe d319da4 [#4247] storeconfigs was calling Puppet::Parser::Resource.new with the wrong arguments 9f91540 [#4256] External nodes parameters can now be assigned to nodes 680dd1a Fix for #4257 -- problems resolving ::-prefixed classes 6e07a19 Fix #4262 - Puppetmaster used to log compilation time 5b68afe Fix for #4255 -- misleading diagnostic message dd03ac9 Partial fix for #4278 -- the performance aspects 4ce33fd Fixed #4249 - Updated SUSE packaging specifications 91185c6 New man pages for 2.6.0 1cda7c5 Fixes errant Trac references in documentation Regards James Turnbull -- Puppet Labs - http://www.puppetlabs.com C: 503-734-8571
ANNOUNCE: Puppet 2.6.0 - Release Candidate 3 available!
Welcome back again to the Puppet release cycle with the just out of the gate release candidate 3. The 2.6.0 release is a major feature release and includes a huge variety of new features, fixes, updates and enhancements. These include the complete cut-over from XMLRPC to the REST API, numerous language enhancements, a complete rewrite of the events and reporting system, an internal Ruby DSL, a single binary, Windows support, a new HTTP report processor, and a myriad of other enhancements. As a result of the bucket-load of new features and enhancements we also need lots of help testing it. Please run up the release candidate in your test environment or using VMs and test it as extensively as possible. We've include release notes below that you can also see at: http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes" rel="nofollow" target="_blank">http://projects.puppetlabs.com/projec...iki/Release_Notes The release candidate is available for download at: http://puppetlabs.com/downloads/puppe...t-2.6.0rc3.tar.gz Please note that all final releases of Puppet are signed with the Puppet Labs key (we'll sign the production release with the new, improved Puppet Labs key). See the Verifying Puppet Download section at http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet" rel="nofollow" target="_blank">http://projects.puppetlabs.com/projec...ownloading_Puppet Please test this release candidate and report feedback via the Puppet Labs Redmine site: http://projects.puppetlabs.com Please select an affected version of 2.6.0rc3. RELEASE NOTES Language Support for parameterised classes The 2.6.0 release provides an extension to the existing class syntax to allow parameters to be passed to classes. This brings classes more in line with definitions, with the significant difference that definitions have multiple instances whilst classes remain singletons. To create a class with parameters you can now specify: class apache($version) { ... class contents ... } Classes with parameters are NOT added using the include function but rather the resulting class can then be included more like a definition: node webserver { class { apache: version => "1.3.13" } } Like definitions, you can also specify default parameter values in your class like so: class apache($version="1.3.13",$home="/var/www") { ... class contents ... } New relationship syntax You can now specify relationships directly in the language: File[/foo] -> Service[bar] Specifies a normal dependency while: File[/foo] ~> Service[bar] Specifies a subscription. You can also do relationship chaining, specifying multiple relationships on a single line: File[/foo] -> Package[baz] -> Service[bar] Note that while it’s confusing, you don’t have to have all of the arrows be the same direction: File[/foo] -> Service[bar] <~ Package[baz] This can provide some succinctness at the cost of readability. You can also specify full resources, rather than just resource references: file { "/foo": ensure => present } -> package { bar: ensure => installed } But wait! There’s more! You can also specify a subscription on either side of the relationship marker: yumrepo { foo: .... } package { bar: provider => yum, ... } Yumrepo <| |> -> Package <| provider == yum |> This, finally, provides easy many to many relationships in Puppet, but it also opens the door to massive dependency cycles. This last feature is a very powerful stick, and you can considerably hurt yourself with it. Run Stages Run Stages are a way for you to provide coarse-grained ordering in your manifests without having to specify relationships to every resource you want in a given order. It’s most useful for setup work that needs to be done before the vast majority of your catalog even works – things like configuring yum repositories so your package installs work. Run Stages are currently (intentionally) a bit limited – you can only put entire classes into a run stage, you can’t put individual resources there. There’s a main stage that resources all exist in by default; if you don’t use run stages, everything’s in this, but it doesn’t matter to you. You can define new stages via the new stage resource type: stage { pre: before => Stage[main] } Here we’ve used the before metaparameter but you could also use after, require, etc to establish the necessary relationships between stages. Now you just specify that your class belongs in your new run stage: class yum { ... } class redhat { ... class { yum: stage => pre } } This will make sure that all of the resources in the yum are applied before the main stage is applied. Note that we’re using the new parameterized classes here – this is necessary because of the class-level limitations of Run Stages. These limitations are present because of the complication of trying to untangle resource dependencies across stage boundaries if we allowed arbitrary resources to specify stages. On a related note, if you specify a stage for a given class, you should specify as few as possible explicit relationships to or from that class. Otherwise you risk a greater chance of dependency cycles. This can all be visualized relatively easily using the —graph option to puppetd and opening the graphs in OmniGraffle or GraphViz. Specifying the ordering of Run Stages also works much better when specified using the new relationship syntax, too: stage { [pre, post]: } Stage[pre] -> Stage[main] -> Stage[post] This way it’s very easy to see at a glance exactly how the stages are ordered. Support for hashes in the DSL This brings a new container syntax to the Puppet DSL: hashes. Hashes are defined like Ruby Hashes: { key1 => val1, ... } The Hash keys are strings but hash values can be any possible right values admitted in Puppet DSL (i.e. a function call or a variable) Currently it is possible: * to assign hashes to a variable $myhash = { key1 => "myval", key2 => $b } * to access hash members (recursively) from a variable containing a hash (works for array too): $myhash = { key => { subkey => "b" }} notice($myhash[key][subkey]] * to use hash member access as resource title * to use hash in default definition parameter or resource parameter if the type supports it (known for the moment). It is not possible to use an hash as a resource title. This might be possible once we support compound resource title. Support for an elsif syntax Allows use of an elsif construct: if $server == 'mongrel' { include mongrel } elsif $server == 'nginx' { include nginx } else { include thin } Case and Selectors now support undef The case and selector statements now support the undef syntax (see #2818). Pure Ruby Manifests Puppet now supports pure Ruby manifests as equivalent to Puppet’s custom language. That is, you can now have Ruby programs along side your Puppet manifests. As is our custom, it’s a limited first version, but it covers most of the specification functionality of the current language. For instance, here’s a simple ssh class: hostclass :ssh do package "ssh", :ensure => :present file "/etc/ssh/sshd_config", :source => "puppet:///ssh/sshd_config", :require => "Package[ssh]" service :sshd, :ensure => :running, :require => "File[/etc/ssh/sshd_config]" end Similar to the ‘hostclass’ construct here, you can specify defined resource types: define "apache::vhost", :ip, :docroot, :modperl => false do file "/etc/apache2/sites-enabled/#{@name}.conf", :content => template("apache/vhost.erb") end As you can see from this code, the parameters for the resources become instance variables inside of the defined resource types (and classes, now that we support parameterized classes). We can do nodes, too: node “mynode” do include “apache” end Ruby has become a first-class citizen alongside the existing external DSL. That means anywhere you can put a manifest, you should be able to put Ruby code and have it behave equivalently. So, the ‘ssh’ class above could be put into ‘$modules/ssh/manifests/init.rb’, the apache vhost type should be placed in ‘$modules/apache/manifests/vhost.rb’, and the node should probably be in your ‘site.pp’ file. You can also apply Ruby manifests directly with puppet: puppet -e mystuff.rb Note that the Ruby support does not yet cover all of the functionality in Puppet’s language. For instance, there is not yet support for overrides or defaults, nor for resource collections. Virtual and exported resources are done using a separate method: virtual file("/my/file", :content => "something") All of the standard functions are also pulled into Ruby and should work fine — e.g., ‘include’, ‘template’, and ‘require’. Stored Configuration Support is now added for using Oracle databases as a back-end for your stored configuration. Facts There are three new facts available in manifests: $clientcert – the name of the client certificate $module_name – the name of the current module (see #1545) $caller_module_name – the name of the calling module (see #1545) In addition all puppet.conf configuration items are now available as facts in your manifests. These can be accessed using the structure: $settings::setting_name Where setting_name is the name of the configuration option you’d like to retrieve. Types and Providers A new provider for pkg has been added to support Solaris and OpenSolaris (pkgadd). A new package provider has been added to support AIX package management. The augeas type has added the ‘incl’ and ‘lens’ parameters. These parameters allow loading a file anywhere on the filesystem; using them also greatly speeds up processing the resource. Binaries and Configuration Single Binary Puppet is now available as a single binary with sub-arguments for the functions previously provided by the seperate binaries (the existing binaries remain for backwards compatibility). This includes renaming several Puppet functions to better fit an overall model. List of binary changes puppetmasterd –> puppet master puppetd –> puppet agent puppet –> puppet apply puppetca –> puppet cert ralsh –> puppet resource puppetrun –> puppet kick puppetqd –> puppet queue filebucket –> puppet filebucket puppetdoc –> puppet doc pi –> puppet describe This also results in a change in the puppet.conf configuration file. The sections, previously things like [puppetd], now should be renamed to match the new binary names. So [puppetd] becomes [agent]. You will be prompted to do this when you start Puppet with a log message for each section that needs to be renamed. This is merely a warning - existing configuration file will work unchanged. New options A new option is available, ca_name, to specify the name to use for the Certificate Authority certificate. It defaults to the value of the certname option (see http://projects.reductivelabs.com/issues/1507). A new option, dbconnections, is now available that specifies a limit for the number of database connections made to remote databases (postgreSQL, MySQL). A new option, dbport, is now available that specifies the database port for remote database connections. There’s also a new option/feature that lets the puppet client use HTTP compression (—http_compression): Allow http compression in REST communication with the master. This setting might improve performance for agent –> master communications over slow WANs. Your puppetmaster needs to support compression (usually by activating some settings in a reverse-proxy in front of the puppetmaster, which rules out webrick). It is harmless to activate this settings if your master doesn’t support compression, but if it supports it, this setting might reduce on high-speed LANs. Binary changes The puppetd (or puppet agent) binary now supports the --detailed-exitcodes option available in the puppet binary. Certificates cleaned with puppetca (or puppet cert) are now also revoked. The puppetca (puppet cert) and puppetd (puppet agent) binaries now have support for certificate fingerprinting and support for specifying digest algorithms. To display the fingerprint of a client certificate use: $ puppetd --fingerprint or $ puppet agent --fingerprint To specify a particular digest algorithm use --digest DIGESTNAME. To fingerprint a certificate with puppetca use: $ puppetca --fingerprint host.example.com or $ puppet cert --fingerprint host.example.com Also supported is the --digest option. The puppetdoc binary now documents inheritance between nodes, shows classes added via the require function and resources added via the realize function. Functions The regsubst function now takes arrays as input (see #2491). Reports There is a new report type called http. If you specify: reports = http Then the new report processor will make a HTTP POST of the report in YAML format to a specified URL. By default this URL is the report import URL for a local Puppet Dashboard installation. You can override this with the new reporturl setting. reports = http reporturl = http://yoururl/post/ CHANGELOG since RC2 9df87e9 [#4219] Install misses command_line dir, puppet $app --help fails 0422852 conf/redhat: Consistently pass pidfile option to daemon, killproc, and status 63bf037 conf/redhat: Update conf/init files for single binary f72741f conf/redhat: Rebase rundir-perms patch 793d7b7 [#4213] -o option for setting onetime now works properly 2edf7fe [#3656] Serializing arrays of references 27d5a47 [#4215] Have rundir depend on vardir 06cc552 Fix for #4220 -- modules not implicitly loading their init files Regards James Turnbull -- Puppet Labs - http://www.puppetlabs.com C: 503-734-8571
ANNOUNCE: Puppet 2.6.1 - Release Candidate 1 available!
In the long Puppet tradition of fast releases and agile iteration comes the 2.6.1 release! The first release candidate is now available and is a maintenance release in the 2.6.x branch. It contains a number of functional and performance enhancements including preliminary support for running Puppet under JRuby (thanks Brice!). We've include release notes below that you can also see at: http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes" rel="nofollow" target="_blank">http://projects.puppetlabs.com/projec...iki/Release_Notes The release candidate is available for download at: http://puppetlabs.com/downloads/puppe...t-2.6.1rc1.tar.gz Please note that all final releases of Puppet are signed with the Puppet Labs key. See the Verifying Puppet Download section at http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet" rel="nofollow" target="_blank">http://projects.puppetlabs.com/projec...ownloading_Puppet Please test this release candidate and report feedback via the Puppet Labs Redmine site: http://projects.puppetlabs.com Please select an affected version of 2.6.1rc1. RELEASE NOTES Added R.I. Pienaar's extlookup function (see release notes for documentation). We'll add JSON and YAML back-ends to the CSV back-ends in future releases. Added preliminary JRuby support Added ext/puppet-load - a tool for testing master compilation speeds Minor supporting fixes including updated VIM syntax, SuSE packaging, Passenger configuration and Red Hat Spec file amongst others. CHANGELOG since 2.6.0 bdfcac5 Update Red Hat spec file for 2.6.0 9f08e7c Feature: puppet-load - a tool to stress-test master compilation ef9a4a6 Fix #4245 - default insertion of ACL is not thread safe 4065e81 Fix race condition in rack autoloading of request/response 3163932 Fix #4244 - Cached Attributes is not thread safe 7d42f77 JRuby doesn't implement Process.maxgroups 760e418 Fix #4349 - Parsing with ignoreimport=true was always loading site.pp 67bdf89 Fix #4348 - Puppet doc single manifest broken 13c71b9 extlookup() is a builtin d38e522 [#4333] old optparse doesn't support default_argv= 86b0882 Fixed #4326 - Updated SUSE packaging 03313b8 Fix #4319 - source file url sent to the master is invalid ac3a0d2 vim: highlight default parameters in definition/classes be2141a vim: match collected resources. c047c8d vim: added elsif 9569136 Fix for 4314 -- Need to allow '-' in class name for refs 636079f Fixed #4304 - Changed logging level for auto import message 000fd1e Fix for #4303 -- reverting to old escaping in '-strings 1d494a3 Tweak to fix for #4302--dangling ref to known_resource_types 2383050 Fix #4302 - Compilation speed regression compared to 2.6 63ec207 Minimal fix for #4297, with notes for follow-up 7ad7eb1 Fix #4286 - rename puppetdoc global module <site> to __site__ 28bb195 Fixed yumrepo type deprecation wanring ` 067a46d Temporary tweak to tests for #4242 9778f2a [#4242] Fixed recursion due to parents including their children 59a23d6 Fix for #3382 -- Empty classes as graph placeholders 865282a Fixed example config.ru a0a63c3 Fixed network and indirection reference 64386cf Fixed Indirection reference Regards James Turnbull -- Puppet Labs - http://www.puppetlabs.com C: 503-734-8571
ANNOUNCE: Puppet 2.6.0 - Release Candidate 2 available!
Welcome back again to the Puppet release cycle with the long-awaited eleventy times better RC2 release. The 2.6.0 release is a major feature release and includes a huge variety of new features, fixes, updates and enhancements. These include the complete cut-over from XMLRPC to the REST API, numerous language enhancements, a complete rewrite of the events and reporting system, an internal Ruby DSL, a single binary, Windows support, a new HTTP report processor, and a myriad of other enhancements. As a result of the bucket-load of new features and enhancements we also need lots of help testing it. Please run up the release candidate in your test environment or using VMs and test it as extensively as possible. We've include release notes below that you can also see at: http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes" rel="nofollow" target="_blank">http://projects.puppetlabs.com/projec...iki/Release_Notes The release candidate is available for download at: http://puppetlabs.com/downloads/puppe...t-2.6.0rc2.tar.gz Please note that all final releases of Puppet are signed with the Puppet Labs key (we'll sign the production release with the new, improved Puppet Labs key). See the Verifying Puppet Download section at http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet" rel="nofollow" target="_blank">http://projects.puppetlabs.com/projec...ownloading_Puppet Please test this release candidate and report feedback via the Puppet Labs Redmine site: http://projects.puppetlabs.com Please select an affected version of 2.6.0rc2. RELEASE NOTES Language Support for parameterised classes The 2.6.0 release provides an extension to the existing class syntax to allow parameters to be passed to classes. This brings classes more in line with definitions, with the significant difference that definitions have multiple instances whilst classes remain singletons. To create a class with parameters you can now specify: class apache($version) { ... class contents ... } Classes with parameters are NOT added using the include function but rather the resulting class can then be included more like a definition: node webserver { class { apache: version => "1.3.13" } } Like definitions, you can also specify default parameter values in your class like so: class apache($version="1.3.13",$home="/var/www") { ... class contents ... } New relationship syntax You can now specify relationships directly in the language: File[/foo] -> Service[bar] Specifies a normal dependency while: File[/foo] ~> Service[bar] Specifies a subscription. You can also do relationship chaining, specifying multiple relationships on a single line: File[/foo] -> Package[baz] -> Service[bar] Note that while it’s confusing, you don’t have to have all of the arrows be the same direction: File[/foo] -> Service[bar] <~ Package[baz] This can provide some succinctness at the cost of readability. You can also specify full resources, rather than just resource references: file { "/foo": ensure => present } -> package { bar: ensure => installed } But wait! There’s more! You can also specify a subscription on either side of the relationship marker: yumrepo { foo: .... } package { bar: provider => yum, ... } Yumrepo <| |> -> Package <| provider == yum |> This, finally, provides easy many to many relationships in Puppet, but it also opens the door to massive dependency cycles. This last feature is a very powerful stick, and you can considerably hurt yourself with it. Run Stages Run Stages are a way for you to provide coarse-grained ordering in your manifests without having to specify relationships to every resource you want in a given order. It’s most useful for setup work that needs to be done before the vast majority of your catalog even works – things like configuring yum repositories so your package installs work. Run Stages are currently (intentionally) a bit limited – you can only put entire classes into a run stage, you can’t put individual resources there. There’s a main stage that resources all exist in by default; if you don’t use run stages, everything’s in this, but it doesn’t matter to you. You can define new stages via the new stage resource type: stage { pre: before => Stage[main] } Here we’ve used the before metaparameter but you could also use after, require, etc to establish the necessary relationships between stages. Now you just specify that your class belongs in your new run stage: class yum { ... } class redhat { ... class { yum: stage => pre } } This will make sure that all of the resources in the yum are applied before the main stage is applied. Note that we’re using the new parameterized classes here – this is necessary because of the class-level limitations of Run Stages. These limitations are present because of the complication of trying to untangle resource dependencies across stage boundaries if we allowed arbitrary resources to specify stages. On a related note, if you specify a stage for a given class, you should specify as few as possible explicit relationships to or from that class. Otherwise you risk a greater chance of dependency cycles. This can all be visualized relatively easily using the —graph option to puppetd and opening the graphs in OmniGraffle or GraphViz. Specifying the ordering of Run Stages also works much better when specified using the new relationship syntax, too: stage { [pre, post]: } Stage[pre] -> Stage[main] -> Stage[post] This way it’s very easy to see at a glance exactly how the stages are ordered. Support for hashes in the DSL This brings a new container syntax to the Puppet DSL: hashes. Hashes are defined like Ruby Hashes: { key1 => val1, ... } The Hash keys are strings but hash values can be any possible right values admitted in Puppet DSL (i.e. a function call or a variable) Currently it is possible: * to assign hashes to a variable $myhash = { key1 => "myval", key2 => $b } * to access hash members (recursively) from a variable containing a hash (works for array too): $myhash = { key => { subkey => "b" }} notice($myhash[key][subkey]] * to use hash member access as resource title * to use hash in default definition parameter or resource parameter if the type supports it (known for the moment). It is not possible to use an hash as a resource title. This might be possible once we support compound resource title. Support for an elsif syntax Allows use of an elsif construct: if $server == 'mongrel' { include mongrel } elsif $server == 'nginx' { include nginx } else { include thin } Case and Selectors now support undef The case and selector statements now support the undef syntax (see #2818). Pure Ruby Manifests Puppet now supports pure Ruby manifests as equivalent to Puppet’s custom language. That is, you can now have Ruby programs along side your Puppet manifests. As is our custom, it’s a limited first version, but it covers most of the specification functionality of the current language. For instance, here’s a simple ssh class: hostclass :ssh do package "ssh", :ensure => :present file "/etc/ssh/sshd_config", :source => "puppet:///ssh/sshd_config", :require => "Package[ssh]" service :sshd, :ensure => :running, :require => "File[/etc/ssh/sshd_config]" end Similar to the ‘hostclass’ construct here, you can specify defined resource types: define "apache::vhost", :ip, :docroot, :modperl => false do file "/etc/apache2/sites-enabled/#{@name}.conf", :content => template("apache/vhost.erb") end As you can see from this code, the parameters for the resources become instance variables inside of the defined resource types (and classes, now that we support parameterized classes). We can do nodes, too: node “mynode” do include “apache” end Ruby has become a first-class citizen alongside the existing external DSL. That means anywhere you can put a manifest, you should be able to put Ruby code and have it behave equivalently. So, the ‘ssh’ class above could be put into ‘$modules/ssh/manifests/init.rb’, the apache vhost type should be placed in ‘$modules/apache/manifests/vhost.rb’, and the node should probably be in your ‘site.pp’ file. You can also apply Ruby manifests directly with puppet: puppet -e mystuff.rb Note that the Ruby support does not yet cover all of the functionality in Puppet’s language. For instance, there is not yet support for overrides or defaults, nor for resource collections. Virtual and exported resources are done using a separate method: virtual file("/my/file", :content => "something") All of the standard functions are also pulled into Ruby and should work fine — e.g., ‘include’, ‘template’, and ‘require’. Stored Configuration Support is now added for using Oracle databases as a back-end for your stored configuration. Facts There are three new facts available in manifests: $clientcert – the name of the client certificate $module_name – the name of the current module (see #1545) $caller_module_name – the name of the calling module (see #1545) In addition all puppet.conf configuration items are now available as facts in your manifests. These can be accessed using the structure: $settings::setting_name Where setting_name is the name of the configuration option you’d like to retrieve. Types and Providers A new provider for pkg has been added to support Solaris and OpenSolaris (pkgadd). A new package provider has been added to support AIX package management. The augeas type has added the ‘incl’ and ‘lens’ parameters. These parameters allow loading a file anywhere on the filesystem; using them also greatly speeds up processing the resource. Binaries and Configuration Single Binary Puppet is now available as a single binary with sub-arguments for the functions previously provided by the seperate binaries (the existing binaries remain for backwards compatibility). This includes renaming several Puppet functions to better fit an overall model. List of binary changes puppetmasterd –> puppet master puppetd –> puppet agent puppet –> puppet apply puppetca –> puppet cert ralsh –> puppet resource puppetrun –> puppet kick puppetqd –> puppet queue filebucket –> puppet filebucket puppetdoc –> puppet doc pi –> puppet describe This also results in a change in the puppet.conf configuration file. The sections, previously things like [puppetd], now should be renamed to match the new binary names. So [puppetd] becomes [agent]. You will be prompted to do this when you start Puppet with a log message for each section that needs to be renamed. This is merely a warning - existing configuration file will work unchanged. New options A new option is available, ca_name, to specify the name to use for the Certificate Authority certificate. It defaults to the value of the certname option (see http://projects.reductivelabs.com/issues/1507). A new option, dbconnections, is now available that specifies a limit for the number of database connections made to remote databases (postgreSQL, MySQL). A new option, dbport, is now available that specifies the database port for remote database connections. There’s also a new option/feature that lets the puppet client use HTTP compression (—http_compression): Allow http compression in REST communication with the master. This setting might improve performance for agent –> master communications over slow WANs. Your puppetmaster needs to support compression (usually by activating some settings in a reverse-proxy in front of the puppetmaster, which rules out webrick). It is harmless to activate this settings if your master doesn’t support compression, but if it supports it, this setting might reduce on high-speed LANs. Binary changes The puppetd (or puppet agent) binary now supports the --detailed-exitcodes option available in the puppet binary. Certificates cleaned with puppetca (or puppet cert) are now also revoked. The puppetca (puppet cert) and puppetd (puppet agent) binaries now have support for certificate fingerprinting and support for specifying digest algorithms. To display the fingerprint of a client certificate use: $ puppetd --fingerprint or $ puppet agent --fingerprint To specify a particular digest algorithm use --digest DIGESTNAME. To fingerprint a certificate with puppetca use: $ puppetca --fingerprint host.example.com or $ puppet cert --fingerprint host.example.com Also supported is the --digest option. The puppetdoc binary now documents inheritance between nodes, shows classes added via the require function and resources added via the realize function. Functions The regsubst function now takes arrays as input (see #2491). Reports There is a new report type called http. If you specify: reports = http Then the new report processor will make a HTTP POST of the report in YAML format to a specified URL. By default this URL is the report import URL for a local Puppet Dashboard installation. You can override this with the new reporturl setting. reports = http reporturl = http://yoururl/post/ CHANGELOG since RC1 fa74020 [#4209] catalog.resources should return resources f5f9a38 Fix for #4210 -- missing require in CA 1c3e844 Minimal fix for #4205 -- incorrect Import loop messages 99d8323 Fix #4206 - import "path/*" tries to import files twice a2115af Alt fix for #4207 -- serialize environments as their names fe4dcd8 [#4208] Missing parameter breaks multithread compilation Regards James Turnbull -- Puppet Labs - http://www.puppetlabs.com C: 503-734-8571
Closed: (DERBY-2918) Errors in regression tests run against 10.3.1.1 release candidate
[
https://issues.apache.org/jira/browse...nels:all-tabpanel
]
Rick Hillegas closed DERBY-2918.
Release CXF 2.0.13/2.1.10/2.2.9
This is a vote to release CXF versions 2.0.13, 2.1.10, and 2.2.9. The main reason for the releases is to fix a potential security vulnerability that will be disclosed soon. That is why 2.0.13 and 2.1.10 are included despite us not really "supporting" those branches anymore. The only changes for 2.0.13 and 2.1.10 are for the security issue. For 2.2.9, we have also resolved over 20 JIRA issues. List of issues: https://issues.apache.org/jira/secure...amp;Create=Create The Maven staging areas are at: 2.0.13: https://repository.apache.org/content...orgapachecxf-030/ 2.1.10: https://repository.apache.org/content...orgapachecxf-031/ 2.2.9: https://repository.apache.org/content...orgapachecxf-034/ The distributions are in the org/apache/cxf/apache-cxf/ directory of each of the staging areas. This releases are tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.0.13 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.1.10 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.2.9 The vote will be open for 72 hours. Here is my +1.
Release
Is there a planned date for the next release? I see several 'Accepted' issues slated for Release 3.x. One being a patch that I submitted for Migrations. Are there requirements or milestones that you typically like to fulfill/achieve prior to releasing a new version? Thanks for any info! /Mike Taylor
2.1.2 release
Hi all, can everyone please take a look at all open bugs, and properly mark the ones that needs to be fixed for our first v2.2.0 release with a "target" of v2.1.2? I'm hoping v2.1.2 will be our last "feature" release before v2.2.0, and we'll only do a v2.1.3 release if there's enough bugs in the v2.1.2 release. Also, take a look at the bugs already assigned for the 2.1.2 release, if any of them can be moved out to after the v2.2.0 release, mark them for either 2.2.1 or 2.3.0. There is still not date decided for the v2.2.0 release, but I think doing some bug triaging will help us estimate when we can possible make the release. Finally, we need to get a whole lot more testing done with the 2.1.x releases, if you can, try it out on as many platforms and configurations as possible. Stress test them, production test them (I converted all my "private" sites to be fronted by ATS), try weird or complex configurations. We need to get some mileage on these builds before we make the 2.2.0 release. Cheers, -- leif
release 1.1?
Ups - thought we already released it!? What about a release now-ish? I looked through the open issues and I don't think I see any blockers. There is always one more bug ...but there can always be one more release, too. cheers
1.4.0 release soon?
I'd like to make a 1.4.0 release of Avro in the next month. The list of unresolved 1.4.0 issues is at: http://tinyurl.com/avro140todo Can developers please look at this list? If there are issues that you're assigned that you don't expect to fix soon, please unset their fix-version. If there are issues that you feel absolutely must be fixed in 1.4.0, please mark them as blockers. Thanks, Doug
Regarding the CXF release 2.0.13
Hi All, Since I have joined the mailing list today I am sending it as a reference to ongoing release of CXF. I am trying to build CXF 2.0.13 which is up for release as per the " *[VOTE] Release CXF 2.0.13/2.1.10/2.2.9". *I see some test failures which are as follows: I am running a clean build with clean M2repo.My environment is apache maven 2.0.10, windows XP SP2 and Java 5. Can someone help me identify what might be going wrong? Running org.apache.cxf.tools.wsdlto.jaxws.JAXWSContainerTest Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 5.125 sec <<< FAILURE! testSuppressCodeGen(org.apache.cxf.tools.wsdlto.jaxws.JAXWSContainerTest) Time elapsed: 0.453 sec <<< FAILURE! org.junit.ComparisonFailure: expected:<http://localhost:9[000/SoapContext/SoapPort]> but was:<http: /localhost:9[100]> at org.junit.Assert.assertEquals(Assert.java:99) at org.junit.Assert.assertEquals(Assert.java:117) at org.apache.cxf.tools.wsdlto.jaxws.JAXWSContainerTest.testSuppressCodeGen(JAXWSContainerT st.java:198) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:8 ) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44) at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirect ryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTest uite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:2 0) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) Running org.apache.cxf.tools.wsdlto.validator.ValidatorTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.485 sec Running org.apache.cxf.tools.wsdlto.jaxws.CodeGenTest Tests run: 41, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 76.39 sec Running org.apache.cxf.tools.wsdlto.jaxws.CodeGenBugTest 2010-06-04 14:35:05.005::INFO: Logging to STDERR via org.mortbay.log.StdErrLog 2010-06-04 14:35:05.052::INFO: jetty-6.1.18 2010-06-04 14:35:05.083::INFO: Started SocketC### @0.0.0.0:8585 Tests run: 54, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 104.719 sec Running org.apache.cxf.tools.wsdlto.jaxws.JAXWSBindingTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.469 sec Running org.apache.cxf.tools.wsdlto.core.PluginLoaderTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec Running org.apache.cxf.tools.wsdlto.jaxws.CodeGenOptionTest Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 7.297 sec Running org.apache.cxf.tools.wsdlto.jaxws.CatalogTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.406 sec Running org.apache.cxf.tools.wsdlto.jaxws.wsdl11.JAXWSDefinitionBuilderTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec Running org.apache.cxf.tools.wsdlto.WSDLToJavaTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec Results : Failed tests: testSuppressCodeGen(org.apache.cxf.tools.wsdlto.jaxws.JAXWSContainerTest) Tests run: 112, Failures: 1, Errors: 0, Skipped: 0 [INFO] | |||||
(1 lines) Jun 2, 2010 21:43
(1 lines) Jun 3, 2010 14:48
(1 lines) Jun 6, 2010 13:04