Pro edition of Nexus shows the dependencies for an artifact...
Want to do the same in the Community edition. Doesn't look like the standard REST API:
https://repository.sonatype.org/nexus-core-documentation-plugin/core/docs/data_ns0.html
supplies a service for dependencies. Have googled for examples on creating plugins (not too charged about the Nexus documentation on plugins right now) and toying with the idea of creating a plugin (a REST based) that pulls out dependencies per artifact. Ideas?
From what I know Nexus basically downloads the pom.xml of the project you are interested and runs the list or tree goals of the maven dependency plugin and then just displays the results nicely.
You could of course do the same in your own custom plugin. You can also use the Aether API and others directly to do the dependency resolution in your plugin and not call the plugin externally and then show the results.. in fact Nexus might just be doing that.
Realistically writing this yourself that sounds like reinventing the wheel and I would just get a Pro license. Beyond that minimal feature, there are a LOT of other benefits to pro. Just give it a try.
Look at this "headless" plugin (plugin that offers services to other plugins, not having any functionality or UI on its own):
https://github.com/sonatype/nexus/tree/master/nexus/nexus-core-plugins/nexus-maven-bridge-plugin
Nexus uses pure Aether, not (whole) Maven - as Manfred says - to calculate the tree of dependencies.... again, just take a peek at that plugin above, it's there ;)
Related
Are there any tutorials for the development of aem6 components without crx?
If you prefer intellij with it's built in maven support, you can use IntelliVault
Well this is a broad topic. For a start you can read the following articles:
FileVault
A tool developed by Adobe that maps the content of a CRX/CQ instance to your file system.
IMHO it's more like for a small project because that approach is hardly applicable to continuous integration.
Eclipse + Maven provides ability to have an easily deliverable components package. Also many continuous integration tools are able to use Maven builder.
Several teams in our company use internal framework to build an Eclipse UI. This framework is composed of set of Eclipse plugins.
Our team is responsible for the develpment of this framework and we're looking for some tools that would check API breakage in the further versions of our framework.
For example, we have the following class:
package com.foo.A;
class A {
public void doSmth() {}
}
Currently in MANIFEST we and users of our plugins do not specify any versions of plugin's dependencies (always complining with the latest version).
We'd like to have some warnings from Eclipse if we change something in this class, e.g. change method signature or something else. We'd like Eclipse to suggest us to rise plugin's version in such cases.
I've read the following information about API tooling in Eclipse:
https://wiki.eclipse.org/PDE/API_Tools/User_Guide
But it seems to me that this tooling works only with Eclipse native plugins, but not with our custom developed ones.
If I'm mistaken, could anyone be so kind to explain me how to setup API tooling for our plugins?
the Eclipse API tooling works also with user bundles. What you should do is take your released framework and define it as baseline. A quick solution is to copy all your build and released to the public bundles in a folder and set the folder as Baseline:
Window - Preferences - Plug-in Development - API Baselines - [Add Baseline...]
You can have multiple Baselines if you have to patch older release versions of the framework for example. Be sure to set your API Errors/Warnings as you reqire them.
Edit: Of course you should enable API Tooling in all your bundles as described in "Configure Bundles for API Tooling" in the web page you linked!
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
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.