Re: main-class + module-version

[Andreas Gudian]

I find the arguments by Plamen very convincing. As a user I would look for
that configuration where I previously did the same thing when it ended up
in the Manifest: in the config of the jar plugin.
I wouldn't expect to suddenly switch to the shade plugin to be able to
define the main class or the module version.

But in the end both m-shade-p and m-jar-p might need those capabilities.

And just to check: the compiler-plugin is not the right spot for that? Or
the resources plugin to extend the module-info.java before compiling? Nah,
that sounds too far off.


Robert Scholte  schrieb am Mi. 23. Aug. 2017 um 11:16:

> On Wed, 23 Aug 2017 08:11:35 +0200, Plamen Totev
>  wrote:
>
> > On Tue, Aug 22, 2017 at 11:03 PM, Robert Scholte 
> > wrote:
> >>
> >>
> >> The maven-shade-plugin has the ability to re-package a jar and
> >> manipulate any type of file, including class files. The best example is
> >> relocation, where you give a set of classes a different package to
> >> prevent potential class collisions when the original dependency
> >> (probably with other version) is added again.
> >> So this is a good match for the module-info.class adjustments.
> >>
> >
> > Thank you for the detailed explanation. Initially I thought that if
> > this is not part of the jar plugin then the transformation should
> > happen before its execution(similar to the MANFEST.MF). Now on second
> > thought it also sounds logical to be done after. But still - isn't the
> > shade plugin supposed to be used for "uber jars" (at least its primary
> > purpose)? Correct me if I'm wrong, but its only target will create a
> > "uber jar". What if I want to set the module version but without
> > changing the rest of the jar? A configuration or new target will solve
> > this issue, but as a user of the plugin I think it would change its
> > purpose. And there is nothing wrong with that of course .
>
> You can choose which artifacts should be included/excluded from the
> uber-jar. By default it'll select all, which means you must do quite some
> extra configuration just to set the main-class and module-version.
> Another downside is that the maven-shade-plugin is probably not the plugin
> one would expect to use to achieve this.
>
> >
> > Also another important question for me. Do you think that other types
> > of packaging will benefit from setting the module version as well? I
> > mean not only now but in future as well. Some of the EE packaging
> > types for example.
> >
> > -
> > 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: Using "annotationProcessorPaths" together with version ranges

[Andreas Gudian]

Yupp, I'm afraid neither version ranges nor information from any
dependencyManagement sections are considered.

Only the plain versions or properties work, and transitive dependencies are
pulled in.

And I agree that a special scope would have been a nice alternative
solution, but that would have opened up a whole can of worms in all kinds
of places...



Mark Derricutt  schrieb am Fr. 18. Aug. 2017 um 06:53:

> On 17 Aug 2017, at 19:33, Cristian Spiescu wrote:
>
> When using maven-compiler-plugin with "annotationProcessorPaths", and I
> specify a dependency with a version range: it doesn't seem to work. I have
> done some debugging, and I see that the general dependency solving
> mechanism (that does
>
> I really wish we could have a new 'annotation' scope and NOT use
> 'annotationProcessorPaths', it makes things really ik to work with when
> using parents/tiles and common compiler plugin settings.
>
> Interestingly, the DTD doesn't actually specify a strict set of scopes,
> and neither does the documentation it seems.
>
> Mark
> --
>
> "The ease with which a change can be implemented has no relevance at all
> to whether it is the right change for the (Java) Platform for all time." —
> Mark Reinhold.
>
> Mark Derricutt
> http://www.theoryinpractice.net
> http://www.chaliceofblood.net
> http://plus.google.com/+MarkDerricutt
> http://twitter.com/talios
> http://facebook.com/mderricutt
>

Re: rewrite StatelessXmlReporter fo JAXB

[Andreas Gudian]

What ever you do, make sure you never try to put unbounded sysout/syserr of
a test case into memory, ever. Not even for a short time, as there may be
users with a ton of output that is currently buffered in the
overflow-files. Changing this can cause serious performance issues (gc
pauses, swapping) or just break the current behavior.

Writing some XML is no rocket science, especially as our schema is very
simple and barely changes anyway. The only thing to take care is encoding
and closing all streams at the right time - but that won't be much simpler
using JAXB.

Just my 2 cent ;-)


Michael Osipov  schrieb am So. 16. Apr. 2017 um 17:12:

> Am 2017-04-16 um 16:52 schrieb Tibor Digana:
> >>> That would still create a string in memory, won't it?
> > It would still leak in memory while getter is called.
> > Streaming to XML is better in this case.
> >
> > Do we have any alternative?
>
> I have to think about it and understand the whole system.
> But why not use the regular XMLStreamWriter paired with this:
> http://stackoverflow.com/a/2514/696632.
>
> You'll be able to stream whatever you want.
>
> > On Sun, Apr 16, 2017 at 4:40 PM, Michael Osipov 
> wrote:
> >
> >> Am 2017-04-16 um 16:15 schrieb Tibor Digana:
> >>
> >>> Since we have XSD [1] we can generate classes and call setters in
> >>> particular places in StatelessXmlReporter.java.
> >>> Regarding memory consumption system-out may consume really a lot of
> >>> memory.
> >>> Therefore this is my proposal:
> >>>
> >>> @XmlJavaTypeAdapter(CdataSystemAdapter.class)
> >>> public Utf8RecodingDeferredFileOutputStream getSystemOut()
> >>>
> >>> class CdataSystemAdapter
> >>> WeakReference with   utf8RecodingDeferredFileOutputStream.writeTo(
> >>> stream )
> >>> return ""
> >>>
> >>
> >> That would still create a string in memory, won't it?
> >>
> >> [1]
> >>> https://maven.apache.org/surefire/maven-surefire-plugin/xsd/
> >>> surefire-test-report.xsd
> >>>
> >>
> >> This needs a rewrite, too much duplication, no typing but xs:string
> only.
> >>
> >> On Sun, Apr 16, 2017 at 2:43 PM, michaelo [via Maven] <
> >>> ml-node+s40175n5906482...@n5.nabble.com> wrote:
> >>>
> >>> Am 2017-04-16 um 14:21 schrieb Tibor Digana:
> 
>  Hi,
> >
> > I want to first talk with you about XML marshaller
> StatelessXmlReporter
> >
>  [1]
> 
> > in Surefire which is built on the top of SharedUtils'
> >
>  PrettyPrintXMLWriter.
> 
> >
> > I found out issues after a contributor opened this issue [2].
> >
> > The problem is that we are using two streams, OutputStream and
> Writer,
> >
>  to
> 
> > create XML in file system for one reason. We write CDATA directly to
> the
> > stream apart of xml facility. We have bug with escaping illegal
> >
>  characters.
> 
> >
> > Instead, my proposal is to create XSD and Jaxb stubs and marshal it
> to
> >
>  XML
> 
> > file and we do need to care about low level XML and escaping
> characters.
> > The code will be easier to understand. The elements system-out and
> > system-err can be large but we have the stream already in temp files
> > Utf8RecodingDeferredFileOutputStream which means that the Jaxb
> >
>  mashaller
> 
> > will not keep String in memory too long - only while Marshaller needs
> >
>  the
> 
> > string.
> >
> > What is your opinion?
> >
> 
>  Looking at the current code -- a lot of boilerplate. I am quite
>  experienced with JAXB, XJC and the Maven JAXB2 Plugin [1].
> 
>  Consider that JAXB always holds the model in memory. If you intend to
>  maintain streams within an XML you can resort fragments and other
> stuff
>  MOXy supports. But let me tell you that it won't be that easy as you
>  think if you want everything as streaming with little memory usage.
> 
>  Michael
> 
>  BTW: this should go to dev@
> 
>  [1] https://github.com/highsource/maven-jaxb2-plugin
> 
>  -
>  To unsubscribe, e-mail: [hidden email]
>  
>  For additional commands, e-mail: [hidden email]
>  
> 
> 
> 
>  --
>  If you reply to this email, your message will be added to the
> discussion
>  below:
>  http://maven.40175.n5.nabble.com/Re-rewrite-StatelessXmlRepo
>  rter-fo-JAXB-
>  tp5906482.html
>  To start a new topic under Maven Developers, email
>  ml-node+s40175n142166...@n5.nabble.com
>  To unsubscribe from Maven Developers, click here
>    acro=unsubscribe_by_code=142166=dGlib3JkaWdhbmFAYX
>  BhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==>
>  .
>  NAML
> 

Re: [VOTE] Release Apache Maven Surefire Plugin version 2.20 - TAKE 3

[Andreas Gudian]

+1

Tested on a couple of projects, with Maven 3.3.9 and 3.5.0, on Win
(binaries) and macOS (source build).

Great job, Tibor!


2017-04-08 14:26 GMT+02:00 Petr Široký :

> +1 (non-binding)
>
> Tested on Fedora 25 + JDK 8u121 + Maven 3.5.0 with several large projects.
> No issue found.
>
> @Tibor, thanks for fixing all the issues I found previously!
>
> Petr
>
> On Sat, Apr 8, 2017 at 12:53 PM Tibor Digana 
> wrote:
>
> > Hi,
> >
> > We solved 70 issues:
> >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12317927=12334636
> >
> > There are still a couple of issues left in JIRA:
> >
> > https://issues.apache.org/jira/i#issues/?jql=project+%
> 3D+SUREFIRE+AND+status+%3D+Open+ORDER+BY+priority+DESC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1330/
> >
> > https://repository.apache.org/content/repositories/maven-
> 1330/org/apache/maven/surefire/surefire/2.20/surefire-2.20-source-release.
> zip
> >
> > Source release checksum(s):
> > surefire-2.20-source-release.zip sha1:
> > fda994228c52dcb581d8ce6d4664f84a29d78797
> >
> > Git tag:
> >
> > https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=
> 8c786523414018099b54a0868ae1bc3d64847411
> >
> > Staging site:
> > http://maven.apache.org/surefire-archives/surefire-LATEST/
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > Cheers,
> > Tibor
> >
>

Re: [VOTE] Release Apache Maven 3.5.0-alpha-1

[Andreas Gudian]

+1

Really awesome stuff, everyone!

(I tested with a good range of projects, some of them having different
versions of some karaf-maven-plugins that tend to break with Maven updates
-- everything was smooth, though.)


2017-02-23 17:10 GMT+01:00 Stephen Connolly :

> Hi,
>
> We solved 65 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12316922=12339664=Text
>
> There are still a couple of issues left in JIRA for 3.5.0, but I do not
> think any of those are blocking an alpha release:
> https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20AND%
> 20fixVersion%20in%20(3.5.0%2C%203.5.0-candidate)%20ORDER%
> 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>
> In addition there are 315 issues left in JIRA for Maven core:
> https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1324
>
> The distributable binaries and sources for testing can be found here:
> https://repository.apache.org/content/repositories/maven-
> 1324/org/apache/maven/apache-maven/3.5.0-alpha-1/
>
> Specifically the zip, tarball, and source archives can be found here:
> https://repository.apache.org/content/repositories/maven-
> 1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache-
> maven-3.5.0-alpha-1-bin.zip
> https://repository.apache.org/content/repositories/maven-
> 1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache-
> maven-3.5.0-alpha-1-bin.tar.gz
> https://repository.apache.org/content/repositories/maven-
> 1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache-
> maven-3.5.0-alpha-1-src.zip
> https://repository.apache.org/content/repositories/maven-
> 1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache-
> maven-3.5.0-alpha-1-src.tar.gz
>
> Source release checksum(s):
> apache-maven-3.5.0-alpha-1-src.tar.gz sha1:
> 6055696aece5b0bfdd0308dae60838b37e218aba
> apache-maven-3.5.0-alpha-1-src.zip sha1:
> 7d6adcdf8929205bf20399c71c6a2bdb9ee4f6dd
>
> Git tag:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> 8e6bbc4d4aa7cdc837625a05358c98ca15f72698
>
> Staging site:
> https://people.apache.org/~stephenc/maven-3.5.0-alpha-1/
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> Thanks,
> -Stephen
>

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

[Andreas Gudian]

+1


Anders Hammar  schrieb am Mi. 4. Jan. 2017 um 13:22:

> +1
>
>
>
> /Anders
>
>
>
> On Wed, Jan 4, 2017 at 1:16 PM, Stephen Connolly <
>
> stephen.alan.conno...@gmail.com> wrote:
>
>
>
> > Hi,
>
> >
>
> > We have collectively managed to mess up our ability to follow the
> original
>
> > release plan for 3.4.0 which was originally supposed to consist of an
>
> > effective no-op change of Eclipse's Aether for the code after migration
> to
>
> > Apache's Maven Resolver plus some other orthogonal changes around logging
>
> > colourization and launcher script bug fixes.
>
> >
>
> > Given that some developer private builds of the current master branch
> have
>
> > been shared with as 3.4.0-SNAPSHOT. More critically, JIRA issues have
> been
>
> > closed with a fixed version of 3.4.0.
>
> >
>
> > For us to release a 3.4.0 with those fixes reverted, could cause
> confusion
>
> > with our user community.
>
> >
>
> > Additionally the informal practice of keeping existing integration tests
> as
>
> > RTC has not been followed, leading to some people to question whether the
>
> > integration tests remain valid.
>
> >
>
> > For all the above reasons it is proposed to do *all* the following as an
>
> > whole:
>
> >
>
> > 1. In git://git.apache.org/maven.git we will rename the current master
>
> > branch to `pre-reset-master` and recreate `master`
>
> > as bce33aa2662a51d18cb00347cf2fb174dc195fb1 (
>
> > https://github.com/apache/maven/commit/bce33aa2662a51d18cb00347cf2fb1
>
> > 74dc195fb1
>
> > )
>
> >
>
> > 2. In git://git.apache.org/maven-integration-testing.git we will rename
>
> > the
>
> > current master branch to `pre-reset-master` and recreate `master`
>
> > as f31241ad6cb6474e559289f1bd7110ea5d5a4fba (
>
> > https://github.com/apache/maven-integration-testing/commit/
>
> > f31241ad6cb6474e559289f1bd7110ea5d5a4fba
>
> > )
>
> >
>
> > 3. In git://git.apache.org/maven-resolver.git we will rename the current
>
> > master branch to `pre-reset-master` and recreate `master`
>
> > as b74f7a1e8837875b4780199f644119f55d22465d (
>
> > https://github.com/apache/maven-resolver/commit/
>
> > b74f7a1e8837875b4780199f644119f55d22465d),
>
> > i.e. the 1.0.x branch
>
> >
>
> > We will then proceed to have (ideally) the original committers
> cherry-pick
>
> > (and tidy up an squash... if the original committers are not able to
> assist
>
> > then squashing may not be practicable) those changes that have been
> agreed
>
> > for 3.5.0 as summarized on the
>
> > https://cwiki.apache.org/confluence/display/MAVEN/Roadmap+2017 wiki page
>
> > (authorative source of the decisions summarized in the wiki page is the
>
> > mail thread:
>
> > https://mail-archives.apache.org/mod_mbox/maven-dev/201612.mbox/%3CCA%
>
> > 2BnPnMxERdjJq5ChMNP-HN_AvZOs8sm7Ud5aVcEza0BPnm5ZOw%40mail.gmail.com%3E
>
> >  ).
>
> >
>
> > As this involves a --force push on the `master` branch, we want to get
> the
>
> > approval of the committers before continuing.
>
> >
>
> > The vote will be open for at least 72 hours.
>
> >
>
> > The vote will be decided by a simple majority of valid votes cast. There
> is
>
> > no veto.
>
> >
>
> > The vote is open to all committers.
>
> >
>
> > In addition, for the vote to be valid, there must be at least 3x+1 votes
>
> > from PMC members
>
> >
>
> > [ ] +1: Yes
>
> > [ ] 0:
>
> > [ ] -1: No
>
> >
>
> > -Stephen
>
> > --
>
> > Sent from my phone
>
> >
>
>

Re: Building jar targeting multiple Java versions, including 9

[Andreas Gudian]

2016-08-31 22:02 GMT+02:00 Tibor Digana :

> >>So, we can try to have different source folders for different runtimes.
> No. If you are developers you would not say this.
> No developer would develop and merge the same code multiple times!!!
> Look, now let the maven-compiler-plugin to download jars of the same
> artifact which was released for Version 1.7 and 1.8, and now let the
> compiler wrap those two versions with current version 1.9 which is
> ready to be released. Now you have fat jar MRjar.
> This means any Java version of the artifact can be chosen on the top of
> JDK9.
>
> >>Most other plugins would need to be executed for each version as well -
> javadoc, junit
> No. because the previous Versions were already tested and processed.
>
> >>Again if they *don't* need a separate execution, then why is MRJar
> needed?
> Exactly, and now I cannot imaging company which is going to complicate
> their project with a stupid MRJar and why so if they have WildFly
> 8.2.1 which supports Java 8 do you think they EE project would
> struggle with MRJar? Of course not. If they have WildFly 10.x
> supporting Java 9 then again no developer would build MRJar.
>
> I think MRJar is suitable only for JDK internals and it is only
> because of Oracle has problem with JCP because JCP does not let Oracle
> to break backwards compatibility and introduce dynamic language
> features. So Oracle is trying for compromise.
> Oracle is trying to let you build java.* JDK with javac, interchange
> internal modules, etc.
> Nothing for other non-JDK projects.
>

That's a bit off-topic, as this thread is about the _how_ and not the
_why_, but I'd like to point out that I disagree with you here ;). MRJars
would be great for a lot of frameworks and libraries that you would _use_
in your end-product. Frameworks that offer different alternatives or
extended features requiring a newer JDK now have to build and maintain
artifacts either with different versions or with different artifactIds
(e.g. funky-annotations and funky-annotations-jdk8, where the -jdk8 variant
contains annotations with @Repeatable) -- there are a lot of examples out
there. And that's not only cumbersome for maintainers, but also for users
(which is the bad thing).

So go MRjars! Making them easily consumable for users is the top-prirority
and it looks like a solid approach.

Making them easy to build for the maintainers is way less important (as
that's only a tiny percentage of the maven-users out there), but it sure
needs to work with different IDEs and especially Eclipse would have
problems handling different target JDKs in the same project.

So for me as an Eclipse user, I'd have to take the road with the
multi-module projects. But that's okay, as I'm just building a framework
and separating the different variants for different JDKs has also a lot of
benefits, as already described above: testing, generating javadocs, and all
that other stuff is already there and can be used without having to change
anything. For me, a project collecting the internally seperate artifacts
and combining them into an MRjar would be totally fine.

Andreas



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

Re: [VOTE] Retire Maven Ant Tasks

[Andreas Gudian]

+1

Am Montag, 16. Mai 2016 schrieb Jason van Zyl :

> +1
>
> > On May 16, 2016, at 7:35 AM, Igor Fedorenko  > wrote:
> >
> > +1
> >
> > --
> > Regards,
> > Igor
> >
> > On Mon, May 16, 2016, at 01:43 AM, Anders Hammar wrote:
> >> +1
> >>
> >> /Anders (mobile)
> >> On May 15, 2016 23:24, "Michael Osipov"  > wrote:
> >>
> >>> Hi,
> >>>
> >>> this component hasn't been touched for years effectively and we rely
> now
> >>> on Maven for Maven (dog food). Additionally, Ant build support has
> already
> >>> been removed from Maven. This relic shouldn't be used with Maven 3
> anymore.
> >>> The last release was 2011-04-13.
> >>>
> >>> I therefore propose that we retire the Maven Ant Tasks.
> >>>
> >>> If this vote is successful I *won't* make one final release of the
> plugin,
> >>> but make it clear on the component site that it has been retired. After
> >>> that the source code will be moved into the "retired" area in
> Subversion. I
> >>> will also remove it from the lefthand side navigation in your site.xml.
> >>>
> >>> The process for retiring a plugin is described here:
> >>> https://maven.apache.org/developers/retirement-plan-plugins.html
> >>>
> >>> The vote is open for 72 hours.
> >>>
> >>> [ ] +1 Yes, it's about time
> >>> [ ] -1 No, because...
> >>>
> >>> -
> >>> 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
> 
> >
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
> For additional commands, e-mail: dev-h...@maven.apache.org 
>
>

Re: Information about how to develop plugin

[Andreas Gudian]

Hi Thomas,

One way to learn how things roll is to find an existing plugin that does
something related to what you are trying to do and check the sources there.
Many of the plugins developed here in the Apache Maven project are not too
complex and might help you finding what you look for. Same goes for the
mojohaus plugins.

I don't really know what the best source of wholesome documentation there
is otherwise, though.

Hope it still helps a little,
Andreas

Am Montag, 4. April 2016 schrieb Thomas Finneid :

> Hi
>
> I am looking into developing a maven plugin for a Scala testing framework
> named ScalaCheck.
>
> I was wondering if there is any up to date articles or such, that explain
> the main concepts of maven internals, its archtecture, work separation
> between modules, how it fits together in the build process and so on.
>
> I have run through the plugin developer article about how to create my
> first mojo, so I have a simple plugin that prints Hello World in my desired
> phase.
> I have looked through a lot of the documentation on plugin development and
> some of the maven development documentation.
> But I am having problems finding information that explains to me how
> things work and how to do stuff or how to access stuff in maven.
>
> All plugins do things and need to access information from maven, to be
> able to do anything useful. E.g. a compiler plugin needs to access the
> source files from the correct directories, it needs access to dependencies
> and so on
>
> As you migh guess I feel a bit lost, so any pointers, tips or explanations
> would be appreciated.
>
> Regards
>
> Thomas
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

[ANN] Apache Maven Compiler Plugin 3.5.1 Released

[Andreas Gudian]

The Apache Maven team is pleased to announce the release of the Apache
Maven Compiler Plugin, version 3.5.1.

The Compiler Plugin is used to compile the sources of your project.

http://maven.apache.org/plugins/maven-compiler-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-compiler-plugin
  3.5.1



Release Notes - Maven Compiler Plugin - Version 3.5.1

** Bug
* [MCOMPILER-236] - Compilation error due to MCOMPILER-157 in deploy
phase
* [MCOMPILER-240] - Generated sources directory should not be added to
compiler's source roots
* [MCOMPILER-262] - When using annotationProcessorPaths, the project
dependencies must not be added as well

Enjoy,

-The Apache Maven team

Re: [VOTE] Release Apache Maven Compiler Plugin 3.5.1

[Andreas Gudian]

Two hours to go - anyone else care for a vote? PMC quorum is not reached,
yet. ;-)


Am Samstag, 6. Februar 2016 schrieb Andreas Gudian :

> Hi,
>
> We solved 3 issues (well, two of them deal with the same error):
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12334747=Text=12317225
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317225%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1247/
>
> https://repository.apache.org/content/repositories/maven-1247/org/apache/maven/plugins/maven-compiler-plugin/3.5.1/maven-compiler-plugin-3.5.1-source-release.zip
>
> Source release checksum(s):
> maven-compiler-plugin-3.5.1-source-release.zip sha1:
> edb4a320dd9094bd0d38daf7647dd132e7dbafc3
>
> Staging site:
>
> http://maven.apache.org/components/plugins-archives/maven-compiler-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
>

[RESULT] [VOTE] Release Apache Maven Compiler Plugin version 3.5.1

[Andreas Gudian]

Hi,

The vote has passed with the following result:

+1 : Andreas Gudian, Michael Osipov, Anders Hammar, Karl Heinz Marbaise

PMC quorum: reached.

I will promote the artifacts to the central repo.

Thanks!

Re: [VOTE] Release Apache Maven Compiler Plugin 3.5.1

[Andreas Gudian]

@Michael: I'll still count your vote only once :-D. But thanks for the
spirit!


Am Dienstag, 9. Februar 2016 schrieb Michael Osipov :

> Am 2016-02-06 um 20:25 schrieb Andreas Gudian:
>
>> Hi,
>>
>> We solved 3 issues (well, two of them deal with the same error):
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12334747=Text=12317225
>>
>> There are still a couple of issues left in JIRA:
>>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317225%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-1247/
>>
>> https://repository.apache.org/content/repositories/maven-1247/org/apache/maven/plugins/maven-compiler-plugin/3.5.1/maven-compiler-plugin-3.5.1-source-release.zip
>>
>> Source release checksum(s):
>> maven-compiler-plugin-3.5.1-source-release.zip sha1:
>> edb4a320dd9094bd0d38daf7647dd132e7dbafc3
>>
>> Staging site:
>>
>> http://maven.apache.org/components/plugins-archives/maven-compiler-plugin-LATEST/
>>
>> Guide to testing staged releases:
>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>
>> Vote open for 72 hours.
>>
>
> +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 Compiler Plugin 3.5.1

[Andreas Gudian]

self +1

2016-02-06 20:25 GMT+01:00 Andreas Gudian <andreas.gud...@gmail.com>:

