Re: Jekyll experiment

[Martijn Dashorst]

While I use jekyll for lots of stuff (blogs and wicket website), I'd
urge to use asciidoc[tor] as the markup format. Markdown is great, but
rather limited for technical documentation. There is some asciidoctor
integration for jekyll available [1], but I haven't used it in anger.

Just my 2 cts.

Martijn

[1] https://google.com/search?q=jekyll%20asciidoctor


On Thu, Mar 19, 2015 at 4:32 AM, Jason van Zyl  wrote:
> Anyone interested in trying a Jekyll experiment for our website? Extract the 
> useful documentation we believe there is and try to make working on the site 
> a pleasurable experience that is easy for users to contribute to?
>
> I'd like to try this because after this last release I'm frankly tired of 
> looking at our pretty awful website. It's ugly, noisy, unmaintained, hard to 
> navigate and personally just makes me not want to write anything. I would 
> like to like writing documentation again and I think a more standard tool 
> like Jekyll will help. I honestly dislike doing core releases because I have 
> to use the site plugin. I created it, I can hate it and I do hate it.
>
> Even if no one answers I'll try this experiment because I think there's only 
> 10-15 useful documents in the whole site so it likely won't take long.
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
>
> There's no sense in being precise when you don't even know what you're 
> talking about.
>
>  -- John von Neumann
>
>
>
>
>
>
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

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

Re: Jekyll experiment

[Jeff Jensen]

+1 asciidoctor


On Thu, Mar 19, 2015 at 4:56 AM, Martijn Dashorst <
martijn.dasho...@gmail.com> wrote:

> While I use jekyll for lots of stuff (blogs and wicket website), I'd
> urge to use asciidoc[tor] as the markup format. Markdown is great, but
> rather limited for technical documentation. There is some asciidoctor
> integration for jekyll available [1], but I haven't used it in anger.
>
> Just my 2 cts.
>
> Martijn
>
> [1] https://google.com/search?q=jekyll%20asciidoctor
>
>
> On Thu, Mar 19, 2015 at 4:32 AM, Jason van Zyl  wrote:
> > Anyone interested in trying a Jekyll experiment for our website? Extract
> the useful documentation we believe there is and try to make working on the
> site a pleasurable experience that is easy for users to contribute to?
> >
> > I'd like to try this because after this last release I'm frankly tired
> of looking at our pretty awful website. It's ugly, noisy, unmaintained,
> hard to navigate and personally just makes me not want to write anything. I
> would like to like writing documentation again and I think a more standard
> tool like Jekyll will help. I honestly dislike doing core releases because
> I have to use the site plugin. I created it, I can hate it and I do hate it.
> >
> > Even if no one answers I'll try this experiment because I think there's
> only 10-15 useful documents in the whole site so it likely won't take long.
> >
> > Thanks,
> >
> > Jason
> >
> > --
> > Jason van Zyl
> > Founder, Takari and Apache Maven
> > http://twitter.com/jvanzyl
> > http://twitter.com/takari_io
> > -
> >
> > There's no sense in being precise when you don't even know what you're
> talking about.
> >
> >  -- John von Neumann
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Jekyll experiment

[Jeff Jensen]

I agree Fred... the reports are very helpful.  I've always thought of it as
handling two needs: "reports" and "docs"; reports basically working OOTB
and docs as the team decides to hand-create.


On Wed, Mar 18, 2015 at 10:43 PM, Fred Cooke  wrote:

> Well, if you created it, then a personal thank you from me for that. I
> would never use it for normal web stuff, but for the autogenerated stuff
> like PMD, checkstyle, findbugs, cross ref code, javadocs, etc etc it's
> GREAT at release time to give you a reference of what was. Or during dev,
> when one feels like it, to create a comprehensive detailed view of the
> state of the code that can be casually navigated through using a browser.
> It has some SVNness in it, which I hate, so I invite you to continue the
> hate for your own reasons :-D
>
> On Thu, Mar 19, 2015 at 4:32 PM, Jason van Zyl  wrote:
>
> > Anyone interested in trying a Jekyll experiment for our website? Extract
> > the useful documentation we believe there is and try to make working on
> the
> > site a pleasurable experience that is easy for users to contribute to?
> >
> > I'd like to try this because after this last release I'm frankly tired of
> > looking at our pretty awful website. It's ugly, noisy, unmaintained, hard
> > to navigate and personally just makes me not want to write anything. I
> > would like to like writing documentation again and I think a more
> standard
> > tool like Jekyll will help. I honestly dislike doing core releases
> because
> > I have to use the site plugin. I created it, I can hate it and I do hate
> it.
> >
> > Even if no one answers I'll try this experiment because I think there's
> > only 10-15 useful documents in the whole site so it likely won't take
> long.
> >
> > Thanks,
> >
> > Jason
> >
> > --
> > Jason van Zyl
> > Founder, Takari and Apache Maven
> > http://twitter.com/jvanzyl
> > http://twitter.com/takari_io
> > -
> >
> > There's no sense in being precise when you don't even know what you're
> > talking about.
> >
> >  -- John von Neumann
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: [VOTE] Release Apache Maven Checkstyle Plugin version 2.15

[Dennis Lundberg]

Hi,

We need one more bindning vote...
Den 15 mar 2015 20:14 skrev "Dennis Lundberg" :

> Hi,
>
> We solved 6 issues:
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11127&styleName=Html&version=20762
>
> There are still a couple of issues left in JIRA:
>
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11127&status=1
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1153/
>
> https://repository.apache.org/content/repositories/maven-1153/org/apache/maven/plugins/maven-checkstyle-plugin/2.15/maven-checkstyle-plugin-2.15-source-release.zip
>
> Source release checksum(s):
> maven-checkstyle-plugin-2.15-source-release.zip sha1:
> 8b89a4d671f2046d19bc40412521f30fcc977b7f
>
> Staging site:
> http://maven.apache.org/plugins-archives/maven-checkstyle-plugin-LATEST/
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> --
> Dennis Lundberg
>

