+1
On 27 October 2015 at 09:21, Hervé BOUTEMY wrote:
> Hi,
>
> This is the first release of this new plugin.
> The JDeps Plugin uses the jdeps tool to analyze classes for internal API
> calls. For more information about the standard jdeps tool, please refer to
> Java+Dependency+Analysis+Tool.
>
+1
On Tue, Oct 27, 2015 at 4:20 PM, Karl Heinz Marbaise wrote:
> Hi,
>
> i need one more binding VOTE...
>
> Kind regards
> Karl Heinz Marbaise
>
> On 10/24/15 12:48 PM, Karl Heinz Marbaise wrote:
>>
>> Hi,
>>
>> We solved 7 issues:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?pro
Hi,
i need one more binding VOTE...
Kind regards
Karl Heinz Marbaise
On 10/24/15 12:48 PM, Karl Heinz Marbaise wrote:
Hi,
We solved 7 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921&version=12333008
There are still a couple of issues left in JIRA:
https://i
Related to Java versions, Apache jclouds uses modernizer-maven-plugin to
encourage use of modern Java APIs such as ArrayList,
String.getBytes(Charset), etc.:
https://github.com/andrewgaul/modernizer-maven-plugin
On Tue, Oct 27, 2015 at 01:49:41PM -0200, Vinicius Corrêa de Almeida wrote:
> I anali
We are just moved to java7 and start using new features
I personally don't like the idea of moving all code to new java, I move the
areas I currently work on
On Tue, Oct 27, 2015 at 10:57 PM, Gary Gregory
wrote:
> Hi,
>
> What I see, is that most projects are struggling to move to Java 7, Java 8
Hi,
What I see, is that most projects are struggling to move to Java 7, Java 8
seems out of range. There are a lot of opinions and both sides of each Java
version for and against. At the end of the day, it's about user feedback
and committer community involvement. The projects I help on also lack
Hi Vinicius,
it is mostly to allow people which are bound (for any reason) to older
JDK versions to use our software. There is a plenty number of projects
which are not able to use newer JDK versions. I know that this is a
controversial topic I think that the majority of us would like to u
If we went this route, it would be a new packaging type you opt into. It would
purely be an additive change so wouldn’t affect any existing behaviour but only
taking advantage of what we have for something like the WAR file. We may find
this is insufficient but I don’t know without trying.
> On
Ok, no worries, as I said already, them version numbers are cheap
(being and infinite supply of them and all that)
On 27 October 2015 at 14:32, Jason van Zyl wrote:
> Appears to be 3.3.7-SNAPHOT on master so I burned another one.
>
>> On Oct 27, 2015, at 7:28 AM, Stephen Connolly
>> wrote:
>>
>
I like the idea of a shaded-jar if we can make
it work... though it does mean that anyone consuming poms outside of
Maven will no longer be able to build the dependency graph without
being aware of this special packaging...
(plus there is also a set of use-cases from the flatten-maven-plugin
and g
I analized some releases and i noticed that not using java 7 features like
multi catch and in java 8 do not use lambda expressions and others
features, so i came by this email to know why the developers not using this
features?
On October 27, 2015 4:08:11 PM Jason van Zyl wrote:
So I think we have then opportunity to model this correctly and we have
something similar already in a WAR. We have a handler that clips all
transitive dependencies. There would be a bit more work but if we make a
separate packaging, build o
So I think we have then opportunity to model this correctly and we have
something similar already in a WAR. We have a handler that clips all transitive
dependencies. There would be a bit more work but if we make a separate
packaging, build out the classpath correctly during the build we can prob
On Tue, Oct 27, 2015 at 10:40 AM, Igor Fedorenko wrote:
> I think this only highlights the need to have immutable core model. The
> bundle plugin has no way to know how the shade plugin manipulates the
> pom and the generated bundle manifest will be based on original project
> model. (assuming I u
I think this only highlights the need to have immutable core model. The
bundle plugin has no way to know how the shade plugin manipulates the
pom and the generated bundle manifest will be based on original project
model. (assuming I understand your suggested usecase)
--
Regards,
Igor
On Tue, Oct
Appears to be 3.3.7-SNAPHOT on master so I burned another one.
> On Oct 27, 2015, at 7:28 AM, Stephen Connolly
> wrote:
>
> I thought the last failed spin was 3.3.5 so we should be spinning
> 3.3.6... but hey I don't mind, version numbers are cheap
>
> On 27 October 2015 at 14:09, Igor Fedoren
I thought the last failed spin was 3.3.5 so we should be spinning
3.3.6... but hey I don't mind, version numbers are cheap
On 27 October 2015 at 14:09, Igor Fedorenko wrote:
> This was announced 7 days ago on this list
>
> http://mail-archives.apache.org/mod_mbox/maven-dev/201510.mbox/%3CFFA7C22B
On Tue, Oct 27, 2015 at 9:58 AM, Igor Fedorenko wrote:
> Did you really mean "the core model has to be mutable"? The rest of your
> message appears to suggest you do not want the model to be mutable, but
> I am not sure.
>
> In any case, I think the core model must not be mutable. If the core
> mo
This was announced 7 days ago on this list
http://mail-archives.apache.org/mod_mbox/maven-dev/201510.mbox/%3CFFA7C22B-DD49-40C7-8D78-2C6D02B87D97%40takari.io%3E
--
Regards,
Igor
On Tue, Oct 27, 2015, at 09:54 AM, Michael Osipov wrote:
> > I’m going to start cutting the 3.3.7 now.
>
> Jason,
>
No, I meant immutable.
> On Oct 27, 2015, at 6:58 AM, Igor Fedorenko wrote:
>
> Did you really mean "the core model has to be mutable"? The rest of your
> message appears to suggest you do not want the model to be mutable, but
> I am not sure.
>
> In any case, I think the core model must not be
Did you really mean "the core model has to be mutable"? The rest of your
message appears to suggest you do not want the model to be mutable, but
I am not sure.
In any case, I think the core model must not be mutable. If the core
model is mutable, this means pom.xml is not the ultimate source of tr
> I’m going to start cutting the 3.3.7 now.
Jason,
could you announce this at least five days in advance? That would give at least
some timeframe to merge PRs and handle issues.
Michael
-
To unsubscribe, e-mail: dev-unsubscr..
According to [1], we're still at 3.3.3, aren't we?
1: http://maven.apache.org/download.cgi
On Tue, Oct 27, 2015 at 2:44 PM, Jason van Zyl wrote:
> I’m going to start cutting the 3.3.7 now.
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Fou
I’m going to start cutting the 3.3.7 now.
Thanks,
Jason
--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-
Three people can ke
Github user jvanzyl commented on the pull request:
https://github.com/apache/maven/pull/70#issuecomment-151499565
Then I donât see an issue with merging it.
> On Oct 27, 2015, at 4:38 AM, barthel wrote:
>
> The default behavior is do nothing. The ITs doesn't show an
+1
> On Oct 26, 2015, at 3:21 PM, Hervé BOUTEMY wrote:
>
> Hi,
>
> This is the first release of this new plugin.
> The JDeps Plugin uses the jdeps tool to analyze classes for internal API
> calls. For more information about the standard jdeps tool, please refer to
> Java+Dependency+Analysis+T
The core model has to be mutable. I think there can be an ancillary model that
carried other types of information like the dependency reduction. But mutation
and re-consumption within the reactor I think is a bad idea and the
complication enumerated below seems fairly extreme. Do you have a conc
Changing the default behaviour of anything resolution related mid 3.x line is
likely not a good idea. We definitely need to run the ITs with any changes like
these to see what happens. Changing the way resolution works is definitely a
4.x thing.
> On Oct 27, 2015, at 1:42 AM, michael-o wrote:
+1
Arnaud
On Mon, Oct 26, 2015 at 11:21 PM, Hervé BOUTEMY
wrote:
> Hi,
>
> This is the first release of this new plugin.
> The JDeps Plugin uses the jdeps tool to analyze classes for internal API
> calls. For more information about the standard jdeps tool, please refer to
> Java+Dependency+Anal
Github user barthel commented on the pull request:
https://github.com/apache/maven/pull/70#issuecomment-151463857
The default behavior is ``do nothing``. The ITs doesn't show any errors at
this modifications.
---
If your project is set up for it, you can reply to this email and have
Context: MNG-5899 [1] which was originally reported as MSHADE-206 [2]
I understand why the change[3] was made... but this change breaks
about 80-90% of the use cases for the shade plugin...
Is there any way we can consider a compromise?
I think it should be permitted for a plugin to replace the
Github user michael-o commented on the pull request:
https://github.com/apache/maven/pull/70#issuecomment-151415114
@jvanzyl Are you saying that you dislike to change the default behavior,
i.e., no merge? @barthel Did you run the ITs before and after your change?
---
If your project
32 matches
Mail list logo