> Hi,
>
> We solved 3 issues (well, two of them deal with the same error):
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12334747=Text=12317225
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317225%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1247/
>
> https://repository.apache.org/content/repositories/maven-1247/org/apache/maven/plugins/maven-compiler-plugin/3.5.1/maven-compiler-plugin-3.5.1-source-release.zip
>
> Source release checksum(s):
> maven-compiler-plugin-3.5.1-source-release.zip sha1:
> edb4a320dd9094bd0d38daf7647dd132e7dbafc3
>
> Staging site:
>
> http://maven.apache.org/components/plugins-archives/maven-compiler-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
>

[VOTE] Release Apache Maven Compiler Plugin 3.5.1

[Andreas Gudian]

Hi,

We solved 3 issues (well, two of them deal with the same error):
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12334747=Text=12317225

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317225%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-1247/
https://repository.apache.org/content/repositories/maven-1247/org/apache/maven/plugins/maven-compiler-plugin/3.5.1/maven-compiler-plugin-3.5.1-source-release.zip

Source release checksum(s):
maven-compiler-plugin-3.5.1-source-release.zip sha1:
edb4a320dd9094bd0d38daf7647dd132e7dbafc3

Staging site:
http://maven.apache.org/components/plugins-archives/maven-compiler-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

Re: [VOTE] Release Apache Maven Doxia version 1.7

[Andreas Gudian]

+1 from me, although I had to remove the DEPENDENCIES file form the
source-zip in order to build it (the rat-config doesn't have an exclusion
for the file).

2016-02-06 0:10 GMT+01:00 Hervé BOUTEMY :

> Hi,
>
> We solved 17 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317230=12330561=Text
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20DOXIA%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1246/
>
> https://repository.apache.org/content/repositories/maven-1246/org/apache/maven/doxia/doxia/1.7/doxia-1.7-source-release.zip
>
> Source release checksum(s):
> doxia-1.7-source-release.zip sha1: 1971646a8a4b22cce7973889765fb69349c61cbe
>
> Staging site:
> http://maven.apache.org/doxia/doxia-archives/doxia-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: Manually triggeren dependency resolution within a plugin

[Andreas Gudian]

No idea if I've done it the way it is supposed to be done, but
check AbstractCompilerMojo#resolveProcessorPathEntries in the
maven-compiler-plugin.

In case it helps... :-)


Am Samstag, 6. Februar 2016 schrieb Karl Heinz Marbaise :

> Hi,
>
> If i'm in a plugin can i manually trigger the resolution of artifacts
> somehow. So that MavenProject.getArtifacts() is not null...
>
> Usually you would define the mojo like this which means the resolution is
> done by Maven core:
>
> @Mojo( name = "",
> requiresDependencyResolution = ResolutionScope.COMPILE,
> )
> public class WhatEverMojo
> extends AbstractMojo...
>
> But i'm searching for a way to trigger this manually...
>
> Someone an idea or a hint?
>
> Thanks in advance...
> Kind regards
> Karl Heinz
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

svn commit: r1728634 - /maven/pom/trunk/maven/pom.xml

[Andreas Gudian]

Welcome Andreas,

Great to have you on bord!

Andreas (the other one, but not Anders. Getting complicated.)

Am Freitag, 5. Februar 2016 schrieb :

> Author: adangel
> Date: Fri Feb  5 10:55:17 2016
> New Revision: 1728634
>
> URL: http://svn.apache.org/viewvc?rev=1728634=rev
> Log:
> Updated to add "Andreas Dangel" to the list of committers
>
> Modified:
> maven/pom/trunk/maven/pom.xml
>
> Modified: maven/pom/trunk/maven/pom.xml
> URL:
> http://svn.apache.org/viewvc/maven/pom/trunk/maven/pom.xml?rev=1728634=1728633=1728634=diff
>
> ==
> --- maven/pom/trunk/maven/pom.xml (original)
> +++ maven/pom/trunk/maven/pom.xml Fri Feb  5 10:55:17 2016
> @@ -280,6 +280,15 @@ under the License.
>
>  
>  
> +  adangel
> +  Andreas Dangel
> +  adan...@apache.org
> +  Europe/Berlin
> +  
> +Committer
> +  
> +
> +
>andham
>Anders Hammar
>and...@apache.org
>
>
>

Re: [ANN] Apache Maven Compiler Plugin Version 3.5 Released

[Andreas Gudian]

To be honest, I wasn't even aware of that bug, as I only checked the
summaries of the x latest bugs shortly before the release. And yes, when on
the command line, I always do a clean build, whereas my IDE does the
incremental stuff corrctly... :-/

But I get that it's annoying and I'll look into it.

Andreas

2016-01-21 15:44 GMT+01:00 Thomas Broyer <t.bro...@gmail.com>:

> On Wed, Jan 20, 2016 at 8:43 PM Andreas Gudian <agud...@apache.org> wrote:
>
> > ** New Feature
> > * [MCOMPILER-203] - Allow compiler-plugin to specify annotation
> > processor dependencies
> >
>
> Great! But…
>
> I don't get how you can add a feature about annotation processors and not
> at the same time fix one of the most annoying issue when using annotation
> processors that generate Java sources:
> https://issues.apache.org/jira/browse/MCOMPILER-235
>
> Is everyone always doing clean builds? or everyone sets
> useIncrementalCompilation to false?
> (or maybe everyone actually still uses 3.1; along with the
> build-helper-maven-plugin if they need the generated sources added as
> source roots in downstream plugins)
>
> /me frustrated
>

Re: [ANN] Apache Maven Compiler Plugin Version 3.5 Released

[Andreas Gudian]

I've just committed a potential fix for MCOMPILER-235.

If some of you could use 3.6-SNAPSHOT (either build it yourself with my
commit included, or wait a bit until it's updated in the apache snapshots
repository) and see if it works for you, I'd apreciate it.

But let's continue that discussion in
https://issues.apache.org/jira/browse/MCOMPILER-235

Thanks,
Andreas


2016-01-21 20:44 GMT+01:00 Andreas Gudian <andreas.gud...@gmail.com>:

> To be honest, I wasn't even aware of that bug, as I only checked the
> summaries of the x latest bugs shortly before the release. And yes, when on
> the command line, I always do a clean build, whereas my IDE does the
> incremental stuff corrctly... :-/
>
> But I get that it's annoying and I'll look into it.
>
> Andreas
>
> 2016-01-21 15:44 GMT+01:00 Thomas Broyer <t.bro...@gmail.com>:
>
>> On Wed, Jan 20, 2016 at 8:43 PM Andreas Gudian <agud...@apache.org>
>> wrote:
>>
>> > ** New Feature
>> > * [MCOMPILER-203] - Allow compiler-plugin to specify annotation
>> > processor dependencies
>> >
>>
>> Great! But…
>>
>> I don't get how you can add a feature about annotation processors and not
>> at the same time fix one of the most annoying issue when using annotation
>> processors that generate Java sources:
>> https://issues.apache.org/jira/browse/MCOMPILER-235
>>
>> Is everyone always doing clean builds? or everyone sets
>> useIncrementalCompilation to false?
>> (or maybe everyone actually still uses 3.1; along with the
>> build-helper-maven-plugin if they need the generated sources added as
>> source roots in downstream plugins)
>>
>> /me frustrated
>>
>
>

[RESULT] [VOTE] Release Apache Maven Compiler Plugin version 3.5

[Andreas Gudian]

Hi,

The vote has passed with the following result:

+1 : Andreas Gudian, Tibor Digana, Karl Heinz Marbaise

PMC quorum: reached.

I will promote the artifacts to the central repo.

Thanks!

[ANN] Apache Maven Compiler Plugin Version 3.5 Released

[Andreas Gudian]

The Apache Maven team is pleased to announce the release of the Apache
Maven Compiler Plugin, version 3.5.

The Compiler Plugin is used to compile the sources of your project.

http://maven.apache.org/plugins/maven-compiler-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-compiler-plugin
  3.5


Attention: Starting with this version, the maven-compiler-plugin requires
Maven 3 and won't work with Maven 2 anymore.


Release Notes - Maven Compiler Plugin - Version 3.5

** New Feature
* [MCOMPILER-203] - Allow compiler-plugin to specify annotation
processor dependencies

** Bug
* [MCOMPILER-211] - Compiler plugin (3.x) fails in eclipse

** Improvement
* [MCOMPILER-257] - Require Maven 3.0
* [MCOMPILER-258] - Removing exclusions from maven-core
* [MCOMPILER-259] - Upgrade maven-shared-utils to 3.0.0


Enjoy,

-The Apache Maven team

[VOTE] Release Apache Maven Compiler Plugin version 3.5

[Andreas Gudian]

Hi,

We solved 5 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12330435=Text=12317225

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317225%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-1244/
https://repository.apache.org/content/repositories/maven-1244/org/apache/maven/plugins/maven-compiler-plugin/3.5/maven-compiler-plugin-3.5-source-release.zip

Source release checksum(s):
maven-compiler-plugin-3.5-source-release.zip sha1:
9d3ef6767c64d4ad7a277e4be67d636175014c31

Staging site:
http://maven.apache.org/components/plugins-archives/maven-compiler-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

Re: [VOTE] Release Apache Maven Compiler Plugin version 3.5

[Andreas Gudian]

My +1:

- checked SHA-1 sum
- checked building from source with ITs
- tested binaries with some smaller projects.


2016-01-17 0:03 GMT+01:00 Andreas Gudian <andreas.gud...@gmail.com>:

> Hi,
>
> We solved 5 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12330435=Text=12317225
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317225%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1244/
>
> https://repository.apache.org/content/repositories/maven-1244/org/apache/maven/plugins/maven-compiler-plugin/3.5/maven-compiler-plugin-3.5-source-release.zip
>
> Source release checksum(s):
> maven-compiler-plugin-3.5-source-release.zip sha1:
> 9d3ef6767c64d4ad7a277e4be67d636175014c31
>
> Staging site:
>
> http://maven.apache.org/components/plugins-archives/maven-compiler-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
>
>

Releasing m-compiler-p 3.5..?

[Andreas Gudian]

Hey there,

I'd like to start with the release process for the maven-compiler-plugin
3.5. It's on Maven 3 now, but the adjustments and cleanups in that area are
only minor until now.

Other than that, it contains one small bugfix and one new feature (support
for specifying an annotation processor classpath to be handed over in
-processorpath to the compiler).

Is anyone planning to do something on the plugin in the next couple of days
and want to see it included in the release? Otherwise I'd just start
rolling it today or tomorrow or so.

Thanks,
Andreas

Re: migrating Surefire to 3.0-RC1

[Andreas Gudian]

Adding maven-compat for the test did the trick for now in my case. If only
I had read that wiki page before, because it actually describes this
already... :-D



2016-01-08 14:55 GMT+01:00 Tibor Digana <tibordig...@apache.org>:

> Hi Kristian,
>
> I do not have edit permissions in confluence. Who can grant me?
>
> On Fri, Jan 8, 2016 at 9:41 AM, Kristian Rosenvold-4 [via Maven] <
> ml-node+s40175n5858379...@n5.nabble.com> wrote:
>
> > I would recommend that you instead update the existing wiki page that we
> > use to gather "tips" about migrating plugins:
> >
> >
> >
> >
> https://cwiki.apache.org/confluence/display/MAVEN/Plugin+migration+to+Maven3+dependencies
> >
> > Kristian
> >
> >
> > 2016-01-08 1:18 GMT+01:00 Tibor Digana <[hidden email]
> > <http:///user/SendEmail.jtp?type=node=5858379=0>>:
> >
> > > Hi Andreas,
> > >
> > > See Robert's change. This maybe helps
> > >
> > >
> >
> https://github.com/apache/maven-surefire/commit/9cb143414134a2c8f0bfec5b84f01571875a26fe
> > >
> > > On Thu, Jan 7, 2016 at 9:54 PM, Andreas Gudian <[hidden email]
> > <http:///user/SendEmail.jtp?type=node=5858379=1>>
> > > wrote:
> > >
> > > > Hey,
> > > >
> > > > funny, I ran into the very same problem when working on MCOMIPLER-203
> > and
> > > > after updating to Maven 3.0 dependencies: I'm getting the very same
> > > > exception when running the CompilerMojoTestCase.
> > > >
> > > > I'm all ears on how to solve that, so if anyone has a hint... :)
> > > >
> > > > I pushed a branch on github, and, for Tibor: here's how I did the
> > > > dependency resolution without using maven-compat or deprecated APIs
> > > > (although I have no clue if that's how it is supposed to be done):
> > > >
> > > >
> > >
> >
> https://github.com/agudian/maven-plugins/commit/51648fc612c55920f7c887a42470a85914858e5e#diff-384c9234a411cc2c48bfb9c8731993b7
> > > >
> > > > For reference, that's what I'm trying to do:
> > > > https://issues.apache.org/jira/browse/MCOMPILER-203
> > > >
> > > > Thanks for any pointers,
> > > > Andreas
> > > >
> > > >
> > > > 2016-01-07 20:33 GMT+01:00 Tibor Digana <[hidden email]
> > <http:///user/SendEmail.jtp?type=node=5858379=2>>:
> > > >
> > > > > Now I removed maven-compat completely.
> > > > >
> > > > > 
> > > > >   org.apache.maven.shared
> > > > >   maven-artifact-transfer
> > > > >   3.0-SNAPSHOT
> > > > > 
> > > > >
> > > > > It seems release version is not available.
> > > > >
> > > > > I should resolve compilation error after new 3.0 AtrifactResolver
> > and
> > > > > I will come back to you.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > return artifactResolver.resolveTransitively( Collections.singleton(
> > > > > providerArtifact ), originatingArtifact,
> > > > >  localRepository,
> > > > > remoteRepositories, artifactMetadataSource,
> > > > >  filter );
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Jan 7, 2016 at 7:39 PM, Robert Scholte <[hidden email]
> > <http:///user/SendEmail.jtp?type=node=5858379=3>>
> > > > > wrote:
> > > > >
> > > > > > Hi Tibor,
> > > > > >
> > > > > > Bullet 4: Remove maven-compat (or give it the test-scope if it is
> > > > > required
> > > > > > by the maven-plugin-testing-harness)
> > > > > >
> > > > > > Now I think you're at a state where Maven2 classes must be
> > replaced
> > > > with
> > > > > > Maven3 solutions.
> > > > > >
> > > > > > Robert
> > > > > >
> > > > > > Op Thu, 07 Jan 2016 18:54:06 +0100 schreef Tibor Digana <
> > > > > > [hidden email]
> > <http:///user/SendEmail.jtp?type=node=5858379=4>>:
> > > > > >
> > > > > >
> > > > > > Hi Robert,
> &

Re: migrating Surefire to 3.0-RC1

[Andreas Gudian]

Hey,

funny, I ran into the very same problem when working on MCOMIPLER-203 and
after updating to Maven 3.0 dependencies: I'm getting the very same
exception when running the CompilerMojoTestCase.

I'm all ears on how to solve that, so if anyone has a hint... :)

I pushed a branch on github, and, for Tibor: here's how I did the
dependency resolution without using maven-compat or deprecated APIs
(although I have no clue if that's how it is supposed to be done):
https://github.com/agudian/maven-plugins/commit/51648fc612c55920f7c887a42470a85914858e5e#diff-384c9234a411cc2c48bfb9c8731993b7

For reference, that's what I'm trying to do:
https://issues.apache.org/jira/browse/MCOMPILER-203

Thanks for any pointers,
Andreas


2016-01-07 20:33 GMT+01:00 Tibor Digana :

> Now I removed maven-compat completely.
>
> 
>   org.apache.maven.shared
>   maven-artifact-transfer
>   3.0-SNAPSHOT
> 
>
> It seems release version is not available.
>
> I should resolve compilation error after new 3.0 AtrifactResolver and
> I will come back to you.
>
>
>
>
> return artifactResolver.resolveTransitively( Collections.singleton(
> providerArtifact ), originatingArtifact,
>  localRepository,
> remoteRepositories, artifactMetadataSource,
>  filter );
>
>
>
>
> On Thu, Jan 7, 2016 at 7:39 PM, Robert Scholte 
> wrote:
>
> > Hi Tibor,
> >
> > Bullet 4: Remove maven-compat (or give it the test-scope if it is
> required
> > by the maven-plugin-testing-harness)
> >
> > Now I think you're at a state where Maven2 classes must be replaced with
> > Maven3 solutions.
> >
> > Robert
> >
> > Op Thu, 07 Jan 2016 18:54:06 +0100 schreef Tibor Digana <
> > tibor.dig...@googlemail.com>:
> >
> >
> > Hi Robert,
> >>
> >> I did as you said and I have new issue. Any dea?
> >>
> >>
> >>
> >>
> testSurefireReportSingleError(org.apache.maven.plugins.surefire.report.SurefireReportMojoTest)
> >> Time elapsed: 0.042 sec  <<< ERROR!
> >>
> >>
> org.codehaus.plexus.component.repository.exception.ComponentLookupException:
> >> java.util.NoSuchElementException
> >>   role: org.apache.maven.repository.RepositorySystem
> >>   roleHint:
> >> at
> >>
> >>
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:253)
> >> at
> >>
> >>
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:241)
> >> at
> >>
> >>
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:235)
> >> at
> org.codehaus.plexus.PlexusTestCase.lookup(PlexusTestCase.java:207)
> >> at
> >>
> >>
> org.apache.maven.plugin.testing.AbstractMojoTestCase.setUp(AbstractMojoTestCase.java:118)
> >> at
> >>
> >>
> org.apache.maven.plugins.surefire.report.SurefireReportMojoTest.setUp(SurefireReportMojoTest.java:56)
> >> at junit.framework.TestCase.runBare(TestCase.java:139)
> >> at junit.framework.TestResult$1.protect(TestResult.java:122)
> >> at junit.framework.TestResult.runProtected(TestResult.java:142)
> >> at junit.framework.TestResult.run(TestResult.java:125)
> >> at junit.framework.TestCase.run(TestCase.java:129)
> >> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> >> at junit.framework.TestSuite.run(TestSuite.java:247)
> >> at
> >>
> >>
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> >> at
> >>
> >>
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> >> at
> >>
> >>
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> >> at
> >>
> >>
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >> at
> >>
> >>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> >> at
> >>
> >>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >> at java.lang.reflect.Method.invoke(Method.java:497)
> >> at
> >>
> >>
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> >> at
> >>
> >>
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> >> at
> >>
> >>
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> >> at
> >>
> >>
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> >> at
> >> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> >> Caused by: java.util.NoSuchElementException
> >> at java.util.Collections$EmptyIterator.next(Collections.java:4189)
> >> at
> >>
> >>
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:249)
> >> ... 25 more
> >>
> >>
> >>
> >>
> >>
> >> On Thu, Jan 7, 2016 at 6:10 PM, Robert 

Re: [VOTE] Release Apache Maven Shared Component: Maven Shared IO Version 3.0.0

[Andreas Gudian]

Santa says it's alright, so here's my +1. :)

2015-12-23 13:17 GMT+01:00 Karl Heinz Marbaise :

> Hi,
>
> i need one more PMC vote...;-)...
>
> On 12/20/15 2:05 PM, Karl Heinz Marbaise wrote:
>
>> Hi,
>>
>> We solved 5 issues:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12334278
>>
>>
>> There are still a couple of issues left in JIRA:
>>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC
>>
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-1238
>>
>> https://repository.apache.org/content/repositories/maven-1238/org/apache/maven/shared/maven-shared-io/3.0.0/maven-shared-io-3.0.0-source-release.zip
>>
>> Source release checksum(s):
>> maven-shared-io-3.0.0-source-release.zip sha1:
>> eafa730cf5d9d11fd1669cffa95ef61c92cfbae7
>>
>> Staging site:
>> http://maven.apache.org/shared-archives/maven-shared-io-LATEST/
>>
>> Guide to testing staged releases:
>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>
>> Vote open for 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>> 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: [VOTE] Release Apache Maven PMD Plugin version 3.6

[Andreas Gudian]

+1

2015-12-13 22:20 GMT+01:00 Dennis Lundberg :

> Hi,
>
> We solved 4 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317621=12332973
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317621%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1237/
>
> https://repository.apache.org/content/repositories/maven-1237/org/apache/maven/plugins/maven-pmd-plugin/3.6/maven-pmd-plugin-3.6-source-release.zip
>
> Source release checksum(s):
> [NAME-OF]-source-release.zip sha1: 2a8528d699898612ebbc036a1d4128c30235ce29
>
> Staging site:
> http://maven.apache.org/plugins-archives/maven-pmd-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
>
>

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[Andreas Gudian]

> JUnit 4 End Of Life
>
> I have a strong reason to use Java 8 in Surefire project.
> For more information read this
> https://github.com/junit-team/junit-lambda/issues/31


Hi Tibor,

Wouldn't it be enough to only build the new Junit-5 provider with
source/target level 8 (if that would even be necessary) and switch the
animal-sniffer to JDK 8 signatures only for that module? Or move that
provider to its own repository with its own JDK 8 build...

In any case, I don't think we'd have a strict requirement to move all of
surefire to Java 8 bytecode only because of a new test provider - or a
dependency thereof. Sure it would be cool to go full Java 8 in Surefire,
but I don't think we can or should pull that off.

Re: Plexus repos moved

[Andreas Gudian]

Hi Kristian,

can you please give me push-access to the plexus-compiler repository?

I'm working on an old MCOMPILER issue and need to change stuff over there
as well...

Thanks,
Andreas


2015-02-09 18:13 GMT+01:00 Kristian Rosenvold :

> They are now all at https://github.com/codehaus-plexus
>
> The issue tracking should be closed on the sonatype clones, it does
> not seem like it's possible to disable pull requests.
>
> Any maven devs or existing committers needing permissions should just
> ping. We'll hopefully get maven central access for publishing for
> everyone in the github org. In the meantime, the "usual suspects" can
> publish to central.
>
> Kristian
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: I wish we had a way to declare a dependency that wouldn't participate in the classpath

[Andreas Gudian]

2015-12-13 19:04 GMT+01:00 Benson Margulies :

> On Sun, Dec 13, 2015 at 9:40 AM, Benson Margulies 
> wrote:
> > On Dec 13, 2015 3:25 AM, "Stephen Connolly"
> >  wrote:
> >>
> >> pom?
> >
> >
> > 1. The feature descriptor is xml
> >
> > 2. I believe that this still adds transitive dependencies to the
> dependency
> > graph.
>
> How about the following proposition: of the type is not jar, nothing
> goes onto the classpath? Not the thing, not its dependencies?
>

That sounds reasonable. Only stuff that _has_ a classpath should expose a
classpath.



>
> >
> >
> >
> >>
> >>
> >> On Saturday 12 December 2015, Benson Margulies 
> >> wrote:
> >>
> >> > Sometimes, we want to declare a dependency without changing a
> classpath.
> >> >
> >> > Project A builds an OSGi bundle and a Karaf feature (classifier
> >> > 'feature', type 'xml').
> >> >
> >> > Project B wants to consume the feature. it wants to declare the
> >> > feature descriptor as a dependency, to (a) ensure reactor order, and
> >> > (b) make the dependency information available to plugins.
> >> >
> >> > But it does _not_ want A's OSGi bundle and it's dependencies in the
> >> > classpath.
> >> >
> >> > The only way out is to exclude them, one-by-one. And when someone adds
> >> > a dependency to A, you have to maintain the exclusion list.
> >> >
> >> > Another example is the tomcat plugin: it needs wars as dependencies,
> >> > and similarly it needs to avoid having their dependencies in the
> >> > classpath.
> >> >
> >> > To me, this calls out for another scope.
> >> >
> >> > -
> >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> 
> >> > For additional commands, e-mail: dev-h...@maven.apache.org
> >> > 
> >> >
> >> >
> >>
> >> --
> >> Sent from my phone
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: I wish we had a way to declare a dependency that wouldn't participate in the classpath

[Andreas Gudian]

2015-12-13 12:05 GMT+01:00 Robert Scholte :

> The first time I heard about JDK9s Jigsaw having a classpath and a
> modulepath, which can be used at the same time AND both containing jars, I
> had a big "OH NO!". We can't change the pom, so the first thing that
> came to my mind was indeed using the scope for this. But that'll have a
> huge impact: if jars need to be used at compile time but don't have that
> scope, what will happen with transitive resolution for example?
> I had a small talk with Alan, Mark and Alexander of the Jigsaw team about
> this. You could say that this is a new specification of a jar which asks
> for a different file-extension. They said that the jar file specification
> was extended. I said that we can't expect from users to know what kind of
> jar it is. Also, buildtools shouldn't pay the price for analyzing the jar
> to discover if it has a module-info or not. Mark immediately answered that
> they should take care of it.
> Now that I'm working on the maven-compiler-plugin it looks like it won't
> be a compile time issue. However, depending on our approach it might be an
> issue for Surefire.
> So yes: I recognize the situation. Dependencies are all very classpath
> oriented assuming that a specific type is always used in the same way.
>
> That's why I want to drop the strict scopes for plugins. Best example is
> the maven-javadoc-plugin where you can add jars for bootclasspath, doclets,
> resources, taglets. My idea: don't add these dependencies as configuration
> elements, but as standard plugin dependencies with there own scope. And
> since there dependencies are specific for this plugin, it can choose any
> scope it likes and select them within its own Mojo code.
>

