Am 03/21/17 um 03:57 schrieb Apache Jenkins Server:
> See https://builds.apache.org/job/maven-3.x-jenkinsfile/job/MNG-6112/1/
>
Seems "null" does not always indicate a successful build. Can someone
take a look at this please and maybe update the Jenkinsfile to have a
subject indicating failures p
Am 03/20/17 um 20:25 schrieb Stephen Connolly:
> Hervé requested to go straight to beta.
>
> Since tags should be for the official release not alphas or betas imho
Ok. I'll update some since tags to 3.5.0 before the next release. No
need for a JIRA issue, right?
Regards,
--
Christian
ouch, "disabling" = "associating to an unknown phase": what a hack!
nice idea :)
there is no such phase association in reports: this hack for plugins can't be
used with reports
What can be done is adding some reportExcludes in maven-site-plugin
configuration: not so easy to configure and explai
even if we call the release beta-1, since alpha-2 is not wrong
and in the long term, we don't care about alphas or betas
Regards,
Hervé
Le lundi 20 mars 2017, 19:25:53 CET Stephen Connolly a écrit :
> Hervé requested to go straight to beta.
>
> Since tags should be for the official release not
GitHub user sesuncedu opened a pull request:
https://github.com/apache/maven-indexer/pull/16
MINDEXER-102 - indexer-reader OSGI changes forward ported to master
Forward ports index-reader changes from MINDEXER-97.
Requires/includes MINDEXER-100, which forward ports other c
GitHub user sesuncedu opened a pull request:
https://github.com/apache/maven-indexer/pull/15
MINDEXER-101 Forward port OSGI improvements to master branch
Forward port most OSGI related changes from 5.x to master branch.
Does not include changes to index-reader, as that requi
Hervé requested to go straight to beta.
Since tags should be for the official release not alphas or betas imho
On Mon 20 Mar 2017 at 18:48, Christian Schulte wrote:
> There will be no alpha-2? Should I update those @since tags to match the
> new beta-1 name? Maybe something to add to the other
+1
On 20 March 2017 at 18:18, Stephen Connolly wrote:
> Analyzer...
>
> stagingUrl: https://repository.apache.org/content/repositories/maven-1325
> groupId: org.apache.maven
> artifactId: apache-maven
> version: 3.5.0-beta-1
>
> Source ZIP url exists.
> https://repository.apache.org/content/repo
There will be no alpha-2? Should I update those @since tags to match the
new beta-1 name? Maybe something to add to the other discussions.
Regards,
--
Christian
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For addi
Hi,
We solved 15 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12339665&styleName=Text
There are still 10 issues left in JIRA for 3.5.0, but I do not think any
of those are blocking an beta release and perhaps could be descoped for
3.5.0:
https://issue
Analyzer...
stagingUrl: https://repository.apache.org/content/repositories/maven-1325
groupId: org.apache.maven
artifactId: apache-maven
version: 3.5.0-beta-1
Source ZIP url exists.
https://repository.apache.org/content/repositories/maven-1325/org/apache/maven/apache-maven/3.5.0-beta-1/apache-mav
Hi Stephen,
so moving to maven-3.5.0 or later until will have correct working tests
...and yes I see it the same having more tests to see where the real
issue is located...
I will change the target version...
Kind regards
Karl Heinz Marbaise
On 20/03/17 16:29, Stephen Connolly wrote:
Nope..
Nope... Nope... Nope...
System property parsing is not fixed...
May be better to add some more tests to MavenCliTest so that this can be
iterated faster
On 20 March 2017 at 15:11, Stephen Connolly wrote:
> If this does not fix the build then I am dropping this branch from the
> scope for Maven
If this does not fix the build then I am dropping this branch from the
scope for Maven 3.5.0-beta-1
If the build is fixed and all tests pass then we can include this... and
fix any bugs found in a beta-2... hopefully no bugs will be found so we can
call it 3.5.0 and move forward ;-)
On 20 March 2
Hi Hervé,
On 20/03/17 08:31, Hervé BOUTEMY wrote:
adding a skip parameter to every plugin is a workaround: better than nothing
should that be possible?
as a user, I want everything: I'd like it to be possible, or I'll be
frustrated because "Maven is inflexible" :)
;-)
the big question is m
+1 to the whole analysis on issue tracking vs scm
one addition: currently, our PR process is "asking for a second": IMHO, it
works
Regards,
Hervé
Le dimanche 19 mars 2017, 22:27:20 CET Elliot Metsger a écrit :
> Just two cents from a long-time list lurker:
>
> First, congrats on all the work
Hi,
Maxim Solodovnik wrote:
> then maybe copy/paste a little:
>
> configure all necessary reports in parent pom (exclude github-report)
> Then add github-report to all child projects except one
or configure the github-report in the parent in a profile that is activated
on existance of a "profi
IMHO, we don't have sufficient *team focus* on one version: how could we have
focus on multiple versions at the same time?
working on creating a scheme to let people work without the others on another
objective (which is supposed to be "the next one") is a recipe for split
developer efforts
Re
one thing we need: common focus for some time
there are so many directions followed by so many people at the same time that
nobody can't follow everything. And when it's about having Maven core evolve,
this is critical to have many people review and evaluate (it's less critical
for a plugin or
then maybe copy/paste a little:
configure all necessary reports in parent pom (exclude github-report)
Then add github-report to all child projects except one
On Mon, Mar 20, 2017 at 2:19 PM, Karl Heinz Marbaise wrote:
> Hi,
>
>
> On 20/03/17 07:54, Maxim Solodovnik wrote:
>>
>> Hello Karl,
>>
>>
Because unless the unit test suite has 100% line and branch coverage, and
possibly various
other metrics, all of which are unfeasible for any real-world sized code
base, it could miss
something. The first line should/must (if you care) be manual integration
of the two change
sets, conflicting, or n
ok
there is only one additional point: when things were working previously
because of special cases that were handled with specific code previously, the
change has to be done with extra care: that's where the general intent of
fixing things has the immediate opposite effect
Then always we caref
adding a skip parameter to every plugin is a workaround: better than nothing
should that be possible?
as a user, I want everything: I'd like it to be possible, or I'll be
frustrated because "Maven is inflexible" :)
the big question is more IMHO: is it possible to add this feature in a
consisten
Hi,
On 19/03/17 18:34, Stephen Connolly wrote:
Unlike the other discuss threads, I think I have some extra context that
means I am going to start from my proposal... or rather my requirements and
then proposal to solve those requirements.
Requirements
===
As a Release Manager,
I canno
Hi,
On 20/03/17 07:54, Maxim Solodovnik wrote:
Hello Karl,
I guess you can "skip" report for subproject?
In this case this is not possible cause I want to have the site except
for the maven-changes-plugin ...(github-report cause I don't have a
github project for it).
Kind regards
Karl He
On Mon 20 Mar 2017 at 00:44, Fred Cooke wrote:
> Sounds like the solution is for people to use a different remote that you
> don't feel personally responsible for checking every commit in. And to fix
> the email system.
>
> Split emails for commits on master to everyone and a new list for other
>
26 matches
Mail list logo
