localization
by Dmitri Dolguikh
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
14 years, 1 month
[jesusr@transam.devel.redhat.com: please delete candlepin-1.0.1-1 tag]
by jesus rodriguez
----- 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 |
+---------------------------------------------+
14 years, 1 month
Fwd: Ruby / Fedora Testing Repos
by Bryan Kearney
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
14 years, 1 month
better exception handling
by jesus rodriguez
-----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-----
14 years, 1 month
Candlepin dependencies RPM Status
by Adam Young
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.
14 years, 1 month
candlepin as rpm
by jesus rodriguez
-----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-----
14 years, 1 month
Scrum status
by Adam Young
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.
14 years, 1 month
Packaging Candlepin as an RPM
by Adam Young
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?
14 years, 1 month
buildr as an rpm
by Adam Young
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.
14 years, 1 month
Stateless (Flyweight) and current user
by Adam Young
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?
14 years, 1 month