+1 non-binding, checked the sha1 sum of the source zip and ran site
generation including changes successfully with some pat projects.
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/
On Apr 12, 2014, at 11:32 AM, Benson Margulies wrote:
>
> I'm much more here. For example, I might have 250,000 words of text
> annotated for training a statistical model. I have a maven build that
> needs to grab unpack that pile into some location, run a plugin that
> performs some data normal
On Sat, Apr 12, 2014 at 11:14 AM, Jason van Zyl wrote:
>
> On Apr 12, 2014, at 8:16 AM, Benson Margulies wrote:
>
>> On Sat, Apr 12, 2014 at 8:07 AM, Hervé BOUTEMY wrote:
>>> after thinking more at it, it seems the "scope" for such artifacts is the
>>> plugin parameter name
>>>
>>
>> I'm forking
On Apr 12, 2014, at 8:16 AM, Benson Margulies wrote:
> On Sat, Apr 12, 2014 at 8:07 AM, Hervé BOUTEMY wrote:
>> after thinking more at it, it seems the "scope" for such artifacts is the
>> plugin parameter name
>>
>
> I'm forking off a new thread here.
>
> A maven repository is a lovely plac
I think allowing plugins to resolve things with annotations is not a good idea
as we already have project dependencies resolution that happens on the fly per
project. This means it's impossible to fully reason about the requirements of a
project being built up front. This, in practice, leads to
On Apr 12, 2014, at 8:02 AM, Hervé BOUTEMY wrote:
>>
>> In short, if I've followed and understood this correctly, and I may not have
>> (holiday time for me), it sounds a very bad idea Igon.
> IMHO, each choice is debatable: this should be an option in compiler plugin.
> Something like "disable
On Apr 12, 2014, at 7:24 AM, Lennart Jörelid wrote:
> Oh I know it is the recommended practise, but I believe that particular
> recommendation is flawed since it does not consider the needs of *big*
> systems with reactors containing lots of projects.
This simply is not the case. It is precisel
Hi,
> We solved 12 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11212&version=19130&styleName=Html
The most important one being that the plugin can now (again) be used
to generate announcements from JIRA for our own projects :-)
There are still a couple of issues left in
+1
reenabling auotmatic annoucements generation will be a good thing, thank you
notice the link to source-release.zip is
https://repository.apache.org/content/repositories/maven-1019/org/apache/maven/plugins/maven-changes-plugin/2.10/maven-changes-plugin-2.10-source-release.zip
(without the "/cont
What about (ab-)using the runtime scope for this? The core could inspect
the pom and inject runtime dependencies into the class path.
Regards
Mirko
--
Sent from my mobile
On Apr 12, 2014 2:08 PM, "Hervé BOUTEMY" wrote:
> after thinking more at it, it seems the "scope" for such artifacts is the
On Sat, Apr 12, 2014 at 8:07 AM, Hervé BOUTEMY wrote:
> after thinking more at it, it seems the "scope" for such artifacts is the
> plugin parameter name
>
I'm forking off a new thread here.
A maven repository is a lovely place to keep all sorts of data used in
builds: test data, templates of on
after thinking more at it, it seems the "scope" for such artifacts is the
plugin parameter name
so why not resolve artifacts (or collections of artifacts) when injecting
parameters?
I'm not sure we really need a need elemen in pom.
Regards,
Hervé
Le samedi 12 avril 2014 10:14:51 Robert Schol
Le vendredi 11 avril 2014 15:10:01 Chris Graham a écrit :
> Sent from my iPhone
>
> On 11/04/2014, at 9:23 AM, Barrie Treloar wrote:
> > On 10 April 2014 23:37, Lennart Jörelid wrote:
> >> So ... the consequence of your approach would be that POMs throughout a
> >> maven reactor would have to re
Oh I know it is the recommended practise, but I believe that particular
recommendation is flawed since it does not consider the needs of *big*
systems with reactors containing lots of projects.
Basically the recommendation is to repeat some information (i.e. dependency
specs) which is already impli
Op Fri, 11 Apr 2014 23:50:54 +0200 schreef Benson Margulies
:
On Fri, Apr 11, 2014 at 5:29 PM, Stephen Connolly
wrote:
On 11 April 2014 22:10, Benson Margulies wrote:
>
> Fwiw, I don't recall the dependency plugin actually injecting stuff
into
> the project class path but equally wish t
15 matches
Mail list logo