Re: [VOTE] Release Apache Maven Checkstyle Plugin version 2.15

[Jason van Zyl]

+1

On Mar 15, 2015, at 3:14 PM, Dennis Lundberg  wrote:

> Hi,
> 
> We solved 6 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11127&styleName=Html&version=20762
> 
> There are still a couple of issues left in JIRA:
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11127&status=1
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1153/
> https://repository.apache.org/content/repositories/maven-1153/org/apache/maven/plugins/maven-checkstyle-plugin/2.15/maven-checkstyle-plugin-2.15-source-release.zip
> 
> Source release checksum(s):
> maven-checkstyle-plugin-2.15-source-release.zip sha1:
> 8b89a4d671f2046d19bc40412521f30fcc977b7f
> 
> Staging site:
> http://maven.apache.org/plugins-archives/maven-checkstyle-plugin-LATEST/
> 
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> 
> -- 
> Dennis Lundberg
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

A man enjoys his work when he understands the whole and when he
is responsible for the quality of the whole

 -- Christopher Alexander, A Pattern Language













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

Re: Jekyll experiment

[Petar Tahchiev]

Hello all,

A few months ago I was inspired by spring framework and Oliver Gierke to
rewrite my whole documentation using Asciidoctor. Turned out the
asciidoctor-maven plugin has some limitations so I spent some time with
Herve Boutemy last weekend to discuss a few pull requests I created for the
maven-asciidoctor-plugin. Basically the bottom of the problem seems to be
the doxia sink API which sanitizes the produced HTML5 result and removes a
lot of the attributes. This is due to the fact that doxia does not provide
html5 parser so the asciidoctor plugin is forced to extend the xhtml
parser. So in terms of html5 some tags have different meaning. For instance
in html5 the  tag is considered an icon and what asciidoctor is
producing:



doxia sink api treats as italics tags and removes the class and title
attributes to become: 

The end result is that the documentation css does not style the output
properly.
The solution for me is to probably create an HTML5 parser in doxia.
Or even better: instead of

Asciidoctor plugin --- creates --> HTML5 --> give it to the HTML5Parser of
doxia --> give it to the sink API --> produce whatever you want (PDF,
docbook, Latex or HTML5)

maybe a better solution is to get rid of the sink API and keep it only for
backward compatibility, but instead allow any new plugins to directly
produce the HTML5 themselves.



2015-03-19 14:02 GMT+02:00 Jeff Jensen :

> I agree Fred... the reports are very helpful.  I've always thought of it as
> handling two needs: "reports" and "docs"; reports basically working OOTB
> and docs as the team decides to hand-create.
>
>
> On Wed, Mar 18, 2015 at 10:43 PM, Fred Cooke  wrote:
>
> > Well, if you created it, then a personal thank you from me for that. I
> > would never use it for normal web stuff, but for the autogenerated stuff
> > like PMD, checkstyle, findbugs, cross ref code, javadocs, etc etc it's
> > GREAT at release time to give you a reference of what was. Or during dev,
> > when one feels like it, to create a comprehensive detailed view of the
> > state of the code that can be casually navigated through using a browser.
> > It has some SVNness in it, which I hate, so I invite you to continue the
> > hate for your own reasons :-D
> >
> > On Thu, Mar 19, 2015 at 4:32 PM, Jason van Zyl  wrote:
> >
> > > Anyone interested in trying a Jekyll experiment for our website?
> Extract
> > > the useful documentation we believe there is and try to make working on
> > the
> > > site a pleasurable experience that is easy for users to contribute to?
> > >
> > > I'd like to try this because after this last release I'm frankly tired
> of
> > > looking at our pretty awful website. It's ugly, noisy, unmaintained,
> hard
> > > to navigate and personally just makes me not want to write anything. I
> > > would like to like writing documentation again and I think a more
> > standard
> > > tool like Jekyll will help. I honestly dislike doing core releases
> > because
> > > I have to use the site plugin. I created it, I can hate it and I do
> hate
> > it.
> > >
> > > Even if no one answers I'll try this experiment because I think there's
> > > only 10-15 useful documents in the whole site so it likely won't take
> > long.
> > >
> > > Thanks,
> > >
> > > Jason
> > >
> > > --
> > > Jason van Zyl
> > > Founder, Takari and Apache Maven
> > > http://twitter.com/jvanzyl
> > > http://twitter.com/takari_io
> > > -
> > >
> > > There's no sense in being precise when you don't even know what you're
> > > talking about.
> > >
> > >  -- John von Neumann
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>



-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

Re: Jekyll experiment

[Manfred Moser]

I agree with the suggestion to use asciidoctor as a format. Markdown seems to 
limited and require escaping to straight html or other hacks way too often.

And on the need to clean up the site I would be willing to help as well. We 
need a fresh clean site. Maybe even with the Owl ;-) 

manfred

Jeff Jensen wrote on 19.03.2015 04:51:

