Re: Maven Web Site

[Karl Heinz Marbaise]

Hi Jon,

always intrested in improvements...

can you make a JIRA issue and attach the patch to the issue ...so i can 
take a look within the next days...


Kind regards
Karl Heinz

On 7/7/16 5:23 PM, Jon Harper wrote:

Hello,
is anyone interested in this very small change for fluido and doing an 1.6
release ?
Jon

Jon

On Wed, Apr 27, 2016 at 7:05 PM, Jon Harper  wrote:


Hi Karl,
congratulations on improving fluido and releasing fluido 1.5 in february.

I tried enabling Bootstrap's 2 responsive mode on
https://maven.apache.org and I thought that it was better than the
current version. Please see a demo here:
http://jonenst.github.io/maven-site/ .
I also added preview images of the main the page using firefox
"Responsive Design View".

The only difference between the two types of images is the inclusion
of the responsive css as per
http://getbootstrap.com/2.3.2/scaffolding.html#responsive .

Note that the responsive mode does significant changes only on
displays of width 767 pixels or less. Above 767px, the changes are very
minor (tiny adjustments to fonts, columns and gutters sizes).

Did you try enabling the responsive mode? Was there something
preventing you from using it ? The only drawback I see is that devices
with 767 pixels have a bigger menu than needed, but:
- the current mode already has some problems (text and images going
outside of the menu, less size of the content).
- there are almost no devices in the 610-767 range. (see
http://mydevice.io/devices/ ). For 600px width, the menu still looks
big but not as oversized as for 767 pixels and using it this way is an
improvement.

Could there be a 1.6 release with the responsive mode enabled ? It's a
very small change (I read in the thread that small improving changes
are welcome until fluido 2.0 is released).

Regards,
Jon
Jon


On Mon, Apr 6, 2015 at 8:30 PM, Raphael Ackermann
 wrote:

Of course the goal is to have a good desktop experience as well as a good
mobile experience. That's done with media queries breakpoints. See for
example


http://www.smashingmagazine.com/2013/03/01/logical-breakpoints-responsive-design/


If css from e.g. bootstrap is used http://getbootstrap.com/  then you

get

support for mobile for free. Kind of ;)

On Mon, Apr 6, 2015 at 7:07 PM Hervé BOUTEMY 

wrote:



Le lundi 6 avril 2015 16:31:20 Raphael Ackermann a écrit :

It is now usable on android chrome 5" phone. Before the right nav/box

was

using up the whole screen. now the content starts.

Left side navigation is cut off and link/titles from left navigation

are

overlapping text a bit. But it's a start.

Reflow looks very nice on mobile and I think websites these days need

to

work on mobile.

Reflow just moves the navigation away from the left side on mobile.

They

same could be achieved with the fluido skin by fixing/changing the

css.

mobile should have menu on top, but I definitely prefer menu on left on

my

desktop



Raphael

On Mon, Apr 6, 2015 at 4:41 PM Karl Heinz Marbaise 

Re: Is there a reason extensions in ".mvn/extensions.xml" don't seem to support configuration?

[Christofer Dutz]

Oh,

well I would have a use case for it. 
I am currently working on bringing more and more parts of Apache Flex from Ant 
to Maven. Here in a lot of places I have dependencies that are not yet 
available as Maven artifacts. While I managed to get in contact with quite some 
of the people maintaining those projects and to publish some of them at Maven 
Central, there still are quite some where my only solution is to have them 
downloaded via ANT and use scope=system for that, but I really hate that.

For the FlexSDK I created a maven extension which intercepts Mavens dependency 
resolution requests and if not being able to resolve, it manually produces 
maven artifacts. 

Now I thought it would be great to have a Maven extension that does this on a 
simpler basis, but on a more generic basis. I would like to define the 
extension in the extensions.xml file, but provide it with the configuration to 
produce the missing artifacts on the fly. I was thinking of reading a config 
file, located relative to the extensions.xml, but would prefer the 
configuration in the extensions.xml option.

I would be happy to be of assistance, but first I have to start and finish 
another thing I volunteered for first :-)

Chris





