candlepin April 2010

candlepin@lists.stg.fedorahosted.org

9 participants
22 discussions

localization
by Dmitri Dolguikh 16 Apr '10

16 Apr '10

changes are in. Here's the skinny: - there's a new dependency in the build: gettext-commons - there are new targets in the build: extractkeys - extracts strings that need to be localized, mergekeys - performs a merge on the existing .po files, createresourcebundles - compiles resource bundles - localized resource bundles can be found in localized_resources/classes/ directory - if you're running tomcat from under eclipse, you'll need to the above directory into tomcat's classpath how to use it (development): inject I18n (there's a I18n provider) instance in the classes that will have user-visible text. Then (assuming instance variable name is i18n): <snip> i18n.tr("goodbye, cruel world."); </snip> will do the trick. NOTES: if a resource bundle for a given locale wasn't found, the default locale (en_US) will be used. Default locale (en_US) is an empty resource bundle, therefore all calls to tr() will return unmodified arguments. how to use it (translation of resources): - create .po file for the desired locale in localized_resources directory - update buildfile (tasks mentioned above) with the new locale - run mergekeys - provide translations using poedit (or w/e else you choose to use) - run createresourcebundles to build the resources - profit! -d

5 8

[jesusr@transam.devel.redhat.com: please delete candlepin-1.0.1-1 tag]
by jesus rodriguez 14 Apr '10

14 Apr '10

----- Forwarded message from Jesus Rodriguez <jesusr(a)redhat.com> ----- Date: Wed, 14 Apr 2010 10:44:55 -0400 From: Jesus Rodriguez <jesusr(a)redhat.com> To: candlepin(a)lists.fedoraproject.org Subject: please delete candlepin-1.0.1-1 tag User-Agent: Mutt/1.5.19 (2009-01-05) I'm reversioning candlepin to 0.0.1, thus the current candlepin-1.0.1-1 has been deleted. Please delete it from your local checkouts: git tag -d candlepin-1.0.1-1 I could've left it there, but it'll cause problems when we hit the real 1.0.x versions. Sure we can skip 1.0.1 but then you'll see ... candlepin-0.9.8-1 candlepin-0.9.9-1 candlepin-1.0.1-1 - points to VERY old code unless deleted candlepin-1.0.2-1 ... By deleting the tag, we can start fresh and not worry about it down the road. Sorry for the inconvenience. jesus -- jesus m. rodriguez | jesusr(a)redhat.com principal software engineer | irc: zeus red hat systems management | 919.754.4413 (w) rhce # 805008586930012 | 919.623.0080 (c) +---------------------------------------------+ | "Those who cannot remember the past | | are condemned to repeat it." | | -- George Santayana | +---------------------------------------------+ ----- End forwarded message ----- -- jesus m. rodriguez | jesusr(a)redhat.com principal software engineer | irc: zeus red hat systems management | 919.754.4413 (w) rhce # 805008586930012 | 919.623.0080 (c) +---------------------------------------------+ | "Those who cannot remember the past | | are condemned to repeat it." | | -- George Santayana | +---------------------------------------------+

1 1

Fwd: Ruby / Fedora Testing Repos
by Bryan Kearney 14 Apr '10

14 Apr '10

