I have created a library of widgets that export to a jar and reuse in several other projects. In my library, I depend on a few other jars in my war/WEB-INF/lib. The problem is that when I use my library in another project the dependencies of the library do not get carried over so I have to add those jars to the classpath and inherit them in the project as well. There has got to be a better way to handle the dependencies, do I need to use maven or is there another practice that works?
Yes, if you don't want to manually manage your dependencies you will have to use a dependency management system. The 3 big ones are Maven, Ivy, and Gradle. I have included links below so you can read about them. A quick search will reveal the pros/cons of each from the community and also information about alternative dependency management systems. There are quite a few out there.
Apache Maven
Apache Ivy
Gradle
Related
I recently used the Library Manager in Netbeans (8.2, on Windows 10) to add a library, as show below:
However, in most guides I find online, in order to actually add the library to the project, I should do the following:
Right click the project -> Select the Libraries tab -> .... further steps ....
However, I haven't even been able to make it past the second step: the Libraries tab simply does not exist on my project properties, as seen below: Is this because the structure for a Vaadin web app project is so different from other Netbeans projects? Any advice would be appreciated
tl;dr
Don’t.
Do not configure libraries manually for your Vaadin project.
Instead, create a new Vaadin project using the template of a Maven archetype provided by the Vaadin Ltd company. Locate and edit the new project’s POM.xml file to list the libraries you need Maven to automatically download and install.
For Vaadin Framework (Vaadin 8), see:
Using Vaadin with Maven
Overview of Maven Archetypes
Maven
Usually Vaadin projects are configured using the Apache Maven tool.
Maven is quite popular across all kinds of Java projects. All three major IDEs (NetBeans, IntelliJ, Eclipse) support Maven-driven projects as an alternative to their own particular project definition system.
Maven has two purposes:
Configure the project parts and define a series of events for the compile-and-build process. You can create a new project pre-configured this way by starting with a Maven archetype (a project template).
Manage “dependencies”. This means you tell Maven what libraries your project needs. Maven then reaches out over the Internet to access a Maven-oriented repository of known libraries. Maven downloads your needed library from that repository, placing it in an appropriate place within your project. Tip: Be patient the first time you do this as Maven builds a local cache of the repository’s database, taking several minutes or more.
You specify both the project-build configuration and your list of desired libraries (“dependencies”) in one or more POM.xml files.
Using Maven eliminates the need to place libraries manually as you are attempting to do. No need to touch the NetBeans Library Manager. Indeed, I believe manually configuring libraries will conflict with Maven, with troubled results.
Using Maven is annoying at first, having to learn the lingo and the concepts. But once you are orientated, Maven does save you time and trouble, and makes your developer life easier. One big benefit: Maven makes switching between the 3 main IDEs much easier since you don’t have to learn about each one’s own idiosyncratic project-build-system.
I recommend you take a few hours to learn the basics. You’ll find many introductions and tutorials on Maven.
The Vaadin Ltd company provides a few good Maven archetypes for a new Vaadin project.
vaadin-archetype-applicationOne is a simpler structure, good for learning Vaadin and also good if building a simple small app.
vaadin-archetype-application-multimoduleAnother archetype is a “multi-module” Maven archetype, good for more serious Vaadin apps. One major feature is that your backend logic such as database-access can be separated from your user-interface logic, each in separate modules. You should definitely start with the simple archetype first. Don’t touch the multi-module archetype until you are comfortable with both Vaadin and Maven (unless you have the guidance of a helpful colleague who is a Maven maven).
By the way, Vaadin development in previous years virtually required the use of a Vaadin-savvy plugin that you would have to install into your IDE. Such a plug-in is no longer needed, now supplanted by Maven. You can ignore old outmoded guides to Vaadin that talk about an IDE plug-in for Vaadin.
Note: This entire Answer applies to Vaadin 8 (Vaadin Framework) specifically, and probably Vaadin 7 (as I recall). Vaadin 10 (Vaadin Flow) is a new ballgame, and I am not yet familiar with the situation there.
I've been beating my head against a wall for about 6 months now and have not found a concise way of understanding the mechanism for developing an eclipse plugin with third-party resources.
We are attempting to develop an Eclipse ODA to ride on top of in-house Spring-based code that accesses a REST based info set.
In broad strokes - this is what I feel that we need to be able to do:
Augment our maven artifacts with Eclipse bundle information using tycho or a the felix bundle plugin.
Set up a plugin project through Eclipse for the ODA Implementation & UI.
Have Tycho generate the poms etc for the plugin.
Now here's where I get muddy. I understand that there are two approaches
Manifest-First - which is the standard mechanism for defining a plugin's dependencies
POM-First - which provides dependencies via Maven's resolution mechanisms.
I'm not entirely sure where to begin trying to start doing this as I've never worked on developing an eclipse plugin.
One of the other questions I have is, how does a developer of an eclipse plugin (maven aside) leverage already existing third-party code (i.e. Apache HttpClient 4.x)? Do they have to download the jars, dump them into a directory within the project, add to classpath, then go from there or is there a "repository" mechanism similar to what is used with ivy, maven, gradle?
Thanks in advance and I apologize if I was rambling a bit with that.
Disclaimer: Your question is very broad, so it is impossible to answer it completely. Still, I can give you some hints so that you know what to search for.
In the Eclipse universe, the primary source for libraries (in the sense of binary dependencies) are p2 repositories. However, since p2 repositories are rarely used outside of the Eclipse context, you won't e.g. find a p2 repository on the Apache HTTP Client project's download page.
To account for this problem, there is the Eclipse Orbit Project which provides libraries used by Eclipse projects in p2 repositories.
If you can't find the library or library version in the Eclipse Orbit, you may also be able to use the libraries from Maven repositories. This is for example supported by Tycho via the pomDependencies=consider mechanism.
Note however that Eclipse plug-ins can only depend on libraries which are OSGi bundles. So if the library in the Maven repository is not yet an OSGi bundle, you need to convert it to an OSGi bundle first, e.g. with the maven-bundle-plugin and the Embed-Dependency mechanism.
The best way for an Eclipse plugin to consume libraries is as OSGi bundles. You just install those bundles into your target platform and reference them in the same way as eclipse.org plugins. Some of the library providers already offer their libraries as OSGi bundles. Absent that, you can typically turn a plain library jar into an OSGi bundle simply by adding a few manifest entries.
Depending on the build system you use and whether the libraries you need are available as OSGi bundles packaged into an online p2 repository, you can reference the URL and rely on your build to download and install the bundle.
If question of choosing a build system for Eclipse plugins with dependencies is still relevant:
Today I released new gradle plugin: Wuff version 0.0.1, which (I think) completely solves the problem. It allows to build Eclipse bundles and applications as they would be "normal" Gradle projects. All OSGi woodoo is auto-generated (although customizable). All dependencies are usual maven dependencies - regardless of whether dependency is OSGi or "normal" library.
Sources and doc: https://github.com/akhikhl/wuff
I'm asking about the approach to deal with Shared Libraries In maven project
Currently we are working on many Java EE projects, having some internal-developed shared libraries (Wars) installed on Weblogic application server
Is it bad approach to add those shared libraries to the project through eclipse class-path as we are working on eclipse IDE, if so what is the best practice for this?
Well, since you are using Maven, you should just be able to turn these shared WAR files into Maven artefacts, and add them as dependencies to your main WAR file.
Since you won't want to put those WAR files into a public repository, and you don't want to build them yourself, you need a group-level or organization-level Maven repository in which shared libraries and other useful things can be stored. (We use Artifactory ... but there are other products that fill the same niche.)
I think install archiva in your company network and deploy all war/jar that. See Maven Deploy Plugin documentation for details. Use that repository as one of repositories.
See Maven Repository Manager Feature Matrix for comparison.
The eclipse plugin development environment is a pretty handy tool when creating from scratch a set of OSGi bundles that need to work together. Particularly this is true when trying to get all the package imports and exports and other manifest fluff right during development, or if there are third party jars that need to be embedded. But trying to retrofit a maven build process around this afterwards seems to be pretty tricky, mainly because most of the maven plugins for bundling/OSGi build the manifest themselves, whereas using the PDE, you are handcrafting the manifest.
What is the best way to retrofit a maven build process to a bunde/set of bundles, that dont respect the standard maven project layout, and already have handcrafted manifests?
Use Tycho. It lacks some documentation, but it does just that: builds the plugins using the PDE semantics (actually, it uses PDE compiler internally). So, all you need is to create almost empty pom.xml's for your modules.
I was trying to start new swing application using maven,
so I started searching on maven documentation but (frustratingly) found no clue. So I'm asking:
what is the archetype used?
what are the dependencies?
how to build swing app in maven [is there is plugin to do so]?
what is the archetype used?
A swing application is a standard JAR so just use the standard archetype:
mvn archetype:generate -DgroupId=com.mycompany.app \
-DartifactId=myswingapp \
-Dversion=1.0-SNAPSHOT
what are the dependencies?
If you plan to use the standard Swing API only, there aren't no extra dependencies to declare. But if you want to use things like JGoodies, MiGLayout, SwingX, Flamingo, SwingFX etc then you'll have to add the appropriate artifacts and repositories. But there is no universal answer to your question.
how to build swing app in maven [is there is plugin to do so ]?
A Swing app is not really particular. I would maybe just consider using Java Web Start (and the Maven Webstart plugin) or maybe a cross platform installer like IzPack (and the Maven IzPack Plugin). But you have time for that, you need an application before :)
Basically, if you are only using Swing (I mean if you do not want additional features such as SwingX for example), then you will not need to add specific information in your pom.xml file, as everything needed for Swing development is already embedded in the JDK.
Concerning the build process, there is also nothing specific additions here. However, you may need be interesed in:
Creating an executable JAR.
Making a big JAR, that also contains all the dependencies.
Check these links if you have problems finding documentation about maven Better builds with Maven and Maven: The Definitive Guide. Then you will figure out that you can build any kind of app like swing using maven. Maven is not a framework is project management and comprehension tool.
Note: Maven: The Definitive Guide was split into two books. The link goes to the blog post that links to both of them.