From ayoung at redhat.com Tue Nov 1 14:12:32 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 01 Nov 2011 10:12:32 -0400 Subject: [Pki-devel] Jersey REST API and dependencies Message-ID: <4EAFFE50.4070108@redhat.com> Jersey is the REeference implementaion of JAX-RS specifically for build RESTful web services. http://jersey.java.net/ The Code can be downloaded directly from here. https://maven.java.net/service/local/artifact/maven/redirect?r=releases&g=com.sun.jersey&a=jersey-archive&v=1.9.1&e=zip Source is available in the Maven repository: http://download.java.net/maven/2/com/sun/jersey/ The Jersey implementation brings along the following libraries which would need to be packaged for Fedora: asm-3.1.jar jackson-xc-1.8.3.jar jersey-server-1.9.1.jar jackson-core-asl-1.8.3.jar jersey-client-1.9.1.jar jettison-1.1.jar jackson-jaxrs-1.8.3.jar jersey-core-1.9.1.jar jsr311-api-1.1.1.jar jackson-mapper-asl-1.8.3.jar jersey-json-1.9.1.jar Fedora currently has asm2. Fedora currently has jettison-1.3 Jackson is built out of a single RPM. There is an older version in JPackage that we will have to update. jsr311 API is also in the Repo. All of these are GPL +classpath exception or CDDL From Joshua.Roys at gtri.gatech.edu Wed Nov 2 16:49:58 2011 From: Joshua.Roys at gtri.gatech.edu (Joshua Roys) Date: Wed, 2 Nov 2011 12:49:58 -0400 Subject: [Pki-devel] [PATCH] Fix Basic auth handling for passwords containing a colon Message-ID: <4EB174B6.9030007@gtri.gatech.edu> Hello, Attached is a patch to fix the parsing of HTTP Basic auth. Thanks, Joshua Roys -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Fix-Basic-auth-handling-for-passwords-containing-a-c.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5045 bytes Desc: S/MIME Cryptographic Signature URL: From alee at redhat.com Wed Nov 2 18:47:42 2011 From: alee at redhat.com (Ade Lee) Date: Wed, 02 Nov 2011 14:47:42 -0400 Subject: [Pki-devel] [PATCH] 0009-add-tests-to-classpath In-Reply-To: <4EA99D13.1000305@redhat.com> References: <4EA99D13.1000305@redhat.com> Message-ID: <1320259663.17206.163.camel@localhost.localdomain> ack On Thu, 2011-10-27 at 14:04 -0400, Adam Young wrote: > Requires 0008 in order to not break the build in eclipse. > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Wed Nov 2 18:48:05 2011 From: alee at redhat.com (Ade Lee) Date: Wed, 02 Nov 2011 14:48:05 -0400 Subject: [Pki-devel] [PATCH] 0008-stub-unimplemented-abstract-methods In-Reply-To: <4EA60AC9.4050303@redhat.com> References: <4EA60AC9.4050303@redhat.com> Message-ID: <1320259686.17206.164.camel@localhost.localdomain> ack On Mon, 2011-10-24 at 21:03 -0400, Adam Young wrote: > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From ayoung at redhat.com Wed Nov 2 21:12:39 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 02 Nov 2011 17:12:39 -0400 Subject: [Pki-devel] [PATCH] 0008-stub-unimplemented-abstract-methods In-Reply-To: <1320259686.17206.164.camel@localhost.localdomain> References: <4EA60AC9.4050303@redhat.com> <1320259686.17206.164.camel@localhost.localdomain> Message-ID: <4EB1B247.1060509@redhat.com> On 11/02/2011 02:48 PM, Ade Lee wrote: > ack > > On Mon, 2011-10-24 at 21:03 -0400, Adam Young wrote: >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > Commited to trunk From ayoung at redhat.com Wed Nov 2 21:12:54 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 02 Nov 2011 17:12:54 -0400 Subject: [Pki-devel] [PATCH] 0009-add-tests-to-classpath In-Reply-To: <1320259663.17206.163.camel@localhost.localdomain> References: <4EA99D13.1000305@redhat.com> <1320259663.17206.163.camel@localhost.localdomain> Message-ID: <4EB1B256.7090402@redhat.com> On 11/02/2011 02:47 PM, Ade Lee wrote: > ack > On Thu, 2011-10-27 at 14:04 -0400, Adam Young wrote: >> Requires 0008 in order to not break the build in eclipse. >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > Committed to trunk From ayoung at redhat.com Wed Nov 2 21:15:36 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 02 Nov 2011 17:15:36 -0400 Subject: [Pki-devel] [PATCH] 0010 code cleanup-com.netscape.cmsutil Message-ID: <4EB1B2F8.9010905@redhat.com> The first of many patches for code -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0010-code-cleanup-com.netscape.cmsutil.patch Type: text/x-patch Size: 182178 bytes Desc: not available URL: From adam at younglogic.com Wed Nov 2 21:26:08 2011 From: adam at younglogic.com (Adam Young) Date: Wed, 02 Nov 2011 17:26:08 -0400 Subject: [Pki-devel] Git svn checkout Message-ID: <4EB1B570.7040501@younglogic.com> If you follow my slides: you will have trouble committing. I was able to commit to the svn repo using the following command: git svn dcommit --commit-url svn+ssh://$FEDORAUSER at svn.fedorahosted.org/svn/pki/trunk Where $FEDORAUSER for me is admiyo I think that the right approach is to do the original clone using the svn+ssh URL: git svn clone ssh://$FEDORAUSER at svn.fedorahosted.org/svn/pki --prefix svn/ --stdlayout I am doing a clone right now, and I will test with my next commit. From alee at redhat.com Thu Nov 3 20:12:54 2011 From: alee at redhat.com (Ade Lee) Date: Thu, 03 Nov 2011 16:12:54 -0400 Subject: [Pki-devel] [PATCH] 0010 code cleanup-com.netscape.cmsutil In-Reply-To: <4EB1B2F8.9010905@redhat.com> References: <4EB1B2F8.9010905@redhat.com> Message-ID: <1320351175.17206.273.camel@localhost.localdomain> CryptoUtil.java: 1. In CryptoUtil.java, I see a lot of places where the static members are qualified by their full name. For example, content = content.substring(LINE_COUNT); becomes content = content.substring(CryptoUtil.LINE_COUNT); Is this some kind of standard - that local static variables need to be fully qualified? 2. Also in CryptoUtil.java, there are cases where unused variables are removed incorrectly: For example, in public static String reqFormat(String content): int beginIndex = CERTREQ_BEGIN_HEADING.length(); becomes -> CryptoUtil.CERTREQ_BEGIN_HEADING.length(); This happens in multiple places. 3. In public static X509CertInfo createX509CertInfo(), you have the following change: AlgorithmId sigAlgId = new AlgorithmId(); which becomes new AlgorithmId(); and then : info.set(X509CertInfo.ALGORITHM_ID, CertificateAlgorithmId(sigAlgId.get(alg))); becomes: info.set(X509CertInfo.ALGORITHM_ID, new CertificateAlgorithmId(AlgorithmId.get(alg))); Is this really right? The changes in this file as clearly messed up. Please fix and resubmit. HttpEofException.java What is the purpose of the new version UID? HttpRequest.java In this file, you also fully specify some static members. Why? JSSSocketFactory.java 1. You fully qualify a few static members? why? 2. Why does : s.enableSSL2Default(false); become SSLSocket.enableSSL2Default(false); ? 3. Why are we removing comments by findCertByNickname? BasicOCSPResponse.java, CertID.java, GoodInfo.java, KeyHashID.java, NameID.java, OCSPRequest.java, OCSPResponse.java, OCSPResponseStatus, Request.java and many others .. You are qualifying local static members here again. The question is -- is this an automated and hence consistent thing? Is this a standard that needs to be enforced in the code style? UnknownInfo.java 1. Why are we removing comments here? The question is one of consistency -- why are we removing those comments and not the ones in the decode() function? CRSPKIMessage.java 1. Good comments removed 2. Its not clear that the variables here ought to be removed. Utils.java 1. Bad removal of variable in checkHost() -- what is that function doing in any case? Any unit tests? Ade On Wed, 2011-11-02 at 17:15 -0400, Adam Young wrote: > The first of many patches for code > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Thu Nov 3 20:43:48 2011 From: alee at redhat.com (Ade Lee) Date: Thu, 03 Nov 2011 16:43:48 -0400 Subject: [Pki-devel] [PATCH] Fix Basic auth handling for passwords containing a colon In-Reply-To: <4EB174B6.9030007@gtri.gatech.edu> References: <4EB174B6.9030007@gtri.gatech.edu> Message-ID: <1320353029.17206.275.camel@localhost.localdomain> Joshua, Thanks for the patch. Looks like a good catch. We'll review it and get back to you soon. Ade On Wed, 2011-11-02 at 12:49 -0400, Joshua Roys wrote: > Hello, > > Attached is a patch to fix the parsing of HTTP Basic auth. > > Thanks, > > Joshua Roys > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From ayoung at redhat.com Thu Nov 3 20:44:25 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 03 Nov 2011 16:44:25 -0400 Subject: [Pki-devel] [PATCH] 0010 code cleanup-com.netscape.cmsutil In-Reply-To: <4EB1B2F8.9010905@redhat.com> References: <4EB1B2F8.9010905@redhat.com> Message-ID: <4EB2FD29.1040301@redhat.com> On 11/02/2011 05:15 PM, Adam Young wrote: > The first of many patches for code > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel Withdrawn at Ade's request. GOing to submite a single patch for just the import changes. The rest of the changes will be submitted in a different patch. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Fri Nov 4 19:04:49 2011 From: ayoung at redhat.com (Adam Young) Date: Fri, 04 Nov 2011 15:04:49 -0400 Subject: [Pki-devel] [PATCH] 0011-Cleanup-imports Message-ID: <4EB43751.5050806@redhat.com> This process was completely automated. Compiled the whole tree successfully afterwards. -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0011-1-Cleanup-imports.patch Type: text/x-patch Size: 1688468 bytes Desc: not available URL: From alee at redhat.com Fri Nov 4 19:39:04 2011 From: alee at redhat.com (Ade Lee) Date: Fri, 04 Nov 2011 15:39:04 -0400 Subject: [Pki-devel] [PATCH] 0011-Cleanup-imports In-Reply-To: <4EB43751.5050806@redhat.com> References: <4EB43751.5050806@redhat.com> Message-ID: <1320435544.17206.338.camel@localhost.localdomain> ack On Fri, 2011-11-04 at 15:04 -0400, Adam Young wrote: > This process was completely automated. Compiled the whole tree > successfully afterwards. > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From ayoung at redhat.com Sat Nov 5 00:00:46 2011 From: ayoung at redhat.com (Adam Young) Date: Fri, 04 Nov 2011 20:00:46 -0400 Subject: [Pki-devel] [PATCH] 0011-Cleanup-imports In-Reply-To: <4EB43751.5050806@redhat.com> References: <4EB43751.5050806@redhat.com> Message-ID: <4EB47CAE.3050200@redhat.com> ACKed in IRC by Ade Lee. Commited to trunk On 11/04/2011 03:04 PM, Adam Young wrote: > This process was completely automated. Compiled the whole tree > successfully afterwards. > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Tue Nov 8 18:10:51 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 08 Nov 2011 13:10:51 -0500 Subject: [Pki-devel] Tomcat Realms and Directory Server Message-ID: <4EB970AB.9080807@redhat.com> One issue I have been looking at recently is how to integrate PKI and IPA at the auth level while keeping a clean separation. We can extract the authentication from the servlet code, so it is purely a matter of configuring the Tomcat instance Realm. I wrote up a Proof of concept for just doing pure LDAP using simple bind, which is not a bad starting point. http://adam.younglogic.com/2011/11/tomcat-simple-ipa/ We want to continue this approach, but use a more secure authentication method. We won't be using basic auth, and we won't be using simple bind. There are two forms of authentication we want to support: Client Certificates and Kerberos. Certificates will work as they do now, and Kerberos will be for passing through user credentials from IPA, through HTTP to CS. In both cases, the data that backs it will be stored in the DS instance. Tomcat has a class classed a CombinedRealm: http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#CombinedRealm That might support stacking Certificate and Kerberos auth on top of each other. The Realm will then delegate to LDAP for extracting the Roles. http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#JAASRealm Kerberos is typically done using a JAAS Realm. I have to admit I don't really like the fact that we have to modify the JVM startup to do so, it is not really that big of a deal. I was also not a fan of setting the Realm up as a single service ticket until Simo informed me that the Browser NEGOTIATE mechanism assumes that the Service ticket is going to be Named HTTP. This means that for Proxied implementations, to include IPA, we will have to share the Service Principal Identity with the Apache HTTPD server. http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#JAASRealm However, once you start digging in, you will find that the solutions are suboptimal. It turns out that the Negotiate auth-method has only very recently been supported, and that is only on Tomcat7. The best resource I have found on the options for a custom realm is here: http://wiki.wsmoak.net/cgi-bin/wiki.pl?TomcatKerberos and the most likely option http://wiki.wsmoak.net/cgi-bin/wiki.pl?TomcatKerberosLoginModule We really want a mix of the KRB5Login Module and the JNDIRealm. That seems to be what is described here: http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html We should target Tomcat 7 for Dogtag:future. Fedora 16 ships with Tomcat-7. I suspect that the CombinedRealm approach will not support falling back from one auth-method to another: I've been looking and have not see it specified that you can put multiple auth-method entries inside a login-config in the web.xml. Ideally, we would attempt a Certificate based authentication first, and then fall back to Negotiate. However, we can say that a given deployment is going to be either Kerberos or Client Certificate, and swap out the configuration at the Tomcat level. I don't like that nearly as much. The document here: http://wiki.apache.org/tomcat/SSLWithFORMFallback talks about how to do Client Cert with a fallback to Form based authentication. We'd want to do Client Cert with a fallback to Krb5. This is using what is called a Valve. In Tomcat 6 and 7 valves have been deprecated in favor of Filters. The general approach is the same. I'd like to keep the idea of the Realm as the primary approach. If we do have to build a custom Realm, and I suspect that we will, we might want to spin it off into its own package, or submit it for Inclusion in Tomcat 7 upstream. It seems that the PKI approach has been to Bind as Directory Manager. What I would like to target moving forward is that the Bind is done as the user making the web request. For managed operations that require a higher level of authentication, we use the concept of queues like we do now. The threads that manage those queue will use a Principal with a higher level of authorization: not "Directory Manger", but perhaps "CA Manager" which is a user we create that manages the CA subtree in the Directory server. For a Dogtag deployment without IPA, the CA Manger would have write privileged on the Identity subtree. For integrated deployments, IPA would have its own principal "IPA Manager" that would not have read or write capabilities in the CA Subtree. DRM, TKS and other subsytems would in turn also get their own Manager users, and they would only have permissions to manage their own trees: we will need to clear up which gets read and write permissions on which other subtrees. Directory Manager would be limited to performing operations that effect the entire DS instance: Setup and Replication. The Directory Manager, CA Manager, IPA manager users should be binding with a certificate or a keytab, not with a cleartext password. From ayoung at redhat.com Thu Nov 10 00:50:56 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 09 Nov 2011 19:50:56 -0500 Subject: [Pki-devel] [PATCH] 0012-Dead-code-removal Message-ID: <4EBB1FF0.90409@redhat.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0012-Dead-code-removal.patch Type: text/x-patch Size: 47530 bytes Desc: not available URL: From ayoung at redhat.com Thu Nov 10 20:26:59 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 10 Nov 2011 15:26:59 -0500 Subject: [Pki-devel] [PATCH] 0013-unnecessary-block-removal Message-ID: <4EBC3393.8000102@redhat.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0013-unnecessary-block-removal.patch Type: text/x-patch Size: 24717 bytes Desc: not available URL: From ayoung at redhat.com Thu Nov 10 20:27:47 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 10 Nov 2011 15:27:47 -0500 Subject: [Pki-devel] [PATCH] 0014-Adjust-classpath-for-F16 Message-ID: <4EBC33C3.6020606@redhat.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0014-Adjust-classpath-for-F16.patch Type: text/x-patch Size: 1160 bytes Desc: not available URL: From ayoung at redhat.com Fri Nov 11 03:29:56 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 10 Nov 2011 22:29:56 -0500 Subject: [Pki-devel] [PATCH] 0015-Removal-of-unused-private-methods Message-ID: <4EBC96B4.1010700@redhat.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0015-Removal-of-unused-private-methods.patch Type: text/x-patch Size: 131155 bytes Desc: not available URL: From ayoung at redhat.com Fri Nov 11 03:30:39 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 10 Nov 2011 22:30:39 -0500 Subject: [Pki-devel] [PATCH] 0016-Exclude-CMake-files-from-classpath Message-ID: <4EBC96DF.80109@redhat.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0016-Exclude-CMake-files-from-classpath.patch Type: text/x-patch Size: 2326 bytes Desc: not available URL: From ayoung at redhat.com Fri Nov 11 03:30:58 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 10 Nov 2011 22:30:58 -0500 Subject: [Pki-devel] [PATCH] 0017-call-statics-statically Message-ID: <4EBC96F2.4080101@redhat.com> From nkinder at redhat.com Fri Nov 11 18:14:23 2011 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 11 Nov 2011 10:14:23 -0800 Subject: [Pki-devel] Dogtag trac instance - please add tasks Message-ID: <4EBD65FF.9050503@redhat.com> I have started configuring our Trac instance to track new Dogtag development work. The Trac instance is available at the following URL: https://fedorahosted.org/pki/ There are still a number of things that will need to be set up and fleshed out as we start using Trac, but I think that we are at a point that we can start adding development tasks. Please go ahead and start creating tasks as we discussed yesterday. Don't worry about tying the tickets to milestones yet. We will go through that next week after we have some initial tasks created. The "estimate" field should be the number of days that you think the task will take. The estimates will be important for deciding what milestone a task should target. We should try to keep the tasks fairly granular in terms of the estimates so it's easy to see if we are on track. As far as the milestones go, I've started creating them on a 1 month cycle. Using a fairly short milestone cycle like this will make it easier to see how we are doing against our plans. We can flesh out the individual milestone goals when we start assigning tasks to milestones next week. If you see anything that you feel should be added (missing components, additional fields, etc.) or have any questions, please speak up. Thanks, -NGK From ayoung at redhat.com Mon Nov 14 14:40:57 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 14 Nov 2011 09:40:57 -0500 Subject: [Pki-devel] Hack to build on F16 Message-ID: <4EC12879.60705@redhat.com> In Fedora 16, the JNI binary JAR files for 64 bit have moved from /usr/lib/java to /usr/lib64/java. CMake doesn't handle this yet. I have a ticket in to fix it, but until we get it fixed, you can build 64 bit rpms by: cd /usr/lib ln -s /usr/lib64/java From ayoung at redhat.com Mon Nov 14 15:48:19 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 14 Nov 2011 10:48:19 -0500 Subject: [Pki-devel] [PATCH] 0017-call-statics-statically In-Reply-To: <4EBC96F2.4080101@redhat.com> References: <4EBC96F2.4080101@redhat.com> Message-ID: <4EC13843.7080103@redhat.com> On 11/10/2011 10:30 PM, Adam Young wrote: > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0017-call-statics-statically.patch Type: text/x-patch Size: 63661 bytes Desc: not available URL: From ayoung at redhat.com Mon Nov 14 20:44:16 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 14 Nov 2011 15:44:16 -0500 Subject: [Pki-devel] [PATCH] 0018-PKISilent-in-single-tre Message-ID: <4EC17DA0.7010401@redhat.com> Tested as far as calling a bunch of the Subordinate classes: ConfigureCA, ConfigureDRM. In general, this patch doesn't change the behavior of anything, just the structure To simply development, and because Perl was really unnecessary for this, the pkisilent wrapper has been redone in Bash. If you wish to test out what this actually does, set -x on the bash line and run it. -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0018-PKISilent-in-single-tree.patch Type: text/x-patch Size: 63263 bytes Desc: not available URL: From alee at redhat.com Tue Nov 15 06:11:56 2011 From: alee at redhat.com (Ade Lee) Date: Tue, 15 Nov 2011 01:11:56 -0500 Subject: [Pki-devel] [PATCH] 0012-Dead-code-removal In-Reply-To: <4EBB1FF0.90409@redhat.com> References: <4EBB1FF0.90409@redhat.com> Message-ID: <1321337517.6303.155.camel@aleeredhat.laptop> This is a review of this patch and the subsequent one removing unnecessary blocks. CMCAuth.java: Can you explain why this code removal is correct? CAAdminServlet.java : code should be commented out, rather than removed. HashEnrollServlet.java : remove the outer conditional as well. DBSubsystem.java: some important comments are removed, they should not be removed. FileAsString.java - does the proposed code removal introduce a resource leak? KeyRecoveryAuthority.java: please explain why the proposed code removal is correct. It certainly looks wrong. Ade On Wed, 2011-11-09 at 19:50 -0500, Adam Young wrote: > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From ayoung at redhat.com Tue Nov 15 22:00:26 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 15 Nov 2011 17:00:26 -0500 Subject: [Pki-devel] [PATCH] 0018-PKISilent-in-single-tre In-Reply-To: <4EC17DA0.7010401@redhat.com> References: <4EC17DA0.7010401@redhat.com> Message-ID: <4EC2E0FA.2000505@redhat.com> On 11/14/2011 03:44 PM, Adam Young wrote: > Tested as far as calling a bunch of the Subordinate classes: > ConfigureCA, ConfigureDRM. In general, this patch doesn't change > the behavior of anything, just the structure > > To simply development, and because Perl was really unnecessary for > this, the pkisilent wrapper has been redone in Bash. If you wish to > test out what this actually does, set -x on the bash line and run it. > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel Self NACK on this one. It does not properly handle the parameters with spaces in them, most notable "Directory Manager" -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Tue Nov 15 22:57:38 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 15 Nov 2011 17:57:38 -0500 Subject: [Pki-devel] [PATCH] 0018-PKISilent-in-single-tre In-Reply-To: <4EC2E0FA.2000505@redhat.com> References: <4EC17DA0.7010401@redhat.com> <4EC2E0FA.2000505@redhat.com> Message-ID: <4EC2EE62.5000101@redhat.com> IPA assumes pkisilent is a Perl executable and calls via /usr/bin/perl. Also, the shell version was not honoring how IPA needs to wrap the arguments to PKI Silent On 11/15/2011 05:00 PM, Adam Young wrote: > On 11/14/2011 03:44 PM, Adam Young wrote: >> Tested as far as calling a bunch of the Subordinate classes: >> ConfigureCA, ConfigureDRM. In general, this patch doesn't change >> the behavior of anything, just the structure >> >> To simply development, and because Perl was really unnecessary for >> this, the pkisilent wrapper has been redone in Bash. If you wish to >> test out what this actually does, set -x on the bash line and run it. >> >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > Self NACK on this one. It does not properly handle the parameters > with spaces in them, most notable "Directory Manager" > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0018-1-PKISilent-in-single-tree.patch Type: text/x-patch Size: 57598 bytes Desc: not available URL: From alee at redhat.com Wed Nov 16 14:33:45 2011 From: alee at redhat.com (Ade Lee) Date: Wed, 16 Nov 2011 09:33:45 -0500 Subject: [Pki-devel] [PATCH] 0016-Exclude-CMake-files-from-classpath In-Reply-To: <4EBC96DF.80109@redhat.com> References: <4EBC96DF.80109@redhat.com> Message-ID: <1321454025.3201.0.camel@aleeredhat.laptop> Why do we need to do this? Does it generate errors/warnings? Ade On Thu, 2011-11-10 at 22:30 -0500, Adam Young wrote: > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Wed Nov 16 14:48:25 2011 From: alee at redhat.com (Ade Lee) Date: Wed, 16 Nov 2011 09:48:25 -0500 Subject: [Pki-devel] [PATCH] 0015-Removal-of-unused-private-methods In-Reply-To: <4EBC96B4.1010700@redhat.com> References: <4EBC96B4.1010700@redhat.com> Message-ID: <1321454906.3201.7.camel@aleeredhat.laptop> I'm struggling with the premise behind this patch. Some of these methods seem like they are valuable - and certainly they were valuable at some point in time (or they would not have been written). On the other hand, I see the benefit of trimming the code base. No need to refactor code that isn't being used. I realize that this removes some eclipse warnings, but is removing these methods good practice? I guess I'm looking for some other folks to chime in here. Ade On Thu, 2011-11-10 at 22:29 -0500, Adam Young wrote: > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From ayoung at redhat.com Wed Nov 16 15:33:23 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 16 Nov 2011 10:33:23 -0500 Subject: [Pki-devel] [PATCH] 0012-Dead-code-removal In-Reply-To: <1321337517.6303.155.camel@aleeredhat.laptop> References: <4EBB1FF0.90409@redhat.com> <1321337517.6303.155.camel@aleeredhat.laptop> Message-ID: <4EC3D7C3.9060407@redhat.com> On 11/15/2011 01:11 AM, Ade Lee wrote: > This is a review of this patch and the subsequent one removing > unnecessary blocks. > > CMCAuth.java: Can you explain why this code removal is correct? At this point in the code, cert can only be null. The only code path that assigns a value to cert has a return after it, and cannot reach this point. Thus, the code executed when cert != null is unreachable > > CAAdminServlet.java : code should be commented out, rather than removed. Disagree. If this code has never been run, it is unnecessary. Lets not put dead code into the source tree. > > HashEnrollServlet.java : remove the outer conditional as well. Done > DBSubsystem.java: some important comments are removed, they should not > be removed. Done > > FileAsString.java - does the proposed code removal introduce a resource > leak? No. FileReader can throw a file not found exception. But BufferedReader only throws an IllegalArgumentException, which wouldn't be caught by that catch block anyway. > > KeyRecoveryAuthority.java: please explain why the proposed code removal > is correct. It certainly looks wrong. I agree that the change looks wrong. I put it back in, and Eclipse did not tag it as dead code. > > Ade > > On Wed, 2011-11-09 at 19:50 -0500, Adam Young wrote: >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0012-1-Dead-code-removal.patch Type: text/x-patch Size: 47201 bytes Desc: not available URL: From ayoung at redhat.com Wed Nov 16 15:35:00 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 16 Nov 2011 10:35:00 -0500 Subject: [Pki-devel] [PATCH] 0016-Exclude-CMake-files-from-classpath In-Reply-To: <1321454025.3201.0.camel@aleeredhat.laptop> References: <4EBC96DF.80109@redhat.com> <1321454025.3201.0.camel@aleeredhat.laptop> Message-ID: <4EC3D824.2050609@redhat.com> On 11/16/2011 09:33 AM, Ade Lee wrote: > Why do we need to do this? Does it generate errors/warnings? > Ade > > On Thu, 2011-11-10 at 22:30 -0500, Adam Young wrote: >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > Yes. The warning is "Duplicated Resource ...." and since they are not needed by the Eclipse build anyway, this is a harmless and correct commit. From ayoung at redhat.com Wed Nov 16 15:38:14 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 16 Nov 2011 10:38:14 -0500 Subject: [Pki-devel] [PATCH] 0015-Removal-of-unused-private-methods In-Reply-To: <1321454906.3201.7.camel@aleeredhat.laptop> References: <4EBC96B4.1010700@redhat.com> <1321454906.3201.7.camel@aleeredhat.laptop> Message-ID: <4EC3D8E6.6080002@redhat.com> On 11/16/2011 09:48 AM, Ade Lee wrote: > I'm struggling with the premise behind this patch. Some of these > methods seem like they are valuable - and certainly they were valuable > at some point in time (or they would not have been written). On the > other hand, I see the benefit of trimming the code base. No need to > refactor code that isn't being used. > > I realize that this removes some eclipse warnings, but is removing these > methods good practice? > > I guess I'm looking for some other folks to chime in here. My feeling is that you do not leave dead code in the code base. The code still exists in the repository, but it is unlikely that a piece of code that is not called today will be needed in exactly the same form in the future. Code is documentation. Code that is not used is misleading to the maintainer. Committing commented out code is a bad practice. As we refactor, the location of the behavior of a lot of these methods will change. Thus, some orphan calls will become uncallable, and others will get in the way of code clean up. This is old code: some of it goes back 15 years. Holding on to unused, uncallable code is akin to hoarding. > > Ade > > On Thu, 2011-11-10 at 22:29 -0500, Adam Young wrote: >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > From alee at redhat.com Wed Nov 16 15:55:44 2011 From: alee at redhat.com (Ade Lee) Date: Wed, 16 Nov 2011 10:55:44 -0500 Subject: [Pki-devel] [PATCH] 0016-Exclude-CMake-files-from-classpath In-Reply-To: <4EC3D824.2050609@redhat.com> References: <4EBC96DF.80109@redhat.com> <1321454025.3201.0.camel@aleeredhat.laptop> <4EC3D824.2050609@redhat.com> Message-ID: <1321458945.3201.8.camel@aleeredhat.laptop> Ok - ACK On Wed, 2011-11-16 at 10:35 -0500, Adam Young wrote: > On 11/16/2011 09:33 AM, Ade Lee wrote: > > Why do we need to do this? Does it generate errors/warnings? > > Ade > > > > On Thu, 2011-11-10 at 22:30 -0500, Adam Young wrote: > >> _______________________________________________ > >> Pki-devel mailing list > >> Pki-devel at redhat.com > >> https://www.redhat.com/mailman/listinfo/pki-devel > > > Yes. The warning is "Duplicated Resource ...." and since they are not > needed by the Eclipse build anyway, this is a harmless and correct > commit. From mharmsen at redhat.com Wed Nov 16 23:38:17 2011 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 16 Nov 2011 15:38:17 -0800 Subject: [Pki-devel] [PATCH] 0018-PKISilent-in-single-tre In-Reply-To: <4EC2EE62.5000101@redhat.com> References: <4EC17DA0.7010401@redhat.com> <4EC2E0FA.2000505@redhat.com> <4EC2EE62.5000101@redhat.com> Message-ID: <4EC44969.9090207@redhat.com> ACK. As we discussed, in "pki/base/silent/src/com/netscape/pkisilent/common/TestClient.java", if possible please make the "public String PWD;" into "protected String PWD;" as it refers to a "password" in this context; if not possible to be made into a "protected" class, perhaps create a public method to assign data to this private variable. On 11/15/11 14:57, Adam Young wrote: > IPA assumes pkisilent is a Perl executable and calls via > /usr/bin/perl. Also, the shell version was not honoring how IPA > needs to wrap the arguments to PKI Silent > > > On 11/15/2011 05:00 PM, Adam Young wrote: >> On 11/14/2011 03:44 PM, Adam Young wrote: >>> Tested as far as calling a bunch of the Subordinate classes: >>> ConfigureCA, ConfigureDRM. In general, this patch doesn't change >>> the behavior of anything, just the structure >>> >>> To simply development, and because Perl was really unnecessary for >>> this, the pkisilent wrapper has been redone in Bash. If you wish >>> to test out what this actually does, set -x on the bash line and >>> run it. >>> >>> >>> _______________________________________________ >>> Pki-devel mailing list >>> Pki-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-devel >> Self NACK on this one. It does not properly handle the parameters >> with spaces in them, most notable "Directory Manager" >> >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Thu Nov 17 00:04:47 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 16 Nov 2011 19:04:47 -0500 Subject: [Pki-devel] [PATCH] 0018-PKISilent-in-single-tre In-Reply-To: <4EC44969.9090207@redhat.com> References: <4EC17DA0.7010401@redhat.com> <4EC2E0FA.2000505@redhat.com> <4EC2EE62.5000101@redhat.com> <4EC44969.9090207@redhat.com> Message-ID: <4EC44F9F.6030409@redhat.com> On 11/16/2011 06:38 PM, Matthew Harmsen wrote: > ACK. > > As we discussed, in > "pki/base/silent/src/com/netscape/pkisilent/common/TestClient.java", > if possible please make the "public String PWD;" into "protected > String PWD;" as it refers to a "password" in this context; if not > possible to be made into a "protected" class, perhaps create a public > method to assign data to this private variable. Made PWD into a protected variable and commited to trunk. > > On 11/15/11 14:57, Adam Young wrote: >> IPA assumes pkisilent is a Perl executable and calls via >> /usr/bin/perl. Also, the shell version was not honoring how IPA >> needs to wrap the arguments to PKI Silent >> >> >> On 11/15/2011 05:00 PM, Adam Young wrote: >>> On 11/14/2011 03:44 PM, Adam Young wrote: >>>> Tested as far as calling a bunch of the Subordinate classes: >>>> ConfigureCA, ConfigureDRM. In general, this patch doesn't change >>>> the behavior of anything, just the structure >>>> >>>> To simply development, and because Perl was really unnecessary for >>>> this, the pkisilent wrapper has been redone in Bash. If you wish >>>> to test out what this actually does, set -x on the bash line and >>>> run it. >>>> >>>> >>>> _______________________________________________ >>>> Pki-devel mailing list >>>> Pki-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/pki-devel >>> Self NACK on this one. It does not properly handle the parameters >>> with spaces in them, most notable "Directory Manager" >>> >>> >>> _______________________________________________ >>> Pki-devel mailing list >>> Pki-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-devel >> >> >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Thu Nov 17 00:05:25 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 16 Nov 2011 19:05:25 -0500 Subject: [Pki-devel] [PATCH] 0016-Exclude-CMake-files-from-classpath In-Reply-To: <1321458945.3201.8.camel@aleeredhat.laptop> References: <4EBC96DF.80109@redhat.com> <1321454025.3201.0.camel@aleeredhat.laptop> <4EC3D824.2050609@redhat.com> <1321458945.3201.8.camel@aleeredhat.laptop> Message-ID: <4EC44FC5.5010100@redhat.com> On 11/16/2011 10:55 AM, Ade Lee wrote: > Ok - ACK > On Wed, 2011-11-16 at 10:35 -0500, Adam Young wrote: >> On 11/16/2011 09:33 AM, Ade Lee wrote: >>> Why do we need to do this? Does it generate errors/warnings? >>> Ade >>> >>> On Thu, 2011-11-10 at 22:30 -0500, Adam Young wrote: >>>> _______________________________________________ >>>> Pki-devel mailing list >>>> Pki-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/pki-devel >> Yes. The warning is "Duplicated Resource ...." and since they are not >> needed by the Eclipse build anyway, this is a harmless and correct >> commit. > Commited to Trunk From ayoung at redhat.com Thu Nov 17 03:00:12 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 16 Nov 2011 22:00:12 -0500 Subject: [Pki-devel] [PATCH] 0019-PKISilent-type-safety-changes Message-ID: <4EC478BC.4070600@redhat.com> Tested by running ipa-server-install, which calls pkisilent. From ayoung at redhat.com Thu Nov 17 23:28:27 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 17 Nov 2011 18:28:27 -0500 Subject: [Pki-devel] Fwd: Re: [Freeipa-users] Delete host: Unable to communicate with CMS (Not Found) In-Reply-To: <4EC55198.5040206@redhat.com> References: <4EC55198.5040206@redhat.com> Message-ID: <4EC5989B.3090502@redhat.com> We needo upgrade F15 to F16 Tomcat instances upon upgrade from pointing to files in /usr/lib/java to /usrlib64/java for x86_64 -------- Original Message -------- Subject: Re: [Freeipa-users] Delete host: Unable to communicate with CMS (Not Found) Date: Thu, 17 Nov 2011 13:25:28 -0500 From: John Dennis To: Dan Scott CC: Adam Young , freeipa-users at redhat.com On 11/17/2011 11:46 AM, Dan Scott wrote: > On Thu, Nov 17, 2011 at 11:35, John Dennis wrote: >> On 11/17/2011 11:25 AM, Adam Young wrote: >>>> >>>> To summarise, the errors are: >>>> SEVERE: Error initializing socket factory >>>> java.lang.ClassNotFoundException: org.mozilla.jss.ssl.SSLSocket >>>> SEVERE: Failed to initialize connector [Connector[HTTP/1.1-9443]] >>>> java.io.IOException: Failed to access resource /WEB-INF/lib/osutil.jar >>>> >>>> I'd guess that this means I'm missing a package? I'm having trouble >>>> figuring out which one contains the code I'm missing. Maybe I need to >>>> reinstall one? >> >>> Is this on F16? It might be that the package is there but not being >>> picked up. >>> >>> JSS and osutils are a JNI packages, and you should find them in >>> /usr/lib64/java/jss4.jar and osutil.jar, but they might end up in >>> /usr/lib/java/jss4.jar and osutil,jar >> >> My guess is this is due to the fact these jars changed their location. The >> symlinks to the jars are established by pkicreate. We have a bug open to >> enchance pkicreate (or add a new tool) which will adjust the links after an >> upgrade (sorry don't recall the bz number off the top of my head, could did >> it up if necessary). >> >> You can cd to /var/lib/pki-ca >> >> and do an ls -l on >> >> common/lib >> >> and >> >> webapps/ca/WEB-INF/lib/ >> >> and inspect the symbolic links to see if any are dangling. If so adjust the >> link to point to it's new location. > > Success! > > Thanks so much. > > /var/lib/pki-ca/common/lib/jss4.jar > /var/lib/pki-ca/webapps/ca/WEB-INF/lib/osutil.jar > /var/lib/pki-ca/webapps/ca/WEB-INF/lib/symkey.jar > > Were all broken, pointing into /usr/lib/. Changing them to link to > /usr/lib64 allowed pki to start properly and I can make changes to the > host entry. > > It sounds like you have a fix for this in progress, or do I need to file a bug? Found the bugzilla, it's https://bugzilla.redhat.com/show_bug.cgi?id=728598 It's filed against Red Hat Certificate System in RHEL, not dogtag in Fedora. Adam do you want to clone it into Fedora? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Fri Nov 18 00:50:48 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 17 Nov 2011 19:50:48 -0500 Subject: [Pki-devel] An argument against RESTeasy Message-ID: <4EC5ABE8.4030804@redhat.com> As I suspected, the dependencies for RESTeasy are too numerous. I thin we need to go with Jersey. grep BuildRequires ~/rpmbuild/SPECS/resteasy.spec BuildRequires: jpackage-utils BuildRequires: java BuildRequires: java-devel BuildRequires: maven2 BuildRequires: maven-compiler-plugin BuildRequires: maven-javadoc-plugin BuildRequires: maven-install-plugin BuildRequires: maven-site-plugin BuildRequires: maven-source-plugin BuildRequires: maven-resources-plugin BuildRequires: maven-surefire-plugin BuildRequires: maven-jar-plugin #BuildRequires: maven-jdocbook-plugin BuildRequires: maven-assembly-plugin BuildRequires: jboss-jaxrpc-api_1.1_spec BuildRequires: jboss-servlet-api_3.0_spec BuildRequires: jboss-el-api_2.2_spec BuildRequires: jboss-ejb-api_3.1_spec BuildRequires: weld-cdi-1.0-api BuildRequires: codehaus-stax11-api BuildRequires: jboss-el BuildRequires: hibernate3-ejb-persistence-3.0-api #BuildRequires: hc-httpcore #BuildRequires: hc-httpclient BuildRequires: httpcomponents-project = 4.1.1-0.2.ep6.el6 BuildRequires: httpcomponents-httpcore = 4.1.3-0.2.ep6.el6 BuildRequires: httpcomponents-httpclient = 4.1.1-0.2.ep6.el6 BuildRequires: glassfish-jaxws #BuildRequires: xmlgraphics-batik #BuildRequires: xmlgraphics-commons #BuildRequires: xml-commons-resolver BuildRequires: javassist >= 0:3.9.0 BuildRequires: glassfish-javamail BuildRequires: glassfish-jaxb >= 0:2.1.9 #BuildRequires: glassfish-jaxws BuildRequires: sun-sjsxp >= 0:1.0.1 BuildRequires: tomcat6-lib >= 0:6.0.32 BuildRequires: jaxen >= 0:1.1.2 BuildRequires: jgroups >= 0:2.6.19 BuildRequires: junit4 BuildRequires: apache-abdera-core >= 0:0.4.0 BuildRequires: apache-abdera-parser >= 0:0.4.0 BuildRequires: apache-abdera-client >= 0:0.4.0 BuildRequires: apache-abdera-dependencies >= 0:0.4.0 BuildRequires: apache-james >= 0:0.6 BuildRequires: ws-commons-axiom >= 0:1.2.7 BuildRequires: codehaus-jackson-core-asl >= 0:1.0.1 BuildRequires: codehaus-jackson-jaxrs >= 0:1.0.1 BuildRequires: codehaus-jackson-mapper-asl >= 0:1.0.1 BuildRequires: codehaus-jackson-xc BuildRequires: jettison >= 0:1.2 BuildRequires: wstx >= 0:3.2.8 BuildRequires: jboss-cache-core >= 0:3.2.7 BuildRequires: jboss-common-core >= 0:2.2.17 BuildRequires: jboss-common-logging-spi >= 0:2.1.2 BuildRequires: jboss-parent BuildRequires: jyaml >= 0:1.3 BuildRequires: richfaces-highlight BuildRequires: richfaces-docs BuildRequires: richfaces-root BuildRequires: scannotation >= 0:1.0.2 BuildRequires: slf4j >= 0:1.5.8 BuildRequires: xalan-j2 >= 0:2.7.0 BuildRequires: xerces-j2 >= 0:2.9.1 BuildRequires: xml-commons >= 0:1.3.03 BuildRequires: xpp3-minimal >= 0:1.1.3.4 BuildRequires: jcip-annotations BuildRequires: zip From adam at younglogic.com Fri Nov 18 01:31:30 2011 From: adam at younglogic.com (Adam Young) Date: Thu, 17 Nov 2011 20:31:30 -0500 Subject: [Pki-devel] ASN.1 Extension policy broken? Message-ID: <4EC5B572.4060407@younglogic.com> Is anyone using this? The code has the constructor set the NAME field. But this is a static field; The second and subsequent calls to the constructor override the static value. This value is used to set the Extenions into a static map, so it is possible that this is working due to luck. Any experience with this class: netscape.security.extensions.GenericASN1Extension? Am I missing something? From alee at redhat.com Fri Nov 18 04:37:26 2011 From: alee at redhat.com (Ade Lee) Date: Thu, 17 Nov 2011 23:37:26 -0500 Subject: [Pki-devel] An argument against RESTeasy In-Reply-To: <4EC5ABE8.4030804@redhat.com> References: <4EC5ABE8.4030804@redhat.com> Message-ID: <1321591047.3201.16.camel@aleeredhat.laptop> Adam, Its not that clear. Unfortunately, the dependencies for Jersey are pretty numerous too. I found an rpm for jersey on rpmbone, so the names may be a little different, but still indicative. [alee at localhost SPECS]$ grep BuildRequires jersey.spec BuildRequires: java-devel >= 0:1.6.0 BuildRequires: jpackage-utils >= 0:1.7.5 BuildRequires: ant >= 0:1.7.1 BuildRequires: maven2 >= 0:2.0.8 BuildRequires: maven2-plugin-antrun BuildRequires: maven2-plugin-assembly BuildRequires: maven2-plugin-compiler BuildRequires: maven2-plugin-dependency BuildRequires: maven2-plugin-install BuildRequires: maven2-plugin-jar BuildRequires: maven2-plugin-javadoc BuildRequires: maven2-plugin-resources BuildRequires: maven2-plugin-war BuildRequires: mojo-maven2-plugin-build-helper BuildRequires: mojo-maven2-plugin-buildnumber BuildRequires: mojo-parent BuildRequires: geronimo-genesis BuildRequires: istack-commons-maven-plugin BuildRequires: jetty6-annotations BuildRequires: jetty6-jsp-2.1 BuildRequires: jetty6-maven2-plugins BuildRequires: junit4 BuildRequires: docbook-xsl BuildRequires: geronimo-genesis2 BuildRequires: hc-httpclient BuildRequires: hc-project BuildRequires: jaxb-maven2-plugin BuildRequires: jflex-maven-plugin BuildRequires: oss-parent BuildRequires: saxon BuildRequires: saxon-scripts BuildRequires: testng BuildRequires: tomcat5-jasper BuildRequires: xmlgraphics-fop BuildRequires: annotation_1_0_api BuildRequires: aopalliance BuildRequires: apache-abdera-extensions BuildRequires: apache-abdera-parser BuildRequires: apache-abdera-server BuildRequires: apache-commons-collections BuildRequires: apache-commons-dbcp BuildRequires: apache-commons-httpclient BuildRequires: apache-commons-logging BuildRequires: aspectj BuildRequires: cglib BuildRequires: google-guice BuildRequires: grizzly >= 0:1.9 BuildRequires: hibernate3-entitymanager BuildRequires: hsqldb BuildRequires: jackson BuildRequires: javamail_1_4_api BuildRequires: jcdi_1_0_api BuildRequires: jdom BuildRequires: jettison BuildRequires: jpa_1_0_api BuildRequires: jsp_2_0_api BuildRequires: jsr311-1.1.1-api BuildRequires: jta_1_0_1B_api BuildRequires: objectweb-asm BuildRequires: ops4j-pax-exam BuildRequires: org.osgi.core BuildRequires: rome #BuildRequires: scala BuildRequires: servlet_2_5_api BuildRequires: servlet_3_0_api BuildRequires: simple BuildRequires: slf4j BuildRequires: spring2-all BuildRequires: sun-fi BuildRequires: sun-jaxb-2.1-api BuildRequires: sun-jaxb-2.1-impl BuildRequires: sun-mimepull BuildRequires: wstx BuildRequires: xerces-j2 On Thu, 2011-11-17 at 19:50 -0500, Adam Young wrote: > As I suspected, the dependencies for RESTeasy are too numerous. I thin > we need to go with Jersey. > > grep BuildRequires ~/rpmbuild/SPECS/resteasy.spec > BuildRequires: jpackage-utils > BuildRequires: java > BuildRequires: java-devel > BuildRequires: maven2 > BuildRequires: maven-compiler-plugin > BuildRequires: maven-javadoc-plugin > BuildRequires: maven-install-plugin > BuildRequires: maven-site-plugin > BuildRequires: maven-source-plugin > BuildRequires: maven-resources-plugin > BuildRequires: maven-surefire-plugin > BuildRequires: maven-jar-plugin > #BuildRequires: maven-jdocbook-plugin > BuildRequires: maven-assembly-plugin > BuildRequires: jboss-jaxrpc-api_1.1_spec > BuildRequires: jboss-servlet-api_3.0_spec > BuildRequires: jboss-el-api_2.2_spec > BuildRequires: jboss-ejb-api_3.1_spec > BuildRequires: weld-cdi-1.0-api > BuildRequires: codehaus-stax11-api > BuildRequires: jboss-el > BuildRequires: hibernate3-ejb-persistence-3.0-api > #BuildRequires: hc-httpcore > #BuildRequires: hc-httpclient > BuildRequires: httpcomponents-project = 4.1.1-0.2.ep6.el6 > BuildRequires: httpcomponents-httpcore = 4.1.3-0.2.ep6.el6 > BuildRequires: httpcomponents-httpclient = 4.1.1-0.2.ep6.el6 > BuildRequires: glassfish-jaxws > #BuildRequires: xmlgraphics-batik > #BuildRequires: xmlgraphics-commons > #BuildRequires: xml-commons-resolver > BuildRequires: javassist >= 0:3.9.0 > BuildRequires: glassfish-javamail > BuildRequires: glassfish-jaxb >= 0:2.1.9 > #BuildRequires: glassfish-jaxws > BuildRequires: sun-sjsxp >= 0:1.0.1 > BuildRequires: tomcat6-lib >= 0:6.0.32 > BuildRequires: jaxen >= 0:1.1.2 > BuildRequires: jgroups >= 0:2.6.19 > BuildRequires: junit4 > BuildRequires: apache-abdera-core >= 0:0.4.0 > BuildRequires: apache-abdera-parser >= 0:0.4.0 > BuildRequires: apache-abdera-client >= 0:0.4.0 > BuildRequires: apache-abdera-dependencies >= 0:0.4.0 > BuildRequires: apache-james >= 0:0.6 > BuildRequires: ws-commons-axiom >= 0:1.2.7 > BuildRequires: codehaus-jackson-core-asl >= 0:1.0.1 > BuildRequires: codehaus-jackson-jaxrs >= 0:1.0.1 > BuildRequires: codehaus-jackson-mapper-asl >= 0:1.0.1 > BuildRequires: codehaus-jackson-xc > BuildRequires: jettison >= 0:1.2 > BuildRequires: wstx >= 0:3.2.8 > BuildRequires: jboss-cache-core >= 0:3.2.7 > BuildRequires: jboss-common-core >= 0:2.2.17 > BuildRequires: jboss-common-logging-spi >= 0:2.1.2 > BuildRequires: jboss-parent > BuildRequires: jyaml >= 0:1.3 > BuildRequires: richfaces-highlight > BuildRequires: richfaces-docs > BuildRequires: richfaces-root > BuildRequires: scannotation >= 0:1.0.2 > BuildRequires: slf4j >= 0:1.5.8 > BuildRequires: xalan-j2 >= 0:2.7.0 > BuildRequires: xerces-j2 >= 0:2.9.1 > BuildRequires: xml-commons >= 0:1.3.03 > BuildRequires: xpp3-minimal >= 0:1.1.3.4 > BuildRequires: jcip-annotations > BuildRequires: zip > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From ayoung at redhat.com Fri Nov 18 17:54:10 2011 From: ayoung at redhat.com (Adam Young) Date: Fri, 18 Nov 2011 12:54:10 -0500 Subject: [Pki-devel] POM deps for Jersey Message-ID: <4EC69BC2.2060009@redhat.com> I first ran the maven Archtype for a Jersey web app and then compiled it. Both before starting and In between the two steps I wiped out my local Maven repository to be able to distinguish waht was necessary. Here are the list of jars pulled down in the second stage. javax/ws/rs/jsr311-api/0.8/jsr311-api-0.8.jar junit/junit/3.8.1/junit-3.8.1.jar commons-cli/commons-cli/1.0/commons-cli-1.0.jar org/sonatype/plexus/plexus-build-api/0.0.4/plexus-build-api-0.0.4.jar org/codehaus/mojo/tomcat-maven-plugin/1.1/tomcat-maven-plugin-1.1.jar org/codehaus/plexus/plexus-interpolation/1.13/plexus-interpolation-1.13.jar org/codehaus/plexus/plexus-utils/2.0.5/plexus-utils-2.0.5.jar org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar org/codehaus/plexus/plexus-compiler-api/1.8.1/plexus-compiler-api-1.8.1.jar org/codehaus/plexus/plexus-compiler-javac/1.8.1/plexus-compiler-javac-1.8.1.jar org/codehaus/plexus/plexus-compiler-manager/1.8.1/plexus-compiler-manager-1.8.1.jar org/apache/maven/doxia/doxia-sink-api/1.0-alpha-7/doxia-sink-api-1.0-alpha-7.jar org/apache/maven/shared/maven-filtering/1.0-beta-4/maven-filtering-1.0-beta-4.jar org/apache/maven/plugins/maven-compiler-plugin/2.3.2/maven-compiler-plugin-2.3.2.jar org/apache/maven/plugins/maven-resources-plugin/2.4.3/maven-resources-plugin-2.4.3.jar org/apache/maven/reporting/maven-reporting-api/2.0.6/maven-reporting-api-2.0.6.jar asm/asm/3.1/asm-3.1.jar com/sun/jersey/jersey/0.8-ea-SNAPSHOT/jersey-0.8-ea-SNAPSHOT.jar I'm guessing these fall into two groups: those needed for building any web app and those specific to Jersey. Maven is fairly well covered by Fedora, so I don't think w'll have too much trouble there. JUnit is in Fedora. commons-cli is in fedora jsr311 is probably just a small set of source file, but it is not in Fedora. Specific to Jersey are these: edited out of the Jersey POM javax.ws.rs.jsr311-api version 0.8 javax.annotation.jsr250-api version 1.0 javax.persistence.persistence-api version 1.0.2 javax.servlet.servlet-api version 2.5 asm.asm version 3.1 NOte that does not indicated what is needed to build Jersey, merely what it requires to build another project. Pulling the Jersey source into Eclipse without and jars to fill in dependencies is more interesting. To build, it refers to a bunch of the Sun classes in the JREs rt.jar, which have access prohibited. we can work around this with a symlink. Other jars I started pulling in The only one I haven't found so far is Which appears to be Weld, or the reference implementation of JSR-299. This looks interesting in its own right. From ayoung at redhat.com Fri Nov 18 18:00:17 2011 From: ayoung at redhat.com (Adam Young) Date: Fri, 18 Nov 2011 13:00:17 -0500 Subject: [Pki-devel] POM deps for Jersey In-Reply-To: <4EC69BC2.2060009@redhat.com> References: <4EC69BC2.2060009@redhat.com> Message-ID: <4EC69D31.1020804@redhat.com> On 11/18/2011 12:54 PM, Adam Young wrote: > I first ran the maven Archtype for a Jersey web app and then compiled > it. Both before starting and In between the two steps I wiped out my > local Maven repository to be able to distinguish waht was necessary. > > Here are the list of jars pulled down in the second stage. > > javax/ws/rs/jsr311-api/0.8/jsr311-api-0.8.jar > junit/junit/3.8.1/junit-3.8.1.jar > commons-cli/commons-cli/1.0/commons-cli-1.0.jar > org/sonatype/plexus/plexus-build-api/0.0.4/plexus-build-api-0.0.4.jar > org/codehaus/mojo/tomcat-maven-plugin/1.1/tomcat-maven-plugin-1.1.jar > org/codehaus/plexus/plexus-interpolation/1.13/plexus-interpolation-1.13.jar > > org/codehaus/plexus/plexus-utils/2.0.5/plexus-utils-2.0.5.jar > org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar > > org/codehaus/plexus/plexus-compiler-api/1.8.1/plexus-compiler-api-1.8.1.jar > > org/codehaus/plexus/plexus-compiler-javac/1.8.1/plexus-compiler-javac-1.8.1.jar > > org/codehaus/plexus/plexus-compiler-manager/1.8.1/plexus-compiler-manager-1.8.1.jar > > org/apache/maven/doxia/doxia-sink-api/1.0-alpha-7/doxia-sink-api-1.0-alpha-7.jar > > org/apache/maven/shared/maven-filtering/1.0-beta-4/maven-filtering-1.0-beta-4.jar > > org/apache/maven/plugins/maven-compiler-plugin/2.3.2/maven-compiler-plugin-2.3.2.jar > > org/apache/maven/plugins/maven-resources-plugin/2.4.3/maven-resources-plugin-2.4.3.jar > > org/apache/maven/reporting/maven-reporting-api/2.0.6/maven-reporting-api-2.0.6.jar > > asm/asm/3.1/asm-3.1.jar > com/sun/jersey/jersey/0.8-ea-SNAPSHOT/jersey-0.8-ea-SNAPSHOT.jar > > > I'm guessing these fall into two groups: those needed for building > any web app and those specific to Jersey. Maven is fairly well > covered by Fedora, so I don't think w'll have too much trouble there. > JUnit is in Fedora. > commons-cli is in fedora > > jsr311 is probably just a small set of source file, but it is not in > Fedora. > > Specific to Jersey are these: edited out of the Jersey POM > > javax.ws.rs.jsr311-api version 0.8 > javax.annotation.jsr250-api version 1.0 > javax.persistence.persistence-api version 1.0.2 > javax.servlet.servlet-api version 2.5 > asm.asm version 3.1 > > NOte that does not indicated what is needed to build Jersey, merely > what it requires to build another project. > > > Pulling the Jersey source into Eclipse without and jars to fill in > dependencies is more interesting. > > To build, it refers to a bunch of the Sun classes in the JREs > rt.jar, which have access prohibited. we can work around this with a > symlink. > > > Other jars I started pulling in > > > path="/usr/share/java/geronimo-annotation.jar"/> > > path="/usr/share/java/felix/org.osgi.core.jar"/> > > > > path="/usr/share/java/tomcat6/annotations-api.jar"/> > > > > path="/usr/share/java/tomcat-servlet-3.0-api.jar"/> > path="/usr/share/java/geronimo-interceptor.jar"/> > > > > The only one I haven't found so far is > path="/home/ayoung/.m2/repository/javax/enterprise/cdi-api/1.1.EDR1.1/cdi-api-1.1.EDR1.1.jar"/> > > Which appears to be Weld, or the reference implementation of > JSR-299. This looks interesting in its own right. A little more digging on weld. I pulled in the cdi-api Source files into the same project. I can get the whole thing to compile if I add in With the exception of javax.enterprise.inject.spi.BeforeBeanDiscovery which has an import that it doesn't use: javax.interceptor.InterceptorBinding; If I comment out that line, it builds. We should be able to make this work in Fedora. 2 new packages (Jersey and cdi-api) are not that bad a payback for the amount of reuse we will get. From alee at redhat.com Fri Nov 18 20:51:38 2011 From: alee at redhat.com (Ade Lee) Date: Fri, 18 Nov 2011 15:51:38 -0500 Subject: [Pki-devel] code formatting on the trunk Message-ID: <1321649499.3201.31.camel@aleeredhat.laptop> Hi all, One of the things that came up recently is the idea of doing an automatic reformatting of the code to match the project's coding standards (after they have been reviewed). This would provide a nice, clean basis on which any future development would occur - and by setting up eclipse appropriately, any new code could be assured to follow the coding standards. So if we do this, I'd like to do it as soon as possible so that future changes are not obscured. A couple of concerns: 1. Once this is done on the trunk, merges of code fixes from the 8.X branch to trunk will be much more difficult - in fact they may all be manual. 2. Auto-reformatting may actually result in code that is less readable in some cases. That is, in some cases, the developer deliberately formatted things in such a way as to improve readability. 3. We may make it more difficult to track history on the trunk. But this is mitigated by the fact that history is present on the 8.x branch. The alternative is to just ensure coding standards are met in any new code added. What does everyone think? Ade From ayoung at redhat.com Sat Nov 19 01:19:09 2011 From: ayoung at redhat.com (Adam Young) Date: Fri, 18 Nov 2011 20:19:09 -0500 Subject: [Pki-devel] code formatting on the trunk In-Reply-To: <1321649499.3201.31.camel@aleeredhat.laptop> References: <1321649499.3201.31.camel@aleeredhat.laptop> Message-ID: <4EC7040D.3000303@redhat.com> On 11/18/2011 03:51 PM, Ade Lee wrote: > Hi all, > > One of the things that came up recently is the idea of doing an > automatic reformatting of the code to match the project's coding > standards (after they have been reviewed). This would provide a nice, > clean basis on which any future development would occur - and by setting > up eclipse appropriately, any new code could be assured to follow the > coding standards. > > So if we do this, I'd like to do it as soon as possible so that future > changes are not obscured. > > A couple of concerns: > 1. Once this is done on the trunk, merges of code fixes from the 8.X > branch to trunk will be much more difficult - in fact they may all be > manual. > 2. Auto-reformatting may actually result in code that is less readable > in some cases. That is, in some cases, the developer deliberately > formatted things in such a way as to improve readability. > 3. We may make it more difficult to track history on the trunk. But > this is mitigated by the fact that history is present on the 8.x branch. > > The alternative is to just ensure coding standards are met in any new > code added. > > What does everyone think? > > Ade > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel I'm all for it. From ayoung at redhat.com Mon Nov 21 01:57:12 2011 From: ayoung at redhat.com (Adam Young) Date: Sun, 20 Nov 2011 20:57:12 -0500 Subject: [Pki-devel] [PATCH] 0012-Dead-code-removal In-Reply-To: <4EC3D7C3.9060407@redhat.com> References: <4EBB1FF0.90409@redhat.com> <1321337517.6303.155.camel@aleeredhat.laptop> <4EC3D7C3.9060407@redhat.com> Message-ID: <4EC9AFF8.2060209@redhat.com> On 11/16/2011 10:33 AM, Adam Young wrote: > On 11/15/2011 01:11 AM, Ade Lee wrote: >> This is a review of this patch and the subsequent one removing >> unnecessary blocks. >> >> CMCAuth.java: Can you explain why this code removal is correct? > > At this point in the code, cert can only be null. The only code path > that assigns a value to cert has a return after it, and cannot reach > this point. Thus, the code executed when cert != null is unreachable > >> >> CAAdminServlet.java : code should be commented out, rather than removed. > > Disagree. If this code has never been run, it is unnecessary. Lets > not put dead code into the source tree. >> >> HashEnrollServlet.java : remove the outer conditional as well. > Done >> DBSubsystem.java: some important comments are removed, they should not >> be removed. > > Done >> >> FileAsString.java - does the proposed code removal introduce a resource >> leak? > > No. FileReader can throw a file not found exception. But > BufferedReader only throws an IllegalArgumentException, which > wouldn't be caught by that catch block anyway. > >> >> KeyRecoveryAuthority.java: please explain why the proposed code removal >> is correct. It certainly looks wrong. > I agree that the change looks wrong. I put it back in, and Eclipse > did not tag it as dead code. >> >> Ade >> >> On Wed, 2011-11-09 at 19:50 -0500, Adam Young wrote: >>> _______________________________________________ >>> Pki-devel mailing list >>> Pki-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-devel >> > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel Is that an ACK? -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Mon Nov 21 14:29:13 2011 From: alee at redhat.com (Ade Lee) Date: Mon, 21 Nov 2011 09:29:13 -0500 Subject: [Pki-devel] POM deps for Jersey In-Reply-To: <4EC69BC2.2060009@redhat.com> References: <4EC69BC2.2060009@redhat.com> Message-ID: <1321885753.2265.18.camel@aleeredhat.laptop> Adam, I'm not sure what you built - but your build seems to lack a lot of key dependencies. I pulled down the jersey source from svn and tried to build it using eclipse (and immediately ran into 50K+ build errors). I then built it in maven and noticed something like 450 jars being pulled in. Now granted, lots of these are duplicate versions - and some of these are in fedora - but a lot of them are not. I tried to figure out which ones are provided by fedora but its slow going. Attached is the list of jars pulled in (pulled_jars) and a slightly more whittled down list after removing multiple versions or seeing the jar in fedora. The whittled down list can probably be whittled down further. Its still over 250 jars long though. Even if we managed to whittle down much further its likely we will end up with over 100 jars that we would need to shepherd through fedora and rhel acceptance. Including a few that would be unacceptable in fedora/rhel. As you say, resteasy is probably a little worse - although in this case, we *might* be able to find folks to maintain some parts of this. So this begs the question - are either of these frameworks feasible for us to use at the current time? Ade On Fri, 2011-11-18 at 12:54 -0500, Adam Young wrote: > I first ran the maven Archtype for a Jersey web app and then compiled > it. Both before starting and In between the two steps I wiped out my > local Maven repository to be able to distinguish waht was necessary. > > Here are the list of jars pulled down in the second stage. > > javax/ws/rs/jsr311-api/0.8/jsr311-api-0.8.jar > junit/junit/3.8.1/junit-3.8.1.jar > commons-cli/commons-cli/1.0/commons-cli-1.0.jar > org/sonatype/plexus/plexus-build-api/0.0.4/plexus-build-api-0.0.4.jar > org/codehaus/mojo/tomcat-maven-plugin/1.1/tomcat-maven-plugin-1.1.jar > org/codehaus/plexus/plexus-interpolation/1.13/plexus-interpolation-1.13.jar > org/codehaus/plexus/plexus-utils/2.0.5/plexus-utils-2.0.5.jar > org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar > org/codehaus/plexus/plexus-compiler-api/1.8.1/plexus-compiler-api-1.8.1.jar > org/codehaus/plexus/plexus-compiler-javac/1.8.1/plexus-compiler-javac-1.8.1.jar > org/codehaus/plexus/plexus-compiler-manager/1.8.1/plexus-compiler-manager-1.8.1.jar > org/apache/maven/doxia/doxia-sink-api/1.0-alpha-7/doxia-sink-api-1.0-alpha-7.jar > org/apache/maven/shared/maven-filtering/1.0-beta-4/maven-filtering-1.0-beta-4.jar > org/apache/maven/plugins/maven-compiler-plugin/2.3.2/maven-compiler-plugin-2.3.2.jar > org/apache/maven/plugins/maven-resources-plugin/2.4.3/maven-resources-plugin-2.4.3.jar > org/apache/maven/reporting/maven-reporting-api/2.0.6/maven-reporting-api-2.0.6.jar > asm/asm/3.1/asm-3.1.jar > com/sun/jersey/jersey/0.8-ea-SNAPSHOT/jersey-0.8-ea-SNAPSHOT.jar > > > I'm guessing these fall into two groups: those needed for building any > web app and those specific to Jersey. Maven is fairly well covered by > Fedora, so I don't think w'll have too much trouble there. > JUnit is in Fedora. > commons-cli is in fedora > > jsr311 is probably just a small set of source file, but it is not in > Fedora. > > Specific to Jersey are these: edited out of the Jersey POM > > javax.ws.rs.jsr311-api version 0.8 > javax.annotation.jsr250-api version 1.0 > javax.persistence.persistence-api version 1.0.2 > javax.servlet.servlet-api version 2.5 > asm.asm version 3.1 > > NOte that does not indicated what is needed to build Jersey, merely > what it requires to build another project. > > > Pulling the Jersey source into Eclipse without and jars to fill in > dependencies is more interesting. > > To build, it refers to a bunch of the Sun classes in the JREs rt.jar, > which have access prohibited. we can work around this with a symlink. > > > Other jars I started pulling in > > > > > > > > > path="/usr/share/java/tomcat6/annotations-api.jar"/> > > > > path="/usr/share/java/tomcat-servlet-3.0-api.jar"/> > > > > > The only one I haven't found so far is > path="/home/ayoung/.m2/repository/javax/enterprise/cdi-api/1.1.EDR1.1/cdi-api-1.1.EDR1.1.jar"/> > > Which appears to be Weld, or the reference implementation of JSR-299. > This looks interesting in its own right. -------------- next part -------------- ./de/zeigermann/xml/xml-im-exporter/1.1/xml-im-exporter-1.1.jar ./stax/stax-api/1.0.1/stax-api-1.0.1.jar ./com/agilejava/docbkx/docbkx-maven-plugin/2.0.11/docbkx-maven-plugin-2.0.11.jar ./com/google/inject/extensions/guice-servlet/3.0/guice-servlet-3.0.jar ./com/google/code/maven-scm-provider-svnjava/maven-scm-provider-svnjava/1.8/maven-scm-provider-svnjava-1.8.jar ./com/sun/codemodel/codemodel/2.4/codemodel-2.4.jar ./com/sun/xml/bind/jaxb-xjc/2.1.12/jaxb-xjc-2.1.12.jar ./com/sun/xml/bind/jaxb-impl/2.1.12/jaxb-impl-2.1.12.jar ./com/sun/xml/fastinfoset/FastInfoset/1.2.9/FastInfoset-1.2.9.jar ./com/sun/net/httpserver/http/20070405/http-20070405.jar ./com/sun/istack/maven-istack-commons-plugin/2.4/maven-istack-commons-plugin-2.4.jar ./com/sun/jersey/jersey-client/1.11-SNAPSHOT/jersey-client-1.11-SNAPSHOT.jar ./com/sun/jersey/jersey-json/1.11-SNAPSHOT/jersey-json-1.11-SNAPSHOT.jar ./com/sun/jersey/jersey-grizzly/1.11-SNAPSHOT/jersey-grizzly-1.11-SNAPSHOT.jar ./com/sun/jersey/jersey-core/1.11-SNAPSHOT/jersey-core-1.11-SNAPSHOT.jar ./com/sun/jersey/contribs/wadl-resourcedoc-doclet/1.11-SNAPSHOT/wadl-resourcedoc-doclet-1.11-SNAPSHOT.jar ./com/sun/jersey/jersey-servlet/1.11-SNAPSHOT/jersey-servlet-1.11-SNAPSHOT.jar ./com/sun/jersey/jersey-server/1.11-SNAPSHOT/jersey-server-1.11-SNAPSHOT.jar ./com/sun/tools/xjc/maven2/maven-jaxb-plugin/1.1.1/maven-jaxb-plugin-1.1.1.jar ./com/sun/grizzly/grizzly-http-servlet/1.9.36/grizzly-http-servlet-1.9.36.jar ./com/sun/grizzly/grizzly-rcm/1.9.36/grizzly-rcm-1.9.36.jar ./com/sun/grizzly/grizzly-framework/1.9.36/grizzly-framework-1.9.36.jar ./com/sun/grizzly/grizzly-http-webserver/1.9.36/grizzly-http-webserver-1.9.36.jar ./com/sun/grizzly/grizzly-servlet-webserver/1.9.36/grizzly-servlet-webserver-1.9.36.jar ./com/sun/grizzly/grizzly-portunif/1.9.36/grizzly-portunif-1.9.36.jar ./com/sun/grizzly/grizzly-http/1.9.36/grizzly-http-1.9.36.jar ./com/sun/grizzly/grizzly-lzma/1.9.36/grizzly-lzma-1.9.36.jar ./com/sun/grizzly/grizzly-utils/1.9.36/grizzly-utils-1.9.36.jar ./javax/activation/activation/1.1/activation-1.1.jar ./javax/mail/mail/1.4.2/mail-1.4.2.jar ./javax/enterprise/cdi-api/1.0-SP4/cdi-api-1.0-SP4.jar ./javax/inject/javax.inject/1/javax.inject-1.jar ./javax/xml/bind/jsr173_api/1.0/jsr173_api-1.0.jar ./javax/xml/bind/jaxb-api/2.1/jaxb-api-2.1.jar ./javax/xml/stream/stax-api/1.0-2/stax-api-1.0-2.jar ./javax/xml/jsr173/1.0/jsr173-1.0.jar ./javax/el/el-api/2.2/el-api-2.2.jar ./javax/servlet/jstl/1.2/jstl-1.2.jar ./javax/servlet/servlet-api/2.5/servlet-api-2.5.jar ./javax/servlet/javax.servlet-api/3.0.1/javax.servlet-api-3.0.1.jar ./javax/servlet/jsp-api/2.0/jsp-api-2.0.jar ./javax/persistence/persistence-api/1.0/persistence-api-1.0.jar ./javax/ws/rs/jsr311-api/1.1.1/jsr311-api-1.1.1-sources.jar ./javax/ws/rs/jsr311-api/1.1.1/jsr311-api-1.1.1.jar ./javax/annotation/jsr250-api/1.0/jsr250-api-1.0.jar ./commons-fileupload/commons-fileupload/1.2.1/commons-fileupload-1.2.1.jar ./slide/slide-webdavlib/2.1/slide-webdavlib-2.1.jar ./commons-beanutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0.jar ./hsqldb/hsqldb/1.8.0.7/hsqldb-1.8.0.7.jar ./asm/asm/3.1/asm-3.1.jar ./asm/asm-all/3.1/asm-all-3.1.jar ./net/liftweb/lift-webkit/1.1-M7/lift-webkit-1.1-M7.jar ./net/liftweb/lift-common/1.1-M7/lift-common-1.1-M7.jar ./net/liftweb/lift-actor/1.1-M7/lift-actor-1.1-M7.jar ./net/liftweb/lift-util/1.1-M7/lift-util-1.1-M7.jar ./net/sourceforge/jwebunit/jwebunit-core/1.4.1/jwebunit-core-1.4.1.jar ./net/sourceforge/jwebunit/jwebunit-htmlunit-plugin/1.4.1/jwebunit-htmlunit-plugin-1.4.1.jar ./net/sf/kxml/kxml2/2.2.2/kxml2-2.2.2.jar ./net/sf/retrotranslator/retrotranslator-runtime/1.2.1/retrotranslator-runtime-1.2.1.jar ./net/sf/alchim/yuicompressor-maven-plugin/0.7.1/yuicompressor-maven-plugin-0.7.1.jar ./biz/aQute/bndlib/0.0.313/bndlib-0.0.313.jar ./commons-dbcp/commons-dbcp/1.2.1/commons-dbcp-1.2.1.jar ./velocity/velocity-dep/1.4/velocity-dep-1.4.jar ./xmlpull/xmlpull/1.1.3.1/xmlpull-1.1.3.1.jar ./ch/qos/cal10n/cal10n-api/0.7.2/cal10n-api-0.7.2.jar ./woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.jar ./nekohtml/nekohtml/0.9.5/nekohtml-0.9.5.jar ./aopalliance/aopalliance/1.0/aopalliance-1.0.jar ./org/apache/geronimo/specs/geronimo-activation_1.0.2_spec/1.1/geronimo-activation_1.0.2_spec-1.1.jar ./org/apache/geronimo/specs/geronimo-stax-api_1.0_spec/1.0.1/geronimo-stax-api_1.0_spec-1.0.1.jar ./org/apache/servicemix/tooling/depends-maven-plugin/1.1/depends-maven-plugin-1.1.jar ./org/apache/abdera/abdera-extensions-html/1.0/abdera-extensions-html-1.0.jar ./org/apache/abdera/abdera-parser/1.0/abdera-parser-1.0.jar ./org/apache/abdera/abdera-core/1.0/abdera-core-1.0.jar ./org/apache/abdera/abdera-i18n/1.0/abdera-i18n-1.0.jar ./org/apache/abdera/abdera-extensions-main/1.0/abdera-extensions-main-1.0.jar ./org/apache/abdera/abdera-client/1.0/abdera-client-1.0.jar ./org/apache/abdera/abdera-server/1.0/abdera-server-1.0.jar ./org/apache/abdera/abdera-extensions-json/1.0/abdera-extensions-json-1.0.jar ./org/apache/felix/org.osgi.core/1.0.0/org.osgi.core-1.0.0.jar ./org/apache/felix/org.osgi.service.obr/1.0.1/org.osgi.service.obr-1.0.1.jar ./org/apache/maven/plugins/maven-javadoc-plugin/2.5/maven-javadoc-plugin-2.5.jar ./org/apache/maven/plugins/maven-javadoc-plugin/2.4/maven-javadoc-plugin-2.4.jar ./org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.jar ./org/apache/maven/plugins/maven-eclipse-plugin/2.6/maven-eclipse-plugin-2.6.jar ./org/apache/maven/plugins/maven-resources-plugin/2.4.3/maven-resources-plugin-2.4.3.jar ./org/apache/maven/plugins/maven-source-plugin/2.1.1/maven-source-plugin-2.1.1.jar ./org/apache/maven/plugins/maven-dependency-plugin/2.0/maven-dependency-plugin-2.0.jar ./org/apache/maven/plugins/maven-jar-plugin/2.2/maven-jar-plugin-2.2.jar ./org/apache/maven/plugins/maven-plugin-plugin/2.4/maven-plugin-plugin-2.4.jar ./org/apache/maven/plugins/maven-assembly-plugin/2.2-beta-5/maven-assembly-plugin-2.2-beta-5.jar ./org/apache/maven/plugins/maven-assembly-plugin/2.2-beta-2/maven-assembly-plugin-2.2-beta-2.jar ./org/apache/maven/plugins/maven-clean-plugin/2.2/maven-clean-plugin-2.2.jar ./org/apache/maven/maven-project/2.0.9/maven-project-2.0.9.jar ./org/apache/maven/maven-settings/2.0.9/maven-settings-2.0.9.jar ./org/apache/maven/maven-plugin-registry/2.0.9/maven-plugin-registry-2.0.9.jar ./org/apache/maven/maven-plugin-descriptor/2.0.9/maven-plugin-descriptor-2.0.9.jar ./org/apache/maven/maven-monitor/2.0.9/maven-monitor-2.0.9.jar ./org/apache/maven/maven-error-diagnostics/2.0.9/maven-error-diagnostics-2.0.9.jar ./org/apache/maven/apache-maven/2.0.9/apache-maven-2.0.9.jar ./org/apache/maven/maven-profile/2.0.9/maven-profile-2.0.9.jar ./org/apache/maven/maven-toolchain/2.0.9/maven-toolchain-2.0.9.jar ./org/apache/maven/maven-artifact-manager/2.0.9/maven-artifact-manager-2.0.9.jar ./org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar ./org/apache/maven/maven-model/2.0.9/maven-model-2.0.9.jar ./org/apache/maven/maven-core/2.0.9/maven-core-2.0.9.jar ./org/apache/maven/maven-archiver/2.2/maven-archiver-2.2.jar ./org/apache/maven/maven-plugin-parameter-documenter/2.0.9/maven-plugin-parameter-documenter-2.0.9.jar ./org/apache/maven/wagon/wagon-webdav/1.0-beta-2/wagon-webdav-1.0-beta-2.jar ./org/apache/maven/wagon/wagon-http-shared/1.0-beta-2/wagon-http-shared-1.0-beta-2.jar ./org/apache/maven/wagon/wagon-http-lightweight/1.0-beta-2/wagon-http-lightweight-1.0-beta-2.jar ./org/apache/maven/wagon/wagon-file/1.0-beta-2/wagon-file-1.0-beta-2.jar ./org/apache/maven/wagon/wagon-ssh-common/1.0-beta-2/wagon-ssh-common-1.0-beta-2.jar ./org/apache/maven/wagon/wagon-ssh/1.0-beta-2/wagon-ssh-1.0-beta-2.jar ./org/apache/maven/wagon/wagon-ssh-external/1.0-beta-2/wagon-ssh-external-1.0-beta-2.jar ./org/apache/maven/wagon/wagon-provider-api/1.0-beta-2/wagon-provider-api-1.0-beta-2.jar ./org/apache/maven/maven-repository-metadata/2.0.9/maven-repository-metadata-2.0.9.jar ./org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.jar ./org/apache/maven/reporting/maven-reporting-impl/2.0.4/maven-reporting-impl-2.0.4.jar ./org/apache/maven/maven-artifact/2.0.9/maven-artifact-2.0.9.jar ./org/apache/maven/shared/maven-common-artifact-filters/1.2/maven-common-artifact-filters-1.2.jar ./org/apache/maven/shared/maven-common-artifact-filters/1.0/maven-common-artifact-filters-1.0.jar ./org/apache/maven/shared/file-management/1.2/file-management-1.2.jar ./org/apache/maven/shared/file-management/1.1/file-management-1.1.jar ./org/apache/maven/shared/maven-plugin-testing-harness/1.1/maven-plugin-testing-harness-1.1.jar ./org/apache/maven/shared/maven-filtering/1.0-beta-4/maven-filtering-1.0-beta-4.jar ./org/apache/maven/shared/maven-dependency-analyzer/1.1/maven-dependency-analyzer-1.1.jar ./org/apache/maven/shared/maven-dependency-analyzer/1.0/maven-dependency-analyzer-1.0.jar ./org/apache/maven/shared/maven-shared-io/1.1/maven-shared-io-1.1.jar ./org/apache/maven/shared/maven-shared-io/1.0/maven-shared-io-1.0.jar ./org/apache/maven/shared/maven-osgi/0.2.0/maven-osgi-0.2.0.jar ./org/apache/maven/shared/maven-dependency-tree/1.2/maven-dependency-tree-1.2.jar ./org/apache/maven/shared/maven-dependency-tree/1.1/maven-dependency-tree-1.1.jar ./org/apache/maven/plugin-tools/maven-plugin-tools-beanshell/2.4/maven-plugin-tools-beanshell-2.4.jar ./org/apache/maven/plugin-tools/maven-plugin-tools-java/2.4/maven-plugin-tools-java-2.4.jar ./org/apache/maven/plugin-tools/maven-plugin-tools-api/2.4/maven-plugin-tools-api-2.4.jar ./org/apache/maven/scm/maven-scm-api/1.2/maven-scm-api-1.2.jar ./org/apache/maven/scm/maven-scm-provider-perforce/1.2/maven-scm-provider-perforce-1.2.jar ./org/apache/maven/scm/maven-scm-provider-starteam/1.2/maven-scm-provider-starteam-1.2.jar ./org/apache/maven/scm/maven-scm-provider-hg/1.2/maven-scm-provider-hg-1.2.jar ./org/apache/maven/scm/maven-scm-provider-cvsexe/1.2/maven-scm-provider-cvsexe-1.2.jar ./org/apache/maven/scm/maven-scm-provider-cvs-commons/1.2/maven-scm-provider-cvs-commons-1.2.jar ./org/apache/maven/scm/maven-scm-provider-clearcase/1.2/maven-scm-provider-clearcase-1.2.jar ./org/apache/maven/scm/maven-scm-manager-plexus/1.2/maven-scm-manager-plexus-1.2.jar ./org/apache/maven/scm/maven-scm-provider-svn-commons/1.2/maven-scm-provider-svn-commons-1.2.jar ./org/apache/maven/scm/maven-scm-provider-svnexe/1.2/maven-scm-provider-svnexe-1.2.jar ./org/apache/ws/commons/axiom/axiom-impl/1.2.5/axiom-impl-1.2.5.jar ./org/apache/ws/commons/axiom/axiom-api/1.2.5/axiom-api-1.2.5.jar ./org/sonatype/plexus/plexus-build-api/0.0.4/plexus-build-api-0.0.4.jar ./org/eclipse/persistence/org.eclipse.persistence.asm/2.2.0-M6/org.eclipse.persistence.asm-2.2.0-M6.jar ./org/eclipse/persistence/org.eclipse.persistence.core/2.2.0-M6/org.eclipse.persistence.core-2.2.0-M6.jar ./org/eclipse/persistence/org.eclipse.persistence.moxy/2.2.0-M6/org.eclipse.persistence.moxy-2.2.0-M6.jar ./org/eclipse/persistence/org.eclipse.persistence.antlr/2.2.0-M6/org.eclipse.persistence.antlr-2.2.0-M6.jar ./org/jboss/interceptor/jboss-interceptor-spi/2.0.0.CR1/jboss-interceptor-spi-2.0.0.CR1.jar ./org/jboss/interceptor/jboss-interceptor-core/2.0.0.CR1/jboss-interceptor-core-2.0.0.CR1.jar ./org/jboss/weld/weld-osgi-bundle/1.1.2.Final/weld-osgi-bundle-1.1.2.Final.jar ./org/jboss/weld/weld-api/1.1.Beta2/weld-api-1.1.Beta2.jar ./org/jboss/weld/weld-core/1.1.2.Final/weld-core-1.1.2.Final.jar ./org/jboss/weld/weld-spi/1.1.Beta2/weld-spi-1.1.Beta2.jar ./org/jboss/spec/javax/interceptor/jboss-interceptors-api_1.1_spec/1.0.0.Beta1/jboss-interceptors-api_1.1_spec-1.0.0.Beta1.jar ./org/springframework/spring-aop/2.5.6/spring-aop-2.5.6.jar ./org/springframework/spring-context/2.5.6/spring-context-2.5.6.jar ./org/springframework/spring-beans/2.5.6/spring-beans-2.5.6.jar ./org/springframework/spring/2.5.5/spring-2.5.5.jar ./org/springframework/spring-web/2.5.6/spring-web-2.5.6.jar ./org/springframework/spring-core/2.5.6/spring-core-2.5.6.jar ./org/aspectj/aspectjweaver/1.5.4/aspectjweaver-1.5.4.jar ./org/aspectj/aspectjrt/1.5.4/aspectjrt-1.5.4.jar ./org/zeroturnaround/jr-sdk/3.1.2/jr-sdk-3.1.2.jar ./org/zeroturnaround/jr-javassist/3.8.0.GA/jr-javassist-3.8.0.GA.jar ./org/zeroturnaround/jrebel-maven-plugin/1.0.7/jrebel-maven-plugin-1.0.7.jar ./org/mortbay/jetty/jetty-util/6.1.19/jetty-util-6.1.19.jar ./org/mortbay/jetty/servlet-api/2.5-20081211/servlet-api-2.5-20081211.jar ./org/mortbay/jetty/maven-jetty-plugin/6.1.15/maven-jetty-plugin-6.1.15.jar ./org/mortbay/jetty/jetty/6.1.19/jetty-6.1.19.jar ./org/testng/testng/5.5/testng-5.5-jdk15.jar ./org/scala-tools/testing/specs/1.6.2.2/specs-1.6.2.2.jar ./org/scala-tools/testing/scalacheck/1.5/scalacheck-1.5.jar ./org/scala-tools/testing/scalatest/0.9.4/scalatest-0.9.4.jar ./org/scala-tools/maven-scala-plugin/2.10.1/maven-scala-plugin-2.10.1.jar ./org/codehaus/jackson/jackson-jaxrs/1.9.0/jackson-jaxrs-1.9.0.jar ./org/codehaus/jackson/jackson-core-asl/1.9.0/jackson-core-asl-1.9.0.jar ./org/codehaus/jackson/jackson-xc/1.9.0/jackson-xc-1.9.0.jar ./org/codehaus/jackson/jackson-mapper-asl/1.9.0/jackson-mapper-asl-1.9.0.jar ./org/codehaus/plexus/plexus-compiler-api/1.8/plexus-compiler-api-1.8.jar ./org/codehaus/plexus/plexus-i18n/1.0-beta-7/plexus-i18n-1.0-beta-7.jar ./org/codehaus/plexus/plexus-compiler-manager/1.8/plexus-compiler-manager-1.8.jar ./org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar ./org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar ./org/codehaus/plexus/plexus-archiver/1.0-alpha-9/plexus-archiver-1.0-alpha-9.jar ./org/codehaus/plexus/plexus-interpolation/1.13/plexus-interpolation-1.13.jar ./org/codehaus/plexus/plexus-velocity/1.1.3/plexus-velocity-1.1.3.jar ./org/codehaus/plexus/plexus-io/1.0-alpha-1/plexus-io-1.0-alpha-1.jar ./org/codehaus/plexus/plexus-compiler-javac/1.8/plexus-compiler-javac-1.8.jar ./org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar ./org/codehaus/woodstox/wstx-asl/3.2.6/wstx-asl-3.2.6.jar ./org/codehaus/mojo/build-helper-maven-plugin/1.7/build-helper-maven-plugin-1.7.jar ./org/codehaus/mojo/cobertura-maven-plugin/2.4/cobertura-maven-plugin-2.4.jar ./org/codehaus/mojo/exec-maven-plugin/1.1/exec-maven-plugin-1.1.jar ./org/codehaus/mojo/xslt-maven-plugin/1.0/xslt-maven-plugin-1.0.jar ./org/codehaus/mojo/buildnumber-maven-plugin/1.0-beta-4/buildnumber-maven-plugin-1.0-beta-4.jar ./org/ops4j/pax/swissbox/pax-swissbox-core/1.2.0/pax-swissbox-core-1.2.0.jar ./org/ops4j/pax/swissbox/pax-swissbox-optional-jcl/1.2.0/pax-swissbox-optional-jcl-1.2.0.jar ./org/ops4j/pax/swissbox/pax-swissbox-extender/1.2.0/pax-swissbox-extender-1.2.0.jar ./org/ops4j/pax/swissbox/pax-swissbox-bnd/1.2.0/pax-swissbox-bnd-1.2.0.jar ./org/ops4j/pax/swissbox/pax-swissbox-tinybundles/1.2.0/pax-swissbox-tinybundles-1.2.0.jar ./org/ops4j/pax/swissbox/pax-swissbox-lifecycle/1.2.0/pax-swissbox-lifecycle-1.2.0.jar ./org/ops4j/pax/exam/pax-exam-container-rbc/1.2.0/pax-exam-container-rbc-1.2.0.jar ./org/ops4j/pax/exam/pax-exam-runtime/1.2.0/pax-exam-runtime-1.2.0.jar ./org/ops4j/pax/exam/pax-exam-container-rbc-client/1.2.0/pax-exam-container-rbc-client-1.2.0.jar ./org/ops4j/pax/exam/pax-exam/1.2.0/pax-exam-1.2.0.jar ./org/ops4j/pax/exam/pax-exam-junit-extender/1.2.0/pax-exam-junit-extender-1.2.0.jar ./org/ops4j/pax/exam/pax-exam-container-default/1.2.0/pax-exam-container-default-1.2.0.jar ./org/ops4j/pax/exam/pax-exam-junit-extender-impl/1.2.0/pax-exam-junit-extender-impl-1.2.0.jar ./org/ops4j/pax/exam/pax-exam-junit/1.2.0/pax-exam-junit-1.2.0.jar ./org/ops4j/pax/exam/pax-exam-spi/1.2.0/pax-exam-spi-1.2.0.jar ./org/ops4j/pax/exam/maven-paxexam-plugin/1.2.0/maven-paxexam-plugin-1.2.0.jar ./org/ops4j/pax/runner/pax-runner-no-jcl/1.3.0/pax-runner-no-jcl-1.3.0.jar ./org/ops4j/base/ops4j-base-store/1.2.1/ops4j-base-store-1.2.1.jar ./org/ops4j/base/ops4j-base-net/1.2.1/ops4j-base-net-1.2.1.jar ./org/ops4j/base/ops4j-base-lang/1.2.1/ops4j-base-lang-1.2.1.jar ./org/ops4j/base/ops4j-base-io/1.2.1/ops4j-base-io-1.2.1.jar ./org/ops4j/base/ops4j-base-monitors/1.2.1/ops4j-base-monitors-1.2.1.jar ./org/freemarker/freemarker/2.3.18/freemarker-2.3.18.jar ./org/tmatesoft/svnkit/svnkit/1.3.1-1/svnkit-1.3.1-1.jar ./org/tmatesoft/sqljet/sqljet/1.0.0-1/sqljet-1.0.0-1.jar ./org/jvnet/jaxb2/maven2/maven-jaxb22-plugin/0.8.0/maven-jaxb22-plugin-0.8.0.jar ./org/jvnet/jaxb2/maven2/maven-jaxb2-plugin-core/0.8.0/maven-jaxb2-plugin-core-0.8.0.jar ./org/jvnet/jaxb2/maven2/maven-jaxb2-plugin/0.8.0/maven-jaxb2-plugin-0.8.0.jar ./org/jvnet/mimepull/1.6/mimepull-1.6.jar ./org/hibernate/hibernate-annotations/3.4.0.GA/hibernate-annotations-3.4.0.GA.jar ./org/hibernate/hibernate-commons-annotations/3.1.0.GA/hibernate-commons-annotations-3.1.0.GA.jar ./org/hibernate/hibernate-entitymanager/3.4.0.GA/hibernate-entitymanager-3.4.0.GA.jar ./org/hibernate/ejb3-persistence/1.0.2.GA/ejb3-persistence-1.0.2.GA.jar ./org/hibernate/hibernate-core/3.3.0.SP1/hibernate-core-3.3.0.SP1.jar ./org/osgi/osgi_R4_core/1.0/osgi_R4_core-1.0.jar ./org/glassfish/javax.annotation/3.1/javax.annotation-3.1.jar ./org/glassfish/maven-embedded-glassfish-plugin/3.1.1/maven-embedded-glassfish-plugin-3.1.1.jar ./org/glassfish/external/management-api/3.0.0-b012/management-api-3.0.0-b012.jar ./org/glassfish/javax.transaction/3.1/javax.transaction-3.1.jar ./org/glassfish/gmbal/gmbal-api-only/3.0.0-b023/gmbal-api-only-3.0.0-b023.jar ./org/glassfish/javax.servlet/3.1/javax.servlet-3.1.jar ./org/glassfish/web/el-impl/2.2/el-impl-2.2.jar ./org/glassfish/javax.ejb/3.1/javax.ejb-3.1.jar ./org/glassfish/grizzly/grizzly-http-servlet/2.1.2/grizzly-http-servlet-2.1.2.jar ./org/glassfish/grizzly/grizzly-rcm/2.1.2/grizzly-rcm-2.1.2.jar ./org/glassfish/grizzly/grizzly-framework/2.1.2/grizzly-framework-2.1.2.jar ./org/glassfish/grizzly/grizzly-http-server/2.1.2/grizzly-http-server-2.1.2.jar ./org/glassfish/grizzly/grizzly-http/2.1.2/grizzly-http-2.1.2.jar ./org/glassfish/extras/glassfish-embedded-all/3.1.1/glassfish-embedded-all-3.1.1.jar ./org/jfrog/maven/annomojo/maven-plugin-anno/1.3.1/maven-plugin-anno-1.3.1.jar ./org/simpleframework/simple/4.1.20/simple-4.1.20.jar -------------- next part -------------- ./commons-lang/commons-lang/2.4/commons-lang-2.4.jar ./commons-discovery/commons-discovery/0.4/commons-discovery-0.4.jar ./commons-logging/commons-logging/1.1.1/commons-logging-1.1.1.jar ./commons-logging/commons-logging-api/1.0.4/commons-logging-api-1.0.4.jar ./de/zeigermann/xml/xml-im-exporter/1.1/xml-im-exporter-1.1.jar ./de/jflex/jflex/1.4.3/jflex-1.4.3.jar ./de/jflex/maven-jflex-plugin/1.4.3/maven-jflex-plugin-1.4.3.jar ./stax/stax-api/1.0.1/stax-api-1.0.1.jar ./rhino/js/1.6R7/js-1.6R7.jar ./rhino/js/1.6R5/js-1.6R5.jar ./commons-cli/commons-cli/1.0/commons-cli-1.0.jar ./commons-collections/commons-collections/2.0/commons-collections-2.0.jar ./commons-collections/commons-collections/3.2/commons-collections-3.2.jar ./commons-collections/commons-collections/3.2.1/commons-collections-3.2.1.jar ./commons-collections/commons-collections/3.1/commons-collections-3.1.jar ./com/jcraft/jsch/0.1.27/jsch-0.1.27.jar ./com/agilejava/docbkx/docbkx-maven-plugin/2.0.11/docbkx-maven-plugin-2.0.11.jar ./com/trilead/trilead-ssh2/build213-svnkit-1.3-patch/trilead-ssh2-build213-svnkit-1.3-patch.jar ./com/ibm/icu/icu4j/2.6.1/icu4j-2.6.1.jar ./com/ning/async-http-client/1.6.5/async-http-client-1.6.5.jar ./com/google/inject/guice/3.0/guice-3.0.jar ./com/google/inject/extensions/guice-servlet/3.0/guice-servlet-3.0.jar ./com/google/code/maven-scm-provider-svnjava/maven-scm-provider-svnjava/1.8/maven-scm-provider-svnjava-1.8.jar ./com/google/guava/guava/r06/guava-r06.jar ./com/sun/codemodel/codemodel/2.4/codemodel-2.4.jar ./com/sun/xml/bind/jaxb-xjc/2.1.12/jaxb-xjc-2.1.12.jar ./com/sun/xml/bind/jaxb-xjc/2.2.4-1/jaxb-xjc-2.2.4-1.jar ./com/sun/xml/bind/jaxb-impl/2.1.12/jaxb-impl-2.1.12.jar ./com/sun/xml/bind/jaxb-impl/2.2.3-1/jaxb-impl-2.2.3-1.jar ./com/sun/xml/bind/jaxb-impl/2.2.4-1/jaxb-impl-2.2.4-1.jar ./com/sun/xml/fastinfoset/FastInfoset/1.2.9/FastInfoset-1.2.9.jar ./com/sun/net/httpserver/http/20070405/http-20070405.jar ./com/sun/istack/maven-istack-commons-plugin/2.4/maven-istack-commons-plugin-2.4.jar ./com/sun/jersey/jersey-client/1.11-SNAPSHOT/jersey-client-1.11-SNAPSHOT.jar ./com/sun/jersey/jersey-client/1.11-SNAPSHOT/jersey-client-1.11-20111119.160318-12.jar ./com/sun/jersey/jersey-json/1.11-SNAPSHOT/jersey-json-1.11-SNAPSHOT.jar ./com/sun/jersey/jersey-json/1.11-SNAPSHOT/jersey-json-1.11-20111119.163119-12.jar ./com/sun/jersey/jersey-grizzly/1.11-SNAPSHOT/jersey-grizzly-1.11-SNAPSHOT.jar ./com/sun/jersey/jersey-grizzly/1.11-SNAPSHOT/jersey-grizzly-1.11-20111119.161605-12.jar ./com/sun/jersey/jersey-core/1.11-SNAPSHOT/jersey-core-1.11-SNAPSHOT.jar ./com/sun/jersey/jersey-core/1.11-SNAPSHOT/jersey-core-1.11-20111119.155427-12.jar ./com/sun/jersey/contribs/wadl-resourcedoc-doclet/1.11-SNAPSHOT/wadl-resourcedoc-doclet-1.11-SNAPSHOT.jar ./com/sun/jersey/contribs/wadl-resourcedoc-doclet/1.11-SNAPSHOT/wadl-resourcedoc-doclet-1.11-20111119.160505-12.jar ./com/sun/jersey/jersey-servlet/1.11-SNAPSHOT/jersey-servlet-1.11-SNAPSHOT.jar ./com/sun/jersey/jersey-servlet/1.11-SNAPSHOT/jersey-servlet-1.11-20111119.160128-12.jar ./com/sun/jersey/jersey-server/1.11-SNAPSHOT/jersey-server-1.11-20111119.155807-12.jar ./com/sun/jersey/jersey-server/1.11-SNAPSHOT/jersey-server-1.11-SNAPSHOT.jar ./com/sun/tools/xjc/maven2/maven-jaxb-plugin/1.1.1/maven-jaxb-plugin-1.1.1.jar ./com/sun/grizzly/grizzly-http-servlet/1.9.36/grizzly-http-servlet-1.9.36.jar ./com/sun/grizzly/grizzly-http-servlet/1.9.35/grizzly-http-servlet-1.9.35.jar ./com/sun/grizzly/grizzly-rcm/1.9.36/grizzly-rcm-1.9.36.jar ./com/sun/grizzly/grizzly-rcm/1.9.35/grizzly-rcm-1.9.35.jar ./com/sun/grizzly/grizzly-framework/1.9.36/grizzly-framework-1.9.36.jar ./com/sun/grizzly/grizzly-framework/1.9.35/grizzly-framework-1.9.35.jar ./com/sun/grizzly/grizzly-http-webserver/1.9.36/grizzly-http-webserver-1.9.36.jar ./com/sun/grizzly/grizzly-servlet-webserver/1.9.36/grizzly-servlet-webserver-1.9.36.jar ./com/sun/grizzly/grizzly-servlet-webserver/1.9.35/grizzly-servlet-webserver-1.9.35.jar ./com/sun/grizzly/grizzly-portunif/1.9.36/grizzly-portunif-1.9.36.jar ./com/sun/grizzly/grizzly-portunif/1.9.35/grizzly-portunif-1.9.35.jar ./com/sun/grizzly/grizzly-http/1.9.36/grizzly-http-1.9.36.jar ./com/sun/grizzly/grizzly-http/1.9.35/grizzly-http-1.9.35.jar ./com/sun/grizzly/grizzly-lzma/1.9.36/grizzly-lzma-1.9.36.jar ./com/sun/grizzly/grizzly-lzma/1.9.35/grizzly-lzma-1.9.35.jar ./com/sun/grizzly/grizzly-utils/1.9.36/grizzly-utils-1.9.36.jar ./com/sun/grizzly/grizzly-utils/1.9.35/grizzly-utils-1.9.35.jar ./com/sun/org/apache/xml/internal/resolver/20050927/resolver-20050927.jar ./xom/xom/1.0/xom-1.0.jar ./cglib/cglib/2.2/cglib-2.2.jar ./xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar ./xml-apis/xml-apis/1.3.02/xml-apis-1.3.02.jar ./javax/activation/activation/1.1/activation-1.1.jar ./javax/mail/mail/1.4.2/mail-1.4.2.jar ./javax/mail/mail/1.4/mail-1.4.jar ./javax/enterprise/cdi-api/1.0-SP4/cdi-api-1.0-SP4.jar ./javax/inject/javax.inject/1/javax.inject-1.jar ./javax/xml/bind/jsr173_api/1.0/jsr173_api-1.0.jar ./javax/xml/bind/jaxb-api/2.1/jaxb-api-2.1.jar ./javax/xml/bind/jaxb-api/2.2.2/jaxb-api-2.2.2.jar ./javax/xml/bind/jaxb-api/2.2.3/jaxb-api-2.2.3.jar ./javax/xml/stream/stax-api/1.0-2/stax-api-1.0-2.jar ./javax/xml/jsr173/1.0/jsr173-1.0.jar ./javax/el/el-api/2.2/el-api-2.2.jar ./javax/servlet/jstl/1.2/jstl-1.2.jar ./javax/servlet/servlet-api/2.5/servlet-api-2.5.jar ./javax/servlet/servlet-api/2.4/servlet-api-2.4.jar ./javax/servlet/javax.servlet-api/3.0.1/javax.servlet-api-3.0.1.jar ./javax/servlet/jsp-api/2.0/jsp-api-2.0.jar ./javax/persistence/persistence-api/1.0/persistence-api-1.0.jar ./javax/transaction/jta/1.1/jta-1.1.jar ./javax/ws/rs/jsr311-api/1.1.1/jsr311-api-1.1.1-sources.jar ./javax/ws/rs/jsr311-api/1.1.1/jsr311-api-1.1.1.jar ./javax/annotation/jsr250-api/1.0/jsr250-api-1.0.jar ./commons-fileupload/commons-fileupload/1.2.1/commons-fileupload-1.2.1.jar ./regexp/regexp/1.3/regexp-1.3.jar ./commons-codec/commons-codec/1.2/commons-codec-1.2.jar ./commons-codec/commons-codec/1.3/commons-codec-1.3.jar ./commons-codec/commons-codec/1.4/commons-codec-1.4.jar ./jdom/jdom/1.0/jdom-1.0.jar ./slide/slide-webdavlib/2.1/slide-webdavlib-2.1.jar ./commons-beanutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0.jar ./hsqldb/hsqldb/1.8.0.7/hsqldb-1.8.0.7.jar ./asm/asm/3.0/asm-3.0.jar ./asm/asm/3.1/asm-3.1.jar ./asm/asm-all/3.1/asm-all-3.1.jar ./net/liftweb/lift-webkit/1.1-M7/lift-webkit-1.1-M7.jar ./net/liftweb/lift-common/1.1-M7/lift-common-1.1-M7.jar ./net/liftweb/lift-actor/1.1-M7/lift-actor-1.1-M7.jar ./net/liftweb/lift-util/1.1-M7/lift-util-1.1-M7.jar ./net/java/dev/jna/jna/3.2.2/jna-3.2.2.jar ./net/sourceforge/jwebunit/jwebunit-core/1.4.1/jwebunit-core-1.4.1.jar ./net/sourceforge/jwebunit/jwebunit-htmlunit-plugin/1.4.1/jwebunit-htmlunit-plugin-1.4.1.jar ./net/sf/kxml/kxml2/2.2.2/kxml2-2.2.2.jar ./net/sf/retrotranslator/retrotranslator-runtime/1.2.1/retrotranslator-runtime-1.2.1.jar ./net/sf/alchim/yuicompressor-maven-plugin/0.7.1/yuicompressor-maven-plugin-0.7.1.jar ./biz/aQute/bndlib/0.0.313/bndlib-0.0.313.jar ./biz/aQute/bndlib/0.0.255/bndlib-0.0.255.jar ./biz/aQute/bndlib/0.0.357/bndlib-0.0.357.jar ./commons-dbcp/commons-dbcp/1.2.1/commons-dbcp-1.2.1.jar ./jaxen/jaxen/1.1/jaxen-1.1.jar ./jaxen/jaxen/1.1.1/jaxen-1.1.1.jar ./velocity/velocity-dep/1.4/velocity-dep-1.4.jar ./velocity/velocity/1.4/velocity-1.4.jar ./xmlpull/xmlpull/1.1.3.1/xmlpull-1.1.3.1.jar ./oro/oro/2.0.7/oro-2.0.7.jar ./xalan/xalan/2.6.0/xalan-2.6.0.jar ./junit/junit/3.8.1/junit-3.8.1.jar ./junit/junit/4.8.2/junit-4.8.2.jar ./ch/qos/cal10n/cal10n-api/0.7.2/cal10n-api-0.7.2.jar ./xerces/xercesImpl/2.6.1/xercesImpl-2.6.1.jar ./xerces/xercesImpl/2.8.1/xercesImpl-2.8.1.jar ./xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar ./xerces/xmlParserAPIs/2.6.2/xmlParserAPIs-2.6.2.jar ./jline/jline/0.9.93/jline-0.9.93.jar ./classworlds/classworlds/1.1/classworlds-1.1.jar ./qdox/qdox/1.6.1/qdox-1.6.1.jar ./javassist/javassist/3.4.GA/javassist-3.4.GA.jar ./javassist/javassist/3.12.0.GA/javassist-3.12.0.GA.jar ./bsh/bsh/1.3.0/bsh-1.3.0.jar ./backport-util-concurrent/backport-util-concurrent/3.0/backport-util-concurrent-3.0.jar ./commons-pool/commons-pool/1.2/commons-pool-1.2.jar ./commons-io/commons-io/1.2/commons-io-1.2.jar ./commons-io/commons-io/1.3/commons-io-1.3.jar ./commons-io/commons-io/1.4/commons-io-1.4.jar ./commons-httpclient/commons-httpclient/3.1-rc1/commons-httpclient-3.1-rc1.jar ./commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar ./commons-httpclient/commons-httpclient/2.0.2/commons-httpclient-2.0.2.jar ./commons-httpclient/commons-httpclient/3.1/commons-httpclient-3.1.jar ./nu/validator/htmlparser/htmlparser/1.0.5/htmlparser-1.0.5.jar ./woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.jar ./nekohtml/nekohtml/0.9.5/nekohtml-0.9.5.jar ./commons-digester/commons-digester/1.6/commons-digester-1.6.jar ./commons-validator/commons-validator/1.2.0/commons-validator-1.2.0.jar ./htmlunit/htmlunit/1.11/htmlunit-1.11.jar ./aopalliance/aopalliance/1.0/aopalliance-1.0.jar ./antlr/antlr/2.7.7/antlr-2.7.7.jar ./antlr/antlr/2.7.6/antlr-2.7.6.jar ./dom4j/dom4j/1.6.1/dom4j-1.6.1.jar ./rome/rome/0.9/rome-0.9.jar ./org/apache/geronimo/specs/geronimo-activation_1.0.2_spec/1.1/geronimo-activation_1.0.2_spec-1.1.jar ./org/apache/geronimo/specs/geronimo-stax-api_1.0_spec/1.0.1/geronimo-stax-api_1.0_spec-1.0.1.jar ./org/apache/httpcomponents/httpcore/4.0-beta3/httpcore-4.0-beta3.jar ./org/apache/httpcomponents/httpcore/4.1/httpcore-4.1.jar ./org/apache/httpcomponents/httpclient/4.1.1/httpclient-4.1.1.jar ./org/apache/httpcomponents/httpclient/4.0-beta2/httpclient-4.0-beta2.jar ./org/apache/servicemix/tooling/depends-maven-plugin/1.1/depends-maven-plugin-1.1.jar ./org/apache/abdera/abdera-extensions-html/1.0/abdera-extensions-html-1.0.jar ./org/apache/abdera/abdera-parser/1.0/abdera-parser-1.0.jar ./org/apache/abdera/abdera-core/1.0/abdera-core-1.0.jar ./org/apache/abdera/abdera-i18n/1.0/abdera-i18n-1.0.jar ./org/apache/abdera/abdera-extensions-main/1.0/abdera-extensions-main-1.0.jar ./org/apache/abdera/abdera-client/1.0/abdera-client-1.0.jar ./org/apache/abdera/abdera-server/1.0/abdera-server-1.0.jar ./org/apache/abdera/abdera-extensions-json/1.0/abdera-extensions-json-1.0.jar ./org/apache/felix/maven-bundle-plugin/2.0.1/maven-bundle-plugin-2.0.1.jar ./org/apache/felix/maven-bundle-plugin/1.4.1/maven-bundle-plugin-1.4.1.jar ./org/apache/felix/org.osgi.core/1.0.0/org.osgi.core-1.0.0.jar ./org/apache/felix/org.osgi.service.obr/1.0.1/org.osgi.service.obr-1.0.1.jar ./org/apache/commons/commons-io/1.3.2/commons-io-1.3.2.jar ./org/apache/velocity/velocity/1.5/velocity-1.5.jar ./org/apache/maven/enforcer/enforcer-rules/1.0/enforcer-rules-1.0.jar ./org/apache/maven/enforcer/enforcer-api/1.0/enforcer-api-1.0.jar ./org/apache/maven/plugins/maven-compiler-plugin/2.3/maven-compiler-plugin-2.3.jar ./org/apache/maven/plugins/maven-javadoc-plugin/2.5/maven-javadoc-plugin-2.5.jar ./org/apache/maven/plugins/maven-javadoc-plugin/2.4/maven-javadoc-plugin-2.4.jar ./org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.jar ./org/apache/maven/plugins/maven-enforcer-plugin/1.0/maven-enforcer-plugin-1.0.jar ./org/apache/maven/plugins/maven-surefire-plugin/2.5/maven-surefire-plugin-2.5.jar ./org/apache/maven/plugins/maven-surefire-plugin/2.4.2/maven-surefire-plugin-2.4.2.jar ./org/apache/maven/plugins/maven-eclipse-plugin/2.6/maven-eclipse-plugin-2.6.jar ./org/apache/maven/plugins/maven-resources-plugin/2.4.3/maven-resources-plugin-2.4.3.jar ./org/apache/maven/plugins/maven-source-plugin/2.1.1/maven-source-plugin-2.1.1.jar ./org/apache/maven/plugins/maven-dependency-plugin/2.0/maven-dependency-plugin-2.0.jar ./org/apache/maven/plugins/maven-jar-plugin/2.2/maven-jar-plugin-2.2.jar ./org/apache/maven/plugins/maven-plugin-plugin/2.4/maven-plugin-plugin-2.4.jar ./org/apache/maven/plugins/maven-assembly-plugin/2.2-beta-5/maven-assembly-plugin-2.2-beta-5.jar ./org/apache/maven/plugins/maven-assembly-plugin/2.2-beta-2/maven-assembly-plugin-2.2-beta-2.jar ./org/apache/maven/plugins/maven-clean-plugin/2.2/maven-clean-plugin-2.2.jar ./org/apache/maven/maven-project/2.0.9/maven-project-2.0.9.jar ./org/apache/maven/maven-settings/2.0.9/maven-settings-2.0.9.jar ./org/apache/maven/maven-plugin-registry/2.0.9/maven-plugin-registry-2.0.9.jar ./org/apache/maven/maven-plugin-descriptor/2.0.9/maven-plugin-descriptor-2.0.9.jar ./org/apache/maven/maven-monitor/2.0.9/maven-monitor-2.0.9.jar ./org/apache/maven/maven-error-diagnostics/2.0.9/maven-error-diagnostics-2.0.9.jar ./org/apache/maven/apache-maven/2.0.9/apache-maven-2.0.9.jar ./org/apache/maven/doxia/doxia-core/1.0-alpha-7/doxia-core-1.0-alpha-7.jar ./org/apache/maven/doxia/doxia-module-apt/1.0-alpha-10/doxia-module-apt-1.0-alpha-10.jar ./org/apache/maven/doxia/doxia-module-xhtml/1.0-alpha-10/doxia-module-xhtml-1.0-alpha-10.jar ./org/apache/maven/doxia/doxia-decoration-model/1.0-alpha-10/doxia-decoration-model-1.0-alpha-10.jar ./org/apache/maven/doxia/doxia-decoration-model/1.0-alpha-7/doxia-decoration-model-1.0-alpha-7.jar ./org/apache/maven/doxia/doxia-decoration-model/1.0-alpha-8/doxia-decoration-model-1.0-alpha-8.jar ./org/apache/maven/doxia/doxia-module-xdoc/1.0-alpha-10/doxia-module-xdoc-1.0-alpha-10.jar ./org/apache/maven/doxia/doxia-site-renderer/1.0-alpha-10/doxia-site-renderer-1.0-alpha-10.jar ./org/apache/maven/doxia/doxia-site-renderer/1.0-alpha-7/doxia-site-renderer-1.0-alpha-7.jar ./org/apache/maven/doxia/doxia-site-renderer/1.0-alpha-8/doxia-site-renderer-1.0-alpha-8.jar ./org/apache/maven/doxia/doxia-sink-api/1.0-alpha-10/doxia-sink-api-1.0-alpha-10.jar ./org/apache/maven/doxia/doxia-module-fml/1.0-alpha-10/doxia-module-fml-1.0-alpha-10.jar ./org/apache/maven/maven-profile/2.0.9/maven-profile-2.0.9.jar ./org/apache/maven/maven-toolchain/2.0.9/maven-toolchain-2.0.9.jar ./org/apache/maven/maven-artifact-manager/2.0.9/maven-artifact-manager-2.0.9.jar ./org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar ./org/apache/maven/maven-model/2.0.9/maven-model-2.0.9.jar ./org/apache/maven/maven-core/2.0.9/maven-core-2.0.9.jar ./org/apache/maven/maven-archiver/2.2/maven-archiver-2.2.jar ./org/apache/maven/maven-plugin-parameter-documenter/2.0.9/maven-plugin-parameter-documenter-2.0.9.jar ./org/apache/maven/wagon/wagon-webdav/1.0-beta-2/wagon-webdav-1.0-beta-2.jar ./org/apache/maven/wagon/wagon-http-shared/1.0-beta-2/wagon-http-shared-1.0-beta-2.jar ./org/apache/maven/wagon/wagon-http-lightweight/1.0-beta-2/wagon-http-lightweight-1.0-beta-2.jar ./org/apache/maven/wagon/wagon-file/1.0-beta-2/wagon-file-1.0-beta-2.jar ./org/apache/maven/wagon/wagon-ssh-common/1.0-beta-2/wagon-ssh-common-1.0-beta-2.jar ./org/apache/maven/wagon/wagon-ssh/1.0-beta-2/wagon-ssh-1.0-beta-2.jar ./org/apache/maven/wagon/wagon-ssh-external/1.0-beta-2/wagon-ssh-external-1.0-beta-2.jar ./org/apache/maven/wagon/wagon-provider-api/1.0-beta-2/wagon-provider-api-1.0-beta-2.jar ./org/apache/maven/maven-repository-metadata/2.0.9/maven-repository-metadata-2.0.9.jar ./org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.jar ./org/apache/maven/reporting/maven-reporting-impl/2.0.4/maven-reporting-impl-2.0.4.jar ./org/apache/maven/maven-artifact/2.0.9/maven-artifact-2.0.9.jar ./org/apache/maven/shared/maven-common-artifact-filters/1.2/maven-common-artifact-filters-1.2.jar ./org/apache/maven/shared/maven-common-artifact-filters/1.0/maven-common-artifact-filters-1.0.jar ./org/apache/maven/shared/file-management/1.2/file-management-1.2.jar ./org/apache/maven/shared/file-management/1.1/file-management-1.1.jar ./org/apache/maven/shared/maven-plugin-testing-harness/1.1/maven-plugin-testing-harness-1.1.jar ./org/apache/maven/shared/maven-filtering/1.0-beta-4/maven-filtering-1.0-beta-4.jar ./org/apache/maven/shared/maven-dependency-analyzer/1.1/maven-dependency-analyzer-1.1.jar ./org/apache/maven/shared/maven-dependency-analyzer/1.0/maven-dependency-analyzer-1.0.jar ./org/apache/maven/shared/maven-shared-io/1.1/maven-shared-io-1.1.jar ./org/apache/maven/shared/maven-shared-io/1.0/maven-shared-io-1.0.jar ./org/apache/maven/shared/maven-osgi/0.2.0/maven-osgi-0.2.0.jar ./org/apache/maven/shared/maven-dependency-tree/1.2/maven-dependency-tree-1.2.jar ./org/apache/maven/shared/maven-dependency-tree/1.1/maven-dependency-tree-1.1.jar ./org/apache/maven/plugin-tools/maven-plugin-tools-beanshell/2.4/maven-plugin-tools-beanshell-2.4.jar ./org/apache/maven/plugin-tools/maven-plugin-tools-java/2.4/maven-plugin-tools-java-2.4.jar ./org/apache/maven/plugin-tools/maven-plugin-tools-api/2.4/maven-plugin-tools-api-2.4.jar ./org/apache/maven/scm/maven-scm-api/1.2/maven-scm-api-1.2.jar ./org/apache/maven/scm/maven-scm-provider-perforce/1.2/maven-scm-provider-perforce-1.2.jar ./org/apache/maven/scm/maven-scm-provider-starteam/1.2/maven-scm-provider-starteam-1.2.jar ./org/apache/maven/scm/maven-scm-provider-hg/1.2/maven-scm-provider-hg-1.2.jar ./org/apache/maven/scm/maven-scm-provider-cvsexe/1.2/maven-scm-provider-cvsexe-1.2.jar ./org/apache/maven/scm/maven-scm-provider-cvs-commons/1.2/maven-scm-provider-cvs-commons-1.2.jar ./org/apache/maven/scm/maven-scm-provider-clearcase/1.2/maven-scm-provider-clearcase-1.2.jar ./org/apache/maven/scm/maven-scm-manager-plexus/1.2/maven-scm-manager-plexus-1.2.jar ./org/apache/maven/scm/maven-scm-provider-svn-commons/1.2/maven-scm-provider-svn-commons-1.2.jar ./org/apache/maven/scm/maven-scm-provider-svnexe/1.2/maven-scm-provider-svnexe-1.2.jar ./org/apache/ws/commons/axiom/axiom-impl/1.2.5/axiom-impl-1.2.5.jar ./org/apache/ws/commons/axiom/axiom-api/1.2.5/axiom-api-1.2.5.jar ./org/sonatype/plexus/plexus-build-api/0.0.4/plexus-build-api-0.0.4.jar ./org/eclipse/persistence/org.eclipse.persistence.asm/2.2.0-M6/org.eclipse.persistence.asm-2.2.0-M6.jar ./org/eclipse/persistence/org.eclipse.persistence.core/2.2.0-M6/org.eclipse.persistence.core-2.2.0-M6.jar ./org/eclipse/persistence/org.eclipse.persistence.moxy/2.2.0-M6/org.eclipse.persistence.moxy-2.2.0-M6.jar ./org/eclipse/persistence/org.eclipse.persistence.antlr/2.2.0-M6/org.eclipse.persistence.antlr-2.2.0-M6.jar ./org/jboss/netty/netty/3.2.5.Final/netty-3.2.5.Final.jar ./org/jboss/interceptor/jboss-interceptor-spi/2.0.0.CR1/jboss-interceptor-spi-2.0.0.CR1.jar ./org/jboss/interceptor/jboss-interceptor-core/2.0.0.CR1/jboss-interceptor-core-2.0.0.CR1.jar ./org/jboss/weld/weld-osgi-bundle/1.1.2.Final/weld-osgi-bundle-1.1.2.Final.jar ./org/jboss/weld/weld-api/1.1.Beta2/weld-api-1.1.Beta2.jar ./org/jboss/weld/weld-core/1.1.2.Final/weld-core-1.1.2.Final.jar ./org/jboss/weld/weld-spi/1.1.Beta2/weld-spi-1.1.Beta2.jar ./org/jboss/spec/javax/interceptor/jboss-interceptors-api_1.1_spec/1.0.0.Beta1/jboss-interceptors-api_1.1_spec-1.0.0.Beta1.jar ./org/springframework/spring-aop/2.5.6/spring-aop-2.5.6.jar ./org/springframework/spring-context/2.5.6/spring-context-2.5.6.jar ./org/springframework/spring-beans/2.5.6/spring-beans-2.5.6.jar ./org/springframework/spring/2.5.5/spring-2.5.5.jar ./org/springframework/spring-web/2.5.6/spring-web-2.5.6.jar ./org/springframework/spring-core/2.5.6/spring-core-2.5.6.jar ./org/aspectj/aspectjweaver/1.5.4/aspectjweaver-1.5.4.jar ./org/aspectj/aspectjrt/1.5.4/aspectjrt-1.5.4.jar ./org/beanshell/bsh/2.0b4/bsh-2.0b4.jar ./org/zeroturnaround/jr-sdk/3.1.2/jr-sdk-3.1.2.jar ./org/zeroturnaround/jr-javassist/3.8.0.GA/jr-javassist-3.8.0.GA.jar ./org/zeroturnaround/jrebel-maven-plugin/1.0.7/jrebel-maven-plugin-1.0.7.jar ./org/mortbay/jetty/jetty-util/6.1.19/jetty-util-6.1.19.jar ./org/mortbay/jetty/servlet-api/2.5-20081211/servlet-api-2.5-20081211.jar ./org/mortbay/jetty/maven-jetty-plugin/6.1.15/maven-jetty-plugin-6.1.15.jar ./org/mortbay/jetty/maven-jetty-plugin/6.1.19/maven-jetty-plugin-6.1.19.jar ./org/mortbay/jetty/maven-jetty-plugin/6.1.24/maven-jetty-plugin-6.1.24.jar ./org/mortbay/jetty/jetty/6.1.19/jetty-6.1.19.jar ./org/testng/testng/5.5/testng-5.5-jdk15.jar ./org/scala-tools/testing/specs/1.6.2.2/specs-1.6.2.2.jar ./org/scala-tools/testing/scalacheck/1.5/scalacheck-1.5.jar ./org/scala-tools/testing/scalatest/0.9.4/scalatest-0.9.4.jar ./org/scala-tools/maven-scala-plugin/2.10.1/maven-scala-plugin-2.10.1.jar ./org/codehaus/jettison/jettison/1.1/jettison-1.1.jar ./org/codehaus/jackson/jackson-jaxrs/1.9.0/jackson-jaxrs-1.9.0.jar ./org/codehaus/jackson/jackson-jaxrs/1.8.3/jackson-jaxrs-1.8.3.jar ./org/codehaus/jackson/jackson-core-asl/1.9.0/jackson-core-asl-1.9.0.jar ./org/codehaus/jackson/jackson-core-asl/1.8.3/jackson-core-asl-1.8.3.jar ./org/codehaus/jackson/jackson-xc/1.9.0/jackson-xc-1.9.0.jar ./org/codehaus/jackson/jackson-xc/1.8.3/jackson-xc-1.8.3.jar ./org/codehaus/jackson/jackson-mapper-asl/1.9.0/jackson-mapper-asl-1.9.0.jar ./org/codehaus/jackson/jackson-mapper-asl/1.8.3/jackson-mapper-asl-1.8.3.jar ./org/codehaus/plexus/plexus-compiler-api/1.8/plexus-compiler-api-1.8.jar ./org/codehaus/plexus/plexus-i18n/1.0-beta-7/plexus-i18n-1.0-beta-7.jar ./org/codehaus/plexus/plexus-i18n/1.0-beta-6/plexus-i18n-1.0-beta-6.jar ./org/codehaus/plexus/plexus-compiler-manager/1.8/plexus-compiler-manager-1.8.jar ./org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar ./org/codehaus/plexus/plexus-utils/1.5.8/plexus-utils-1.5.8.jar ./org/codehaus/plexus/plexus-utils/1.4.7/plexus-utils-1.4.7.jar ./org/codehaus/plexus/plexus-utils/1.5.6/plexus-utils-1.5.6.jar ./org/codehaus/plexus/plexus-utils/1.5.1/plexus-utils-1.5.1.jar ./org/codehaus/plexus/plexus-utils/1.4.1/plexus-utils-1.4.1.jar ./org/codehaus/plexus/plexus-utils/2.0.5/plexus-utils-2.0.5.jar ./org/codehaus/plexus/plexus-utils/1.4.6/plexus-utils-1.4.6.jar ./org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar ./org/codehaus/plexus/plexus-container-default/1.0-alpha-9-stable-1/plexus-container-default-1.0-alpha-9-stable-1.jar ./org/codehaus/plexus/plexus-archiver/1.0-alpha-9/plexus-archiver-1.0-alpha-9.jar ./org/codehaus/plexus/plexus-archiver/1.0-alpha-7/plexus-archiver-1.0-alpha-7.jar ./org/codehaus/plexus/plexus-interpolation/1.13/plexus-interpolation-1.13.jar ./org/codehaus/plexus/plexus-velocity/1.1.3/plexus-velocity-1.1.3.jar ./org/codehaus/plexus/plexus-velocity/1.1.7/plexus-velocity-1.1.7.jar ./org/codehaus/plexus/plexus-velocity/1.1.2/plexus-velocity-1.1.2.jar ./org/codehaus/plexus/plexus-io/1.0-alpha-1/plexus-io-1.0-alpha-1.jar ./org/codehaus/plexus/plexus-compiler-javac/1.8/plexus-compiler-javac-1.8.jar ./org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar ./org/codehaus/woodstox/wstx-asl/3.2.6/wstx-asl-3.2.6.jar ./org/codehaus/mojo/build-helper-maven-plugin/1.7/build-helper-maven-plugin-1.7.jar ./org/codehaus/mojo/cobertura-maven-plugin/2.4/cobertura-maven-plugin-2.4.jar ./org/codehaus/mojo/exec-maven-plugin/1.1/exec-maven-plugin-1.1.jar ./org/codehaus/mojo/xslt-maven-plugin/1.0/xslt-maven-plugin-1.0.jar ./org/codehaus/mojo/buildnumber-maven-plugin/1.0-beta-4/buildnumber-maven-plugin-1.0-beta-4.jar ./org/ops4j/pax/swissbox/pax-swissbox-core/1.2.0/pax-swissbox-core-1.2.0.jar ./org/ops4j/pax/swissbox/pax-swissbox-optional-jcl/1.2.0/pax-swissbox-optional-jcl-1.2.0.jar ./org/ops4j/pax/swissbox/pax-swissbox-extender/1.2.0/pax-swissbox-extender-1.2.0.jar ./org/ops4j/pax/swissbox/pax-swissbox-bnd/1.2.0/pax-swissbox-bnd-1.2.0.jar ./org/ops4j/pax/swissbox/pax-swissbox-tinybundles/1.2.0/pax-swissbox-tinybundles-1.2.0.jar ./org/ops4j/pax/swissbox/pax-swissbox-lifecycle/1.2.0/pax-swissbox-lifecycle-1.2.0.jar ./org/ops4j/pax/exam/pax-exam-container-rbc/1.2.0/pax-exam-container-rbc-1.2.0.jar ./org/ops4j/pax/exam/pax-exam-runtime/1.2.0/pax-exam-runtime-1.2.0.jar ./org/ops4j/pax/exam/pax-exam-container-rbc-client/1.2.0/pax-exam-container-rbc-client-1.2.0.jar ./org/ops4j/pax/exam/pax-exam/1.2.0/pax-exam-1.2.0.jar ./org/ops4j/pax/exam/pax-exam-junit-extender/1.2.0/pax-exam-junit-extender-1.2.0.jar ./org/ops4j/pax/exam/pax-exam-container-default/1.2.0/pax-exam-container-default-1.2.0.jar ./org/ops4j/pax/exam/pax-exam-junit-extender-impl/1.2.0/pax-exam-junit-extender-impl-1.2.0.jar ./org/ops4j/pax/exam/pax-exam-junit/1.2.0/pax-exam-junit-1.2.0.jar ./org/ops4j/pax/exam/pax-exam-spi/1.2.0/pax-exam-spi-1.2.0.jar ./org/ops4j/pax/exam/maven-paxexam-plugin/1.2.0/maven-paxexam-plugin-1.2.0.jar ./org/ops4j/pax/runner/pax-runner-no-jcl/1.3.0/pax-runner-no-jcl-1.3.0.jar ./org/ops4j/base/ops4j-base-store/1.2.1/ops4j-base-store-1.2.1.jar ./org/ops4j/base/ops4j-base-net/1.2.1/ops4j-base-net-1.2.1.jar ./org/ops4j/base/ops4j-base-lang/1.2.1/ops4j-base-lang-1.2.1.jar ./org/ops4j/base/ops4j-base-io/1.2.1/ops4j-base-io-1.2.1.jar ./org/ops4j/base/ops4j-base-monitors/1.2.1/ops4j-base-monitors-1.2.1.jar ./org/freemarker/freemarker/2.3.18/freemarker-2.3.18.jar ./org/tmatesoft/svnkit/svnkit/1.3.1-1/svnkit-1.3.1-1.jar ./org/tmatesoft/sqljet/sqljet/1.0.0-1/sqljet-1.0.0-1.jar ./org/jvnet/jaxb2/maven2/maven-jaxb22-plugin/0.8.0/maven-jaxb22-plugin-0.8.0.jar ./org/jvnet/jaxb2/maven2/maven-jaxb2-plugin-core/0.8.0/maven-jaxb2-plugin-core-0.8.0.jar ./org/jvnet/jaxb2/maven2/maven-jaxb2-plugin/0.8.0/maven-jaxb2-plugin-0.8.0.jar ./org/jvnet/mimepull/1.6/mimepull-1.6.jar ./org/hibernate/hibernate-annotations/3.4.0.GA/hibernate-annotations-3.4.0.GA.jar ./org/hibernate/hibernate-commons-annotations/3.1.0.GA/hibernate-commons-annotations-3.1.0.GA.jar ./org/hibernate/hibernate-entitymanager/3.4.0.GA/hibernate-entitymanager-3.4.0.GA.jar ./org/hibernate/ejb3-persistence/1.0.2.GA/ejb3-persistence-1.0.2.GA.jar ./org/hibernate/hibernate-core/3.3.0.SP1/hibernate-core-3.3.0.SP1.jar ./org/javassist/javassist/3.14.0-GA/javassist-3.14.0-GA.jar ./org/slf4j/slf4j-api/1.5.10/slf4j-api-1.5.10.jar ./org/slf4j/slf4j-api/1.5.9.RC1/slf4j-api-1.5.9.RC1.jar ./org/slf4j/slf4j-api/1.6.2/slf4j-api-1.6.2.jar ./org/slf4j/slf4j-ext/1.5.10/slf4j-ext-1.5.10.jar ./org/slf4j/slf4j-log4j12/1.5.9.RC1/slf4j-log4j12-1.5.9.RC1.jar ./org/osgi/osgi_R4_core/1.0/osgi_R4_core-1.0.jar ./org/glassfish/javax.annotation/3.1/javax.annotation-3.1.jar ./org/glassfish/maven-embedded-glassfish-plugin/3.1.1/maven-embedded-glassfish-plugin-3.1.1.jar ./org/glassfish/external/management-api/3.0.0-b012/management-api-3.0.0-b012.jar ./org/glassfish/javax.transaction/3.1/javax.transaction-3.1.jar ./org/glassfish/gmbal/gmbal-api-only/3.0.0-b023/gmbal-api-only-3.0.0-b023.jar ./org/glassfish/javax.servlet/3.1/javax.servlet-3.1.jar ./org/glassfish/web/el-impl/2.2/el-impl-2.2.jar ./org/glassfish/javax.ejb/3.1/javax.ejb-3.1.jar ./org/glassfish/grizzly/grizzly-http-servlet/2.1.2/grizzly-http-servlet-2.1.2.jar ./org/glassfish/grizzly/grizzly-rcm/2.1.2/grizzly-rcm-2.1.2.jar ./org/glassfish/grizzly/grizzly-framework/2.1.2/grizzly-framework-2.1.2.jar ./org/glassfish/grizzly/grizzly-http-server/2.1.2/grizzly-http-server-2.1.2.jar ./org/glassfish/grizzly/grizzly-http/2.1.2/grizzly-http-2.1.2.jar ./org/glassfish/extras/glassfish-embedded-all/3.1.1/glassfish-embedded-all-3.1.1.jar ./org/jfrog/maven/annomojo/maven-plugin-anno/1.3.1/maven-plugin-anno-1.3.1.jar ./org/scala-lang/scala-library/2.7.5/scala-library-2.7.5.jar ./org/scala-lang/scala-compiler/2.7.5/scala-compiler-2.7.5.jar ./org/antlr/stringtemplate/3.2/stringtemplate-3.2.jar ./org/antlr/antlr-runtime/3.1.3/antlr-runtime-3.1.3.jar ./org/simpleframework/simple/4.1.20/simple-4.1.20.jar ./log4j/log4j/1.2.12/log4j-1.2.12.jar ./log4j/log4j/1.2.14/log4j-1.2.14.jar ./ant/ant/1.6.5/ant-1.6.5.jar ./jtidy/jtidy/4aug2000r7-dev/jtidy-4aug2000r7-dev.jar From alee at redhat.com Mon Nov 21 14:49:01 2011 From: alee at redhat.com (Ade Lee) Date: Mon, 21 Nov 2011 09:49:01 -0500 Subject: [Pki-devel] [PATCH] 0012-Dead-code-removal In-Reply-To: <4EC9AFF8.2060209@redhat.com> References: <4EBB1FF0.90409@redhat.com> <1321337517.6303.155.camel@aleeredhat.laptop> <4EC3D7C3.9060407@redhat.com> <4EC9AFF8.2060209@redhat.com> Message-ID: <1321886941.2265.19.camel@aleeredhat.laptop> On Sun, 2011-11-20 at 20:57 -0500, Adam Young wrote: > On 11/16/2011 10:33 AM, Adam Young wrote: > > On 11/15/2011 01:11 AM, Ade Lee wrote: > > > This is a review of this patch and the subsequent one removing > > > unnecessary blocks. > > > > > > CMCAuth.java: Can you explain why this code removal is correct? > > > > At this point in the code, cert can only be null. The only code > > path that assigns a value to cert has a return after it, and cannot > > reach this point. Thus, the code executed when cert != null is > > unreachable > > > > > > > > CAAdminServlet.java : code should be commented out, rather than > > > removed. > > > > Disagree. If this code has never been run, it is unnecessary. > > Lets not put dead code into the source tree. > > > > > > HashEnrollServlet.java : remove the outer conditional as well. > > Done > > > DBSubsystem.java: some important comments are removed, they should > > > not > > > be removed. > > > > Done > > > > > > FileAsString.java - does the proposed code removal introduce a > > > resource > > > leak? > > > > No. FileReader can throw a file not found exception. But > > BufferedReader only throws an IllegalArgumentException, which > > wouldn't be caught by that catch block anyway. > > > > > > > > KeyRecoveryAuthority.java: please explain why the proposed code > > > removal > > > is correct. It certainly looks wrong. > > I agree that the change looks wrong. I put it back in, and Eclipse > > did not tag it as dead code. > > > > > > Ade > > > > > > On Wed, 2011-11-09 at 19:50 -0500, Adam Young wrote: > > > > _______________________________________________ > > > > Pki-devel mailing list > > > > Pki-devel at redhat.com > > > > https://www.redhat.com/mailman/listinfo/pki-devel > > > > > > > > > > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > Is that an ACK? > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ACK From alee at redhat.com Mon Nov 21 17:17:41 2011 From: alee at redhat.com (Ade Lee) Date: Mon, 21 Nov 2011 12:17:41 -0500 Subject: [Pki-devel] POM deps for Jersey In-Reply-To: <1321885753.2265.18.camel@aleeredhat.laptop> References: <4EC69BC2.2060009@redhat.com> <1321885753.2265.18.camel@aleeredhat.laptop> Message-ID: <1321895862.12495.15.camel@aleeredhat.laptop> OK - I think the right solution here is going to be RESTeasy. Why? Because I was able to find the guy who is responsible for getting the JBOSS packages into fedora. We were able to determine the five or six packages that need to be added to fedora to get us the functionality we need. While that number is likely to get bigger, we can get this prioritized if we help him. So thats what we should do. Here is mgoldmann's link to a template he is using for packages, and couple of other useful links: https://gist.github.com/1383245 http://resteasy.svn.sourceforge.net/viewvc/resteasy/tags/RESTEASY_JAXRS_2_2_3_GA/resteasy-jaxrs/pom.xml?revision=1569&view=markup http://fedoraproject.org/wiki/JBossAS7#Wishlist Ade On Mon, 2011-11-21 at 09:29 -0500, Ade Lee wrote: > Adam, > > I'm not sure what you built - but your build seems to lack a lot of key > dependencies. I pulled down the jersey source from svn and tried to > build it using eclipse (and immediately ran into 50K+ build errors). > > I then built it in maven and noticed something like 450 jars being > pulled in. Now granted, lots of these are duplicate versions - and some > of these are in fedora - but a lot of them are not. > > I tried to figure out which ones are provided by fedora but its slow > going. Attached is the list of jars pulled in (pulled_jars) and a > slightly more whittled down list after removing multiple versions or > seeing the jar in fedora. The whittled down list can probably be > whittled down further. > > Its still over 250 jars long though. Even if we managed to whittle down > much further its likely we will end up with over 100 jars that we would > need to shepherd through fedora and rhel acceptance. Including a few > that would be unacceptable in fedora/rhel. > > As you say, resteasy is probably a little worse - although in this case, > we *might* be able to find folks to maintain some parts of this. > > So this begs the question - are either of these frameworks feasible for > us to use at the current time? > > Ade > > On Fri, 2011-11-18 at 12:54 -0500, Adam Young wrote: > > I first ran the maven Archtype for a Jersey web app and then compiled > > it. Both before starting and In between the two steps I wiped out my > > local Maven repository to be able to distinguish waht was necessary. > > > > Here are the list of jars pulled down in the second stage. > > > > javax/ws/rs/jsr311-api/0.8/jsr311-api-0.8.jar > > junit/junit/3.8.1/junit-3.8.1.jar > > commons-cli/commons-cli/1.0/commons-cli-1.0.jar > > org/sonatype/plexus/plexus-build-api/0.0.4/plexus-build-api-0.0.4.jar > > org/codehaus/mojo/tomcat-maven-plugin/1.1/tomcat-maven-plugin-1.1.jar > > org/codehaus/plexus/plexus-interpolation/1.13/plexus-interpolation-1.13.jar > > org/codehaus/plexus/plexus-utils/2.0.5/plexus-utils-2.0.5.jar > > org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar > > org/codehaus/plexus/plexus-compiler-api/1.8.1/plexus-compiler-api-1.8.1.jar > > org/codehaus/plexus/plexus-compiler-javac/1.8.1/plexus-compiler-javac-1.8.1.jar > > org/codehaus/plexus/plexus-compiler-manager/1.8.1/plexus-compiler-manager-1.8.1.jar > > org/apache/maven/doxia/doxia-sink-api/1.0-alpha-7/doxia-sink-api-1.0-alpha-7.jar > > org/apache/maven/shared/maven-filtering/1.0-beta-4/maven-filtering-1.0-beta-4.jar > > org/apache/maven/plugins/maven-compiler-plugin/2.3.2/maven-compiler-plugin-2.3.2.jar > > org/apache/maven/plugins/maven-resources-plugin/2.4.3/maven-resources-plugin-2.4.3.jar > > org/apache/maven/reporting/maven-reporting-api/2.0.6/maven-reporting-api-2.0.6.jar > > asm/asm/3.1/asm-3.1.jar > > com/sun/jersey/jersey/0.8-ea-SNAPSHOT/jersey-0.8-ea-SNAPSHOT.jar > > > > > > I'm guessing these fall into two groups: those needed for building any > > web app and those specific to Jersey. Maven is fairly well covered by > > Fedora, so I don't think w'll have too much trouble there. > > JUnit is in Fedora. > > commons-cli is in fedora > > > > jsr311 is probably just a small set of source file, but it is not in > > Fedora. > > > > Specific to Jersey are these: edited out of the Jersey POM > > > > javax.ws.rs.jsr311-api version 0.8 > > javax.annotation.jsr250-api version 1.0 > > javax.persistence.persistence-api version 1.0.2 > > javax.servlet.servlet-api version 2.5 > > asm.asm version 3.1 > > > > NOte that does not indicated what is needed to build Jersey, merely > > what it requires to build another project. > > > > > > Pulling the Jersey source into Eclipse without and jars to fill in > > dependencies is more interesting. > > > > To build, it refers to a bunch of the Sun classes in the JREs rt.jar, > > which have access prohibited. we can work around this with a symlink. > > > > > > Other jars I started pulling in > > > > > > > > > > > > > > > > > > > path="/usr/share/java/tomcat6/annotations-api.jar"/> > > > > > > > > > path="/usr/share/java/tomcat-servlet-3.0-api.jar"/> > > > > > > > > > > The only one I haven't found so far is > > > path="/home/ayoung/.m2/repository/javax/enterprise/cdi-api/1.1.EDR1.1/cdi-api-1.1.EDR1.1.jar"/> > > > > Which appears to be Weld, or the reference implementation of JSR-299. > > This looks interesting in its own right. > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From ayoung at redhat.com Mon Nov 21 18:09:17 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 21 Nov 2011 13:09:17 -0500 Subject: [Pki-devel] POM deps for Jersey In-Reply-To: <1321885753.2265.18.camel@aleeredhat.laptop> References: <4EC69BC2.2060009@redhat.com> <1321885753.2265.18.camel@aleeredhat.laptop> Message-ID: <4ECA93CD.4030703@redhat.com> On 11/21/2011 09:29 AM, Ade Lee wrote: > Adam, > > I'm not sure what you built - but your build seems to lack a lot of key > dependencies. I pulled down the jersey source from svn and tried to > build it using eclipse (and immediately ran into 50K+ build errors). > > I then built it in maven and noticed something like 450 jars being > pulled in. Now granted, lots of these are duplicate versions - and some > of these are in fedora - but a lot of them are not. > > I tried to figure out which ones are provided by fedora but its slow > going. Attached is the list of jars pulled in (pulled_jars) and a > slightly more whittled down list after removing multiple versions or > seeing the jar in fedora. The whittled down list can probably be > whittled down further. > > Its still over 250 jars long though. Even if we managed to whittle down > much further its likely we will end up with over 100 jars that we would > need to shepherd through fedora and rhel acceptance. Including a few > that would be unacceptable in fedora/rhel. > > As you say, resteasy is probably a little worse - although in this case, > we *might* be able to find folks to maintain some parts of this. > > So this begs the question - are either of these frameworks feasible for > us to use at the current time? I'll have to tkae a closer look, but I do know that I commented out the grizzley web server. that pulls in a few, and it really makes no sense. There are a bunch that get pulled in just for Maven, but that are not required for building. Most of these should be things that are already accounted for. I think Jersey is do-able. > > Ade > > On Fri, 2011-11-18 at 12:54 -0500, Adam Young wrote: >> I first ran the maven Archtype for a Jersey web app and then compiled >> it. Both before starting and In between the two steps I wiped out my >> local Maven repository to be able to distinguish waht was necessary. >> >> Here are the list of jars pulled down in the second stage. >> >> javax/ws/rs/jsr311-api/0.8/jsr311-api-0.8.jar >> junit/junit/3.8.1/junit-3.8.1.jar >> commons-cli/commons-cli/1.0/commons-cli-1.0.jar >> org/sonatype/plexus/plexus-build-api/0.0.4/plexus-build-api-0.0.4.jar >> org/codehaus/mojo/tomcat-maven-plugin/1.1/tomcat-maven-plugin-1.1.jar >> org/codehaus/plexus/plexus-interpolation/1.13/plexus-interpolation-1.13.jar >> org/codehaus/plexus/plexus-utils/2.0.5/plexus-utils-2.0.5.jar >> org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar >> org/codehaus/plexus/plexus-compiler-api/1.8.1/plexus-compiler-api-1.8.1.jar >> org/codehaus/plexus/plexus-compiler-javac/1.8.1/plexus-compiler-javac-1.8.1.jar >> org/codehaus/plexus/plexus-compiler-manager/1.8.1/plexus-compiler-manager-1.8.1.jar >> org/apache/maven/doxia/doxia-sink-api/1.0-alpha-7/doxia-sink-api-1.0-alpha-7.jar >> org/apache/maven/shared/maven-filtering/1.0-beta-4/maven-filtering-1.0-beta-4.jar >> org/apache/maven/plugins/maven-compiler-plugin/2.3.2/maven-compiler-plugin-2.3.2.jar >> org/apache/maven/plugins/maven-resources-plugin/2.4.3/maven-resources-plugin-2.4.3.jar >> org/apache/maven/reporting/maven-reporting-api/2.0.6/maven-reporting-api-2.0.6.jar >> asm/asm/3.1/asm-3.1.jar >> com/sun/jersey/jersey/0.8-ea-SNAPSHOT/jersey-0.8-ea-SNAPSHOT.jar >> >> >> I'm guessing these fall into two groups: those needed for building any >> web app and those specific to Jersey. Maven is fairly well covered by >> Fedora, so I don't think w'll have too much trouble there. >> JUnit is in Fedora. >> commons-cli is in fedora >> >> jsr311 is probably just a small set of source file, but it is not in >> Fedora. >> >> Specific to Jersey are these: edited out of the Jersey POM >> >> javax.ws.rs.jsr311-api version 0.8 >> javax.annotation.jsr250-api version 1.0 >> javax.persistence.persistence-api version 1.0.2 >> javax.servlet.servlet-api version 2.5 >> asm.asm version 3.1 >> >> NOte that does not indicated what is needed to build Jersey, merely >> what it requires to build another project. >> >> >> Pulling the Jersey source into Eclipse without and jars to fill in >> dependencies is more interesting. >> >> To build, it refers to a bunch of the Sun classes in the JREs rt.jar, >> which have access prohibited. we can work around this with a symlink. >> >> >> Other jars I started pulling in >> >> >> >> >> >> >> >> >> > path="/usr/share/java/tomcat6/annotations-api.jar"/> >> >> >> >> > path="/usr/share/java/tomcat-servlet-3.0-api.jar"/> >> >> >> >> >> The only one I haven't found so far is >> > path="/home/ayoung/.m2/repository/javax/enterprise/cdi-api/1.1.EDR1.1/cdi-api-1.1.EDR1.1.jar"/> >> >> Which appears to be Weld, or the reference implementation of JSR-299. >> This looks interesting in its own right. From ayoung at redhat.com Mon Nov 21 18:09:44 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 21 Nov 2011 13:09:44 -0500 Subject: [Pki-devel] POM deps for Jersey In-Reply-To: <1321895862.12495.15.camel@aleeredhat.laptop> References: <4EC69BC2.2060009@redhat.com> <1321885753.2265.18.camel@aleeredhat.laptop> <1321895862.12495.15.camel@aleeredhat.laptop> Message-ID: <4ECA93E8.6020906@redhat.com> On 11/21/2011 12:17 PM, Ade Lee wrote: > OK - I think the right solution here is going to be RESTeasy. > > Why? Because I was able to find the guy who is responsible for getting > the JBOSS packages into fedora. We were able to determine the five or > six packages that need to be added to fedora to get us the functionality > we need. > > While that number is likely to get bigger, we can get this prioritized > if we help him. So thats what we should do. > > Here is mgoldmann's link to a template he is using for packages, and > couple of other useful links: > > https://gist.github.com/1383245 > http://resteasy.svn.sourceforge.net/viewvc/resteasy/tags/RESTEASY_JAXRS_2_2_3_GA/resteasy-jaxrs/pom.xml?revision=1569&view=markup > http://fedoraproject.org/wiki/JBossAS7#Wishlist > > Ade > > On Mon, 2011-11-21 at 09:29 -0500, Ade Lee wrote: >> Adam, >> >> I'm not sure what you built - but your build seems to lack a lot of key >> dependencies. I pulled down the jersey source from svn and tried to >> build it using eclipse (and immediately ran into 50K+ build errors). >> >> I then built it in maven and noticed something like 450 jars being >> pulled in. Now granted, lots of these are duplicate versions - and some >> of these are in fedora - but a lot of them are not. >> >> I tried to figure out which ones are provided by fedora but its slow >> going. Attached is the list of jars pulled in (pulled_jars) and a >> slightly more whittled down list after removing multiple versions or >> seeing the jar in fedora. The whittled down list can probably be >> whittled down further. >> >> Its still over 250 jars long though. Even if we managed to whittle down >> much further its likely we will end up with over 100 jars that we would >> need to shepherd through fedora and rhel acceptance. Including a few >> that would be unacceptable in fedora/rhel. >> >> As you say, resteasy is probably a little worse - although in this case, >> we *might* be able to find folks to maintain some parts of this. >> >> So this begs the question - are either of these frameworks feasible for >> us to use at the current time? >> >> Ade >> >> On Fri, 2011-11-18 at 12:54 -0500, Adam Young wrote: >>> I first ran the maven Archtype for a Jersey web app and then compiled >>> it. Both before starting and In between the two steps I wiped out my >>> local Maven repository to be able to distinguish waht was necessary. >>> >>> Here are the list of jars pulled down in the second stage. >>> >>> javax/ws/rs/jsr311-api/0.8/jsr311-api-0.8.jar >>> junit/junit/3.8.1/junit-3.8.1.jar >>> commons-cli/commons-cli/1.0/commons-cli-1.0.jar >>> org/sonatype/plexus/plexus-build-api/0.0.4/plexus-build-api-0.0.4.jar >>> org/codehaus/mojo/tomcat-maven-plugin/1.1/tomcat-maven-plugin-1.1.jar >>> org/codehaus/plexus/plexus-interpolation/1.13/plexus-interpolation-1.13.jar >>> org/codehaus/plexus/plexus-utils/2.0.5/plexus-utils-2.0.5.jar >>> org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar >>> org/codehaus/plexus/plexus-compiler-api/1.8.1/plexus-compiler-api-1.8.1.jar >>> org/codehaus/plexus/plexus-compiler-javac/1.8.1/plexus-compiler-javac-1.8.1.jar >>> org/codehaus/plexus/plexus-compiler-manager/1.8.1/plexus-compiler-manager-1.8.1.jar >>> org/apache/maven/doxia/doxia-sink-api/1.0-alpha-7/doxia-sink-api-1.0-alpha-7.jar >>> org/apache/maven/shared/maven-filtering/1.0-beta-4/maven-filtering-1.0-beta-4.jar >>> org/apache/maven/plugins/maven-compiler-plugin/2.3.2/maven-compiler-plugin-2.3.2.jar >>> org/apache/maven/plugins/maven-resources-plugin/2.4.3/maven-resources-plugin-2.4.3.jar >>> org/apache/maven/reporting/maven-reporting-api/2.0.6/maven-reporting-api-2.0.6.jar >>> asm/asm/3.1/asm-3.1.jar >>> com/sun/jersey/jersey/0.8-ea-SNAPSHOT/jersey-0.8-ea-SNAPSHOT.jar >>> >>> >>> I'm guessing these fall into two groups: those needed for building any >>> web app and those specific to Jersey. Maven is fairly well covered by >>> Fedora, so I don't think w'll have too much trouble there. >>> JUnit is in Fedora. >>> commons-cli is in fedora >>> >>> jsr311 is probably just a small set of source file, but it is not in >>> Fedora. >>> >>> Specific to Jersey are these: edited out of the Jersey POM >>> >>> javax.ws.rs.jsr311-api version 0.8 >>> javax.annotation.jsr250-api version 1.0 >>> javax.persistence.persistence-api version 1.0.2 >>> javax.servlet.servlet-api version 2.5 >>> asm.asm version 3.1 >>> >>> NOte that does not indicated what is needed to build Jersey, merely >>> what it requires to build another project. >>> >>> >>> Pulling the Jersey source into Eclipse without and jars to fill in >>> dependencies is more interesting. >>> >>> To build, it refers to a bunch of the Sun classes in the JREs rt.jar, >>> which have access prohibited. we can work around this with a symlink. >>> >>> >>> Other jars I started pulling in >>> >>> >>> >>> >>> >>> >>> >>> >>> >> path="/usr/share/java/tomcat6/annotations-api.jar"/> >>> >>> >>> >>> >> path="/usr/share/java/tomcat-servlet-3.0-api.jar"/> >>> >>> >>> >>> >>> The only one I haven't found so far is >>> >> path="/home/ayoung/.m2/repository/javax/enterprise/cdi-api/1.1.EDR1.1/cdi-api-1.1.EDR1.1.jar"/> >>> >>> Which appears to be Weld, or the reference implementation of JSR-299. >>> This looks interesting in its own right. >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > I'm OK with this, too. From ayoung at redhat.com Mon Nov 21 18:38:33 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 21 Nov 2011 13:38:33 -0500 Subject: [Pki-devel] [PATCH] 0012-Dead-code-removal In-Reply-To: <1321886941.2265.19.camel@aleeredhat.laptop> References: <4EBB1FF0.90409@redhat.com> <1321337517.6303.155.camel@aleeredhat.laptop> <4EC3D7C3.9060407@redhat.com> <4EC9AFF8.2060209@redhat.com> <1321886941.2265.19.camel@aleeredhat.laptop> Message-ID: <4ECA9AA9.8040107@redhat.com> On 11/21/2011 09:49 AM, Ade Lee wrote: > On Sun, 2011-11-20 at 20:57 -0500, Adam Young wrote: >> On 11/16/2011 10:33 AM, Adam Young wrote: >>> On 11/15/2011 01:11 AM, Ade Lee wrote: >>>> This is a review of this patch and the subsequent one removing >>>> unnecessary blocks. >>>> >>>> CMCAuth.java: Can you explain why this code removal is correct? >>> At this point in the code, cert can only be null. The only code >>> path that assigns a value to cert has a return after it, and cannot >>> reach this point. Thus, the code executed when cert != null is >>> unreachable >>> >>>> CAAdminServlet.java : code should be commented out, rather than >>>> removed. >>> Disagree. If this code has never been run, it is unnecessary. >>> Lets not put dead code into the source tree. >>>> HashEnrollServlet.java : remove the outer conditional as well. >>> Done >>>> DBSubsystem.java: some important comments are removed, they should >>>> not >>>> be removed. >>> Done >>>> FileAsString.java - does the proposed code removal introduce a >>>> resource >>>> leak? >>> No. FileReader can throw a file not found exception. But >>> BufferedReader only throws an IllegalArgumentException, which >>> wouldn't be caught by that catch block anyway. >>> >>>> KeyRecoveryAuthority.java: please explain why the proposed code >>>> removal >>>> is correct. It certainly looks wrong. >>> I agree that the change looks wrong. I put it back in, and Eclipse >>> did not tag it as dead code. >>>> Ade >>>> >>>> On Wed, 2011-11-09 at 19:50 -0500, Adam Young wrote: >>>>> _______________________________________________ >>>>> Pki-devel mailing list >>>>> Pki-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/pki-devel >>> >>> >>> _______________________________________________ >>> Pki-devel mailing list >>> Pki-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-devel >> Is that an ACK? >> >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > ACK > Commited to trunk. To to the PKISIlent restructuring, I had to move the ArgParser code by hand, but the change matches what was done in the patch. From ayoung at redhat.com Tue Nov 22 02:57:09 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 21 Nov 2011 21:57:09 -0500 Subject: [Pki-devel] Is clone method broken on /PropConfigStore? Message-ID: <4ECB0F85.50301@redhat.com> I've come across a piece of code resistant to the Type safety cleanup, and I suspectthat it is broken, and we are lucky that it is never blown up. CMS.init calls DBSubsystem.init() which calls PropConfigStore.clone(). So this code path is executed. In the file: http://svn.fedorahosted.org/svn/pki/trunk/pki/base/common/src/com/netscape/cmscore/base/PropConfigStore.java the clone method calls Enumeration subs = getSubStoreNames(); while (subs.hasMoreElements()) { IConfigStore sub = (IConfigStore) subs.nextElement(); So the collection returned is expected to be filled with instances that implement IConfigStore. However, looking at getSubStoreNames: String pname = (String) e.nextElement(); int i = pname.indexOf('.'); // substores have "." if (i != -1) { String n = pname.substring(0, i); if (!v.contains(n)) { v.addElement(n); } } } return v.elements(); It is definitely filling the collection with Strings. My only guess is that the collection used does not have any of the paths joined with a dot, so the returned collection is empty. SVN shows this code was checked in this way during the initial import. I'm guessing noone here has touched it. I'm planning on changing it like this: - Enumeration subs = getSubStoreNames(); + Enumeration subs = getSubStoreNames(); while (subs.hasMoreElements()) { - IConfigStore sub = (IConfigStore) - subs.nextElement(); + String subName = subs.nextElement(); + + IConfigStore sub = (IConfigStore)getSubStore(subName); If anyone objects, speak up now. From ayoung at redhat.com Tue Nov 22 16:29:19 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 22 Nov 2011 11:29:19 -0500 Subject: [Pki-devel] Fwd: Re: [freeipa] #1353: Explore how to use authentiucation tokens instead of a DM password saved into a file for connecting to CS instances In-Reply-To: <043.206c1f13c055f69b4522f7e56af1bfb5@fedorahosted.org> References: <043.206c1f13c055f69b4522f7e56af1bfb5@fedorahosted.org> Message-ID: <4ECBCDDF.7010400@redhat.com> This ticket is/was assigned to me. It is something that we should solve for PKI in general. Insteado of binding to the DS using UID/password, we should use a certificate stored in the local NSS database inside the Tomcat instance. -------- Original Message -------- Subject: Re: [freeipa] #1353: Explore how to use authentiucation tokens instead of a DM password saved into a file for connecting to CS instances Date: Tue, 22 Nov 2011 16:05:12 -0000 From: freeipa Reply-To: nobody at fedoraproject.org To: undisclosed-recipients:; #1353: Explore how to use authentiucation tokens instead of a DM password saved into a file for connecting to CS instances ----------------------+----------------------------------------------------- Reporter: simo | Owner: admiyo Type: defect | Status: new Priority: major | Milestone: 3.1 Backlog Component: IPA | Version: Resolution: | Keywords: Tests: 0 | Testsupdated: 0 Affects_cli: 0 | Candidate_to_defer: 0 Affects_doc: 0 | Estimate: On_review: 0 | ----------------------+----------------------------------------------------- Changes (by dpal): * priority: critical => major -- Ticket URL: freeipa FreeIPA -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Tue Nov 22 16:43:05 2011 From: alee at redhat.com (Ade Lee) Date: Tue, 22 Nov 2011 11:43:05 -0500 Subject: [Pki-devel] Fwd: Re: [freeipa] #1353: Explore how to use authentiucation tokens instead of a DM password saved into a file for connecting to CS instances In-Reply-To: <4ECBCDDF.7010400@redhat.com> References: <043.206c1f13c055f69b4522f7e56af1bfb5@fedorahosted.org> <4ECBCDDF.7010400@redhat.com> Message-ID: <1321980186.30457.3.camel@aleeredhat.laptop> Right. There is a ticket for this (currently assigned to me, but subject to change): https://fedorahosted.org/pki/ticket/5 Ade On Tue, 2011-11-22 at 11:29 -0500, Adam Young wrote: > This ticket is/was assigned to me. It is something that we should > solve for PKI in general. > > > Insteado of binding to the DS using UID/password, we should use a > certificate stored in the local NSS database inside the Tomcat > instance. > > > > > -------- Original Message -------- > Subject: > Re: [freeipa] #1353: Explore how to > use authentiucation tokens instead > of a DM password saved into a file > for connecting to CS instances > Date: > Tue, 22 Nov 2011 16:05:12 -0000 > From: > freeipa > Reply-To: > nobody at fedoraproject.org > To: > undisclosed-recipients:; > > > #1353: Explore how to use authentiucation tokens instead of a DM password saved > into a file for connecting to CS instances > ----------------------+----------------------------------------------------- > Reporter: simo | Owner: admiyo > Type: defect | Status: new > Priority: major | Milestone: 3.1 Backlog > Component: IPA | Version: > Resolution: | Keywords: > Tests: 0 | Testsupdated: 0 > Affects_cli: 0 | Candidate_to_defer: 0 > Affects_doc: 0 | Estimate: > On_review: 0 | > ----------------------+----------------------------------------------------- > Changes (by dpal): > > * priority: critical => major > From alee at redhat.com Wed Nov 23 15:48:42 2011 From: alee at redhat.com (Ade Lee) Date: Wed, 23 Nov 2011 10:48:42 -0500 Subject: [Pki-devel] Automatic reformatting and code style Message-ID: <1322063323.2283.6.camel@aleeredhat.laptop> Hi all, It has been decided that the code should go through an automatic reformatting on the trunk to ensure that everything matches the project's coding standards. Prior to this, we need to review the coding standards and confirm that they are what we want to use. The current coding standards for the project are referenced here: http://pki.fedoraproject.org/wiki/PKI_C_Coding_Style http://pki.fedoraproject.org/wiki/PKI_Java_Coding_Style Some alternative styles: http://freeipa.org/page/Coding_Style (C) http://www.oracle.com/technetwork/java/codeconvtoc-136057.html (java, sun conventions) We should focus on the java coding style first, followed by C. Most of the Perl code is mostly going away most likely, so no need to focus on that. IPA has a style guide for python, which, unless we have another compelling reason, we should probably use that: http://freeipa.org/page/Python_Coding_Style We'd like to get this resolved soon - so as not to obscure any future changes as we do new development. So, please devote some attention to this soon. Thanks, Ade From ayoung at redhat.com Wed Nov 23 17:26:08 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 23 Nov 2011 12:26:08 -0500 (EST) Subject: [Pki-devel] Automatic reformatting and code style In-Reply-To: <1322063323.2283.6.camel@aleeredhat.laptop> Message-ID: <0b1275ca-6bea-472b-a803-03e07951913a@zmail15.collab.prod.int.phx2.redhat.com> MIght I highly encourage that we folow the Sun guides, as it is the Inustry standard in Java, and it is pretty staightforward. ----- Original Message ----- From: "Ade Lee" To: pki-devel at redhat.com Sent: Wednesday, November 23, 2011 10:48:42 AM Subject: [Pki-devel] Automatic reformatting and code style Hi all, It has been decided that the code should go through an automatic reformatting on the trunk to ensure that everything matches the project's coding standards. Prior to this, we need to review the coding standards and confirm that they are what we want to use. The current coding standards for the project are referenced here: http://pki.fedoraproject.org/wiki/PKI_C_Coding_Style http://pki.fedoraproject.org/wiki/PKI_Java_Coding_Style Some alternative styles: http://freeipa.org/page/Coding_Style (C) http://www.oracle.com/technetwork/java/codeconvtoc-136057.html (java, sun conventions) We should focus on the java coding style first, followed by C. Most of the Perl code is mostly going away most likely, so no need to focus on that. IPA has a style guide for python, which, unless we have another compelling reason, we should probably use that: http://freeipa.org/page/Python_Coding_Style We'd like to get this resolved soon - so as not to obscure any future changes as we do new development. So, please devote some attention to this soon. Thanks, Ade _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Wed Nov 23 19:57:57 2011 From: alee at redhat.com (Ade Lee) Date: Wed, 23 Nov 2011 14:57:57 -0500 Subject: [Pki-devel] Automatic reformatting and code style In-Reply-To: <0b1275ca-6bea-472b-a803-03e07951913a@zmail15.collab.prod.int.phx2.redhat.com> References: <0b1275ca-6bea-472b-a803-03e07951913a@zmail15.collab.prod.int.phx2.redhat.com> Message-ID: <1322078288.2283.34.camel@aleeredhat.laptop> I looked at our current guidelines and noticed the following differences with the Sun guides: 1. Placement of braces In the current coding guidelines, we say classes and methods should look like this: public class MyClass { ... } instead of this (as in the Sun standard): public class MyClass { ... } 2. We require that interface names begin with "I". Sun says nothing about this. This is probably a good one to keep. 3. We specify "no tabs". Sun says tabs are optional. We should keep this. 4. We say "Static methods should begin with a capital letter with each subsequent new word in uppercase, and subsequent letters in each word in lower case. Sun has no special treatment for static methods - ie. they are treated just like other methods .. ie. beginning with a lower-case letter. 5. We do have some guidelines for naming functions that go beyond what Sun specifies - and also perhaps, beyond what eclipse can verify. For example: * Get and set methods should begin with "get" / "set" and return the appropriate object type. * Boolean get methods should use "is" or "can" as a prefix, such as "isUndoable()" rather than "getUndoable()". * Factory class names should include the word "Factory". Factory method names should start with the word "Make." * Methods for debug-only implementations should begin with "debug". * Member variables should begin with "m". For example, mMemberVariable. My take on this is that we should adopt the Sun coding standards and add the additional requirements that make sense - like the ones listed in point 5 above. For the cases where we conflict with the Sun standards, we should go with the Sun standards instead. Comments? Ade On Wed, 2011-11-23 at 12:26 -0500, Adam Young wrote: > MIght I highly encourage that we folow the Sun guides, as it is the Inustry standard in Java, and it is pretty staightforward. > > ----- Original Message ----- > From: "Ade Lee" > To: pki-devel at redhat.com > Sent: Wednesday, November 23, 2011 10:48:42 AM > Subject: [Pki-devel] Automatic reformatting and code style > > Hi all, > > It has been decided that the code should go through an automatic > reformatting on the trunk to ensure that everything matches the > project's coding standards. > > Prior to this, we need to review the coding standards and confirm that > they are what we want to use. > > The current coding standards for the project are referenced here: > http://pki.fedoraproject.org/wiki/PKI_C_Coding_Style > http://pki.fedoraproject.org/wiki/PKI_Java_Coding_Style > > Some alternative styles: > http://freeipa.org/page/Coding_Style (C) > http://www.oracle.com/technetwork/java/codeconvtoc-136057.html (java, > sun conventions) > > We should focus on the java coding style first, followed by C. Most of > the Perl code is mostly going away most likely, so no need to focus on > that. > > IPA has a style guide for python, which, unless we have another > compelling reason, we should probably use that: > > http://freeipa.org/page/Python_Coding_Style > > We'd like to get this resolved soon - so as not to obscure any future > changes as we do new development. So, please devote some attention to > this soon. > > Thanks, > Ade > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Wed Nov 23 21:05:51 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 23 Nov 2011 15:05:51 -0600 Subject: [Pki-devel] Automatic reformatting and code style In-Reply-To: <1322078288.2283.34.camel@aleeredhat.laptop> References: <0b1275ca-6bea-472b-a803-03e07951913a@zmail15.collab.prod.int.phx2.redhat.com> <1322078288.2283.34.camel@aleeredhat.laptop> Message-ID: <4ECD602F.6090402@redhat.com> On 11/23/2011 1:57 PM, Ade Lee wrote: > 1. Placement of braces I'd say we should go with Sun's style, it's more common and would be consistent with the rest of the code (e.g. if/while/switch/try): > public class MyClass { > ... > } > 2. We require that interface names begin with "I". Sun says nothing > about this. This is probably a good one to keep. Yes. > 3. We specify "no tabs". Sun says tabs are optional. We should keep > this. Yes. > 4. We say "Static methods should begin with a capital letter with each > subsequent new word in uppercase, and subsequent letters in each word in > lower case. Sun has no special treatment for static methods - ie. they > are treated just like other methods .. ie. beginning with a lower-case > letter. Yes, I don't think it needs any special treatment. Most IDE will show it italicized. > 5. We do have some guidelines for naming functions that go beyond what > Sun specifies - and also perhaps, beyond what eclipse can verify. > > For example: > * Get and set methods should begin with "get" / "set" and return the > appropriate object type. OK. > * Boolean get methods should use "is" or "can" as a prefix, such as > "isUndoable()" rather than "getUndoable()". There are probably some other words too, e.g. 'has'. > * Factory class names should include the word "Factory". Factory method > names should start with the word "Make." Would 'create' be better? 'make' doesn't always mean creating a new object. > * Methods for debug-only implementations should begin with "debug". OK. > * Member variables should begin with "m". For example, mMemberVariable. I'd prefer not to use any prefix because sometimes we want to expose an attribute publicly, in that case it would be better to use less cryptic names. Most IDE will color it differently too. -- Endi S. Dewata From ayoung at redhat.com Wed Nov 23 21:30:40 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 23 Nov 2011 16:30:40 -0500 (EST) Subject: [Pki-devel] Automatic reformatting and code style In-Reply-To: <1322078288.2283.34.camel@aleeredhat.laptop> Message-ID: >I looked at our current guidelines and noticed the following differences >with the Sun guides: > >1. Placement of braces >In the current coding guidelines, we say classes and methods should look >like this: > public class MyClass > { > ... > } > >instead of this (as in the Sun standard): > public class MyClass { > ... > } Yes please; >2. We require that interface names begin with "I". Sun says nothing >about this. This is probably a good one to keep. NO! This should go away. We definitely have too many interfaces. If there is only one Impl, we should merge Impl and interface. Hungarian notation is a crimae against Humanity. The interface should get the Good, simple name, and the Impl sould get whatever makes it special. >3. We specify "no tabs". Sun says tabs are optional. We should keep >this. Agreed. No tabs >4. We say "Static methods should begin with a capital letter with each >subsequent new word in uppercase, and subsequent letters in each word in >lower case. Sun has no special treatment for static methods - ie. they >are treated just like other methods .. ie. beginning with a lower-case >letter. lowercase the first letter. It is what everyone expects. >5. We do have some guidelines for naming functions that go beyond what >Sun specifies - and also perhaps, beyond what eclipse can verify. > >For example: >* Get and set methods should begin with "get" / "set" and return the >appropriate object type. >* Boolean get methods should use "is" or "can" as a prefix, such as >"isUndoable()" rather than "getUndoable()". >* Factory class names should include the word "Factory". Factory method >names should start with the word "Make." >* Methods for debug-only implementations should begin with "debug". These are all fine. get/set is the bean API. While I am not a fan, doing this does make things work with automated tools. >>* Member variables should begin with "m". For example, mMemberVariable.. 'm' should go away. Again, hungarina notation, obfusticates the code, and makes it hard to read. >My take on this is that we should adopt the Sun coding standards and add >the additional requirements that make sense - like the ones listed in >point 5 above. For the cases where we conflict with the Sun standards, >we should go with the Sun standards instead. Agreed. I'd like to exorcise the Hungarian naming conventions, but that can be done over time. Code is meant to be readable, and all HN does is obfuscate. It is not necessary in Java. I am pretty sure it is explictly against the Sun Java Conventions. http://www.oracle.com/technetwork/java/codeconventions-137265.html#587 There is one thing I don't really agree with. It is not only OK to make member variables public, it is a best practice, provided that you make them final. Instead of private String namel public String getName(){ return name; } it should be public final String name; public MyObject(String name){ this.name = name; } What this means is that instance variables are set in the constructor where ever possible. In general, we should favor immutable objects, as they are inherantly thread safe. It also means that we use the constructor to confirm that a given object complies with its contract. This is in Keeping with JOshua Block'ss advice in "Evffective Java" which should be required reading. From mharmsen at redhat.com Wed Nov 23 22:05:47 2011 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 23 Nov 2011 14:05:47 -0800 Subject: [Pki-devel] Automatic reformatting and code style In-Reply-To: <1322078288.2283.34.camel@aleeredhat.laptop> References: <0b1275ca-6bea-472b-a803-03e07951913a@zmail15.collab.prod.int.phx2.redhat.com> <1322078288.2283.34.camel@aleeredhat.laptop> Message-ID: <4ECD6E3B.6040808@redhat.com> On 11/23/11 11:57, Ade Lee wrote: > I looked at our current guidelines and noticed the following differences > with the Sun guides: > > 1. Placement of braces > In the current coding guidelines, we say classes and methods should look > like this: > public class MyClass > { > ... > } > > instead of this (as in the Sun standard): > public class MyClass { > ... > } The history behind this probably comes from a nice handy 'vi' shortcut (pressing ']' twice) that allows for developers to quickly find the beginning of various 'functions' in 'C'/'C++'; note that the opening brace must be a standalone character in the first column for this to work. This was probably applied to the Java code to find the beginning and ending of a 'class' in java files that contained more than one non-nested class in a single '.java' file, so I don't see that big of a problem in changing this for Java -- however, I would prefer that 'C'/'C++' functions/methods retain this handy feature, as not every programmer is particularly fond of IDEs, and I would argue that we should not require developers to use an IDE such as eclipse. That being said, I would prefer multiple non-nested public classes to reside in their own files, leaving only cases where we need/require standalone private/protected classes to co-exist within the same file? I am uncertain if we even have any of these. > 2. We require that interface names begin with "I". Sun says nothing > about this. This is probably a good one to keep. I agree that we should keep this 'handy' notation. > > 3. We specify "no tabs". Sun says tabs are optional. We should keep > this. My personal preference is to use 'spaces' instead of 'tabs' primarily due to the variable 'tabstop' settings in files. > > 4. We say "Static methods should begin with a capital letter with each > subsequent new word in uppercase, and subsequent letters in each word in > lower case. Sun has no special treatment for static methods - ie. they > are treated just like other methods .. ie. beginning with a lower-case > letter. I have no particular preference one way or another on this. > > 5. We do have some guidelines for naming functions that go beyond what > Sun specifies - and also perhaps, beyond what eclipse can verify. > > For example: > * Get and set methods should begin with "get" / "set" and return the > appropriate object type. > * Boolean get methods should use "is" or "can" as a prefix, such as > "isUndoable()" rather than "getUndoable()". > * Factory class names should include the word "Factory". Factory method > names should start with the word "Make." > * Methods for debug-only implementations should begin with "debug". > * Member variables should begin with "m". For example, mMemberVariable. These all seem fine to me. While I understand Adam's doesn't like Hungarian notation, the downside of renaming everything will make it far more difficult for the people who are the most familiar with this code to continue to make changes. > My take on this is that we should adopt the Sun coding standards and add > the additional requirements that make sense - like the ones listed in > point 5 above. For the cases where we conflict with the Sun standards, > we should go with the Sun standards instead. > > Comments? > Ade > > On Wed, 2011-11-23 at 12:26 -0500, Adam Young wrote: >> MIght I highly encourage that we folow the Sun guides, as it is the Inustry standard in Java, and it is pretty staightforward. >> >> ----- Original Message ----- >> From: "Ade Lee" >> To: pki-devel at redhat.com >> Sent: Wednesday, November 23, 2011 10:48:42 AM >> Subject: [Pki-devel] Automatic reformatting and code style >> >> Hi all, >> >> It has been decided that the code should go through an automatic >> reformatting on the trunk to ensure that everything matches the >> project's coding standards. >> >> Prior to this, we need to review the coding standards and confirm that >> they are what we want to use. >> >> The current coding standards for the project are referenced here: >> http://pki.fedoraproject.org/wiki/PKI_C_Coding_Style >> http://pki.fedoraproject.org/wiki/PKI_Java_Coding_Style >> >> Some alternative styles: >> http://freeipa.org/page/Coding_Style (C) >> http://www.oracle.com/technetwork/java/codeconvtoc-136057.html (java, >> sun conventions) >> >> We should focus on the java coding style first, followed by C. Most of >> the Perl code is mostly going away most likely, so no need to focus on >> that. >> >> IPA has a style guide for python, which, unless we have another >> compelling reason, we should probably use that: >> >> http://freeipa.org/page/Python_Coding_Style >> >> We'd like to get this resolved soon - so as not to obscure any future >> changes as we do new development. So, please devote some attention to >> this soon. >> >> Thanks, >> Ade >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From jdennis at redhat.com Wed Nov 23 22:25:12 2011 From: jdennis at redhat.com (John Dennis) Date: Wed, 23 Nov 2011 17:25:12 -0500 Subject: [Pki-devel] Automatic reformatting and code style In-Reply-To: <1322078288.2283.34.camel@aleeredhat.laptop> References: <0b1275ca-6bea-472b-a803-03e07951913a@zmail15.collab.prod.int.phx2.redhat.com> <1322078288.2283.34.camel@aleeredhat.laptop> Message-ID: <4ECD72C8.9070305@redhat.com> On 11/23/2011 02:57 PM, Ade Lee wrote: > instead of this (as in the Sun standard): > public class MyClass { > ... > } preferred, closer to K&R, you can more lines of code on the screen if you don't allocate one line just for a brace. > 2. We require that interface names begin with "I". Sun says nothing > about this. This is probably a good one to keep. Using an initial character to declare a type was a bad idea over a half century ago when Fortran was invented, but of course there were justifiable limitations in the 1950's but those have vanished, oh let's say 30-40 years ago. Then some idiot at Microsoft came up with Hungarian notation, one of the worst ideas I've ever seen. In a strongly typed language there is absolutely no need to encode the type of the object in it's name, a throwback to a bad idea in Fortran which diminishes readability for no apparent useful reason. Let's not encode the type in the name. The name should be self evident and if you still can't figure out the type then look up it's declaration. I also don't believe in declaring interfaces unless there is a need. Excessive use of interfaces for which there is only one class implementing the interface just makes the code more verbose and harder to understand what's going on. The presence of an interface implies there is some public sharing between objects. Can't tell you the number of times I went looking for all the places an interface was used only to discover it was just one self contained class, go figure. > 3. We specify "no tabs". Sun says tabs are optional. We should keep > this. No tabs. Everyone has a different idea of what tab width should be and if they aren't the same, which they never are, all you get is a jumbled mess. > > 4. We say "Static methods should begin with a capital letter with each > subsequent new word in uppercase, and subsequent letters in each word in > lower case. Sun has no special treatment for static methods - ie. they > are treated just like other methods .. ie. beginning with a lower-case > letter. > > 5. We do have some guidelines for naming functions that go beyond what > Sun specifies - and also perhaps, beyond what eclipse can verify. > > For example: > * Get and set methods should begin with "get" / "set" and return the > appropriate object type. > * Boolean get methods should use "is" or "can" as a prefix, such as > "isUndoable()" rather than "getUndoable()". > * Factory class names should include the word "Factory". Factory method > names should start with the word "Make." > * Methods for debug-only implementations should begin with "debug". All good. > * Member variables should begin with "m". For example, mMemberVariable. Another incredibly annoying convention, see above rant about encoding type information in a symbol name. Objects essentially can only have member variables and methods, if someone can't figure out the difference then prefixing it with an 'm' is the least of their problems :-) -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ayoung at redhat.com Wed Nov 23 22:50:09 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 23 Nov 2011 17:50:09 -0500 (EST) Subject: [Pki-devel] Automatic reformatting and code style In-Reply-To: <4ECD6E3B.6040808@redhat.com> Message-ID: vi long since became capable of handling either format. I'll leave it as ana excersize to you vi guys to figure out how to get it to match. Renaming is trivial in Eclipse, and "Its always been done this way" is not sufficient grounds to keep up a bad practice. The code is going to shrink, get reordred, and things are going to get renamed. THis is acleanup that will have a very large net positive advantage, and we have the flexibility to do it right. Lets not hamstring outselves with decisions bad in the past that no longer apply: keep the good, but don't hoard things, esepcially not in code. INterfaces have their uses, but the PKI code base shows some of the mistakes made by following the "best practices" of the day that have since been discarded. Interfaces in Java should be used for cutting dependncies, information hading and the like, but should be the exception, not the rule. A fundamental guideline is "favor collaboration over inheritance" and that means Interfaces as well as abstract base classes. I'm not saying "Don't use them" but I am saying "Be prepared to justify their use" if you do. For the domain model, using an IRequest to front RequestImpl where there is only one Impl is an anti-pattern. a Date transfer object should have minimal functionality in it, and no external dependencies. Thus, it gains no benefit from the abstraction of the Interface. A much better approach is to make Request a POJO, and, if posssible, immutable. I'll go more into how to code this way as examples pop up. Sorry for top posting, but I'm having mail failure and can only use Zimbra web, which doesn't do the > thing. ----- Original Message ----- From: "Matthew Harmsen" To: alee at redhat.com Cc: "Adam Young" , pki-devel at redhat.com Sent: Wednesday, November 23, 2011 5:05:47 PM Subject: Re: [Pki-devel] Automatic reformatting and code style On 11/23/11 11:57, Ade Lee wrote: > I looked at our current guidelines and noticed the following differences > with the Sun guides: > > 1. Placement of braces > In the current coding guidelines, we say classes and methods should look > like this: > public class MyClass > { > ... > } > > instead of this (as in the Sun standard): > public class MyClass { > ... > } The history behind this probably comes from a nice handy 'vi' shortcut (pressing ']' twice) that allows for developers to quickly find the beginning of various 'functions' in 'C'/'C++'; note that the opening brace must be a standalone character in the first column for this to work. This was probably applied to the Java code to find the beginning and ending of a 'class' in java files that contained more than one non-nested class in a single '.java' file, so I don't see that big of a problem in changing this for Java -- however, I would prefer that 'C'/'C++' functions/methods retain this handy feature, as not every programmer is particularly fond of IDEs, and I would argue that we should not require developers to use an IDE such as eclipse. That being said, I would prefer multiple non-nested public classes to reside in their own files, leaving only cases where we need/require standalone private/protected classes to co-exist within the same file? I am uncertain if we even have any of these. > 2. We require that interface names begin with "I". Sun says nothing > about this. This is probably a good one to keep. I agree that we should keep this 'handy' notation. > > 3. We specify "no tabs". Sun says tabs are optional. We should keep > this. My personal preference is to use 'spaces' instead of 'tabs' primarily due to the variable 'tabstop' settings in files. > > 4. We say "Static methods should begin with a capital letter with each > subsequent new word in uppercase, and subsequent letters in each word in > lower case. Sun has no special treatment for static methods - ie. they > are treated just like other methods .. ie. beginning with a lower-case > letter. I have no particular preference one way or another on this. > > 5. We do have some guidelines for naming functions that go beyond what > Sun specifies - and also perhaps, beyond what eclipse can verify. > > For example: > * Get and set methods should begin with "get" / "set" and return the > appropriate object type. > * Boolean get methods should use "is" or "can" as a prefix, such as > "isUndoable()" rather than "getUndoable()". > * Factory class names should include the word "Factory". Factory method > names should start with the word "Make." > * Methods for debug-only implementations should begin with "debug". > * Member variables should begin with "m". For example, mMemberVariable. These all seem fine to me. While I understand Adam's doesn't like Hungarian notation, the downside of renaming everything will make it far more difficult for the people who are the most familiar with this code to continue to make changes. > My take on this is that we should adopt the Sun coding standards and add > the additional requirements that make sense - like the ones listed in > point 5 above. For the cases where we conflict with the Sun standards, > we should go with the Sun standards instead. > > Comments? > Ade > > On Wed, 2011-11-23 at 12:26 -0500, Adam Young wrote: >> MIght I highly encourage that we folow the Sun guides, as it is the Inustry standard in Java, and it is pretty staightforward. >> >> ----- Original Message ----- >> From: "Ade Lee" >> To: pki-devel at redhat.com >> Sent: Wednesday, November 23, 2011 10:48:42 AM >> Subject: [Pki-devel] Automatic reformatting and code style >> >> Hi all, >> >> It has been decided that the code should go through an automatic >> reformatting on the trunk to ensure that everything matches the >> project's coding standards. >> >> Prior to this, we need to review the coding standards and confirm that >> they are what we want to use. >> >> The current coding standards for the project are referenced here: >> http://pki.fedoraproject.org/wiki/PKI_C_Coding_Style >> http://pki.fedoraproject.org/wiki/PKI_Java_Coding_Style >> >> Some alternative styles: >> http://freeipa.org/page/Coding_Style (C) >> http://www.oracle.com/technetwork/java/codeconvtoc-136057.html (java, >> sun conventions) >> >> We should focus on the java coding style first, followed by C. Most of >> the Perl code is mostly going away most likely, so no need to focus on >> that. >> >> IPA has a style guide for python, which, unless we have another >> compelling reason, we should probably use that: >> >> http://freeipa.org/page/Python_Coding_Style >> >> We'd like to get this resolved soon - so as not to obscure any future >> changes as we do new development. So, please devote some attention to >> this soon. >> >> Thanks, >> Ade >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From mharmsen at redhat.com Thu Nov 24 03:33:17 2011 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 23 Nov 2011 19:33:17 -0800 Subject: [Pki-devel] Removal of PKI Contributor License Agreement Message-ID: <4ECDBAFD.2050708@redhat.com> Everyone, Great news! It has been determined by our legal department that Dogtag no longer requires that a "Contributor License Agreement" be signed and filed prior to accepting code submittals for the Dogtag Certificate System! Therefore, I have removed the following two pages (and hopefully removed all references to this requirement from 'pki.fedoraproject.org'): * pki.fedoraproject.org/wiki/PKI_SVN_Rules * pki.fedoraproject.org/wiki/PKI_Contributor_License_Agreement * pki.fedoraproject.org/wiki/PKI_Contributing (previously referenced CLA) * pki.fedoraproject.org/wiki/PKI_FAQ (previously referenced CLA) -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Mon Nov 28 15:15:39 2011 From: alee at redhat.com (Ade Lee) Date: Mon, 28 Nov 2011 10:15:39 -0500 Subject: [Pki-devel] Automatic reformatting and code style In-Reply-To: References: Message-ID: <1322493340.18330.26.camel@aleeredhat.laptop> I had no idea that the naming of interfaces and member fields would generate such debate. I'm going to play devil's advocate here, and argue FOR keeping the convention of prefixing "m" to object fields. 1. The arguments against Hungarian notation have mostly been made against what is called "systems Hungarian" - that is, things that are readily checked by a compiler or an IDE. When I hover over a variable in eclipse, it will tell me the type - so there is no need to prefix the variable with that information. Using iFoo for an integer is counterproductive for those reasons. Attaching "m" to an object tells us about scope - which is not displayed when I hover over the variable. Sure, I can look up the declaration - but with the prefix, I don't have to. 2. Does the "m" prefix make the code less readable? I don't think so - we're not talking about plzFoo here. What it does do, is allow me when looking at segment of code - to instantly determine whether the variables in the code are local to the function or member variables. 3. You may want to change the scope of a variable - and this would require you to rename the variable. But I would argue that this is a conscious decision - and one that will likely require the addition/removal of getters/setters. Having the variable prefixed by "m" requires you to think about that. And as has been mentioned, renaming is trivial in eclipse. 4. Renaming a specific variable is trivial in eclipse, but I have not found a simple way to do a mass renaming so that all the variables that are now in Hungarian notation in eclipse. There is a way to enforce the use of a prefix - but not a way to systematically remove the prefixes. If we can't do that, then we run the risk of having code which conformed to old standard - along with code which conformed to a new standard which did not require the "m" - which I would argue is much worse. 5. Even if we could remove all Hungarian notation, this would make merges from 8.X to the tip much more labor intensive. Its one thing to have to do things manually because of formatting. Its another to have to replace variables stuck in the code. Ade On Wed, 2011-11-23 at 17:50 -0500, Adam Young wrote: > vi long since became capable of handling either format. I'll leave it as ana excersize to you vi guys to figure out how to get it to match. > > Renaming is trivial in Eclipse, and "Its always been done this way" is not sufficient grounds to keep up a bad practice. > > > The code is going to shrink, get reordred, and things are going to get renamed. THis is acleanup that will have a very large net positive advantage, and we have the flexibility to do it right. Lets not hamstring outselves with decisions bad in the past that no longer apply: keep the good, but don't hoard things, esepcially not in code. > > INterfaces have their uses, but the PKI code base shows some of the mistakes made by following the "best practices" of the day that have since been discarded. Interfaces in Java should be used for cutting dependncies, information hading and the like, but should be the exception, not the rule. A fundamental guideline is "favor collaboration over inheritance" and that means Interfaces as well as abstract base classes. I'm not saying "Don't use them" but I am saying "Be prepared to justify their use" if you do. > > > For the domain model, using an IRequest to front RequestImpl where there is only one Impl is an anti-pattern. a Date transfer object should have minimal functionality in it, and no external dependencies. Thus, it gains no benefit from the abstraction of the Interface. > > A much better approach is to make Request a POJO, and, if posssible, immutable. I'll go more into how to code this way as examples pop up. > > > > Sorry for top posting, but I'm having mail failure and can only use Zimbra web, which doesn't do the > thing. > > > ----- Original Message ----- > From: "Matthew Harmsen" > To: alee at redhat.com > Cc: "Adam Young" , pki-devel at redhat.com > Sent: Wednesday, November 23, 2011 5:05:47 PM > Subject: Re: [Pki-devel] Automatic reformatting and code style > > On 11/23/11 11:57, Ade Lee wrote: > > I looked at our current guidelines and noticed the following differences > > with the Sun guides: > > > > 1. Placement of braces > > In the current coding guidelines, we say classes and methods should look > > like this: > > public class MyClass > > { > > ... > > } > > > > instead of this (as in the Sun standard): > > public class MyClass { > > ... > > } > The history behind this probably comes from a nice handy 'vi' shortcut > (pressing ']' twice) that allows for developers to quickly find the > beginning of > various 'functions' in 'C'/'C++'; note that the opening brace must be a > standalone > character in the first column for this to work. > > This was probably applied to the Java code to find the beginning and > ending of a > 'class' in java files that contained more than one non-nested class in a > single '.java' > file, so I don't see that big of a problem in changing this for Java -- > however, > I would prefer that 'C'/'C++' functions/methods retain this handy > feature, as > not every programmer is particularly fond of IDEs, and I would argue that we > should not require developers to use an IDE such as eclipse. > > That being said, I would prefer multiple non-nested public classes to > reside in their > own files, leaving only cases where we need/require standalone > private/protected > classes to co-exist within the same file? I am uncertain if we even > have any of these. > > > 2. We require that interface names begin with "I". Sun says nothing > > about this. This is probably a good one to keep. > I agree that we should keep this 'handy' notation. > > > > 3. We specify "no tabs". Sun says tabs are optional. We should keep > > this. > My personal preference is to use 'spaces' instead of 'tabs' primarily > due to the > variable 'tabstop' settings in files. > > > > 4. We say "Static methods should begin with a capital letter with each > > subsequent new word in uppercase, and subsequent letters in each word in > > lower case. Sun has no special treatment for static methods - ie. they > > are treated just like other methods .. ie. beginning with a lower-case > > letter. > I have no particular preference one way or another on this. > > > > 5. We do have some guidelines for naming functions that go beyond what > > Sun specifies - and also perhaps, beyond what eclipse can verify. > > > > For example: > > * Get and set methods should begin with "get" / "set" and return the > > appropriate object type. > > * Boolean get methods should use "is" or "can" as a prefix, such as > > "isUndoable()" rather than "getUndoable()". > > * Factory class names should include the word "Factory". Factory method > > names should start with the word "Make." > > * Methods for debug-only implementations should begin with "debug". > > * Member variables should begin with "m". For example, mMemberVariable. > These all seem fine to me. > > While I understand Adam's doesn't like Hungarian notation, the > downside of renaming everything will make it far more difficult > for the people who are the most familiar with this code to > continue to make changes. > > > My take on this is that we should adopt the Sun coding standards and add > > the additional requirements that make sense - like the ones listed in > > point 5 above. For the cases where we conflict with the Sun standards, > > we should go with the Sun standards instead. > > > > Comments? > > Ade > > > > On Wed, 2011-11-23 at 12:26 -0500, Adam Young wrote: > >> MIght I highly encourage that we folow the Sun guides, as it is the Inustry standard in Java, and it is pretty staightforward. > >> > >> ----- Original Message ----- > >> From: "Ade Lee" > >> To: pki-devel at redhat.com > >> Sent: Wednesday, November 23, 2011 10:48:42 AM > >> Subject: [Pki-devel] Automatic reformatting and code style > >> > >> Hi all, > >> > >> It has been decided that the code should go through an automatic > >> reformatting on the trunk to ensure that everything matches the > >> project's coding standards. > >> > >> Prior to this, we need to review the coding standards and confirm that > >> they are what we want to use. > >> > >> The current coding standards for the project are referenced here: > >> http://pki.fedoraproject.org/wiki/PKI_C_Coding_Style > >> http://pki.fedoraproject.org/wiki/PKI_Java_Coding_Style > >> > >> Some alternative styles: > >> http://freeipa.org/page/Coding_Style (C) > >> http://www.oracle.com/technetwork/java/codeconvtoc-136057.html (java, > >> sun conventions) > >> > >> We should focus on the java coding style first, followed by C. Most of > >> the Perl code is mostly going away most likely, so no need to focus on > >> that. > >> > >> IPA has a style guide for python, which, unless we have another > >> compelling reason, we should probably use that: > >> > >> http://freeipa.org/page/Python_Coding_Style > >> > >> We'd like to get this resolved soon - so as not to obscure any future > >> changes as we do new development. So, please devote some attention to > >> this soon. > >> > >> Thanks, > >> Ade > >> > >> _______________________________________________ > >> Pki-devel mailing list > >> Pki-devel at redhat.com > >> https://www.redhat.com/mailman/listinfo/pki-devel > > > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > From alee at redhat.com Mon Nov 28 15:34:05 2011 From: alee at redhat.com (Ade Lee) Date: Mon, 28 Nov 2011 10:34:05 -0500 Subject: [Pki-devel] Automatic reformatting and code style In-Reply-To: References: Message-ID: <1322494446.19037.1.camel@aleeredhat.laptop> I had no idea that the naming of interfaces and member fields would generate such spirited debate. I'm going to play devil's advocate here, and argue FOR keeping the convention of prefixing "m" to object fields. 1. The arguments against Hungarian notation have mostly been made against what is called "systems Hungarian" - that is, things that are readily checked by a compiler or an IDE. When I hover over a variable in eclipse, it will tell me the type - so there is no need to prefix the variable with that information. Using iFoo for an integer is counterproductive for those reasons. Attaching "m" to an object tells us about scope - which is not displayed when I hover over the variable. Sure, I can look up the declaration - but with the prefix, I don't have to. 2. Does the "m" prefix make the code less readable? I don't think so - we're not talking about plzFoo here. What it does do, is allow me when looking at segment of code - to instantly determine whether the variables in the code are local to the function or member variables. 3. You may want to change the scope of a variable - and this would require you to rename the variable. But I would argue that this is a conscious decision - and one that will likely require the addition/removal of getters/setters. Having the variable prefixed by "m" requires you to think about that. And as has been mentioned, renaming is trivial in eclipse. 4. Renaming a specific variable is trivial in eclipse, but I have not found a simple way to do a mass renaming so that all the variables that are now in Hungarian notation in eclipse. There is a way to enforce the use of a prefix - but not a way to systematically remove the prefixes. If we can't do that, then we run the risk of having code which conformed to old standard - along with code which conformed to a new standard which did not require the "m" - which I would argue is much worse. 5. Even if we could remove all Hungarian notation, this would make merges from 8.X to the tip much more labor intensive. Its one thing to have to do things manually because of formatting. Its another to have to replace variables stuck in the code. Ade On Wed, 2011-11-23 at 17:50 -0500, Adam Young wrote: > vi long since became capable of handling either format. I'll leave it as ana excersize to you vi guys to figure out how to get it to match. > > Renaming is trivial in Eclipse, and "Its always been done this way" is not sufficient grounds to keep up a bad practice. > > > The code is going to shrink, get reordred, and things are going to get renamed. THis is acleanup that will have a very large net positive advantage, and we have the flexibility to do it right. Lets not hamstring outselves with decisions bad in the past that no longer apply: keep the good, but don't hoard things, esepcially not in code. > > INterfaces have their uses, but the PKI code base shows some of the mistakes made by following the "best practices" of the day that have since been discarded. Interfaces in Java should be used for cutting dependncies, information hading and the like, but should be the exception, not the rule. A fundamental guideline is "favor collaboration over inheritance" and that means Interfaces as well as abstract base classes. I'm not saying "Don't use them" but I am saying "Be prepared to justify their use" if you do. > > > For the domain model, using an IRequest to front RequestImpl where there is only one Impl is an anti-pattern. a Date transfer object should have minimal functionality in it, and no external dependencies. Thus, it gains no benefit from the abstraction of the Interface. > > A much better approach is to make Request a POJO, and, if posssible, immutable. I'll go more into how to code this way as examples pop up. > > > > Sorry for top posting, but I'm having mail failure and can only use Zimbra web, which doesn't do the > thing. > > > ----- Original Message ----- > From: "Matthew Harmsen" > To: alee at redhat.com > Cc: "Adam Young" , pki-devel at redhat.com > Sent: Wednesday, November 23, 2011 5:05:47 PM > Subject: Re: [Pki-devel] Automatic reformatting and code style > > On 11/23/11 11:57, Ade Lee wrote: > > I looked at our current guidelines and noticed the following differences > > with the Sun guides: > > > > 1. Placement of braces > > In the current coding guidelines, we say classes and methods should look > > like this: > > public class MyClass > > { > > ... > > } > > > > instead of this (as in the Sun standard): > > public class MyClass { > > ... > > } > The history behind this probably comes from a nice handy 'vi' shortcut > (pressing ']' twice) that allows for developers to quickly find the > beginning of > various 'functions' in 'C'/'C++'; note that the opening brace must be a > standalone > character in the first column for this to work. > > This was probably applied to the Java code to find the beginning and > ending of a > 'class' in java files that contained more than one non-nested class in a > single '.java' > file, so I don't see that big of a problem in changing this for Java -- > however, > I would prefer that 'C'/'C++' functions/methods retain this handy > feature, as > not every programmer is particularly fond of IDEs, and I would argue that we > should not require developers to use an IDE such as eclipse. > > That being said, I would prefer multiple non-nested public classes to > reside in their > own files, leaving only cases where we need/require standalone > private/protected > classes to co-exist within the same file? I am uncertain if we even > have any of these. > > > 2. We require that interface names begin with "I". Sun says nothing > > about this. This is probably a good one to keep. > I agree that we should keep this 'handy' notation. > > > > 3. We specify "no tabs". Sun says tabs are optional. We should keep > > this. > My personal preference is to use 'spaces' instead of 'tabs' primarily > due to the > variable 'tabstop' settings in files. > > > > 4. We say "Static methods should begin with a capital letter with each > > subsequent new word in uppercase, and subsequent letters in each word in > > lower case. Sun has no special treatment for static methods - ie. they > > are treated just like other methods .. ie. beginning with a lower-case > > letter. > I have no particular preference one way or another on this. > > > > 5. We do have some guidelines for naming functions that go beyond what > > Sun specifies - and also perhaps, beyond what eclipse can verify. > > > > For example: > > * Get and set methods should begin with "get" / "set" and return the > > appropriate object type. > > * Boolean get methods should use "is" or "can" as a prefix, such as > > "isUndoable()" rather than "getUndoable()". > > * Factory class names should include the word "Factory". Factory method > > names should start with the word "Make." > > * Methods for debug-only implementations should begin with "debug". > > * Member variables should begin with "m". For example, mMemberVariable. > These all seem fine to me. > > While I understand Adam's doesn't like Hungarian notation, the > downside of renaming everything will make it far more difficult > for the people who are the most familiar with this code to > continue to make changes. > > > My take on this is that we should adopt the Sun coding standards and add > > the additional requirements that make sense - like the ones listed in > > point 5 above. For the cases where we conflict with the Sun standards, > > we should go with the Sun standards instead. > > > > Comments? > > Ade > > > > On Wed, 2011-11-23 at 12:26 -0500, Adam Young wrote: > >> MIght I highly encourage that we folow the Sun guides, as it is the Inustry standard in Java, and it is pretty staightforward. > >> > >> ----- Original Message ----- > >> From: "Ade Lee" > >> To: pki-devel at redhat.com > >> Sent: Wednesday, November 23, 2011 10:48:42 AM > >> Subject: [Pki-devel] Automatic reformatting and code style > >> > >> Hi all, > >> > >> It has been decided that the code should go through an automatic > >> reformatting on the trunk to ensure that everything matches the > >> project's coding standards. > >> > >> Prior to this, we need to review the coding standards and confirm that > >> they are what we want to use. > >> > >> The current coding standards for the project are referenced here: > >> http://pki.fedoraproject.org/wiki/PKI_C_Coding_Style > >> http://pki.fedoraproject.org/wiki/PKI_Java_Coding_Style > >> > >> Some alternative styles: > >> http://freeipa.org/page/Coding_Style (C) > >> http://www.oracle.com/technetwork/java/codeconvtoc-136057.html (java, > >> sun conventions) > >> > >> We should focus on the java coding style first, followed by C. Most of > >> the Perl code is mostly going away most likely, so no need to focus on > >> that. > >> > >> IPA has a style guide for python, which, unless we have another > >> compelling reason, we should probably use that: > >> > >> http://freeipa.org/page/Python_Coding_Style > >> > >> We'd like to get this resolved soon - so as not to obscure any future > >> changes as we do new development. So, please devote some attention to > >> this soon. > >> > >> Thanks, > >> Ade > >> > >> _______________________________________________ > >> Pki-devel mailing list > >> Pki-devel at redhat.com > >> https://www.redhat.com/mailman/listinfo/pki-devel > > > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > From edewata at redhat.com Mon Nov 28 18:48:22 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 28 Nov 2011 12:48:22 -0600 Subject: [Pki-devel] [PATCH] 1 Added support for JUnit in CMake. Message-ID: <4ED3D776.2090306@redhat.com> A new function add_junit_test() has been added to execute JUnit tests in CMake. The function is used to execute the unit tests in the common package. Ticket #36 Note: The test report will be handled in a separate patch. JUnit doesn't have a built-in report generator, so we might have to write a custom code to generate this kind of report: http://stackoverflow.com/questions/4922867/junit-xml-format-specification-that-hudson-supports -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-edewata-0001-Added-support-for-JUnit-in-CMake.patch Type: text/x-patch Size: 7337 bytes Desc: not available URL: From ayoung at redhat.com Mon Nov 28 19:29:55 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 28 Nov 2011 14:29:55 -0500 Subject: [Pki-devel] [PATCH] 1 Added support for JUnit in CMake. In-Reply-To: <4ED3D776.2090306@redhat.com> References: <4ED3D776.2090306@redhat.com> Message-ID: <4ED3E133.7030207@redhat.com> Andreas, can you give this a review? Is this something that can get into upstream? On 11/28/2011 01:48 PM, Endi Sukma Dewata wrote: > A new function add_junit_test() has been added to execute JUnit > tests in CMake. The function is used to execute the unit tests in > the common package. > > Ticket #36 > > Note: The test report will be handled in a separate patch. JUnit > doesn't have a built-in report generator, so we might have to write a > custom code to generate this kind of report: > > http://stackoverflow.com/questions/4922867/junit-xml-format-specification-that-hudson-supports > > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Mon Nov 28 21:41:17 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 28 Nov 2011 16:41:17 -0500 Subject: [Pki-devel] Automatic reformatting and code style In-Reply-To: <1322078288.2283.34.camel@aleeredhat.laptop> References: <0b1275ca-6bea-472b-a803-03e07951913a@zmail15.collab.prod.int.phx2.redhat.com> <1322078288.2283.34.camel@aleeredhat.laptop> Message-ID: <4ED3FFFD.7050307@redhat.com> Can't find Ade's oreigianl message, but regarding the m at the beginning of member variables: No. Just no. It is not needed, it makes things hard to change. If the scope is so difficult to track, there is something wrong with the class. No Systems Hungarian. No Applications Hungarian. None of it. It is not needed, does not help, and makes things hard to read. Besides, it sets everyone's teeth on edge. Let it go. From ayoung at redhat.com Mon Nov 28 22:19:44 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 28 Nov 2011 17:19:44 -0500 Subject: [Pki-devel] [PATCH] 1 Added support for JUnit in CMake. In-Reply-To: <4ED3D776.2090306@redhat.com> References: <4ED3D776.2090306@redhat.com> Message-ID: <4ED40900.5070505@redhat.com> On 11/28/2011 01:48 PM, Endi Sukma Dewata wrote: > A new function add_junit_test() has been added to execute JUnit > tests in CMake. The function is used to execute the unit tests in > the common package. > > Ticket #36 > > Note: The test report will be handled in a separate patch. JUnit > doesn't have a built-in report generator, so we might have to write a > custom code to generate this kind of report: > > http://stackoverflow.com/questions/4922867/junit-xml-format-specification-that-hudson-supports > > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ACK from me. I applied the patch and ran the scripte build_dogtag_pki which still ran successfully. I also applied and ran the tests by hand usig cmake: -DVAR_INSTALL_DIR:PATH=/var -DBUILD_PKI_CORE:BOOL=ON -DJAVA_LIB_INSTALL_DIR=/usr/lib64/java ../../pki/pki/ make make test We'll push it as soon as we get the git repo established and approved. Can you open tickets for the TODO messages in the code, specifically about the one for automatically finding all of the JUnit tests? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Tue Nov 29 00:47:38 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 28 Nov 2011 19:47:38 -0500 Subject: [Pki-devel] Git repo in testing mode Message-ID: <4ED42BAA.1080503@redhat.com> We have a Git Repo up on Fedorahosted. We are still testing it out, but we've imported the Git tree into it. As of now there are only two remote branches exposed. The others are there, but due to the way SVN m,aps to git, we are concerned that exposing more will significantly bloat the git checkouts. http://git.fedorahosted.org/git/?p=pki.git;a=summary If you are a member of the gitpki group, you can checkout out using ssh, and should be able to commit: git clone ssh://$USERNAME at git.fedorahosted.org/git/pki.git Read only access is available via the git protocol or the http protocol from the links on the page above. Question: do we want to move the 8 Series work into this repository as well? From cfu at redhat.com Tue Nov 29 01:40:28 2011 From: cfu at redhat.com (Christina) Date: Mon, 28 Nov 2011 17:40:28 -0800 Subject: [Pki-devel] Automatic reformatting and code style In-Reply-To: <1322494446.19037.1.camel@aleeredhat.laptop> References: <1322494446.19037.1.camel@aleeredhat.laptop> Message-ID: <4ED4380C.9040901@redhat.com> I agree with Ade. I have been busy with the actual pki implementation and bug fixes and I'm not sure if I'm supposed to pay attention to this subject (and I didn't much), but I think it's worthwhile to chime in. I have worked on the project for maybe 13 or 15 years since my Netscape days, so I may be partial, but I think it's a good idea to hear out both sides of the debate. This is not the 1st controversial item that I have observed, and I have no idea what happened to the other ones in the end. May I suggest that you guys separate the non-controversial items from the controversial ones and leave the controversial ones alone until people debate it out? Perhaps a wiki page to capture all the controversial issues so for those of us who can't follow the whole email threads all the time can have a chance to go to the wiki and find out points from both sides of the debate? Each side should be able to go to the wiki and put down your points. Then we vote at some point, hopefully when I'm around? Is this acceptable? thanks! Christina On 11/28/2011 07:34 AM, Ade Lee wrote: > I had no idea that the naming of interfaces and member fields would > generate such spirited debate. > > I'm going to play devil's advocate here, and argue FOR keeping the > convention of prefixing "m" to object fields. > > 1. The arguments against Hungarian notation have mostly been made > against what is called "systems Hungarian" - that is, things that are > readily checked by a compiler or an IDE. > > When I hover over a variable in eclipse, it will tell me the type - so > there is no need to prefix the variable with that information. Using > iFoo for an integer is counterproductive for those reasons. > > Attaching "m" to an object tells us about scope - which is not displayed > when I hover over the variable. Sure, I can look up the declaration - > but with the prefix, I don't have to. > > 2. Does the "m" prefix make the code less readable? I don't think so - > we're not talking about plzFoo here. What it does do, is allow me when > looking at segment of code - to instantly determine whether the > variables in the code are local to the function or member variables. > > 3. You may want to change the scope of a variable - and this would > require you to rename the variable. But I would argue that this is a > conscious decision - and one that will likely require the > addition/removal of getters/setters. Having the variable prefixed by > "m" requires you to think about that. And as has been mentioned, > renaming is trivial in eclipse. > > 4. Renaming a specific variable is trivial in eclipse, but I have not > found a simple way to do a mass renaming so that all the variables that > are now in Hungarian notation in eclipse. There is a way to enforce the > use of a prefix - but not a way to systematically remove the prefixes. > > If we can't do that, then we run the risk of having code which conformed > to old standard - along with code which conformed to a new standard > which did not require the "m" - which I would argue is much worse. > > 5. Even if we could remove all Hungarian notation, this would make > merges from 8.X to the tip much more labor intensive. Its one thing to > have to do things manually because of formatting. Its another to have > to replace variables stuck in the code. > > Ade > > On Wed, 2011-11-23 at 17:50 -0500, Adam Young wrote: >> vi long since became capable of handling either format. I'll leave it as ana excersize to you vi guys to figure out how to get it to match. >> >> Renaming is trivial in Eclipse, and "Its always been done this way" is not sufficient grounds to keep up a bad practice. >> >> >> The code is going to shrink, get reordred, and things are going to get renamed. THis is acleanup that will have a very large net positive advantage, and we have the flexibility to do it right. Lets not hamstring outselves with decisions bad in the past that no longer apply: keep the good, but don't hoard things, esepcially not in code. >> >> INterfaces have their uses, but the PKI code base shows some of the mistakes made by following the "best practices" of the day that have since been discarded. Interfaces in Java should be used for cutting dependncies, information hading and the like, but should be the exception, not the rule. A fundamental guideline is "favor collaboration over inheritance" and that means Interfaces as well as abstract base classes. I'm not saying "Don't use them" but I am saying "Be prepared to justify their use" if you do. >> >> >> For the domain model, using an IRequest to front RequestImpl where there is only one Impl is an anti-pattern. a Date transfer object should have minimal functionality in it, and no external dependencies. Thus, it gains no benefit from the abstraction of the Interface. >> >> A much better approach is to make Request a POJO, and, if posssible, immutable. I'll go more into how to code this way as examples pop up. >> >> >> >> Sorry for top posting, but I'm having mail failure and can only use Zimbra web, which doesn't do the> thing. >> >> >> ----- Original Message ----- >> From: "Matthew Harmsen" >> To: alee at redhat.com >> Cc: "Adam Young", pki-devel at redhat.com >> Sent: Wednesday, November 23, 2011 5:05:47 PM >> Subject: Re: [Pki-devel] Automatic reformatting and code style >> >> On 11/23/11 11:57, Ade Lee wrote: >>> I looked at our current guidelines and noticed the following differences >>> with the Sun guides: >>> >>> 1. Placement of braces >>> In the current coding guidelines, we say classes and methods should look >>> like this: >>> public class MyClass >>> { >>> ... >>> } >>> >>> instead of this (as in the Sun standard): >>> public class MyClass { >>> ... >>> } >> The history behind this probably comes from a nice handy 'vi' shortcut >> (pressing ']' twice) that allows for developers to quickly find the >> beginning of >> various 'functions' in 'C'/'C++'; note that the opening brace must be a >> standalone >> character in the first column for this to work. >> >> This was probably applied to the Java code to find the beginning and >> ending of a >> 'class' in java files that contained more than one non-nested class in a >> single '.java' >> file, so I don't see that big of a problem in changing this for Java -- >> however, >> I would prefer that 'C'/'C++' functions/methods retain this handy >> feature, as >> not every programmer is particularly fond of IDEs, and I would argue that we >> should not require developers to use an IDE such as eclipse. >> >> That being said, I would prefer multiple non-nested public classes to >> reside in their >> own files, leaving only cases where we need/require standalone >> private/protected >> classes to co-exist within the same file? I am uncertain if we even >> have any of these. >> >>> 2. We require that interface names begin with "I". Sun says nothing >>> about this. This is probably a good one to keep. >> I agree that we should keep this 'handy' notation. >>> 3. We specify "no tabs". Sun says tabs are optional. We should keep >>> this. >> My personal preference is to use 'spaces' instead of 'tabs' primarily >> due to the >> variable 'tabstop' settings in files. >>> 4. We say "Static methods should begin with a capital letter with each >>> subsequent new word in uppercase, and subsequent letters in each word in >>> lower case. Sun has no special treatment for static methods - ie. they >>> are treated just like other methods .. ie. beginning with a lower-case >>> letter. >> I have no particular preference one way or another on this. >>> 5. We do have some guidelines for naming functions that go beyond what >>> Sun specifies - and also perhaps, beyond what eclipse can verify. >>> >>> For example: >>> * Get and set methods should begin with "get" / "set" and return the >>> appropriate object type. >>> * Boolean get methods should use "is" or "can" as a prefix, such as >>> "isUndoable()" rather than "getUndoable()". >>> * Factory class names should include the word "Factory". Factory method >>> names should start with the word "Make." >>> * Methods for debug-only implementations should begin with "debug". >>> * Member variables should begin with "m". For example, mMemberVariable. >> These all seem fine to me. >> >> While I understand Adam's doesn't like Hungarian notation, the >> downside of renaming everything will make it far more difficult >> for the people who are the most familiar with this code to >> continue to make changes. >> >>> My take on this is that we should adopt the Sun coding standards and add >>> the additional requirements that make sense - like the ones listed in >>> point 5 above. For the cases where we conflict with the Sun standards, >>> we should go with the Sun standards instead. >>> >>> Comments? >>> Ade >>> >>> On Wed, 2011-11-23 at 12:26 -0500, Adam Young wrote: >>>> MIght I highly encourage that we folow the Sun guides, as it is the Inustry standard in Java, and it is pretty staightforward. >>>> >>>> ----- Original Message ----- >>>> From: "Ade Lee" >>>> To: pki-devel at redhat.com >>>> Sent: Wednesday, November 23, 2011 10:48:42 AM >>>> Subject: [Pki-devel] Automatic reformatting and code style >>>> >>>> Hi all, >>>> >>>> It has been decided that the code should go through an automatic >>>> reformatting on the trunk to ensure that everything matches the >>>> project's coding standards. >>>> >>>> Prior to this, we need to review the coding standards and confirm that >>>> they are what we want to use. >>>> >>>> The current coding standards for the project are referenced here: >>>> http://pki.fedoraproject.org/wiki/PKI_C_Coding_Style >>>> http://pki.fedoraproject.org/wiki/PKI_Java_Coding_Style >>>> >>>> Some alternative styles: >>>> http://freeipa.org/page/Coding_Style (C) >>>> http://www.oracle.com/technetwork/java/codeconvtoc-136057.html (java, >>>> sun conventions) >>>> >>>> We should focus on the java coding style first, followed by C. Most of >>>> the Perl code is mostly going away most likely, so no need to focus on >>>> that. >>>> >>>> IPA has a style guide for python, which, unless we have another >>>> compelling reason, we should probably use that: >>>> >>>> http://freeipa.org/page/Python_Coding_Style >>>> >>>> We'd like to get this resolved soon - so as not to obscure any future >>>> changes as we do new development. So, please devote some attention to >>>> this soon. >>>> >>>> Thanks, >>>> Ade >>>> >>>> _______________________________________________ >>>> Pki-devel mailing list >>>> Pki-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/pki-devel >>> _______________________________________________ >>> Pki-devel mailing list >>> Pki-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-devel > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5130 bytes Desc: S/MIME Cryptographic Signature URL: From nkinder at redhat.com Tue Nov 29 02:27:28 2011 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 28 Nov 2011 18:27:28 -0800 Subject: [Pki-devel] Automatic reformatting and code style In-Reply-To: <4ED4380C.9040901@redhat.com> References: <1322494446.19037.1.camel@aleeredhat.laptop> <4ED4380C.9040901@redhat.com> Message-ID: <4ED44310.4080800@redhat.com> On 11/28/2011 05:40 PM, Christina wrote: > I agree with Ade. > > I have been busy with the actual pki implementation and bug fixes and > I'm not sure if I'm supposed to pay attention to this subject (and I > didn't much), but I think it's worthwhile to chime in. I have worked > on the project for maybe 13 or 15 years since my Netscape days, so I > may be partial, but I think it's a good idea to hear out both sides of > the debate. > > This is not the 1st controversial item that I have observed, and I > have no idea what happened to the other ones in the end. > May I suggest that you guys separate the non-controversial items from > the controversial ones and leave the controversial ones alone until > people debate it out? Perhaps a wiki page to capture all the > controversial issues so for those of us who can't follow the whole > email threads all the time can have a chance to go to the wiki and > find out points from both sides of the debate? > Each side should be able to go to the wiki and put down your points. > Then we vote at some point, hopefully when I'm around? > > Is this acceptable? I believe that some of these decisions need to be made now, as we only want to be making large refactoring changes once. The longer we drag it out, the more painful it is going to be to work on the code as things will constantly be in flux. I can see Ade's point about not having an easy way to clean up all of the "mFoo" type variables automatically, but do we really want to require all new code to use the "m" prefix? That will cause you to have to change the variable name in a potentially large number of places if one decides to change the scope of a variable, which is really just extra work that shouldn't be needed. The other thing I don't like about encoding the scope into the variable name is that it might be incorrect. Just because a variable is named "mFoo" doesn't mean it's really a member variable. This can lead to false assumptions when one should really consult the declaration to see what it truly is. The ability for the naming to be inconsistent with the declaration makes encoding the scope useless (and potentially bad) IMHO. I know I've been very frustrated running into variable names in C that had the type encoded originally, but someone changed the type in the declaration without changing the variable name. > > thanks! > Christina > > On 11/28/2011 07:34 AM, Ade Lee wrote: >> I had no idea that the naming of interfaces and member fields would >> generate such spirited debate. >> >> I'm going to play devil's advocate here, and argue FOR keeping the >> convention of prefixing "m" to object fields. >> >> 1. The arguments against Hungarian notation have mostly been made >> against what is called "systems Hungarian" - that is, things that are >> readily checked by a compiler or an IDE. >> >> When I hover over a variable in eclipse, it will tell me the type - so >> there is no need to prefix the variable with that information. Using >> iFoo for an integer is counterproductive for those reasons. >> >> Attaching "m" to an object tells us about scope - which is not displayed >> when I hover over the variable. Sure, I can look up the declaration - >> but with the prefix, I don't have to. >> >> 2. Does the "m" prefix make the code less readable? I don't think so - >> we're not talking about plzFoo here. What it does do, is allow me when >> looking at segment of code - to instantly determine whether the >> variables in the code are local to the function or member variables. >> >> 3. You may want to change the scope of a variable - and this would >> require you to rename the variable. But I would argue that this is a >> conscious decision - and one that will likely require the >> addition/removal of getters/setters. Having the variable prefixed by >> "m" requires you to think about that. And as has been mentioned, >> renaming is trivial in eclipse. >> >> 4. Renaming a specific variable is trivial in eclipse, but I have not >> found a simple way to do a mass renaming so that all the variables that >> are now in Hungarian notation in eclipse. There is a way to enforce the >> use of a prefix - but not a way to systematically remove the prefixes. >> >> If we can't do that, then we run the risk of having code which conformed >> to old standard - along with code which conformed to a new standard >> which did not require the "m" - which I would argue is much worse. >> >> 5. Even if we could remove all Hungarian notation, this would make >> merges from 8.X to the tip much more labor intensive. Its one thing to >> have to do things manually because of formatting. Its another to have >> to replace variables stuck in the code. >> >> Ade >> >> On Wed, 2011-11-23 at 17:50 -0500, Adam Young wrote: >>> vi long since became capable of handling either format. I'll leave >>> it as ana excersize to you vi guys to figure out how to get it to >>> match. >>> >>> Renaming is trivial in Eclipse, and "Its always been done this >>> way" is not sufficient grounds to keep up a bad practice. >>> >>> >>> The code is going to shrink, get reordred, and things are going to >>> get renamed. THis is acleanup that will have a very large net >>> positive advantage, and we have the flexibility to do it right. >>> Lets not hamstring outselves with decisions bad in the past that no >>> longer apply: keep the good, but don't hoard things, esepcially >>> not in code. >>> >>> INterfaces have their uses, but the PKI code base shows some of the >>> mistakes made by following the "best practices" of the day that >>> have since been discarded. Interfaces in Java should be used for >>> cutting dependncies, information hading and the like, but should >>> be the exception, not the rule. A fundamental guideline is "favor >>> collaboration over inheritance" and that means Interfaces as well >>> as abstract base classes. I'm not saying "Don't use them" but I >>> am saying "Be prepared to justify their use" if you do. >>> >>> >>> For the domain model, using an IRequest to front RequestImpl where >>> there is only one Impl is an anti-pattern. a Date transfer object >>> should have minimal functionality in it, and no external >>> dependencies. Thus, it gains no benefit from the abstraction of >>> the Interface. >>> >>> A much better approach is to make Request a POJO, and, if >>> posssible, immutable. I'll go more into how to code this way as >>> examples pop up. >>> >>> >>> >>> Sorry for top posting, but I'm having mail failure and can only >>> use Zimbra web, which doesn't do the> thing. >>> >>> >>> ----- Original Message ----- >>> From: "Matthew Harmsen" >>> To: alee at redhat.com >>> Cc: "Adam Young", pki-devel at redhat.com >>> Sent: Wednesday, November 23, 2011 5:05:47 PM >>> Subject: Re: [Pki-devel] Automatic reformatting and code style >>> >>> On 11/23/11 11:57, Ade Lee wrote: >>>> I looked at our current guidelines and noticed the following >>>> differences >>>> with the Sun guides: >>>> >>>> 1. Placement of braces >>>> In the current coding guidelines, we say classes and methods should >>>> look >>>> like this: >>>> public class MyClass >>>> { >>>> ... >>>> } >>>> >>>> instead of this (as in the Sun standard): >>>> public class MyClass { >>>> ... >>>> } >>> The history behind this probably comes from a nice handy 'vi' shortcut >>> (pressing ']' twice) that allows for developers to quickly find the >>> beginning of >>> various 'functions' in 'C'/'C++'; note that the opening brace must be a >>> standalone >>> character in the first column for this to work. >>> >>> This was probably applied to the Java code to find the beginning and >>> ending of a >>> 'class' in java files that contained more than one non-nested class >>> in a >>> single '.java' >>> file, so I don't see that big of a problem in changing this for Java -- >>> however, >>> I would prefer that 'C'/'C++' functions/methods retain this handy >>> feature, as >>> not every programmer is particularly fond of IDEs, and I would argue >>> that we >>> should not require developers to use an IDE such as eclipse. >>> >>> That being said, I would prefer multiple non-nested public classes to >>> reside in their >>> own files, leaving only cases where we need/require standalone >>> private/protected >>> classes to co-exist within the same file? I am uncertain if we even >>> have any of these. >>> >>>> 2. We require that interface names begin with "I". Sun says nothing >>>> about this. This is probably a good one to keep. >>> I agree that we should keep this 'handy' notation. >>>> 3. We specify "no tabs". Sun says tabs are optional. We should keep >>>> this. >>> My personal preference is to use 'spaces' instead of 'tabs' primarily >>> due to the >>> variable 'tabstop' settings in files. >>>> 4. We say "Static methods should begin with a capital letter with each >>>> subsequent new word in uppercase, and subsequent letters in each >>>> word in >>>> lower case. Sun has no special treatment for static methods - ie. >>>> they >>>> are treated just like other methods .. ie. beginning with a lower-case >>>> letter. >>> I have no particular preference one way or another on this. >>>> 5. We do have some guidelines for naming functions that go beyond what >>>> Sun specifies - and also perhaps, beyond what eclipse can verify. >>>> >>>> For example: >>>> * Get and set methods should begin with "get" / "set" and return the >>>> appropriate object type. >>>> * Boolean get methods should use "is" or "can" as a prefix, such as >>>> "isUndoable()" rather than "getUndoable()". >>>> * Factory class names should include the word "Factory". Factory >>>> method >>>> names should start with the word "Make." >>>> * Methods for debug-only implementations should begin with "debug". >>>> * Member variables should begin with "m". For example, >>>> mMemberVariable. >>> These all seem fine to me. >>> >>> While I understand Adam's doesn't like Hungarian notation, the >>> downside of renaming everything will make it far more difficult >>> for the people who are the most familiar with this code to >>> continue to make changes. >>> >>>> My take on this is that we should adopt the Sun coding standards >>>> and add >>>> the additional requirements that make sense - like the ones listed in >>>> point 5 above. For the cases where we conflict with the Sun >>>> standards, >>>> we should go with the Sun standards instead. >>>> >>>> Comments? >>>> Ade >>>> >>>> On Wed, 2011-11-23 at 12:26 -0500, Adam Young wrote: >>>>> MIght I highly encourage that we folow the Sun guides, as it is >>>>> the Inustry standard in Java, and it is pretty staightforward. >>>>> >>>>> ----- Original Message ----- >>>>> From: "Ade Lee" >>>>> To: pki-devel at redhat.com >>>>> Sent: Wednesday, November 23, 2011 10:48:42 AM >>>>> Subject: [Pki-devel] Automatic reformatting and code style >>>>> >>>>> Hi all, >>>>> >>>>> It has been decided that the code should go through an automatic >>>>> reformatting on the trunk to ensure that everything matches the >>>>> project's coding standards. >>>>> >>>>> Prior to this, we need to review the coding standards and confirm >>>>> that >>>>> they are what we want to use. >>>>> >>>>> The current coding standards for the project are referenced here: >>>>> http://pki.fedoraproject.org/wiki/PKI_C_Coding_Style >>>>> http://pki.fedoraproject.org/wiki/PKI_Java_Coding_Style >>>>> >>>>> Some alternative styles: >>>>> http://freeipa.org/page/Coding_Style (C) >>>>> http://www.oracle.com/technetwork/java/codeconvtoc-136057.html (java, >>>>> sun conventions) >>>>> >>>>> We should focus on the java coding style first, followed by C. >>>>> Most of >>>>> the Perl code is mostly going away most likely, so no need to >>>>> focus on >>>>> that. >>>>> >>>>> IPA has a style guide for python, which, unless we have another >>>>> compelling reason, we should probably use that: >>>>> >>>>> http://freeipa.org/page/Python_Coding_Style >>>>> >>>>> We'd like to get this resolved soon - so as not to obscure any future >>>>> changes as we do new development. So, please devote some >>>>> attention to >>>>> this soon. >>>>> >>>>> Thanks, >>>>> Ade >>>>> >>>>> _______________________________________________ >>>>> Pki-devel mailing list >>>>> Pki-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/pki-devel >>>> _______________________________________________ >>>> Pki-devel mailing list >>>> Pki-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/pki-devel >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdennis at redhat.com Tue Nov 29 13:36:39 2011 From: jdennis at redhat.com (John Dennis) Date: Tue, 29 Nov 2011 08:36:39 -0500 Subject: [Pki-devel] Automatic reformatting and code style In-Reply-To: <4ED44310.4080800@redhat.com> References: <1322494446.19037.1.camel@aleeredhat.laptop> <4ED4380C.9040901@redhat.com> <4ED44310.4080800@redhat.com> Message-ID: <4ED4DFE7.7000007@redhat.com> On 11/28/2011 09:27 PM, Nathan Kinder wrote: >This can lead to false assumptions when one should > really consult the declaration to see what it truly is. The ability for > the naming to be inconsistent with the declaration makes encoding the > scope useless (and potentially bad) IMHO. I know I've been very > frustrated running into variable names in C that had the type encoded > originally, but someone changed the type in the declaration without > changing the variable name. Which is precisely why encoding type information into a symbol name is a bad idea. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ayoung at redhat.com Tue Nov 29 14:22:27 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 29 Nov 2011 09:22:27 -0500 Subject: [Pki-devel] Automatic reformatting and code style In-Reply-To: <4ED4380C.9040901@redhat.com> References: <1322494446.19037.1.camel@aleeredhat.laptop> <4ED4380C.9040901@redhat.com> Message-ID: <4ED4EAA3.40402@redhat.com> On 11/28/2011 08:40 PM, Christina wrote: > I agree with Ade. > > I have been busy with the actual pki implementation and bug fixes and > I'm not sure if I'm supposed to pay attention to this subject (and I > didn't much), but I think it's worthwhile to chime in. I have worked > on the project for maybe 13 or 15 years since my Netscape days, so I > may be partial, but I think it's a good idea to hear out both sides of > the debate. > > This is not the 1st controversial item that I have observed, and I > have no idea what happened to the other ones in the end. > May I suggest that you guys separate the non-controversial items from > the controversial ones and leave the controversial ones alone until > people debate it out? Perhaps a wiki page to capture all the > controversial issues so for those of us who can't follow the whole > email threads all the time can have a chance to go to the wiki and > find out points from both sides of the debate? > Each side should be able to go to the wiki and put down your points. > Then we vote at some point, hopefully when I'm around? > > Is this acceptable? Makes sense, although I think we can talk it out in this forum. Email, especially a publicly archived list like this, is actually a good way to drive he discussion, better, I've found, than a wiki. There are two issues here, though, as Christina points out: the automatable changes, which should be fairly non-contraversial, and the ones that will require manual changes. We are not going to automate the removal of the 'm' friom member variables and the like, so we can defer making a decision on those. > > thanks! > Christina > > On 11/28/2011 07:34 AM, Ade Lee wrote: >> I had no idea that the naming of interfaces and member fields would >> generate such spirited debate. >> >> I'm going to play devil's advocate here, and argue FOR keeping the >> convention of prefixing "m" to object fields. >> >> 1. The arguments against Hungarian notation have mostly been made >> against what is called "systems Hungarian" - that is, things that are >> readily checked by a compiler or an IDE. >> >> When I hover over a variable in eclipse, it will tell me the type - so >> there is no need to prefix the variable with that information. Using >> iFoo for an integer is counterproductive for those reasons. >> >> Attaching "m" to an object tells us about scope - which is not displayed >> when I hover over the variable. Sure, I can look up the declaration - >> but with the prefix, I don't have to. >> >> 2. Does the "m" prefix make the code less readable? I don't think so - >> we're not talking about plzFoo here. What it does do, is allow me when >> looking at segment of code - to instantly determine whether the >> variables in the code are local to the function or member variables. >> >> 3. You may want to change the scope of a variable - and this would >> require you to rename the variable. But I would argue that this is a >> conscious decision - and one that will likely require the >> addition/removal of getters/setters. Having the variable prefixed by >> "m" requires you to think about that. And as has been mentioned, >> renaming is trivial in eclipse. >> >> 4. Renaming a specific variable is trivial in eclipse, but I have not >> found a simple way to do a mass renaming so that all the variables that >> are now in Hungarian notation in eclipse. There is a way to enforce the >> use of a prefix - but not a way to systematically remove the prefixes. >> >> If we can't do that, then we run the risk of having code which conformed >> to old standard - along with code which conformed to a new standard >> which did not require the "m" - which I would argue is much worse. >> >> 5. Even if we could remove all Hungarian notation, this would make >> merges from 8.X to the tip much more labor intensive. Its one thing to >> have to do things manually because of formatting. Its another to have >> to replace variables stuck in the code. >> >> Ade >> >> On Wed, 2011-11-23 at 17:50 -0500, Adam Young wrote: >>> vi long since became capable of handling either format. I'll leave >>> it as ana excersize to you vi guys to figure out how to get it to >>> match. >>> >>> Renaming is trivial in Eclipse, and "Its always been done this >>> way" is not sufficient grounds to keep up a bad practice. >>> >>> >>> The code is going to shrink, get reordred, and things are going to >>> get renamed. THis is acleanup that will have a very large net >>> positive advantage, and we have the flexibility to do it right. >>> Lets not hamstring outselves with decisions bad in the past that no >>> longer apply: keep the good, but don't hoard things, esepcially >>> not in code. >>> >>> INterfaces have their uses, but the PKI code base shows some of the >>> mistakes made by following the "best practices" of the day that >>> have since been discarded. Interfaces in Java should be used for >>> cutting dependncies, information hading and the like, but should >>> be the exception, not the rule. A fundamental guideline is "favor >>> collaboration over inheritance" and that means Interfaces as well >>> as abstract base classes. I'm not saying "Don't use them" but I >>> am saying "Be prepared to justify their use" if you do. >>> >>> >>> For the domain model, using an IRequest to front RequestImpl where >>> there is only one Impl is an anti-pattern. a Date transfer object >>> should have minimal functionality in it, and no external >>> dependencies. Thus, it gains no benefit from the abstraction of >>> the Interface. >>> >>> A much better approach is to make Request a POJO, and, if >>> posssible, immutable. I'll go more into how to code this way as >>> examples pop up. >>> >>> >>> >>> Sorry for top posting, but I'm having mail failure and can only >>> use Zimbra web, which doesn't do the> thing. >>> >>> >>> ----- Original Message ----- >>> From: "Matthew Harmsen" >>> To: alee at redhat.com >>> Cc: "Adam Young", pki-devel at redhat.com >>> Sent: Wednesday, November 23, 2011 5:05:47 PM >>> Subject: Re: [Pki-devel] Automatic reformatting and code style >>> >>> On 11/23/11 11:57, Ade Lee wrote: >>>> I looked at our current guidelines and noticed the following >>>> differences >>>> with the Sun guides: >>>> >>>> 1. Placement of braces >>>> In the current coding guidelines, we say classes and methods should >>>> look >>>> like this: >>>> public class MyClass >>>> { >>>> ... >>>> } >>>> >>>> instead of this (as in the Sun standard): >>>> public class MyClass { >>>> ... >>>> } >>> The history behind this probably comes from a nice handy 'vi' shortcut >>> (pressing ']' twice) that allows for developers to quickly find the >>> beginning of >>> various 'functions' in 'C'/'C++'; note that the opening brace must be a >>> standalone >>> character in the first column for this to work. >>> >>> This was probably applied to the Java code to find the beginning and >>> ending of a >>> 'class' in java files that contained more than one non-nested class >>> in a >>> single '.java' >>> file, so I don't see that big of a problem in changing this for Java -- >>> however, >>> I would prefer that 'C'/'C++' functions/methods retain this handy >>> feature, as >>> not every programmer is particularly fond of IDEs, and I would argue >>> that we >>> should not require developers to use an IDE such as eclipse. >>> >>> That being said, I would prefer multiple non-nested public classes to >>> reside in their >>> own files, leaving only cases where we need/require standalone >>> private/protected >>> classes to co-exist within the same file? I am uncertain if we even >>> have any of these. >>> >>>> 2. We require that interface names begin with "I". Sun says nothing >>>> about this. This is probably a good one to keep. >>> I agree that we should keep this 'handy' notation. >>>> 3. We specify "no tabs". Sun says tabs are optional. We should keep >>>> this. >>> My personal preference is to use 'spaces' instead of 'tabs' primarily >>> due to the >>> variable 'tabstop' settings in files. >>>> 4. We say "Static methods should begin with a capital letter with each >>>> subsequent new word in uppercase, and subsequent letters in each >>>> word in >>>> lower case. Sun has no special treatment for static methods - ie. >>>> they >>>> are treated just like other methods .. ie. beginning with a lower-case >>>> letter. >>> I have no particular preference one way or another on this. >>>> 5. We do have some guidelines for naming functions that go beyond what >>>> Sun specifies - and also perhaps, beyond what eclipse can verify. >>>> >>>> For example: >>>> * Get and set methods should begin with "get" / "set" and return the >>>> appropriate object type. >>>> * Boolean get methods should use "is" or "can" as a prefix, such as >>>> "isUndoable()" rather than "getUndoable()". >>>> * Factory class names should include the word "Factory". Factory >>>> method >>>> names should start with the word "Make." >>>> * Methods for debug-only implementations should begin with "debug". >>>> * Member variables should begin with "m". For example, >>>> mMemberVariable. >>> These all seem fine to me. >>> >>> While I understand Adam's doesn't like Hungarian notation, the >>> downside of renaming everything will make it far more difficult >>> for the people who are the most familiar with this code to >>> continue to make changes. >>> >>>> My take on this is that we should adopt the Sun coding standards >>>> and add >>>> the additional requirements that make sense - like the ones listed in >>>> point 5 above. For the cases where we conflict with the Sun >>>> standards, >>>> we should go with the Sun standards instead. >>>> >>>> Comments? >>>> Ade >>>> >>>> On Wed, 2011-11-23 at 12:26 -0500, Adam Young wrote: >>>>> MIght I highly encourage that we folow the Sun guides, as it is >>>>> the Inustry standard in Java, and it is pretty staightforward. >>>>> >>>>> ----- Original Message ----- >>>>> From: "Ade Lee" >>>>> To: pki-devel at redhat.com >>>>> Sent: Wednesday, November 23, 2011 10:48:42 AM >>>>> Subject: [Pki-devel] Automatic reformatting and code style >>>>> >>>>> Hi all, >>>>> >>>>> It has been decided that the code should go through an automatic >>>>> reformatting on the trunk to ensure that everything matches the >>>>> project's coding standards. >>>>> >>>>> Prior to this, we need to review the coding standards and confirm >>>>> that >>>>> they are what we want to use. >>>>> >>>>> The current coding standards for the project are referenced here: >>>>> http://pki.fedoraproject.org/wiki/PKI_C_Coding_Style >>>>> http://pki.fedoraproject.org/wiki/PKI_Java_Coding_Style >>>>> >>>>> Some alternative styles: >>>>> http://freeipa.org/page/Coding_Style (C) >>>>> http://www.oracle.com/technetwork/java/codeconvtoc-136057.html (java, >>>>> sun conventions) >>>>> >>>>> We should focus on the java coding style first, followed by C. >>>>> Most of >>>>> the Perl code is mostly going away most likely, so no need to >>>>> focus on >>>>> that. >>>>> >>>>> IPA has a style guide for python, which, unless we have another >>>>> compelling reason, we should probably use that: >>>>> >>>>> http://freeipa.org/page/Python_Coding_Style >>>>> >>>>> We'd like to get this resolved soon - so as not to obscure any future >>>>> changes as we do new development. So, please devote some >>>>> attention to >>>>> this soon. >>>>> >>>>> Thanks, >>>>> Ade >>>>> >>>>> _______________________________________________ >>>>> Pki-devel mailing list >>>>> Pki-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/pki-devel >>>> _______________________________________________ >>>> Pki-devel mailing list >>>> Pki-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/pki-devel >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Tue Nov 29 15:06:52 2011 From: alee at redhat.com (Ade Lee) Date: Tue, 29 Nov 2011 10:06:52 -0500 Subject: [Pki-devel] Automatic reformatting and code style In-Reply-To: <4ED4DFE7.7000007@redhat.com> References: <1322494446.19037.1.camel@aleeredhat.laptop> <4ED4380C.9040901@redhat.com> <4ED44310.4080800@redhat.com> <4ED4DFE7.7000007@redhat.com> Message-ID: <1322579213.19378.15.camel@aleeredhat.laptop> On Tue, 2011-11-29 at 08:36 -0500, John Dennis wrote: > On 11/28/2011 09:27 PM, Nathan Kinder wrote: > >This can lead to false assumptions when one should > > really consult the declaration to see what it truly is. The ability for > > the naming to be inconsistent with the declaration makes encoding the > > scope useless (and potentially bad) IMHO. I know I've been very > > frustrated running into variable names in C that had the type encoded > > originally, but someone changed the type in the declaration without > > changing the variable name. > > Which is precisely why encoding type information into a symbol name is a > bad idea. > FWIW, it is possible to set the project formatting rules in eclipse to require member fields to be prefixed with "m" - and to replace all non-confirming instances automatically, as well as to flag inconsistencies going forward. So if we choose to continue to maintain this convention, we can be consistent. And renaming any particular variable is trivial in eclipse. I'm not arguing that this type of thing is a good idea in itself. But I also think that having code that contains member variables that have been prefixed as well as member variables that haven't been - is worse off - because it is inconsistent and no one will know whether to trust the "m" notation or not. We have a very large code base that by and large follows this convention. We can make it absolutely consistent by setting the eclipse formatting rules if we choose to continue to follow this convention. If we abandon the convention, we can do a few things: 1. We could try to replace all old instances all at once - which is a monumental and error-prone process. And one which quite frankly, we do not have the time to do. 2. We could replace variables in files as we work on them. 3. We could just leave the old variables and not use the convention in new code. Both 2 and 3 leave the code in an inconsistent and therefore, I would argue, less readable state. Ade From ayoung at redhat.com Tue Nov 29 15:54:46 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 29 Nov 2011 10:54:46 -0500 Subject: [Pki-devel] Automatic reformatting and code style In-Reply-To: <1322579213.19378.15.camel@aleeredhat.laptop> References: <1322494446.19037.1.camel@aleeredhat.laptop> <4ED4380C.9040901@redhat.com> <4ED44310.4080800@redhat.com> <4ED4DFE7.7000007@redhat.com> <1322579213.19378.15.camel@aleeredhat.laptop> Message-ID: <4ED50046.5080300@redhat.com> OK, here's why I think we should drop the 'm'. Hmmmm ....OK...let me back up.... An object should conform to a contract. Once the object is created, that contract has been signed, sealed and delivered. At least, that is the intention. However, Java often falls down on this. We have "Init" methods. We have Property setters that must be called before we have a "valid" object. Why? Java is a pretty strongly typed language. But, it needs to be able to interface with scripting languages, and thus it has, among other things, the reflection API. Reflection has the ability to enumerate the properties (member variables) of the object, and to fetch values from the object without having to have a compile time dependency. We can even make variables that are Read Only by tagging them as 'final'. A final field must be defined by the time the constructor has returned. The dependencies to decide the value for the final field must be passed in to the constructror. The constructor is available via reflection. the Parameters are avialable via reflection...but.... Not the names of the parameters. This is possibly the largest oversight in the Java language. Without named parameters, a scripting language cannot do anything to determine which of the values it has maps to which of the dependencies of the constructor. All it can do is try to pass them in the right order. So what happened? Java has a nasty covention called the bean API. A naming convention get and set. Want to make somethig read only, drop the set. Joshua Blcok sets out an important rule of thumb in Effective Java: Favor Immutable Objects. An immutable object is implicitly thread safe. The Bean API with its late initialzation of properties makes this impossible. However, we have hope. In recent versions of Java, the Attribute API makes it possible to automatically build classes that let us create a Dictionary to pass to the constructor based on the names of the parameters. There is also the possibility of getting named parameters into the Java standard in the future. Regardless, this is only really an issue for scripting languages. Our application is all Java. This means that we can use classes and type safety to strongly associate the dependecies of a constructor with the objects that can fulfil those dependencies. We don't need to play "Everything is a string" like Javascript does. We can have immutable objects, without the bean API. And we can expose the properties of those objects as final properties instead of get. But this only makes sense if the names of the properties are the "good name". This has the potential to make code that is much more readable and concise, while increasing type safety. Yes, increasing type safety. If a string field is immutable, but it needs some business logic, say to confirm that it complies with a pattern, we create a class that encapsulated that format, and make an immutable instance of that class. The pattern is confirmed in the constructor. If we try to make an instance that does not conform, throw an exception. Here is how it is done in a beanAPI way: public class Certificate{ String fingerprint; String getFingerprint(){ return fingerprint; } String setFingerprint(String fingerprint) throws IllegalArgumentException { validateFingerprint(fingerprint); this.fingerprint = fingerprint; } } Note that the logic for fingerprint is encapsulated in the Certificate object, and cannot be cleanly separated out. Here's the refactored solution. public class Fingerprint{ private String internal; public Fingerprint(String) throws InvalidArgumentException{ ... } String toString(){ ... } } public class Certificate{ public final Fingerprint fingerprint; puiblic Certificate (Fingerprint fingerprint) { this.fingerprint = fingerprint; } } From mharmsen at redhat.com Wed Nov 30 01:09:45 2011 From: mharmsen at redhat.com (Matthew Harmsen) Date: Tue, 29 Nov 2011 17:09:45 -0800 Subject: [Pki-devel] PKI 'svn' tags and branches to be exposed in 'git' . . . Message-ID: <4ED58259.4040104@redhat.com> Please expose the following 'svn' branches in the 'git' repository: remotes/svn/trunk remotes/svn/DOGTAG_9_BRANCH remotes/svn/IPA_v2_RHEL_6_ERRATA_BRANCH Due to a concern that the RHCS 8.x 'svn' repositories use an *ant/autoconf* build system that relies on the 'overlay' of a separate 'svn' repository as well as making heavy use of the 'svn' externals properties, it may be best if the RHCS 8.x series of branches remain primarily located in their 'svn' repositories. However, for experimental purposes, please also currently expose the following 'svn' branches in the 'git' repository as discussed: remotes/svn/PKI_8_0_ERRATA_BRANCH remotes/svn/PKI_8_1_ERRATA_BRANCH remotes/svn/PKI_8_BRANCH Finally, when the final 'git' repository is created, please also expose the following 'svn' tags: remotes/svn/tags/DOGTAG_9_0_FEDORA_15_16_17_20111028 remotes/svn/tags/IPA_v2_RHEL_6_2_20111003 and, depending upon the success of the experiment alluded to above, the following 'svn' tags: remotes/svn/tags/PKI_8_0_RTM_20090720 remotes/svn/tags/PKI_8_1_RC_1_20111103 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mharmsen at redhat.com Wed Nov 30 01:37:12 2011 From: mharmsen at redhat.com (Matthew Harmsen) Date: Tue, 29 Nov 2011 17:37:12 -0800 Subject: [Pki-devel] Question about nightly builds of 'pki-ca' for 'ipa-devel' in Fedora 16 and Rawhide . . . Message-ID: <4ED588C8.9030101@redhat.com> Before I file two release engineering tickets (one for F16 and one for F17 (rawhide)), I have a couple of questions regarding the following ticket: * https://fedorahosted.org/pki/ticket/61 As we are in the midst of moving source code from an 'svn' repo to a 'git' repo, and making potentially radical changes to the tip, should I: 1. Specify using an 'svn' repo or a 'git' repo for generating these nightly builds? 2. Specify the 'trunk', or 'DOGTAG_9_BRANCH' (the last 'stable' Dogtag source code that was released on Fedora 15, 16, and 17)? -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Wed Nov 30 02:21:45 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 29 Nov 2011 21:21:45 -0500 Subject: [Pki-devel] PKI 'svn' tags and branches to be exposed in 'git' . . . In-Reply-To: <4ED58259.4040104@redhat.com> References: <4ED58259.4040104@redhat.com> Message-ID: <4ED59339.3090104@redhat.com> On 11/29/2011 08:09 PM, Matthew Harmsen wrote: > Please expose the following 'svn' branches in the 'git' repository: > > remotes/svn/trunk > In git the convention is "master" whereas trunk is Subversion. The Master branch now reflects what is on trunk, plus one commit. > remotes/svn/DOGTAG_9_BRANCH > remotes/svn/IPA_v2_RHEL_6_ERRATA_BRANCH > > Due to a concern that the RHCS 8.x 'svn' repositories use an > *ant/autoconf* build system that relies > on the 'overlay' of a separate 'svn' repository as well as making > heavy use of the 'svn' externals properties, > it may be best if the RHCS 8.x series of branches remain primarily > located in their 'svn' repositories. > > However, for experimental purposes, please also currently expose the > following 'svn' branches in the 'git' repository as discussed: > > remotes/svn/PKI_8_0_ERRATA_BRANCH > remotes/svn/PKI_8_1_ERRATA_BRANCH > remotes/svn/PKI_8_BRANCH > > Finally, when the final 'git' repository is created, please also > expose the following 'svn' tags: > > remotes/svn/tags/DOGTAG_9_0_FEDORA_15_16_17_20111028 > remotes/svn/tags/IPA_v2_RHEL_6_2_20111003 > > and, depending upon the success of the experiment alluded to above, > the following 'svn' tags: > > remotes/svn/tags/PKI_8_0_RTM_20090720 > remotes/svn/tags/PKI_8_1_RC_1_20111103 > All these have been made. > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From emaldona at redhat.com Wed Nov 30 02:46:33 2011 From: emaldona at redhat.com (Elio Maldonado) Date: Tue, 29 Nov 2011 21:46:33 -0500 (EST) Subject: [Pki-devel] Question about nightly builds of 'pki-ca' for 'ipa-devel' in Fedora 16 and Rawhide . . . In-Reply-To: <4ED588C8.9030101@redhat.com> Message-ID: On 11/29/2011 05:37 PM, Matthew Harmsen wrote: Before I file two release engineering tickets (one for F16 and one for F17 (rawhide)), I have a couple of questions regarding the following ticket: ? https://fedorahosted.org/pki/ticket/61 As we are in the midst of moving source code from an 'svn' repo to a 'git' repo, and making potentially radical changes to the tip, should I: 1. Specify using an 'svn' repo or a 'git' repo for generating these nightly builds? 2. Specify the 'trunk', or 'DOGTAG_9_BRANCH' (the last 'stable' Dogtag source code that was released on Fedora 15, 16, and 17)? -- Matt _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel On Rawhide we are on pre-alpha and they are merging the code into the rhel-7 git repos. Deadline is Dec 13. Given that my best guess would be git. For what is worth, I also saw this in the RHEL-7-Planning list On Tue, Oct 04, 2011 at 02:50:06PM -0400, Paul W. Frields wrote: > I want to make it easy for developers to find answers to burning > questions about RHEL 7 development phase. For instance, there may be > questions about using the forthcoming git repositories; using the new > 'rhpkg' tool; RHEL Rawhide and any expectations for developers; how > content imports will be done; and others. > > I've started a wiki page to capture these questions here: > https://home.corp.redhat.com/wiki/rhel-7-developer-information > > The page will be linked prominently in the main planning page and > elsewhere. Rather than making it a huge page full of information I'd > like to structure it as a FAQ, with links to specific Q&A to make it > easy to direct people to specific topics. I'm thinking primarily > about technical process questions, but that's open to discussion. The page above has been updated to provide additional information on dist-git and fixing builds. The page is a work in progress, so feel free to suggest other questions to be answered here. Elio -------------- next part -------------- An HTML attachment was scrubbed... URL: From mharmsen at redhat.com Wed Nov 30 02:53:29 2011 From: mharmsen at redhat.com (Matthew Harmsen) Date: Tue, 29 Nov 2011 18:53:29 -0800 Subject: [Pki-devel] CMake 'JNI' macro question . . . Message-ID: <4ED59AA9.1000805@redhat.com> Andreas, I would like to request your assistance on the following 'CMake' issue requested by Adam: * https://fedorahosted.org/pki/ticket/9 Basically, on Fedora 16 and later, the default location of Java Native Interface (JNI) jar files was changed to reside under '/usr/lib/java' for 32-bit platforms, and '/usr/lib64/java' for 64-bit platforms. Per the TRAC ticket, I made a change in the spec files to handle this via the 'jpackage-utils' RPM. However, I do not know if 'CMake' can change the 'JAVA_LIB_INSTALL_DIR' macro located in the 'pki/cmake/Modules/DefineInstallationPaths.cmake' file to rely on the '%{_jnidir}' macro of 'jpackage-utils' stored in the '/etc/rpm/macros.jpackage', or if there is a different way of handling this where the following logic comes into play: * '/usr/lib/java' on RHEL 6 and earlier (32-bit AND 64-bit platforms) * '/usr/lib/java' on Fedora 15 and earlier (32-bit AND 64-bit platforms) * '/usr/lib/java' on Fedora 16 and later (32-bit platforms) * '/usr/lib/java' on Fedora 16 and later (using a 32-bit JVM on 64-bit platforms) o I am fairly confident that this case may actually REQUIRE a compiler override, as it does not look as if 'jpackage-utils' computes its '%{_jnidir}' macro based upon the 'JVM' architecture being utilized, but rather the '%{_libdir}' macro based upon the operating system architecture located in the appropriate '/usr/lib/rpm/platform//macros' file * '/usr/lib64/java' on Fedora 16 and later (64-bit platforms) Your assistance on this matter is greatly appreciated. Eventually, do you think that we may want the appropriate logic added to the '/etc/rpm/macros.cmake' file? Thanks, -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Wed Nov 30 03:43:28 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 29 Nov 2011 22:43:28 -0500 Subject: [Pki-devel] PKI-Silent can't tell if this is success or failure Message-ID: <4ED5A660.2040207@redhat.com> I've been crafting a PKI Silent call from the command line, and reading the various responses to see what I got wrong. Below is the end of the output from my last call. Is this "Success"? ############################################# Attempting to connect to: ayoung.boston.devel.redhat.com:8443 Connected. Posting Query = https://ayoung.boston.devel.redhat.com:8443//ca/admin/console/config/wizard?p=13&op=next&xml=true&choice=backupkey&__pwd=freeipa4all&__pwdagain=freeipa4all RESPONSE STATUS: HTTP/1.1 200 OK RESPONSE HEADER: Server: Apache-Coyote/1.1 RESPONSE HEADER: Content-Type: application/xml;charset=UTF-8 RESPONSE HEADER: Date: Wed, 30 Nov 2011 03:41:18 GMT RESPONSE HEADER: Connection: close admin/console/config/savepkcs12panel.vm ca success 19 Save Keys and Certificates welcome Welcome module Key Store confighsmlogin ConfigHSMLogin securitydomain Security Domain securitydomain Display Certificate Chain subsystem Subsystem Type clone Display Certificate Chain restorekeys Import Keys and Certificates cahierarchy PKI Hierarchy database Internal Database size Key Pairs subjectname Subject Names certrequest Requests and Certificates backupkeys Export Keys and Certificates savepk12 Save Keys and Certificates importcachain Import CA's Certificate Chain admin Administrator importadmincert Import Administrator's Certificate done Done CA Setup Wizard