But I would guess such specially scoped dependencies still show up on the
classpath of the plugin itself, right? For example, right now I'm looking
into MCOMPILE-203 which is about configuring the -processorpath option of
javac. Right now I have it working locally with a new
configuration-element. Using a special scope in the plugin-dependency
would, currently, mean polluting the plugins classpath - which wouldn't be
that ideal.

Or are plugin-dependencies with funky scopes already filtered out right now?




>
> For plugins such a change is easy, but within the scope of the pom that's
> hard.
>
> Robert
>
>
> Op Sat, 12 Dec 2015 22:04:47 +0100 schreef Benson Margulies <
> bimargul...@gmail.com>:
>
>
> Sometimes, we want to declare a dependency without changing a classpath.
>>
>> Project A builds an OSGi bundle and a Karaf feature (classifier
>> 'feature', type 'xml').
>>
>> Project B wants to consume the feature. it wants to declare the
>> feature descriptor as a dependency, to (a) ensure reactor order, and
>> (b) make the dependency information available to plugins.
>>
>> But it does _not_ want A's OSGi bundle and it's dependencies in the
>> classpath.
>>
>> The only way out is to exclude them, one-by-one. And when someone adds
>> a dependency to A, you have to maintain the exclusion list.
>>
>> Another example is the tomcat plugin: it needs wars as dependencies,
>> and similarly it needs to avoid having their dependencies in the
>> classpath.
>>
>> To me, this calls out for another scope.
>>
>> -
>> 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: svn commit: r1719038 - /maven/pom/trunk/maven/pom.xml

[Andreas Gudian]

Welcome, Christian! Great to have you with us!


Am Donnerstag, 10. Dezember 2015 schrieb Karl Heinz Marbaise :

> Hi Christian,
>
> also a welcome from my side..
>
> Kind regards
> Karl Heinz Marbaise
>
> On 12/10/15 11:08 PM, Hervé BOUTEMY wrote:
>
>> yeah, welcome to the team, Christian!
>>
>> Le jeudi 10 décembre 2015 07:50:11 Jason van Zyl a écrit :
>>
>>> Woo hoo!
>>>
>>> On Dec 10, 2015, at 1:39 AM, schu...@apache.org wrote:

 Author: schulte
 Date: Thu Dec 10 09:39:15 2015
 New Revision: 1719038

 URL: http://svn.apache.org/viewvc?rev=1719038=rev
 Log:
 Updated to add 'Christian Schulte' to the list of committers.

 Modified:
 maven/pom/trunk/maven/pom.xml

 Modified: maven/pom/trunk/maven/pom.xml
 URL:

 http://svn.apache.org/viewvc/maven/pom/trunk/maven/pom.xml?rev=1719038
 =1719037=1719038=diff

 =
 = --- maven/pom/trunk/maven/pom.xml (original)
 +++ maven/pom/trunk/maven/pom.xml Thu Dec 10 09:39:15 2015
 @@ -494,6 +494,15 @@ under the License.

+1

  
  

 +  schulte
 +  Christian Schulte
 +  schu...@apache.org
 +  
 +Committer
 +  
 +  Europe/Berlin
 +
 +

simonetripodi
Simone Tripodi
simonetrip...@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: [DISCUSS] Java version requirement for Mavan 3.4.x

[Andreas Gudian]

Great, it's that time of year again :-).

I'm all for bumping the Java version, although I have no apparent need for
it. But Java 8 opens so many doors, as Stephen listed... And who knows how
long we'll live with 3.4.x.

In the end, usually users who are stuck with an old JDK for their code
either freezed most of their tooling aswell, including their old version of
Hudson or Jenkins, their Maven 3.0.5, and stuff like that... or they use
Toolchains (as they should)

My 2e-2 €


2015-11-30 22:18 GMT+01:00 Stephen Connolly :

> Picking up from
>
> http://mail-archives.apache.org/mod_mbox/maven-dev/201511.mbox/%3CCA%2BnPnMyjogmqRweYbxLuULLB9ve2P6MPcQuH%2BPkxcNn-oN4GPg%40mail.gmail.com%3E
> (and my follow up to that but archive.apache.org is being a tad slow)
>
> Here is our policy:
>
> The development line of Maven core should require a minimum JRE version
> > that is no older than 18 months after the end of Oracle's public updates
> > for that JRE version at the time that the first version of the
> development
> > line was released, but may require a higher minimum JRE version if other
> > requirements dictate a higher JRE version
>
>
> (Source:
> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy)
>
> OK, so it's a draft policy... but we've all been silent on the draft, so
> lazy consensus!
>
> Now in http://www.oracle.com/technetwork/java/javase/eol-135779.html they
> state:
>
> after April 2015, Oracle will not post further updates of Java SE 7 to its
> > public download sites
>
>
> So per our (draft) version number policy, we can keep Java 7 as the
> baseline :-( or we can choose to upgrade code to Java 8 (because we want to
> use lambdas... there's a requirement)
>
>
> So assuming we bump the master branch of Maven core to 3.4.0, what Java
> version do we want to use as the baseline?
>
> There are thankfully only two options:
>
> Java 7
>   + Not actually changing things
>   + May make it easier to drive adoption
>   - Still can't use newer language features in core
>   - Java 7 is EOL and it may get harder for developers to source JDKs to
> test and develop against
>
> Java 8
>   + We're not as old hat any more
>   + We can use lambdas
>   + We can use Nashorn (may make integrating with Node easier... certainly
> could make integrating with JavaScript tooling easier)
>   + EOL for Java 8 is at least Sep 2017 (and may be later)
>   - May be harder to drive adoption in shops that have issues upgrading
> Java (but toolchains and they likely wouldn't upgrade to 3.4.x anyway
> unless there are features dragging their change controlled heels over the
> line)
>
> So...
>
> Let's have a heated debate!
>
> -Stephen
>
> P.S.
>
>   I'm waiting for Chris to chime in about how IBM is still supporting Java
> 1.3 or something like that ;-)
>

Re: Why can't dependency plugin "see" statics /and staticimports

[Andreas Gudian]

AFAIR, such constants (primitives and Strings) are inlined by the compiler
- and the dependeny analyzer works on the bytecode and not the sources,
right?



Am Mittwoch, 25. November 2015 schrieb Jochen Wiedmann :

> What exactly is it, you'd like to detect?
>
>
> On Wed, Nov 25, 2015 at 8:11 AM, Kristian Rosenvold
> > wrote:
> > I poked around in the depdenedncy analyzer code to see if I could make
> > it "see" the following code:
> >
> > Module 1:
> > public class Test2 {
> > public static final int AZAZ = 42;
> > }
> >
> > Module 2:
> >
> > import foo.Test2;
> >
> > public class BarMain
> > {
> > public static void main(String[] args) {
> > System.out.println("AZ " + Test2.AZAZ);
> > }
> > }
> >
> > Isn't this possible to detect or am I just a total n00b with asm ??
> >
> >
> > Kristian
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
> > For additional commands, e-mail: dev-h...@maven.apache.org
> 
> >
>
>
>
> --
> The next time you hear: "Don't reinvent the wheel!"
>
>
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
> For additional commands, e-mail: dev-h...@maven.apache.org 
>
>

Fwd: Open Test Alliance

[Andreas Gudian]

Forwarding to dev@

-- Forwarded Message --
From: *Johannes Link* 
Date: 18/11/2015
Subject: Open Test Alliance


Hi you all,

I'm writing to you in your roles as committers to the maven sure-fire
plugin. Since we couldn't figure out the "main contributors" (in case
you have such a thing), I randomly picked a few from:
https://maven.apache.org/surefire/maven-surefire-plugin/team-list.html
Maybe we can communicate through just one or a few people later, if
necessary. If the right person is not in the list, please forward the
email or let me know who I should contact. Let's get to the point:

We, the JUnit Lambda team, are reaching out to you for collaboration
on an initiative we are tentatively calling the Open Test Alliance.

As we all know, there is no standard for testing on the JVM. The only
common building block we have is java.lang.AssertionError. That's
great for signaling that a test has failed, but it doesn't go far
enough. Each testing framework is therefore forced to fill the gap
with custom subclasses of AssertionError or RuntimeException to
provide a richer feature set to end users. The downside is that each
framework has its *own* set of custom errors and exceptions, and this
makes it a challenge for frameworks to interoperate. For example,
JUnit has long supported the notion of a failed assumption via its
AssumptionViolatedException, but assertion frameworks like AssertJ
cannot integrate that feature without a direct dependency on JUnit.
Furthermore, the status quo makes the work of IDE and build tools more
difficult than it should be.

The solution is to create a foundation that we can all build on!

Based on recent discussions with IDE and build tool developers from
Eclipse, Gradle, and IntelliJ, the JUnit Lambda team has developed a
proposal for an open source project to provide a minimal common
foundation for testing libraries on the JVM. The primary goal of the
project is to enable testing frameworks like JUnit, TestNG, Spock,
etc. and third-party assertion libraries like Hamcrest, AssertJ, etc.
to use a common set of exceptions that IDEs and build tools can
support in a consistent manner across all testing scenarios -- for
example, for consistent handling of failed expectations and failed
assumptions as well as visualization of test execution in IDEs and
reports.

We have already begun with a small set of errors and exceptions that
we consider to be common for all testing and assertion frameworks. In
fact, we are already using these exceptions in the JUnit Lambda
Prototype [1].

Please take a look at our current draft in the open-test-alliance [2]
project and let us know what you think.

Furthermore, in order to foster open discussions, we have created a
GitHub issue [3] where you are welcome to comment and collaborate.

We look forward to your feedback and encourage you to join us in this
initiative to make testing easier for everyone on the JVM.

Best regards,

Johannes, in the name of the JUnit Lambda Team


[1] https://github.com/junit-team/junit-lambda/wiki/Prototype
[2]
https://github.com/junit-team/junit-lambda/tree/master/open-test-alliance
[3] https://github.com/junit-team/junit-lambda/issues/12

Re: [VOTE] Maven 3.3.9

[Andreas Gudian]

+1 from me.

2015-11-10 18:16 GMT+01:00 Jason van Zyl :

> Hi,
>
> Time to release Maven 3.3.9!
>
> Here is a link to the issues resolved:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12333074
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1233/
>
> The distributable binaries and sources for testing can be found here:
>
> https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/
>
> Specifically the zip, tarball, and source archives can be found here:
>
> https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/apache-maven-3.3.9-bin.zip
>
> https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/apache-maven-3.3.9-bin.tar.gz
>
> https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/apache-maven-3.3.9-src.zip
>
> https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/apache-maven-3.3.9-src.tar.gz
>
> Source release checksum(s):
> apache-maven-3.3.9-src.zip sha1: 2b783992afcba54255f46508d582fe656e2c37dc
>
> Staging site:
> http://people.apache.org/~jvanzyl/maven-3.3.9/
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
>
> A party which is not afraid of letting culture,
> business, and welfare go to ruin completely can
> be omnipotent for a while.
>
>   -- Jakob Burckhardt
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Updating the default versions for maven-compiler-plugin

[Andreas Gudian]

I think it's actually a good idea to do something about that.

Users who don't specify a source/target version would fall on their bottoms
with a change to 1.7 as default as well. So why using 1.7 as a default,
which is EOL (or at least nearly) anyway?

Keeping the default on 1.5 might bite users also in the near future, as the
JDK compiler only supports a limited number of previous versions. Is 1.5
even still supported in JDK 8?

But I guess the question is if we want to put in a fixed default value for
those parameters anyway. Instead, we could just detect the actual
language version of the JDK used for the build / in the toolchain Using
source/target versions different than the JDK language version is fishy
anyway - which will change in JDK 9, but there it's a new parameter
(-platform or something? I don't remember right now).

My 0,02€... ;-)

Andreas

Am Freitag, 6. November 2015 schrieb Michael Osipov :

> Am 2015-11-06 um 13:56 schrieb Attila-Mihály Balázs:
>
>> Hello,
>>
>> Given that we're almost in 2015, what do people think about updating the
>> default source / target for maven-compiler-plugin to 1.8? (And also on
>> the site:
>>
>> https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-source-and-target.html
>> ).
>>
>
> Clearly -1
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Updating the default versions for maven-compiler-plugin

[Andreas Gudian]

2015-11-06 18:42 GMT+01:00 Uwe Barthel :

> -1
>
> Many commercial projects still require Java 1.6.
>

The question asked by Attila is if the *default *values for the
source/target parameters in the compiler-plugin could use some attention
(and I think it should, as the default value 1.5 is just useless and
constantly confuses people that are new to maven).
This is not about limiting the possible JDK versions that can be used in
toolchains or used in the build, or to limit the possible values of those
parameters... :-)



>
> mit freundlichen Grüßen
> --
> Uwe Barthel 
>
>
>
>
> On November 6, 2015 1:57:04 PM Attila-Mihály Balázs 
> wrote:
>
> Hello,
>>
>> Given that we're almost in 2015, what do people think about updating the
>> default source / target for maven-compiler-plugin to 1.8? (And also on
>> the site:
>>
>> https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-source-and-target.html
>> ).
>>
>> If there is interest, I'm happy to submit a patch!
>>
>> Cheers,
>> Attila Balazs (Grey Panther)
>>
>> -
>> 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 JDeps Plugin version 3.0.0

[Andreas Gudian]

+1 :)

2015-10-29 15:19 GMT+01:00 Tamás Cservenák :

> +1
>
> On Wed, Oct 28, 2015 at 5:28 PM Robert Scholte 
> wrote:
>
> > +1
> > Robert Scholte
>

Re: [VOTE] Maven 3.3.7

[Andreas Gudian]

It's a smooth ride. Here's my +1 ... not legally, but morally binding ;)

2015-10-28 14:30 GMT+01:00 Jason van Zyl :

> Hi,
>
> Time to release Maven 3.3.7!
>
> Here is a link to the issues resolved:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12333074
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1228/
>
> The distributable binaries and sources for testing can be found here:
>
> https://repository.apache.org/content/repositories/maven-1228/org/apache/maven/apache-maven/3.3.7/
>
> Specifically the zip, tarball, and source archives can be found here:
>
> https://repository.apache.org/content/repositories/maven-1228/org/apache/maven/apache-maven/3.3.7/apache-maven-3.3.7-bin.zip
>
> https://repository.apache.org/content/repositories/maven-1228/org/apache/maven/apache-maven/3.3.7/apache-maven-3.3.7-bin.tar.gz
>
> https://repository.apache.org/content/repositories/maven-1228/org/apache/maven/apache-maven/3.3.7/apache-maven-3.3.7-src.zip
>
> https://repository.apache.org/content/repositories/maven-1228/org/apache/maven/apache-maven/3.3.7/apache-maven-3.3.7-src.tar.gz
>
> Source release checksum(s):
> apache-maven-3.3.7-src.zip sha1: 771b5f3844d41e573cfb921a555ca4b9fa25a938
>
> Staging site:
> http://people.apache.org/~jvanzyl/maven-3.3.7/
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Thanks,
>
> The Maven Team
>
>
>
>
>
>
>
>
>
>
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
>
> The modern conservative is engaged in one of man's oldest exercises in
> moral philosophy; that is,
> the search for a superior moral justification for selfishness.
>
>  -- John Kenneth Galbraith
>
>
>
>
>
>
>
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Surefire Plugin version 2.19 (Take 2)

[Andreas Gudian]

Benson, is there a full stack trace in the XML test report? I would have
expected that we shorten out most of the stack traces on the console
output...

2015-10-16 16:35 GMT+02:00 Benson Margulies :

> On Fri, Oct 16, 2015 at 10:31 AM, Tibor Digana 
> wrote:
> > Can you give me the link?
>
>
> https://github.com/ops4j/org.ops4j.pax.exam2/commit/c466e58cae6c2275a38bc2712cc76a70f768d769
>
>
> >
> > On Fri, Oct 16, 2015 at 4:27 PM, Benson Margulies [via Maven] <
> > ml-node+s40175n5849346...@n5.nabble.com> wrote:
> >
> >> I've committed the fix to the master for pax-exam.
> >>
> >>
> >> On Fri, Oct 16, 2015 at 10:19 AM, Benson Margulies
> >> <[hidden email]  /user/SendEmail.jtp?type=node=5849346=0>>
> >> wrote:
> >>
> >> > On Fri, Oct 16, 2015 at 9:56 AM, Tibor Digana
> >> > <[hidden email]  /user/SendEmail.jtp?type=node=5849346=1>>
> >> wrote:
> >> >> try to debug this stack part of ProbeRunner.
> >> >> What version of pax-exam-spi you use?
> >> >
> >> > 4.6.0. I am testing the fix to pax-exam now.
> >> >
> >> >>
> >> >>  at org.ops4j.pax.exam.spi.
> >> >>
> >>
> reactors.ReactorManager.addConfigurationsToReactor(ReactorManager.java:239)
> >> >>  at
> >> >>
> >>
> org.ops4j.pax.exam.spi.reactors.ReactorManager.prepareReactor(ReactorManager.java:184)
> >>
> >> >>  - locked <0x411> (a org.ops4j.pax.exam.spi.reactors.ReactorManager)
> >> >>  at
> >> org.ops4j.pax.exam.junit.impl.ProbeRunner.(ProbeRunner.java:78)
> >> >>
> >> >>
> >> >> On Fri, Oct 16, 2015 at 3:46 PM, Benson Margulies <[hidden email]
> >> >
> >> >> wrote:
> >> >>
> >> >>> Step 1: here's the backtrace of the InvocationTargetException. It's
> >> >>> caused by an IllegalArgumentException, which I will break on next.
> >> >>>
> >> >>> That is in turn, as you supposed, caused by the use of the file:
> >> >>>
> >> >>>
> >> >>>
> >>
> jar:file:/Users/benson/x/rosapi1.5/itests/tests/target/rosapi-itests-tests.jar!/META-INF/maven/dependencies.properties
> >>
> >> >>>
> >> >>> being non-hierarchical.
> >> >>>
> >> >>> So, the underlying issue is a bug in pax-exam. However, I still
> wonder
> >> >>> what you think about the fact that failsafe did not provide any
> >> >>> backtrace.
> >> >>>
> >> >>>
> >> >>>
> >> >>> "main@1" prio=5 tid=0x1 nid=NA runnable
> >> >>>   java.lang.Thread.State: RUNNABLE
> >> >>>  at
> >> >>>
> >>
> sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> >>
> >> >>>  at
> >> >>>
> >>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> >>
> >> >>>  at
> >> >>>
> >>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >>
> >> >>>  at java.lang.reflect.Method.invoke(Method.java:497)
> >> >>>  at
> >> >>>
> >>
> org.ops4j.pax.exam.spi.reactors.ReactorManager.addConfigurationsToReactor(ReactorManager.java:239)
> >>
> >> >>>  at
> >> >>>
> >>
> org.ops4j.pax.exam.spi.reactors.ReactorManager.prepareReactor(ReactorManager.java:184)
> >>
> >> >>>  - locked <0x411> (a org.ops4j.pax.exam.spi.reactors.ReactorManager)
> >> >>>  at
> >> org.ops4j.pax.exam.junit.impl.ProbeRunner.(ProbeRunner.java:78)
> >> >>>  at org.ops4j.pax.exam.junit.PaxExam.createDelegate(PaxExam.java:82)
> >> >>>  at org.ops4j.pax.exam.junit.PaxExam.(PaxExam.java:73)
> >> >>>  at
> >> >>>
> >>
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(NativeConstructorAccessorImpl.java:-1)
> >>
> >> >>>  at
> >> >>>
> >>
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> >>
> >> >>>  at
> >> >>>
> >>
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> >>
> >> >>>  at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
> >> >>>  at
> >> >>>
> >>
> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
> >>
> >> >>>  at
> >> >>>
> >>
> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
> >>
> >> >>>  at
> >> >>>
> >>
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
> >>
> >> >>>  at
> >> >>>
> >>
> org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26)
> >>
> >> >>>  at org.junit.runner.Computer.getRunner(Computer.java:40)
> >> >>>  at org.junit.runner.Computer$1.runnerForClass(Computer.java:31)
> >> >>>  at
> >> >>>
> >>
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
> >>
> >> >>>  at
> >> org.junit.runners.model.RunnerBuilder.runners(RunnerBuilder.java:101)
> >> >>>  at
> >> org.junit.runners.model.RunnerBuilder.runners(RunnerBuilder.java:87)
> >> >>>  at org.junit.runners.Suite.(Suite.java:81)
> >> >>>  at org.junit.runner.Computer.getSuite(Computer.java:28)
> >> >>>  at org.junit.runner.Request.classes(Request.java:75)
> >> >>>  at 

Re: slow SVN when committing 4,200 files

[Andreas Gudian]

Am Donnerstag, 15. Oktober 2015 schrieb Michael Osipov :

> Am 2015-10-15 um 02:26 schrieb Tibor Digana:
>
>> Hi,
>>
>> It takes 4 to 5 hour to complete the commit of surefire site on SVN.
>> The site is about 4,200 files and 820 folders.
>>
>> I am doing it on people.apache.org machine; otherwise Maven scm-publish
>> would fail on my localhost.
>>
>
> Are you certain that homes on p.a.o are nto NFS-mounted? Subversion over
> NFS is horribly slow. I have such a problem at work too.
>
> Michael



What Tibor means is 4-5 hrs when doing that at home from Europe. On p.a.o,
it's a matter if one or two minutes.

Andreas


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

Re: MNG-5858 - Question

[Andreas Gudian]

Good idea!

Funny enough, I've seen multi-module projects that wouldn't work with this
- they have an aggregator pom on the top-level, with:
 componentA/common
 componentA/server
 componentB/common
..
So they skip a level of aggregator poms (in the componentX-directories).

I'd consider that an edge case, though. The implications that the current
approach shows in the examples of the Jira issue seem to be worse.





2015-10-12 20:16 GMT+02:00 Karl Heinz Marbaise :

> Hi,
>
> based on the changes we have made to identify the folder where ".mvn" is
> located i would suggest to enhance the check with checking the pom.xml file
> as well...So i would suggest to enhance the find_maven_basedir() function
> like the following:
>
>local basedir="$(pwd)"
>local wdir="$(pwd)"
>while [ "$wdir" != '/' ] ; do
> -if [ -d "$wdir"/.mvn ] ; then
> +if [ -d "$wdir"/.mvn ] && [ -e "$wdir"/pom.xml ] ; then
>basedir=$wdir
>break
>  fi
>
> WDYT ?
>
> See also my comments:
> [1]:
> https://issues.apache.org/jira/browse/MNG-5858?focusedCommentId=14744204=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14744204
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Retire Maven Eclipse Plugin / Donation to Mojohaus

[Andreas Gudian]

I was the last one doing a release there, primarily fixing some issues that
blocked it from being much of use for Java 8 projects that share the
.project / .classpath files in SCM. I still stand by the reasoning that I
had the last time, of why there is still the need for it - despite the
great lengths that m2e has come.

But I can totally welcome the idea to donate it to Mojohaus, where it
whould be more open to changes by users who want to chip in. Because let's
face it, I didn't even get to fix the formality issues that Karl-Heinz
found during the vote of that last release... :-/

So, +1 on retring and donating it.

Btw, are there any changes after the last release that require an
additional release now?


2015-10-06 22:54 GMT+02:00 Michael Osipov :

> Am 2015-10-04 um 11:18 schrieb Robert Scholte:
>
>> Hi,
>>
>> during the latest upgrade of the plugin-parent I faced several issues
>> with the maven-eclipse-plugin.
>> It will take quite some time to fix these issues, but is it worth
>> maintaining it here?
>> Nowadays the Maven support for Eclipse is good and stable.
>> The maven-eclipse-plugin has a lot of integration tests which should be
>> rewritten, because it always launches a new Maven fork and it takes ages
>> to complete. This simply blocks good continuous integration of the
>> plugins.
>> I know there are still some projects with can't use the Maven
>> Integration of Eclipse and depend on this plugin, so the sources need to
>> stay available for users so the can extend it for their own usage.
>>
>> I therefor propose that we retire maven-eclipse-plugin for the Apache
>> Maven project and donate it to the Mojohaus project
>>
>> If this vote is successful I will make one final release of the plugin,
>> making
>> it clear on the plugin site that it has been retired. After that the
>> source code
>> will be moved into the "retired" area in Subversion.
>>
>> The process for retiring a plugin is described here:
>> http://maven.apache.org/developers/retirement-plan-plugins.html
>>
>> The vote is open for 72 hours.
>>
>>
> [X] +1 Yes, it's about time
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Surefire Plugin version 2.19

