Benson, I'm curious as to what you did, and also how it broke both for Git
users and other users. Any links/refs/bugs/emails/etc to read?
Was it just a case of leveraging features only available in very new
versions? A data point if so:
This sid laptop 2.1.3
My wheezy server 1.7.10.4
Work ucuntu
Of course with Perforce SCM where the crucial fix is for.
Thanks
-Dan
On Sat, Jun 27, 2015 at 9:40 AM, Dan Tran wrote:
> +1 none binding. Tested with both maven 3.2.x and 3.3.x
>
> Thanks Karl Heinz for doing this
>
> -Dan
>
> On Sat, Jun 27, 2015 at 8:02 AM, Karl Heinz Marbaise
> wrote:
>
>
Tibor,
Well, we'll see. Let's parse this situation into some smaller ones. We
don't need any votes. We need initiative coupled with enough time,
knowledge, and energy to make progress.
There's the maven core and the pom. Quite a while ago, I tried to push
this; but I don't have the necessary inte
+1 none binding. Tested with both maven 3.2.x and 3.3.x
Thanks Karl Heinz for doing this
-Dan
On Sat, Jun 27, 2015 at 8:02 AM, Karl Heinz Marbaise
wrote:
> Hi,
>
> this is only a bug fix release and based on the fix we required to use
> Java 1.6 Only (that is the reason for the version upgrad
2015-06-27 14:40 GMT+02:00 robert.patr...@oracle.com <
robert.patr...@oracle.com>:
>
> The second time, I tried to interact around someone else's problem with
> mvnDebug.cmd. No one ever responded.
>
That's not really true - people did respond, it's just that no one stood up
and put your suggest
Hi,
this is only a bug fix release and based on the fix we required to use
Java 1.6 Only (that is the reason for the version upgrade to 2.0.0).
We solved 2 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317525&version=12332831
There are still a couple of issues lef
@Benson
Excellent!
Since you have good inside of this problem you should post a Vote with this
list of activities and I hope that others will extend it.
As you and Robert Scholte described, the situation around
maven-release-plugin and SCM artifacts is pathetic. I hope Jason will bring
some ins
Hi,
We solved 5 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317422&version=12330698
There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MEAR%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%
Hi Robert,
On 6/27/15 2:40 PM, robert.patr...@oracle.com wrote:
I have only tried to interact a few times myself (others in my team have tried
as well).
> The first time, my team and I get a patch we submitted
>to enhance the wagon-http for SSO-protected repositories adopted
thanks to Olivie
To begin with, we have a lot more plugins than we have people to work on them.
Then, we have some critical functionality that is very fragile.
Perhaps this is because the problem is fundamentally hard. Perhaps it
is because the abstraction is fundamentally wrong.
In the case of git, where I think
I have only tried to interact a few times myself (others in my team have tried
as well). The first time, my team and I get a patch we submitted to enhance
the wagon-http for SSO-protected repositories adopted thanks to Olivier Lamy.
The second time, I tried to interact around someone else's pro
>> Which would exactly results in coded builds which is in the end much
>> more complicated and worse maintainable than any Maven build every be
I agreed that the build is worse maintainable after long time, but the
problem is that Java Hamcrest project, as an example, decided to use Graddle
Hi Robert,
On 6/27/15 12:51 PM, robert.patr...@oracle.com wrote:
Sorry for butting in but as someone who is a staunch supporter of
> Maven within my company and its user community,
> I have to agree that the difficulty in engaging
> the Maven developers to even discuss issues
> is too high.
F
>> And the team should be big enough to cover them all. Otherwise we should
just look for them.
Agree. So why not to introduce more committers.
This still sounds to me like we do not have environment to cover the fix in
tests on all SCM we support.
--
View this message in context:
http://mav
Exactly my plan
Op Sat, 27 Jun 2015 12:56:43 +0200 schreef Tibor Digana
:
@rfscholte
If the plugin needs redesign, I guess M3 is the rightest milestone for
that.
Everybody should accept that major version comes with breaking something
but
fixing a lot as well.
--
View this message in
"The trick is that the status cannot be worse then it is now."
Sadly that's not always true.
A good example are the GIT fixes in SCM, which should make it more robust,
but in the end did more harm than good, even with unittest included. For
the reporter it seemed to work, but not for the whole
@rfscholte
If the plugin needs redesign, I guess M3 is the rightest milestone for that.
Everybody should accept that major version comes with breaking something but
fixing a lot as well.
--
View this message in context:
http://maven.40175.n5.nabble.com/number-of-bugs-in-maven-release-plugin-tp5
Sorry for butting in but as someone who is a staunch supporter of Maven within
my company and its user community, I have to agree that the difficulty in
engaging the Maven developers to even discuss issues is too high. I often find
myself fixing plugins by forking my own private versions since
>> At least, without breaking stuff for existing users.
This has solution as well. Just accept the patch in a release with new
incremental version and release the plugin very often. You can always easily
ask in Jira to retest with a bunch of versions and identify where it started
not working and
>> And without the ability to verify both the bug and
the fix *I* won't apply those patches (unless the code clearly exposes the
issue).
This is the problem. My colleague told me to have a look in ASF JIRA and see
how many people provided patches. He said that he dislikes Maven community
beca
Some of the issues are mine. I'm pretty sure that at some point I realised
that to get it working properly for my use case would require forking it to
a privately released version. I guess now that it's mostly or all in git,
that's feasible. The conflicting requirements across SCMs, the highly
vari
It was even worse.
When I joined this team I started working on this plugin and managed to
close half of them ( let's say from 300 back to 150 issues).
Right now there's a situation where new issues are often easy to reproduce.
The older ones are often harder to reproduce or are already fixed.
22 matches
Mail list logo