> +1 asciidoctor
> 
> 
> On Thu, Mar 19, 2015 at 4:56 AM, Martijn Dashorst <
> martijn.dasho...@gmail.com> wrote:
> 
>> While I use jekyll for lots of stuff (blogs and wicket website), I'd
>> urge to use asciidoc[tor] as the markup format. Markdown is great, but
>> rather limited for technical documentation. There is some asciidoctor
>> integration for jekyll available [1], but I haven't used it in anger.
>>
>> Just my 2 cts.
>>
>> Martijn
>>
>> [1] https://google.com/search?q=jekyll%20asciidoctor
>>
>>
>> On Thu, Mar 19, 2015 at 4:32 AM, Jason van Zyl  wrote:
>> > Anyone interested in trying a Jekyll experiment for our website? Extract
>> the useful documentation we believe there is and try to make working on the
>> site a pleasurable experience that is easy for users to contribute to?
>> >
>> > I'd like to try this because after this last release I'm frankly tired
>> of looking at our pretty awful website. It's ugly, noisy, unmaintained,
>> hard to navigate and personally just makes me not want to write anything. I
>> would like to like writing documentation again and I think a more standard
>> tool like Jekyll will help. I honestly dislike doing core releases because
>> I have to use the site plugin. I created it, I can hate it and I do hate it.
>> >
>> > Even if no one answers I'll try this experiment because I think there's
>> only 10-15 useful documents in the whole site so it likely won't take long.
>> >
>> > Thanks,
>> >
>> > Jason
>> >
>> > --
>> > Jason van Zyl
>> > Founder, Takari and Apache Maven
>> > http://twitter.com/jvanzyl
>> > http://twitter.com/takari_io
>> > -
>> >
>> > There's no sense in being precise when you don't even know what you're
>> talking about.
>> >
>> >  -- John von Neumann
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: dev-h...@maven.apache.org
>> >
>>
>>
>>
>> --
>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>>
>> -
>> 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: Jekyll experiment

[Aldrin Leal]

JBake supports both markdown and adoc btw :)


--
-- Aldrin Leal, 
Master your EC2-fu! Get the latest ekaterminal public beta
http://www.ingenieux.com.br/products/ekaterminal/

On Thu, Mar 19, 2015 at 1:27 PM, Manfred Moser  wrote:

> I agree with the suggestion to use asciidoctor as a format. Markdown seems
> to limited and require escaping to straight html or other hacks way too
> often.
>
> And on the need to clean up the site I would be willing to help as well.
> We need a fresh clean site. Maybe even with the Owl ;-)
>
> manfred
>
> Jeff Jensen wrote on 19.03.2015 04:51:
>
> > +1 asciidoctor
> >
> >
> > On Thu, Mar 19, 2015 at 4:56 AM, Martijn Dashorst <
> > martijn.dasho...@gmail.com> wrote:
> >
> >> While I use jekyll for lots of stuff (blogs and wicket website), I'd
> >> urge to use asciidoc[tor] as the markup format. Markdown is great, but
> >> rather limited for technical documentation. There is some asciidoctor
> >> integration for jekyll available [1], but I haven't used it in anger.
> >>
> >> Just my 2 cts.
> >>
> >> Martijn
> >>
> >> [1] https://google.com/search?q=jekyll%20asciidoctor
> >>
> >>
> >> On Thu, Mar 19, 2015 at 4:32 AM, Jason van Zyl  wrote:
> >> > Anyone interested in trying a Jekyll experiment for our website?
> Extract
> >> the useful documentation we believe there is and try to make working on
> the
> >> site a pleasurable experience that is easy for users to contribute to?
> >> >
> >> > I'd like to try this because after this last release I'm frankly tired
> >> of looking at our pretty awful website. It's ugly, noisy, unmaintained,
> >> hard to navigate and personally just makes me not want to write
> anything. I
> >> would like to like writing documentation again and I think a more
> standard
> >> tool like Jekyll will help. I honestly dislike doing core releases
> because
> >> I have to use the site plugin. I created it, I can hate it and I do
> hate it.
> >> >
> >> > Even if no one answers I'll try this experiment because I think
> there's
> >> only 10-15 useful documents in the whole site so it likely won't take
> long.
> >> >
> >> > Thanks,
> >> >
> >> > Jason
> >> >
> >> > --
> >> > Jason van Zyl
> >> > Founder, Takari and Apache Maven
> >> > http://twitter.com/jvanzyl
> >> > http://twitter.com/takari_io
> >> > -
> >> >
> >> > There's no sense in being precise when you don't even know what you're
> >> talking about.
> >> >
> >> >  -- John von Neumann
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > -
> >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> > For additional commands, e-mail: dev-h...@maven.apache.org
> >> >
> >>
> >>
> >>
> >> --
> >> Become a Wicket expert, learn from the best: http://wicketinaction.com
> >>
> >> -
> >> 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: Suggestions User Information about Maven 2.2.1 EoL / Plugins / JDK

[Karl Heinz Marbaise]

Hi,

nothing more to improve ?

Kind regards
Karl Heinz Marbaise
On 3/18/15 10:21 PM, Karl Heinz Marbaise wrote:

Hi,

i have incorporated the suggestions/ideas/improvements

https://github.com/khmarbaise/maven2eol/blob/master/message.txt


If you have adds/supplementals/etc. please send a pull request or you
can create an issue...


The list of Maven versions / JDK requirements should be listed on the
download page...IMHO...

Kind regards
Karl Heinz Marbaise


On 3/5/15 7:35 PM, Karl Heinz Marbaise wrote:

Hi,

here is my suggestions for the user list announcement regarding Maven
2.2.1 EoL / Plugins version lift / JDK etc.

Any enhancement / things which should also be mentioned please reply and
make appropriate changes / Thinks which i have missed...


-
Dear Maven Users,

based on the End of Life of Maven 2.2.1 (a year ago) now the time has
come to make the final releases of Apache Maven Plugins which support
Maven 2.X.

We have documented the final releases of plugins which support Maven
2.2.1 in relationship with JDK 1.5

The complete list can be found here:

http://maven.apache.org/maven-2.x-eol.html

