maven-javadoc-plugin 2.9.1 does not work with JDK 8, cannot find javax.interceptor.InterceptorBinding

2014-09-10 Thread Rabe, Jens
Hello, this problem was already posted in March, but there were no answers, since I have the same problem, I post it again: When using a source level of 1.8, the maven-javadoc-plugin does not work. My configuration in pom.xml is the following: plugin

Re: maven-javadoc-plugin 2.9.1 does not work with JDK 8, cannot find javax.interceptor.InterceptorBinding

2014-09-10 Thread Karl Heinz Marbaise
Hi, based on the following issue: http://jira.codehaus.org/browse/MJAVADOC-393 Have you used the most recent version of JDK 8 (8u20?) Kind regards Karl-Heinz Marbaise On 9/10/14 9:58 AM, Rabe, Jens wrote: Hello, this problem was already posted in March, but there were no answers, since I

Build once, deploy everywhere

2014-09-10 Thread Jan
Hi All, Does anyone using Maven as Build Once and deploy Everywhere method? Like lets say i don't want to recompile my source code everytime for different environment DEV,SIT,UAT PROD. I want to do my compile and package only at DEV then deploy the artifact to all mentioned environment. Is this

Re: Build once, deploy everywhere

2014-09-10 Thread Stephen Connolly
What you want to do is have your packaged software be independent of the environment it is deployed to. That way you know by checking the SHA1 of the artifact you can know it was the one that was tested by QA. So what you do is have your application read its configuration from an external source.

RE: Build once, deploy everywhere

2014-09-10 Thread cody.a.fyler
Both of the below are good solutions. I've also seen folks use a run time based solution where a different set of properties is loaded based on an Environment Variable common to all servers. Cody Fyler Lending Grid Build Team G=Lending Grid Builds (515) – 441 - 0814 -Original Message-

Re: Build once, deploy everywhere

2014-09-10 Thread Stephen Connolly
The down side of that is that if your environment details for a specific server change, then you need to rebuild. If you are loading configuration from an external source then you just update the external source and continue with the app as is. On 10 September 2014 15:17,

Re: Build once, deploy everywhere

2014-09-10 Thread Graham Leggett
On 10 Sep 2014, at 10:03, Jan raghure...@gmail.com wrote: Does anyone using Maven as Build Once and deploy Everywhere method? Like lets say i don't want to recompile my source code everytime for different environment DEV,SIT,UAT PROD. I want to do my compile and package only at DEV then

How to get a dependency tree view of plugin dependencies used in the build

2014-09-10 Thread David Hoffer
Similar to dependency:tree for project dependencies how can I get a similar list of plugin dependencies used in the build? -Dave

Re: Build once, deploy everywhere

2014-09-10 Thread Jan
Thanks All. My package is not environment specific, and currently i compile and package using Maven, and run deployment using Ant, coz when i tried to run maven deploy it was using the full life cycle goals again, instead of this is there any way to execute just deploy and skip all other goals?

How to extend the dependencies of a reused plugin ?

2014-09-10 Thread Cristiano Gavião
Hello, I have two maven plugins A and B. When used separated I can extend the dependencies of A using this: plugin artifactIdorg.A/artifactId dependencies dependency artifactIdanDependency/artifactId /dependency /dependencies

Re: Build once, deploy everywhere

2014-09-10 Thread Adrien Rivard
Hi, You can always run mvn deploy:deploy, but the main point of deploy is not to deploy applications but to deploy binaries into a Maven repository manager (Nexus ..) Deploying applications is traditionnally done via others specifics tools, though a few maven plugins do that as well. On Wed,

Re: Build once, deploy everywhere

2014-09-10 Thread Jason van Zyl
Yes, this is the only thing I've ever done. Unfortunately all the JEE specs don't seem to be well thought out in this regard. For a given runtime the model I use is one where there is a launcher, a binary part (libs and app), and configuration. I combine these three things to make a working

Re: Build once, deploy everywhere

2014-09-10 Thread Stephen Connolly
you could look at my attempt to work around that: ship-maven-plugin @ codehaus On 10 September 2014 16:07, Jan raghure...@gmail.com wrote: Thanks All. My package is not environment specific, and currently i compile and package using Maven, and run deployment using Ant, coz when i tried to

RE: Build once, deploy everywhere

2014-09-10 Thread Martin Gainty
From: cody.a.fy...@wellsfargo.com To: users@maven.apache.org Subject: RE: Build once, deploy everywhere Date: Wed, 10 Sep 2014 14:17:25 + �Both of the below are good solutions. I've also seen folks use a run time based solution where a different set of properties is loaded

Re: Build once, deploy everywhere

2014-09-10 Thread james northrup
(http://) 12factor.net lean service deployment works well enough with maven projects if the presence of source is not a detriment to a given sla. I use git pull;mvn install;bin/run.sh when transitioning to production from development and I agree with 12factor apps about ENV vars being a

Re: How to get a dependency tree view of plugin dependencies used in the build

2014-09-10 Thread Baptiste Mathus
Found that, seems to match your question: http://stackoverflow.com/a/7079876/345845. Karl-Heinz is everywhere :-). 2014-09-10 16:50 GMT+02:00 David Hoffer dhoff...@gmail.com: Similar to dependency:tree for project dependencies how can I get a similar list of plugin dependencies used in the

Re: Build once, deploy everywhere

2014-09-10 Thread Baptiste Mathus
*that* deploy has actually nothing to do with the deploy you want. It's only and specifically designed to push a binary produced by the building process to some maven repository manager (say archiva, nexus or artifactory for example). 2014-09-10 17:07 GMT+02:00 Jan raghure...@gmail.com: Thanks

Re: How to extend the dependencies of a reused plugin ?

2014-09-10 Thread Cristiano Gavião
well, seems that there is no way to accomplish that easily. but I found a working solution. I created another mojo in project B extending the mojo class from project A and changed the lifecycle settings properly... best, Cristiano On 10-09-2014 12:18, Cristiano Gavião wrote: Hello, I

RE: Build once, deploy everywhere

2014-09-10 Thread Martin Gainty
PortBinding: different services in the computer which needs to send and receive data are uniquely identified by PORT no. I would like to see an example implementation of this Thanks James, From: northrup.ja...@gmail.com Date: Wed, 10 Sep 2014 11:49:30 -0700 Subject: Re: Build once, deploy

Re: Build once, deploy everywhere

2014-09-10 Thread james northrup
Martin i use https://github.com/jnorthrup/1xio/blob/master/src/main/java/one/xio/Config.java in several projects to have configs close to source but based on defaults overriden by -D commandline and environment. as far as a key value pair of port:role, sounds too coupled to me, would rather just