[Andreas Gudian]

What a release! 50 issues solved? Tibor, you're the man! Kudos for all the
work you've put into this one (again).

I've just built it from the source including all integration tests (JDK 7
only, sorry). In just 41 minutes, the build showed full success. I've
executed the test that Karl-Heinz wrote about again with JDK 6, but it
worked for me (on Windows).

So here's my +1!

Thanks a lot, Tibor!



2015-10-06 22:19 GMT+02:00 Tibor Digana :

> Hi Robert, we trigger profile -Pmaven-2.2.1 setting maven.home in
> maven-failsafe-plugin.
>
> On Tue, Oct 6, 2015 at 6:53 PM, Robert Scholte 
> wrote:
>
> > when testing for 2.2.1 it means that the Maven runtime must be 2.2.1, not
> > the buildtime.
> >
> > In such cases please use
> > mvn verify -Prun-its -Dinvoker.mavenHome=/path/to/apache-maven-2.2.1
> >
> > in this case you shouldn't need the 'install' which might be required for
> > M2.2.1
> >
> > thanks,
> > Robert
> >
> > ps. yes, I should work on toolchain support for this :) Budapest made me
> > remind that
> >
> > Op Tue, 06 Oct 2015 12:10:07 +0200 schreef Karl Heinz Marbaise <
> > khmarba...@gmx.de>:
> >
> >
> > Hi,
> >>
> >> First building with Maven 2.2.1 is not possible...I don't really care
> >> but the pom says 2.2.1 minimum...(just for the record)...
> >>
> >> I have tested via:
> >>
> >> mvn -Prun-its clean verify
> >>
> >> with Maven 3.0.5 (JDK 6), unfortunately i have found an issue in the
> >> integration test which has failedI have attached the failing
> >> integration-test-result output
> >>
> >> This is my environment:
> >> Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da;
> >> 2013-02-19 14:51:28+0100)
> >> Maven home: /usr/share/maven
> >> Java version: 1.6.0_65, vendor: Apple Inc.
> >> Java home:
> >> /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
> >> Default locale: en_US, platform encoding: MacRoman
> >> OS name: "mac os x", version: "10.8.5", arch: "x86_64", family: "mac"
> >>
> >> Kind regards
> >> Karl Heinz Marbaise
> >>
> >> On 10/6/15 4:39 AM, Tibor Digana wrote:
> >>
> >>> Hi,
> >>>
> >>> We solved 50 issues:
> >>>
> >>>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12331679
> >>>
> >>> There are still a couple of issues left in JIRA:
> >>>
> >>>
> https://issues.apache.org/jira/i#issues/?jql=project+%3D+SUREFIRE+AND+status+%3D+Open+ORDER+BY+priority+DESC
> >>>
> >>> Staging repo:
> >>> https://repository.apache.org/content/repositories/maven-1212
> >>>
> >>>
> https://repository.apache.org/service/local/repositories/maven-1212/content/org/apache/maven/surefire/surefire/2.19/surefire-2.19-source-release.zip
> >>>
> >>> Source release checksum(s):
> >>> surefire-2.19-source-release.zip sha1:
> >>> 55b5b8d88f31be56347b7c6c16999bfde0d39d00
> >>>
> >>> Staging site:
> >>> http://maven.apache.org/surefire-archives/surefire-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
> >
> >
>
>
> --
> Cheers
> Tibor
>

Re: User Community was (Re: number of bugs in maven-release-plugin)

[Andreas Gudian]

2015-06-27 14:40 GMT+02:00 robert.patr...@oracle.com 
robert.patr...@oracle.com:


 The second time, I tried to interact around someone else's problem with
 mvnDebug.cmd.  No one ever responded.


That's not really true - people did respond, it's just that no one stood up
and put your suggestion into committable code.

As with many projects that have such a long history and a large number of
users, it is sometimes difficult to be heard. Look at Eclipse, Hibernate
ORM, Glassfish or the JDK itself. If you want something to be done, you
have to make sure that you make it as easy as possible for the committers
to review and apply the patch. And maybe make yourself heard if still no
one reacted... We all do things here in our free time for fun and sometimes
other stuff is more fun at a given time... ;-)

Anyway, someone else had opened a PR at github for that mvnDebug issue and
Jason had already created a corresponding Jira ticket for it... But nothing
really happened, yet.
You bringing that up now made me take a look and I'll fix it, basically the
way you suggested it, as it fit's what's done in the .cmd script.

So thanks for the heads-up!

Andreas

Re: issues.apache.org problems.

[Andreas Gudian]

Hi Milos,

Try your asf username (without @apache.org) and the corresponding password.
That should get you in.

Hth,
Andreas

Am Mittwoch, 17. Juni 2015 schrieb Milos Kleint :

 Hey,

 this is the first time round I'm trying to edit a MNG issue after migration
  from codehaus and while my username exists (mkleint) on issues.apache.org
 ,
 it doesn't send my password reset emails and when I query all my emails (
 mkle...@apache.org javascript:;, @codehaus.org, @gmail.com), JIRA
 claims none of these
 are associated with any account. That's why I'm likely not getting the
 emails.

 Anyone had same problems? Do I really need to create a temporary user
 account to file a problem with my current username?

 Thx.

 Milos

Re: Mojo API to add target/generated-sources/DIR to eclipse's source folder

[Andreas Gudian]

Hi,

You can check the build-helper-maven-plugin, which has a tiny goal to add a
source directory to the project:
https://github.com/mojohaus/build-helper-maven-plugin/blob/master/src/main/java/org/codehaus/mojo/buildhelper/AddSourceMojo.java

The maven-eclipse-plugin picks up all source directories listed in the
model of the build.

Hope that helps,
Andreas

Am Montag, 8. Juni 2015 schrieb Behrooz Nobakht :

 Hi,

 I am trying to follow what `maven-plugin-plugin` Mojo does when generating
 HelpMojo.java.
 It also updates eclipse's .classpath some way (?) that I can see the
 `target/generated-sources/plugin`
 as a source folder in my IDE.

 Similarly, this is also what maven-jaxb2-plugin does when generating
 sources files from a schema.

 I'm a bit clueless at this moment how to achieve the same for a custom
 plugin I'm developing.
 Any specific documentation, hints, or example sources I can look into for
 this?

 Thanks in advance,
 Behrooz

Re: Full migration to Git

[Andreas Gudian]

How about running the git-svn import on people.a.o? Would we be allowed to
do that (in terms of load/storage)? Svn-operations there are blazing fast
in comparison to the remote https access. Or should we ask infra for some
access to a server in the vicinity of one of the svn-mirrors?


Am Montag, 1. Juni 2015 schrieb Fred Cooke :

 Yep, that's getting pretty deep! If the clone(s where's the s?) has
 been done poorly (monolithically or otherwise brokenly) then the only
 sensible option is to do it again. The right approach is the slow one, per
 slice, otherwise the tags don't make sense. Trying to do this after the
 fact from a monolithic clone sounds hideously painful.

 On Tue, Jun 2, 2015 at 5:13 AM, Kristian Rosenvold 
 kristian.rosenv...@gmail.com javascript:; wrote:

  Re-running the clone from a backup of asf svn is time consuming but might
  be the way to go, because we could probably get the correct layout in one
  go. (But it's dooog slow and will be even worse multiplied by X)
 
  Alternately one could probably get around the strange layout of the
 current
  git-svn clone by doing some hardcore conditional filter-branching to
  rewrite the root directory of only those commits that are not already at
  the root. This is not your average git-svn rewrite and we're *way* beyond
  powerpoint presentations here.
 
  But bottom line, it's just a dirty job that someone has to do :)
 
   Kristian
 
  2015-06-01 17:12 GMT+02:00 Jason van Zyl ja...@takari.io javascript:;
 :
 
   I wasn’t but that’s good. If you wanted to run the clone again is that
 an
   issue? We just figure out the best way and then do it to all of them.
  
On Jun 1, 2015, at 10:48 AM, Kristian Rosenvold 
   kristian.rosenv...@gmail.com javascript:; wrote:
   
You're probably aware the I have done a substantial number of git
migrations. Hopefully someone out there has a simple way to fix this
problem;
   
If I was to do this I'd probably re-run the initial git svn clone
 from
   the
SVN repository...
   
Kristian
   
   
2015-06-01 16:40 GMT+02:00 Jason van Zyl ja...@takari.io
 javascript:;:
   
Ok, let’s look around I’m sure folks have gone from monorepo setups
 to
individual project setups. I doubt we’re the first to attempt this.
   
On Jun 1, 2015, at 10:28 AM, Kristian Rosenvold 
kristian.rosenv...@gmail.com javascript:; wrote:
   
git clone https://github.com/apache/maven-plugins.git
cd maven-plugins
ls -al
git checkout maven-shade-plugin-2.2
ls -al
   
The root gets rewritten on the tags. Not nice. Mojo did not have
 this
issue.
   
Kristian
   
   
2015-06-01 16:27 GMT+02:00 Kristian Rosenvold 
kristian.rosenv...@gmail.com javascript:;
:
   
No, the maven-plugins repo is a slightly different beast when
  compared
to
mojo. And since we're splitting anyway, we're talking about 30-40
different
repos, so there is really no point in your suggested route (the
 git
clones
already exist although I am unsure if they can be used).
   
So I think it's a good idea for everything but maven-shared and
maven-plugins. The plan you have outlined does not make sense for
these. We
need that script that creates plausible split repos first.
   
To be verify specific, there's something weird about the *tags* in
  the
plugins repo and how this has been translated to git in the
 current
   git
svn
close. Mojo did not have this problem.
   
Try this:
   
git clone https://github.com/apache/maven-plugins.git
   
Kristian
   
   
   
   
   
2015-06-01 16:16 GMT+02:00 Jason van Zyl ja...@takari.io
 javascript:;:
   
I think we have that PoC with Mojo moving to Github no? Baptiste,
  was
this an issue?
   
I think it will just be easier to do it all from Git. I don’t
 think
we’re
going to lose anything in the translation directly from SVN to
 Git
with the
maturity of the tools.
   
But do you agree with the general plan. Get it all to Git and
 then
we’ll
collectively figure it out. I really don’t see it being an issue
   given
how
much Git knowledge we have between us all and the Mojo migration
 to
Github.
   
On Jun 1, 2015, at 8:13 AM, Kristian Rosenvold 
kristian.rosenv...@gmail.com javascript:; wrote:
   
The real problem here is maven-shared and maven-plugins, which
  need
   to
be
rewritten quite heavily.
   
The existing git mirrors may be used as a starting point for
   filtering
operations, but I suspect retaining history is going to be
 quite a
   lot
of
work when splitting the repos.
   
We should not defer this operation like you suggest, we really
  need
   a
proof
of concept filtering first.
   
Kristian
   
   
2015-06-01 14:06 GMT+02:00 Jason van Zyl ja...@takari.io
 javascript:;:
   
Maybe it best then to have everything mirrored to Git, if there
  are
any
 

Re: [VOTE] Release Apache Maven Eclipse Plugin version 2.10

[Andreas Gudian]

Here's my own +1.

2015-05-26 23:10 GMT+02:00 Hervé BOUTEMY herve.bout...@free.fr:

 +1

 Regards,

 Hervé

 Le dimanche 24 mai 2015 22:04:52 Andreas Gudian a écrit :
  Hi,
 
  this will be the last Maven 2 compatible release of this plugin.
 
  We solved 9 issues:
 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317423ve
  rsion=12330751
 
  There are still a couple of issues left in JIRA:
 
 https://issues.apache.org/jira/issues/?jql=project%20%3D%20MECLIPSE%20AND%20
  status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
 
  Staging repo:
  https://repository.apache.org/content/repositories/maven-1187/
 
 https://repository.apache.org/content/repositories/maven-1187/org/apache/mav
 
 en/plugins/maven-eclipse-plugin/2.10/maven-eclipse-plugin-2.10-source-releas
  e.zip
 
  Source release checksum(s):
  maven-eclipse-plugin-2.10-source-release.zip sha1:
  691ad83cb0b731c8c0ab5a6c5f105a25cd34f73b
 
  Staging site:
  http://maven.apache.org/plugins-archives/maven-eclipse-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

[RESULT] [VOTE] Release Apache Maven Eclipse Plugin version 2.10

[Andreas Gudian]

Hi,

The vote has passed with the following result:

+1 (binding): Karl Heinz Marbaise, Jason van Zyl, Hervé Boutemy
+1 (non binding): Andreas Gudian

Thank you guys for the votes!

I will promote the artifacts to the central repo.


2015-05-27 21:44 GMT+02:00 Andreas Gudian andreas.gud...@gmail.com:

 Here's my own +1.

 2015-05-26 23:10 GMT+02:00 Hervé BOUTEMY herve.bout...@free.fr:

 +1

 Regards,

 Hervé

 Le dimanche 24 mai 2015 22:04:52 Andreas Gudian a écrit :
  Hi,
 
  this will be the last Maven 2 compatible release of this plugin.
 
  We solved 9 issues:
 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317423ve
  rsion=12330751
 
  There are still a couple of issues left in JIRA:
 
 https://issues.apache.org/jira/issues/?jql=project%20%3D%20MECLIPSE%20AND%20
  status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
 
  Staging repo:
  https://repository.apache.org/content/repositories/maven-1187/
 
 https://repository.apache.org/content/repositories/maven-1187/org/apache/mav
 
 en/plugins/maven-eclipse-plugin/2.10/maven-eclipse-plugin-2.10-source-releas
  e.zip
 
  Source release checksum(s):
  maven-eclipse-plugin-2.10-source-release.zip sha1:
  691ad83cb0b731c8c0ab5a6c5f105a25cd34f73b
 
  Staging site:
  http://maven.apache.org/plugins-archives/maven-eclipse-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

[ANN] Apache Maven Eclipse Plugin 2.10 Released

[Andreas Gudian]

The Apache Maven team is pleased to announce the release of the Apache
Maven Eclipse Plugin, version 2.10

This plugin is used to generate Eclipse IDE files (*.classpath, *.project,
*.wtpmodules and the .settings folder) for use with a project - if the M2E
Eclipse-Plugin does not fit you.

This release is the last one supporting Maven 2.

http://maven.apache.org/plugins/maven-eclipse-plugin/

You should specify the version in your project's plugin configuration:

plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-eclipse-plugin/artifactId
  version2.10/version
/plugin

Release Notes - Maven Eclipse Plugin - Version 2.10

** Bug
* [MECLIPSE-731] - eclipse:clean not deleting ./settings folder that it
creates
* [MECLIPSE-738] - NullPointerException in LinkedResource if
locationURI is present in .project

** Improvement
* [MECLIPSE-697] - Delete deprecated code
* [MECLIPSE-721] - Improve documentation to explain why Eclipse
sometimes does not import projects with correct project names.
* [MECLIPSE-754] - UPdate plexus-archiver to 2.9,plexus-utils to 3.0.18
and maven-archiver to 2.5
* [MECLIPSE-756] - Fix RAT Report
* [MECLIPSE-757] - Add proper classpath entry names for Java 7 / 8
* [MECLIPSE-758] - Use mojo annotations

** New Feature
* [MECLIPSE-759] - Add goal to resolve dependencies in .classpath files
of a workspace


Enjoy,

-The Apache Maven team

Re: [VOTE] Release Apache Maven Eclipse Plugin version 2.10

[Andreas Gudian]

Good catch, Karl!

I just checked the previous release (2.9) and it shows a similar problem.
Apperently the .metadata directories don't end up in the sources-zip file.

I've created a JIRA issue for this problem:
https://issues.apache.org/jira/browse/MECLIPSE-760

I'd say it would be sufficient to fix this for the next version. WDYT?



2015-05-25 13:43 GMT+02:00 Karl Heinz Marbaise khmarba...@gmx.de:

 Hi,

 check SHASUM Ok.

 Unfortunately the release package does not work

 Checked with Maven 2.2.1, 3.0.5 and failed with the same...

 Results :

 Tests in error:
   ReadWorkspaceLocationsTest.setUp:57 » FileNotFound
 /Users/kama/Downloads/maven...
   ReadWorkspaceLocationsTest.setUp:57 » FileNotFound
 /Users/kama/Downloads/maven...
   ReadWorkspaceLocationsTest.setUp:57 » FileNotFound
 /Users/kama/Downloads/maven...
   ReadWorkspaceLocationsTest.setUp:57 » FileNotFound
 /Users/kama/Downloads/maven...
   ReadWorkspaceLocationsTest.setUp:57 » FileNotFound
 /Users/kama/Downloads/maven...

 Tests run: 50, Failures: 0, Errors: 5, Skipped: 3


 It looks like the contents which is expected seemed to be not part of the
 release package...


 If i start the tests in the
 https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-eclipse-plugin
 directory the above tests will run successfully...and don't produce
 errors...




 On 5/24/15 10:04 PM, Andreas Gudian wrote:

 Hi,

 this will be the last Maven 2 compatible release of this plugin.

 We solved 9 issues:

 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317423version=12330751

 There are still a couple of issues left in JIRA:

 https://issues.apache.org/jira/issues/?jql=project%20%3D%20MECLIPSE%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC

 Staging repo:
 https://repository.apache.org/content/repositories/maven-1187/

 https://repository.apache.org/content/repositories/maven-1187/org/apache/maven/plugins/maven-eclipse-plugin/2.10/maven-eclipse-plugin-2.10-source-release.zip

 Source release checksum(s):
 maven-eclipse-plugin-2.10-source-release.zip sha1:
 691ad83cb0b731c8c0ab5a6c5f105a25cd34f73b

 Staging site:
 http://maven.apache.org/plugins-archives/maven-eclipse-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

[VOTE] Release Apache Maven Eclipse Plugin version 2.10

[Andreas Gudian]

Hi,

this will be the last Maven 2 compatible release of this plugin.

We solved 9 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317423version=12330751

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MECLIPSE%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-1187/
https://repository.apache.org/content/repositories/maven-1187/org/apache/maven/plugins/maven-eclipse-plugin/2.10/maven-eclipse-plugin-2.10-source-release.zip

Source release checksum(s):
maven-eclipse-plugin-2.10-source-release.zip sha1:
691ad83cb0b731c8c0ab5a6c5f105a25cd34f73b

Staging site:
http://maven.apache.org/plugins-archives/maven-eclipse-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

Re: [VOTE] Add Manfred Moser as committer

[Andreas Gudian]

+1, I also always like what I'm reading from Manfred.

(don't these votes usually take place in private@?)

2015-05-13 13:12 GMT+02:00 Jason van Zyl ja...@takari.io:

 +1

 On May 13, 2015, at 2:55 AM, Hervé BOUTEMY herve.bout...@free.fr wrote:

  Hi,
 
  I'd like to introduce Manfred Moser as committer for the Apache  Maven
  project.
 
  He's working on Android Maven plugin for years, has great discussions
 both on
  users and dev MLs, has a great attitude.
  And he's just told he wants to improve the site and work on Maven:
 having him
  make pull requests is just a waste of energy for both Manfred and
 whoever will
  accept the PRs: I'm confident that he'll know when to do changes by
 himself and
  when some discussion is necessary before doing the job.
 
  Vote open for 72H
 
  [+1]
  [0]
  [-1]
 
  And here's my +1.
 
  Hervé
 
  -
  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: [VOTE] Maven Site upgrade to maven-fluido-skin 1.4

[Andreas Gudian]

Nice! +1


Am Donnerstag, 7. Mai 2015 schrieb Stephen Connolly :

 +1

 On 7 May 2015 at 18:59, Karl Heinz Marbaise khmarba...@gmx.de
 javascript:; wrote:

  Hi,
 
  i would like to update our main page http://maven.apache.org/ to the new
  Maven Fluido Skin 1.4 including new logo which will look like this:
 
  http://khmarbaise.github.io/maven-site/fluido/index.html
 
  Vote open for 72 hours.
 
  [ ] +1
  [ ] +0
  [ ] -1
 
  Kind regards
  Karl Heinz Marbaise
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:;
  For additional commands, e-mail: dev-h...@maven.apache.org
 javascript:;
 
 

Supported Toolchain JDK version in Surefire / was: surefire refactoring done

[Andreas Gudian]

Hi Tibor,

wow, that's a lot of work you put in there! Great!

As you also changed stuff in surefire-booter and I always wondered, I'm
cc-ing dev@ with this question:

Do we have any documentation on which JDKs we officially support to be used
in a toolchain configuration?

For quite a while now, surefire-booter and dependent modules were compiled
with target=1.5 (AFAIK). So surefire would support executing tests with
toolchain-support only if the toolchained JDK is at least 1.5. I think that
is ok, but we should keep an eye on that when going towards 1.7 for most of
the code in the future.

Do we have other plugins with this kind of dependency? I would guess that
the compiler plugin doesn't care, as it doesn't have any of its own code
executed in the toolchain JVM.

Andreas



2015-05-06 18:42 GMT+02:00 Tibor Digana tibor.dig...@googlemail.com:

 Finished a big refactoring in surefire.
 Basically the previous code looked like Java 1.4 - no generics, no
 for-each, no var-args.
 Now it's more type safe code.

 These are activities in SUREFIRE-1155:

 Java 5 for-each instead of Iterator
 optimized loops
 optimized branching
 some conditions in if-else could not happen - therefore was simplified
 improved loops variables
 optimized use of this pointer
 using Java Generics instead of java.util.Properties
 removed unnecessary cast
 boolean instead of Boolean
 isEmpty() instead of Collection#size() == 0
 removed unused code
 resolved warnings shown by IntelliJ IDEA
 use Arrays.asList( o ) to Collections.singletonList( o ) with single object
 @SuppressWarnings where code generics cannot be improved
 substitute Java 4 StringBuilder with String concatination for better code
 clarity. Java Compilet 5 will compile to use StringBuilder in bytecode.
 using ternary operator
 added remark @todo use try-with-resources JDK7, search in all code
 get rid of Class[] in Reflection and use var args
 caught InvocationTargetException and use exception cause in rethrown
 RuntimeException

 Cheers

Re: Release Plan maven-shared-utils-0.8

[Andreas Gudian]

Done. Created issue MSHARED-415 and set it to resolved.

@Tibor: if there isn't anything else in the release anyway, you can also
combine both into one release-process/vote.

2015-05-04 18:47 GMT+02:00 Karl Heinz Marbaise khmarba...@gmx.de:

 Hi,


 On 5/3/15 11:13 PM, Tibor Digana wrote:

 Currently surefire is dependent on snapshot version:
 maven-shared-utils-0.8-SNAPSHOT.
 When do we plane the release of 0.8 ?

 Cheers
 Tibor


 I have taken a look into jira for that and first i didn't find any related
 issue which is fixed related to maven-shared-utils 0.8 ...

 So gone into the SVN history and found some parts which have fixed but not
 updated on JIRA site...

 For example i have found the following:

 r1656924 | agudian | 2015-02-03 22:17:36 +0100 (Tue, 03 Feb 2015) | 1 line
 Changed paths:
M
 /maven/shared/trunk/maven-shared-utils/src/main/java/org/apache/maven/shared/utils/cli/CommandLineUtils.java
M
 /maven/shared/trunk/maven-shared-utils/src/main/java/org/apache/maven/shared/utils/cli/StreamPumper.java

 [SUREFIRE-1137] Allow passing a Charset to be used by the StreamPumper to
 read from the input streams (i.e. the output streams of the forked process)

 which unfortunately didn't has a related issue in MSHARED ?...and based on
 JIRA i can't make it part of the release via fixed in version

 It would be nice if someone can create an appropriate MSHARED issue make
 it related to version 0.8 of shared utils and update the log message
 accordingly...

 Apart from that there is no reason not to start a release VOTE for it ?

 Kind regards
 Karl Heinz Marbaise

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

Re: Do we want to go for gitpubsub?

[Andreas Gudian]

5 gig? wow...

I think a whole lot of of the pages is garbage that no one ever really
reads. No, not the docs itself ;-) - I'm talking about the many many source
xref and javadoc pages (both main and test code) And every single of
those pages is updated on every release because they all contain the
version number or a timestamp somewhere.

If we could stop adding source xrefs and javadocs to the site reports, that
would already help a lot. I haven't read any javadoc pages in the browser
for years... and when I look for source code, I use the quick search on
github or browse through the web-cvs. When I actually use a library, then
the sources are downloaded automatically anyway in the IDE - together with
the Javadocs if necessary.

Or does anyone see that there's still need for those pages? Do we maybe
have some statistics on visits to those pages?

2015-05-03 10:52 GMT+02:00 Hervé BOUTEMY herve.bout...@free.fr:

 Le vendredi 1 mai 2015 15:14:05 Andreas Gudian a écrit :
  Anyone who has ever done a release of a large plugin like surefire from a
  european location knows what a pain it is to svn-commit a couple of
  thousand files. It takes hours, but only if you're lucky and the process
 is
  not interrupted by the server.
  I had to dance around that by zipping up the locally generated site, scp
 it
  to people.a.o and commit it from there. Every time I did that, I thought
  about how cool it would be to just push one git-commit - it would be done
  in seconds.
 +1

 
  So I'd be all in favour of that. Depends on how that would be structured,
  though. Everything in one big repository? Or could it be sliced into
 parts
  of the different areas of the sites, like main maven pages, the
  single-module plugins, and dedicated repositories for the bigger plugins?
 you're pointing to the key good question

 There was a discussion last month on infrastructure mailing list about
 eventually deprecating CMS: that is the starting point of my work on
 .htaccess
 and /content vs /components for merging main site content with components
 documentations (both latest and versioned in *-archives/)

 And from the discussion I had with infra, having multiple SCM entries (one
 for
 the main site and one for each and every component) would cause issues for
 infra, since it means infra would have to configure a lot of *pubsub
 listeners:
 it's not part of infra plan to have so much listeners, and being in the
 loop
 every time we add one component.
 Notice I don't see how versioned content (in *-archives) could be done: but
 that's another issue, perhaps we could find a strategy.


 Then if we switched to git, this would be one big git repo with absolutely
 everything in it: I counted, there are 475 000 files, for 5 GB. Not sure
 we'll
 have the performance improvement we expected from git...


 Notice that we have curently 2 html repos: /content and /components
 We could migrate /content, ie the main site content, to gitpubsub
 But I think we would loose the CMS, since CMS doesn't support git, AFAIK
 Not that I'm a big CMS fan, but what I like is the main site automatic
 build
 (not done from personal desktop but from buildbot [1] ), which is part of
 the
 CMS workflow


 Then I fear the dream we all have to improve component documentation
 publication performance won't come from this


 But during the discussion with infra, this huge performance issue was
 clearly
 shared and there was an idea expressed by Joe Schaefer:
 Supporting tar/zip files with svnpubsub is straightforward with the
 built-in
 hook support.  Someone would just need to write a custom hook that expands
 zip
 files for websites (a list of where to find these files needs to be
 supplied or
 conventionalized).

 The way I'd envision this working is that,

 1) projects add their compressed archives listings to a specific file
 similar to
 extpaths for the cms.  Each entry would be a target path and a source
 tarball.

 2) when a project commits a new entry with a new tarball, the hook will
 look
 at each entry in the tarball file and compare timestamps against what's on
 disk.  If the directory is older than the tarball it nukes the directory
 and
 reexpands and resets the timestamp on the base of the tree.

 This of course has nothing to do with the cms.  Everything needed is
 already
 possible with svnpubsub and perhaps gitpubsub as well.


 If somebody is interested to work on this, I can give pointers and work
 with
 him: at the moment, i felt too alone on the topic to have energy to do
 anything...

 Regards,

 Hervé


 [1] http://ci.apache.org/builders/maven-site-staging

 
  2015-04-30 21:16 GMT+02:00 Jason van Zyl ja...@takari.io:
   My read is this work much like Github pages works. You have a
 repository
   with your source and the rendered pages go into a branch. But nothing
   stops
   you from having the source in one repo and just pushing the generated
   content to another repo. This is currently how we do the M2Eclipse
 site.
   We