The next step on our roadmap is to lift all plugin versions to 3.X to
make clear those plugins will only work with Maven 3.0+ furthermore the
Java minimum requirement will lifted to JDK 1.6 as well.

No "rule" without exceptions. Here they come:


  * maven-site-plugin (Version 3.4)
See the docs of the plugin for usage in Maven 2.X

  * maven-compiler-plugin (Version 3.2)
which works with Maven 2.2.1.

  * maven-plugin-plugin (Version 3.4)
which works with Maven 2.2.1

  * maven-pmd-plugin (Version 3.4)
which works with Maven 2.2.1 but needs JDK 1.6


The following plugins already have the Maven 3.0+ requirement:

* maven-scm-publish-plugin (Version 1.1)
* maven-shade-plugin (Version 2.3)


So to make things more clearer here is an example:

Currently we have the maven-clean-plugin with version 2.6.1.

This plugin supports Maven 2.2.1 and JDK 1.5 minimum.

This plugin will get a new major release with version 3.0 which has the
Maven minimum 3.0 AND Jave minimum 1.6.


Kind regards
The Apache Maven Team




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

Re: [VOTE] Release Apache Maven Shared Maven Invoker 2.2

[Robert Scholte]

Hi Karl Heinz,

I think it has to do with the chain of Maven invocations, although it  
shouldn't matter.
Just for me: how do you execute these tests? Plain old commandline or  
buildserver or ...?


thanks,
Robert

Op Thu, 19 Mar 2015 07:12:33 +0100 schreef Karl Heinz Marbaise  
:



Hi Robert,

a followup...checked with Maven 3.2.5 as well and got the same  
issue...so it seemed to be not limited to Maven 3.3.1...


Kind regards
Karl Heinz Marbaise
On 3/19/15 7:03 AM, Karl Heinz Marbaise wrote:

Hi Robert,


I have checked with Maven 3.3.1 on Mac and got the following:

Running org.apache.maven.shared.invoker.DefaultInvokerTest
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 13.914
sec - in org.apache.maven.shared.invoker.DefaultInvokerTest
Running org.apache.maven.shared.invoker.MavenCommandLineBuilderTest
Tests run: 52, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.078
sec <<< FAILURE! - in
org.apache.maven.shared.invoker.MavenCommandLineBuilderTest
testShouldSetEnvVar_M2_HOME(org.apache.maven.shared.invoker.MavenCommandLineBuilderTest)
  Time elapsed: 0.018 sec  <<< ERROR!
org.junit.internal.AssumptionViolatedException: got: <[null]>, expected:
every item is not null
 at org.junit.Assume.assumeThat(Assume.java:95)
 at org.junit.Assume.assumeNotNull(Assume.java:73)
 at
org.apache.maven.shared.invoker.MavenCommandLineBuilderTest.testShouldSetEnvVar_M2_HOME(MavenCommandLineBuilderTest.java:1108)


Running org.apache.maven.shared.invoker.SystemOutHandlerTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec -
in org.apache.maven.shared.invoker.SystemOutHandlerTest
Running org.apache.maven.shared.invoker.SystemOutLoggerTest
Tests run: 31, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002
sec - in org.apache.maven.shared.invoker.SystemOutLoggerTest

Results :

Tests in error:
   MavenCommandLineBuilderTest.testShouldSetEnvVar_M2_HOME:1108 »
AssumptionViolated

Tests run: 92, Failures: 0, Errors: 1, Skipped: 0

Do i need to do something special to get those tests workig ?


Kind regards
Karl Heinz Marbaise

On 3/18/15 11:52 PM, Robert Scholte wrote:

Hi,

this release contains a critical fix for Windows users who want to
invoke Apache Maven 3.3.1. Due to
http://jira.codehaus.org/browse/MNG-5776 the start-script has been
renamed from mvn.bat to mvn.cmd, which caused that the Invoker couldn't
find the executable file anymore.

We solved 7 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761&styleName=Html&version=18970



There are still 2 issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11761&status=1&component=13271



Staging repo:
https://repository.apache.org/content/repositories/maven-1154
https://repository.apache.org/content/repositories/maven-1154/org/apache/maven/shared/maven-invoker/2.2/maven-invoker-2.2-source-release.zip



Source release checksum(s):
maven-invoker-2.2-source-release.zip sha1:
56fb87afb12378ebbf5ddf1546ac10528e18dca6

Staging site:
http://maven.apache.org/shared-archives/maven-invoker-LATEST/

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1




-
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: [VOTE] Release Apache Maven Shared Maven Invoker 2.2

[Karl Heinz Marbaise]

Hi Robert,
> Hi Karl Heinz,


I think it has to do with the chain of Maven invocations, although it
shouldn't matter.
Just for me: how do you execute these tests? Plain old commandline or
buildserver or ...?


Just plain old commandline ;-)...

mvn clean verify ...

nothing odd

Kind regards
Karl Heinz Marbaise


thanks,
Robert

Op Thu, 19 Mar 2015 07:12:33 +0100 schreef Karl Heinz Marbaise
:


Hi Robert,

a followup...checked with Maven 3.2.5 as well and got the same
issue...so it seemed to be not limited to Maven 3.3.1...

Kind regards
Karl Heinz Marbaise
On 3/19/15 7:03 AM, Karl Heinz Marbaise wrote:

Hi Robert,


I have checked with Maven 3.3.1 on Mac and got the following:

Running org.apache.maven.shared.invoker.DefaultInvokerTest
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 13.914
sec - in org.apache.maven.shared.invoker.DefaultInvokerTest
Running org.apache.maven.shared.invoker.MavenCommandLineBuilderTest
Tests run: 52, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.078
sec <<< FAILURE! - in
org.apache.maven.shared.invoker.MavenCommandLineBuilderTest
testShouldSetEnvVar_M2_HOME(org.apache.maven.shared.invoker.MavenCommandLineBuilderTest)

  Time elapsed: 0.018 sec  <<< ERROR!
