Probably because not a lot of folks are using it. It's a mistake, go ahead
and add it.
Thanks,
S.
On Thursday, February 20, 2014, Karl Heinz Marbaise
wrote:
> Hi,
>
> so after taken a look into SVN it looks a little bit strange to me.
>
> The entry for the maven-acr-plugin has been added in r10
Jason, Stephen, other PMC members,
I can't really know if there is behind-the-scenes pmc-only discussion
going on, but is there any chance to get 3.2.1 released this week?
I need to do legal/IP paperwork for upcoming m2e 1.5 release by
this coming Friday, and I would really like to list Maven 3.
Hi,
so after taken a look into SVN it looks a little bit strange to me.
The entry for the maven-acr-plugin has been added in r1087343
which is long time a go but the question is why does not appear on
the sites ?
Kind regards
Karl Heinz Marbaise
--
Hello Mirko,
Hello Anders,
this have been the information what i have missed...
Thanks for your help.
Kind regards.
Karl-Heinz
>
you may take a look at
https://github.com/mfriedenhagen/org.jacoco.filteringsamples. These
are some code samples for JDK5, 6, 7 and 8, which will be asmified
(decomp
Hi,
i just came across that the maven-acr-plugin is not listed on the page
http://maven.apache.org/plugins/index.html
The question is:
Should i create an jira issue for that and fix it afterwards or just fix
it ?
BTW: Do we have other plugins which are not listed on the page ?
Kind regards
sounds interesting.
WDYT folks?
On 19 February 2014 09:04, everflux wrote:
> GitHub user everflux opened a pull request:
>
> https://github.com/apache/maven-indexer/pull/3
>
> Update to lucene 4.6 with new API
>
> Please note that the version is changed for local development. You may
So we have nightlies/weeklies and post to the dev list, that's fine.
On Feb 19, 2014, at 12:27 PM, Benson Margulies wrote:
> I need to remind people about the Apache rules here. Yes you can have
> weekly builds. No you can't 'advertise them' in any way that is likely
> to attract the attention o
Hello Karl-Heinz,
you may take a look at
https://github.com/mfriedenhagen/org.jacoco.filteringsamples. These
are some code samples for JDK5, 6, 7 and 8, which will be asmified
(decompiled) to see differences in byte code produced by different
JDKs.
This is how the maven-compiler-plugin uses the t
I need to remind people about the Apache rules here. Yes you can have
weekly builds. No you can't 'advertise them' in any way that is likely
to attract the attention of mere users as opposed to people engaged in
the development community. Please don't shoot me, I'm just the
messenger here.
On Wed,
Hello,
If you include new functionality this means that according to semver you
increase the second digit, which means conservative users will do this upgrade
step not so easy anymore (and therefore miss all future fixes).
I would rather include enhancements anyway but divert from strict semve
One thing it can be used for is to define a different JDK to be used (than
the one used for executing Maven itself). More info here:
http://maven.apache.org/guides/mini/guide-using-toolchains.html
/Anders
On Wed, Feb 19, 2014 at 7:12 PM, Karl Heinz Marbaise wrote:
> Hi,
>
> maybe i didn't see a
Hi,
maybe i didn't see a thing, but can someone explain me the intention of
the maven toolchain in relationship with a plugin ...
Currently i only see that it can find some kind of executable which is
configured in somekind of buildcontext...which i currently don't
understand how to configur
Agreed, if they small enhancements then I don't really want to release 4 things
issues in a patch release and then another 5. Generally I'm fine with small
enhancements, or small fixes going into patch releases, along with anything
marked @provisional as I'd rather have the experimental code in
I don't see any necessity to restrict patch releases to patches only -- as
long as any new functionality is a tiny enhancement and doesn't make
incompatibilities. Save medium/major structural changes for a new minor
version.
On Wed, Feb 19, 2014 at 7:37 AM, Benson Margulies wrote:
> A bit of a r
A bit of a recap:
Let's say that our goal as a group was to be very responsive to user's
bug reports.
So, we'd want to make fixes and releases, 'promptly', for some
definition of prompt.
But no one will install those releases if they are not confident that
they are, in fact, not going to have un
+1. Totally for a (nonstrict) semver Maven.
Copied from the other thread for reference:
I think you'd have a lot more confidence in moving up to a newer maven.
>
> Enterprises will move to versions that they perceive as low risk. A true
> maintenance mode with a regular predictable release cade
On 19 February 2014 11:05, Fred Cooke wrote:
> Sorry, still working on your first email in this thread which never
> explicitly stated that, only implicitly, if your read the URL linked to,
> AND happened to know what state 3.2.X was in.
No worries
> You did indeed point this out
> at a later
Sorry, still working on your first email in this thread which never
explicitly stated that, only implicitly, if your read the URL linked to,
AND happened to know what state 3.2.X was in. You did indeed point this out
at a later date. My mistake. But the first email set the tone, which is
hard to sh
On 19 February 2014 10:13, Fred Cooke wrote:
> You missed the point. No-change commits include:
>
>- Clean up white space
>- Fix some comments in the code base
>- POM tweaks that don't affect binary output
>- Light genuine bonafide refactoring that causes no actual change in
>
You missed the point. No-change commits include:
- Clean up white space
- Fix some comments in the code base
- POM tweaks that don't affect binary output
- Light genuine bonafide refactoring that causes no actual change in
behaviour at all
There is zero point to releasing these thi
On 18 February 2014 22:49, Fred Cooke wrote:
> Perhaps a stupid question, however if no change goes in, and it kicks off
> and gives the same gold star as the previous week, then there's no point to
> releasing it, because it's the same thing, what takes care of this?
It will not work that way.
Thanks for bringing this up, Stephen!
My +1 goes to "backwards-compatible bug fixes (only)" in a bugfix/patch
release.
If we could decide (whatever we decide) what changes goes into what sort of
release, I think that would help the community a lot. I personally think
that re-using somehting like s
I think we have a bit of a disagreement about what changes should be going
into different version numbers.
To my mind, we should be using the convention that most people expect, i.e.
semver[1]-ish. I am not saying that we need to be super-strict in following
the exact semver specification, but I d
23 matches
Mail list logo