14

savepk12 ############################################# Attempting to connect to: ayoung.boston.devel.redhat.com:8443 Connected. Posting Query = https://ayoung.boston.devel.redhat.com:8443//ca/admin/console/config/savepkcs12? RESPONSE STATUS: HTTP/1.1 200 OK RESPONSE HEADER: Server: Apache-Coyote/1.1 RESPONSE HEADER: Content-Type: application/x-pkcs12 RESPONSE HEADER: Date: Wed, 30 Nov 2011 03:41:19 GMT RESPONSE HEADER: Connection: close ERROR: ConfigureCA: BackupPanel() failure ERROR: unable to create CA ####################################################################### From dpal at redhat.com Wed Nov 30 13:55:30 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 30 Nov 2011 08:55:30 -0500 Subject: [Pki-devel] Question about nightly builds of 'pki-ca' for 'ipa-devel' in Fedora 16 and Rawhide . . . In-Reply-To: <4ED588C8.9030101@redhat.com> References: <4ED588C8.9030101@redhat.com> Message-ID: <4ED635D2.7090503@redhat.com> On 11/29/2011 08:37 PM, Matthew Harmsen wrote: > Before I file two release engineering tickets (one for F16 and one for > F17 (rawhide)), I have a couple of questions regarding the following > ticket: > > * https://fedorahosted.org/pki/ticket/61 > > As we are in the midst of moving source code from an 'svn' repo to a > 'git' repo, and making potentially radical changes to the tip, should I: > > 1. Specify using an 'svn' repo or a 'git' repo for generating these > nightly builds? > 2. Specify the 'trunk', or 'DOGTAG_9_BRANCH' (the last 'stable' > Dogtag source code that was released on Fedora 15, 16, and 17)? > What is the difference between trunk and 9 brunch? > -- Matt > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Wed Nov 30 14:29:53 2011 From: alee at redhat.com (Ade Lee) Date: Wed, 30 Nov 2011 09:29:53 -0500 Subject: [Pki-devel] PKI-Silent can't tell if this is success or failure In-Reply-To: <4ED5A660.2040207@redhat.com> References: <4ED5A660.2040207@redhat.com> Message-ID: <1322663394.19378.30.camel@aleeredhat.laptop> This is failure. Looks like you got a success response from the backup panel, but then failed some processing of the response. Maybe you do not have the required directory in which to backup the keys? Ade On Tue, 2011-11-29 at 22:43 -0500, Adam Young wrote: > I've been crafting a PKI Silent call from the command line, and reading > the various responses to see what I got wrong. Below is the end of the > output from my last call. Is this "Success"? > > > ############################################# > Attempting to connect to: ayoung.boston.devel.redhat.com:8443 > Connected. > Posting Query = > https://ayoung.boston.devel.redhat.com:8443//ca/admin/console/config/wizard?p=13&op=next&xml=true&choice=backupkey&__pwd=freeipa4all&__pwdagain=freeipa4all > RESPONSE STATUS: HTTP/1.1 200 OK > RESPONSE HEADER: Server: Apache-Coyote/1.1 > RESPONSE HEADER: Content-Type: application/xml;charset=UTF-8 > RESPONSE HEADER: Date: Wed, 30 Nov 2011 03:41:18 GMT > RESPONSE HEADER: Connection: close > > > > admin/console/config/savepkcs12panel.vm > > ca > > success > > 19 > Save Keys and Certificates > > > > welcome > Welcome > > > module > Key Store > > > confighsmlogin > ConfigHSMLogin > > > securitydomain > Security Domain > > > securitydomain > Display Certificate Chain > > > subsystem > Subsystem Type > > > clone > Display Certificate Chain > > > restorekeys > Import Keys and Certificates > > > cahierarchy > PKI Hierarchy > > > database > Internal Database > > > size > Key Pairs > > > subjectname > Subject Names > > > certrequest > Requests and Certificates > > > backupkeys > Export Keys and Certificates > > > savepk12 > Save Keys and Certificates > > > importcachain > Import CA's Certificate Chain > > > admin > Administrator > > > importadmincert > Import Administrator's Certificate > > > done > Done > > > > CA Setup Wizard >