On 2016-07-05 18:48 (+0200), Igor Fedorenko  wrote: 
> The latter. My original prototype had configuration support (may still> 
> have the code somewhere, not sure) but we took it out because we didn't> 
> have immediate usecase and didn't want to commit to any specific format> 
> and api without clear understanding how it was going to be used..> 
> 
> -- > 
> Regards,> 
> Igor> 
> 
> On Tue, Jul 5, 2016, at 04:57 AM, Christofer Dutz wrote:> 
> > Hi,> 
> > > 
> > > 
> > I just noticed that the extensions.xml doesn't seem to support> 
> > configuring an extension. Is this intentional because it would break> 
> > things or is it simply that none needed or implemented that functionality> 
> > yet?> 
> > > 
> > > 
> > Chris> 
> 
> -> 
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org> 
> For additional commands, e-mail: dev-h...@maven.apache.org> 
> 
>  

-- 

Mit freundlichen Grüßen | Best regards
Christofer Dutz | Senior IT Consultant

codecentric AG | Kreuzmacher Straße 30 | 60486 Frankfurt | Deutschland

fax: +49 (0) 69.71492-682 | mobil: +49 (0) 1525.3057806 <> 

www.codecentric.de  | blog.codecentric.de 
 | www.meettheexperts.de 
 | www.more4fi.de 


Sitz der Gesellschaft: Düsseldorf | HRB 63043 | Amtsgericht Düsseldorf
Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns
Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen Schütz

Diese E-Mail einschließlich evtl. beigefügter Dateien enthält vertrauliche 
und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige 
Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie 
bitte sofort den Absender und löschen Sie diese E-Mail und evtl. beigefügter 
Dateien umgehend. Das unerlaubte Kopieren, Nutzen oder Öffnen evtl. beigefügter 
Dateien sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Ralph Goers]

Actually, for me the ideal would be a command line switch that could re-enable 
the feature that was deprecated. Then you don’t really have to wait a release, 
so long as it is documented. This makes sure user’s are aware since they have 
to take a minor action to continue to make things work.

Ralph

> On Jul 7, 2016, at 9:27 AM, Paul Benedict  wrote:
> 
> Christian, you are right that introducing a warning does delay delivering
> the fix. Thanks for pointing that out. With that said, it's not all that
> bad because there are some choices...
> 
> 1) If 3.4-SNAPSHOT has a warning, make sure 3.5-SNAPSHOT has the fix
> enabled, and ask users@ to concurrently test both.
> 
> 2) A variation of #1, publish SNAPSHOT from the feature branch that
> contains the fix enabled.
> 
> 3) Do something Oracle-ish like introduce a command line option to enable
> prototype features. Pretending that -Z represents that new option, using
> -Z:MNG5277 would tentatively enable the fix and perhaps any -Z option
> would spit out a warning into the log saying you turned on an incomplete
> feature at your own risk.
> 
> To your point about "cluttering the different code bases", I personally
> just consider it a necessary development tax. Where's it possible, spit out
> the warning; otherwise not. Please also note option #3 also "clutters" even
> more by introducing if-checking for different behavior. Since I'd rather
> have less cluster than more, I personally prefer emitting the warning with
> a // TODO or // XXX marker in the code so the fix isn't not forgotten (with
> a reference to the MNG ticket).
> 
> Cheers,
> Paul
> 
> On Thu, Jul 7, 2016 at 11:12 AM, Christian Schulte  wrote:
> 
>> Am 07/07/16 um 17:49 schrieb Paul Benedict:
>>> If there is a change that will prevent a build from working, asking for
>>> users@ testing is not the way to do this. The way to do this is to
>>> introduce emit a "warning" first in the next version of Maven, and then
>>> convert it to an "error" in the next version after that. We can't just
>> say
>>> to users "hey, we may break your build now so please test" -- that's not
>>> nice of us. Let them test the warning, if anything, to make sure all
>> cases
>>> are correctly captured. If all cases are correctly captured, then
>>> converting the "warning" to an "error" will be simple.
>>> 
>>> I really propose we give users enough up-front notice that things are
>> going
>>> to break in a future build -- but not without introducing warnings into
>>> their build first. Let's give time for the community to correct their
>> POMs
>>> without creating emergency changes for developers.
>>> 
>> 
>> Then that's the way we are going to deliver bugfixes. So be it. Any news
>> on that 'feature toggle API'? Just emitting warnings everywhere is not
>> always possible. There is no logger available everywhere. I really would
>> like to capture things like these with an API. Having an API forcing you
>> to add references to issues in JIRA and so on you can search usages and
>> things like this. Cluttering the different codebases with warnings
>> everywhere whenever a bug is found/a new feature is introduced means we
>> will not fix the bug/introduce the feature but add a warning. So noone
>> will have a chance to test builds with the bugs fixed/features enabled.
>> Maybe we add a '-pedantic' command line option users can use to test
>> "what will happen when Maven does error out instead of warning me".
>> Someone still working on that MNG-6056 branch? We really need a shared
>> component for this. It's not only about Maven core. Do we all agree on
>> those feature toggles, BTW?
>> 
>> Regards,
>> --
>> Christian
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>> 



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Gary Gregory]