org.junit.internal.AssumptionViolatedException: got: <[null]>, expected:
every item is not null
 at org.junit.Assume.assumeThat(Assume.java:95)
 at org.junit.Assume.assumeNotNull(Assume.java:73)
 at
org.apache.maven.shared.invoker.MavenCommandLineBuilderTest.testShouldSetEnvVar_M2_HOME(MavenCommandLineBuilderTest.java:1108)



Running org.apache.maven.shared.invoker.SystemOutHandlerTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec -
in org.apache.maven.shared.invoker.SystemOutHandlerTest
Running org.apache.maven.shared.invoker.SystemOutLoggerTest
Tests run: 31, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002
sec - in org.apache.maven.shared.invoker.SystemOutLoggerTest

Results :

Tests in error:
   MavenCommandLineBuilderTest.testShouldSetEnvVar_M2_HOME:1108 »
AssumptionViolated

Tests run: 92, Failures: 0, Errors: 1, Skipped: 0

Do i need to do something special to get those tests workig ?


Kind regards
Karl Heinz Marbaise

On 3/18/15 11:52 PM, Robert Scholte wrote:

Hi,

this release contains a critical fix for Windows users who want to
invoke Apache Maven 3.3.1. Due to
http://jira.codehaus.org/browse/MNG-5776 the start-script has been
renamed from mvn.bat to mvn.cmd, which caused that the Invoker couldn't
find the executable file anymore.

We solved 7 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761&styleName=Html&version=18970




There are still 2 issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11761&status=1&component=13271




Staging repo:
https://repository.apache.org/content/repositories/maven-1154
https://repository.apache.org/content/repositories/maven-1154/org/apache/maven/shared/maven-invoker/2.2/maven-invoker-2.2-source-release.zip




Source release checksum(s):
maven-invoker-2.2-source-release.zip sha1:
56fb87afb12378ebbf5ddf1546ac10528e18dca6

Staging site:
http://maven.apache.org/shared-archives/maven-invoker-LATEST/

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1




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

Re: [VOTE] Release Apache Maven Shared Maven Invoker 2.2

[Robert Scholte]

Hi Karl Heinz,

could you test current trunk version?
I hope http://svn.apache.org/r1667876 fixed the issue.

The other interesting part is: is seems like on (your) Mac the M2_HOME  
isn't set by the mvn script, but for Windows it is...


thanks,
Robert

Op Thu, 19 Mar 2015 21:08:09 +0100 schreef Karl Heinz Marbaise  
:



Hi Robert,
 > Hi Karl Heinz,


I think it has to do with the chain of Maven invocations, although it
shouldn't matter.
Just for me: how do you execute these tests? Plain old commandline or
buildserver or ...?


Just plain old commandline ;-)...

mvn clean verify ...

nothing odd

Kind regards
Karl Heinz Marbaise


thanks,
Robert

Op Thu, 19 Mar 2015 07:12:33 +0100 schreef Karl Heinz Marbaise
:


Hi Robert,

a followup...checked with Maven 3.2.5 as well and got the same
issue...so it seemed to be not limited to Maven 3.3.1...

Kind regards
Karl Heinz Marbaise
On 3/19/15 7:03 AM, Karl Heinz Marbaise wrote:

Hi Robert,


I have checked with Maven 3.3.1 on Mac and got the following:

Running org.apache.maven.shared.invoker.DefaultInvokerTest
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 13.914
sec - in org.apache.maven.shared.invoker.DefaultInvokerTest
Running org.apache.maven.shared.invoker.MavenCommandLineBuilderTest
Tests run: 52, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.078
sec <<< FAILURE! - in
org.apache.maven.shared.invoker.MavenCommandLineBuilderTest
testShouldSetEnvVar_M2_HOME(org.apache.maven.shared.invoker.MavenCommandLineBuilderTest)

  Time elapsed: 0.018 sec  <<< ERROR!
org.junit.internal.AssumptionViolatedException: got: <[null]>,  
expected:

every item is not null
 at org.junit.Assume.assumeThat(Assume.java:95)
 at org.junit.Assume.assumeNotNull(Assume.java:73)
 at
org.apache.maven.shared.invoker.MavenCommandLineBuilderTest.testShouldSetEnvVar_M2_HOME(MavenCommandLineBuilderTest.java:1108)



Running org.apache.maven.shared.invoker.SystemOutHandlerTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec  
-

in org.apache.maven.shared.invoker.SystemOutHandlerTest
Running org.apache.maven.shared.invoker.SystemOutLoggerTest
Tests run: 31, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002
sec - in org.apache.maven.shared.invoker.SystemOutLoggerTest

Results :

Tests in error:
   MavenCommandLineBuilderTest.testShouldSetEnvVar_M2_HOME:1108 »
AssumptionViolated

Tests run: 92, Failures: 0, Errors: 1, Skipped: 0

Do i need to do something special to get those tests workig ?


Kind regards
Karl Heinz Marbaise

On 3/18/15 11:52 PM, Robert Scholte wrote:

Hi,

this release contains a critical fix for Windows users who want to
invoke Apache Maven 3.3.1. Due to
http://jira.codehaus.org/browse/MNG-5776 the start-script has been
renamed from mvn.bat to mvn.cmd, which caused that the Invoker  
couldn't

find the executable file anymore.

We solved 7 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761&styleName=Html&version=18970




There are still 2 issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11761&status=1&component=13271