14

> > savepk12 > > ############################################# > Attempting to connect to: ayoung.boston.devel.redhat.com:8443 > Connected. > Posting Query = > https://ayoung.boston.devel.redhat.com:8443//ca/admin/console/config/savepkcs12? > RESPONSE STATUS: HTTP/1.1 200 OK > RESPONSE HEADER: Server: Apache-Coyote/1.1 > RESPONSE HEADER: Content-Type: application/x-pkcs12 > RESPONSE HEADER: Date: Wed, 30 Nov 2011 03:41:19 GMT > RESPONSE HEADER: Connection: close > ERROR: ConfigureCA: BackupPanel() failure > ERROR: unable to create CA > > ####################################################################### > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From kchamart at redhat.com Wed Nov 30 14:47:08 2011 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Wed, 30 Nov 2011 20:17:08 +0530 Subject: [Pki-devel] PKI-Silent can't tell if this is success or failure In-Reply-To: <4ED5A660.2040207@redhat.com> References: <4ED5A660.2040207@redhat.com> Message-ID: <4ED641EC.6060305@redhat.com> On 11/30/2011 09:13 AM, Adam Young wrote: > I've been crafting a PKI Silent call from the command line, and reading the various > responses to see what I got wrong. Below is the end of the output from my last call. Is > this "Success"? Adam, here is a successful invocation of pkisilent on Fedora-16 and it's stdout -- http://kashyapc.fedorapeople.org/dogtag-pki/pki-silent-succesful-stdout.txt > > > ############################################# > Attempting to connect to: ayoung.boston.devel.redhat.com:8443 > Connected. > Posting Query = > https://ayoung.boston.devel.redhat.com:8443//ca/admin/console/config/wizard?p=13&op=next&xml=true&choice=backupkey&__pwd=freeipa4all&__pwdagain=freeipa4all > > RESPONSE STATUS: HTTP/1.1 200 OK > RESPONSE HEADER: Server: Apache-Coyote/1.1 > RESPONSE HEADER: Content-Type: application/xml;charset=UTF-8 > RESPONSE HEADER: Date: Wed, 30 Nov 2011 03:41:18 GMT > RESPONSE HEADER: Connection: close > > > > admin/console/config/savepkcs12panel.vm > > ca > > success > > 19 > Save Keys and Certificates > > > > welcome > Welcome > > > module > Key Store > > > confighsmlogin > ConfigHSMLogin > > > securitydomain > Security Domain > > > securitydomain > Display Certificate Chain > > > subsystem > Subsystem Type > > > clone > Display Certificate Chain > > > restorekeys > Import Keys and Certificates > > > cahierarchy > PKI Hierarchy > > > database > Internal Database > > > size > Key Pairs > > > subjectname > Subject Names > > > certrequest > Requests and Certificates > > > backupkeys > Export Keys and Certificates > > > savepk12 > Save Keys and Certificates > > > importcachain > Import CA's Certificate Chain > > > admin > Administrator > > > importadmincert > Import Administrator's Certificate > > > done > Done > > > > CA Setup Wizard >

