I have my itch scratched on the 2.6 branch. If anyone else wants to
pull something else onto the branch before I release 2.6.0, please
speak up.
On Sun, Oct 4, 2015 at 6:03 PM, Benson Margulies wrote:
> OK, will do.
>
>
> On Sun, Oct 4, 2015 at 5:54 PM, Karl Heinz Marbaise wrote:
>> Hi Benson,
>
OK, will do.
On Sun, Oct 4, 2015 at 5:54 PM, Karl Heinz Marbaise wrote:
> Hi Benson,
>
> just update the branch. I have checked in a fix for that...
>
> You need simply to define Java 6 as target/source otherwise the parent will
> control that which is there by default 1.5...
>
> I would suggest
Hi Benson,
just update the branch. I have checked in a fix for that...
You need simply to define Java 6 as target/source otherwise the parent
will control that which is there by default 1.5...
I would suggest to make 2.6.0 which identifies as JDK
6...requirement3.0.0 should be reserved f
What can I do to help move the 3.0 effort along?
Or, alternatively, what would it take to get a consensus to move to
Java 1.6 for m-a-p 2.6?
I'm stuck on...
The version of plexus I need to get the feature I want requires 1.6,
and the existing code is insisting on 1.5.
[INFO] --- maven-enforcer-
On Oct 4, 2015 4:08 PM, "Dennis Lundberg" wrote:
> From what I have read we need to move all of maven-plugins to git in one
> go.
> See the thread "Full migration to Git" for more info
>
I guess I'll have to go tune into that thread.
>
> 2015-10-04 14:07 GMT+02:00 Benson Margulies :
> > OK, th
Hi,
i needed to change the build server configuration for the
maven-shared-utils job...
https://builds.apache.org/view/M-R/view/Maven/job/maven-shared/
In the previous configuration the checkout was simply done by an update
via Subversion...now it first deletes unversioned/ignored files and
Hi,
On 10/4/15 10:03 PM, Dennis Lundberg wrote:
Hi,
IIRC maven-shared-utils uses a bunch of Apache Commons components
under the hood. The shading might be to not expose the commons
artifacts to the users of maven-shared-utils.
The bunch of commons components comprises exactly of:
commons-io.
2015-10-04 22:14 GMT+02:00 Tibor Digana :
> Dennis, is there any issue with incompatibility between versions of Apache
> Commons?
Usually no. Commons takes compatibility issues seriously.
> If there is no such, then maybe normal dependency inheritance would be
> useful.
I didn't do any coding my
Dennis, is there any issue with incompatibility between versions of Apache
Commons?
If there is no such, then maybe normal dependency inheritance would be
useful.
On Sun, Oct 4, 2015 at 10:03 PM, Dennis Lundberg wrote:
> Hi,
>
> IIRC maven-shared-utils uses a bunch of Apache Commons components
>
+1 to retire it
2015-10-04 11:18 GMT+02:00 Robert Scholte :
> Hi,
>
> during the latest upgrade of the plugin-parent I faced several issues with
> the maven-eclipse-plugin.
> It will take quite some time to fix these issues, but is it worth
> maintaining it here?
> Nowadays the Maven support for E
>From what I have read we need to move all of maven-plugins to git in one go.
See the thread "Full migration to Git" for more info
2015-10-04 14:07 GMT+02:00 Benson Margulies :
> OK, then, I want to move it to git first. Any objections?
>
>
> On Sun, Oct 4, 2015 at 7:27 AM, Karl Heinz Marbaise wr
Hi,
IIRC maven-shared-utils uses a bunch of Apache Commons components
under the hood. The shading might be to not expose the commons
artifacts to the users of maven-shared-utils.
2015-10-01 22:17 GMT+02:00 Karl Heinz Marbaise :
> Hi,
>
> just a question on understanding...
>
> Can someone explain
@Igor
Currently I should use Takari extensions, but in the future Maven should be
incremental IMHO.
This was discussed with Robert in ApacheCON as well as circumstances when
the project can be incremental.
I am sure that the build may in certain circumstance skip incremental
facilities.
We discusse
I'd let animal-sniffer remember what classes it scanned last build and
process only changed/new classes (and clean up messages related to the
deleted classes). This is how we implemented incremental build behaviour
in takari lifecycle. You may also want to have a look at
io.takari.incrementalbuild
+1 to retire.
/Anders
On Sun, Oct 4, 2015 at 5:48 PM, Tamás Cservenák wrote:
> +1 retire it
>
> On Sun, Oct 4, 2015, 17:01 Arnaud Héritier wrote:
>
> > +1 to retire it from Apache and to give it to MojoHaus where
> contributions
> > are easier if some users want to give him some love.
> >
> >
Good point and how to restore the state and skip one plugin depending on
run of other plugin if previous run was successful?
On Sun, Oct 4, 2015 at 8:53 PM, Robert Scholte-4 [via Maven] <
ml-node+s40175n5846977...@n5.nabble.com> wrote:
> Only if you store the state of animal-sniffer. If there are
Only if you store the state of animal-sniffer. If there are no classes to
compile, but previous run had an issue found by animal sniffer, it must
still fail either by rerunning animal-sniffer or displaying previous
result.
Robert
Op Sun, 04 Oct 2015 20:43:37 +0200 schreef Tibor Digana
:
I want to speed up the build and skip sniffer-plugin if "Nothing to compile
- all classes are up to date".
Do you think that maven-compiler-plugin can do it.
For instance to set POM $property if incremental compiler says "Nothing to
compile - all classes are up to date".
Cheers
Tibor
I don't think I need a branch for it. I only did a couple of branches for
those component related to Aether and Artifacts, shared-utils should be
fine.
Robert
Op Sun, 04 Oct 2015 16:18:23 +0200 schreef Tibor Digana
:
Yeah it's good to run straight ahead of 3.0 and jdk6.
Although Robert
+1 retire it
On Sun, Oct 4, 2015, 17:01 Arnaud Héritier wrote:
> +1 to retire it from Apache and to give it to MojoHaus where contributions
> are easier if some users want to give him some love.
>
> On Sun, Oct 4, 2015 at 11:18 AM, Robert Scholte
> wrote:
>
> > Hi,
> >
> > during the latest upg
Yes, we have a wiki page with an official procedure.
On Oct 4, 2015 9:11 AM, "Tibor Digana" wrote:
> @Benson
> Maybe no objections if you mention details of moving repo from svn / to
> github, etc.
> Do you mean that assembly will be fully git based in [1] which means I will
> be able to directly
On Sun, Oct 4, 2015 at 5:23 PM, Tibor Digana
wrote:
> How is the change working on CI? Is not there any escape codes around
> every line?
>
In Jenkins we have an ansi colors interpreter plugin. I need to check if it
will work correctly with Maven jobs.
Maybe for users who don't like colors or f
How is the change working on CI? Is not there any escape codes around
every line?
I guess jansi has or needs JNI lib or should be added for Win. Working on
all platforms?
On Sun, Oct 4, 2015 at 4:38 PM, Arnaud Héritier wrote:
> Hi all,
>
> After our exchanges this week at ApacheCon Core I wan
+1 to retire it from Apache and to give it to MojoHaus where contributions
are easier if some users want to give him some love.
On Sun, Oct 4, 2015 at 11:18 AM, Robert Scholte
wrote:
> Hi,
>
> during the latest upgrade of the plugin-parent I faced several issues with
> the maven-eclipse-plugin.
Hi all,
After our exchanges this week at ApacheCon Core I wanted to have a look
at what avoided us to provide for exemple in 3.4 a colorised output...
1/ Looking at this I found several issues related to a missing export of
classes from SLF4J:
https://issues.apache.org/jira/browse/MNG-5787
htt
+1 I understand Rotert's problem with this plugin. I would personally move
it away from Apache repo in GitHub because I think we should not dedicate
our spare time to maintain it. The only problem is who will have rights to
commit into it, or let the contributors to push pull requests like it is in
Yeah it's good to run straight ahead of 3.0 and jdk6.
Although Robert will branch last tag, I hope he does not have bottleneck on
it but anyway better to have 3.0 than nothing.
I have only problem with the dependency maven-core which was tools having
scope=provided. Very strict enforcer may fail th
I do not have explanation for that.
What SVN history says?
Who committed the change in POM?
On Thu, Oct 1, 2015 at 10:17 PM, Karl Heinz Marbaise
wrote:
> Hi,
>
> just a question on understanding...
>
> Can someone explain me why maven-shared-utils produces a shaded artifact
> instead a usual jar
Hi,
does someone has an explanation?
Kind regard
Karl Heinz Marbaise
On 10/1/15 10:17 PM, Karl Heinz Marbaise wrote:
Hi,
just a question on understanding...
Can someone explain me why maven-shared-utils produces a shaded artifact
instead a usual jar file ?
Kind regards
Karl Heinz Marbaise
@Benson
Maybe no objections if you mention details of moving repo from svn / to
github, etc.
Do you mean that assembly will be fully git based in [1] which means I will
be able to directly push to GitHub and the pull-requests as well?
[1] https://github.com/apache/maven-plugins/tree/trunk/maven-ass
On 4 October 2015 at 19:48, Robert Scholte wrote:
> Hi,
>
> during the latest upgrade of the plugin-parent I faced several issues with
> the maven-eclipse-plugin.
> It will take quite some time to fix these issues, but is it worth
> maintaining it here?
> Nowadays the Maven support for Eclipse is
Hi,
at the moment i have the maven-shared-utils upgraded to 3.0 dependencies
etc...
From my point of view it looks ok...
WDYT ?
I would like to start with the release within this week...
Kind regards
Karl Heinz Marbaise
-
T
OK, then, I want to move it to git first. Any objections?
On Sun, Oct 4, 2015 at 7:27 AM, Karl Heinz Marbaise wrote:
> Hi,
>
>
> On 10/4/15 10:58 AM, Robert Scholte wrote:
>>
>> Hmm, I see we tried to start with a 3.0.0 version, so not on the trunk.
>>
>> Assembly is far from ready as M3-only, s
I don't want to go into these kind of details yet, there are more things
which needs to be done.
Let's first agree that we don't want to maintain it here anymore. Since
there's still need for the plugin, mojohaus seems to be the best place to
continue its development.
Robert
Op Sun, 04
+0.5.
Having been using M2E for almost 10 years, granted, was touchy in the
beginning, but wo issue nowaways,
I guess that if it comes to MojoHaus we should put a notice for newcomers
that they're likely more looking for M2E than using it.
Btw, if it comes to MojoHaus I suppose you plan to change
Hi,
On 10/4/15 10:58 AM, Robert Scholte wrote:
Hmm, I see we tried to start with a 3.0.0 version, so not on the trunk.
Assembly is far from ready as M3-only, so I suggest branching the latest
tag.
Yes that's the way to make a fix release...
Kind regards
Karl Heinz Marbaise
thanks,
Robert
Hi,
during the latest upgrade of the plugin-parent I faced several issues with
the maven-eclipse-plugin.
It will take quite some time to fix these issues, but is it worth
maintaining it here?
Nowadays the Maven support for Eclipse is good and stable.
The maven-eclipse-plugin has a lot of int
Hmm, I see we tried to start with a 3.0.0 version, so not on the trunk.
Assembly is far from ready as M3-only, so I suggest branching the latest
tag.
thanks,
Robert
Op Fri, 02 Oct 2015 13:26:18 +0200 schreef Benson Margulies
:
Could we do this? I'm waiting on the 'snappy' support.
---
38 matches
Mail list logo
