Since version 9.x Jetty seems not to have an aggregate artifact that provides the Jetty server within OSGi environments. It would be very helpful if the project could provide an OSGi compliant aggregate artifact for 9.x and further. In 8.x we had the org.eclipse.jetty.aggregate:jetty-all-server artifact. Why does it not exist for 9.x?
Can anybody help me or has some explanations?
The aggregates that exist for Jetty are not meant to be used by projects directly. They were created specifically for the documentation, and specifically for command line use to demonstrate some of the features of Embedded Jetty use.
It is not recommended to use aggregates for your project.
In fact, jetty-all (a name kept for historical reasons), isn't even "all of jetty" anymore. This concept isn't even possible anymore, as there are many component options for Jetty that cannot exist in the same jar at the same time.
Would highly recommend using the individual artifacts properly, and with a build tool that supports the global central repository, such as maven, ant+ivy, buildr, groovy grape, gradle+grails, scala sbt, or even leiningen.
Once you have a good build setup, you can then pick and choose and setup your own uber jars for jetty that fit your specific needs. Keep in mind that for OSGi, this would mean having to rewrite the manifest for this uberjar to include all of the OSGi references properly. Also note, that if you do this, you will likely not play well in the rest of OSGi world that is using Jetty properly. That is a decision you should make. Do I play in my own world of OSGi and never use OSGi bundles from other open source projects, or do I want to use other popular OSGi bundles in the future.
Related
The general guidance appears to be to install Sitecore into one folder, e.g. D:\Websites\MyWebSite and then create your Visual Studio project in a separate folder, e.g. C:\Projects\MyWebProject. You would then publish your custom code into the Sitecore folder from Visual Studio (This video explains what I’m describing https://www.youtube.com/watch?v=i3Mwcphtz4w around 13 mins in).
I have the following questions:-
Do people only store their Visual Studio project in source countrol and not the Sitecore code?
The publish option from VS into the Sitecore folder only has options for adding files or deleting anything not in the VS project. How would files removed from the VS project ever get deleted without doing it manually?
We use web-deploy to publish sites to staging and live environments. In this scenario would you publish from your VS project or would you set up a way to publish the Sitecore folder (if so how)?
Is this actually a good set up to have or do you do something different?
I did a lot of research on this when we started Sitecore development a couple of years ago. I remember reading a post from Sean Kearney that made a lot of sense to me: http://seankearney.com/post/Visual-Studio-Projects-and-Sitecore
We ended up using this approach for both large and small scale projects and it has been great. You will also want to look at a couple of other tools:
Team Development for Sitecore (TDS) from Hedgehog Development (http://www.hhogdev.com/products/team-development-for-sitecore/overview.aspx)
CopySauce from Igloo (http://www.igloo.com.au/blog/copysauce-igloos-sitecore-development-utility/)
SitecoreRocks for Visual Studio
So to answer your questions:
All of your code and some of the Sitecore items are stored in source control. The approach you want to take is to only store new Sitecore items (layouts, sublayouts, templates, etc) that you create along with any items you may need to customize. You do not need to store all of the sitecore source, content or modules...just what you would need to reapply to get a fresh environment up-to-date. You can manage this manually but a tool like TDS makes this MUCH easier.
We use TDS to manage the publish/deploy to each of our environments. TDS has configurable settings for handling items that have been deleted, including the ability to move it to the Sitecore recycle bin or simply remove it. You have to be careful with this but it does work.
We use a separate build environment to assemble and run deployments using TDS and Jenkins. Basically, all of the code is retrieved from the source control system to the Sitecore server and built using MSBuild and TDS. In most cases we use a webdeploy directly to the Sitecore webroot, but for production we build TDS packages and then run them on each Content Delivery Server
We have used this setup for 7 sitecore projects so far and I am very happy with how it has worked out. We have questioned whether TDS is worth the license fee but the answer always comes back as a yes. The alternative is not very appealing for our development staff and time savings far out-weigh the costs.
Everything is stored in Source Control!... just not always in the same area as they reside on the web server. Storing the Sitecore folder in source control is a good idea as there are changes that you will have as you install modules, but you do NOT add the Sitecore folder as part of your solution/project and should really be there to pull from if need be and not something that is even tracked/monitored.
Once Sitecore is installed, create a new project that resides in the website folder and only add things like the properties folder, layouts, xml and other folders that you want. I don't even include the app_config in my project. Oh and to be clear, it's probably best to just keep the Sitecore folder as a sort of reference folder in your source control but not as part of your website trunk. We have it on the ignore list for website folder in source control. However, that being said, keep in mind that you will NEED to have it in your website folder.
Technically speaking, the recommended approach is to install Sitecore on to the server itself as a stand alone empty instance.. like using the installer with the client mode (not full) so that you get the framework for an empty site in place. Then you can create the deployment package/packages/whatever and it will all be your own code. You should really never have to mess with changing/removing the base Sitecore file system manually.
See above. Generally speaking, unless you have a reason to do so: install Sitecore as an empty instance... then manage your code/files via deployment and just leave the Sitecore folder files alone. You will have very little reason to ever touch them or the Sitecore folder itself outside of an upgrade.
Adding Sitecore itself to source control should be avoided, since you won't be deploying Sitecore as part of your implementation. For modifications to Sitecore itself, you would need a way of handling those inside your implementation, but the config patch system and other mechanisms provide the means for this.
Redundant files in the web site folder will only be a real problem in your development environment. When publishing to a demo environment or to a live environment, you will only publish the material that you actually want. And the deployment-based setup opens up the possibility of always starting from a clean Sitecore installation - as long as you include your Sitecore modifications as part of your implementation (which is not covered in the video). So there is little risk of this being a problem in real life, and the development method in the video makes eliminating this risk entirely possible.
The Sitecore installation should be handled outside of the deployment of your implementation.
It's a good setup, because the method in the video is the method Sitecore recommends for development, and it is also the method Sitecore teaches to developers in development courses. The most obvious advantages of this method are
Clean separation between your web site implementation and the Sitecore installation. There is no risk of accidentally mangling the Sitecore installation, and there is no risk of forgetting unmanaged manual modifications to Sitecore that are needed to run your site. This separation is hard to accomplish if you're not using the method in the video.
By using publishing to deploy your implementation, you know that your implementation is deployable on top of a clean Sitecore installation - and works. This means when deploying to a production or demo server in the future, things will work the same and there will be no surprises. This is very hard to be confident about if you're not using the method in the video.
To test your implementation on a different version of Sitecore, you can just deploy to a clean installation of a different version. This is very hard to test if you're not using the method in the video.
There is sample source code for the video on GitHub, along with instructions on how to set up the development environment, including the publishing parts. This sample source directly and indirectly answers some of your questions.
Currently My web Application is running on jboss 5.1 and we need to migrate it to jetty server..i am looking for a complete detail and steps to do the process...Thanks in advance
I don't think there exists a step by step document along the lines you are looking for. It largely depends on your web application how simple or hard the migration would be. If you are using EJB's for instance then you would have to also factor in the openejb integration we have some support for, if it is a straight war file then it is likely much easier. There are professional services from the jetty developers available to help if you like, you can google Webtide for that. I would recommend going straight to Jetty 9.1 though, the new distribution layout makes things a fair amount easier to separate things out.
Current documentation is here though: http://www.eclipse.org/jetty/documentation/current/
We're working on a project that has some Clojure-Java interop. At this point we have a single class that has a variety of dependencies which we put into a user library in Eclipse for development, but of course that doesn't help when using Leiningen (2.x). Most of our dependencies are proprietary, so they aren't on a repository somewhere.
What is the easiest/right way to do this?
I've seen leiningen - how to add dependencies for local jars?, but it appears to be out of date?
Update: So I made a local maven repository for my jar following these instructions and the lein deployment docs on github, and edited my project.clj file like this:
:dependencies [[...]
[usc "0.1.0"]]
:repositories {"usc" "file://maven_repository"}
Where maven_repository is under the project directory (hence not using file:///). When I ran "lein deps"--I got this message:
Retrieving usc/usc/0.1.0/usc-0.1.0.pom from usc
Could not transfer artifact usc:usc:pom:0.1.0 from/to usc (file://maven_repository): no supported algorithms found
This could be due to a typo in :dependencies or network issues.
Could not resolve dependencies
What is meant by "no supported algorithms found" and how do I fix it?
Update2: Found the last bit of the answer here.
add them as a dependency to your leiningen project. You can make up the names and versions.
then run lein deps and the error message when it fails to find it will give you the exact command to run so you can install the jar to your local repo then sould you decide to use a shared repo you can use this same process to put your dependencies there.
#Arthur's answer is good but I figured I'd flesh it out a bit more since it leaves some details lacking.
Always keep in mind Repeatability. If you don't make it so that anyone who needs access to the artifacts can get access to the artifacts in a standard way, you're asking for support hell.
The documentation on deployment is a good place to go to find out everything you need to know about deploying your artifacts. Since you're in a polyglot environment you probably can't have lein take care of deploying all your artifacts but at least you can get your clojure specific jars up into S3 or even a file share if you like. The rest of your artifacts will have to use Maven or Ant directly to upload the artifacts to the Maven repo on the file server or S3. At my current company we are using technomancy's excellent s3 wagon private to great effect for hosting our closed source artifacts and clojars for hosting anything that we can open-source.
What #Arthur is referring to is doing a lein install. All that does is install a copy of the current project into your local .m2 directory so that other projects on your box can reference them. Unless you have configured your install of maven to use a shared directory for your .m2 folder (maybe not a bad idea in your environment?), this will mean that anyone else who checks out your project will not be able to build it. If you wanted to go this route, you need to set the localRepository node in your $M2_HOME/conf/settings.xml to be the shared location that the rest of your team has access to. See the docs for more information.
YMMV but I've found it best to use Maven rather than Leiningen when you are working with Polyglot Clojure / Java projects.
It's mainly because the Java based tools (Eclipse etc.) understand Maven projects but don't really understand Leiningen projects. It's getting slowly better with the excellent Counterclockwise Clojure plugin, but the integration still isn't quite good enough yet for an efficient IDE based workflow.
On the repository side of things, I'd suggest setting up a private shared Maven repository. You're going to need it sooner or later if you plan to manage a complex set of dependencies within your team: might as well bite the bullet and get it done now.
Our project has started mandating us to write tests for all modules going into Prod from now on. We have cases where a Spring POJO has some injected EJBs and these EJBs are used within the POJO methods. Since we couldn't find a way to unit test injected EJBs within a POJO (tried various ways but were unsuccessful), we were suggested to use Arquillian. I configured Arquillian to run on a local JBoss 6.0.0 server - all their tests ran properly from command line as well as from Eclipse.
However, our test and prod environments use Weblogic 10.3 server. I havent found much information as to how we could configure Arquillian unit tests to run in weblogic. If anyone has tried this earlier, could you please let me know which config files and what to change ?
-Sonu
The properties to be specified in the arquillian.xml file for WLS 10.3, are listed in the Arquillian Reference Guide. Usually, one may need to specify the mandatory properties, but should the need arise, other properties can be specified as well.
Note that, the contents of this page are for the 1.0.0.Alpha1 version at the moment, and would be revised at some point in the future in subsequent releases (when they are made).
What exactly is the difference? I've been using Jetty 8.0.0 lately and when I try the distribution download I cannot get neither WebSockets nor Servlet 3.0 #WebServlet annotation to work. If I use hightide, it just works.
What is the point of the distribution?
I'm interested in the difference too, and what's online is confusing. Here's Jesse McConnell's ( https://stackoverflow.com/users/1185262/jesse-mcconnell ) answer to my just-posted question on the [jetty-users] mailing list ( http://jetty.4.n6.nabble.com/jetty-users-jetty-versions-tt3675449.html ):
yes, hightide is just the jetty-distribution with some additions that we can not distribute from eclipse do to their IP restrictions.
I did a lot of digging around before I got that answer, so I'll include the results below for reference. I hope this helps.
Description from eclipse.org: The Jetty Hightide application server is a distribution of the jetty Web Server assembled at codehaus with additional services like JNDI, XA & JDBC preconfigured. For jetty-hightide-6 this is an optimized, patched rebuild of jetty-6, while for jetty-hightide-7 it is distribution based on the standard jetty-7 artifacts combined with other third party integrations. -- http://www.eclipse.org/jetty/about.php
Description from docs.codehaus.org: Hightide is an optimized, versioned distribution of the Jetty open source web container. It comes pre-integrated with a number of services usually only found in J2EE application servers, or which you would otherwise have to craft together yourself: JNDI, an XA transaction service, a JMS message fabric, and a JDBC accessible database. Thanks to Jetty's light weight, pluggable architecture, Hightide allows you to easily choose which of these services you want to use, or even replace them with others. -- http://docs.codehaus.org/display/JETTY/Hightide+Documentation
FAQ: "What's the difference between Jetty from Mort Bay, Codehaus and/or Eclipse?" at wiki.eclipse.org: The latest releases of core jetty-7 and later are available from Eclipse, which use the org.eclipse.jetty packaging. For versions 6 of Jetty, plus some jetty-7 components such as RPMs, Debs, Hightide, use codehaus, which uses the org.mortbay packaging. -- http://wiki.eclipse.org/Jetty/FAQ
However, the contents of the two distributions (see 'Downloads' below) both use the o.e.j packaging, so I don't think the answer is entirely correct.
Mentions of features at http://wiki.eclipse.org/Jetty:
The Hightide distribution of jetty contains an example webapp that uses JAAS. -- http://wiki.eclipse.org/Jetty/Feature/JAAS
Jetty supports java:comp/env lookups in web apps. This is an optional feature and you need to do some setup. However, if you are using the Hightide distribution of Jetty, this feature is already fully enabled, so you can skip any setup steps, and just read the sections on how to put objects into Jetty's JNDI so that you can retrieve them at runtime. -- http://wiki.eclipse.org/Jetty/Feature/JNDI
Annotation processing is not enabled by default by the standard jetty distribution, only by the Hightide distribution. -- http://wiki.eclipse.org/Jetty/Feature/Annotations
Downloads: Version numbers seem in-sync:
http://download.eclipse.org/jetty/8.1.4.v20120524/dist/
http://dist.codehaus.org/jetty/jetty-hightide-8.1.4/
After a cursory look, the contents look extremely similar.