14

> > savepk12 > > ############################################# > Attempting to connect to: ayoung.boston.devel.redhat.com:8443 > Connected. > Posting Query = > https://ayoung.boston.devel.redhat.com:8443//ca/admin/console/config/savepkcs12? > RESPONSE STATUS: HTTP/1.1 200 OK > RESPONSE HEADER: Server: Apache-Coyote/1.1 > RESPONSE HEADER: Content-Type: application/x-pkcs12 > RESPONSE HEADER: Date: Wed, 30 Nov 2011 03:41:19 GMT > RESPONSE HEADER: Connection: close > ERROR: ConfigureCA: BackupPanel() failure > ERROR: unable to create CA > > ####################################################################### > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel > -- /kashyap From ayoung at redhat.com Wed Nov 30 15:52:26 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 30 Nov 2011 10:52:26 -0500 Subject: [Pki-devel] CMake 'JNI' macro question . . . In-Reply-To: <4ED59AA9.1000805@redhat.com> References: <4ED59AA9.1000805@redhat.com> Message-ID: <4ED6513A.4070407@redhat.com> Cross posting to Java devel as there might be a an answer from the Java/Fedora side of the house On 11/29/2011 09:53 PM, Matthew Harmsen wrote: > Andreas, > > I would like to request your assistance on the following 'CMake' issue > requested by Adam: > > * https://fedorahosted.org/pki/ticket/9 > > Basically, on Fedora 16 and later, the default location of Java Native > Interface (JNI) jar files was > changed to reside under '/usr/lib/java' for 32-bit platforms, and > '/usr/lib64/java' for 64-bit platforms. > > Per the TRAC ticket, I made a change in the spec files to handle this > via the 'jpackage-utils' RPM. > However, I do not know if 'CMake' can change the > 'JAVA_LIB_INSTALL_DIR' macro located in > the 'pki/cmake/Modules/DefineInstallationPaths.cmake' file to rely on > the '%{_jnidir}' macro of > 'jpackage-utils' stored in the '/etc/rpm/macros.jpackage', or if there > is a different way of handling > this where the following logic comes into play: > > * '/usr/lib/java' on RHEL 6 and earlier (32-bit AND 64-bit platforms) > * '/usr/lib/java' on Fedora 15 and earlier (32-bit AND 64-bit platforms) > * '/usr/lib/java' on Fedora 16 and later (32-bit platforms) > * '/usr/lib/java' on Fedora 16 and later (using a 32-bit JVM on > 64-bit platforms) > o I am fairly confident that this case may actually REQUIRE a > compiler override, as it does > not look as if 'jpackage-utils' computes its '%{_jnidir}' > macro based upon the 'JVM' architecture > being utilized, but rather the '%{_libdir}' macro based upon > the operating system architecture > located in the appropriate > '/usr/lib/rpm/platform//macros' file > * '/usr/lib64/java' on Fedora 16 and later (64-bit platforms) > > Your assistance on this matter is greatly appreciated. > > Eventually, do you think that we may want the appropriate logic added > to the '/etc/rpm/macros.cmake' file? > > Thanks, > -- Matt > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Wed Nov 30 15:53:22 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 30 Nov 2011 10:53:22 -0500 Subject: [Pki-devel] CMake 'JNI' macro question . . . In-Reply-To: <4ED59AA9.1000805@redhat.com> References: <4ED59AA9.1000805@redhat.com> Message-ID: <4ED65172.603@redhat.com> Cross posting to the Java Devel list On 11/29/2011 09:53 PM, Matthew Harmsen wrote: > Andreas, > > I would like to request your assistance on the following 'CMake' issue > requested by Adam: > > * https://fedorahosted.org/pki/ticket/9 > > Basically, on Fedora 16 and later, the default location of Java Native > Interface (JNI) jar files was > changed to reside under '/usr/lib/java' for 32-bit platforms, and > '/usr/lib64/java' for 64-bit platforms. > > Per the TRAC ticket, I made a change in the spec files to handle this > via the 'jpackage-utils' RPM. > However, I do not know if 'CMake' can change the > 'JAVA_LIB_INSTALL_DIR' macro located in > the 'pki/cmake/Modules/DefineInstallationPaths.cmake' file to rely on > the '%{_jnidir}' macro of > 'jpackage-utils' stored in the '/etc/rpm/macros.jpackage', or if there > is a different way of handling > this where the following logic comes into play: > > * '/usr/lib/java' on RHEL 6 and earlier (32-bit AND 64-bit platforms) > * '/usr/lib/java' on Fedora 15 and earlier (32-bit AND 64-bit platforms) > * '/usr/lib/java' on Fedora 16 and later (32-bit platforms) > * '/usr/lib/java' on Fedora 16 and later (using a 32-bit JVM on > 64-bit platforms) > o I am fairly confident that this case may actually REQUIRE a > compiler override, as it does > not look as if 'jpackage-utils' computes its '%{_jnidir}' > macro based upon the 'JVM' architecture > being utilized, but rather the '%{_libdir}' macro based upon > the operating system architecture > located in the appropriate > '/usr/lib/rpm/platform//macros' file > * '/usr/lib64/java' on Fedora 16 and later (64-bit platforms) > > Your assistance on this matter is greatly appreciated. > > Eventually, do you think that we may want the appropriate logic added > to the '/etc/rpm/macros.cmake' file? > > Thanks, > -- Matt > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Wed Nov 30 16:25:11 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 30 Nov 2011 11:25:11 -0500 Subject: [Pki-devel] PKI-Silent can't tell if this is success or failure In-Reply-To: <1322663394.19378.30.camel@aleeredhat.laptop> References: <4ED5A660.2040207@redhat.com> <1322663394.19378.30.camel@aleeredhat.laptop> Message-ID: <4ED658E7.8020404@redhat.com> OK, that was it. When I switched to : -save_p12 false \ it worked. On 11/30/2011 09:29 AM, Ade Lee wrote: > This is failure. > > Looks like you got a success response from the backup panel, but then > failed some processing of the response. Maybe you do not have the > required directory in which to backup the keys? > > Ade > > On Tue, 2011-11-29 at 22:43 -0500, Adam Young wrote: >> I've been crafting a PKI Silent call from the command line, and reading >> the various responses to see what I got wrong. Below is the end of the >> output from my last call. Is this "Success"? >> >> >> ############################################# >> Attempting to connect to: ayoung.boston.devel.redhat.com:8443 >> Connected. >> Posting Query = >> https://ayoung.boston.devel.redhat.com:8443//ca/admin/console/config/wizard?p=13&op=next&xml=true&choice=backupkey&__pwd=freeipa4all&__pwdagain=freeipa4all >> RESPONSE STATUS: HTTP/1.1 200 OK >> RESPONSE HEADER: Server: Apache-Coyote/1.1 >> RESPONSE HEADER: Content-Type: application/xml;charset=UTF-8 >> RESPONSE HEADER: Date: Wed, 30 Nov 2011 03:41:18 GMT >> RESPONSE HEADER: Connection: close >> >> >> >> admin/console/config/savepkcs12panel.vm >> >> ca >> >> success >> >> 19 >> Save Keys and Certificates >> >> >> >> welcome >> Welcome >> >> >> module >> Key Store >> >> >> confighsmlogin >> ConfigHSMLogin >> >> >> securitydomain >> Security Domain >> >> >> securitydomain >> Display Certificate Chain >> >> >> subsystem >> Subsystem Type >> >> >> clone >> Display Certificate Chain >> >> >> restorekeys >> Import Keys and Certificates >> >> >> cahierarchy >> PKI Hierarchy >> >> >> database >> Internal Database >> >> >> size >> Key Pairs >> >> >> subjectname >> Subject Names >> >> >> certrequest >> Requests and Certificates >> >> >> backupkeys >> Export Keys and Certificates >> >> >> savepk12 >> Save Keys and Certificates >> >> >> importcachain >> Import CA's Certificate Chain >> >> >> admin >> Administrator >> >> >> importadmincert >> Import Administrator's Certificate >> >> >> done >> Done >> >> >> >> CA Setup Wizard >>

