I'm using 24.0.0.alpha4 and vaadin-core in my pom.xml. vaadin-testbench dependency is removed. Project is created at start.vaadin.com. When building in production mode a license is requested. Is this something new in v. 24, or just a glitch in an alpha-version?
It's a glitch.
As a workaround, you can manually exclude flow-polymer-template that is accidentally brought in as a dependency of vaadin-core.
Related
We are building a web app with Vaadin 19 Fusion, and I'm following this tutorial:
https://vaadin.com/docs/latest/fusion/security/spring-login
(I have selected the V19+ Docs and then Fusion)
In the tutorial there is a reference to VaadinWebSecurityConfigurerAdapter which is used for setting up the security with Spring, but this class is not available on the classpath. I have tried downloading a plain starter project (v19) from start.vaadin.com, and here I am also not able to use VaadinWebSecurityConfigurerAdapter.
Is there an alternative in v19 or am I missing a dependency? I have the same dependency tree as the starter project, so I was assuming the pom is correct.
It looks like the VaadinWebSecurityConfigurerAdapter will end up in V20, which is scheduled for release in June.
The documentation page you linked has a tag V20 pre-release at the top. This could certainly be made more visible.
I packaged my addon and tested in firefox 31 , it worked fine.
I try to install it on firefox 21 , I got an error mentioning invalid package addon/sdk/window
my question is how could i include packages so that it could work on firefox 21?
Any ideas?
Thanks
I dont think that will be supported, as firefox is improving day by day, and changes in the version of SDKs also.
Also, the firefox v21, must not be supporting the SDK packed addons. You should create them using XUL.
cfx has the option --force-use-bundled-sdk to bundle the sdk libraries themselves with the XPI, but that doesn't guarantee that those modules will work in older firefox versions
You could also wrap the module require() in try-catch blocks and use older APIs on failure. I think some modules were renamed over time
Also, FF21 is long out of support. At the time of writing 31.4.0esr is the oldest still maintained release.
We are using this openAM 9.5 RC1 branch source in our project. https://github.com/svn2github/openam.git
In order to fix some bugs, we have to modify existing openAM's amserver library. For this, we have downloaded the source code from above location and tried to compile it offline using ant (as stated in README). But we are not able to compile it anyhow (even after making necessary changes, adding dependencies etc.)
Is there any way to construct required library (amserver.jar) from this source code ?
The OpenAM 9.5.x and 10.0.x versions are rather difficult to build, but from 11.0.0 the build process should be much more simpler since the project has been migrated over to Maven build system.
In any case, the version you are using (Snapshot 9.5.1 RC1) is very much outdated and most likely has several critical issues (not to mention the security issues).
I would strongly advise against putting effort into backporting fixes to that ancient version. Instead you should realize that you are running a more than 4 years old version of a security component, and upgrade your system to a more recent version as soon as possible.
IDEA 11.1.2
I have a Grails app I need to upgrade. The application consists of several modules. One being the application and a few others being plugins. I right clicked on the application and went to Grails -> Change SDK Version. I chose the version I wanted, then IDEA asked me if I wanted to upgrade the application. Clicked yes and all was good.
I've been trying to do the same thing on the plugin modules. IDEA never asks if I want to upgrade and it doesn't appear to change the SDK. If I upgrade the modules from the command line, when I come back to IDEA, it thinks there is a version mismatch and automatically downgrades me without even asking.
Is there a workaround for this?
It worked for me in this IDEA version. Make sure that you change Grails version in application.properties of all plugins:
app.grails.version=2.1.0
Then right-click on every module (plugin), Grails, Change SDK version. It should be changed already.
Have exactly same problem - app + plugins wich requires different SDK (for testing).
After some investigation found that it's an IntelliJ IDEA bug IDEA-114418. So, I think, it will be good if you'll vote for this bug there too.
I also had the same bug. I took extreme measures to rectify it.
I deleted the old grails from the Global Libraries. Go to file>Project Structure > Global Libraries . It should complain that this is used by a module.
Then I had to add grails framework support, but added the new one.
I've just inherited an application written in Grails (version 1.0.3) and would like to upgrade it to the newest release (version 1.3.5).
I can't seem to find a reference that enumerates the differences between the two versions. I know there is the "grails upgrade" command - but is this the best option given the large differences in versions.
I have a similar question that I asked today as well for upgrading the version of Groovy, and the sntactical differences to be aware of (between version 1.3.5 and 1.7.5) - but I thought it may be best to separate the two questions to focus on each.
Many thanks,
~Aki
Things have changed quite a bit since 1.0.3, and unfortunately grails upgrade isn't going to do much for you.
Two significant changes that come to mind are that there was a bug in 1.0.3 and previous where 1-many and many-to-many collections (hasMany/belongsTo) were supposed to be lazy-loaded but weren't. This was fixed in 1.0.4 and several users found that they were relying on the behavior and saw issues. Most people didn't, and just saw a significant performance boost. So watch out for lazy loading exceptions.
Another thing that changed is that plugins are no longer in the root of the project in the 'plugins' folder but are now stored under your $HOME/.grails folder. If you've checked the plugins into source control (and especially if you've made any changes) then you can revert to 1.0.x behavior by adding a property to BuildConfig.groovy (a new file that was introduced in 1.1):
grails.project.plugins.dir = 'plugins'
I described my process for upgrading plugins and apps here: How to install Grails plugin from source code? - it's about a plugin project but the same goes for app upgrades.
The log4j configuration changed from one that's properties-based to a DSL. This means that if you leep your config settings from Config.groovy the log4j behavior will be the default, so you'll need to convert that.
Another change that isn't required but should be considered is that Ivy jar file resolution from Maven repos is now preferred over putting jar files in the lib directory. You can still put them in the lib dir, but it's more DRY to have Ivy download them once.
You'll probably also find that some of the plugins you have don't work in 1.3, so there might be some migration work there.
There are two recent books that cover Grails 1.2/1.3, "Grails: A Quick-Start Guide": http://www.amazon.com/dp/1934356468/ and "Getting Started with Grails, 2nd ed": http://www.infoq.com/minibooks/grails-getting-started - you should probably check those out since they're the most current Grails books.
Overall it shouldn't be that bad, as long as you don't try to upgrade in-place. Use the approach I described in the other post I referenced, i.e. create empty apps and diff files to see what changed (basically a 3-way diff).
The newest release is 1.3.6 (as of Dec 15). You can get a list of changes from the Release Notes of each release. Also, the upgrading from previous versions link the documentation is a good source of changes.