Re: Maven Eclipse Plugin Final Release ?

[Andreas Gudian]

Hi Karl,

I still have half of an issue to fix before the release - I was just
immensly lazy regarding my maven activities the last months.

So it's good you bring it up, Karl! I'll see that I get my ass up over this
weekend.

I also promised to add some lines in the relation of this plugin vs m2e on
the site - I'll do that as well. I can roll the release once I'm done.

Again, thanks for the wakeup call,
Andreas


Am Freitag, 1. Mai 2015 schrieb Martijn Dashorst :

 Would be cool if the site was updated wit the new location of jira
 issues as well.

 Martijn

 On Thu, Apr 30, 2015 at 10:25 PM, Karl Heinz Marbaise khmarba...@gmx.de
 javascript:; wrote:
  Hi,
 
  i would like to know if there are any objections to make a final release
 of
  the maven-eclipse-plugin ?
 
  The reason is simply because it is the last plugin on the list which
 misses
  the Maven 2.2.1 minimum
 
  This could make our release map complete here...
 
  as you can see here:
 
 
 https://builds.apache.org/job/dist-tool-plugin/site/dist-tool-prerequisites.html
 
 
  If there will be no objections until 8. May 2015 i will start a release
 on
  weekend afterwards...
 
  Kind regards
  Karl Heinz Marbaise
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:;
  For additional commands, e-mail: dev-h...@maven.apache.org
 javascript:;
 



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

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

Re: Do we want to go for gitpubsub?

[Andreas Gudian]

Anyone who has ever done a release of a large plugin like surefire from a
european location knows what a pain it is to svn-commit a couple of
thousand files. It takes hours, but only if you're lucky and the process is
not interrupted by the server.
I had to dance around that by zipping up the locally generated site, scp it
to people.a.o and commit it from there. Every time I did that, I thought
about how cool it would be to just push one git-commit - it would be done
in seconds.

So I'd be all in favour of that. Depends on how that would be structured,
though. Everything in one big repository? Or could it be sliced into parts
of the different areas of the sites, like main maven pages, the
single-module plugins, and dedicated repositories for the bigger plugins?



2015-04-30 21:16 GMT+02:00 Jason van Zyl ja...@takari.io:

 My read is this work much like Github pages works. You have a repository
 with your source and the rendered pages go into a branch. But nothing stops
 you from having the source in one repo and just pushing the generated
 content to another repo. This is currently how we do the M2Eclipse site. We
 have a Jekyll site in one repository, and we have a process that runs
 Jekyll and produces the website which gets pushed. I think if we did the
 same it would be cool because we could have the site on Github where we can
 use Jekyll, let people make pull requests and push it back here for
 official publishing.

 On Apr 30, 2015, at 2:55 PM, Michael Osipov micha...@apache.org wrote:

  Am 2015-04-30 um 00:31 schrieb Stephen Connolly:
  http://bit.ly/1QLwWGS
 
  (Source: https://twitter.com/planetapache/status/593535338074611712)
 
  Wouldn't that imply always to clone a private copy of the entire repo
 with autogerated stuff just to push changes back to the canonical repo?
 
  Sounds like an absolute waste of time and resources to me.
 
  Michael
 
 
  -
  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 language that doesn’t affect the way you think about programming is not
 worth knowing.

  -- Alan Perlis













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

Re: mvnDebug with problems

[Andreas Gudian]

In the windows script, I introduced a new variable for the debug settings -
perhaps we can do the same for the shell scripts.

Am Freitag, 24. April 2015 schrieb Francisco Collao Gárate :

 Yep the behavior is different, in my case I was using a .mavenrc, so
 when I use the mvnDebug add all options for opts and debug BUT.. when
 finally execute mvn bin all that env variables are deleted with this
 peace of code:

 if [ -z $MAVEN_SKIP_RC ] ; then

   if [ -f /etc/mavenrc ] ; then
 . /etc/mavenrc
   fi

   if [ -f $HOME/.mavenrc ] ; then
 . $HOME/.mavenrc
   fi

 fi

 After that moment MAVEN_OPTS are right (debug options + maven_opts),
 when load .mavenrc ( .$HOME/.mavenrc) clank! all env variables are
 deleted!.

 I think the old way to exectute mvnDebug was fine or maybe use new env
 vars for the new one.

 Best Regards

 On Thu, Apr 9, 2015 at 11:59 AM, Robert Patrick
 robert.patr...@oracle.com javascript:; wrote:
  I sent an email this weekend pointing out the difference in behavior of
 mvnDebug between Windows and Linux/Unix.  Whether you consider it a bug or
 not, there is no doubt that the behavior is different.  If you wanted to
 reconcile the differences, I would do something like this:
 
  index 902de4a..0f5427a 100755
  --- a/apache-maven/src/bin/mvn
  +++ b/apache-maven/src/bin/mvn
  @@ -226,6 +226,7 @@ export MAVEN_CMD_LINE_ARGS
 
   exec $JAVACMD \
 $MAVEN_OPTS \
  +  $MAVEN_DEBUG_OPTS \
 -classpath ${M2_HOME}/boot/plexus-classworlds-*.jar \
 -Dclassworlds.conf=${M2_HOME}/bin/m2.conf \
 -Dmaven.home=${M2_HOME}
 -Dmaven.multiModuleProjectDirectory=${MAVEN_PROJEC
 
  diff --git a/apache-maven/src/bin/mvnDebug
 b/apache-maven/src/bin/mvnDebug
  index 73905fd..a1077ce 100755
  --- a/apache-maven/src/bin/mvnDebug
  +++ b/apache-maven/src/bin/mvnDebug
  @@ -38,4 +38,4 @@ MAVEN_DEBUG_OPTS=-Xdebug
 -Xrunjdwp:transport=dt_socket,server
 
 
   echo Preparing to Execute Maven in Debug Mode
 
  -env MAVEN_OPTS=$MAVEN_OPTS $MAVEN_DEBUG_OPTS $(dirname $0)/mvn $@
  +env MAVEN_OPTS=$MAVEN_OPTS MAVEN_DEBUG_OPTS=$MAVEN_DEBUG_OPTS
 $(dirname $0)
 
  --
  Robert Patrick robert.patr...@oracle.com javascript:;
  VP, Oracle Corporation
  7460 Warren Pkwy, Ste. 300  Office: +1.972.963.2872
  Frisco, TX 75034, USA   Mobile: +1.469.556.9450
 
  Professional Oracle WebLogic Server
  by Robert Patrick, Gregory Nyberg, and Philip Aston
  with Josh Bregman and Paul Done
  Book Home Page: http://www.wrox.com/
  Kindle Version: http://www.amazon.com/
 
 
  -Original Message-
  From: Francisco Collao Gárate [mailto:pcoll...@gmail.com javascript:;]
  Sent: Thursday, April 09, 2015 9:38 AM
  To: dev@maven.apache.org javascript:;
  Subject: mvnDebug with problems
 
  Hi,
 
  Based in this discussion over the Karl-Heinz Marbaise, someone had the
 opportunity to review if there is or not a bug with mvnDebug (version
 3.3.1).
 
 
 http://blog.soebes.de/blog/2015/03/17/apache-maven-3-dot-3-1-features/#comment-1947464703
 
  If you need more information about this, I would like to help.
 
  Best Regards
  --
  Francisco Collao Gárate
  LinuxUser #363300
  http://blog.pcollaog.cl
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:;
 For additional commands, e-mail: dev-h...@maven.apache.org javascript:;
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:;
  For additional commands, e-mail: dev-h...@maven.apache.org
 javascript:;
 



 --
 Francisco Collao Gárate
 LinuxUser #363300
 http://blog.pcollaog.cl

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

Re: [IMPORTANT NOTICE] Jira migration from Codehaus to Apache on April 4th

[Andreas Gudian]

Hervé, it looks much better now, as far as issues are concerned: I can
assign issues and edit all parts of them (including title and descrition).
That's great :).

But I still can't manage the versions, e.g. add new ones, mark them
released, or add descriptions to them. As that is part of the stuff that
needs to be done when releasing  something, I think that the Committers
role should have the rights for that as well... Is that possible?


Btw, I think that the work that you, Infra and Codehaus have put in for
this is remarkable - a big thanks from me as well!

2015-04-11 1:38 GMT+02:00 Hervé BOUTEMY herve.bout...@free.fr:

 Hi,

 Dan and Andreas, you're in maven-developers groups = what is expected

 Then if you can't do anything useful, yes, there is some part missing in
 the
 config: we'll need to figure out which one :)

 Currently, the pattern applied to the Maven projects regarding roles is:
 - role Administrators = maven-administrators
 - role Developers = maven-developers
 which seems logical

 looking at Permissions, I see that most permissions are set on PMC and
 Committers roles, but absolutely no permission is set on Developers role: I
 thing it is the problem!

 To test another config on one project before doing it on every other,
 let's try
 on SUREFIRE:
 I just configured role PMC for maven-administrators and role Committers for
 maven-developers

 Can you check what actions this lets you do and if somthing is still
 missing,
 please?

 Regards

 Hervé


 Le vendredi 10 avril 2015 23:34:49 Andreas Gudian a écrit :
  Hi,
 
  I already am in the group maven-developers, but I don't seem to be able
  to do anything meaningfull, like managing versions or assigning issues to
  myself... I checked in SUREFIRE and in MECLIPSE.
 
  Is there some part missing in the config?
 
  Thanks,
  Andreas
 
  2015-04-10 23:23 GMT+02:00 Dan Tran dant...@gmail.com:
   Hi
  
   Please add me as well
  
   Thanks
  
   -D
  
   On Fri, Apr 10, 2015 at 1:59 PM, Hervé BOUTEMY herve.bout...@free.fr
  
   wrote:
I added you to the last request for maven-developers group
   
https://issues.apache.org/jira/browse/INFRA-9422
   
Regards,
   
Hervé
   
Le vendredi 10 avril 2015 22:20:30 Mirko Friedenhagen a écrit :
 Hello,

 now I tried to assign
 https://issues.apache.org/jira/browse/MRELEASE-901 to myself and
 was
 unable to do so. However I was allowed to resolve the issue (and
 could
 close it as well).
 When going to my profile
 (https://issues.apache.org/jira/secure/ViewProfile.jspa) I see
 that I
 am only in the group jira-users and not in any other group (so is
 Robert Scholte btw, but he has assigned issues).

 Regards Mirko
 --
 http://illegalstateexception.blogspot.com/
 https://github.com/mfriedenhagen/ (
 http://osrc.dfm.io/mfriedenhagen)
 https://bitbucket.org/mfriedenhagen/


 On Tue, Apr 7, 2015 at 7:43 AM, Kristian Rosenvold

 kristian.rosenv...@gmail.com wrote:
  The user name mapping seems to be ok, but I seem to be missing
  permissions to do anything sensible at all ?
 
  (krosenvold)
 
  Kristian
 
  2015-04-06 23:58 GMT+02:00 Mirko Friedenhagen 
  
   mfriedenha...@gmail.com
  
  A big thank you from my side as well, I logged in to
  https://issues.apache.org/jira/ and was easily able to see all
 my
  reported issues and am allowed to edit the open ones.
  Regards Mirko
  --
  http://illegalstateexception.blogspot.com/
  https://github.com/mfriedenhagen/ (
 http://osrc.dfm.io/mfriedenhagen
  
   )
  
  https://bitbucket.org/mfriedenhagen/
 
  On Mon, Apr 6, 2015 at 2:29 PM, Jason van Zyl ja...@takari.io
   
wrote:
  The mapping did not work for my user as all issues that were
   
assigned to
   
  jason on the Codehaus side are now mapping to Jason Lane. I
 also
   
can
   
  no longer even log into issues.apache.org  to comment on
  
   INFRA-9389.
  
  My codehaus user is jason, and my Apache user is jvanzyl.
 
  I lined up all my email addresses but only did so 3 hours
 before
  
   the
  
  migration so maybe that is the issue. But I've lost all access
 to
  
   the
  
  Apache JIRA instance all together and all my issues are
 assigned
  to
  someone else completely.
  On Apr 6, 2015, at 6:26 AM, Hervé BOUTEMY 
 herve.bout...@free.fr
   
wrote:
  there were a lot of manual tasks that took hours, really many
  
   hours
  
  (the night was shorter than expected), even more for Mark than
  for
   
me:
  it's great to see that the result is positive = you can
 continue
  
   to
  
  work on the issues
 
  but everything didn't go as expected regarding accounts:
 please
   
report
   
  any
  problem to INFRA-9389 [1] with precise info regarding
 usernames
  at
  Codehaus
  and at ASF
 
  Thank you Ben

Re: [IMPORTANT NOTICE] Jira migration from Codehaus to Apache on April 4th

[Andreas Gudian]

Hi,

I already am in the group maven-developers, but I don't seem to be able
to do anything meaningfull, like managing versions or assigning issues to
myself... I checked in SUREFIRE and in MECLIPSE.

Is there some part missing in the config?

Thanks,
Andreas

2015-04-10 23:23 GMT+02:00 Dan Tran dant...@gmail.com:

 Hi

 Please add me as well

 Thanks

 -D

 On Fri, Apr 10, 2015 at 1:59 PM, Hervé BOUTEMY herve.bout...@free.fr
 wrote:

  I added you to the last request for maven-developers group
 
  https://issues.apache.org/jira/browse/INFRA-9422
 
  Regards,
 
  Hervé
 
  Le vendredi 10 avril 2015 22:20:30 Mirko Friedenhagen a écrit :
   Hello,
  
   now I tried to assign
   https://issues.apache.org/jira/browse/MRELEASE-901 to myself and was
   unable to do so. However I was allowed to resolve the issue (and could
   close it as well).
   When going to my profile
   (https://issues.apache.org/jira/secure/ViewProfile.jspa) I see that I
   am only in the group jira-users and not in any other group (so is
   Robert Scholte btw, but he has assigned issues).
  
   Regards Mirko
   --
   http://illegalstateexception.blogspot.com/
   https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
   https://bitbucket.org/mfriedenhagen/
  
  
   On Tue, Apr 7, 2015 at 7:43 AM, Kristian Rosenvold
  
   kristian.rosenv...@gmail.com wrote:
The user name mapping seems to be ok, but I seem to be missing
permissions to do anything sensible at all ?
   
(krosenvold)
   
Kristian
   
2015-04-06 23:58 GMT+02:00 Mirko Friedenhagen 
 mfriedenha...@gmail.com
  :
A big thank you from my side as well, I logged in to
https://issues.apache.org/jira/ and was easily able to see all my
reported issues and am allowed to edit the open ones.
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen
 )
https://bitbucket.org/mfriedenhagen/
   
On Mon, Apr 6, 2015 at 2:29 PM, Jason van Zyl ja...@takari.io
  wrote:
The mapping did not work for my user as all issues that were
  assigned to
jason on the Codehaus side are now mapping to Jason Lane. I also
  can
no longer even log into issues.apache.org  to comment on
 INFRA-9389.
   
My codehaus user is jason, and my Apache user is jvanzyl.
   
I lined up all my email addresses but only did so 3 hours before
 the
migration so maybe that is the issue. But I've lost all access to
 the
Apache JIRA instance all together and all my issues are assigned to
someone else completely.
On Apr 6, 2015, at 6:26 AM, Hervé BOUTEMY herve.bout...@free.fr
  wrote:
there were a lot of manual tasks that took hours, really many
 hours
(the night was shorter than expected), even more for Mark than for
  me:
it's great to see that the result is positive = you can continue
 to
work on the issues
   
but everything didn't go as expected regarding accounts: please
  report
any
problem to INFRA-9389 [1] with precise info regarding usernames at
Codehaus
and at ASF
   
Thank you Ben for all the Codehaus support, and big big big thank
  you
to Mark at ASF infra for the huge work on import.
   
Regards,
   
Hervé
   
[1] https://issues.apache.org/jira/browse/INFRA-9389
   
Le lundi 6 avril 2015 11:55:01 Robert Scholte a écrit :
I would like to take this chance to give huge kudo's to all
  involved
parties.
   
My first impression is that the migration went very well, since I
  can
continue my work at https://issues.apache.org/jira as I was used
  to.
The preparations already showed that it was more than a simple
  copy.
It was a huge move and not everything could be automated (e.g.
  making
all
60+ Jira projects read-only at Codehaus) but the end result is
  great.
   
Thanks a lot Hervé, ASF Infra and Codehaus Support!
   
   
Op Sat, 04 Apr 2015 23:10:55 +0200 schreef Hervé BOUTEMY
   
herve.bout...@free.fr:
Hi,
   
Codehaus was put read-only during migration, when we started by
  doing
a
dump
of the content.
Import at ASF is not one yet: should be done tomorrow.
   
You just have to way for 24 hours that the migration is done :)
   
Regards,
   
Hervé
   
Le samedi 4 avril 2015 14:03:43 Tibor Digana a écrit :
Hello guys,
   
I am not able to find
  https://issues.apache.org/jira/browse/SUREFIRE
I am not able to manage the issues at Codehaus either ASF.
What can we do about that?
   
Cheers
Tibor
   
   
   
--
View this message in context:
   
  http://maven.40175.n5.nabble.com/IMPORTANT-NOTICE-Jira-migration-fro
m-Cod
eh
aus-to-Apache-on-April-4th-tp5830262p5831520.html Sent from the
Maven
Developers mailing list archive at Nabble.com.
   
   
  
-
To unsubscribe, e-mail: 

Re: Two cleanup patches for maven-eclipse-plugin (MECLIPSE-697, MECLIPSE-758)

[Andreas Gudian]

Great, Thanks!

I'll do the 2.10 release in a not too distant future.


Am Donnerstag, 9. April 2015 schrieb Joseph Walton :

 I've taken a look at two cleanup tasks for maven-eclipse-plugin.

 One is a clearout of long-deprecated classes:

 https://issues.apache.org/jira/browse/MECLIPSE-697

 and the other is updating the mojos to use annotations:

 https://issues.apache.org/jira/browse/MECLIPSE-758

 Both have patches attached which apply cleanly and leave the integration
 tests passing. The one for MECLIPSE-758 applies cleanly on top of
 MECLIPSE-697.

 Would someone with commit privileges be able to take a look and apply them,
 or give me some feedback? I understand that releasing 2.10 isn't a priority
 right now, but it'd be nice to get those in place to simplify things for
 when that happens.

 Thanks.

Re: Prepare release maven-release-plugin

[Andreas Gudian]

2015-04-07 21:53 GMT+02:00 Robert Scholte rfscho...@apache.org:

 Hi,

 I'd like to do a release of the maven-release-plugin soon, especially for
 the Windows+M3.3.1 users.


I still don't get why I didn't think of that when renaming mvn.bat to
mvn.cmd... :-/

Re: Maven 3.3.1 Script Bug

[Andreas Gudian]

If I read that right, there is a problem in the shell scripts, not the
windows cmd script, right? Because mvnDebug.cmd works for me as expected.



Am Sonntag, 5. April 2015 schrieb Karl Heinz Marbaise :

 Hi,

 based on some comments (http://blog.soebes.de/blog/
 2015/03/17/apache-maven-3-dot-3-1-features/#disqus_thread) on my site it
 looks like we have a bug in the debug scripts which do not correctly export
 the variables to the underlying mvn scripts...

 mvnDebug.cmd

 @setlocal

 will prevent exporting the environment variable to the sub calling mvn.cmd
 file...

 furthermore in mvnDebug the call env ... will do the same ? (I'm not
 sure about) can someone acknowledge this with more knowledge about this?


 Kind regards
 Karl Heinz Marbaise

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

Re: [VOTE] Maven 3.3.1 Release

[Andreas Gudian]

+1 from me.

I've tested under Windows with some projects that also contain Maven
Verifier based integration tests.

Thanks for doing this release, Jason!


2015-03-13 23:46 GMT+01:00 Karl Heinz Marbaise khmarba...@gmx.de:

 Hi Jason,

 checked several projects of my own projects,

 checked with:
   * takari (maven-profiler)..

 checked with:
  * maven-scm,
  * maven-archetype,
  * maven-enforcer,
  * maven-jxr,
  * maven-plugin-tools,
  * maven-assembly-plugin

 checked with:
  * apache-rat project,

 without any issue...

 So +1 from me


 Kind regards
 Karl Heinz Marbaise

 On 3/13/15 9:21 PM, Jason van Zyl wrote:

 Hi,

 Time to release Maven 3.3.1!

 Here is a link to Jira with 37 issues resolved:
 https://jira.codehaus.org/secure/ReleaseNote.jspa?
 projectId=10500version=21013

 Staging repo:
 https://repository.apache.org/content/repositories/maven-1151/

 The distributable binaries and sources for testing can be found here:
 https://repository.apache.org/content/repositories/maven-
 1151/org/apache/maven/apache-maven/3.3.1/

 Specifically the zip, tarball, and source archives can be found here:
 https://repository.apache.org/content/repositories/maven-
 1151/org/apache/maven/apache-maven/3.3.1/apache-maven-3.3.1-bin.zip
 https://repository.apache.org/content/repositories/maven-
 1151/org/apache/maven/apache-maven/3.3.1/apache-maven-3.3.1-bin.tar.gz
 https://repository.apache.org/content/repositories/maven-
 1151/org/apache/maven/apache-maven/3.3.1/apache-maven-3.3.1-src.zip
 https://repository.apache.org/content/repositories/maven-
 1151/org/apache/maven/apache-maven/3.3.1/apache-maven-3.3.1-src.tar.gz

 Source release checksum(s):
 apache-maven-3.3.1-src.zip sha1: 93b2e7efaec93437aee67f0618fc77793e20a828

 Staging site:
 http://takari.io/maven-3.3.1/

 Vote open for 72 hours.

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

 Thanks,


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

Re: Release Notes in Plugin Sites

[Andreas Gudian]

In the last two releases of surefire, we included the jira-report in the
site, listing all resolved issues with the appropriate fix-version:

http://maven.apache.org/surefire/maven-surefire-plugin/jira-report.html


Am Dienstag, 10. März 2015 schrieb Karl Heinz Marbaise :

 Hi Stephan,

 On 3/10/15 1:26 PM, Krull, Stephan wrote:

 I agree that there is no HUGE benefit to it.


 I wasn't talking about a HUGE benefit...I have asked if there is any
 benefit

 I see only see a very very small to more or less no benefit at all..


  Just a matter of conformity to common practices.

 To which common practices ? All other projects do release notes/changelogs
 manually...(either pages / files) which i don't like to maintain...

 Furthermore we have JIRA for every plugins / component...


 When you start to release will the release notes from the JIRA version be
 finished?


 JIRA has simply a link to release notes

 Sometimes it happens that the content changes.or later...The link is
 fixed...but it changes from release to release...

  That way one could append the link of the release notes
   to the project overview page before the maven
  site generation for the release starts.

 I would definitely prevent doing something manually ([1] there are enough
 manual steps to do...)...which could lead in missing it...


  I would not vote for integrating the changes plugin if that leads to
 problems.


 Not really problems, but sometimes it happens that issues will be
 changed/added etc. which would result in different Release notes in JIRA
 and on the generated page, cause the page will be generated during the site
 generation processand will not being changed afterwards...


 If you have a single project which is released let's say every 3
 months...it's not a problem to do such things...but here we have 49 plugins
 + (I don't know the number currently) of components etc. where we do
 releases[2]...for...You can take a look into the quaterly report[3] which
 gives you an impression how many releases we are doing...

 May be someone of the other devs has a better idea...

 BTW: That should not prevent you from creating a jira issue for this idea
 ...and you might take a deeper look here into the project and may be you a
 good solution for this or other problem...


 [1] http://maven.apache.org/developers/release/maven-
 project-release-procedure.html
 [2] http://mail-archives.apache.org/mod_mbox/maven-announce/
 201503.mbox/browser
 [3] http://mail-archives.apache.org/mod_mbox/maven-announce/
 201501.mbox/%3C9815490.A2dQluKqs1%40herve-desktop%3E


 Kind regards
 Karl Heinz Marbaise


 -Ursprüngliche Nachricht-
 Von: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
 Gesendet: Dienstag, 10. März 2015 12:15
 An: Maven Developers List
 Betreff: Re: Release Notes in Plugin Sites

 Hi Stephan,

 the question on this is: What would be the benefit of this? Or in other
 words: Will it bring supplemental information?

 All the information is available as you already mentioned...if you really
 interested you can find the information

 Apart from that i could think of using maven-changes-plugin to handle
 this...which unfortunately would make the release process more
 fragile...and which would mean to change the configuration for all 49
 plugins...(here on apache)...

 To be honest: Is that really worth the effort...?

 What do the other devs think?

 Kind regards
 Karl Heinz Marbaise
 On 3/10/15 12:01 PM, Krull, Stephan wrote:

 Hello Maven folks,

 I wonder if there is a possibility to include release notes for plugin
 versions into the common maven site structure. the release notes are
 available via announcement email (i.e. attached mail) or via JIRA issue
 tracker from i.e. http://maven.apache.org/plugins/maven-jar-plugin/
 issue-tracking.html .

 It would be helpful to have that information included in the standard
 maven site for an (official) plugin. Probably in a new section on the
 overview page (i.e. http://maven.apache.org/plugins/maven-jar-plugin/
 index.html) or a new menu entry under menu section Project
 Information.

 What do you think?

 Kind regards
 Stephan Krull


 -Ursprüngliche Nachricht-
 Von: Karl Heinz Marbaise [mailto:khmarba...@apache.org]
 Gesendet: Dienstag, 10. März 2015 11:38
 An: annou...@maven.apache.org
 Cc: us...@maven.apache.org; dev@maven.apache.org
 Betreff: [ANN] Apache Maven Jar Plugin Version 2.6 Released

 The Apache Maven team is pleased to announce the release of the Apache
 Maven Jar Plugin, version 2.6

 This plugin provides the capability to build jars.

 http://maven.apache.org/plugins/maven-jar-plugin/

 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-jar-plugin/artifactId
 version2.6/version
 /plugin

 Release Notes - Maven JAR Plugin - Version 2.6

 Bugs:

* [MJAR-135] - encoding problem with folder-names
* [MJAR-151] - Error assembling JAR on OS X
* [MJAR-179] - Adding empty files to jar failed 

Re: Maven 3.2.6

[Andreas Gudian]

I'm done with my changes (documented in MNG-5776), and it seems to work -
no at least the java process is started with the right parameters and no
script variables leak out into the cmd console... ;-)

@Igor: thanks for checking up, I overlooked your second commit with the
change of the VM-argument name.


2015-02-26 18:07 GMT+01:00 Jason van Zyl ja...@takari.io:


 On Feb 26, 2015, at 3:49 AM, Andreas Gudian andreas.gud...@gmail.com
 wrote:

  I can handle that, but not before the weekend.
 
  Jason, does that conflict with your schedule for the release?
 

 No dire rush on my side and I have two feature branches to merge anyway so
 take your time. Happy to have the help.

  Perhaps we just say that we drop the support for old Windows versions
 with
  3.3.0 and do the actual work that removes the support from the bat files
 in
  the next minor release?
 
  I would imagine that no one out there cares for Windows 98/ME anyway ;-).
 
 
  Am Donnerstag, 26. Februar 2015 schrieb Anders Hammar :
 
  On Thu, Feb 26, 2015 at 8:16 AM, Stephen Connolly 
  stephen.alan.conno...@gmail.com javascript:; wrote:
 
  On Thursday, February 26, 2015, Anders Hammar and...@hammar.net
  javascript:; wrote:
 
 
  One thing we could do to make stuff easier around these .bat scripts
  is
  to
  drop support for this 4NT shell and Windows versions that are not
  based
  on
  NT (i.e. Windows 9x / ME).
 
 
  Well, as Maven 3.2+ requires a minimum of JDK 1.6 there is no reason
 to
  support anything that JDK 1.6 doesn't run on.
 
 
  If we are calling this 3.3.0 we can just say we have dropped win 9x/Me
  support and the 4NT alternative command interpreter
 
 
  Yes. We should probably clearly state what we support in the System
  Requirements (both on-line and in distro).
  And a JIRA ticket to go with this is good for the release notes.
 
  /Anders
 
 
 
 
 
 
  I can't find any info about Oracle JDK 1.6, but Oracle JDK 1.7
  requires a
  minimum of Windows Vista [1].
 
  I couldn't find any info on openJDK's requirements.
 
  IBM J9 JDK 6 seems to require a minimum of Windows XP SP3 [2].
 
  [1] http://www.oracle.com/technetwork/java/javase/config-417990.html
  [2]
 
 
 
 
 http://www-01.ibm.com/support/knowledgecenter/#!/SSYKE2_6.0.0/com.ibm.java.doc.60_26/vm626/GenericWrapper/hardwareandsoftwarerequirements.html
 
  /Anders
 
 
 
 
 
 
  2015-02-25 19:38 GMT+01:00 Jason van Zyl ja...@takari.io
  javascript:;
  javascript:;
  :
 
  Awesome, thanks!
 
  On Feb 25, 2015, at 10:32 AM, Andreas Gudian 
  andreas.gud...@gmail.com javascript:;
  javascript:;
  wrote:
 
  Hi guys,
 
  I'm stuck with a windows box and I can give it a try...
 
  .bat-scripting is not really a joy, but what's in the patch
  should
  be
  translatable.
 
  Andreas
 
  2015-02-25 17:01 GMT+01:00 Igor Fedorenko i...@ifedorenko.com
  javascript:;
  javascript:;:
 
  You can see actual diff to mvn shell script in [1], but the
  changes
  was
  basically two-fold. First, find nearest parent directory that
  contains
  .mvn/ subdirectory. This parent is considered true
  multi-module
  project root (MNG-1958). Second, if .mvn/java.config file is
  present
  immediately under the true multimodule project root, use its
  content
  as
  java invocation parameters, i.e. similar to $MAVEN_OPTS
  environment
  variable.
 
  I don't know enough about Windows scripting to make similar
  change
  to
  mvn.bat and mvnDebug.bat batch files.
 
  [1]
  https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
  8ed9a1caa8890773b45c6c408a4e40acf4f4b0fd
 
  --
  Regards,
  Igor
 
 
  On 2015-02-25 9:56, Robert Patrick wrote:
 
  What exactly is the problem that Igor ran into that limits his
  solution
  to Unix-only?  Knowing this would help people determine what
  the
  level
  of
  effort needed to solve the problem.
 
 
  --
  Robert Patrick robert.patr...@oracle.com javascript:;
  javascript:;
  VP, Oracle Corporation
  7460 Warren Pkwy, Ste. 300  Office: +1.972.963.2872
  Frisco, TX 75034, USA   Mobile: +1.469.556.9450
 
  Professional Oracle WebLogic Server
  by Robert Patrick, Gregory Nyberg, and Philip Aston
  with Josh Bregman and Paul Done
  Book Home Page: http://www.wrox.com/
  Kindle Version: http://www.amazon.com/
 
 
  -Original Message-
  From: Jason van Zyl [mailto:ja...@takari.io javascript:;
  javascript:;]
  Sent: Wednesday, February 25, 2015 7:40 AM
  To: Maven Developers List
  Subject: Re: Maven 3.2.6
 
 
  On Feb 24, 2015, at 11:31 PM, Arnaud Héritier 
  aherit...@gmail.com javascript:;
  javascript:;
  wrote:
 
  I had a quick look at the changeling and I'm +1 for a 3.3.0
  with
  improvements like the toolchain integration and few others I'm
  far
  from the project and won't veto anything as I have no time for
  it
  but
  I don't understand why
  http://jira.codehaus.org/browse/MNG-5767
  was
  integrated without a windows support ? For me it is everything
  or
  nothing.
  Noone could help Igor on this ?
 
 
  It would

Re: Maven 3.2.6

[Andreas Gudian]

I can handle that, but not before the weekend.

Jason, does that conflict with your schedule for the release?

Perhaps we just say that we drop the support for old Windows versions with
3.3.0 and do the actual work that removes the support from the bat files in
the next minor release?

I would imagine that no one out there cares for Windows 98/ME anyway ;-).


