Anders Hammar wrote:
>> The Enunciate plugin "attaches" its own artifact with a unique
>artifactId.
>
>
>Do you have an example of this? I checked the docs (
>http://enunciate.codehaus.org/executables.html#maven) and I can't see
>this.
The install and deploy goals are what I was referring to.
The Enunciate plugin "attaches" its own artifact with a unique artifactId. I'm
not sure of the implementation details, but it's got its own install-artifact
and deploy-artifact goals that do the work. (Just to note that there's at
least one other plugin doing something similar, not to make a c
Anders Hammar wrote:
The Enunciate plugin "attaches" its own artifact with a unique
artifactId.
Do you have an example of this? I checked the docs (
http://enunciate.codehaus.org/executables.html#maven) and I can't see
this.
The install and deploy goals are what I was referring to.
I'm no
The Enunciate plugin "attaches" its own artifact with a unique artifactId.
I'm not sure of the implementation details, but it's got its own
install-artifact and deploy-artifact goals that do the work. (Just to note
that there's at least one other plugin doing something similar, not making a
cl
While you're there, "parallel" rather than "parrallel", please!
On 23/04/12 05:14 PM, Olivier Lamy wrote:
good catch too.
I didn't test the parrallelThreads stuff
So I cancel the vote.
2012/4/23 Karl Heinz Marbaise:
Hi,
i have checked the staged Site and observed that the frames around the
There's also org.codehaus.mojo:build-helper-maven-plugin:reserve-network-port,
which only assigns random ports (unlike port-allocator, which allows the use
of explicit ports).
I'm hesitant to put this next bit forward, given Jason's implicit approval of
the "POM expression" approach, but what
Dennis Lundberg wrote:
> Staging repo:
> https://repository.apache.org/content/repositories/maven-068/
The new plugin *almost* solves MRELEASE-458, in that setting
updateWorkingCopyVersions=false for release:branch does result in the working
copy version being preserved at the end of the releas
On 16/10/09 11:45 AM, Stephen Connolly wrote:
2009/10/16 Peter Janes
On 15/10/09 05:45 AM, Stephen Connolly wrote:
These are very dangerous versions to suggest use of.
...but there *are* use cases for them.
When your use case results in a completely unpredictable build... no thank
you
On 16/10/09 11:45 AM, Stephen Connolly wrote:
2009/10/16 Peter Janes
On 15/10/09 05:45 AM, Stephen Connolly wrote:
These are very dangerous versions to suggest use of.
...but there *are* use cases for them.
When your use case results in a completely unpredictable build... no thank
you
On 16/10/09 11:47 AM, Stephen Connolly wrote:
2009/10/16 Peter Janes
However, I'm not aware of any released version of Maven or any plugin that
actually treats dependencies this way; Mercury, tested through
versions-maven-plugin, doesn't appear to either. (But I'd love to
On 15/10/09 05:45 AM, Stephen Connolly wrote:
These are very dangerous versions to suggest use of.
...but there *are* use cases for them.
These are deprecated and are only "special" versions when considering
plugins... and they do not behave as you think they behave.
For what it's worth, th
I was in the process of writing a similar (but much longer) response, but
Christian's covers most of the same ground. I've only got two points to add.
Point 1: I think it's important not to conflate identifiers with other
attributes. In particular, "scope" and "optional" shouldn't be consider
Looks like this has been considered before (and implemented):
Maven URL handler implements the specs from OSGi URl Handlers Service and
registers a service that handles url's as:
mvn://repository/groupId/artifactId/version/type?instructions
Where:
* repository - is the repostory from
009
New Revision: 753302
URL: http://svn.apache.org/viewvc?rev=753302&view=rev
Log:
[MCOMPILER-91] Allow source and output directories to be
configured.
Patch from Peter Janes (peterj).
Added:
maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director
ies-MCOMPILER-91/
14 matches
Mail list logo
