Sometimes an image created and put in some repository needs to have more than one tag. The most common case is when building on to tag it as latest. Or current. The GitHub actions by default tag it with the the short SHA of the commit that triggered the workflow. This is like the built image has its own ID whit which it can be addressed in later commands:
This is good ... in Github's own context. But in the lifecycle of the image it may exist in several other contexts (repository, deployment environment, automation scripts, etc.)
There are a few ways (command syntaxes). Probably the easiest way is to just list the image:tag pairs one after the other:
Yet, there is even simpler way: not to issue the tag command but to define the tags during build-time:
And this works fine.
Next the tags have to be pushed to the desired repository. I ensured (for myself) that pushing the same image with different tags doesn't create multiple copies of the same image but only adds the new tags to the same image (silly thought but the question appears at some point).
Another question was if a push command has to be issued for every single tag, or this can be done in one go. You know - to reduce traffic (sometimes images are +1GB) ...
I found the correct syntax for pushing multiple tags with a single command:
And it worked just fine in a local experiment.
The key (obviously) was to use the --all-tags option of the docker push command. It also has the reduced form -a.
Unfortunately this didn't work in the Github action, since the Docker version in the runner's environment doesn't recognize the said option:
This, of course, is a bit unpleasant but not a showstopper. The solution is to simply issue the command once per every tag. Which is another reason for striving to keep images smaller when possible.
Maybe I should try the same setup with podman sometime.
Recently I had to automate a GCP Cloud Run deployment on commits in a Github repository. In cases like that the default solution is to define a Github action. Well not exactly.
The Cloud native way
In the case of Google Cloud (I can't be detailed about the others) the Cloud Build is what's the closest to the execution environment. Using it utilizes the GCP's native containerization (Cloud Build's Docker runner), direct tagging and uploading to an Artifact Registry (formerly the Container Repository which was deprecated and is now retired) repository, and eventually that is the shortest path to Cloud Run itself.
Yet, the "cloud native" way is not always the right or the proper way.
In my case the Cloud Run application was a backend application the source for which resides in a monorepo along with the one for the accompanying frontend application. After a short research for my context I settled on the premise that the Cloud Build triggers can't distinguish if a commit comes solely for one of the applications and build and deploy everything possible in the repository tree (frontend, backend and whatever else Dockerized applications it finds in its repo scan). Not always convenient or necessary.
On the other hand the Github workflows can see not only branches but directory tree paths too. This was enough to tip the scales towards this solution - to build the application at it's source of truth and call the cloud operations from there to finish the job with deploying it (through the custom gcloud run deploy command).
Implementing the Action
For the basic case of building the application, authenticating with the Cloud, uploading the image and deploying it with the bare minimum of the said command there are more than enough tutorials. There are even readily available templates for the task in the Github's own workflows library.
There are also many video tutorials with different levels of complexity. I especially liked this one:
because of it's graceful pace and to the point, grounded explanations - nothing redundant. Kudos.
Yet, my case was just a bit more complex than the minimum deployments. And it's nothing that is special. I even think almost anyone's Cloud Run use case includes that - the environment variables and the secrets.
The slightly specific sub-case arises when one needs to pass a service account credentials to the container being deployed. In the above video there is an example of defining a secret that contains such credentials but in his case is for a different purpose. These credentials are the ones authenticating the Github action (basically a runner - container with Ubuntu OS by default) with the Google Cloud Infrastructure for invoking the image upload and eventually the deployment. But I was already past that step and had the problem with passing the contents of the said secret to the container being deployed.
I won't get into details why I didn't use Workload Identity Federation, or resorted to the Base64-encoding method, let's just say it wasn't entirely my decision - I had to deal with just passing the secret.
As for the secrets - they're basically the same with the main difference that one's no longer able to see their value anywhere on Github after creation.
When it comes to putting a Service Account in a secret there's a certain gotcha that must be complied with. Let's keep the following in mind:
In its essence a Service Account is a string in a JSON format that if kept as a local file is a multiline JSON document.
Github Secrets can take multiline values but preserve them in a single line string. How true is that can be arguable.
After long hours of frustration, chatbot circular hallucinations, short-lived moments of epiphany, and the mandatory existential dread I decided that I'll fight it off and make it actually work with the flags file method.
In short the method includes the additional step (prior to executing the deployment command) that defines a YAML file on the fly and fills it with the environment variables assigning them the values of the secrets. The syntax looks like this:
Once created the file is passed to the command with the --env-vars-file flag.
Looks easy and why it didn't work out of the box cost me the longest time to figure out. It has to do with how the secrets keep the multiline values.
The telltale sign of the problem if easily visible (if you know what to look for) here:
What is seen is the Github secret actually preserves the multiline JSON format if one assigns it this way on creation/update. From here on it is the gcloud run deploy command that can't work it out this way because it can't recognize it as a proper YAML syntax.
So what could I do? The common sense suggested that when deployed from the Cloud Console the Service Accounts being passed as variables or secrets never pose this problem.
So I refreshed all of the secrets' values with the ones taken directly from the Console (from the Edit screen but the fact that the variables are single lines can be seen also in the auto generated YAML of the deployment).
The result in the runner's log changed to:
At this point all of the secrets being single-line strings are written as such in the generated flags file in proper YAML syntax, hence the successfully executed deployment.
Take Out
The imposing conclusion has the following dimensions:
Keep it simple and if possible retain the whole process of the Github workflow to be visible on one page. The action and the flags file solution meet that requirement while the Base64 encoding and Workload Identity Federation methods although robust and proven in smaller use cases might be an overkill in terms of configuration and coding.
Always double check the values of your environment variables and secrets, AND when used with the flags file make sure the values are strictly one-liners, no matter what they hold.
And probably, as a rule of thumb, check as much as needed with the Cloud Console the alignment between the two points of deployment because sometimes drift happens and may cause other hard-to-debug problems.
Today I renamed the blog (from nbide to polystack) because the industry changed in a way that:
One language is already not enough.
One IDE is rarely enough.
One cloud provider is usually not entirely enough. And often it might not even be the right solution.
At first I wanted to keep it simple and repurpose the blog to be related to the programming languages I'm currently interested in but it's never that simple. The mentioned languages right now are:
Rust
Go
C (only C, and NOT C++ - that thing is not healthy)
Java (still)
Kotlin
Haskell
And since no language exists without its realm, purpose, and use cases some possible habitats and the various tooling can be involved in the narrative. That is for context and perspective. So things to be mentioned might include:
Cloud Providers (GCP, and Azure mostly)
Infrastructure (IaC) tools (Terraform, and Ansible mostly)
IDEs and Editors (NetBeans is always in my heart but I recognize that with time it get farther and farther from the best ones)
GitOps (GitLab mostly)
Linux - as a development environment and conainerization suitable distros
... the list can't be limited.
Also this might not be the only blog to cover these areas, and cross-posting might happen from time to time.
If you're still not aware of the current state of the IDE's governance, the first thing you see might surprise you - Oracle gave the IDE to the Apache Foundation. So from 9.0 version onward we'll have Apache NetBeans.
From the rest of the contents of the page you can see some of the interesting new features that come to support the latest additions in the 9th and 10th versions of the JDK. It's mostly some syntactic sugar (the var type declartation) and hints. The modular system is supported with GUI tools, as is the new Java Shell ... But don't take myword for it, just go and see for yourselves.
Currently the RC1 is available, so I hope we'll have the final version within a month.
In a previous post I promised to make a review for a book about JBoss AS 7. At that time I still didn't dig into it, and didn't know that our latest NetBeans IDE (7.1) still does not support the seventh generation of JBoss servers. You may see some informative rant going on here. And to be clear - hacking to simulate support thanks to the configurations of the 5-th or 6-th versions wouldn't help. JBoss 7 is completely redesigned to be modular. So the default support (unsurprisingly) comes from the rival - eclipse ;)
While we're waiting you may actually read the book, because it is a good one. If you need first to read the review, it is here on my other blog.
My recent experimentation with the cloud service took me to a revelation that says: "Well you should've known better!" At least I should be more careful setting up my system. Especially when being aware of the nature of things, but still let myself be sloppy. It cost me some precious time and puzzled, achy head, but at the end the situation is already crystal clear to me. I was trying to run NetBeans with portable JDK - both tools in the DropBox folder. It constantly refused to run saying it couldn't find a proper JDK. At some point I decided to go with absolute paths in the netbeans.conf file. I did it very simply by defining in all my environments the variable $DROPBOX_BASE (with the actual corresponding value for every system of course). No more misty relative paths. Still I didn't have success running the IDE. Hmm! These days I'm experimenting with the new JBoss AS 7. Well taking the same approach there, the result that followedis obvious - the JBoss complained that it can not find a proper JDK unless I show it its position on the system with the --jdkhome command line option. Getting the same result after using the option in question, puzzled me the most. But it didn't take long until I realized that something wrong should be happening with some executable bits. Again some time and googling passed until I remembered that on the current (Linux) system I placed the Dropbox folder on NTFS partition, which was never even designed for the idea of executable bits being set as permissions. So, my conclusion: when using DropBox on Linux, never set its folder on partitions designed for Windows OSes. You might still sync properly, but successfully executing binaries from it is very unlikely. Touché!
The official announcement came almost a week ago and for me it almost coincided with another event. The guys from PACKT Publishing gave me the chance to review another one of their books.
First about the IDE:
May be the release notes would be more informative than the official announcement. At least it contains all the possible links you might need along with the latest top features presented visually. Of course there is this video presentation, which is worth watching.
It seems this time the focus is on JavaFX. Its 2.0 version is covered in a way that makes its applications' configuration and deployment easy and complete - it seems you won't miss a feature here.
From the other features presented in the video the most attractive seemed the visual debugger, the batch and selective rectangular re-factoring and the enhanced maven integration.
Once I have more time to make some stuff with it, I'll report. Which leads me to the second point - the book:
Going through this book is a nice opportunity to check the new architecture of the revamped JBoss Application Server. I guess (and hope) it will have some in-depth tweaks. Scrolling over its TOC increased my appetite seeing topics like clustering, security and cloud leveraging. I'm anxious to start it, so I'll say no more in this post.
To continue from the last two posts and driven by curiosity, I decided to see if a DropBoxed GlassFish application server (along with its built in JavaDB database) will be able to complement the dropboxed NetBeans IDE I already use on three Linux systems.
As a little detour I must state that these Linux systems are such that I have complete access over them. If I had to work in a more mixed environment (e.g. in Windows or in any system without administrative privileges), I would still use OS independent packages, but I would use a USB flash drive as a carrier. It doesn't seem appropriate for one to utilize the service on a machine that is publicly shared. It comes to my mind that going hardcore, could make you try to install a DropBox on the system in question (whether I doubt it is possible without administrative privileges) and as synchronized folder to use one on a flash drive. But I have the impression that, at least currently, the DropBox service is not intended for such loose usage.
So! GlassFish. OS independent ZIP archive. Extracting it somewhere under the DropBox root folder completes its installation. It takes some minutes (or maybe hour, or two) to propagate, but as usual, this has never been a concern.
Now - configuring and running seem to be more interesting. Adding the server in NetBeans under the "Servers" node is nothing special. You just point to the installation directory, where the ZIP was extracted. If you need to, specify a custom domain different from the default domain1 and that's it. NetBeans knows all the rest. If you start it from its node with the context menu, in a few seconds, you'll be able to access it in a browser. Of course it still needs certain configurations, so that not everybody has access to the administration console on port 4848, etc.
One good way to test the installation is to test it against the Quick Start Guide. If we say that the installation directory for the server is marked GF, the guide in question is the file:
GF/glassfish/docs/quickstart.html
It opens in a browser and explains with examples, what commands can be issued in the command line in order to make the administration tool do the right job for you. The tool is called asadmin and it starts the desired domain (or simply the default) and the database. In Linux the absolute and the relative paths should work the same way.
Another good testing method is to run through some tutorial, and what would be better than this one.
While taking it, it is interesting to observe what's going on in your DropBox. May be the most beautiful part is that the both entities - the syncing service and the development stack - just work. The development stack behaves like it exists in a usual file system, like it actually is. The service rapidly synchronizes the bunch of small files that are created and/or modified during the development process - changing configuration files, writing to log files, deploying the different types of Java archives to the domain sub-folders of the server, etc.
Opening your "Events" page on the DropBoxweb site you'll see something like this:
This of course is not the full list, but as you can see the more details are easily accessible by clicking the appropriate link:
I read some time ago a question on StackOverflow that someone had trouble running the JavaDB database after installing the GalssFish server in his DropBox folder. All I can say is that it worked in my set of environments from the command line. But just because NetBeans is good enough to manage a development environment on its own, I use it for the same purpose. Registering the application server with the IDE is the only required step - as a consequence it manages the built-in database pretty well. And after running the examples from the FirstCup tutorial on one of my machines, I could very easily review exactly the same data on every other machine registered with the syncing service:
I heard some categorizations that DropBox is a "cloud service". I don't know if this is a fair comparison, because cloud computing although becoming better and better defined every day, still has some vague boundaries. Despite that the feeling when working with my mirrored and aptly synchronized small-project-sized-single-user-development-environment is like I have one computer everywhere I go. I guess at least this is what the Coluds are trying to achieve. So if we're already there, there's nothing left but to wait and see what will be the next challenge.
So, NetBeans stack (with servers) portable through DropBox - sounds quite possible. After all PortableApps can be used this way. But what's to consider first? Here's the list (it's not long at all):
Will the free account's box size suffice? Yes, it will, even for a full install (with the two app servers). And I guess there'll be a little bit more space for some small projects, etc.
What if utilize multiple platforms (Windows at work, Linux at home, and Mac on the move)? Well fortunately the IDE still has the "OS independent Zip" on the download page, but as you can see there, this option comes without the servers. The servers are completely different story, for another post.
And should I put the JDK also in the DropBox? If so, should it also be platform independent? Hm, friend, this is Java you know! And I think, we've already been through this :)
Maybe these are all of the preliminary considerations, so I dive in ....
Downloaded the OS independent ZIP for the latest (currently 7.0.1) version (242 MB archived, and around 470 MB extracted to a DropBox sub-folder). With my connection, it uploaded to the central server for around half an hour.
For further examinations lets name the path to the DropBox folder as DB. So if the IDE is extracted to DB/netbeans, the adventure starts from the DB/netbeans/bin folder (I believe you can easily figure out the corresponding Windows paths). In this folder there are only two files - the executables for the two major platforms. Since the IDE is configured by default to search for the java installation existing on the system, if such exists, the IDE will run. If only JRE is installed, it might run, but it surely won't compile your projects and it will complain about it. Of course, the access to a java installation can be configured, but I don't think there is a point in repeating myself. Everything said in that post still applies.
I would only add that if you use a portable JDK, you might tweak it, to make it slimmer. This means that bin, jre and lib folders will suffice. Another detail is that you might have to gather the executable files from different platforms in their corresponding sub-folders in order to be fully portable. Actually it is all a matter of taste and context. All environments that I have DropBox on are Linux, so I don't need portable JDK. In that case I only have to take care that on every environment I use compatible JDKs. For example if on Env1 I have installed JDK 1.7, the Env2 which has by default (from repositories) JDK 1.6 the projects might become in conflicted state. This might not happen for different updates of the same version of the JDK, but for a different versions of used application servers the conflict is certain. So the journey continues.
I don't know how close, but this installment looks to me similar to an IDE on the cloud. I accept every suggestion that might reduce the distance between the reality and the idea.
Few months ago I found DropBox. I almost immediately started using it as holder of some sample NetBeans projects. Its seamless integration with the host OS and immediate synchronising of the project files amazed me. These guys have done a wonderful job. I know they are being criticised about security and privacy matters, but if you get to become paranoid about your sensitive data why use Internet at all?
At first I didn't think of it as a variant of portability - actually portable are only your projects, and not the IDE. This in fact is more similar to a very simplified one-user-version-control. And for small projects I guess I would be happy with it. I would call it cloud portability, but it still would be about the projects.
And there's the idea - what if I installed the IDE in my DropBox folder? There are few drawbacks that come into my mind:
It would take up most of my original 2 GB quota. This is not the greatest concern - I could invite some friends or at some point I even can go for a paid account.
Performance. May be this is the biggest (as usual) concern. But since the IDE is copied on every HDD I installed DropBox on, it will be ran form a hard drive and not from a flash drive. This leads me to the next concern.
Synchronised environments. In order for the IDE to work at all I'll have to use the same classpaths for the JVM and the libraries. And may be at some point even for any servers. I know your next question - why not install everything in the DropBox folder? It seems tempting. Something bothers me here. I'm not very sure what exactly it is, but I'll figure it soon. May be the best way to find out is to just do the thing and watch it how it moves.
One thing is certain - installing the IDE will be as slow as your bandwidth. I mean, not installing it on the local hard drive, but sending it to your other PCs. Well this is not a real worry - DropBox does the transfer, not you. And if your remote PC is online, once you get there you'll might already have the IDE on it.
I'm kind of tempted to do it, but may be after some more considerations.
I am an occasional blogger. So here is the occasion. A big one. Actually there are three interconnected events:
Oracle finally released the latest (7th) version of the standard edition variant of the prominent Java programming language's SDK. The tech related part of the web is all boiling with the fuss. Use it! Don't use it! There are severe bugs in the JVM. There's nothing scary about the bugs - they'll be fixed before the JVM is adopted in production. The new syntax enhancements are great. There's not enough new features to the language. Etc., etc., etc. It's always been and will always be a work in progress - there'll always be hideous bugs lurking in the code invisible, until the rarest never-met-before conditions bring them to the light. It's OK. Bugs, features, fallacies - its' all part of producing software. Any kind of software. Even great meta-software like Java. Since the engine is here, where's the new chassis so we can utilize it for a nice smooth software development drive? Here it comes.
Oracle released the 7th version of the NetBeans IDE some time before the official release of the Java SE 7 SDK, so after the first event on the list, they had to release the NetBeans 7.0.1 with the required official support. Game on! The IDE is ready for download you very well know where from. I wish it was available in the Ubuntu repositories also, but I don't think this will be an option soon.
A book. You didn't expect this, right? In fact it is a very nice book about how the IDE eases the development of Java 6 Enterprise applications. I won't tell more about it right now, because I'm in process of going through it, in order to make a full review. So, with no more distractions, I'm diving back to Mr. Heffelfinger's thoughtfully organized and narrated set of screen-shots. Here's the cover to just whet your appetite:
All the three events are pretty significant for the NetBeans users. The tool of the trade was upgraded and on the other hand there is a concise source of some background information for the developers.
I already published two almost identical reviews at Developer Zone and Amazon. I feel it is clear what are the purpose and the structure of Java EE 6 Development with NetBeans 7. The reasons for why I like it are not just that I needed such reference for a long time and it finally showed up. I liked it because it is straight to the point. Promptly teaches you what you need to do, with further details where possible and reveals the technology gradually and remarkably fully for the given small amount of pages.
So in the sake of diversity, completeness and to give the book the coverage it deserves, I'll pay a bit more attention to its contents.
The introductory chapters
The first three chapters might be considered as legacy. I mean, they are there in favor of the complete beginners. On the other hand most of the functions represented here can be found in the same or similar form through the previous versions of the IDE. Those are the features that define the NetBeans way - the keys for simplicity, speed and robustness during your development process.
First we're introduced with the IDE. From installing it to adding and managing application and database servers - it is all a fundamental knowledge. Even if you only create desktop applications the chances are rather small, that you'll never have to work with database. This knowledge is just amust precondition.
After that a similar thing is done for Java EE and how it is backed by the IDE. If the reader is not a bit more familiar with Servlets, JSPs, configuring the security, etc. this introduction can't be enough. Here you'll see presented the ready templates and configuration-tweaking editors that require such basic knowledge.
Finally we're given the tag palettes. They are organised around the forms in the applications' pages. NetBeans gives us automation for the HTML tags that require most effort when written by hand, and for some of the JSTL tags.
The nicest example I found here is a small tutorial on how to create custom JSP tags - sometimes the wide JSTL extension over HTML still might not be enough functional or flexible.
The basics of the Enterprise Java
In the following two chapters we meet the newer wave in the Java EE history - the Java Sever Faces (JSF) framework over the core Servelt and JSP APIs and a complementary component library - PrimeFaces.
Since every chapter in the book can be taken as a separate tutorial for creating a certain technology-centered throw-away application, these two chapters are visually oriented. In terms of the MVC design pattern here we're shown how to create the View. The JSF API is backed up by lots of wizards - managed beans, facelets, components, etc. Do you think this is enough? Well, NetBeans don't. They provide the PrimeFaces components integration, so with the help of fast code-completion very decently looking pages can be built that could have tabbed layout, or to behave like wizards. Of course I wish there was at least a plugin that could bring the tags in their own palette, but I guess this integration is in an early stage.
The core innovations to Java EE 6
In the previous version of the SDK, the Enterprise Java Beans (EJB) API consisted of three types of Enterprise Beans - entity beans, session beans and message-driven beans. With the API's evolution, the first ones were extracted to their own specification comprising the Java Persistence API (JPA). Another new feature covered is the Contexts and Dependency Injection (CDI) - long awaited, after all it is one of the things that made the Spring framework so famous.
To the Enterprise Beans and CDI's integration are dedicated the next four chapters of the book. The one for JPA is my favorite tutorial, because it shows not only the power of the IDE to automate the creation of data components. It gives a whole MVC application - JSF application extracted from the paired database. The rest of these chapters concentrate on the business tire in an enterprise application. We see how easily can be created modules and clients, message resources, qualifiers and stereotypes. Everything is there after a few clicks in the file wizard, smartly coded templates ready for customization.
Java EE 6 and the Open Web
The web services are left for the last two chapters. The classic SOAP services, using heavy XML for data transfer versus the modern RESTful services that utilize the lighter JSON data format. Both are equally and very well covered. To the point that NetBeans has a nice graphical editor for configuring the parameters of a service.
As examples we can see a SOAP web service created from existing EJB module and from ready WSDL file, and RESTful web service created from existing database. The last one also has a client created for it.
The Appendixes
I cannot imagine developing some application without debugging some of its trickier methods at a point. Doing it for an enterprise application is generally a bit more difficult, regarding the external execution environment - the server. NetBeans proves such difficulty does not exist.
I must admit that the Profiler is the NetBeans's prominent performance tool that I never had a chance to use in working conditions. Yet having it in the IDE for such a long time (if memory doesn't fool me, after version 5.5 it became integrated, instead of being a separate plugin) is a persuasive argument towards its quality.
Like I said in the external reviews, code templates customization and the possibility for adding custom palettes, deserved at least another appendix, but after all this is a Java-EE-6-centric book, and NetBeans is just the tool. Anyway, I personally like very much the way this book gives credit to the IDE, to its grade of integration with the SDK. The plethora of examples might comprise only to throw-away applications, but they are so technology-aware that throwing-away option easily might be transformed to merging-and-extending option. Have fun!
I'm using my portable NetBeans 6.8 IDE with all my projects set up on the same flash drive. However when I was making the portable installation something slipped my attention, and here is the fix.
Some days ago I was reviewing one of the Patrick Keegan's JavaDB tutorials on a Windows laptop. Made the example and tweaked it a little but didn't go further about how the JavaDB drivers are set up - I taught that they're somewhere in the debris of the netbeans folder like MySQL's and PostgreSQL's drivers. After that I forgot about this example and the other day when I tried to open the same project in NetBeans IDE installed on an Ubuntu PC I got the warning sign for a reference problem. The IDE usually gives this one when a library is missing from the paths declared to the project. I opened the "Resolve Reference Problem" dialog from the context menu and only the derby.jar was listed in it. Didn't have time to fix it then but today decided to dig into it.
In the IDE when I went to "Tools > Libraries" I found such for MySQL and PostgreSQL, but there was none for JavaDB. So I went to Services window and opened the Drivers node in order to see in the properties where the drivers were pointed to. This is what I found:
So I needed to do a fresh and prferrably portable JavaDB installation in order to fix this issue. Since I wanted it portable, I couldn't use the MSI installer for Windows - the installer actually couldn't see my portable device (unless you write it manually instead of using the Browse button) even though it lets you change the installation path. To spare myself time and possible troubles, I chose the platform independent ZIP archive package. I extracted it directly into the root of my flash drive and in the IDE's Service window customized the drivers' nodes to point in the right directions (the JARs are located in the lib folder of the package). The same approach can be taken in a Linux/UNIX environments.
Now I could resolve the reference problem.
And after making sure the project runs and has DB capabilities I can say that today my IDE is yet again a little further more portable than before.
I just said few words about Dzone's cheat sheets regarding NetBeans in my last post and they came with a new one. This time the refcard numbered 80 tells in short about the NetBeans Platform. It briefs about the massive structure upon the IDE is built up and is suitable for constructing full-blown and feature rich desktop and client applications.
This matter is the foundation for building the IDE's plugins and modules. If you wonder what's the difference, the simplest explanation is that:
a plugin is the piece of software unit that can be uniformly added to the IDE in order to perform some specialized task. Depending on the task, the plugin might range in simplicity and size.
a module is an independent package of software that ties to the platform in such uniform way that makes it a separate software product. Modules might be targeted at enhancing the IDE's functionality or they just might run free ;)
This area sure is targeted at the hardcore developers and professionals, but some of the novices might also be interested what actually lies under the hood. Well done DZone!
Do you know DZone? Of course you do! This gathering place for developers from all over that hosts the well-known RefCardz. And the newest one is a very relevant and on-time update of an older one. Generally a version is skipped and we have refcardz for NetBeans 6.1 and 6.8. This is not such a big deal since the most present is also the most relevant. And the most present is already here. Enjoy!
I bring up the theme of portability once again, because of the last comment from this my post. Thanks on this Valery! I really missed this one before.
Let us start with the obvious - Java is by default a portable language. So any software written in it, if not making any assumptions for the host operating system or utilizing platform specific features, should without changes run anywhere. Although the NetBeans IDE is developed with several OSes in mind, it also has such platform-independent version:
As can be seen, the most complete bundle for the current version (6.8) lacks the JavaFX IDE and the application servers, but has everything else.
Download, unzip to the USB drive (lets say we have K:\netbeans folder as a result) and this is where the fun begins.
In the K:\netbeans\bin folder there are two files - a Windows executable, and a shell script for the UNIX family OSes. All is the way it should be.
Running the netbeans.exe on different PCs shows that the IDE feels pretty comfortable anywhere. It even isn't as slow as I expected! The only "drawback" is that it makes itself at home everywhere. This means that it scans the local $HOME directory and arranges its properties there. It even suggests you to import the setting of a previous version if such has existed on the machine. I'm still not sure how this gets along with installing your preferred plugins on the PC and then using them on another PC. But I wouldn't rely on such IDE scattered across several computers. I just would take the steps necessary to make it more portable. The step is generally one and it is toward editing the K:\netbeans\etc\netbeans.conf file. This configuration file is pretty self explanatory but lets take a look just in case.
The first property is netbeans_default_userdir. Its default value is "${HOME}/.netbeans/6.8". At first I replaced it with:
"${HOME}/.netbeans/6.8" -> "../.netbeans/6.8"
and ... nothing actually happened. In such cases running the executable makes things a bit more clear and ... it did:
It appears that the NetBeans IDE doesn't let you place its configuration and properties directory into its installation directory. That makes sense if think about it. So pick some place on your USB drive dedicated to configuration stuff and point to it in the netbeans.conf file. In the end I have my specific properties in K:\data\.netbeans\6.8 and it works fine with the property value set to:
The second property is netbeans_default_options. Its default value tunes up the JVM that runs the IDE with several parameters. They are not directly relevant to the portability. They are more of a performance tweaks.
All the other properties are commented, hence not taken into account by the IDE. Here's what they mean:
netbeans_jdkhome - this one is important and it should be uncommented in all cases where on the host OS there is no any Java installed. It also must be uncommented for the sake of portability. In my case I have this path K:\jdk\jdk1.6.0_16. I could put it in the K:\netbeans folder but I also use portable eclipse in some cases, so the JDK is kind of shared between the two IDEs (and any Java dependent software I decide to use on my USB drive in future). The value for the property becomes "../../jdk/jdk1.6.0_16" (that makes two folder up in the tree).
netbeans_extraclusters - this is related to modules that come separated from the official bundles. For example you've made your own C# editor on top of the NetBeans platform and you want to use it in your portable IDE. This is where you set the relationship between both.
Well, if I have some conclusion to make, it would be that if the intricacies of the host operating system are not concerned, the portability is only a matter of correctly setting the paths, whatever your portable media is.
So far we've exhausted the current portability issue, wright? Wrong! What about UNIX/Linux? And what about WINE? Soon.
Преди около час NetBeans обявиха в Twitter (10.12.2009), че официалното издание на версия 6.8 вече е налично за сваляне.
Чудя се има ли връзка, между забавянето на 7-та версия с постоянно бавещата се също 7-ма версия на Java.
На официалния сайт са се постарали да представят новостите в средата чрез комплект от тематични видео-та, което би било интересно не само за начинаещите.
Това, което ми направи впечатление относно наличността на средата е, че вече не може да се поръча безплатното ДВД. Може да се свали ISO файла му, но той е все още за версия 6.7.1 - е явно не може всичко да се свърши наведнъж. Друг вариант е закупуването на въпросното през онлайн магазина на SUN срещу само $8.50.
Ами честито! За новостите отвътре ще поговорим мако по-нататък.
Ето, че повече от седмица измина откакто излезе новата версия (6.7) на любимото IDE и вече е време за малко впечатления. Не съм се ровил надълбоко, но новости могат да се открият и на повърхността - при изпълнение на тривиални задачи, като създаването на нов проект например. Ще спомена само какво ми се наби на очи при бърз поглед върху средата. При създаване на нов проект, първоначално всички категории са дезактивирани. Това означава, че преди не е работено по проект от тази категория и за да се активиря тя, просто се натиска бутона за следващата стъпка. Според мен това е новост свързана с платформата, която има общо с повишена ефективнаост при използване на паметта. Друга видима разлика е вкарване на поддръжката на maven проектите в ядрото (вместо да се тегли като плъгин) , като заедно с това тук е разширен и списъка с категориите:
Още нещо, което от скоро е хит сред разработчиците в общността - Project KENAI. Това е поддържана от (все още) SUN Microsystems услуга за взаимопомощ между разработчици и подслоняване на проекти (друга аналогична инициатива е Google Code). Интеграцията с NetBeans прави използването на услугата естествена част от процеса на разработка. Може да се намери в собствено подменю в менюто "Team". Трябва да се отбележи, че версия на средата за новата версия на JavaFX (1.2) ще се появи малко по-късно като добавка, поради закъснение при хората от JavaFX. За сега толкова. В очакване на седмата версия, скоро може заедно да хвърлим едно око на платформата на IDE-то, като отворим капака и надзърнем в непрекъснато развиващото се API.
Всеки ден откривам нови малки нещица, които придават цвят и вкус на работата с любимото IDE. Например до сега не бях обърнал внимание на тази екстра, която дойде по Twitter. Екран на който няма нищо друго освен NetBeans. Може да е задушаващо за някои, но лично за мен е точно обратното. Често когато съм писaл код съм имал чувството, че екрана не ми стига и съм изпитвал неистово желание да увелича прозореца на редактора дори отвъд границите на екрана. Е сега вече съм още малко по-близо до желаното.
The biggest news of these days is the acquisition of SUN Microsystems by the ORACLE Corporation. I felt a little chill creeping down my spine. I hope it's just from the colder weather today. I hope for the best for NetBeans, but it all soon will be revealed.
And now for the homies:
Няма как да не сте чули вече новината - за добро или за зло Оракула вече ще се разпорежда с нашето IDE. Дано всички страхове да са само илюзорни.
Междувременно има и някои добри новини. Особено ако се интересувате от JavaFX. За българските почитатели на новата технология ще обърна внимание на това ново местенце в системата, където ще можете да научавате доста интересни нови трикове. Пожелавам успех на колегата и при възможност ще помагам ;)
