Hmmm in reviewing the code provenance I notice that
https://svn.apache.org/viewvc?view=revision=1791757 was merged
without bumping the pom version to 3.0.0.
Should we drop and respin with 3.0.0 as the release version?
Otherwise all looks good to me, but I'd rather get opinion on the version
Nope IIRC the intent of MENFORCER-267 is that the version should be 3.0.0
(hence the Fix Version)
On 20 June 2017 at 04:14, Anders Hammar wrote:
> v2.0.0?
>
> /Anders
>
> On Tue, Jun 20, 2017 at 12:53 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > Hmmm
How is this possible? I ran the UTs twice. Did you check the dep tree? 3.0.0
should have been mediated.
> Gesendet: Montag, 19. Juni 2017 um 22:13 Uhr
> Von: "Guillaume Boué"
> An: dev@maven.apache.org, "Michael Osipov"
> Betreff: Re: svn commit:
v2.0.0?
/Anders
On Tue, Jun 20, 2017 at 12:53 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> Hmmm in reviewing the code provenance I notice that
> https://svn.apache.org/viewvc?view=revision=1791757 was merged
> without bumping the pom version to 3.0.0.
>
> Should we drop and
Hi,
We solved 14 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317520=1253=Text
There are still a couple of issues left in JIRA:
as explained in the git migration status [1], the biggest issue with plugins 1
svn repo to 41 git repo migration is the maintenance of Jenkins job files, with
their java + maven version matrix.
With Jenkinsfile as worked out in Mavne core, same type of configuration could
help us to change our
Stephen knows more the ASF infra than me to tell if it is possible but in
Jenkins we have the notion of organization folder for GitHub which allow to
automatically browse an org in GitHub and create/update/delete
multibranches jobs for each repo. If we can also create shared libraries in
Jenkins
On Tue 20 Jun 2017 at 20:29, Arnaud Héritier wrote:
> Stephen knows more the ASF infra than me to tell if it is possible but in
> Jenkins we have the notion of organization folder for GitHub which allow to
> automatically browse an org in GitHub and create/update/delete
>
+1 for me
On Wed, Jun 21, 2017 at 12:02 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> On Tue 20 Jun 2017 at 20:29, Arnaud Héritier wrote:
>
> > Stephen knows more the ASF infra than me to tell if it is possible but in
> > Jenkins we have the notion of
On Tue, Jun 20, 2017 at 11:36 AM, Jochen Wiedmann wrote:
> On Tue, Jun 20, 2017 at 7:01 PM, Owen O'Malley
> wrote:
>
> >Is there already a plugin for storing the transitive dependency
> > information in the jar's META-INF as part of the
Owen O'Malley wrote:
> On Tue, Jun 20, 2017 at 11:36 AM, Jochen Wiedmann
> > wrote:
>
>> On Tue, Jun 20, 2017 at 7:01 PM, Owen O'Malley
>> wrote:
>>
>> >Is there already a plugin for storing the transitive dependency
>> > information in
Maybe you are looking for
https://github.com/nanosai/modrun
Verzonden vanaf Samsung Mobile.
Oorspronkelijk bericht Van: Owen O'Malley
Datum:20-06-2017 19:01 (GMT+01:00)
Aan: dev@maven.apache.org Onderwerp: Is there a maven
plugin for storing the
Yes, 3.0.0 is selected during conflict resolution. And this is part of
the issue: some classes of plexus-io 2.7.1, on which plexus-archiver 3.4
depends on, were removed in 3.0.0. So they are not present within the
resolved dependencies because 2.7.1 was (rightfully) omitted.
Did you run them
Hi all,
Is there already a plugin for storing the transitive dependency
information in the jar's META-INF as part of the build? I'd like to build a
dynamic class loader that would be similar to shared libraries on
Linux/Unix, but part of that is that I need the dependency information
stored in
On Tue, Jun 20, 2017 at 7:01 PM, Owen O'Malley wrote:
>Is there already a plugin for storing the transitive dependency
> information in the jar's META-INF as part of the build? I'd like to build a
> dynamic class loader that would be similar to shared libraries on
>
15 matches
Mail list logo