On Thu, Jul 7, 2016 at 8:49 AM, Paul Benedict  wrote:

> If there is a change that will prevent a build from working, asking for
> users@ testing is not the way to do this. The way to do this is to
> introduce emit a "warning" first in the next version of Maven, and then
> convert it to an "error" in the next version after that. We can't just say
> to users "hey, we may break your build now so please test" -- that's not
> nice of us. Let them test the warning, if anything, to make sure all cases
> are correctly captured. If all cases are correctly captured, then
> converting the "warning" to an "error" will be simple.
>
> I really propose we give users enough up-front notice that things are going
> to break in a future build -- but not without introducing warnings into
> their build first. Let's give time for the community to correct their POMs
> without creating emergency changes for developers.
>

+1, just like when you deprecate an API in Java.

The trick for Maven is to define what deprecation means for itself.

Of course that does not help you when you jump multiple versions at once,
but at least you can then go back and update one version at a time.

Gary


>
> Cheers,
> Paul
>
> On Wed, Jul 6, 2016 at 4:44 PM, Christian Schulte  wrote:
>
> > Am 07/06/16 um 23:32 schrieb Christian Schulte:
> > > Am 07/06/16 um 23:19 schrieb Christian Schulte:
> > >> Am 07/06/16 um 22:41 schrieb Stuart McCulloch:
> > >>> On Wednesday, 6 July 2016 at 20:46, Karl Heinz Marbaise wrote:
> >  Hi to all Maven users,
> > 
> >  If you like to help making the next Maven release better it would be
> >  nice if you could help a little bit.
> > 
> >  Please be aware of this *** This is not an official release ***
> > 
> >  I have created downloadable packages which are available from here:
> > 
> >  Windows: https://s.apache.org/qDs1
> >  Linux/Mac: https://s.apache.org/Sn7X
> > 
> >  Every kind of feedback is helpful.
> > 
> >  Important hint:
> > 
> >  Based on the following issue
> >  https://issues.apache.org/jira/browse/MNG-5227 the optional flag
> in a
> >  dependencyManagement was simply ignored with previous Maven
> versions.
> >  This Maven version starts to handle that correct. If you have
> problems
> >  with that please report.
> > 
> > 
> > >>>
> > >>> I believe this build (git hash
> > 227085283b6379038ec16f4cf9ad2e8869cef694) doesn’t actually contain the
> fix
> > for MNG-5227. The previous testing snapshot built from
> > 644ac9c40ad41bf61e3b099918af33b8eb950621 did contain the fix for
> MNG-5227,
> > but the fix was reverted to avoid breaking builds which relied on the old
> > behaviour.
> > >>>
> > >>> (this is just based on my reading of the commit history)
> > >>
> > >> There is MNG-5935 which is fixed and has an impact on the optional
> flag
> > >> in dependency management. See this commit and its message.
> > >> <
> >
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=184f58ff83a6d043c695a07f1b1ae89630f6bc9e
> > >
> > >> and there is MNG-5227 which has an impact on the optional flag in
> > >> dependency management. See this commit and its message.
> > >> <
> >
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=09bfdee699443b2482d2427b5eff7226768b340a
> > >.
> > >> Someone on dev@ has reported that he is using the optional flag in
> > >> dependency management (setting it to true) and that he has noticed
> that
> > >> this starts working in 3.4-SNAPSHOT for him. I haven't asked if he
> > >> noticed it is not working before. What is important to know is that
> > >> before the fix for MNG-5935 all managed dependencies were implicitly
> > >> managing optional to false. Aether got updated to change the optional
> > >> flag from 'boolean' to 'Boolean' and Maven has not been updated to
> > >> reflect that. So instead of passing 'null' to Aether, it passed
> 'false'
> > >> meaning 'manage the optional flag to false' where it should have
> passed
> > >> 'null' meaning 'do not manage the optional flag in any way'.
> > >>
> > >
> > > To confuse everyone even more. The first 3.4-SNAPSHOT we asked users to
> > > test contained an Aether bugfix. That bugfix has lead to reports about
> > > missing 'test' dependencies. See this commit and it's message
> > > <
> >
> https://github.com/ChristianSchulte/aether-core/commit/da9708bf7321e25c2a74dddb893539f735135a6d
> > >
> > > and the description in the bugtracker
> > > .
> > > That bugfix has been reverted in 3.4 but will re-appear as soon as we
> > > update Aether which contains that bugfix correctly.
> > >
> > > Regards,
> > >
> >
> >
> > Long drum-roll here.
> >
> > What we were discussing on users@ was how we are going to ship bugfixes
> > like these to the users. Either they will notice something has not
> > worked before and starts working or they will not notice 

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Paul Benedict]

