As I already did with JVM Options and Utilities, I'm sharing the spreadsheet with useful commands and plugins of maven.
Thursday, May 22, 2008
Wednesday, May 21, 2008
Generation of Eclipse projects using maven
I believe that everyone who uses maven and eclipse is familiar with eclipse:eclipse goal. For these who are not familiar: get familiar with it as quick as you can! It does a very simple but powerful thing: generates eclipse projects for you with all the dependencies.
And here are some tips:
1. To generate new eclipse project from pom.xml, type "mvn eclipse:eclipse".
2. To generate new eclipse project with source attachments type: "mvn eclipse:eclipse -DdownloadSources=true"
3. To regenerate eclipse project close the project in eclipse and type "mvn eclipse:clean eclipse:eclipse". Add "-DdownloadSources=true", if you like to.
4. Now suppose you have hierarchy of projects. You may like to generate all projects with the proper dependencies between them or you may like to generate a project or two, which are dependent on the repository.
In the first case run "mvn eclipse:eclipse" using root pom.xml. In the second case run "mvn eclipse:eclipse" from the project's directory.
5. To use the projects in eclipse, you need to configure variable called M2_REPO which must point to your local repository. Maven can do it for you by running "mvn -Declipse.workspace= eclipse:add-maven-repo". Although I don't find this feature very useful, since you need to do it only once per workspace and it can be shortly done manually.
And here are some tips:
1. To generate new eclipse project from pom.xml, type "mvn eclipse:eclipse".
2. To generate new eclipse project with source attachments type: "mvn eclipse:eclipse -DdownloadSources=true"
3. To regenerate eclipse project close the project in eclipse and type "mvn eclipse:clean eclipse:eclipse". Add "-DdownloadSources=true", if you like to.
4. Now suppose you have hierarchy of projects. You may like to generate all projects with the proper dependencies between them or you may like to generate a project or two, which are dependent on the repository.
In the first case run "mvn eclipse:eclipse" using root pom.xml. In the second case run "mvn eclipse:eclipse" from the project's directory.
5. To use the projects in eclipse, you need to configure variable called M2_REPO which must point to your local repository. Maven can do it for you by running "mvn -Declipse.workspace=
Wednesday, May 14, 2008
How to use SAML with REST Web Services
The Problem
OASIS Web Services Security describes how to use SAML with SOAP web services. The signed SAML Assertion should be added to the SOAP header... and so on. However, there is no specification that describes how to add SAML to REST web services. The reason that there is no such specification is simple: REST is not a standard, but it's an architectural style. So it's impossible to define standard that is not based on standard.
And still we would like to support SAML for our REST web services. Why? The same reason we support SAML for SOAP web services: it's a standard, it's convenient, many frameworks start to support it and so on.
The Solution
The solution is quite simple. Since REST web services are based on HTTP protocol we can use the HTTP Redirect Binding (see SAML Bindings, 3.4) to send the Unsolicited Responses (see SAML Profiles, 4.1.5). Since there is no problem to add the necessary query parameters to any HTTP method, the HTTP Redirect Binding with Unsolicited Responses covers the same scenario we have with SOAP without defining the additional standards.
Concerns
The only concern I have about this solution is the url length. Theoretically the url length is infinite, but of cause it cannot be supported. Each vendor limits the url length in its way and if the SAML Response will be very long, it may cause the url to be truncated. Which will cause failure to parse or validate the SAML Response.
Conclusion
Unless we send very long messages, we can send SAML with REST web services using the HTTP Redirect Binding. Although it is not a standard, it still a standard way to do things and it should work.
Who do you think?
2. REST in Practice: Hypermedia and Systems Architecture
3. Securing Web Services with WS-Security: Demystifying WS-Security, WS-Policy, SAML, XML Signature, and XML Encryption
OASIS Web Services Security describes how to use SAML with SOAP web services. The signed SAML Assertion should be added to the SOAP header... and so on. However, there is no specification that describes how to add SAML to REST web services. The reason that there is no such specification is simple: REST is not a standard, but it's an architectural style. So it's impossible to define standard that is not based on standard.
And still we would like to support SAML for our REST web services. Why? The same reason we support SAML for SOAP web services: it's a standard, it's convenient, many frameworks start to support it and so on.
The Solution
The solution is quite simple. Since REST web services are based on HTTP protocol we can use the HTTP Redirect Binding (see SAML Bindings, 3.4) to send the Unsolicited Responses (see SAML Profiles, 4.1.5). Since there is no problem to add the necessary query parameters to any HTTP method, the HTTP Redirect Binding with Unsolicited Responses covers the same scenario we have with SOAP without defining the additional standards.
Concerns
The only concern I have about this solution is the url length. Theoretically the url length is infinite, but of cause it cannot be supported. Each vendor limits the url length in its way and if the SAML Response will be very long, it may cause the url to be truncated. Which will cause failure to parse or validate the SAML Response.
Conclusion
Unless we send very long messages, we can send SAML with REST web services using the HTTP Redirect Binding. Although it is not a standard, it still a standard way to do things and it should work.
Who do you think?
Recommended Reading
1. Restful Web Services2. REST in Practice: Hypermedia and Systems Architecture
3. Securing Web Services with WS-Security: Demystifying WS-Security, WS-Policy, SAML, XML Signature, and XML Encryption
Thursday, May 1, 2008
IDE Survey results
And the results are:
Eclipse 23 (54%)
Netbeans 4 (9%)
IntelliJ 9 (21%)
JBuilder 3 (7%)
Other 3 (7%)
Total votes: 42
So the Eclipse wins. Actually this doesn't supprise me, since I personally believe that Eclipse is the best free IDE for JAVA.
However, I thought that there will be more people, who use IntelliJ. Many people said in comments that IntelliJ is very good and I agree with them. Probably the price makes it less attractive.
In addition there were people, who said in comments that they are forced to use Eclipse and if they had a choice, they would have used something else.
I can only say: Shame on the managers of these people. No project should insist on using a specific IDE, but each developer should be able to choose. And the project should be maintained using the build scripts.
Anyway this survey is over.
Thank you for the participation!
Eclipse 23 (54%)
Netbeans 4 (9%)
IntelliJ 9 (21%)
JBuilder 3 (7%)
Other 3 (7%)
Total votes: 42
So the Eclipse wins. Actually this doesn't supprise me, since I personally believe that Eclipse is the best free IDE for JAVA.
However, I thought that there will be more people, who use IntelliJ. Many people said in comments that IntelliJ is very good and I agree with them. Probably the price makes it less attractive.
In addition there were people, who said in comments that they are forced to use Eclipse and if they had a choice, they would have used something else.
I can only say: Shame on the managers of these people. No project should insist on using a specific IDE, but each developer should be able to choose. And the project should be maintained using the build scripts.
Anyway this survey is over.
Thank you for the participation!
Subscribe to:
Posts (Atom)