On 26/02/2013 2:34 AM, Jean-Noël Colin wrote:
Hi Ron,
Do you mean invoking the ant plugin from the pom.xml file? I was wondering
whether this was a good practice, or something to be kept only for situations
where you really can't avoid it
It would probably not be described as a best practice b
On 26/02/2013 2:54 AM, Baptiste MATHUS wrote:
I *think* Ron means: using maven to produce your standard artifacts
(jar/war/ear ?), and then use pure ant somewhere in the process just before
deploying for a specific customer to do the replacements you're talking
about.
(By the way, invoking ant f
Hi,
I would like to setup profiles with username and password as properties.
Then I would like to use the properties in the servers/server tags in the
same file.
Something like the following:
profile>
old-nexus
true
Hi,
> I would like to setup profiles with username and password as properties.
> Then I would like to use the properties in the servers/server tags in
the
> same file.
> Something like the following:
> profile>
> old-nexus
>
> true
>
>
>
So, I've absently-constructed the following problem.
I've got a JAX-RS service that does, essentially, all of its work in a
StreamingOutput object. It also has an error mapper that produces a
Json body to go with the 400 status code in the error response.
You can see where this goes: the code suc
This is not a Maven problem...
On 26 February 2013 14:08, Benson Margulies wrote:
> So, I've absently-constructed the following problem.
>
> I've got a JAX-RS service that does, essentially, all of its work in a
> StreamingOutput object. It also has an error mapper that produces a
> Json body t
so your suggestion would be to have maven do the compile, and a kind of
'war:exploded', and then run ant to add the customized files and create the war
file, is that correct?
or should I write a plugin that does that for me?
You write: "Separating run-time deployment from Maven is a best prac
I don't want to speak for Ron, but I'll fill in my interpretation of
his comments...
> so your suggestion would be to have maven do the compile, and a kind
> of 'war:exploded', and then run ant to add the customized files and create
> the war file, is that correct?
Not at all. I believe he is say
> Plugins are development time tools and not deliverables to the customer. So
> customer should not care how(by which plugin versions) artifacts are build.
> Therefore never reveal versions of the build tools to the customer :-)
I expect that OP is working as a consultant to someone, to help them
That's true. I obviously wasn't awake.
On Tue, Feb 26, 2013 at 9:15 AM, Stephen Connolly
wrote:
> This is not a Maven problem...
>
>
> On 26 February 2013 14:08, Benson Margulies wrote:
>
>> So, I've absently-constructed the following problem.
>>
>> I've got a JAX-RS service that does, essential
again, many thanks for your valuable comments; but my issue is that if Maven
packages the war file, it means that the config files have already been
customized (think of the spring config files in WEB-INF for instance); so how
can I mix both approaches?
Cheers
Jean-Noël
On 26 Feb 2013, at 16:
> again, many thanks for your valuable comments; but my issue is
> that if Maven packages the war file, it means that the config files
> have already been customized (think of the spring config files in
> WEB-INF for instance); so how can I mix both approaches?
Here's two solutions I can imagine:
this sounds easy :-) any CM tool to recommend?
many thanks
On 26 Feb 2013, at 16:22, Wayne Fay wrote:
>> again, many thanks for your valuable comments; but my issue is
>> that if Maven packages the war file, it means that the config files
>> have already been customized (think of the spring co
I have an answer on Stack Overflow that might help your thought processes:
http://stackoverflow.com/questions/14650468/whats-a-practicable-way-for-automated-configuration-versioning-and-deployment/14661186#14661186
On 26 February 2013 15:06, Jean-Noël Colin wrote:
> so your suggestion would be
I say that you could just run a post-deployment command that performs any
filtering. You could use ant, perl, java, whatever you wanted to... and
perhaps have it pull down content from a centralized git repository or
something to make it easy to maintain your properties/configs.
The obvious mess
Since you want to support a "lot" of customers with different
configurations, you may want something that is based on a simple CMS
that provides a database and an editing tool and an API for extracting
content.
You script could then navigate the CMS picking up the right pieces to
make up the wa
many thanks for this very useful reference
/jnc
On 26 Feb 2013, at 16:43, Stephen Connolly
wrote:
> I have an answer on Stack Overflow that might help your thought processes:
> http://stackoverflow.com/questions/14650468/whats-a-practicable-way-for-automated-configuration-versioning-and-deploy
Correct. It's not really a big deal, I'll just have some 'splainin' to do
if they ask.
On Tue, Feb 26, 2013 at 9:16 AM, Wayne Fay wrote:
> > Plugins are development time tools and not deliverables to the customer.
> So
> > customer should not care how(by which plugin versions) artifacts are
>
This explain it: http://jira.codehaus.org/browse/MPLUGIN-225
Robert
Op Mon, 25 Feb 2013 00:45:34 +0100 schreef Dan Tran :
I think MojoDecriptor can get me PluginDescriptor. but dont think
${mojo} would give me MojoDescriptor. Null is what I get.
-D
On Sun, Feb 24, 2013 at 2:25 PM, Dan Tran
Thanks, with this new info, I got it working now
-D
On Tue, Feb 26, 2013 at 10:07 AM, Robert Scholte wrote:
> This explain it: http://jira.codehaus.org/browse/MPLUGIN-225
>
> Robert
>
> Op Mon, 25 Feb 2013 00:45:34 +0100 schreef Dan Tran :
>
>
>> I think MojoDecriptor can get me PluginDescripto
I'm writing a plugin that needs to combine a bunch of artifacts into a zip
and create an XML file of it. I am currently working on creating the XML,
for the rest i use the assembly plugin. To generate the XML i need a way
(an api) to traverse the graph of maven dependencies
Here is a normal hie
Hello Martin,
of course I could redefine some plugins to be run in a different phase,
enforcer could run during verify etc. However some (as buildnumber-version)
are mostly useful for filtering resources, so delaying this to later phases
makes no sense IMO :-).
Regards Mirko
On Mon, Feb 25, 2013
Dear All,
I have a question regarding the release plugin's branch goal. What I am
trying to achieve (using CVS for scm) is this:
-I have a release on the HEAD, let's call this 1.1, with release tag
"REL_1_1"
-I have new changes committed to HEAD (in 1.1-SNAPSHOT)
-I have to fix a bug in 1.1 immedi
23 matches
Mail list logo