Am Donnerstag, 26. Februar 2015 schrieb Anders Hammar :

 On Thu, Feb 26, 2015 at 8:16 AM, Stephen Connolly 
 stephen.alan.conno...@gmail.com javascript:; wrote:

  On Thursday, February 26, 2015, Anders Hammar and...@hammar.net
 javascript:; wrote:
 
   
One thing we could do to make stuff easier around these .bat scripts
 is
   to
drop support for this 4NT shell and Windows versions that are not
 based
   on
NT (i.e. Windows 9x / ME).
  
  
   Well, as Maven 3.2+ requires a minimum of JDK 1.6 there is no reason to
   support anything that JDK 1.6 doesn't run on.
 
 
  If we are calling this 3.3.0 we can just say we have dropped win 9x/Me
  support and the 4NT alternative command interpreter


 Yes. We should probably clearly state what we support in the System
 Requirements (both on-line and in distro).
 And a JIRA ticket to go with this is good for the release notes.

 /Anders



 
 
  
   I can't find any info about Oracle JDK 1.6, but Oracle JDK 1.7
 requires a
   minimum of Windows Vista [1].
  
   I couldn't find any info on openJDK's requirements.
  
   IBM J9 JDK 6 seems to require a minimum of Windows XP SP3 [2].
  
   [1] http://www.oracle.com/technetwork/java/javase/config-417990.html
   [2]
  
  
 
 http://www-01.ibm.com/support/knowledgecenter/#!/SSYKE2_6.0.0/com.ibm.java.doc.60_26/vm626/GenericWrapper/hardwareandsoftwarerequirements.html
  
   /Anders
  
  
  
   
   
   
2015-02-25 19:38 GMT+01:00 Jason van Zyl ja...@takari.io
 javascript:;
  javascript:;
   :
   
 Awesome, thanks!

 On Feb 25, 2015, at 10:32 AM, Andreas Gudian 
  andreas.gud...@gmail.com javascript:;
   javascript:;
 wrote:

  Hi guys,
 
  I'm stuck with a windows box and I can give it a try...
 
  .bat-scripting is not really a joy, but what's in the patch
 should
  be
  translatable.
 
  Andreas
 
  2015-02-25 17:01 GMT+01:00 Igor Fedorenko i...@ifedorenko.com
 javascript:;
   javascript:;:
 
  You can see actual diff to mvn shell script in [1], but the
  changes
was
  basically two-fold. First, find nearest parent directory that
   contains
  .mvn/ subdirectory. This parent is considered true
 multi-module
  project root (MNG-1958). Second, if .mvn/java.config file is
  present
  immediately under the true multimodule project root, use its
  content
as
  java invocation parameters, i.e. similar to $MAVEN_OPTS
  environment
  variable.
 
  I don't know enough about Windows scripting to make similar
 change
   to
  mvn.bat and mvnDebug.bat batch files.
 
  [1]
  https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
  8ed9a1caa8890773b45c6c408a4e40acf4f4b0fd
 
  --
  Regards,
  Igor
 
 
  On 2015-02-25 9:56, Robert Patrick wrote:
 
  What exactly is the problem that Igor ran into that limits his
solution
  to Unix-only?  Knowing this would help people determine what
 the
level
 of
  effort needed to solve the problem.
 
 
  --
  Robert Patrick robert.patr...@oracle.com javascript:;
 javascript:;
  VP, Oracle Corporation
  7460 Warren Pkwy, Ste. 300  Office: +1.972.963.2872
  Frisco, TX 75034, USA   Mobile: +1.469.556.9450
 
  Professional Oracle WebLogic Server
  by Robert Patrick, Gregory Nyberg, and Philip Aston
  with Josh Bregman and Paul Done
  Book Home Page: http://www.wrox.com/
  Kindle Version: http://www.amazon.com/
 
 
  -Original Message-
  From: Jason van Zyl [mailto:ja...@takari.io javascript:;
 javascript:;]
  Sent: Wednesday, February 25, 2015 7:40 AM
  To: Maven Developers List
  Subject: Re: Maven 3.2.6
 
 
  On Feb 24, 2015, at 11:31 PM, Arnaud Héritier 
  aherit...@gmail.com javascript:;
   javascript:;
  wrote:
 
  I had a quick look at the changeling and I'm +1 for a 3.3.0
 with
  improvements like the toolchain integration and few others I'm
  far
  from the project and won't veto anything as I have no time for
  it
but
  I don't understand why
 http://jira.codehaus.org/browse/MNG-5767
   was
  integrated without a windows support ? For me it is everything
  or
  nothing.
  Noone could help Igor on this ?
 
 
  It would be great if someone would help, but it is still a step
 forward.
  For projects that require this and document specific
 requirements
   it
 will
  just work for non-Windows users. Say the project needs 8gb to
 run
  correctly: in most cases

Re: Maven 3.2.6

[Andreas Gudian]

Hi guys,

I'm stuck with a windows box and I can give it a try...

 .bat-scripting is not really a joy, but what's in the patch should be
translatable.

Andreas

2015-02-25 17:01 GMT+01:00 Igor Fedorenko i...@ifedorenko.com:

 You can see actual diff to mvn shell script in [1], but the changes was
 basically two-fold. First, find nearest parent directory that contains
 .mvn/ subdirectory. This parent is considered true multi-module
 project root (MNG-1958). Second, if .mvn/java.config file is present
 immediately under the true multimodule project root, use its content as
 java invocation parameters, i.e. similar to $MAVEN_OPTS environment
 variable.

 I don't know enough about Windows scripting to make similar change to
 mvn.bat and mvnDebug.bat batch files.

 [1] https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
 8ed9a1caa8890773b45c6c408a4e40acf4f4b0fd

 --
 Regards,
 Igor


 On 2015-02-25 9:56, Robert Patrick wrote:

 What exactly is the problem that Igor ran into that limits his solution
 to Unix-only?  Knowing this would help people determine what the level of
 effort needed to solve the problem.


 --
 Robert Patrick robert.patr...@oracle.com
 VP, Oracle Corporation
 7460 Warren Pkwy, Ste. 300  Office: +1.972.963.2872
 Frisco, TX 75034, USA   Mobile: +1.469.556.9450

 Professional Oracle WebLogic Server
 by Robert Patrick, Gregory Nyberg, and Philip Aston
 with Josh Bregman and Paul Done
 Book Home Page: http://www.wrox.com/
 Kindle Version: http://www.amazon.com/


 -Original Message-
 From: Jason van Zyl [mailto:ja...@takari.io]
 Sent: Wednesday, February 25, 2015 7:40 AM
 To: Maven Developers List
 Subject: Re: Maven 3.2.6


 On Feb 24, 2015, at 11:31 PM, Arnaud Héritier aherit...@gmail.com
 wrote:

  I had a quick look at the changeling and I'm +1 for a 3.3.0 with
 improvements like the toolchain integration and few others I'm far
 from the project and won't veto anything as I have no time for it but
 I don't understand why http://jira.codehaus.org/browse/MNG-5767 was
 integrated without a windows support ? For me it is everything or
 nothing.
 Noone could help Igor on this ?


 It would be great if someone would help, but it is still a step forward.
 For projects that require this and document specific requirements it will
 just work for non-Windows users. Say the project needs 8gb to run
 correctly: in most cases no one reads the documentation they run the build
 and it fails. Then they go read something and figure it out and it works.
 We've at least made it work for some people. If there isn't a single Maven
 committer who uses Windows who can add the same capabilities or we can't
 find a contributor I don't think it should stop the feature for going in
 for the people it can benefit.

 Igor and I don't use Windows regularly, don't know Windows, don't want to
 know Windows and none of our customers use Windows.

 It's overall a net improvement. For me it's a about gradual improvement.
 But I've asked on Twitter if there are any Windows users that can help.

  Many months/years ago the integration of colors in logs output was
 rejected in a part because we wasn't confident in the windows support ...


 I don't think that was the issue. The issue was us not being able the
 decide on an underlying logging framework. I've seen JANSI working fine on
 Windows for years.


 My 2 cents.

 On Wed, Feb 25, 2015 at 1:29 AM, Mark Derricutt m...@talios.com wrote:

  On 25 Feb 2015, at 4:06, Karl Heinz Marbaise wrote:

  based on the list of changes i would suggest to make a 3.3.0 instead
 of

 3.2.6to make clear something is introduced

 +1 on 3.3.0 here. Bring on the changes!

 Mark

 --
 Mark Derricutt
 http://www.theoryinpractice.net
 http://www.chaliceofblood.net
 http://plus.google.com/+MarkDerricutt
 http://twitter.com/talios
 http://facebook.com/mderricutt




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


 Thanks,

 Jason

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

 People develop abstractions by generalizing from concrete examples.
 Every attempt to determine the correct abstraction on paper without
 actually developing a running system is doomed to failure. No one is that
 smart. A framework is a resuable design, so you develop it by looking at
 the things it is supposed to be a design of. The more examples you look at,
 the more general your framework will be.

-- Ralph Johnson  Don Roberts, Patterns for Evolving Frameworks













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


 -
 To 

Re: Maven 3.2.6

[Andreas Gudian]

Well, ok, here it is:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=562896a192072b9044a6b2fd37ff31bf638214c8

For Windows 9x/ME, only the first line of jvm.config can be used.

I also started checking if I could boil down mvnDebug.bat to pretty much
just delegate to mvn.bat, but Windows 9x compatibility and this 4NT Shell
from jp software which I never heard of before changed my mind - I'm not
that deep into this to make sure I don't break something for non-WinNT
users. So I left it as it is and made sure mvn.bat and mvnDebug.bat are
properly synchronized.

One thing we could do to make stuff easier around these .bat scripts is to
drop support for this 4NT shell and Windows versions that are not based on
NT (i.e. Windows 9x / ME).



2015-02-25 19:38 GMT+01:00 Jason van Zyl ja...@takari.io:

 Awesome, thanks!

 On Feb 25, 2015, at 10:32 AM, Andreas Gudian andreas.gud...@gmail.com
 wrote:

  Hi guys,
 
  I'm stuck with a windows box and I can give it a try...
 
  .bat-scripting is not really a joy, but what's in the patch should be
  translatable.
 
  Andreas
 
  2015-02-25 17:01 GMT+01:00 Igor Fedorenko i...@ifedorenko.com:
 
  You can see actual diff to mvn shell script in [1], but the changes was
  basically two-fold. First, find nearest parent directory that contains
  .mvn/ subdirectory. This parent is considered true multi-module
  project root (MNG-1958). Second, if .mvn/java.config file is present
  immediately under the true multimodule project root, use its content as
  java invocation parameters, i.e. similar to $MAVEN_OPTS environment
  variable.
 
  I don't know enough about Windows scripting to make similar change to
  mvn.bat and mvnDebug.bat batch files.
 
  [1] https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
  8ed9a1caa8890773b45c6c408a4e40acf4f4b0fd
 
  --
  Regards,
  Igor
 
 
  On 2015-02-25 9:56, Robert Patrick wrote:
 
  What exactly is the problem that Igor ran into that limits his solution
  to Unix-only?  Knowing this would help people determine what the level
 of
  effort needed to solve the problem.
 
 
  --
  Robert Patrick robert.patr...@oracle.com
  VP, Oracle Corporation
  7460 Warren Pkwy, Ste. 300  Office: +1.972.963.2872
  Frisco, TX 75034, USA   Mobile: +1.469.556.9450
 
  Professional Oracle WebLogic Server
  by Robert Patrick, Gregory Nyberg, and Philip Aston
  with Josh Bregman and Paul Done
  Book Home Page: http://www.wrox.com/
  Kindle Version: http://www.amazon.com/
 
 
  -Original Message-
  From: Jason van Zyl [mailto:ja...@takari.io]
  Sent: Wednesday, February 25, 2015 7:40 AM
  To: Maven Developers List
  Subject: Re: Maven 3.2.6
 
 
  On Feb 24, 2015, at 11:31 PM, Arnaud Héritier aherit...@gmail.com
  wrote:
 
  I had a quick look at the changeling and I'm +1 for a 3.3.0 with
  improvements like the toolchain integration and few others I'm far
  from the project and won't veto anything as I have no time for it but
  I don't understand why http://jira.codehaus.org/browse/MNG-5767 was
  integrated without a windows support ? For me it is everything or
  nothing.
  Noone could help Igor on this ?
 
 
  It would be great if someone would help, but it is still a step
 forward.
  For projects that require this and document specific requirements it
 will
  just work for non-Windows users. Say the project needs 8gb to run
  correctly: in most cases no one reads the documentation they run the
 build
  and it fails. Then they go read something and figure it out and it
 works.
  We've at least made it work for some people. If there isn't a single
 Maven
  committer who uses Windows who can add the same capabilities or we
 can't
  find a contributor I don't think it should stop the feature for going
 in
  for the people it can benefit.
 
  Igor and I don't use Windows regularly, don't know Windows, don't want
 to
  know Windows and none of our customers use Windows.
 
  It's overall a net improvement. For me it's a about gradual
 improvement.
  But I've asked on Twitter if there are any Windows users that can help.
 
  Many months/years ago the integration of colors in logs output was
  rejected in a part because we wasn't confident in the windows support
 ...
 
 
  I don't think that was the issue. The issue was us not being able the
  decide on an underlying logging framework. I've seen JANSI working
 fine on
  Windows for years.
 
 
  My 2 cents.
 
  On Wed, Feb 25, 2015 at 1:29 AM, Mark Derricutt m...@talios.com
 wrote:
 
  On 25 Feb 2015, at 4:06, Karl Heinz Marbaise wrote:
 
  based on the list of changes i would suggest to make a 3.3.0 instead
  of
 
  3.2.6to make clear something is introduced
 
  +1 on 3.3.0 here. Bring on the changes!
 
  Mark
 
  --
  Mark Derricutt
  http://www.theoryinpractice.net
  http://www.chaliceofblood.net
  http://plus.google.com/+MarkDerricutt
  http://twitter.com/talios
  http://facebook.com/mderricutt
 
 
 
 
  --
  -
  Arnaud Héritier
  http://aheritier.net
  Mail