Christian, you are right that introducing a warning does delay delivering
the fix. Thanks for pointing that out. With that said, it's not all that
bad because there are some choices...

1) If 3.4-SNAPSHOT has a warning, make sure 3.5-SNAPSHOT has the fix
enabled, and ask users@ to concurrently test both.

2) A variation of #1, publish SNAPSHOT from the feature branch that
contains the fix enabled.

3) Do something Oracle-ish like introduce a command line option to enable
prototype features. Pretending that -Z represents that new option, using
-Z:MNG5277 would tentatively enable the fix and perhaps any -Z option
would spit out a warning into the log saying you turned on an incomplete
feature at your own risk.

To your point about "cluttering the different code bases", I personally
just consider it a necessary development tax. Where's it possible, spit out
the warning; otherwise not. Please also note option #3 also "clutters" even
more by introducing if-checking for different behavior. Since I'd rather
have less cluster than more, I personally prefer emitting the warning with
a // TODO or // XXX marker in the code so the fix isn't not forgotten (with
a reference to the MNG ticket).

Cheers,
Paul

On Thu, Jul 7, 2016 at 11:12 AM, Christian Schulte  wrote:

> Am 07/07/16 um 17:49 schrieb Paul Benedict:
> > If there is a change that will prevent a build from working, asking for
> > users@ testing is not the way to do this. The way to do this is to
> > introduce emit a "warning" first in the next version of Maven, and then
> > convert it to an "error" in the next version after that. We can't just
> say
> > to users "hey, we may break your build now so please test" -- that's not
> > nice of us. Let them test the warning, if anything, to make sure all
> cases
> > are correctly captured. If all cases are correctly captured, then
> > converting the "warning" to an "error" will be simple.
> >
> > I really propose we give users enough up-front notice that things are
> going
> > to break in a future build -- but not without introducing warnings into
> > their build first. Let's give time for the community to correct their
> POMs
> > without creating emergency changes for developers.
> >
>
> Then that's the way we are going to deliver bugfixes. So be it. Any news
> on that 'feature toggle API'? Just emitting warnings everywhere is not
> always possible. There is no logger available everywhere. I really would
> like to capture things like these with an API. Having an API forcing you
> to add references to issues in JIRA and so on you can search usages and
> things like this. Cluttering the different codebases with warnings
> everywhere whenever a bug is found/a new feature is introduced means we
> will not fix the bug/introduce the feature but add a warning. So noone
> will have a chance to test builds with the bugs fixed/features enabled.
> Maybe we add a '-pedantic' command line option users can use to test
> "what will happen when Maven does error out instead of warning me".
> Someone still working on that MNG-6056 branch? We really need a shared
> component for this. It's not only about Maven core. Do we all agree on
> those feature toggles, BTW?
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Christian Schulte]