Staging repo:
https://repository.apache.org/content/repositories/maven-1154
https://repository.apache.org/content/repositories/maven-1154/org/apache/maven/shared/maven-invoker/2.2/maven-invoker-2.2-source-release.zip




Source release checksum(s):
maven-invoker-2.2-source-release.zip sha1:
56fb87afb12378ebbf5ddf1546ac10528e18dca6

Staging site:
http://maven.apache.org/shared-archives/maven-invoker-LATEST/

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1




-
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: [VOTE] Release Apache Maven Shared Maven Invoker 2.2

[Karl Heinz Marbaise]

Hi Robert,


On 3/19/15 10:07 PM, Robert Scholte wrote:

Hi Karl Heinz,

could you test current trunk version?
I hope http://svn.apache.org/r1667876 fixed the issue.


Tested now with Maven 3.0.5, 3.1.1, 3.2.5, 3.3.1...just fine...great...

Hm...I'm astonished that this change caused fixing this? Cause there you 
have changed only from JUnit 3.8 style (extends TestCase) to 4.X @Test 
annotations...but nothing really in the code...


Kind regards
Karl Heinz Marbaise





The other interesting part is: is seems like on (your) Mac the M2_HOME
isn't set by the mvn script, but for Windows it is...

thanks,
Robert

Op Thu, 19 Mar 2015 21:08:09 +0100 schreef Karl Heinz Marbaise
:


Hi Robert,
 > Hi Karl Heinz,


I think it has to do with the chain of Maven invocations, although it
shouldn't matter.
Just for me: how do you execute these tests? Plain old commandline or
buildserver or ...?


Just plain old commandline ;-)...

mvn clean verify ...

nothing odd

Kind regards
Karl Heinz Marbaise


thanks,
Robert

Op Thu, 19 Mar 2015 07:12:33 +0100 schreef Karl Heinz Marbaise
:


Hi Robert,

a followup...checked with Maven 3.2.5 as well and got the same
issue...so it seemed to be not limited to Maven 3.3.1...

Kind regards
Karl Heinz Marbaise
On 3/19/15 7:03 AM, Karl Heinz Marbaise wrote:

Hi Robert,


I have checked with Maven 3.3.1 on Mac and got the following:

Running org.apache.maven.shared.invoker.DefaultInvokerTest
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 13.914
sec - in org.apache.maven.shared.invoker.DefaultInvokerTest
Running org.apache.maven.shared.invoker.MavenCommandLineBuilderTest
Tests run: 52, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.078
sec <<< FAILURE! - in
org.apache.maven.shared.invoker.MavenCommandLineBuilderTest
testShouldSetEnvVar_M2_HOME(org.apache.maven.shared.invoker.MavenCommandLineBuilderTest)


  Time elapsed: 0.018 sec  <<< ERROR!
org.junit.internal.AssumptionViolatedException: got: <[null]>,
expected:
every item is not null
 at org.junit.Assume.assumeThat(Assume.java:95)
 at org.junit.Assume.assumeNotNull(Assume.java:73)
 at
org.apache.maven.shared.invoker.MavenCommandLineBuilderTest.testShouldSetEnvVar_M2_HOME(MavenCommandLineBuilderTest.java:1108)




Running org.apache.maven.shared.invoker.SystemOutHandlerTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0
sec -
in org.apache.maven.shared.invoker.SystemOutHandlerTest
Running org.apache.maven.shared.invoker.SystemOutLoggerTest
Tests run: 31, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002
sec - in org.apache.maven.shared.invoker.SystemOutLoggerTest

Results :

Tests in error:
   MavenCommandLineBuilderTest.testShouldSetEnvVar_M2_HOME:1108 »
AssumptionViolated

Tests run: 92, Failures: 0, Errors: 1, Skipped: 0

Do i need to do something special to get those tests workig ?


Kind regards
Karl Heinz Marbaise

On 3/18/15 11:52 PM, Robert Scholte wrote:

Hi,

this release contains a critical fix for Windows users who want to
invoke Apache Maven 3.3.1. Due to
http://jira.codehaus.org/browse/MNG-5776 the start-script has been
renamed from mvn.bat to mvn.cmd, which caused that the Invoker
couldn't
find the executable file anymore.

We solved 7 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761&styleName=Html&version=18970





There are still 2 issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11761&status=1&component=13271





Staging repo:
https://repository.apache.org/content/repositories/maven-1154
https://repository.apache.org/content/repositories/maven-1154/org/apache/maven/shared/maven-invoker/2.2/maven-invoker-2.2-source-release.zip





Source release checksum(s):
maven-invoker-2.2-source-release.zip sha1:
56fb87afb12378ebbf5ddf1546ac10528e18dca6

Staging site:
http://maven.apache.org/shared-archives/maven-invoker-LATEST/

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html


Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1




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

Re: [VOTE] Release Apache Maven Shared Maven Invoker 2.2

[Robert Scholte]

IIUC JUnit3 only knows success or failure, JUnit4 introduced skipped. The  
Assume should cause a skip in your case, but since that Exception isn't  
recognized it was translated to failure.


Op Thu, 19 Mar 2015 23:13:15 +0100 schreef Karl Heinz Marbaise  
:



Hi Robert,


On 3/19/15 10:07 PM, Robert Scholte wrote:

Hi Karl Heinz,

could you test current trunk version?
I hope http://svn.apache.org/r1667876 fixed the issue.


Tested now with Maven 3.0.5, 3.1.1, 3.2.5, 3.3.1...just fine...great...

Hm...I'm astonished that this change caused fixing this? Cause there you  
have changed only from JUnit 3.8 style (extends TestCase) to 4.X @Test  
annotations...but nothing really in the code...


