I am trying to get ROM RSS to work and the JDOM dependency is not working with it. Apparently this is because the JDOM libraries use the package org.jdom2.Document type classes not the org.jdom.Document classes that Rome is expecting. Apparently Rome is ancient and has not been maintained since 2009.
What is the solution here? Do I need to dredge up some ancient version of JDOM that Rome is actually compatible with or is there an alternative to Rome that has been maintained within the current decade and can work with the latest JDOM releases?
The latest releases of ROME can be found here: http://search.maven.org/#search%7Cga%7C1%7Crometools
We had to change the groupId some time ago
Related
My department is planning to switching to using NMT V3 soon, but we will need the dictionary feature (adding glossary and Do-Not-Translate list) for training.
This might have been asked before but I don't see any recent post asking for it, would you be able to advise when this feature will be released? A rough estimation will do (2019 Q1 for example)
Many thanks,
Simon
The dictionary feature should be available in Custom Translator within the next month. Please be sure to follow the Microsoft Translator blog (http://aka.ms/TranslatorBlog) and Twitter (http://aka.ms/TranslatorTwitter) to stay up to date with major Translator releases.
As you can guess I am at Qt developer and in the interest of getting up and running with libspotify as quickly as possible I am looking for a Qt wrapper.
I did come across this link https://github.com/romnes/libqspotify but as you can see the source is two years old. I am guessing libspotify has moved on a lot since then.
Does such a wrapper even exist?
Thanks
QSpot appears still to be in development and is based on libqspotify (they have copied the libqspotify sources into their qspotify_src directory). There are some recent commits (August 2012) to that directory, so I'd guess their classes are fresher than the ones you found on GitHub.
The sources of QSpot are found here.
If that doesn't work for you, there is also MeeSpot which is based on a library called libQtSpotify, located in MeeSpot's sources.
There's also Tomahawk. It's also open source
When I explored and worked on HttpUnit 3 yrs back I liked it for what it does. Though after 3 yrs of not tracking it, when I suggested a solution based on it to my colleague, he told me it is deprecated? The apache status tells it is active. No where I could find if this is true. I will be shocked if that is true. Went thro the bug list and found no assignees for last 1 year. Should I conclude from this inference that it is deprecated?
The news has not been updated because the website has not been updated, and is no longer current with the changes to sourceforge. I am looking into moving the project to github.
My name is Wolfgang Fahl and I am one of the committers of httpunit.
The project is not dead. Russell and me still commit changes regularly. Progress is slow since there are not too many developers involved. You are kindly invited to participate if you'd like to see any improvements. We have just released 1.7.2 to maven.org a few weeks ago:
http://search.maven.org/#artifactdetails|org.httpunit|httpunit|1.7.2|jar
See
https://stackoverflow.com/questions/21705675/patch-process-for-httpunit/21706183#21706183
for an ongoing activity. Please feel free to ask more questions here.
I am thinking of using either RSS or Atom in my project, but also "enhancing" the feed with some of my own special attributes specifically used by my project.
So I have two questions:
1) Which is most used of RSS and Atom on the web and by the big sites?
2) Which is most suitable to be build from by adding my own tags?
Update:
So RSS is most used, but I should pick Atom since I need to make my own tweaks on a feed? If RSS is more popular, why not pick that? Why didn't Google pick that?
There was a day when I was really interested in syndication and publishing formats. I knew all the quirks of RSS 0.91/1.0/2.0 and Atom 1.0 (and the 0.3 version). Atom was basically born to create something more complete out of the RSS experience which consisted roughly only on the very specifications of Dave Winer's and Netscape's (now only the RSS 2.0 makes practical sense and its specification is here: http://cyber.law.harvard.edu/rss/rss.html). Atom was started by Sam Ruby, then was adopted and developed by a committee of savvy people and it resulted in two things: an XML based syndication format and a publishing protocol. Since 2005 Atom is an IETF standard and in my opinion more complete and better specified than RSS.
As of adoption I think that in raw numbers RSS is still in advantage. A lot of sites decided to stick with the version they already had in place (RSS) and podcasting is usually done on RSS too. There a ton of websites offering both by the way.
As of expanding the format, your second question, Atom has been created with this in mind so you should go down that route. Google GData format is basically an extension of the Atom format: https://developers.google.com/gdata/docs/1.0/elements
Atom is absolutely the standard to go for.
I presume you're using the standard to share (or move) information - so it's like a pipe that your information is padding along. By adopting Atom you can be confident that both ends of the pipe are in agreement about what's in there. It's more hit & miss with RSS.
I ask this question in the hope of collecting all the incompatible changes/bugfixes in Flex 3.*, of which the maintainer of a Flex 2.0.1 application needs to be aware before upgrading. I'm thinking of issues of the following nature:
Bugs in 2.0.1 that had had some workaround, and have been fixed in 3.*, rendering the workaround not only useless but also erroneous.
Bugs introduced in 3.* that worked in 2.0.1, needing new workarounds.
Features that behave slightly differently (events, attributes, etc.).
Incompatible internal changes, that should not effect the progammer, unless they meddled a bit with the internal objects of the framework, like I did. :-)
Anything not fitting in any of these categories.
(I found several such issues, when I last tried this some time ago. Unfortunately I didn't take notes, and I forgot them since then, but I will update this post when I figure them out again. I reported one issue on the Adobe bug tracking site, it was unfortunately deferred.)
It would also be interesting to read about the advantages/drawbacks of such an upgrade. Are there any showstoppers?
here are some links that may help in your endeavors:
http://blogs.adobe.com/flexdoc/2008/02/migrating_from_flex_2_to_flex.html
http://blog.comtaste.com/2007/06/migrate_from_flex_2_to_flex_3.html
http://butterfliesandbugs.wordpress.com/category/flex-migration/
http://butterfliesandbugs.wordpress.com/2008/03/04/understanding-flex-3-migration-issues-part-i/
http://butterfliesandbugs.wordpress.com/2008/03/06/understanding-flex-3-migration-issues-part-ii/
http://butterfliesandbugs.wordpress.com/2008/03/16/understanding-flex-3-migration-issues-part-iii/
For the record, most of the migration problems from Flex 2 to 3 are minor, especially when compared to the problems of migrating from Flex 1.x to 2. I upgraded several applications with no problems at all. That being said, the above links should help note most of the problems you might run into.