Am 07/07/16 um 17:49 schrieb Paul Benedict:
> If there is a change that will prevent a build from working, asking for
> users@ testing is not the way to do this. The way to do this is to
> introduce emit a "warning" first in the next version of Maven, and then
> convert it to an "error" in the next version after that. We can't just say
> to users "hey, we may break your build now so please test" -- that's not
> nice of us. Let them test the warning, if anything, to make sure all cases
> are correctly captured. If all cases are correctly captured, then
> converting the "warning" to an "error" will be simple.
> 
> I really propose we give users enough up-front notice that things are going
> to break in a future build -- but not without introducing warnings into
> their build first. Let's give time for the community to correct their POMs
> without creating emergency changes for developers.
> 

Then that's the way we are going to deliver bugfixes. So be it. Any news
on that 'feature toggle API'? Just emitting warnings everywhere is not
always possible. There is no logger available everywhere. I really would
like to capture things like these with an API. Having an API forcing you
to add references to issues in JIRA and so on you can search usages and
things like this. Cluttering the different codebases with warnings
everywhere whenever a bug is found/a new feature is introduced means we
will not fix the bug/introduce the feature but add a warning. So noone
will have a chance to test builds with the bugs fixed/features enabled.
Maybe we add a '-pedantic' command line option users can use to test
"what will happen when Maven does error out instead of warning me".
Someone still working on that MNG-6056 branch? We really need a shared
component for this. It's not only about Maven core. Do we all agree on
those feature toggles, BTW?

Regards,
-- 
Christian


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [jira] [Created] (MNG-6059) Important use cases not covered, as child.inherit.append.path affects all children

[Christian Schulte]

Wouldn't it be better to re-open MNG-5951? Does not make much sense to
release 3.4 introducing this when there already is a ticket telling us
it does not fit the needs.

Regards,