Re: Early Access builds for JDK 9 b48, JDK 8u40 b23 JDK 7u80 b05 are available on java.net

[Andreas Gudian]

 With one of the previous builds, I've noticed that the mvn compiler
 plugin running on JDK 9 is unable to use a different JDK from a toolchain.


I'm taking that back - it's not the toolchain, but it happens when you try
to use maven-compiler-plugin with the jdt compiler from tyco-compiler-jdt
package... Looking at their code, that's to be expected.




2015-02-06 18:51 GMT+01:00 Andreas Gudian andreas.gud...@gmail.com:

 Hi,

 With one of the previous builds, I've noticed that the mvn compiler
 plugin running on JDK 9 is unable to use a different JDK from a toolchain.

 Before I start digging into this: has anyone else noticed /
 investigated that already?

 On a different note: using JDK 9 to do some  compiling / annotation
 processing takes twice the time as with JDK 8 - but I guess that can be
 expected in an early early-access build :-).

 Andreas

 Am Freitag, 6. Februar 2015 schrieb Rory O'Donnell :

 Hi Robert  Kristian,

 Nice meeting you guys at FOSDEM.

 Now that JDK 9 Early Access build images are modular [1], there is a fresh
 Early Access build for JDK 9 b48 https://jdk9.java.net/download/
 available on java.net.
 The summary of  changes are listed here http://www.java.net/download/
 jdk9/changes/jdk9-b48.html

 In addition, there are new Early Access builds for the ongoing update
 releases.

 The Early Access build for JDK 8u40 b23 http://jdk8.java.net/
 download.html is available on java.net, with the
 summary of changes listed here. http://www.java.net/download/
 jdk8u40/changes/jdk8u40-b23.html

 Finally, the Early Access build for JDK 7u80 b05 https://jdk7.java.net/
 download.htmlis available on java.net,
 with the summary of changes listed here. http://download.java.net/
 jdk7u80/changes/jdk7u80-b05.html

 As we enter the later phases of development for JDK 7u80  JDK 8u40,
 please log any show stoppers as soon as possible.

 Rgds,Rory

 [1] http://mreinhold.org/blog/jigsaw-modular-images

 --
 Rgds,Rory O'Donnell
 Quality Engineering Manager
 Oracle EMEA , Dublin, Ireland

Re: Early Access builds for JDK 9 b48, JDK 8u40 b23 JDK 7u80 b05 are available on java.net

[Andreas Gudian]

Hi,

With one of the previous builds, I've noticed that the mvn compiler
plugin running on JDK 9 is unable to use a different JDK from a toolchain.

Before I start digging into this: has anyone else noticed /
investigated that already?

On a different note: using JDK 9 to do some  compiling / annotation
processing takes twice the time as with JDK 8 - but I guess that can be
expected in an early early-access build :-).

Andreas

Am Freitag, 6. Februar 2015 schrieb Rory O'Donnell :

 Hi Robert  Kristian,

 Nice meeting you guys at FOSDEM.

 Now that JDK 9 Early Access build images are modular [1], there is a fresh
 Early Access build for JDK 9 b48 https://jdk9.java.net/download/
 available on java.net.
 The summary of  changes are listed here http://www.java.net/download/
 jdk9/changes/jdk9-b48.html

 In addition, there are new Early Access builds for the ongoing update
 releases.

 The Early Access build for JDK 8u40 b23 http://jdk8.java.net/
 download.html is available on java.net, with the
 summary of changes listed here. http://www.java.net/download/
 jdk8u40/changes/jdk8u40-b23.html

 Finally, the Early Access build for JDK 7u80 b05 https://jdk7.java.net/
 download.htmlis available on java.net,
 with the summary of changes listed here. http://download.java.net/
 jdk7u80/changes/jdk7u80-b05.html

 As we enter the later phases of development for JDK 7u80  JDK 8u40,
 please log any show stoppers as soon as possible.

 Rgds,Rory

 [1] http://mreinhold.org/blog/jigsaw-modular-images

 --
 Rgds,Rory O'Donnell
 Quality Engineering Manager
 Oracle EMEA , Dublin, Ireland

Re: Open JIRA issues/retiring plugins

[Andreas Gudian]

I'm pretty sure I might be bashed for writing this, but what the heck... ;-)

I do still see some need for the maven-eclipse-plugin.

To be perfectly clear, I agree that m2e is by far superior in many ways,
not only tech-wise, but also conceptionally.

Still, at work we had to migrate from m2e to m-eclipse-p a couple of years
ago, which included some minor adaptations to the plugin, and it works like
a charm since then (that was back in the days when m2e was far away from
version 1.0.0). We have a workspace with about 500 projects and we commit
the eclipse metadata for each project to our source repository. Changes in
the poms don't happen that often, and if needed that one colleague runs
m-eclipse-p to update the metadata and commits everything in one go. The
other colleagues do their update, refresh in eclipse, maybe run a batch
file to download newly referenced jars to the local repo, and they're done.
Eclipse will build quite quickly.

I just tried the latest m2e version with our projects and, although it's by
far better than it was some years ago, I had to tripple my memory settings
and wait 20 minutes for the update project... and the following build.
That's something I can't sell to my colleagues (many of them don't even
have enough RAM for that, sadly enough).

So I'm herby volunteering to go ahead and pull out some of the adjustments
that I did for my customer and I'd be happy to do a release. If there's a
chance to get some PMC votes on such a thing ;-).

I'd also include a disclaimer on the site that builds with m2e are in many
cases closer to the real maven build, that m2e is much more maintained,
that it is discouraged to use m-eclipse-p, and that the maven team strongly
suggests using m2e. Something like that.

WDYT?

Andreas



2015-02-02 14:00 GMT+01:00 Benson Margulies bimargul...@gmail.com:

 Just to be perfectly clear:

 I am volunteering to include archetype in the herd.

 I have submitted INFRA-9100 to move it to git.
 I have assigned http://jira.codehaus.org/browse/ARCHETYPE-471 to myself.

 So no need to send any email announcing its demise.

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

Re: Open JIRA issues/retiring plugins

[Andreas Gudian]

Great, Daniel, I thought I'm the only one thinking that way... ;-)

2015-02-02 19:38 GMT+01:00 Daniel Kulp dk...@apache.org:


 I’m -1 to retiring the maven-eclipse-plugin until the m2e stuff is at a
 state where it can be as flexible and useful as the maven-eclipse-plugin.
  Trying to bring a large complex project like CXF into eclipse with m2e is
 PAINFUL and doesn’t even result in fully configured and ready workspace.
  The developer experience within eclipse is so much better after using the
 maven-eclipse-plugin.

 I suppose that does mean I should step up and look at some of the JIRA’s
 and get a release out.  I’ll see if I can find some time.

 Dan



  On Feb 2, 2015, at 4:23 AM, Michael Osipov 1983-01...@gmx.net wrote:
 
  Hi folks,
 
  I have performed another cleanup on JIRA in the last couple of days,
 most of on old issues.
  Right now, we have more than 2000 open issues. Not manageble from my
 point of view.
 
  I have noticed that several plugins haven't been touched in years. What
 is the status of
  the following plugins:
 
  http://maven.apache.org/plugins/maven-docck-plugin/
  http://maven.apache.org/plugins/maven-doap-plugin/
  http://maven.apache.org/plugins/maven-repository-plugin/
  http://maven.apache.org/plugins/maven-stage-plugin/
  http://maven.apache.org/plugins/maven-eclipse-plugin/
  http://maven.apache.org/plugins/maven-verifier-plugin/
  http://maven.apache.org/plugins/maven-patch-plugin/
  http://maven.apache.org/plugins/maven-pdf-plugin/
  http://maven.apache.org/archetype/maven-archetype-plugin/
 
  Is anyone working on them or planning to release a version? Any thoughts
 or objections?
 
  I'd like to retire them and clean up JIRA plugin by plugin.
 
  Michael
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 

 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com


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

Re: Surefire Plugin does not handle workingDirectory in fork mode properly

[Andreas Gudian]

Thanks, Norbert!

Could you also create a new Pull-Request for it? Then I can fetch it more
easily :-)


Am Mittwoch, 28. Januar 2015 schrieb Norbert Wnuk :

 Link after pushing amended commit -

 https://github.com/norbertwnuk/maven-surefire/commit/d6a8af593fc03e12ecf2dc8047669472f7ca263b

 On Wed, Jan 28, 2015 at 3:10 AM, Norbert Wnuk norbertw...@gmail.com
 javascript:; wrote:

  Hi Tibor / Andreas,
  I found a time to address problem with unit test, will take a look at
  integration test tomorrow.
 
 
 https://github.com/norbertwnuk/maven-surefire/commit/44b6ffaddc93c34c3e76abd4ea5fd3b8d837a130
 
  NW
 
  On Sun, Jan 25, 2015 at 1:32 AM, Tibor Digana tibordig...@apache.org
 javascript:;
  wrote:
 
  Hi Norbert,
  I have updaated PR #82 with comment on GitHub.
  The Ubuntu builds fail.
  I would prefer keeping the test anyway.
  Try to find a solution for Ubuntu as well; otherwise use JUnit
 assumption
  statement
  assumeThat( os, anyOf( is( Windows ), is( Ubuntu1 ) ) )
  in the particular IT method, possibly unit test.
 
 
 
 
  --
  View this message in context:
 
 http://maven.40175.n5.nabble.com/Surefire-Plugin-does-not-handle-workingDirectory-in-fork-mode-properly-tp5824054p5824683.html
  Sent from the Maven Developers mailing list archive at Nabble.com.
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:;
  For additional commands, e-mail: dev-h...@maven.apache.org
 javascript:;
 
 
 

Re: Surefire Plugin does not handle workingDirectory in fork mode properly

[Andreas Gudian]

Hi Norbert,

yesterday I ran the whole build locally (Windows) with JDK 5 and everything
worked for me.

For the linux case, I guess it's hard to create an directory with an
invalid name. In case you don't find an alternative approach, I wouldn't be
devastated if we just removed that test case again... ;-)

Andreas

2015-01-22 23:47 GMT+01:00 Norbert Wnuk norbertw...@gmail.com:

 Hi Andreas,
 My pull request seems to be unusually problematic ... I was running all
 tests on Ubuntu (and Windows too) but apparently assumption that '\0'
 cannot be used in directory name on Linux might not be always true:
 https://builds.apache.org/job/maven-surefire/1386/
 https://builds.apache.org/job/maven-surefire-mvn-2.2.1/1539/

 http://stackoverflow.com/questions/1976007/what-characters-are-forbidden-in-windows-and-linux-directory-names
 Are you able to recreate the behavior?
 Not sure how it is related to the fact that I was forced to swap to first
 characters in directory name: ?\0InvalidDirectoryName after last
 refactoring (removing nio API) since leading '\0' just after '\' in the
 path name started to affect getCanonicalPath on Windows (it was terminating
 path name at this position). Need one day more to clarify unit test and
 additionally re-run integration test with maven 2.x.

 Regards,
 NW


 On Thu, Jan 22, 2015 at 1:52 AM, Norbert Wnuk norbertw...@gmail.com
 wrote:

  Pull request with the fix -
  https://github.com/apache/maven-surefire/pull/82
 
  NW
 
  On Wed, Jan 21, 2015 at 9:27 PM, Tibor Digana tibordig...@apache.org
  wrote:
 
  This is a traditional problem with animal-sniffer-maven-plugin.
  We had the same issue in JUnit project. Alrerady reported in JIRA
  http://jira.codehaus.org/browse/MANIMALSNIFFER-54
  http://jira.codehaus.org/browse/MANIMALSNIFFER-40
  I would like to have the check-test goal or a new parameter.
  It's still assigned to @stephenc.
  I would appreciate it working and utilized in Maven and JUnit projects.
 
 
 
  --
  View this message in context:
 
 http://maven.40175.n5.nabble.com/Surefire-Plugin-does-not-handle-workingDirectory-in-fork-mode-properly-tp5824054p5824348.html
  Sent from the Maven Developers mailing list archive at Nabble.com.
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 

Re: Surefire Plugin does not handle workingDirectory in fork mode properly

[Andreas Gudian]

Hi Norbert,

Oh, I misses that one as well - our animal sniffer seems to put its nose
only into the main classes.

A new pull-request would be great.

Am Dienstag, 20. Januar 2015 schrieb Norbert Wnuk :

 Hi Andreas,
 The JDK API level is not enforced during build so that my accidental usage
 of JDK 1.7 API in tests was not discovered till recent Jenkins build:
 https://builds.apache.org/job/maven-surefire/1385/ Should I create new
 pull
 request / what is the procedure after closing original pull request?

 Regards,
 NW

 On Tue, Jan 20, 2015 at 1:24 AM, Norbert Wnuk norbertw...@gmail.com
 javascript:; wrote:

  JIRA created, pull request with more mature fix attached (including
  integration test).
 
  https://jira.codehaus.org/browse/SUREFIRE-1136
  https://github.com/apache/maven-surefire/pull/80
 
  Regards,
  NW
 
  On Mon, Jan 19, 2015 at 8:03 AM, Karl Heinz Marbaise khmarba...@gmx.de
 javascript:;
  wrote:
 
  Hi Norbert,
 
  It's great that you asking for permission to create a jira but you don't
  need to just create one and describe the situation etc. why and how it
 went
  wrong or what can be improved and of course your patch is really
  great...but it would be much easier if you could either provide a test
 for
  your patch or at least add an example project which shows the wrong
  behaviour...
 
  Thanks in advance
 
  Kind regards
  Karl Heinz Marbaise
 
 
  On 1/18/15 10:56 PM, Norbert Wnuk wrote:
 
  Hi All,
  Not sure whether this is a proper place however Surefire webpage
  redirects to this mailing group.
  Recently we found two issues in Surefire plugin related to
  surefire.forkNumber variable and ability to define separate working
  directory per forked JVM. First issue is that the same directory is set
  for each of forked JVMs, the second problem is that surefire.forkNumber
  is expanded only for user.dir property and not for actual working
  directory (it leads to the situations like described here:
  http://stackoverflow.com/questions/1234795/why-is-the-
  user-dir-system-property-working-in-java).
  Attaching patch that resolves both problems for us (without test cases
  yet). Asking for a permission to create a JIRA.
 
  workingDirectorydirectory_${surefire.forkNumber}/workingDirectory
 
  Regards,
  Norbert
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:;
  For additional commands, e-mail: dev-h...@maven.apache.org
 javascript:;
 
 
 

Re: Surefire Plugin does not handle workingDirectory in fork mode properly

[Andreas Gudian]

Hi Norbert,

sounds great! To create a Jira-Issue for surefire [1], you just need to
sign-up on xircles [2].

You can attach your path to the Jira issue, if you like. The most fluent
way to suggest patches is by making a pull-request on GitHub where we can
directly discuss the patch.

In the end, for a patch to be applied, we need an intergration test - but
we can guide you to that step by step, if you want to let us take a first
look on what you changed.

Thanks,
Andreas

1: http://jira.codehaus.org/browse/SUREFIRE
2: https://xircles.codehaus.org/signup/

2015-01-18 22:56 GMT+01:00 Norbert Wnuk norbertw...@gmail.com:

 Hi All,
 Not sure whether this is a proper place however Surefire webpage redirects
 to this mailing group.
 Recently we found two issues in Surefire plugin related to
 surefire.forkNumber variable and ability to define separate working
 directory per forked JVM. First issue is that the same directory is set for
 each of forked JVMs, the second problem is that surefire.forkNumber is
 expanded only for user.dir property and not for actual working directory
 (it leads to the situations like described here:
 http://stackoverflow.com/questions/1234795/why-is-the-user-dir-system-property-working-in-java).
 Attaching patch that resolves both problems for us (without test cases
 yet). Asking for a permission to create a JIRA.

 workingDirectorydirectory_${surefire.forkNumber}/workingDirectory

 Regards,
 Norbert


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

Re: Plugable/Softcoded/Customized Maven Plugins

[Andreas Gudian]

I think that we don't need to fully open up our plugins so that anyone can
customize each aspect on the fly. We would too much hide the fact that
the execution is highly customized because some special stuff is hidden on
the classpath somewhere.

Likewise, if we allowed that sort of customization directly as script in
the pom, then we'd try to mimic something that other tools like gradle
already do - that may be good for some use cases (and then you should use
gradle), but it's not what Maven is there for. What especially liked about
Maven after years of Ant was, besides the dependency management, the
uniformity of all those different maven projects. Maven has still a lot
room for improvement, sure. Allowing the complete redefinition of mojos via
scripting in the poms is not something that I would see as an improvement
(plus, there are all those drawbacks on coding, testing, debugging, as
Kristian already pointed out).

For the big picture, I think it would suffice if we found and agreed upon a
handy mechanism to allow users to hook in at _defined_ places (e.g. for
Surefire the processing of the list of tests to execute, reporting, maybe
forking, ..).

I'd say such a mechanism is handy, if it fulfills the following
requirements:
* pulling in a client-api does not mean I also get all sorts of other
maven-specific stuff on my classpath
* it should be possible to pick up the exension from the current reactor
(from the classpath - or perhaps we use some new packaging-type or
something)
* it should be easy and maybe encouraged to publish extensions - that
should be a no-brainer in any case, but perhaps there's something we can do
to help people find existing extensions - similar to the way you find
plugins for Jenkins

Andreas


2015-01-15 11:57 GMT+01:00 Tibor Digana tibordig...@apache.org:

 Maybe Jason can bring some light into this discussion.
 Jason?



 --
 View this message in context:
 http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823611.html
 Sent from the Maven Developers mailing list archive at Nabble.com.

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

Re: [VOTE] Release Apache Maven Surefire Plugin version 2.18.1

[Andreas Gudian]

+1


2014-12-24 17:03 GMT+01:00 tibo...@lycos.com:

 Hi,

 We solved 13 issues:
 https://jira.codehaus.org/secure/ReleaseNote.jspa?
 projectId=10541version=20814

 There are still a couple of issues left in JIRA:
 http://jira.codehaus.org/secure/IssueNavigator.jspa?
 reset=truemode=hidejqlQuery=project+%3D+SUREFIRE+AND+
 resolution+%3D+Unresolved+ORDER+BY+updated+DESC

 Staging repo:
 https://repository.apache.org/content/repositories/maven-1110
 https://repository.apache.org/service/local/repositories/
 maven-1110/content/org/apache/maven/surefire/surefire/2.18.
 1/surefire-2.18.1-source-release.zip

 Source release checksum(s):
 surefire-2.18.1-source-release.zip sha1: 59a04c54118e796ca3729b0376a718
 91d299ed9b

 Staging site:
 http://maven.apache.org/surefire-archives/surefire-
 LATEST/maven-surefire-plugin/index.html
 http://maven.apache.org/surefire-archives/surefire-
 LATEST/maven-failsafe-plugin/index.html
 http://maven.apache.org/surefire-archives/surefire-
 LATEST/maven-surefire-report-plugin/index.html

 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: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)

[Andreas Gudian]

Did we already cover what we want to keep supporting via Toolchains?

We would have to take some care in Surefire if we wanted to keep some
support for 1.6 when using toolchains or when allowing users to configure
a different JVM.



2014-12-25 15:57 GMT+01:00 Karl Heinz Marbaise khmarba...@gmx.de:

 Hi,

 let me summarize things a little bit:

  Last time discussed this we established a consensus to establish 3.0.5
  (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins.

 http://www.mail-archive.com/dev@maven.apache.org/msg102539.html

 that was not three months ago...so the line to lift all plugins to 2.2.1
 minimum is not very far way...

 I would assume a month or two...I hope less..

 https://builds.apache.org/job/dist-tool-plugin/site/dist-
 tool-prerequisites.html

 maven-enforcer: next takes a little bit..working on it...
 maven-ear-plugin: waiting for a feedback (on monday i hope so). After that
 i will call a VOTE for it...
 maven-jar-plugin: currently one issue open.
 maven-gpg-plugin: could be released...
 maven-plugin-plugin: currently no issue open for the 3.4 release (so could
 be pushed out in very short time)
 maven-compiler-plugin: just to fit 2.2.1 could be released
 maven-antrun-plugin: Release 1.8 prepared (i would call a vote in a few
 days).
 maven-jarsigner-plugin: Could be released...to fullfil 2.2.1

 maven-archetype-plugin: Takes some time...started to work on it

 So now the problematic items:

 maven-ant-plugin: Should be retired
 maven-doap-plugin: Might be retired
 maven-stage-plugin: Might be retired
 maven-docck-plugin: Might be retired Unsure
 maven-patch-plugin: Should be retired (better use VCS for such things).
 maven-repository-plugin: Might be retired
 maven-verifier-plugin: Should be retired
 maven-eclipse-plugin: Should be retired to bring people to correct
 direction and use m2e instead

 So now coming to the maven releases:

 Maven 3.0.X line
  No change for a year (https://github.com/apache/maven/tree/maven-3.0.x)
  No issue related to 3.0.X line in JIRA

 Maven 3.1.X Line
  No change for 10 months (https://github.com/apache/maven/tree/maven-3.1.x
 )
  No issue related to 3.1.X line in JIRA

 So next level upgrading will be 3.0.5 minium

 So we should declare EoL for Maven 3.0.5 in Februar 2015...or earlier...
 and for 3.1.1 in April...

 So based on the above i would say moving to Java 1.6 does really make
 sense although it is inconsistent from the user point of view...but making
 a clear release note shouldn't be that hard to make...

 So +1 to move to 1.6

 This should be made clear by making all plugin versions to bump to 3.0
 (some of them are already there in relationship with Maven 3 minimum).


 And for all things which have problem we could make a branch from the
 latest releases and fix it there...


 Kind regards
 Karl Heinz Marbaise
 On 12/24/14 2:20 PM, Kristian Rosenvold wrote:

 Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven
 plugins. We need to upgrade to 1.6; I'm taking this to the mailing list :)



 This 3.0.X has a 1.5 java requirement.  The problem is that *everyone*
 is moving to 1.6 and it's getting increasingly hard to maintain a 1.5
 code base. As an example, I have been moving code to apache commons,
 but we're basically unable to use this effort because commons is now
 1.6. alternately I need to backport the code in a
 source-level-shading, but these things are getting silly.

 I propose the following:

 Make the 3.x line of plugins java 1.6+ only.
 Release all shared utilities in 1.6 versions in the 3.x version range.
 3.0.X maven versions stay forever on the 2.x line of plugins and jdk
 1.5.
 The most recent core version moves defaults to the 3.x range of plugins.
 The parent poms migrate to 3.x range some time in the near future.

 Keeping 3.0.x fixes to a minuimum (and critical stuff) only, will
 ensure that we can still stay 1.5 compatible here.


 Kristian

 2014-12-24 13:52 GMT+01:00 Benson Margulies bimargul...@gmail.com:

 I don't have access to push a plexus-archiver release, could you
 please do the honors.

 Also, looks like my splitting job left some work behind in terms of
 the parent pom.



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

Re: [VOTE] Run-off for mascot's name

[Andreas Gudian]

H, H, or otherwise H.


Am Dienstag, 9. Dezember 2014 schrieb Stephen Connolly :

 This is a run-off vote to select the top two options for our new mascot's
 name.

 The entries with the highest number of votes will be selected for the final
 round. If there is only one entry with the highest number of votes then the
 entries with the second highest number of votes will also be included in
 the final round.

 The vote will be open for 72 hours.

 The entries are as follows:

 A. Abraham
 B. Boo
 C. Darth Mowl
 D. Jacob
 E. Kaboom
 F. Moses
 G. Rap
 H. Shotgun
 K. The Maven Owl
 L. Ty

 It is not clear whether all of the above suggestions were completely
 serious, but I have included them anyway for this first round.

 Please respond with at most your top three in order of preference. I may
 not use second or third preferences if we get a sufficient number of votes,
 but in the case of a small poll the additional preferences will help.

 In the event of repeated votes from an individual, only the last cast vote
 as determined by me will count.

 Any other discussion should happen in a separate thread.

 Thanks

 -Stephen

Re: [VOTE] Change project logo and adopt owl as mascot

[Andreas Gudian]

+1

Am Dienstag, 25. November 2014 schrieb Stephen Connolly :

 For anyone who has been living under a rock, here is the background

 Background
 =

 I think everyone can agree that the site needs a reorganisation and a
 rewrite. Users cannot find what they need, and the end result is that
 people keep on abusing maven rather than having maven help them.

 Try as I might, I have been unable to motivate myself to do the
 reorganisation with the current dated look and feel of the site... I am not
 saying that picking a new logo and selecting a mascot will result in making
 progress, but it can't hurt and I believe it will help

 Proposed changes
 ===

 1. Change the logo font to Alte Haas Grotesk Bold with italics applied by
 Inkscape
 2. Change the highlighted letter from 'a' to 'v' and replace the v with two
 Apache Feathers
 3. Adopt the (currently unnamed) owl as our mascot

 Here is a link to the font:

 http://www.dafont.com/alte-haas-grotesk.font

 Here is a large version of the owl and the logo:


 http://people.apache.org/~stephenc/maven-logo-contest/maven-owl-final-large.png

 A regular version of the own and the logo, e.g. a size suitable for use in
 the top of the standard maven sites:

 http://people.apache.org/~stephenc/maven-logo-contest/maven-owl-final.png

 (Note that in all likelihood, the mascot would probably end up on the other
 side of the title bar from the logo... and that is IF the mascot ends up on
 the title bar)

 Here is both of those rendered in a site (as it can be helpful to see the
 graphics adjacent to text)


 http://people.apache.org/~stephenc/maven-logo-contest/maven-owl-final-context.png


 Logo Rational
 ===

 If we do some searches for the Maven logo:


 https://www.google.com/search?site=imghptbm=ischq=maven+logooq=maven+logo


 http://www.bing.com/images/search?q=maven+logogo=Submitqs=nform=QBLHscope=imagespq=maven+logo

 Our current logo, with a single highlighted letter stands out quite well
 from the other maven logos, so keeping a highlighted letter and an italic
 rendered font maintains continuity with our current logo.

 By changing the highlighted letter to the `v` and by using two Apache
 feathers to create the `v`, we connect our logo back to Apache... we are
 Apache Maven after all.

 The `v` is also the common short term for version (e.g.v3 is short for
 version 3). Apache Maven puts a lot of emphasis on versions of dependencies
 and plugins... you could say that versions are very important to Maven.

 The colours of the feather were changed to solid colours to match the owl
 mascot's scarf, beak and eyebrows

 Voting rules
 =

 Anyone who is subscribed to the dev or users list is eligible to vote.

 If you vote multiple times, only your final vote will be counted.

 The vote will be open until 1:00pm GMT on Wed 3rd Dec 2014

 The vote is for all three changes as one single change. Partial votes (e.g.
 for the logo but not the mascot, or vice-versa) will not be counted.

 I, as the caller of the vote, reserve the right to cancel the vote if this
 vote is putting the harmony of the community at risk.

 If a majority of the PMC believe that this vote is putting the harmony of
 the community at risk, then the PMC may cancel this vote (though if even a
 small minority of the PMC were of that belief, I will more than likely have
 cancelled the vote before the PMC would need to decide... I'm just stating
 this FTR)

 The decision will be a simple majority, there will be no special veto
 powers.

 +1: [ ] Change the logo to the proposed logo and adopt the owl as project
 mascot
 0: [ ] No opinion
 -1: [ ] No change

 Please only respond with +1, 0 or -1. If you want to discuss the proposed
 changes please use a different thread. This thread is for voting only.

 -Stephen

Re: [DISCUSS] In the event of adopting the owl as project mascot, what will we call it?

[Andreas Gudian]

I suggest Darth Mowl. But not seriously ;-).


Am Dienstag, 25. November 2014 schrieb Stephen Connolly :


 http://people.apache.org/~stephenc/maven-logo-contest/maven-owl-final-large.png

 When I created this owl, I gave it the name Couché Tard which is a french
 nickname for an owl (literal translation: Sleeps Late)

 Early versions of this owl have ended up with the nickname Shotgun Owl
 due to the belly feathers being white in the initial versions, which some
 people thought made it look like it had been shot.

 Some people feel that we shouldn't name a mascot...

 As creator of the graphic, I could force the issue... but I would much
 rather if the community has a name that the community wants.

 Please provide your suggestions in this thread. If the owl is adopted as a
 mascot, we will have a second vote thread to confirm its name.

 I personally recommend a gender neutral name.

Re: New logo?

[Andreas Gudian]

I like it. Cute but resolute birdy, and the font looks fresh and modern.

But wait - did someone shoot a hole right through the owl? You can even see
the shadow behind it. ;-) Maybe the patch in the middle could be a little
darker, perhaps with a hint/tint of the surrounding colour?