14

>> >> savepk12 >> >> ############################################# >> Attempting to connect to: ayoung.boston.devel.redhat.com:8443 >> Connected. >> Posting Query = >> https://ayoung.boston.devel.redhat.com:8443//ca/admin/console/config/savepkcs12? >> RESPONSE STATUS: HTTP/1.1 200 OK >> RESPONSE HEADER: Server: Apache-Coyote/1.1 >> RESPONSE HEADER: Content-Type: application/x-pkcs12 >> RESPONSE HEADER: Date: Wed, 30 Nov 2011 03:41:19 GMT >> RESPONSE HEADER: Connection: close >> ERROR: ConfigureCA: BackupPanel() failure >> ERROR: unable to create CA >> >> ####################################################################### >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > From mharmsen at redhat.com Wed Nov 30 17:43:25 2011 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 30 Nov 2011 09:43:25 -0800 Subject: [Pki-devel] Question about nightly builds of 'pki-ca' for 'ipa-devel' in Fedora 16 and Rawhide . . . In-Reply-To: <4ED635D2.7090503@redhat.com> References: <4ED588C8.9030101@redhat.com> <4ED635D2.7090503@redhat.com> Message-ID: <4ED66B3D.10906@redhat.com> On 11/30/11 05:55, Dmitri Pal wrote: > On 11/29/2011 08:37 PM, Matthew Harmsen wrote: >> Before I file two release engineering tickets (one for F16 and one >> for F17 (rawhide)), I have a couple of questions regarding the >> following ticket: >> >> * https://fedorahosted.org/pki/ticket/61 >> >> As we are in the midst of moving source code from an 'svn' repo to a >> 'git' repo, and making potentially radical changes to the tip, should I: >> >> 1. Specify using an 'svn' repo or a 'git' repo for generating these >> nightly builds? >> 2. Specify the 'trunk', or 'DOGTAG_9_BRANCH' (the last 'stable' >> Dogtag source code that was released on Fedora 15, 16, and 17)? >> > > What is the difference between trunk and 9 brunch? As documented at http://pki.fedoraproject.org/wiki/Dogtag#Source_Code: This new version of Dogtag will be developed using the source code on the Dogtag Trunk which is currently stored utilizing the Subversion Revision Control System and managed using git svn until such time as the source code can be migrated to the Git Revision Control System . NOTE: As a part of this activity, the Dogtag trunk will be in flux, and so for the convenience of current Dogtag 9.0 users, we have created a source code branch entitled DOGTAG_9_BRANCH . > >> -- Matt >> >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From mharmsen at redhat.com Wed Nov 30 19:49:13 2011 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 30 Nov 2011 11:49:13 -0800 Subject: [Pki-devel] Request to enable nightly builds of 'ipa-pki-theme' and 'pki-core' on Fedora 16 and Fedora 17 (rawhide) Message-ID: <4ED688B9.2090702@redhat.com> To satisfy the PKI TRAC ticket https://fedorahosted.org/pki/ticket/61 'pki-ca in ipa-devel has not been built for Fedora 16 and rawhide', please create nightly builds of the following components on Fedora 16 and Fedora 17 (rawhide) for use by FreeIPA: * dogtag-pki-theme o dogtag-pki-common-theme o dogtag-pki-ca-theme o dogtag-pki-kra-theme o dogtag-pki-ocsp-theme o dogtag-pki-ra-theme o dogtag-pki-tks-theme o dogtag-pki-tps-theme o dogtag-pki-console-theme * pki-core o pki-setup o pki-symkey o pki-native-tools o pki-util o pki-util-javadoc o pki-java-tools o pki-java-tools-javadoc o pki-common o pki-common-javadoc o pki-selinux o pki-ca o pki-silent For 'stability' purposes, please point these nightly builds to use the following branch from the new PKI 'git' repo (until notified otherwise): * git clone -b DOGTAG_9_BRANCH git://git.fedorahosted.org/git/pki.git Thanks, -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From release-engineering at redhat.com Wed Nov 30 19:49:21 2011 From: release-engineering at redhat.com (mharmsen@redhat.com via RT) Date: Wed, 30 Nov 2011 14:49:21 -0500 Subject: [Pki-devel] [engineering.redhat.com #130939] Request to enable nightly builds of 'ipa-pki-theme' and 'pki-core' on Fedora 16 and Fedora 17 (rawhide) In-Reply-To: <4ED688B9.2090702@redhat.com> References: <4ED688B9.2090702@redhat.com> Message-ID: Ticket To satisfy the PKI TRAC ticket https://fedorahosted.org/pki/ticket/61 'pki-ca in ipa-devel has not been built for Fedora 16 and rawhide', please create nightly builds of the following components on Fedora 16 and Fedora 17 (rawhide) for use by FreeIPA: * dogtag-pki-theme o dogtag-pki-common-theme o dogtag-pki-ca-theme o dogtag-pki-kra-theme o dogtag-pki-ocsp-theme o dogtag-pki-ra-theme o dogtag-pki-tks-theme o dogtag-pki-tps-theme o dogtag-pki-console-theme * pki-core o pki-setup o pki-symkey o pki-native-tools o pki-util o pki-util-javadoc o pki-java-tools o pki-java-tools-javadoc o pki-common o pki-common-javadoc o pki-selinux o pki-ca o pki-silent For 'stability' purposes, please point these nightly builds to use the following branch from the new PKI 'git' repo (until notified otherwise): * git clone -b DOGTAG_9_BRANCH git://git.fedorahosted.org/git/pki.git Thanks, -- Matt From release-engineering at redhat.com Wed Nov 30 22:04:21 2011 From: release-engineering at redhat.com (Kevin Wright via RT) Date: Wed, 30 Nov 2011 17:04:21 -0500 Subject: [Pki-devel] [engineering.redhat.com #130939] Request to enable nightly builds of 'ipa-pki-theme' and 'pki-core' on Fedora 16 and Fedora 17 (rawhide) In-Reply-To: <4ED688B9.2090702@redhat.com> References: <4ED688B9.2090702@redhat.com> Message-ID: Ticket Hi Matt, I've requested the ip and mac addresses for the new machine. Once I have that, I can set up the new VMs. --Kevin