Kind regards
Karl Heinz Marbaise





The other interesting part is: is seems like on (your) Mac the M2_HOME
isn't set by the mvn script, but for Windows it is...

thanks,
Robert

Op Thu, 19 Mar 2015 21:08:09 +0100 schreef Karl Heinz Marbaise
:


Hi Robert,
 > Hi Karl Heinz,


I think it has to do with the chain of Maven invocations, although it
shouldn't matter.
Just for me: how do you execute these tests? Plain old commandline or
buildserver or ...?


Just plain old commandline ;-)...

mvn clean verify ...

nothing odd

Kind regards
Karl Heinz Marbaise


thanks,
Robert

Op Thu, 19 Mar 2015 07:12:33 +0100 schreef Karl Heinz Marbaise
:


Hi Robert,

a followup...checked with Maven 3.2.5 as well and got the same
issue...so it seemed to be not limited to Maven 3.3.1...

Kind regards
Karl Heinz Marbaise
On 3/19/15 7:03 AM, Karl Heinz Marbaise wrote:

Hi Robert,


I have checked with Maven 3.3.1 on Mac and got the following:

Running org.apache.maven.shared.invoker.DefaultInvokerTest
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:  
13.914

sec - in org.apache.maven.shared.invoker.DefaultInvokerTest
Running org.apache.maven.shared.invoker.MavenCommandLineBuilderTest
Tests run: 52, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:  
0.078

sec <<< FAILURE! - in
org.apache.maven.shared.invoker.MavenCommandLineBuilderTest
testShouldSetEnvVar_M2_HOME(org.apache.maven.shared.invoker.MavenCommandLineBuilderTest)


  Time elapsed: 0.018 sec  <<< ERROR!
org.junit.internal.AssumptionViolatedException: got: <[null]>,
expected:
every item is not null
 at org.junit.Assume.assumeThat(Assume.java:95)
 at org.junit.Assume.assumeNotNull(Assume.java:73)
 at
org.apache.maven.shared.invoker.MavenCommandLineBuilderTest.testShouldSetEnvVar_M2_HOME(MavenCommandLineBuilderTest.java:1108)




Running org.apache.maven.shared.invoker.SystemOutHandlerTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0
sec -
in org.apache.maven.shared.invoker.SystemOutHandlerTest
Running org.apache.maven.shared.invoker.SystemOutLoggerTest
Tests run: 31, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:  
0.002

sec - in org.apache.maven.shared.invoker.SystemOutLoggerTest

Results :

Tests in error:
   MavenCommandLineBuilderTest.testShouldSetEnvVar_M2_HOME:1108 »
AssumptionViolated

Tests run: 92, Failures: 0, Errors: 1, Skipped: 0

Do i need to do something special to get those tests workig ?


Kind regards
Karl Heinz Marbaise

On 3/18/15 11:52 PM, Robert Scholte wrote:

Hi,

this release contains a critical fix for Windows users who want to
invoke Apache Maven 3.3.1. Due to
http://jira.codehaus.org/browse/MNG-5776 the start-script has been
renamed from mvn.bat to mvn.cmd, which caused that the Invoker
couldn't
find the executable file anymore.

We solved 7 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761&styleName=Html&version=18970





There are still 2 issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11761&status=1&component=13271





Staging repo:
https://repository.apache.org/content/repositories/maven-1154
https://repository.apache.org/content/repositories/maven-1154/org/apache/maven/shared/maven-invoker/2.2/maven-invoker-2.2-source-release.zip





Source release checksum(s):
maven-invoker-2.2-source-release.zip sha1:
56fb87afb12378ebbf5ddf1546ac10528e18dca6

Staging site:
http://maven.apache.org/shared-archives/maven-invoker-LATEST/

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html


Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1




-
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

[DISCUSSION] JEP 238: Multi-Version JAR Files

[Robert Scholte]

Hi,

we've been asked to give our opinion on the JEP 238: Multi-Version JAR  
Files


Here's a quote from Rory O'Donnels e-mail:
---
 It's goal is to extend the JAR file format to allow multiple, JDK  
release-specific versions of class
 files to coexist in a single file. An additional goal is to backport the  
run-time changes to
 JDK 8u60, thereby enabling JDK 8 to consume multi-version JARs. For a  
detailed discussion,

 please see the corresponding thread on the core-libs-dev mailing list. [1]

 Please keep in mind that a JEP in the Candidate state is merely an idea  
worthy of consideration
 by JDK Release Projects and related efforts; there is no commitment that  
it will be delivered in

 any particular release.

 Comments, questions, and suggestions are welcome on the corelibs-dev  
mailing list. (If you
 haven’t already subscribed to that list then please do so first,  
otherwise your message will be

 discarded as spam.)

 [0] http://openjdk.java.net/jeps/238
 [1]  
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031461.html


---

IIUC the original request was to have different version of the same class  
within the same artifact. On the mailinglist I noticed a more interesting  
idea: you need a mechanism to map Classes, Methods or Fields from one  
version to the other.


From a Maven perspective I don't see that much issues with the original  
idea. You should already be able to do it right now with a lot of  
execution-blocks.
However, I don't see how users would maintain different version of the  
same class (within an IDE).

To me this all looks quite complex for rare cases.
If you really want multiple JDK versions of the same artifact, I would  
probably split them into classified artifacts.


Any other comments?

thanks,
Robert

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

Re: [DISCUSSION] JEP 238: Multi-Version JAR Files

[Gary Gregory]

The level of granularity feels wrong.

This sounds like it would make jar "heavier", potentially a lot heavier.
Another angle would be to manage versions 1-1 with jars, one jar for java
7, one for java 8, and so on. With >1 version in one jar, I am FORCED to
download versions of class files I'll never use. That seems like a bad idea
baked in.

