I have a mule application where I have added the external jar files as dependencies and invoking java classes. Now I am working on a different application where I need to use the same external jar files as dependency.
Is there a way I could reuse the first application(with java code) in the second one without added the external jars again as dependencies?
Thanks in advance
You should not add the Mule application as a dependency if you only need to use the Jar files for the Java libraries. Just add the dependencies for the Java libraries to the second application.
If you want to reuse the dependency in an onprem Mule deployment you can add it to a common Mule domain.
Related
I would like to build a custom component and share it with my team. I don't want to online upload the new component. Is there an offline way to share components?
I can define my github account instead of Mule's when creating a project. Will then it be private?
Adding details:
I created jars which I want to use in my Mule project. I added 2 Java classes in my project that uses the jars. I also have 3 apps on different computers that needs the jars.
Instead of duplicating these jars and the Java code, I would like to wrap it in a component/ connector and share the component between apps/developers in my team. As far as I understood from reading I can use both connector and component for my needs. However, I couldn't understand how can I share offline what I built.
The best option is to Maven-deploy your common JARs to a private Maven repository. This can be a simple as an S3 bucket or as refined as Nexus server.
This way, your different Mule projects will be able to pull these common JARs in their builds by simply adding them to their pom.xml files.
I am using the Jersey Test Framework, that includes servlet-api 2.5 in the test scope. Unfortunately, I have also written my own custom filter that requires me to have access to servlet-api at compile time. I don't want to elevate the scope to "compile" though, because I still don't want it in the war file. Is there any hope?
It is supposed to just work. To quote the reference:
This is much like compile, but
indicates you expect the JDK or a
container to provide the dependency at
runtime. For example, when building a
web application for the Java
Enterprise Edition, you would set the
dependency on the Servlet API and
related Java EE APIs to scope provided
because the web container provides
those classes. This scope is only
available on the compilation and test
classpath, and is not transitive.
Maven downloads the thing, adds it to test and compile classpaths, but does not include it in packaging.
My shop has been running Oracle's Application Server for several years. As such, before we knew better, we have developed a norm of having application config files stored outside of the WAR file and the app-specific config directory is added to each application using an Oracle-specific deployment descriptor. This deployment descriptor allows us to add classpath elements at the application layer rather than having to include all dependencies in the WAR.
Now we are faced with upgrading to WebLogic 10.3 and I need to find an alternative for our applications that depend on external configs.
Is there a way in WebLogic to add external jars or directories to the classloader at the application level? I've found ways to add them to the system classloader, but I'd prefer to add them to the application level to avoid having to re-work the applications beyond modifying deployment descriptors.
Is such a thing possible in WebLogic 10?
After further research, we've learned about WebLogic's Generic File Loading Overrides feature.
This feature allows us to use a Deployment Plan for our application and specify a "config-root" for the application. Within the config-root, we can create a directory called "AppFileOverrides" and override any file in the WEB-INF/classes or WEB-INF/lib directories.
This feature works by injecting a classloader just in front of the Web Application classloader, thus any resource loaded from the classpath will be found in this classloader before anything bundled into the web application archive.
Using this feature, we are able to add configuration files (and in theory, classes) that don't exist in the war file at all. Thus, we are able to mimic the functionality of keeping configuration files outside the war.
Moving forward, I'm encouraging our developers to include the configurations inside the war file, but this will work nicely for legacy apps and for situations where we need to change the configuration for a given deployment target (dev vs production)
External jars can be referenced by deployments using the shared libraries.
Roughly, the external jars should be 'deployed' as libraries. Then they can be referenced from your app's weblogic-application.xml using library-ref descriptors.
refer to this doc.
Though, I dont think you can provide external directories/config files other than by using system classpath.
To my knowledge, this is not possible with Weblogic. External configuration files need indeed to be added to the system classpath. You can tweak a bit the classloader (see filtering and loading order) but there is nothing allowing to add dependencies at the "application level" a la OAS. For this, you'll have to run separated domains if the scenario mentioned above is not an option.
I'm building my application to run in an OSGi container. I use Maven and the Maven Bundle Plugin from Apache Felix to set up the OSGi manifests for my own modules and that works great.
Now, I'm deploying my bundles into an OSGi container together with several 3rd party libraries. Some of these are already OSGi-fied when I get them from the Maven repos, others, I want to convert into OSGi-compatible jars. I want to set up a Maven project that collects all dependencies, and puts each in its own OSGi jar. The ultimate goal is to collect these jars and my own into an assembly that I can use as a standalone deployment package.
I know how to convert standard jars to OSGi jars, and I have a (somewhat hackish) approach to merge multiple OSGi bundles, even if I probably shouldn't. But if I have a dependency that's already fine as it is, and I just want to copy it from the repo into my assembly, what part of Maven do I use? The bundle plugin is wrong, it messes up the manifests if a dependency is already OSGi-compatible. Do I use the dependency-plugin, the assembly plugin or something else?
I have the feeling I'm overlooking something very simple here.
Did you have a look at the PAX tools? In particular Pax-Runner and
pax-construct... They do not only give you a nice template to start with, but also solve most the problems you mentioned for free.
We use many libraries which are not OSGified by the vendor and which are not available on the Spring bundle repository. We also have many of these and want to deploy them all together hassle free. For this we have created a 2-layer maven setup:
Individual maven projects that either download or contain (as 'system' scope depends) the 3rd party lib in question, and OSGify these using the Apache Felix bundle plugin
One container project that has a dependency on all of these small projects and makes an assembly of them using the core assembly maven plugin. This POM also uses the copy-dependencies goal of maven to make sure everything is in place.
Once it is turned into an assembly (ours is a tar file) we deploy this to our servers. We have gone one step further and used this assembly of 3rd party libraries as the Target Platform for our Eclipse build environment. But this may be irrelevant for you.
You can get OSGi friendly versions of many common artifacts from the Spring bundle repository. So you may not have to do it yourself.
See details of how to configure the bundle repository for Maven.
(will update with some ideas for those that aren't available as bundles already)
Can I make a single maven project that can be included as a dependency (to reference Java classes inside) and executed as a plugin?
I'm working on a library to help with hosting GWT on a LAMP stack. For someone to use this, they need to extend some Java classes (so it must be a dependency) and they need to invoke a maven plugin (so it needs to be a plugin). The plugin code references the same Java classes, so if they are seperate projects, the plugin one must depend on the library one.
As is, I have the library as a normal maven project, and the plugin as a maven plugin that depends on the library. This means that to do a release, I have to release two different artifacts, and the dependent project must update both version numbers for both artifacts. It'd be nice to have a single project.
You'd be better of by doing the following
project for the jar, Foo:Foo.jar
project that uses Foo:Foo.jar as a
dependency that builds the plugin
Maven parent project that
builds 1&2
The directory structure would look like this
\project\pom.xml
\project\foo\pom.xml
\project\foo\src\main\java\foo.java
\project\plugin\pom.xml
\project\plugin\src\main\resources
\project\plugin\src\main\java
From \project you can do a mvn clean package to build \project\foo\target\foo.jar and \project\plugin\target\plugin.jar
Hope this helps.
If you create a maven plugin it still has a artifactId/groupId/version. There's no reason it can't be references both in your section and in your section. On the other hand, if thats ugly, why not just make a library with the common code that both your main project and your maven plugin project depend on?
EDIT:
Sorry, wasn't clear on the second part. Look into composite maven projects, where there is a top level pom that defines a number of child modules. In this case, the maven plugin and the common library code could be separate children producing separate artifacts, but you only need one version number and one release command executed from the top level. I haven't done this but there are any number of open source projects that do. its often used as an idiom to put testing code into a single module that can be referenced by all the others, without having it go out in any distributable jar.
The best practice is to not do what you're suggesting. Examples of this include PMD, BND, JUnit/TestNG, and so on - no serious projects seem to package the maven plugin with the library proper.
One way to get both alternatives is to use maven assemblies to have two seperate maven projects for each the library proper and the plugin and then a separate packaging as a jar containing the classes from both.