Am 07/07/16 um 12:14 schrieb Andreas Sewe (JIRA):
> Andreas Sewe created MNG-6059:
> -
> 
>  Summary: Important use cases not covered, as 
> child.inherit.append.path affects all children
>  Key: MNG-6059
>  URL: https://issues.apache.org/jira/browse/MNG-6059
>  Project: Maven
>   Issue Type: Bug
>   Components: Inheritance and Interpolation
>  Environment: Apache Maven 3.4.0-SNAPSHOT 
> (227085283b6379038ec16f4cf9ad2e8869cef694; 2016-07-06T21:29:12+02:00)
> Reporter: Andreas Sewe
> 
> 
> The {{child.inherit.append.path}} attribute introduced with MNG-5951 
> unfortunately does not support the use case where the children of the element 
> with the attribute should follow different inheritance rules. Take a typical 
> configuration for Github, for example (taken from 
> ):
> 
> {noformat}
> 
>   
> scm:git:git://github.com/simpligility/ossrh-demo.git
>   
> scm:git:ssh://github.com:simpligility/ossrh-demo.git
>   http://github.com/simpligility/ossrh-demo/tree/master
> 
> {noformat}
> 
> If the {{ossrh-demo.git}} repository contains a child module called 
> {{some-module}}, then that child’s {{scm/url}} should become 
> {{http://github.com/simpligility/ossrh-demo/tree/master/some-module}} as per 
> the normal inheritance rules, but both the {{scm/connection}} and 
> {{scm/developerConnection}} URLs should remain unchanged.
> 
> Unfortunately, this is not possible with {{*child*.inherit.append.path}}, 
> which acts on all children simultaneously.
> 
> IMHO, this is a conceptual problem. In particular, setting 
> {{child.inherit.append.path}} on the *root* element to just control a single 
> child ({{project/url}}) feels wrong, as the attribute is in all likelihood 
> not even located close to the {{}} element it controls.
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Paul Benedict]

If there is a change that will prevent a build from working, asking for
users@ testing is not the way to do this. The way to do this is to
introduce emit a "warning" first in the next version of Maven, and then
convert it to an "error" in the next version after that. We can't just say
to users "hey, we may break your build now so please test" -- that's not
nice of us. Let them test the warning, if anything, to make sure all cases
are correctly captured. If all cases are correctly captured, then
converting the "warning" to an "error" will be simple.

I really propose we give users enough up-front notice that things are going
to break in a future build -- but not without introducing warnings into
their build first. Let's give time for the community to correct their POMs
without creating emergency changes for developers.

Cheers,
Paul

On Wed, Jul 6, 2016 at 4:44 PM, Christian Schulte  wrote:

> Am 07/06/16 um 23:32 schrieb Christian Schulte:
> > Am 07/06/16 um 23:19 schrieb Christian Schulte:
> >> Am 07/06/16 um 22:41 schrieb Stuart McCulloch:
> >>> On Wednesday, 6 July 2016 at 20:46, Karl Heinz Marbaise wrote:
>  Hi to all Maven users,
> 
>  If you like to help making the next Maven release better it would be
>  nice if you could help a little bit.
> 
>  Please be aware of this *** This is not an official release ***
> 
>  I have created downloadable packages which are available from here:
> 
>  Windows: https://s.apache.org/qDs1
>  Linux/Mac: https://s.apache.org/Sn7X
> 
>  Every kind of feedback is helpful.
> 
>  Important hint:
> 
>  Based on the following issue
>  https://issues.apache.org/jira/browse/MNG-5227 the optional flag in a
>  dependencyManagement was simply ignored with previous Maven versions.
>  This Maven version starts to handle that correct. If you have problems
>  with that please report.
> 
> 
> >>>
> >>> I believe this build (git hash
> 227085283b6379038ec16f4cf9ad2e8869cef694) doesn’t actually contain the fix
> for MNG-5227. The previous testing snapshot built from
> 644ac9c40ad41bf61e3b099918af33b8eb950621 did contain the fix for MNG-5227,
> but the fix was reverted to avoid breaking builds which relied on the old
> behaviour.
> >>>
> >>> (this is just based on my reading of the commit history)
> >>
> >> There is MNG-5935 which is fixed and has an impact on the optional flag
> >> in dependency management. See this commit and its message.
> >> <
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=184f58ff83a6d043c695a07f1b1ae89630f6bc9e
> >
> >> and there is MNG-5227 which has an impact on the optional flag in
> >> dependency management. See this commit and its message.
> >> <
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=09bfdee699443b2482d2427b5eff7226768b340a
> >.
> >> Someone on dev@ has reported that he is using the optional flag in
> >> dependency management (setting it to true) and that he has noticed that
> >> this starts working in 3.4-SNAPSHOT for him. I haven't asked if he
> >> noticed it is not working before. What is important to know is that
> >> before the fix for MNG-5935 all managed dependencies were implicitly
> >> managing optional to false. Aether got updated to change the optional
> >> flag from 'boolean' to 'Boolean' and Maven has not been updated to
> >> reflect that. So instead of passing 'null' to Aether, it passed 'false'
> >> meaning 'manage the optional flag to false' where it should have passed
> >> 'null' meaning 'do not manage the optional flag in any way'.
> >>
> >
> > To confuse everyone even more. The first 3.4-SNAPSHOT we asked users to
> > test contained an Aether bugfix. That bugfix has lead to reports about
> > missing 'test' dependencies. See this commit and it's message
> > <
> https://github.com/ChristianSchulte/aether-core/commit/da9708bf7321e25c2a74dddb893539f735135a6d
> >
> > and the description in the bugtracker
> > .
> > That bugfix has been reverted in 3.4 but will re-appear as soon as we
> > update Aether which contains that bugfix correctly.
> >
> > Regards,
> >
>
>
> Long drum-roll here.
>
> What we were discussing on users@ was how we are going to ship bugfixes
> like these to the users. Either they will notice something has not
> worked before and starts working or they will not notice anything and
> just complain the build is no longer working as before. And we cannot
> revert things like these for eternity.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Maven Web Site

[Jon Harper]

Hello,
is anyone interested in this very small change for fluido and doing an 1.6
release ?
Jon

Jon

On Wed, Apr 27, 2016 at 7:05 PM, Jon Harper  wrote:

> Hi Karl,
> congratulations on improving fluido and releasing fluido 1.5 in february.
>
> I tried enabling Bootstrap's 2 responsive mode on
> https://maven.apache.org and I thought that it was better than the
> current version. Please see a demo here:
> http://jonenst.github.io/maven-site/ .
> I also added preview images of the main the page using firefox
> "Responsive Design View".
>
> The only difference between the two types of images is the inclusion
> of the responsive css as per
> http://getbootstrap.com/2.3.2/scaffolding.html#responsive .
>
> Note that the responsive mode does significant changes only on
> displays of width 767 pixels or less. Above 767px, the changes are very
> minor (tiny adjustments to fonts, columns and gutters sizes).
>
> Did you try enabling the responsive mode? Was there something
> preventing you from using it ? The only drawback I see is that devices
> with 767 pixels have a bigger menu than needed, but:
> - the current mode already has some problems (text and images going
> outside of the menu, less size of the content).
> - there are almost no devices in the 610-767 range. (see
> http://mydevice.io/devices/ ). For 600px width, the menu still looks
> big but not as oversized as for 767 pixels and using it this way is an
> improvement.
>
> Could there be a 1.6 release with the responsive mode enabled ? It's a
> very small change (I read in the thread that small improving changes
> are welcome until fluido 2.0 is released).
>
> Regards,
> Jon
> Jon
>
>
> On Mon, Apr 6, 2015 at 8:30 PM, Raphael Ackermann
>  wrote:
> > Of course the goal is to have a good desktop experience as well as a good
> > mobile experience. That's done with media queries breakpoints. See for
> > example
> >
> http://www.smashingmagazine.com/2013/03/01/logical-breakpoints-responsive-design/
> >
> > If css from e.g. bootstrap is used http://getbootstrap.com/  then you
> get
> > support for mobile for free. Kind of ;)
> >
> > On Mon, Apr 6, 2015 at 7:07 PM Hervé BOUTEMY 
> wrote:
> >
> >> Le lundi 6 avril 2015 16:31:20 Raphael Ackermann a écrit :
> >> > It is now usable on android chrome 5" phone. Before the right nav/box
> was
> >> > using up the whole screen. now the content starts.
> >> >
> >> > Left side navigation is cut off and link/titles from left navigation
> are
> >> > overlapping text a bit. But it's a start.
> >> >
> >> > Reflow looks very nice on mobile and I think websites these days need
> to
> >> > work on mobile.
> >> >
> >> > Reflow just moves the navigation away from the left side on mobile.
> They
> >> > same could be achieved with the fluido skin by fixing/changing the
> css.
> >> mobile should have menu on top, but I definitely prefer menu on left on
> my
> >> desktop
> >>
> >> >
> >> > Raphael
> >> >
> >> > On Mon, Apr 6, 2015 at 4:41 PM Karl Heinz Marbaise  >
> >> >
> >> > wrote:
> >> > > Hi,
> >> > >
> >> > > i have improved the fluido part a little bit (removed the right
> >> > > navigation)
> >> > >
> >> > > and added an example with Reflow skin
> >> > >
> >> > > http://khmarbaise.github.io/maven-site/reflow/
> >> > > http://khmarbaise.github.io/maven-site/fluido/
> >> > >
> >> > >
> >> > > Kind regards
> >> > > Karl Heinz Marbaise
> >> > >
> >> > >
> -
> >> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> > > For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
>

Re: 3.4.0-SNAPSHOT failure with findbugs Re: colorized Maven output

[Arnaud Héritier]

FYI Garvin just released the findbugs plugin 3.0.4 which solves this issue.
Thanks Garvin

On Fri, Jun 10, 2016 at 11:01 PM, Arnaud Héritier 
wrote:

> yes it is exactly this one Stuart
>
> Thanks
>
> On Fri, Jun 10, 2016 at 10:46 PM, Stuart McCulloch 
> wrote:
>
>> On Friday, 10 June 2016 at 21:33, Arnaud Héritier wrote:
>>
>> I need to investigate but I have a bug with findbugs and 3.4.0-SNAPSHOT
>>
>> [ERROR] Failed to execute goal
>> org.codehaus.mojo:findbugs-maven-plugin:3.0.1:findbugs (findbugs) on
>> project support-analytics: Unable to parse configuration of mojo
>> org.codehaus.mojo:findbugs-maven-plugin:3.0.1:findbugs for parameter
>> pluginArtifacts: Cannot assign configuration entry 'pluginArtifacts' with
>> value '${plugin.artifacts}' of type
>> java.util.Collections.UnmodifiableRandomAccessList to property of type
>> java.util.ArrayList -> [Help 1]
>>
>> Is there someone who can verify that he can reproduce the issue with this
>> pom please ?
>>
>> https://github.com/gleclaire/findbugs-maven-plugin/pull/35 ?
>>
>> Cheers
>>
>>
>> On Fri, Jun 10, 2016 at 9:26 AM, Arnaud Héritier 
>> wrote:
>>
>> \o/
>>
>> On Fri, Jun 10, 2016 at 8:39 AM, Hervé BOUTEMY 
>> wrote:
>>
>> here it is:
>> I merged Christian fix
>> and I managed to make ITs run as embedded (ASF Jenkins should confirm what
>> works on my machine)
>>
>> if everything goes well, I'll merge to master tonight
>>
>> Regards,
>>
>> Hervé
>>
>> Le jeudi 9 juin 2016 09:20:38 Christian Schulte a écrit :
>> > Am 06/09/16 um 09:04 schrieb Petar Tahchiev:
>> > > Hello,
>> > >
>> > > I checked on Windows with Herve's [1]. Unfortunately I am unable to
>> build
>> > >
>> > > my project with 3.4.0-SNAPSHOT. I have this dependency:
>> > > 
>> > >
>> > > org.drools
>> > > drools-bom
>> > > pom
>> > > ${drools.version}
>> > > import
>> > >
>> > > 
>> > >
>> > > where drools version is defined to be
>> > > 6.4.0.Final. And when I build it I
>> get:
>> > >
>> > > [ERROR] Non-resolvable import POM: Failure to find
>> > > org.kie:kie-bom:pom:${project.version} in
>> http://repo1.maven.org/maven2/
>> > > was cached in the local repository, resolution will not be reattempted
>> > > until the update interval of official-m2-repo has elapsed or updates
>> are
>> > > forced @ org.drools:drools-bom:[unknown-version]
>> > > [org.drools:drools-bom:[unknown-version]],
>> > >
>> [C:\Users\e-tahchpet\.m2\repository\org\drools\drools-bom\6.4.0.Final\droo
>> > > ls-bom-6.4.0.Final.pom], line 27, column 19
>> >
>> > Could be a regression due to MNG-5971. It's reproducible here. Thanks
>> > for testing a SNAPSHOT Maven version.
>> >
>> > > If I comment this dependency then I see some colors on windows, but
>> at the
>> > > end of the build findbugs will break:
>> > >
>> > > [ERROR] Failed to execute goal
>> > > org.codehaus.mojo:findbugs-maven-plugin:3.0.1:findbugs (findbugs) on
>> > > project bom: Unable to parse configuration of mojo
>> > > org.codehaus.mojo:findbugs-maven-plugin:3.0.1:findbugs for parameter
>> > > pluginArtifacts: Cannot assign configuration entry 'pluginArtifacts'
>> with
>> > > value '${plugin.artifacts}' of type
>> > > java.util.Collections.UnmodifiableRandomAccessList to property of type
>> > > java.util.ArrayList -> [Help 1]
>> >
>> > That's already fixed upstream and will be fixed in the next FindBugs
>> > plugin release.
>> >
>> > <
>> https://github.com/gleclaire/findbugs-maven-plugin/commit/7954b94eff5c6b052
>> > 4e7fe26d8f114b3c5450b86>
>> >
>> > Regards,
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>>
>>
>> --
>> -
>> Arnaud Héritier
>> http://aheritier.net
>> Mail/GTalk: aheritier AT gmail DOT com
>> Twitter/Skype : aheritier
>>
>>
>>
>>
>> --
>> -
>> Arnaud Héritier
>> http://aheritier.net
>> Mail/GTalk: aheritier AT gmail DOT com
>> Twitter/Skype : aheritier
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>
>
>
> --
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>



-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

[GitHub] maven-plugins pull request #87: Reintroduce verbose support for dependency:t...

[retomerz]

Github user retomerz closed the pull request at:

https://github.com/apache/maven-plugins/pull/87


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-scm pull request #51: fix SCM-835 collision

[shvar]

GitHub user shvar opened a pull request:

https://github.com/apache/maven-scm/pull/51

fix SCM-835 collision

Please, see: https://issues.apache.org/jira/browse/SCM-835

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/shvar/maven-scm master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-scm/pull/51.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #51


commit de40d5ecbf39c0812b218115e6c86b6f8075ee95
Author: Eli Shvartsman 
Date:   2016-07-07T08:02:53Z

fix SCM-835 collision




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org