Gary

On Thu, Mar 19, 2015 at 3:38 PM, Robert Scholte 
wrote:

> Hi,
>
> we've been asked to give our opinion on the JEP 238: Multi-Version JAR
> Files
>
> Here's a quote from Rory O'Donnels e-mail:
> ---
>  It's goal is to extend the JAR file format to allow multiple, JDK
> release-specific versions of class
>  files to coexist in a single file. An additional goal is to backport the
> run-time changes to
>  JDK 8u60, thereby enabling JDK 8 to consume multi-version JARs. For a
> detailed discussion,
>  please see the corresponding thread on the core-libs-dev mailing list. [1]
>
>  Please keep in mind that a JEP in the Candidate state is merely an idea
> worthy of consideration
>  by JDK Release Projects and related efforts; there is no commitment that
> it will be delivered in
>  any particular release.
>
>  Comments, questions, and suggestions are welcome on the corelibs-dev
> mailing list. (If you
>  haven’t already subscribed to that list then please do so first,
> otherwise your message will be
>  discarded as spam.)
>
>  [0] http://openjdk.java.net/jeps/238
>  [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-
> February/031461.html
>
> ---
>
> IIUC the original request was to have different version of the same class
> within the same artifact. On the mailinglist I noticed a more interesting
> idea: you need a mechanism to map Classes, Methods or Fields from one
> version to the other.
>
> From a Maven perspective I don't see that much issues with the original
> idea. You should already be able to do it right now with a lot of
> execution-blocks.
> However, I don't see how users would maintain different version of the
> same class (within an IDE).
> To me this all looks quite complex for rare cases.
> If you really want multiple JDK versions of the same artifact, I would
> probably split them into classified artifacts.
>
> Any other comments?
>
> thanks,
> Robert
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VOTE] Release Apache Maven Checkstyle Plugin version 2.15

[Hervé BOUTEMY]

+1

Regards,

Hervé

Le dimanche 15 mars 2015 20:14:02 Dennis Lundberg a écrit :
> Hi,
> 
> We solved 6 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11127&styleName=H
> tml&version=20762
> 
> There are still a couple of issues left in JIRA:
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11127&sta
> tus=1
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1153/
> https://repository.apache.org/content/repositories/maven-1153/org/apache/mav
> en/plugins/maven-checkstyle-plugin/2.15/maven-checkstyle-plugin-2.15-source-
> release.zip
> 
> Source release checksum(s):
> maven-checkstyle-plugin-2.15-source-release.zip sha1:
> 8b89a4d671f2046d19bc40412521f30fcc977b7f
> 
> Staging site:
> http://maven.apache.org/plugins-archives/maven-checkstyle-plugin-LATEST/
> 
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1


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

Re: [DISCUSSION] JEP 238: Multi-Version JAR Files

[Manfred Moser]

I totally agree. This feels like a royally bad idea that is totally counter to 
the idea for slim runtime and fast startup times. I would much rather have some 
additional info somewhere in the archive that documents used bytecode, 
supported runtime and things like that. 

On the Maven side it would be good to have some standard way to include this 
information in the coordinates maybe so that things could be validated even 
before downloading the archive, opening it up and parsing it.

Ideally it would be a better solution than the classifier based approach used 
in the past.. 

Maybe this is a hot candidate for the consumer pom work..

manfred

Gary Gregory wrote on 19.03.2015 15:43:

> The level of granularity feels wrong.
> 
> This sounds like it would make jar "heavier", potentially a lot heavier.
> Another angle would be to manage versions 1-1 with jars, one jar for java
> 7, one for java 8, and so on. With >1 version in one jar, I am FORCED to
> download versions of class files I'll never use. That seems like a bad idea
> baked in.
> 
> Gary
> 
> On Thu, Mar 19, 2015 at 3:38 PM, Robert Scholte 
> wrote:
> 
>> Hi,
>>
>> we've been asked to give our opinion on the JEP 238: Multi-Version JAR
>> Files
>>
>> Here's a quote from Rory O'Donnels e-mail:
>> ---
>>  It's goal is to extend the JAR file format to allow multiple, JDK
>> release-specific versions of class
>>  files to coexist in a single file. An additional goal is to backport the
>> run-time changes to
>>  JDK 8u60, thereby enabling JDK 8 to consume multi-version JARs. For a
>> detailed discussion,
>>  please see the corresponding thread on the core-libs-dev mailing list. [1]
>>
>>  Please keep in mind that a JEP in the Candidate state is merely an idea
>> worthy of consideration
>>  by JDK Release Projects and related efforts; there is no commitment that
>> it will be delivered in
>>  any particular release.
>>
>>  Comments, questions, and suggestions are welcome on the corelibs-dev
>> mailing list. (If you
>>  haven’t already subscribed to that list then please do so first,
>> otherwise your message will be
>>  discarded as spam.)
>>
>>  [0] http://openjdk.java.net/jeps/238
>>  [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-
>> February/031461.html
>>
>> ---
>>
>> IIUC the original request was to have different version of the same class
>> within the same artifact. On the mailinglist I noticed a more interesting
>> idea: you need a mechanism to map Classes, Methods or Fields from one
>> version to the other.
>>
>> From a Maven perspective I don't see that much issues with the original
>> idea. You should already be able to do it right now with a lot of
>> execution-blocks.
>> However, I don't see how users would maintain different version of the
>> same class (within an IDE).
>> To me this all looks quite complex for rare cases.
>> If you really want multiple JDK versions of the same artifact, I would
>> probably split them into classified artifacts.
>>
>> Any other comments?
>>
>> thanks,
>> Robert
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
> 


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