FYI. -- bk -------- Original Message -------- Subject: Ruby / Fedora Testing Repos Date: Wed, 14 Apr 2010 02:41:48 -0400 From: Mohammed Morsi <mmorsi(a)redhat.com> Reply-To: Ruby SIG mailing list <ruby-sig(a)lists.fedoraproject.org> To: Ruby SIG mailing list <ruby-sig(a)lists.fedoraproject.org> Hey just a quick update w/ some work I've been doing towards getting a platform which to test Ruby on Fedora. I've pushed many updates to Polisher (http://github.com/movitto/polisher) the focus of which has been expanded to manage any generic upstream project release process. Special cases have also been added to make use of the gemcutter API and gem2rpm for gem based projects. I've also added a Ruby DSL which can be used to descibe any number of projects w/ sources, and setup post-processing workflows to be executed on releases. I've grabbed several popular Ruby related packages in Fedora, made some small modifications to the specs, and setup Polisher scripts (http://github.com/movitto/polisher-scripts) to run through simulated releases of various versions, setting up the following yum repos (http://projects.morsi.org/polisher/repos) in the process: * stable - same packages that are currently in Fedora updates * maintenance - later releases in the same major version branch of the packages currently in stable * devel - packages that work w/ Ruby 1.9 (great <a href="http://isitruby19.com/">resource</a>) * rawhide - all latest ruby project versions By tweaking the Polisher scripts and rpm spec file templates, the contents of these repos can be changed and new ones can be setup for any target software stack. You can simply point a yum repo entry towards any of those repos beforing running a yum update to get all the latest Ruby packages provided by that repo, through there most likely will be breakage as Polisher and the scripts themselves are a work in progress. I'm also setting up various virt appliances, each pointing at a different Polisher generated repo by default, so that anyone can just download a VM image containing Fedora and a complete Ruby stack for whichever version of Ruby they want to use. It's a work in progress, I will put links up on my blog (http://mo.morsi.org/blog) as I upload the images. Obviously this is all a work in progress and it is quite a bit of effort to get Polisher scripts written for every Ruby related package, but if this thing starts rolling, I can see this as being a useful tool in the "upstream project to Fedora repo" process as mass parallel source releases can be triggered and handled easily in a committable / reproducible / reliable fashion. If anyone has any cycles I'd appreciate any help (patches, testing, etc). Stay tuned for more updates. -Mo _______________________________________________ ruby-sig mailing list ruby-sig(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

1 0

better exception handling
by jesus rodriguez 13 Apr '10

13 Apr '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We have a task to get better exception handling from the API and the client. We'd like to have better error messages and possibly error codes, as well as json serializable. Today we throw the following exceptions: ForbiddenException - thrown from ConsumerResource NotFoundException - thrown from a few Resources BadRequestException - thrown from almost all Resources WebApplicationException (parent to the above) - called directly The above exceptions extend WebApplicationException and for the return type to be "text/plain", which means you can't parse it as JSON on the client side. This is odd since all other responses are in JSON, it would be nice to be consistent. Sadly it isn't enough to leave off the type call as it will default to text/plain. In order to get it serializable the thought is to create a class to be used as the payload for the Exceptions, say something like ExceptionMessage. This class will be annotated with JAXB objects and can be used to return as JSON or XML based on the Accept header, just like the other API calls do. The thought is to have it contain the following: * error code - int * label - string * display message - string (i18n probably) We may not need the error code since the HTTP codes might be enough, then we'd just need to have decent message strings. HTTP status codes - http://en.wikipedia.org/wiki/List_of_HTTP_status_codes ResponseStatus javadoc - http://bit.ly/aMhkkM Now on the exception side, we can continue to create wrapper exceptions like BadRequestException OR we could use standard exceptions and use the RESTeasy ExceptionMapper to map a standard exception to a proper Response code. I personally like the wrapper exceptions since it makes it more explicit, then use the ExceptionMapper for a final catchall like NullPointerException, and other gross things that we might want to offer a nicer error message to easy the pain :) All in all the main key is to identify better error messages that the client can use and make it consistent for Resource developers. jesus - -- jesus m. rodriguez | jesusr(a)redhat.com principal software engineer | irc: zeus red hat systems management | 919.754.4413 (w) rhce # 805008586930012 | 919.623.0080 (c) +---------------------------------------------+ | "Those who cannot remember the past | | are condemned to repeat it." | | -- George Santayana | +---------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAku8+mcACgkQvJZ57YntiYOMKwCg1ZjNmJ9URIUHTd2OxzIG31FN HkkAn0YPX+13VjO6X1O7H0ldz2iPEM3h =luRo -----END PGP SIGNATURE-----

7 17

Candlepin dependencies RPM Status
by Adam Young 09 Apr '10

09 Apr '10

I've updated the dependencies page with the latest status of the RPMs. https://fedorahosted.org/candlepin/wiki/Dependencies The One's that I am building are at the bottom under MySpecs. They are all checked into a huge ugly project on github: http://github.com/admiyo/MySpecs There are a couple there that can be removed: aopalliance is covered by JPackage, I think, and the asm3 is covered by objectweb-asm. Once I get all of them built, the real fun starts: trying to make this whole thing work together. One quick check I plan on doing is gathering the jars from these files, and comparing to a list of the files composed in the jars inside of candlepin/WEB_INF/lib. I know that some of the test classes aren't there, as some projects use som rfairly archaic tools for testing, like Acme.Serve.Serve. Yes, that is a fully qualified java class name. There have been a few additional deps that have been added in order to build some of these. Let me state for the record that Java not having Header files is a bigger pain than I ever realized. Of the ones I have left: teh two rest-easy ones should be easy to medium, as I think I've gotten most of the resteasy deps knowcked out. jta Is probably pretty easy, as I have the sources for it. I haven't looked at the The Jackson jars at all. I did a quick stab at Hibernate-tools this morning. Lots of Binary dependencies. It is probably going to be the worst one.

3 2

candlepin as rpm
by jesus rodriguez 08 Apr '10

08 Apr '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 WARNING! WARNING! WARNING! very long email, bear with me please :) WARNING! WARNING! WARNING! Here is the updated candlepin.spec file (as of today) : http://bit.ly/9WAXXK Here is the diff between what's in master and my tito branch: http://pastie.org/908199 I installed the tomcat6 version of the rpm on my development machine and was able to run the python tests against it (after I did the 'init' step from the deploy script). There is still quite a bit of work to get candlepin packaged 100% as an rpm with all of its dependencies ( see Adam's list: https://fedorahosted.org/candlepin/wiki/Dependencies ) but there are a few more items that need to be addressed before we can merge the tito branch back to master: 1. explode candlepin war for the jboss deployment 2. fix githash code to work or find alternative approach 3. spec file requires rubygem-buildr rpm to build, we could make that BuildRequires: /usr/bin/buildr until the buildr rpms are ready. 4. buildr's buildfile has a version (which hasn't changed, and the spec file has a version which tito bumps automagically). How hard are the above issues to address? 1. is trivial will be done probably before you read this email. 2. this is a bit more difficult because we need a way to update the candlepin_info.properties on the fly and the build isn't running in a git checkout at the time of the rpm build. How important is the candlepin_info.properties with a git hash? 3. requiring rubygem-buildr is the proper way to do it, but if the rpm isn't ready for folks to deploy, then the candlepin rpm won't be buildable yet. Changing it to require /usr/bin/buildr will make it buildable now and *will* require changing once we have a proper rpm of buildr. An alternative is to BuildRequires: ant, add a build.xml to build the code just for the rpm. (sorry I ain't doing no maven rpm). I'm leaning towards simply requiring /usr/bin/buildr for now, and merge it into master for now with a new item to finalize the buildr rpm. 4. I think the best way is to *pass* in the version number to the build command from the spec file, and have the buildfile read the version from the spec file during dev builds. In other words, in the candlepin.spec the %build section will look as follows: buildr clean test=no package version=%{version} I'm not sure if this is even possible on the buildr side, but since it can do anything ruby and rake can, it's probably doable. I'll need help with coming to a decision on 2, 3, & 4 so we can merge this into master. jesus - -- jesus m. rodriguez | jesusr(a)redhat.com principal software engineer | irc: zeus red hat systems management | 919.754.4413 (w) rhce # 805008586930012 | 919.623.0080 (c) +---------------------------------------------+ | "Those who cannot remember the past | | are condemned to repeat it." | | -- George Santayana | +---------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAku87zsACgkQvJZ57YntiYMy2gCcCyXbBzRTfoqz+cLc5j9OAwSO Ta8AoKiRSV4bHFoC8nt7jGLqlH1TxlDW =P+W8 -----END PGP SIGNATURE-----

4 6

Scrum status
by Adam Young 05 Apr '10

05 Apr '10

Last week: Started working on a script to convert the sources.jar dependencies for candlepin into spec files Today: Get it working for one of the poms and post for code review No Blockers.

1 0

Packaging Candlepin as an RPM
by Adam Young 05 Apr '10

05 Apr '10

After doing the work using gem2rpm, I realized that we could do the same kind of thing for the Java dependencies that don't have RPMs in Fedora. The Maven repos tend to havea source jar with a standard naming convention right next to the binary jar, and the pom file has most of the info required by the RPM: License, version, dependencies, and so on. I've started working on a pom2rpm script that produces a spec file. And, to make Jesus happy, I wrote it in Ruby. So, for this sprint, I'd like to hand off the Group/Security tasks to someone else, and concentrate on getting Candlepin packaged as an RPM. Is this OK?

3 5

buildr as an rpm
by Adam Young 05 Apr '10

05 Apr '10

Just doing the preliminary spike into getting buildr and candlepin to build as rpms. Here's what I have so far: We need to add the following gems as RPMs Antwrap (= 0.7.0, runtime) echoe (>= 0, development) fakefs (>= 0.2.1, development) heckle (>= 1.4.3, development) json_pure (>= 1.1.7, runtime) net-sftp (= 2.0.2, runtime) net-ssh (= 2.0.15, runtime) prawn prawn-format rjb (= 1.1.9, runtime) rr rubyzip (= 0.9.1, runtime) shoulda spork xml-simple (= 1.0.12, runtime) webmock To generate this list, I ran gem dependency buildr | cut -f1 -d\( | xargs gem dependency | grep -v Gem | sort -u | cut -f1 -d\( and then kept adding on to the end | xargs gem dependency | grep -v Gem | cut -f1 -d\( | sort -u | xargs gem dependency | grep -v Gem | sort -u | cut -f1 -d\( Until I go no new gems. I haven't Built a tree out of them yet. I've attached an spreadsheet so you can see the list of dependencies that are filled as well.

4 21

Stateless (Flyweight) and current user
by Adam Young 01 Apr '10

01 Apr '10

The current implementation of candlepin is complete oblivious to the caller. We can authenticate, but once we do, we do not tailor the output of the calls based on who logged in. If we are to implement the multi-org functionality, we need to rpovide a mechanism for checking "who asked this." For example, on ConsumerResource.list is implemented as: public List<Consumer> list() { return consumerCurator.findAll(); } To filter this via user, we have three choices. I'm going to use rincipal for the user, as we don't havea first calss user object yet, but we can change that later. 1. Change the method signature public List<Consumer> list(Principal p) { return consumerCurator.findByOwner(getOwner(p)); } 2. Add it to the ConsumerResource constructor via dependency injection. (Note that I wouldn't really implement getOwner this way, just to demostrate) public List<Consumer> list() { return consumerCurator.findByOwner(this.getOwner(this.getPrinciapl())); } 3. Fetch it from a context like JNDI public List<Consumer> list() { Principal p = (Principal)new InitialContext().resolve(Principal.class.getName()); return consumerCurator.findByOwner(this.getOwner(p)); } Option 1 is best for cases where this is going to be only required for one or two methods. THe Principal will be needed for just about every method. Option 2 means that the Resource Objects will no longer be stateless, but instead will have to be created either on each request, or once per session Option 3 menas we have non-explicit dependencies. Do we need a meeting for this?

5 16

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

candlepin April 2010