2014-11-19 18:19 GMT+01:00 Arnaud Héritier aherit...@gmail.com:

 I love. Thx a lot for this new contribution !

 On Wed, Nov 19, 2014 at 6:15 PM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

  I know this kind of fell to the floor...
 
  So here's an attempt at a reboot.
 
  A Maven is an expert or connoisseur
 
  The couché tard is considered to be a wise creature... perhaps it sleeps
  in while downloading the interwebs... you should not ignore their cute
  looks either, if crossed they may bite and leave you in pain...
 
  So without further delay I present a suggestion for our mascot and a
  refreshed logo
 
  http://people.apache.org/~stephenc/maven-logo-contest/maven-owl.png
 
  Using the Alte Haas Grotesk Bold font with italic applied from inkscape
  logo. The middle v is changed to the red of the mascot.
 
 
 
  On 16 December 2013 22:35, Stephen Connolly 
  stephen.alan.conno...@gmail.com wrote:
 
  I have been playing with reworking our front page...[image: Inline
  images 1]
 
  I think the fluido skin is a big improvement, I would like to switch to
  that...
 
  Only problem I see is that our current logo(s) are very tied to the old
  look and feel...
 
  So do we want to see about launching a logo competition. TomEE had good
  success with theirs.
 
  Also I'm looking at going with the top-menu version of fluido skin
 rather
  than the left menu... I have a solution to the hidden nature... but
  you'll just have to wait until I sync up with Hervé to find a way to
 get it
  pushed to staging from a branch without blowing up the production site
 to
  see my trickery!
 
  -Stephen
 
 
 


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

Re: Surefire plugin - external streamed test name source

[Andreas Gudian]

Hi Marek,

interesting... For Surefire 3.0 we have some stuff in mind to allow users
hooking in the surefire logic at several points, one of them being the
determination of tests to run and their execution order. I didn't think
about that particular case of yours, yet. But good to know.

As for the Junit4 Provider... well that's strange. It's not supposed to
eagerly load all the lazy tests, as it disrupts the way forkCount1 with
reuseForks=true is distributing the load among the forks. So: if what you
describe is really the case, then I'd say it's a bug. Could you open up a
Jira issue for it? [1]

Thanks,
Andreas

[1] Jira: https://jira.codehaus.org/browse/SUREFIRE


2014-11-08 1:32 GMT+01:00 Marek Piechut marek.piec...@gmail.com:

 I’ve got it somewhat working by extending TestsToRun with my
 implementation.
 Everything is fine, except that surefire loads all test classes before
 launching any test just to create test description.
 (It’s a JUnit4Provider that’s doing it).

 Do you think it’s safe to omit creation of test description if
 TestsToRun.allowEagerReading method returns false?

  On 07 Nov 2014, at 22:00, Marek Piechut marek.piec...@gmail.com wrote:
 
  Hi.
 
  I’m trying to modify surefire plugin to make it lazily receive tests
 from another host.
  I’ve done a quick look at surefire plugin code and it looks that it
 could be done by some variation around LazyTestsToRun.
  Later on I’ve also found TestProvidingInputStream that also looks useful.
 
  Do you have any hint what’s the best way to achieve what I’m trying to
 do?
  Any test I can take a look to get better understanding how to do this?
 
  Exact use case below if you have time :)
 
  At my company we have a quite big integration test suite and a Jenkins
 cluster that’s launching them.
  We divide all tests to few categories and run each category on separate
 node.
 
  What I’ve noticed is that we often have these categories unbalanced (one
 machine needs much more time to launch it’s portion of tests while rest is
 waiting before whole suite can be finished). From time to time we go trough
 these categories and balance them again. Right now it takes around 2 hours
 to run all tests.
 
  What I’ve wanted to do is to keep list of tests to run on Jenkins master
 and make slaves ask for each test after it finishes previous (using some
 simple script that would be sending test class name to client over socket
 after request and remove it from list, so another slave gets another test).
 This way our suite would be self balancing and would not need any manual
 reconfiguration.
 
  Thanks,
  Marek.


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

[ANN] Apache Maven Surefire Plugin 2.18 Released

[Andreas Gudian]

The Apache Maven team is pleased to announce the release of the Apache
Maven Surefire Plugin, version 2.18

The release contains a number of bug fixes, and introduces an option to
automatically rerun failing tests, including proper reporting on the
console and in the XML reports for the individual runs.
Again we received some much appreciated contributions from the community in
form of bug reports, bug fixes and patches for new features. Thank you and
keep 'em coming!

You should specify the version in your project's plugin configuration:

plugin
  groupIdorg.apache.maven.
plugins/groupId
  artifactIdmaven-surefire-plugin/artifactId
  version2.18/version
/plugin

or for failsafe:

plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-failsafe-plugin/artifactId
  version2.18/version
/plugin

Release Notes - Maven Surefire - Version 2.18

** Bug
* [SUREFIRE-649] - Might be impossible to have empty strings in
systemPropertyVariables element
* [SUREFIRE-941] - TESTS header printed twice when forkMode is always
* [SUREFIRE-963] - Unable to set empty environment variables
* [SUREFIRE-1023] - Report generation fails with
StringIndexOutOfBoundsException
* [SUREFIRE-1028] - Unable to run single test (junit)
* [SUREFIRE-1069] - Typo in alwaysGenerateSurefireReport doc:
Defaulyts
* [SUREFIRE-1072] - Duplicate example of commandline in run single test
documentation
* [SUREFIRE-1075] - Addresses to documented mailing lists in Maven site
dead
* [SUREFIRE-1077] - NPE problem will happen if you set testng status to
fail at afterInvocation method
* [SUREFIRE-1078] - Failure running forked mode with TestNG test suites
defined via XML files
* [SUREFIRE-1080] - Use parallel and fork together run some tests
multiple times
* [SUREFIRE-1081] - Doc claims parallel is TestNG only, but rest of doc
implies junit works, too.
* [SUREFIRE-1088] - When test fail during initialization the test
execution time can result in a large negative number.
* [SUREFIRE-1090] - NPE in SmartStacktraceParser if
Thread.contextCassLoader is null
* [SUREFIRE-1091] - IOException when test with much output prints in
@After / @AfterClass - possible haning processes
* [SUREFIRE-1092] - The shutdown hook of parallel computer randomly
prints started tests after timeout overflow
* [SUREFIRE-1095] - NPE in RunListener
* [SUREFIRE-1096] - ClassCastException: Fork test for TestNG with
xmlsuite
* [SUREFIRE-1098] - runOrder=balanced is not working
* [SUREFIRE-1099] - Invalid link ids in surefire-report
* [SUREFIRE-1102] - The module surefire-setup-integration-tests fails
with Maven 3.2.3
* [SUREFIRE-1104] - Internal Maven Surefire IT tests fail with Maven
3.2.x

** Improvement
* [SUREFIRE-1053] - Suppress warning message if file.encoding is set
using argLine
* [SUREFIRE-1097] - improve documentation includes/excludes
* [SUREFIRE-1101] - Surefire does not shutdown thread-pools
programatically after test run has finished.
* [SUREFIRE-1105] - Surefire build should check Java 1.5 API signatures
with JDK version  5
* [SUREFIRE-1106] - Update to minimum maven 2.2.1
* [SUREFIRE-1108] - Surefire should print parallel tests in progress
been stopped after elapsed timeout

** New Feature
* [SUREFIRE-654] - TestNG: Recognize successful tests when using
invocationCount and successPercentage parameters on the @Test annotation
* [SUREFIRE-1087] - New option rerunFailingTestsCount
* [SUREFIRE-1093] - Exceptional parallel execution on @NotThreadSafe
testcase or suite


Enjoy,

-The Apache Maven team

Re: Stance on patch releases

[Andreas Gudian]

I would just respin the release with version 3.3. With Subversion it's not
that big a deal to delete a tag (with a proper comment) and recreate it for
the re-spin.
With git it would be a big no-no to replace an already pushed tag, that's
why I create the final tag only after the vote completed and use tags
ending with *-vote_1 etc instead for the time of the vote.
I remember there were some lengthy discussions about that a year ago or
so...


2014-11-08 13:15 GMT+01:00 Mirko Friedenhagen mfriedenha...@gmail.com:

 Hello,

 now that I canceled the vote on maven-pmd-plugin 3.3 should I go for 3.3.1
 or _delete_ and _reuse_ the tag. Or may the release responsible decide this
 on his own? I am always in favor of creating a new tag.

 Regards
 Mirko
 --
 Sent from my mobile

Re: [VOTE] Release Maven Surefire Plugin version 2.18 - Take 2

[Andreas Gudian]

Am Dienstag, 4. November 2014 schrieb Kristian Rosenvold :

 +1

 Although I *strongly* dislike the extra whitespace that has appeared
 out of nowhere in 2.18:

 Results :





 Tests run: 60, Failures: 0, Errors: 0, Skipped: 0


I knew there was something looking funny about that. I'll create a Jira
issue and fix it for the next version.




 Kristian


 2014-11-03 23:12 GMT+01:00 Hervé BOUTEMY herve.bout...@free.fr
 javascript:;:
  +1
 
  Regards,
 
  Hervé
 
  Le samedi 1 novembre 2014 20:59:10 Andreas Gudian a écrit :
  Hi,
 
 
  We solved 31 issues:
 
 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541version=20
  175
 
  There are still lots of issues left in JIRA:
 
 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidejql
 
 Query=project+%3D+SUREFIRE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DE
  SC
 
  Staging repo:
  https://repository.apache.org/content/repositories/maven-1090
 
 https://repository.apache.org/service/local/repositories/maven-1090/content/
  org/apache/maven/surefire/surefire/2.18/surefire-2.18-source-release.zip
 
  Source release checksum(s):
  surefire-2.18-source-release.zip sha1:
  807095a8efb4b531bc64cfc90978a2462250c4fa
 
  Source: https://git-wip-us.apache.org/repos/asf/maven-surefire.git tag
  surefire-2.18_vote-2
 
  Staging site:
 
 http://maven.apache.org/surefire-archives/surefire-2.18/maven-surefire-plugi
  n/index.html
 
 http://maven.apache.org/surefire-archives/surefire-2.18/maven-failsafe-plug
  in/index.html
 
 http://maven.apache.org/surefire-archives/surefire-2.18/maven-surefire-repo
  rt-plugin/index.html
 
  Guide to testing staged releases:
  http://maven.apache.org/guides/development/guide-testing-releases.html
 
  Vote open for 72 hours.
 
  [ ] +1
  [ ] +0
  [ ] -1
 
  Thanks!
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:;
  For additional commands, e-mail: dev-h...@maven.apache.org
 javascript:;
 

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

[RESULT] [VOTE] Release Maven Surefire Plugin version 2.18 - Take 2

[Andreas Gudian]

Hi,

The vote has passed with the following result:

+1 (binding):
Karl Heinz Marbaise, Hervé Boutemy, Kristian Rosenvold

+1 (non binding):
Tibor Digana, Andreas Gudian

I will promote the artifacts to the central repo.


Could on of the PMC members please copy the source release to the dist area
and note the release for the board report?

Thanks,
Andreas


2014-11-04 16:53 GMT+01:00 Andreas Gudian andreas.gud...@gmail.com:

 Am Dienstag, 4. November 2014 schrieb Kristian Rosenvold :

 +1

 Although I *strongly* dislike the extra whitespace that has appeared
 out of nowhere in 2.18:

 Results :





 Tests run: 60, Failures: 0, Errors: 0, Skipped: 0


 I knew there was something looking funny about that. I'll create a Jira
 issue and fix it for the next version.




 Kristian


 2014-11-03 23:12 GMT+01:00 Hervé BOUTEMY herve.bout...@free.fr:
  +1
 
  Regards,
 
  Hervé
 
  Le samedi 1 novembre 2014 20:59:10 Andreas Gudian a écrit :
  Hi,
 
 
  We solved 31 issues:
 
 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541version=20
  175
 
  There are still lots of issues left in JIRA:
 
 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidejql
 
 Query=project+%3D+SUREFIRE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DE
  SC
 
  Staging repo:
  https://repository.apache.org/content/repositories/maven-1090
 
 https://repository.apache.org/service/local/repositories/maven-1090/content/
 
 org/apache/maven/surefire/surefire/2.18/surefire-2.18-source-release.zip
 
  Source release checksum(s):
  surefire-2.18-source-release.zip sha1:
  807095a8efb4b531bc64cfc90978a2462250c4fa
 
  Source: https://git-wip-us.apache.org/repos/asf/maven-surefire.git tag
  surefire-2.18_vote-2
 
  Staging site:
 
 http://maven.apache.org/surefire-archives/surefire-2.18/maven-surefire-plugi
  n/index.html
 
 http://maven.apache.org/surefire-archives/surefire-2.18/maven-failsafe-plug
  in/index.html
 
 http://maven.apache.org/surefire-archives/surefire-2.18/maven-surefire-repo
  rt-plugin/index.html
 
  Guide to testing staged releases:
  http://maven.apache.org/guides/development/guide-testing-releases.html
 
  Vote open for 72 hours.
 
  [ ] +1
  [ ] +0
  [ ] -1
 
  Thanks!
 
 
  -
  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 Maven Surefire Plugin version 2.18 - Take 2

[Andreas Gudian]

My own +1.


Am Sonntag, 2. November 2014 schrieb Karl Heinz Marbaise :

 Hi,

 first to say trying to build surefire with Maven 2.2.1 will fail with a
 circular dependency...problem (as Kristian mentioned)...so best would be to
 require such things not by a README better by prerequisites/enforcer ...

 Apart from the README.txt is intended for developers of Surefire and not
 for users of surefire...cause they will on the web site and see Maven 2.2.1
 / JDK 1.4 The don't take a look into the release-source package

 The requirement for some plugins at the momment: Maven 3.X
 (maven-shade-plugin, maven-scm-publish-plugin)...is not a problem but the
 compatibility for run-time...Maven 2.2.1 minimum

 The majority of the plugins will currently being lifted to Maven 2.2.1
 minimum which implies Java 1.5 ...which for example for surefire it not the
 case JDK 1.4...at the moment...

 See here:

 https://builds.apache.org/job/dist-tool-plugin/site/dist-
 tool-prerequisites.html


 The next level will be Maven 3.0.5 minimum and number the plugins
 accordingly like 3.0 as already mentioned...to have a clear line for
 users...(Maven Site Plugin already does so...)...

 Karl Heinz


 On 11/2/14 6:42 PM, Kristian Rosenvold wrote:

 For the record, maven2 does not have precise enough dependency
 resolution to handle the somewhat crazy hoops we jump through to test
 surefire with surefire itself. So although we're still 2.2.1
 compatible, we've required 3.x to build for some time.

 Kristian


 2014-11-02 18:18 GMT+01:00 tibor17 tibo...@lycos.com:

 Karl, the README.txt will force the users to prepare for Maven 3.
 IMHO the SUREFIRE 3.0 would completely switch to Maven 3.
 Then we can use prerequisites with enforcer declaring the same min
 version
 of Maven dist.
 We will have chance to use Java Generics instead of using
 java.lang.Object
 in public API, remove jdk-1.3 and 1.4 profiles, declare surefire|failsafe
 property prefixes, use JDK 6 and Java 1.6 API, and break the backwards
 compatibility.

 The Java 6 is not maintained by the Oracle. It would be nice to see the
 Maven running on the top of Java 8 in the near future. I am not sure if
 we
 would have any bigger benefits from JDK 7 except for NIO and GC
 improvements.



 -
 BR, tibor17
 --


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

Re: [VOTE] Release Maven Surefire Plugin version 2.18

[Andreas Gudian]

Looks like this source-zip can't be built due to the failing rat-check on
the generated DEPENDENCIES file as well.

I'm supposed to cancel the vote now, right? I would do a respin with an
exclusion for that file in the rat-config.

What about the other votes in progress?



2014-10-31 20:10 GMT+01:00 Michael Osipov micha...@apache.org:

 Am 2014-10-31 um 09:17 schrieb Hervé BOUTEMY:

 thank you for the feedback

 looks like you found issues for MPIR:

 1. enhancement, to list only direct modules, not modules of modules


 MPIR-279.






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

[CANCELLED][VOTE] Release Maven Surefire Plugin version 2.18

[Andreas Gudian]

Vote cancelled, as the source-zip can't be built due to the failing
rat-check on the DEPENDENCIES file.

I'll start respinning the release and put up a new vote later tonight.

Andreas



2014-11-01 19:08 GMT+01:00 Karl Heinz Marbaise khmarba...@gmx.de:

 Hi Andreas,

 I have canceled the vote for Maven JXR based on this problem...

 Filed in an issue https://issues.apache.org/jira/browse/RAT-184


 Kind regards
 Karl Heinz Marbaise


 On 11/1/14 7:05 PM, Andreas Gudian wrote:

 Looks like this source-zip can't be built due to the failing rat-check on
 the generated DEPENDENCIES file as well.

 I'm supposed to cancel the vote now, right? I would do a respin with an
 exclusion for that file in the rat-config.

 What about the other votes in progress?



 2014-10-31 20:10 GMT+01:00 Michael Osipov micha...@apache.org:

  Am 2014-10-31 um 09:17 schrieb Hervé BOUTEMY:

  thank you for the feedback

 looks like you found issues for MPIR:

 1. enhancement, to list only direct modules, not modules of modules


 MPIR-279.


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

[VOTE] Release Maven Surefire Plugin version 2.18 - Take 2

[Andreas Gudian]

Hi,


We solved 31 issues:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541version=20175

There are still lots of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidejqlQuery=project+%3D+SUREFIRE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-1090
https://repository.apache.org/service/local/repositories/maven-1090/content/org/apache/maven/surefire/surefire/2.18/surefire-2.18-source-release.zip

Source release checksum(s):
surefire-2.18-source-release.zip sha1:
807095a8efb4b531bc64cfc90978a2462250c4fa

Source: https://git-wip-us.apache.org/repos/asf/maven-surefire.git tag
surefire-2.18_vote-2

Staging site:
http://maven.apache.org/surefire-archives/surefire-2.18/maven-surefire-plugin/index.html
http://maven.apache.org/surefire-archives/surefire-2.18/maven-failsafe-plugin/index.html
http://maven.apache.org/surefire-archives/surefire-2.18/maven-surefire-report-plugin/index.html

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

Vote open for 72 hours.

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

Thanks!

Re: [VOTE] Release Apache Maven JXR version 2.5

[Andreas Gudian]

Hmm, I would find it a bit embarrassing to release a source zip that I know
does not build without either deleting a file or skipping the rat-check,
which, as of only recently, is otherwise part of the build. That was not
the case for the previous releases... :-/



Am Sonntag, 2. November 2014 schrieb Kristian Rosenvold :

 Personally I think the canceling of this vote is on the boundary of
 absolute silliness. We have been releasing stuff with incorrect
 license headers for years, and we are working to improve it. As long
 as we are showing clear progress in the proper direction, I find this
 process utterly wasteful.

 Kristian


 2014-11-01 16:56 GMT+01:00 Robert Scholte rfscho...@apache.org
 javascript:;:
  Hi Karl-Heinz,
 
  my compliments for taking the responsibility as release manager to cancel
  this vote, even when there were enough binding votes.
 
  best,
  Robert
 
  Op Sat, 01 Nov 2014 16:41:05 +0100 schreef Karl Heinz Marbaise
  khmarba...@gmx.de javascript:;:
 
 
  I will cancel this vote based on the problem with DEPENDENCIES file in
  relationship with apache-rat-plugin which would result in a release
 which
  couldn't be built without touching configuration which couldn't be the
 right
  way...
 
 
  Kind regards
  Karl Heinz Marbaise
 
  On 10/26/14 11:15 PM, Karl Heinz Marbaise wrote:
 
  Hi,
 
  We solved 10 issues:
 
 
 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11085version=19853
 
 
  There are still a couple of issues left in JIRA:
 
 
 http://jira.codehaus.org/issues/?jql=project%20%3D%20JXR%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
 
 
  Staging repo:
  https://repository.apache.org/content/repositories/maven-1087
 
 
 
 http://repository.apache.org/content/repositories/maven-1087/org/apache/maven/jxr/jxr/2.5/jxr-2.5-source-release.zip
 
 
  Source release checksum(s):
  jxr-source-release.zip sha1: a6b1658404b8d2362641b2a8279c545d13c9ef88
 
  Staging site:
  http://maven.apache.org/jxr-archives/jxr-LATEST/
 
  Guide to testing staged releases:
  http://maven.apache.org/guides/development/guide-testing-releases.html
 
  Vote open for 72 hours.
 
  [ ] +1
  [ ] +0
  [ ] -1
 
  Kind regards
  Karl Heinz Marbaise
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:;
  For additional commands, e-mail: dev-h...@maven.apache.org
 javascript:;
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:;
  For additional commands, e-mail: dev-h...@maven.apache.org
 javascript:;
 

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