I currently have an application that runs on jfreechart-1.0.13, and would like to upgrade it to run on jfreechart-1.0.17(latest).
So I am wondering how can I integrate the latest version of jfreechart with my current application?
In this application, I have build.xml (which is common to jfreechart I notice). Do I need to just update the urls in here to point to the latest jar file?
How can I upgrade my existing application to use the latest version of jfreechart?
As with everything Java, at the very least you'll need to replace the old jar files with the new. Whether that means physically swapping them out in your project, or pointing some configuration file to point to other files depends on your environment.
After that, all bets are off as there may well have been API changes that require changes to your code for things to compile, let alone run.
build.xml is typically an ANT file, and would have no influence on what jar files are included as ANT expects all those to be available already.
Of course other systems can use the same name, impossible to tell from here :)
IOW know your environment, do what is needed in your environment, then TEST.
Related
I'm a recent CS grad working for a start-up. I've been tasked with adding new features to some software they bought. I've downloaded the software from AWS and have begun trying to get started but I'm having trouble with the front-end, which is built with React and bundled by Webpack.
The download left me with an old version of the front-end and minified files of the new version. I was able to use their source maps to unpack them and get the unbundled files but now I can't figure out how to rebuild it.
The old version is set up to have its dependencies installed and minified by npm. I would like to set up something similar with the new version. I've been able to add all its dependencies to the package.json file but I keep running into errors, mostly stemming from versioning conflicts. What should I do in this situation? Am I just going about this the wrong way?
Software might be a vague term to describe what you have in your hands.
It seems from your wording that you have the source code of an older version, but the production build (bundle.js, main.chunk.js, etc) of some newer version, for which you don't have (or potentially own) the source code.
React is very complex itself, it was probably built using Create React App, dealing with the bundled and ejected files is probably worse, and adding the new features without the source code sounds like a nightmare for a CS grad at a startup. This might even potentially be illegal.
I'm new to qooxdoo. I'd like to use it for an embedded web interface for an application I'm developing right now.
To keep building my application as easy as possible I'd like to stay away from using the python build scripts after every change if possible. Because the website will only be used once in a while by a single user load times etc. are also not a big concern for me.
I've read about the "build-all" target but could not find a detailed description on how to activate it with the current release. Can someone explain how I can get a complete desktop build of qooxdoo?
You don't have to run generate.py every time you change the code, only every time you reference a new class. During development it's usually relatively infrequent that you have to re-run the generator, compared to how often you will do the edit/save/alt-tab/refresh/test cycle.
But you can do what you're asking during development by using the "source-all" target, eg:
./generate.py source-all
When loading an app from a file:// url this is fine because file:// URLs are very fast, but you can optimise this manually by modifying your config.json to incorporate specific sets of classes.
To do this, in your application's config.json, add (or edit) a job called "source" and add:
"jobs": {
"source": {
"include": [ "qx.ui.*" ]
}
This will cause all of the qx.ui.* classes to be included into the ./generate.py source build of your application; obviously you can fine tune this further.
When it comes to deploying your application, use ./generate.py build because this will produce a minimised, optimised version (with debug code removed etc) which uses only those classes that are required.
If you are still looking for a build version of Qooxdoo, here is my qxSimple project. It includes some examples.
http://adeliz.github.io/qxsimple/
You can also generate your own build version following these steps :
Dowload the latest qooxdoo release
Go in the framework folder
Edit the config.json file
uncomment the //build-all line
run generate.py build-all
What is the best way to upgrade a local development version of DNN source without destroying the database (pages, settings, module settings, etc..)?
I'm currently moving from 07.00.XX to 07.02.00 and there is a tremendous amount of refactoring, seems impossible to just overlay the source.
Is there a way I can do this with preservation of all settings, etc....or will I need to rebuild parts of the site?
Since you are using the SOURCE package, you should be able to simply copy the SOURCE files from the ZIP file you download, over all of the existing files.
You might make sure that the new SOURCE package doesn't have a web.config file, if it does, remove/rename that so that it doesn't replace your existing web.config file, and thus saving your MachineKeys and connection strings.
Back up the FILES and Database before you attempt this however, just to be safe.
After the copy you might have to build the solution before the upgrade will work.
I typically don't recommend using the SOURCE package for DNN, unless you absolutely need to make changes (not recommended) to the source, it isn't necessary for doing Module Development or skinning.
I'm trying to divide my solution by three configurations:
Development
Testing
Release
All above will have different publishing location, so users can work with release, do their test in testing and see what is new in development release. All three versions will be build with different name postfixes and icons and installed on each user workstation.
For now I get :
Unable to install this application because an application with the
same identity is already installed. To install this application,
either modify the manifest version for this application or uninstall
the preexisting application."
I can't even install this more than once at one workstation.
So What can I do to achive this?
You can not install the same application multiple times unless you change the deployment. The easiest way to do this is by changing the assembly name. This article explains this.
As time past, I can now see that the solution was quite close, just required me to be able to specify my requirements first.
So, now I can tell that it mostly depends on number of such configurations:
if it is limited and low, i.e. live/test/dev, you can have each as separate project in solution, like AppLive, AppTest, AppDev, this requires refactoring to move everything that is common into separate projects, but it makes code and releases clearer and easier to manage.
if those configurations are unlimited, or number is high, than way to go is to load configurations from file and pick one from the pool based on custom logic.
Currently I'm using mix of both, as I want to be able to release test versions earlier than live, but also my application is used by multiple branches, and each of them has some unique styling, logos and such, so this is applied from embed xml file, and proper set is identified based on Active Directory entries.
I would like to know what are the industry standards or suggestion on how are you doing at your end for following situation.
I am creating multiple silverlight projects which get publised at different dates. All these projects uses varios shared code (common dlls). These shared code would be used in client side or server side. My question is, if the shared code changes would you recompile all the afftected project and release or recompile only when you are making change to the actual code which uses the shared component?
For now, client side, we create a assembly reference folder in each silverlight project and put the latest required dlls in it. By doing it, it has all required files in the XAP itself and it will not conflict with other projects and it works fine. With this approach I will not rebuild any other client side code just because common dll changed. If the common dll change is required for multiple projects then drop the latest copy in all affected projects and build them and distribute them.
On the other hand, the server side (Domain Services using EF), all the service code sit under bin folder of the web site. So if i would make a change to a common dll, then not only I need to publish the latest common dll for current project to work, but also recompile all the other services to use the new dll.
Would like to know your opinions and suggestions.
Thanks
There are two approaches possible:
Add Common Code to the solution and have a project reference
Get the build process to build to a folder and reference from there
I prefer first option. I always build and debug using the latest code and do not have to worry about stale references. I have used the second approach in the past and it is messy and can waste your team's time going after debugging bugs that do not exist (old version referenced). In fact I remember Visual Studio sometimes would not get a later version when it was available.
Another alternative for your Silverlight projects would be to use MEF to dynamically download a XAP file containing the common libraries. Then if the common libraries change, you could publish an updated "CommonLibraries.xap", and your Silverlight clients can pick up the refresh independently of the rest of the Silverlight application.
You could follow the same approach with other projects that use these common libraries. The applications could dynamically load the common libraries so that the common libraries can be refreshed independently.
If possible, consider consuming the "common library" code via WCF services.