I am using ag-grid but came to know about it's huge bundle size which makes it impossible to add it into the website due to the obvious concerns being raised about increase in bundle size.
I have tried the approach to use modules #ag-grid-community/core which again is 1.88mb in bundle size.
Is there any other approach to decrease the bundle size further and exclude different modules?
Is it the similar case with ag-grid-enterprise? I can see if I include it without license it download ag-grid-community/core module too which again defeat the purpose.
You will find that the majority of the code is in the #ag-grid-community/core package and so is the largest part of AG Grid. This code is shared by the enterprise featurs.
Using the grid feature modules, as described in the docs you will be able to just add the enterprise features that you require. As such you may find that the bundle size does not increase that much when moving to Enterprise
I have written the following article that walks
through this.
Related
I have an Eclipse-based OSGi application consisting of bundles organised in features. I use a product definition to launch the application. In this definition, I can also set start-levels for my bundles.
Now imagine I want to add a feature to the running application. Is a p2.inf file the only way to specify start levels for the bundles in this feature? Re-defining and re-starting the product does not sound like an optimal solution as it's not really dynamic.
I am not aware of any real tooling support for setting start levels for bundles on the feature level. The only option you have is manual hacking with a p2.inf.
I think the reason that setting start levels is only really supported for products is that p2 can't handle the case where start levels are specified multiple times. This could easily happen if setting start levels on feature level was encouraged.
So, you can make this work on feature level, but only if you know what you do.
I have the same problem I believe: I have a feature that is both part of a packaged product and present on an update site to be installed into an Eclipse IDE. And I also want to set the start-level for some of the plug-ins to ensure a very early start-up.
I have overcome this with a p2.inf file with the following content:
instructions.configure=setStartLevel(startLevel:1);markStarted(started: true);
instructions.unconfigure=setStartLevel(startLevel:-1);markStarted(started: false);
(I don't think I need to specify the start-level in the product definition anymore though I have not tried to remove this yet.)
I originally used start-level 2, but at least for Juno packages, there are some plug-ins that are started at level 1 so I now use level 1 as well.
I have an application in the form of a jar file which is around 2MB in size. For several reasons, I have to bundle the JRE with my application. When I create an MSI with my jar and the JRE, the MSI size comes out to be around 30MB.
I am looking for a commercial or free JRE which I can bundle so that I can reduce the size of my MSI to as low as possible. I am looking at 5MB total, but even upto 10MB may be OK.
Prebuilt JRE Binaries would be great, but not an absolute must.
I looked at similar questions posted here and here.
A lot of answers in these and other threads suggest Excelsior. I downloaded an evaluation version of Excelsior JET & Tried it out - for a few reasons, I think it may not be the right product for me.
1) Excelsior looks at reducing the footprint of the Installed Product not the Installer. I don't care much about the size of the Installed Product - I am mainly looking at a smaller download (the installer of my product currently at 30MB).
2) Amongst other things, Excelsior does lot of optimizations to code to achieve this - I don't want my jar file touched at all. I want a smaller JRE with my jar as is. There isn't a way to turn off some of the optimisations also.
3) Excelsior creates an EXE - I am not particularly looking for this - I am ok with my product being invoked via the javaw.exe command line.
So are there any suggestions for my need?
Avian and ProGuard are your friends as someone has already mentioned in one of the threads you linked to (it's the second comment btw).
From the Avian homepage:
The class library is designed to be as loosely coupled as possible,
allowing tools like ProGuard to aggressively isolate the minimum code
needed for an application. This translates to smaller downloads and
faster startup.
Sounds like exactly what you need. And if that doesn't help you then look at the rest of the tools referenced in that thread.
There is a possible solution here. Those tools install a minimalistic version of Java. I don't know if it is small enough for you. Just take a look and see:
https://superuser.com/questions/745112/how-do-i-run-a-jar-file-without-installing-java
I would make the JRE a separate install from Oracle (or your preferred vendor) You could have it download as required if you wish. If the JRE is already installed, it would be a waste to download it again even a reduced JRE.
BTW: I wouldn't mess with what is in the JRE because
AFAIK its a violation of your license agreement.
Its very difficult to get right and not remove a class you might need one day.
Maybe outdated: there was a rumor about something called JavaKernel/ConsumerJRE.
http://weblogs.java.net/blog/enicholas/archive/2007/05/java_kernel_unm.html
http://www.oracle.com/technetwork/java/javase/kernel-135055.html
I'm going to deploy a QML based application. Now I'm wondering it's better to use resources system for .qml files and their associated files or using relative addressing or there is a better way?
The first way maybe make the project difficult to manage if the number of qml files and your images become larger and larger. Also I think it would be harder to deploy third party plugins like Qt desktop components.
And the second way is not secure as it should be. Every one can open a text editor and edit your .qml files.
Is there a better way?
Using Resource system :
Binds all the dependencies into one single binary, thus no problem of placing them at exact locations as per the paths given in your code.
Many times you would not want to share your qml code/images etc. [close source projects], helpful in those cases. Also it is more secured as no one can modify your files and cripple your application possibly.
You will not be able to modify these dependent files at run time, which might be required in some cases.
The first way maybe make the project difficult to manage if the number of qml files and your images become larger and larger.
Contrary to what you say, I think its easier to manage them, how so many files there might be. You can see here how easy it is to do using Qt Creator.
Relative addressing:
All the dependencies are scattered at different locations, thus problem of placing them at exact locations as per the paths given in your code.
Since your files are directly available to anyone who would want to access them, unsecure.
If there is a modification required in one the files at run time, you can do it. Eg. having a log file and writing/reading some data into/from it.
Difficult to manage(compared to first approach) when number of files increase as exact paths have to be given.
One personal advantage I have found of second approach is in situations like this :
I need to send my Qt apps for Demos to clients with managers, offshore. These demos go on full day. If some minor UI feature ( eg size of a button seems very small ) is getting too much negative attention, we can direct the manager over call to the respective qml file, and make him do small changes ( eg. scale : 1.5 ) This is helpful as we wont have time to build the whole system, resend the exes to them etc.
Is there a better way? Not that I have seen any. I thinks its a matter of finding which one of the above suits your requirements more.
Given a project I'm about to start there will be documentation produced.
What is the best practice for this?
Should the documents live with the code and assets or should there be a separate documentation store?
Edit
I'd like a wiki but I will need to print the documents etc... It's a university project.
It really depends on your team. Where I work, we keep documentation in a wiki which is linked in with our team website. For the purposes of shipping documentation, the wiki can be exported and we run it through a parser that "fancifies" the look and feel of the documentation for customer purposes.
Storing the documentation with the code (typically in your source repository) is not a bad idea. Just make sure to keep them separated. For example, keep a docs folder which is on the same level with your src folder in your repository. This way, you can quickly ship the current documentation, you can easily track revisions, and anybody new to the project can immediately jump in without having to go to multiple locations for information.
Storing it in source control is fine.
This is an interesting question -- basically, what others are saying is right about generated documentation, source files and templates/etc. should be stored in source control and generated during your build process.
As far as requirements/specs/etc. documentation, I have worked both ways, and I very much prefer using SharePoint or a Wiki/document portal that is designed for document sharing/versioning. The reason is, most non-developer folks aren't comfortable working with source control systems, and you don't gain any of the advantages of intelligent merging if you are using a binary format like Word. Plus it's nice to have internet-based access so you can reference and work on the docs in a distributed team without people having to install extra software.
Here's a 2017 summary of the options and my experience:
(extreme 1) Completely external (e.g. a wiki, Google Docs, LaTeX, MS Word, MS Onedrive)
People aren't bothered about keeping it up to date (half of them don't even know where to find the page that needs updating since it's so out of the trenches).
wiki platforms are “captive user interfaces” - your data gets stored in their proprietary schemas and is not easy to examine with a simple text editor (Confluence is even worse in that you have no access to the plaintext content at all anymore)
(extreme 2) Completely internal (e.g. javadoc)
pollutes the source code, and is usually too low level to be of any use. Well-written source code is still the best form of low level documentation.
However, I feel package-info.java files are underutilized.
(balance) Colocated documentation (e.g. README.md)
A good half way solution, with the benefits of version control. If a single README.md file is not enough, consider a doc/ folder. The only drawback of this I've seen is whether to source control helpful graphics (e.g. png files) and risk bloating the repo.
One interesting way to avoid this problem is to use plaintext diagram tools (I find Grapheasy and Text Diagram to be a breath of fresh air).
plaintext can be easily read even if your rendering engine changes as the years go by.
Github's success is in no small part thanks to its README.md located in the root of the project.
One tiny disadvantage of this approach though is that your continuous integration system will trigger a new build each time you make edits to the README.md file.
If you are writing versioned user documentation associated with each release of the product, then it makes sense to put the documentation in source control along with its associated product release.
If you are writing internal developer documentation, use automated internal source code documentation (javadoc, doxygen, .net annotations, etc) for source level documentation and a project wiki for design level documentation.
I think most of us in the industry are not really following best-practices and it of course also depends a lot on your situation.
In an agile environment where you would have a very iterative process of release, you will want to "travel light". In this particular case, Jason's suggestion of a separate Wiki really works great.
In a water-fall/big bang model, you will have a better opportunity to have a decent documentation update with each new release. Also you will need to clearly document what version of the requirements was agreed on and have loads of documentation for every tiny change you do to requirements (due to the effects it has on subsequent stages). Often if the documentation can live together with the version controlled source code it is the best.
Are you using any sort of auto-documentation or is it completely manual? Assuming that you are using an auto-documentation system, the documentation is more or less generated on the fly, and would be part of the code itself.
To me, (assuming that it's possible with whatever code you are using), this would be the preferred method of handling it, as you wouldn't need to maintain the documentation source at all.
I want to use Selection Service feature from the eclipse RCP in my swing project. Currently the o.e.ui.workbench bundle which contains the related interface is around 3.7 MB, that's way too huge for our requirement
Is there any way to split it the workbench to get only the selection service
Are there distros already for this
Is it leagal to do so. Are there any licencse issues?
It does not look like it would be that hard to do it yourself, and that's pretty much what you would have to do. I know of no distros that do this however.
It's certainly legal to do so; you can freely use or modify any part of Eclipse until the EPL. If you split it without modifications then you have no obligations under the license. However if you extend it (and redistribute your code), then you need to make available your code that extends it (which can be done using an Eclipse bug report for example).