Re: Loging api in JSR-330 component

[Mark Struberg]

 +1Technically from a pure ClassLoader point our very own makes more sense.We 
can probably think about Lambda to resolve the String lazily.Insofar the SLF4J 
api is outdated as well.
And of course internally we might still route to slf4j. But we should not 
expose those classes to the plugins if not necessary. They just unnecessarily 
create classpatch clashes some times (been there done that).

LieGrue,strub

On Saturday, 23 January 2021, 18:06:34 CET, Romain Manni-Bucau 
 wrote:  
 
 Hi Benjamin,

Guess it was unexpectedly deprecated, let's revert that on master.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le sam. 23 janv. 2021 à 17:58, Benjamin Marwell  a
écrit :

> Robert, that's deprecated! What to use instead? Or was it deprecated in
> error?
>
>
> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/java/org/apache/maven/plugin/logging/Log.java
>
>
>
>
>
>
> On Sat, 23 Jan 2021, 12:10 Robert Scholte,  wrote:
>
> > See
> >
> https://maven.apache.org/ref/3.6.3/maven-plugin-api/apidocs/org/apache/maven/plugin/AbstractMojo.html
> >
> > You can get the logger by calling getLog(), so don't inject the logger
> > here.
> >
> > Robert
> > On 22-1-2021 19:19:47, Slawomir Jaranowski 
> wrote:
> > It is not only an extension case.
> >
> > For example I can write Mojo like:
> >
> > @Mojo(name = "example")
> > public class ExampleMojo extends AbstractMojo {
> >
> > @Inject
> > private MyService myService;
> >
> > @Override
> > public void execute() {
> > }
> > }
> >
> > and
> >
> > @Named
> > public class MyService {
> >
> > @Inject
> > private Logger??? logger;
> > }
> >
> > So the question is what logger we should use in the component?
> >
> > Another case is that components can be Singleton and their instance will
> be
> > created once.
> >
> >
> > pt., 22 sty 2021 o 12:36 Romain Manni-Bucau
> > napisał(a):
> >
> > > Do it means if we represent our classloading structure, all loaders on
> > top
> > > of mojo use slf4j and others our maven abstraction.
> > > Sounds ok to me except for extensions which are not in maven land so
> > > subject to slf4j api breaking changes and undefined/ambiguous context -
> > > which is never true for maven code itself since we guarantee and own
> it.
> > > Should we promote the abstraction for extensions too?
> > >
> > > Le ven. 22 janv. 2021 à 11:41, Robert Scholte a
> > > écrit :
> > >
> > > > I'm not so sure about this, it probably depends on the context.
> > > >
> > > > I think we should assume that JSR330 component are not aware of their
> > > > context.
> > > > They should not require a Maven context, hence in such case it makes
> > > sense
> > > > to use SLF4J API, while the application selects the logger
> > > implementation.
> > > > Think of Maven Extensions. I'd say they should be using the SLF4J API
> > > > because their context is not bound to 1 plugin.
> > > >
> > > > thanks,
> > > > Robert
> > > > On 18-1-2021 09:34:01, Romain Manni-Bucau wrote:
> > > > Generally you want to propagate the mojo logger to have consistent
> logs
> > > but
> > > > worse case we should promote mojo logging api as injectable at
> > injection
> > > > points if needed, avoids all the mess you can get in mojo with
> loggers
> > to
> > > > respect that rule of dumb IMHO.
> > > >
> > > > Le dim. 17 janv. 2021 à 22:48, Slawomir Jaranowski
> > > > a écrit :
> > > >
> > > > > Hi,
> > > > >
> > > > > We can use the JSR-330 component for developing maven plugins -
> > > > > https://maven.apache.org/maven-jsr330.html
> > > > >
> > > > > There is not clear how to access logging api from JSR-330
> component.
> > > As I
> > > > > found out last time, maven plugins should not directly use
> slf4j-api,
> > > so
> > > > > what is recommended in this case.
> > > > >
> > > > > --
> > > > > Sławomir Jaranowski
> > > > >
> > > >
> > >
> >
> >
> > --
> > Sławomir Jaranowski
> >
>
  

Re: Loging api in JSR-330 component

[Mark Struberg]

 
    @Inject
    private Logger??? logger;
That would imo depend on the package of the Logger in the import. There could 
be producers for both our internal maven logging api and SLF4J. 

LieGrue,strub
On Friday, 22 January 2021, 19:19:47 CET, Slawomir Jaranowski 
 wrote:  
 
 It is not only an extension case.

For example I can write Mojo like:

@Mojo(name = "example")
public class ExampleMojo extends AbstractMojo {

    @Inject
    private MyService myService;

    @Override
    public void execute() {
    }
}

and

@Named
public class MyService {

    @Inject
    private Logger??? logger;
}

So the question is what logger we should use in the component?

Another case is that components can be Singleton and their instance will be
created once.


pt., 22 sty 2021 o 12:36 Romain Manni-Bucau 
napisał(a):

> Do it means if we represent our classloading structure, all loaders on top
> of mojo use slf4j and others our maven abstraction.
> Sounds ok to me except for extensions which are not in maven land so
> subject to slf4j api breaking changes and undefined/ambiguous context -
> which is never true for maven code itself since we guarantee and own it.
> Should we promote the abstraction for extensions too?
>
> Le ven. 22 janv. 2021 à 11:41, Robert Scholte  a
> écrit :
>
> > I'm not so sure about this, it probably depends on the context.
> >
> > I think we should assume that JSR330 component are not aware of their
> > context.
> > They should not require a Maven context, hence in such case it makes
> sense
> > to use SLF4J API, while the application selects the logger
> implementation.
> > Think of Maven Extensions. I'd say they should be using the SLF4J API
> > because their context is not bound to 1 plugin.
> >
> > thanks,
> > Robert
> > On 18-1-2021 09:34:01, Romain Manni-Bucau  wrote:
> > Generally you want to propagate the mojo logger to have consistent logs
> but
> > worse case we should promote mojo logging api as injectable at injection
> > points if needed, avoids all the mess you can get in mojo with loggers to
> > respect that rule of dumb IMHO.
> >
> > Le dim. 17 janv. 2021 à 22:48, Slawomir Jaranowski
> > a écrit :
> >
> > > Hi,
> > >
> > > We can use the JSR-330 component for developing maven plugins -
> > > https://maven.apache.org/maven-jsr330.html
> > >
> > > There is not clear how to access logging api from JSR-330 component.
> As I
> > > found out last time, maven plugins should not directly use slf4j-api,
> so
> > > what is recommended in this case.
> > >
> > > --
> > > Sławomir Jaranowski
> > >
> >
>


-- 
Sławomir Jaranowski
  

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

[Mark Struberg]

 +1
LieGrue,strub

On Sunday, 24 January 2021, 00:02:35 CET, Sylwester Lachiewicz 
 wrote:  
 
 Hi,

We solved 5 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317223=12347024=Text

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

Staging repo:
https://repository.apache.org/content/repositories/maven-1624/
https://repository.apache.org/content/repositories/maven-1624/org/apache/maven/plugins/maven-checkstyle-plugin/3.1.2/maven-checkstyle-plugin-3.1.2-source-release.zip

Source release checksum(s):
maven-checkstyle-plugin-3.1.2-source-release.zip sha512:
4d90277a306390ec5a6434e01631295654fc4c45c1a4a0b5fae6c7c000a40e8357667fa943d05ddb55d1d742eae7628f371e4aba637941c538791bdd9ef39d08

Staging site:
https://maven.apache.org/plugins-archives/maven-checkstyle-plugin-LATEST/

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

Vote open for at least 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: cdi-api leaking?

[Mark Struberg]

+1 for dropping. Also already had problems with it.

LieGrue,
strub

> Am 01.12.2020 um 17:50 schrieb Romain Manni-Bucau :
> 
> Up,
> 
> Encountered a few bugs related to this regression, wonder how we want to
> tackle it.
> My 2cts would be to drop cdi-api and replace the single used
> annotation from there by a maven one.
> If we don't want to break plugins (not sure any use that) we can rewrite it
> with asm or equivalent at load time since we own the classloading.
> 
> Anyone having an opinion on that?
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 
> Le mar. 6 févr. 2018 à 18:02, Romain Manni-Bucau  a
> écrit :
> 
>> commented inline
>> 
>> 
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github
>>  | LinkedIn
>>  | Book
>> 
>> 
>> 2018-02-06 17:51 GMT+01:00 Stuart McCulloch :
>> 
>>> On Tuesday, 6 February 2018 at 13:25, Romain Manni-Bucau wrote:
 2018-02-06 12:25 GMT+01:00 Stuart McCulloch >> mccu...@gmail.com)>:
 
> The "javax.enterprise.inject" CDI package was explicitly exported as
>>> part
> of the ongoing effort to migrate legacy Plexus components onto more
>>> modern
> standard annotations.
> 
 
 
 Hmm, this looks wrong from my window cause Maven doesn't support CDI
>>> API -
 guice doesn't. So it is an interpretation of a well defined API which
>>> is by
 defintion a bad public API, no?
 
 
>>> 
>>> Raw Guice supports JSR330, but requires programmatic configuration (ie.
>>> bindings defined in modules)
>>> 
>>> Sisu builds on Guice to add support for things like annotation scanning
>>> and wiring, injectable collections that dynamically update as plugins come
>>> and go, property placeholders, etc.
>>> 
>>> If the CDI annotations are on the classpath then it also honours the
>>> @Typed annotation. This was a feature request to help migrate certain
>>> components from other Plexus-based applications over to JSR330 + @Typed. At
>>> the time there was a consideration that the rest of the CDI annotations
>>> would eventually be supported, as another compatibility layer.
>>> 
>>> Sisu also provides a Plexus compatibility layer that supports Plexus
>>> annotations and XML
>>> 
>>> Maven 3.x switched to Sisu so old Plexus-based components can still be
>>> used, while modern components can be written with JSR330. At the time of
>>> the switch it was decided to enable support for @Typed in Maven
>>> plugins/extensions (because there was a developer need for this feature,
>>> but that may well have changed and no longer be relevant).
>>> 
>>> So Maven currently honours using @Typed on components - if it’s decided
>>> that Maven doesn’t want to support @Typed in plugins then just remove the
>>> export and exclude the cdi-api jar. As mentioned previously support for
>>> @Typed is used by other downstream non-Maven applications so it will always
>>> be something the container supports, but it's totally optional so if you
>>> don’t want it then you don’t need to ship the cdi-api jar.
>>> 
>> 
>> Yes but having the full API for one class is luxury (see later comment for
>> the detail)
>> 
>> 
 
> 
> Specifically, the @javax.enterprise.inject.Typed annotation lets
> components state they are only visible for injection under a specific
>>> type,
> rather than any type in their hierarchy.
> 
> There’s no annotation to control binding visibility in JSR330,
>>> because it
> deliberately avoids configuration concerns, which is why we went with
>>> the
> closest standard annotation (@Typed from JSR299 aka CDI). While we
>>> could
> have decided to use our own annotation - and the container does in
>>> fact
> support using @org.eclipse.sisu.Typed - this is not standardised or
> portable. Also note the container will continue to support this
>>> (optional)
> feature for other downstream users, regardless of what’s decided here
>>> - the
> question is whether Maven still wants to use this feature and whether
>>> it
> wants to use the standard annotation or not.
> 
> Another point is that whichever annotation is chosen must be
> visible/defined from the same classloader to both core and plugins.
>>> If the
> annotation is not exported then core and each plugin will end up with
>>> a
> different @Typed class, defined by different classloaders. Any use of
> @Typed in plugins would then effectively be invisible to 

Re: DirectoryScanner, exclusions wins or loose over inclusions?

[Mark Struberg]

Don't we configure those patterns mostly directly in the poms?
Ditching our own DirectoryScanner would likely require a huge amount of 
existing projects to rewrite their config when they update some plugins. 
Don't think this is really worth it. Plus the Java7 directoryScanner is not 
really faster than our own impl, isn't?

LieGrue,
strub


> Am 09.06.2020 um 14:54 schrieb Romain Manni-Bucau :
> 
> Do you suggest to use java regex?
> Think it is very rare that mojo use that (even outside
> org.apache.maven.plugins) and each time it kind of hurts users so I hope we
> don't go that path. On the other side, never saw anyone complaining of ant
> regexes.
> Ant like syntax is way more friendly and natural IMHO and does not assume
> maven user is a Java expert nor a regex expert (this is actually rare you
> use them properly at this location, you likely don't escape it properly or
> have some headache with xml in some cases).
> I also don't think we can break all plugins out there using this piece of
> code so rewriting the impl with whatever newer API is ok if as fast but
> changing the config requires a wider discussion IMHO.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 
> Le mar. 9 juin 2020 à 14:46, Elliotte Rusty Harold  a
> écrit :
> 
>> On Tue, Jun 9, 2020 at 8:30 AM Romain Manni-Bucau 
>> wrote:
>>> 
>>> Wildcard support which is more user friendly (who would like to use java
>>> regex to configure that ;)).
>> 
>> Familiarity is user friendly. Standard Java regex that developers
>> already know and use beats a marginally simpler syntax they don't. I'd
>> rather stick to one well-documented wildcard syntax across multiple
>> projects than learn a new and slightly different one for each project.
>> Relying on developers to read and understand the details of a new
>> syntax is dangerous. That's even assuming it's fully and correctly
>> documented and implemented in the first place, which might not be the
>> case here.
>> 
>> 
>> 
>> --
>> Elliotte Rusty Harold
>> elh...@ibiblio.org
>> 
>> -
>> 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 Shade Plugin version 3.2.2

[Mark Struberg]

+1

Thanks Hervé, was on my list for the next weeks as well ;)

LieGrue,
strub
 

> Am 09.02.2020 um 10:24 schrieb Hervé BOUTEMY :
> 
> Hi,
> 
> We solved 28 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=1230=Text
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1550/
> https://repository.apache.org/content/repositories/maven-1550/org/apache/maven/plugins/maven-shade-plugin/3.2.2/maven-shade-plugin-3.2.2-source-release.zip
> 
> Source release checksum(s):
> maven-shade-plugin-3.2.2-source-release.zip sha512: 
> c9ecdf2003c5c983005e62ad4f0bcae408c25583496d32fc7c7912ba34060048f541cea135c3d308146f39c0cb17795124cf9e1d50f42373c9456f47d2d61830
> 
> Staging site:
> https://maven.apache.org/plugins-archives/maven-shade-plugin-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for at least 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


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

Re: [maven-shade-plugin] 3.2.2 status and open PRs

[Mark Struberg]

I'll try to give it a look over the weekend.

LieGrue,
strub


> Am 16.01.2020 um 23:31 schrieb Falko Modler :
> 
> Hi Karl Heinz,
> 
> thanks for this clarification.
> 
> So now there is only one last ticket left for 3.2.2 and the PR for it
> looks good to be merged:
> https://github.com/apache/maven-shade-plugin/pull/33
> https://issues.apache.org/jira/browse/MSHADE-339
> 
> Looking forward to 3.2.2.
> 
> Thank you very much!
> 
> Best regards,
> Falko
> 
> Am 04.01.2020 um 11:57 schrieb Karl Heinz Marbaise:
>> Hi,
>> 
>> On 03.01.20 17:11, Falko Modler wrote:
>>> Hi everyone,
>>> 
>>> it has been over a year since the last release 3.2.1 and two weeks ago
>>> there have been some activities to release 3.2.2 but it seems those
>>> commits were (partially) reverted.
>>> 
>>> See: https://github.com/apache/maven-shade-plugin/commits/master
>>> 
>>> I cannot see 3.2.2 on Maven Central either. Does anyone know the status?
>> 
>> Of course you don't see it on Maven Central, cause there had no VOTE
>> thread about the plugin which ended positive which in consequence means
>> no release announcement ...
>> 
>> There had come issues related to Javadoc etc. which I have fixed
>> afterwards...
>> 
>> 
>>> 
>>> I also do ask this because I've just created a PR which I'd love to see
>>> included in 3.2.2 or a near-term 3.2.3:
>>> https://github.com/apache/maven-shade-plugin/pull/35
>> 
>> Testing in CI...
>> 
>> Kind regards
>> Karl Heinz Marbaise
>>> 
>>> Apart from older PRs, there are two recent PRs created by other users
>>> for issues that are assigned to 3.2.2, but both are still open:
>>> 
>>> - https://issues.apache.org/jira/browse/MSHADE-340
>>> 
>>> - https://issues.apache.org/jira/browse/MSHADE-339
>>> 
>>> 
>>> Thanks for your attention/help!
>>> 
>>> 
>>> Best regards and happy 2020,
>>> 
>>> Falko Modler
>>> 
>> 
>> -
>> 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
> 


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

Re: [VOTE] Release Apache Parent POM version 22

[Mark Struberg]

+1

LieGrue,
strub


> Am 05.01.2020 um 18:45 schrieb Hervé BOUTEMY :
> 
> Hi,
> 
> We solved N issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250=12343925=Text
> 
> https://github.com/apache/maven-apache-parent/compare/apache-21...apache-22
> 
> Staging repo:
> https://repository.apache.org/content/repositories/orgapacheapache-1017/
> https://repository.apache.org/content/repositories/orgapacheapache-1017/org/apache/apache/22/apache-22-source-release.zip
> 
> Source release checksum(s):
> apache-22-source-release.zip sha512: 
> 180896d6ada20d029203791d594f657e3874730eaa6ebf5288325766728fee4bb55e1dc8666207ed9d88e735edfe1e3e660492d234d248f5202575edbeb5b7a9
> 
> Staging site:
> https://maven.apache.org/pom-archives/asf-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for at least 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


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

Re: Absolute and relative paths in plugins and descriptors

[Mark Struberg]

Yes, will go down this route. 

Fun side note: that warning was so far mostly applied to the outputDirectory 
part. But this is just the path INSIDE the zip. So most of the warnings have 
been pretty much useless ;)

Will continue to work on this. Probably we might also extract the path handling 
out into maven-shared-utils even. Let's see.

LieGrue,
strub


> Am 02.01.2020 um 11:33 schrieb Robert Scholte :
> 
> I'd prefer to switch to Path, and in this case use Path.resolve
> You should add that to the test.
> I agree that a path starting with "/" should be interpreted as an absolute 
> path, and AFAIK the warning is there already for ages so I don't mind 
> changing the behavior.
> 
> thanks,
> Robert
> On 1-1-2020 23:26:00, Mark Struberg  wrote:
> Hi lords and ladies!
> 
> I try to get my head around the ticket MASSEMBLY-775.
> It is related to MASSEMBLY-746 and MASSEMBLY-665.
> 
> The problem is basically that a reference to /somedirectory is interpreted as 
> absolute path on *nix and as relative path on Win*.
> 
> And sometimes we have code of the form
> 
> File destDir = new File(dest);
> if (! destDir.isAbsolute()) {
> destDir = new File(basedir destDir);
> }
> 
> And thus we treat e.g. /src/test/my.txt as relative to ${project.basedir} on 
> Windows but as an absolute path in OSX and Linux for example. But Maven 
> projects should by default be perfectly portable on different operating 
> systems.
> 
> It get's a bit more complicated when also taking mingw and cygwin into 
> consideration.
> 
> I wrote a tiny class and tested it on multiple systems.
> 
> public class Test {
> public static void main(String[] args) {
> java.lang.System.out.println("path: " + new 
> java.io.File(args[0]).getAbsolutePath());
> }
> }
> 
> Feeding /test as parameter gives the following values:
> OSX: /test
> Linux: /test
> Windows CMD: c:\test
> Windows mingw: c:\opt\GIT\test
> Windows Powershell: c\test
> 
> I don't have cygwin at hand. Anyone?
> 
> It looks like using / as detector for an absolute file *in addition* to 
> File#isAbsolute() would be the most porbable way to handle it?
> At least if we otherwise concat it to our basedir like we did in 
> maven-assembly-plugin.
> 
> Wdyt?
> 
> LieGrue,
> strub
> 
> 
> 
> -
> 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

Absolute and relative paths in plugins and descriptors

[Mark Struberg]

Hi lords and ladies!

I try to get my head around the ticket MASSEMBLY-775.
It is related to MASSEMBLY-746 and MASSEMBLY-665.

The problem is basically that a reference to /somedirectory is 
interpreted as absolute path on *nix and as relative path on Win*.

And sometimes we have code of the form

 File destDir = new File(dest);
 if (! destDir.isAbsolute()) {
   destDir = new File(basedir destDir); 
 }

And thus we treat e.g. /src/test/my.txt as relative to 
${project.basedir} on Windows but as an absolute path in OSX and Linux for 
example. But Maven projects should by default be perfectly portable on 
different operating systems.

It get's a bit more complicated when also taking mingw and cygwin into 
consideration.

I wrote a tiny class and tested it on multiple systems. 

public class Test {
   public static void main(String[] args) {
   java.lang.System.out.println("path: " + new 
java.io.File(args[0]).getAbsolutePath());
   }
}

Feeding /test as parameter gives the following values:
OSX: /test
Linux: /test
Windows CMD: c:\test
Windows mingw: c:\opt\GIT\test<- a bit unexpected tbh...
Windows Powershell: c\test

I don't have cygwin at hand. Anyone?

It looks like using / as detector for an absolute file *in addition* to 
File#isAbsolute() would be the most porbable way to handle it?
At least if we otherwise concat it to our basedir like we did in 
maven-assembly-plugin.

Wdyt?

LieGrue,
strub



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

Re: More checkstyle API changes

[Mark Struberg]

But the main purpose is not to have multiple frameworks run with it. That's the 
main difference to surefire.

The maven-checkstyle-plugin is rather pretty much hardcoded to a specific 
checkstyle version. While you _could_ technically exchange the checkstyle 
dependency it is not really intended.

The 'compatibility' layer is rather only important for the checkstyle 
configuration. That part should really remain stable. If not, we have to up to 
major version.

LieGrue,
strub


> Am 23.12.2019 um 12:34 schrieb Romain Manni-Bucau :
> 
> Point is it is the only way to not break end user since it gives us the
> control of which version to select depending user config and java version.
> Which we dont ask any change to user im fine either ways though.
> 
> Le lun. 23 déc. 2019 à 12:28, Benjamin Marwell  a
> écrit :
> 
>> I not think that would be a benefit, because removing the class loader call
>> will also work with older versions of checkstyle.
>> Also, of the plugin is just a wrapper, why even bother to detect if the
>> checkstyle.xml and checkstyle dependency will work together?
>> 
>> Or am I missing something?
>> 
>> On Mon, 23 Dec 2019, 09:32 Romain Manni-Bucau, 
>> wrote:
>> 
>>> What about loading checkstyle from a dependency resolver and use a custom
>>> classloader with an integration per version (a bit like surefire). It
>>> enables to use any version and even detect an user override in plugin
>> deps.
>>> 
>>> Le lun. 23 déc. 2019 à 09:27, Benjamin Marwell  a
>>> écrit :
>>> 
 Hi Enrico,
 
 that would mean a lot of incompatibilities which I wanted to avoid.
 If the checkstyle jar is updated first (8.xx), maven users wouldn't be
>>> able
 to use a current version for quite a while, because the Maven plugin
>>> would
 throw NoSuchMethodExceptions. I wanted to avoid this.
 
 On the other hand, if the Maven plugin gets updated and released first,
 there is more time for users to migrate to a more recent maven plugin.
 Hence my PR.
 
 I really do not see the benefit of updating the checkstyle jar first
>> and
 this having a period of time where Maven users cannot use a recent
>>> version
 of checkstyle at all.
 
 Maybe I did express the issue with checkstyle 8.24 in a wrong way.
>> Users
 can already use it if they rewrite their checkstyle.xml. it's just that
>>> the
 maven plugin should not update the default checkstyle version to not
>>> break
 any default setups and force users to rewrite their checks.
 
 
 
 
 On Mon, 23 Dec 2019, 08:45 Enrico Olivelli, 
>> wrote:
 
> Ben,
> What about having a release of checkstyle with all of the requested
 changes
> and then update maven plugin and then release it?
> Checkstyle maven plugin is just a wrapper over checkstyle library.
> 
> The best way would be that you (or anyone from Checkstyle) create a
>> PR
 when
> you are ready with the new release.
> 
> I will be happy to help you move forward with this change and cut a
 release
> 
> Cheers
> Enrico
> 
> Il lun 23 dic 2019, 07:21 Benjamin Marwell  ha
> scritto:
> 
>> Hi all,
>> 
>> The checkstyle team is waiting for my PR:
>> 
>> https://github.com/apache/maven-checkstyle-plugin/pull/18
>> 
>> The problem is, that they want to remove a method. If they do this
>>> too
>> early, maven users will not be able to update the checkstyle
>> version
>> anymore.
>> 
>> Also, the maven Checkstyle plugin cannot ship a Checkstyle version
 beyond
>> 8.23 because of breaking changes. There is also an issue for this.
>> 
>> This really needs some attention by someone with more
>> responsibility.
>> 
>> Please keep in mind that there is already a jira issue about the
>> 8.24
>> incompability. I commented that they should have made it a major
 version,
>> and maybe the checkstyle plugin will have to jump to a new major
 release
> at
>> some point?
>> 
>> Thanks for looking into this.
>> 
>> Ben
>> 
> 
 
>>> 
>> 


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

Re: relativePath for parent poms in our plugins

[Mark Struberg]

To be honest, I didn't even know that there is a 'main project' with tons of 
git-submodules to emulate our old maven master build.

I still wonder whether it has any benefit to have the relativePath in our 
plugins.
It is useful if you have a reactor build where maven then knows how to search 
for other dependencies and figures what other parts to build. But I do not 
really see this for multiple reasons:

* We don't have any snapshot but a fixed version of the parent maven-plugins:33 
(and other versions) in every plugin. That means they won't use the 'is-a' in 
aggregator-style anyway
* That means the parent pom is merely a 'build-pom' but not much more. I
* Even if we would upgrade every plugin to use the latest snapshot of our 
maven-plugins parent pom we would not add much. It would still build fine 
without having a relativePath section. And we would not gain much from keeping 
relativePath because we barely have dependencies between our plugins. 

Hervé, others did I overlook something?

And sorry for starting this discussion. It's totally unimportant if we keep it 
or not. I'm fine both ways, it just looked like something we missed to remove 
when we moved from the maven-plugins sparse tree in SVN over to single GIT 
repos for each and every single maven plugin.

LieGrue,
strub


> Am 21.12.2019 um 18:38 schrieb Romain Manni-Bucau :
> 
> Le sam. 21 déc. 2019 à 15:03, Hervé BOUTEMY  a
> écrit :
> 
>> how does the current relativePath work less than without it?
>> Does it really break anything more than just "people don't understand the
>> value" then consider it "wrong"?
>> 
> 
> Well, it is unlikely but it can break the build yes, at least if it exists.
> It is also not friendly for newcomers cause not obvious.
> 
> 
>> in addition, I know that intermittent Maven contributor will clone only
>> one
>> Git repository, but I personally work on every Maven Git repository on
>> many
>> computers: being able to clone and update everything easily is key to me
>> 
> 
> Not sure I see how it changes anything :s. Assume we drop it, then you can
> still do all that (it is top-down and not down-top afaik).
> 
> 
> 
>> Regards,
>> 
>> Hervé
>> 
>> Le samedi 21 décembre 2019, 14:29:17 CET Romain Manni-Bucau a écrit :
>>> Agree with Robert, git clone && mvn install must always work and be
>>> straight forward if we want people to be able to help/work imho.
>>> 
>>> Le sam. 21 déc. 2019 à 13:33, Robert Scholte  a
>>> 
>>> écrit :
>>>> that only works for the very, very few that uses this repository.
>>>> It should work as to how contributors work with it, otherwise you'll
>> see
>>>> other issues compared to them.
>>>> 
>>>> Robert
>>>> On 21-12-2019 12:33:53, Hervé BOUTEMY  wrote:
>>>> disagree
>>>> 
>>>> We have the repo configuration which brings a location for every Git
>>>> repository:
>>>> https://maven.apache.org/scm.html
>>>> or https://github.com/apache/maven-sources/
>>>> 
>>>> The relative paths are calculated against that.
>>>> And I recently even added aggregator poms to build absolutely
>> everything
>>>> in
>>>> one unique build
>>>> 
>>>> Regards,
>>>> 
>>>> Hervé
>>>> 
>>>> Le jeudi 19 décembre 2019, 12:13:56 CET Mark Struberg a écrit :
>>>>> Hi folks!
>>>>> 
>>>>> Looking at massembler right now I stumbled across a parentPom section
>>>>> 
>>>>> 
>>>>> maven-plugins
>>>>> org.apache.maven.plugins
>>>>> 33
>>>>> ../../pom/maven/maven-plugins/pom.xml
>>>>> 
>>>>> 
>>>>> This was perfectly fine when we had all in SVN under one big project.
>>>>> But nowadays - having all in GIT - I'd we should remove the
>>>>> relativePath,
>>>>> isn't?
>>>>> 
>>>>> LieGrue,
>>>>> strub
>>>>> 
>>>>> 
>>>>> -
>>>>> 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
>> 
>> 
>> 
>> 
>> 
>> -
>> 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 Source Plugin version 3.2.1

[Mark Struberg]

+1

LieGrue,
strub



> Am 16.12.2019 um 19:37 schrieb Hervé BOUTEMY :
> 
> Hi,
> 
> We solved 2 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317924=12346480=Text
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1545/
> https://repository.apache.org/content/repositories/maven-1545/org/apache/maven/plugins/maven-source-plugin/3.2.1/maven-source-plugin-3.2.1-source-release.zip
> 
> Source release checksum(s):
> maven-source-plugin-3.2.1-source-release.zip sha512: 
> 4d7252839cc74dae8100a47adadbe6fc2c8f4d57e930fa695e4e6c75a8571b1246a63aa25de0cf2d73601e599faea2a31be43b1fe442e36d463702d885ccf8b7
> 
> Staging site:
> https://maven.apache.org/plugins-archives/maven-source-plugin-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for at least 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


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

Re: [massembly] code question

[Mark Struberg]

Well, the project dependencies may or may not be used depending on your 
assembly setup.
The only data which is used in this scenario is List 
dependencySets;
So it might probably be fine to add a logging if the dependencySets is empty.

The only part where the project dependencies are really used is the 
RepositoryAssembler. And there is already a warning if it is empty:

https://github.com/apache/maven-assembly-plugin/blob/master/src/main/java/org/apache/maven/plugins/assembly/repository/DefaultRepositoryAssembler.java#L83


LieGrue,
strub


> Am 19.12.2019 um 15:59 schrieb Romain Manni-Bucau :
> 
> @Mark: likely studid but do you get the debug insight removing it on a
> project without dependencies?
> 
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
> 
> 
> Le jeu. 19 déc. 2019 à 14:39, Mark Struberg  a
> écrit :
> 
>> Hi!
>> 
>> Feeling a bit rusty, so I thought I better ask for a 2nd opinion.
>> 
>> To me it looks like the following code block is really obsolete and did
>> not make anything useful ever since
>> 
>> 
>> https://github.com/apache/maven-assembly-plugin/blob/master/src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java#L112
>> 
>>> final List deps = project.getDependencies();
>>> if ( ( deps == null ) || deps.isEmpty() )
>>> {
>>>logger.debug( "Project " + project.getId() + " has no dependencies.
>> Skipping dependency set addition." );
>>> }
>> 
>> 'deps' is never used. And it's just a logging.
>> Plus all ITs plus a big custom project still fully pass if I remove the
>> block.
>> 
>> Any reason not to remove it?
>> 
>> LieGrue,
>> strub
>> -
>> 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

[massembly] code question

[Mark Struberg]

Hi!

Feeling a bit rusty, so I thought I better ask for a 2nd opinion.

To me it looks like the following code block is really obsolete and did not 
make anything useful ever since

https://github.com/apache/maven-assembly-plugin/blob/master/src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java#L112

> final List deps = project.getDependencies();
> if ( ( deps == null ) || deps.isEmpty() )
> {
> logger.debug( "Project " + project.getId() + " has no dependencies. 
> Skipping dependency set addition." );
> }

'deps' is never used. And it's just a logging.
Plus all ITs plus a big custom project still fully pass if I remove the block.

Any reason not to remove it?

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

relativePath for parent poms in our plugins

[Mark Struberg]

Hi folks!

Looking at massembler right now I stumbled across a parentPom section


  maven-plugins
  org.apache.maven.plugins
  33
  ../../pom/maven/maven-plugins/pom.xml


This was perfectly fine when we had all in SVN under one big project.
But nowadays - having all in GIT - I'd we should remove the relativePath, isn't?

LieGrue,
strub


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

Re: Jenkins and Maven 3.0.5 or JDK 7

[Mark Struberg]

Hi folks!

Having dozen sub repos in GIT is still a PITA. 
Also git-submodules is still sub-optimal and at best a smallish helper.

For me personally there is one major decision point if it comes to deciding 
whether to hav one big repo or multiple smaller ones: the deliverable.

Is there exactly one deliverable (one 'maven' release), then it should be one 
repo.

Are there many deliverables whith separate lifecycle (like most plugins) then I 
normally do seperate repos.

If I have multiple repos then I usually do a manually maintained build pipeline 
against a FRESH repo!
This is important! You must _not_ have any snapshot of that version in your 
upstream maven repos.
Otherwise you effectively cannot detect whethere there are cycles between 
modules.
A -> B -> A. Works totally fine and compiles if a n-1 version SNAPSHOT of A and 
B is in the repository. But you will never be able to build it from scratch.

The question is whether the 'core' maven plugins (maven-clean-plugin, 
maven-plugin-plugin, etc) create such a cycle with the maven core?
That might happen if we add a new feature to the plugin API?

LieGrue,
strub


> Am 07.10.2017 um 22:32 schrieb Arnaud Héritier :
> 
> AFAIR the main concern was for developers to have to clone several dozen of
> repositories
> I don't think it is a real issue. We can share a script to do it easily
> 
> 
> On Sat, Oct 7, 2017 at 10:26 PM, Chas Honton  wrote:
> 
>> What are the concerns with separate git repository per artifact?  Is it
>> the monolithic build?
>> 
>> Chas
>> 
>>> On Oct 7, 2017, at 1:20 PM, Arnaud Héritier  wrote:
>>> 
>>> +1
>>> 
 On Sat, Oct 7, 2017 at 7:11 PM, Hervé BOUTEMY 
>> wrote:
 
 we can start with naming the future git repos: I suppose adding a table
>> at
 the
 end of the Git migration Wiki page can give a good view of the result
 (with 78
 new repos + existing 7 repos + the 6 in migration if nobody objects = 91
 repos)
 
 once we're all convinced of the target, we'll see how to work with infra
 and I suppose they already have the right authors list, given the
>> current
 mirrors already published
 
 Regards,
 
 Hervé
 
 Le samedi 7 octobre 2017, 16:05:45 CEST Tibor Digana a écrit :
> Herve,
> 
> I think, first of all, we should write a list with exact names of git
> repositories for which INFRA will crate them in
> git1-us-west.apache.org/repos/asf
> and mirror in github.com/apache
> 
> And then the authors.txt.
> 
> In my case I did not migrate tags and branches which is my problem
>> given
 in
> my example with previous e-mail.
> 
> On Sat, Oct 7, 2017 at 3:48 PM, Tibor Digana 
 wrote:
>> Herve,
>> I think making the tag as I wanted would not be possible in git.
>> 
>> Let's make it with all 78 projects.
>> In 2016 I migrated my svn project "audit" located in sub-folder behind
>> trunk (trunk/libs/audit) to git which is exactly what we need to do in
>> ASF.
>> 
>> In our case the commands would be 99% the same. The 1% is the source
 SVN
>> URL and target GitHub URL. That's all. Then if we provide INFRA with
 bunch
>> of commands like these then they will only execute them with their
>> permissions.
>> I do not think they will give me admin permissions to make it.
>> 
>> git svn clone --no-metadata --authors-file=E:\*authors.txt* http://
>> ***/svn/***/*trunk/libs/audit audit*
>> git config --global user.name "*** ***"
>> git config --global user.email "***@***.***"
>> git remote add origin https://***@github.com/apache/
 *maven-clean-plugin*
>> .git
>> git push -u origin --all
>> 
>> I observed the *authors.txt* from command
>> *svn log -q*
>> Each person from between first two pipes, e.g.:
>> r1234567 | tibordigana | 2015-10-19 02:20:00
>> 
>> Every developer added e-mail and full name, i.e.:
>> tibordigana = Tibor Digana 
>> etc.
>> 
>> This list of users which should be created in prior to contact INFRA.
>> Not all users are active after years but it would be nice to include
 them
>> too.
>> This list of users is one thing which cannot be automated!
>> 
>> 
>> 
>> 
>> On Sat, Oct 7, 2017 at 2:48 PM, Tibor Digana 
>> 
>> wrote:
>>> In my company I have such situation in SVN. Making a tag from
 subfolder.
>>> Git always makes the tag from the root, right?
>>> Let's google something...
>>> 
>>> On Sat, Oct 7, 2017 at 2:47 PM, Tibor Digana <
 tibor.dig...@googlemail.com
>>> 
 wrote:
 In my company I have such situation.
 Making a tag from subfolder.
 Git always makes the tag from the root, right?
 Let's 

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

[Mark Struberg]

> I like this idea of avoiding force pushing, but I'm not git expert to know 
> exactly if this gives exactly the intended result = start clean and not
> have noise when doing bisects or git blame

It's clean for our own repo but might probably screw up cloned repos as they 
cannot just git-pull anymore.

LieGrue,
strub

> Am 08.01.2017 um 11:41 schrieb Hervé BOUTEMY :
> 
> I like this idea of avoiding force pushing, but I'm not git expert to know 
> exactly if this gives exactly the intended result = start clean and not have 
> noise when doing bisects or git blame
> 
> this technical discussion should probably on a separate email thread, to not 
> pollute the vote thread
> 
> Any git experts to evaluate this implementation strategy?
> 
> Regards,
> 
> Hervé
> 
> Le jeudi 5 janvier 2017, 10:12:10 CET Mark Derricutt a écrit :
>> On 5 Jan 2017, at 1:16, Stephen Connolly wrote:
>> 
>> As this involves a --force push on the `master` branch, we want to get the
>> approval of the committers before continuing.
>> 
>> You could branch at the point you want to reset to, then use an ours/theirs
>> merge strategy which creates a merge commit that ONLY takes one side.
>> Effectively resetting, keeping the fact we did this reversal, and doesn't
>> force everyone to re-clone.
>> 
>> From https://git-scm.com/docs/merge-strategies:
>> 
>> ours: This resolves any number of heads, but the resulting tree of the merge
>> is always that of the current branch head, effectively ignoring all changes
>> from all other branches. It is meant to be used to supersede old
>> development history of side branches. Note that this is different from the
>> -Xours option to the 'recursive' merge strategy.
>> 
>> Would something like this be better than force pushing?
>> 
>> --
>> Mark Derricutt
>> http://www.theoryinpractice.net
>> http://www.chaliceofblood.net
>> http://plus.google.com/+MarkDerricutt
>> http://twitter.com/talios
>> http://facebook.com/mderricutt
> 
> 
> 
> -
> 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 Shade Plugin version 2.4

[Mark Struberg]

+1 
LieGrue,
strub


 Am 08.06.2015 um 12:32 schrieb Jason van Zyl ja...@takari.io:
 
 +1
 
 On Jun 7, 2015, at 6:15 AM, Karl Heinz Marbaise khmarba...@gmx.de wrote:
 
 Hi,
 
 We solved 14 issues:
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921version=12331393
 
 There are still a couple of issues left in JIRA:
 https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHADE%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
 
 Staging repo:
 https://repository.apache.org/content/repositories/maven-1189
 https://repository.apache.org/content/repositories/maven-1189/org/apache/maven/plugins/maven-shade-plugin/2.4/maven-shade-plugin-2.4-source-release.zip
 
 Source release checksum(s):
 maven-shade-plugin-2.4-source-release.zip sha1: 
 2ffe5cb14f62410523a59f9eb1e181d78ad47659
 
 
 Staging site:
 http://maven.apache.org/plugins-archives/maven-shade-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
 
 Kind regards
 Karl Heinz Marbaise
 
 -
 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
 -
 
 Simplex sigillum veri. (Simplicity is the seal of truth.)
 
 
 
 
 
 
 
 
 
 
 
 
 
 -
 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] Add Manfred Moser as committer

[Mark Struberg]

+1 on Manfred, even thought he is already^^

LieGrue,
strub

PS: usually committer votes are held on the private lists…:wq

 Am 13.05.2015 um 17:13 schrieb Stephane Nicoll stephane.nic...@gmail.com:
 
 +1
 
 S.
 
 On Wed, May 13, 2015 at 8: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
 
 


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

Re: [VOTE] Release Wagon 2.9

[Mark Struberg]

+1

only did simple checks (work) and checked source. looks good so far 

LieGrue,
strub


 Am 27.04.2015 um 16:52 schrieb Kristian Rosenvold 
 kristian.rosenv...@gmail.com:
 
 +1
 27. apr. 2015 16.01 skrev Stephen Connolly 
 stephen.alan.conno...@gmail.com:
 
 +1 (you beat me to my vote on core, but you can have my vote on wagon)
 
 On 27 April 2015 at 14:36, Jason van Zyl ja...@takari.io wrote:
 
 Can I get a couple more votes for Wagon 2.9 please. It's holding up the
 release of Maven 3.3.3 now.
 
 On Apr 21, 2015, at 10:38 AM, Jason van Zyl ja...@takari.io wrote:
 
 Hi,
 
 We have fixed 9 issues:
 
 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318122version=12331786
 
 Staging repository:
 https://repository.apache.org/content/repositories/maven-1171/
 
 Staged site: http://maven.apache.org/wagon-archives/wagon-LATEST/
 
 Vote open for 72H
 
 [+1]
 [0]
 [-1]
 
 Thanks,
 
 The Maven Team
 
 
 
 
 
 
 
 
 
 
 
 
 -
 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 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
 
 
 


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

Re: [VOTE] Release Wagon 2.9

[Mark Struberg]

indeed, then it passed twice ;)

LieGrue,
strub


 Am 27.04.2015 um 17:01 schrieb Jason van Zyl ja...@takari.io:
 
 You have checked Maven 3.3.3 so really you have already checked Wagon 2.9 :-)
 
 On Apr 27, 2015, at 10:59 AM, Mark Struberg strub...@yahoo.de wrote:
 
 +1
 
 only did simple checks (work) and checked source. looks good so far 
 
 LieGrue,
 strub
 
 
 Am 27.04.2015 um 16:52 schrieb Kristian Rosenvold 
 kristian.rosenv...@gmail.com:
 
 +1
 27. apr. 2015 16.01 skrev Stephen Connolly 
 stephen.alan.conno...@gmail.com:
 
 +1 (you beat me to my vote on core, but you can have my vote on wagon)
 
 On 27 April 2015 at 14:36, Jason van Zyl ja...@takari.io wrote:
 
 Can I get a couple more votes for Wagon 2.9 please. It's holding up the
 release of Maven 3.3.3 now.
 
 On Apr 21, 2015, at 10:38 AM, Jason van Zyl ja...@takari.io wrote:
 
 Hi,
 
 We have fixed 9 issues:
 
 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318122version=12331786
 
 Staging repository:
 https://repository.apache.org/content/repositories/maven-1171/
 
 Staged site: http://maven.apache.org/wagon-archives/wagon-LATEST/
 
 Vote open for 72H
 
 [+1]
 [0]
 [-1]
 
 Thanks,
 
 The Maven Team
 
 
 
 
 
 
 
 
 
 
 
 
 -
 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 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
 
 
 
 
 
 -
 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
 -
 
 We all have problems. How we deal with them is a measure of our worth.
 
 -- Unknown
 
 
 
 
 
 
 
 
 
 
 
 
 
 -
 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] ASF Parent POM Version 17

[Mark Struberg]

+1

tested with 2 projects without issues.

LieGrue,
strub


 Am 24.04.2015 um 21:08 schrieb Karl Heinz Marbaise khmarba...@gmx.de:
 
 Hi,
 
 We solved 10 issues:
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250version=12329009
 
 Staging repo:
 https://repository.apache.org/content/repositories/orgapacheapache-1005
 
 https://repository.apache.org/content/repositories/orgapacheapache-1005/org/apache/apache/17/apache-17-source-release.zip
 
 Source release checksum(s):
 apache-17-source-release.zip sha1: 640e27bb2ae3b77962ccdf2d82fe6628a83894be
 
 Staging site:
 http://maven.apache.org/pom-archives/asf-LATEST/
 
 Guide to testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html
 
 Changes since last release:
 http://svn.apache.org/viewvc/maven/pom/tags/apache-17/pom.xml?r1=HEADr2=1639452diff_format=h
 
 
 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] ASF Parent POM Version 17

[Mark Struberg]

nope, go on you even have 4 already:

Kristian, Jason, you, me

http://people.apache.org/committers-by-project.html#maven-pmc

LieGrue,
strub


 Am 27.04.2015 um 20:37 schrieb Karl Heinz Marbaise khmarba...@gmx.de:
 
 Hi,
 
 here is my +1.
 
 need two more binding VOTES...
 
 Kind regards
 Karl Heinz Marbaise
 
 
 On 4/24/15 9:08 PM, Karl Heinz Marbaise wrote:
 Hi,
 
 We solved 10 issues:
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250version=12329009
 
 
 Staging repo:
 https://repository.apache.org/content/repositories/orgapacheapache-1005
 
 https://repository.apache.org/content/repositories/orgapacheapache-1005/org/apache/apache/17/apache-17-source-release.zip
 
 
 Source release checksum(s):
 apache-17-source-release.zip sha1: 640e27bb2ae3b77962ccdf2d82fe6628a83894be
 
 Staging site:
 http://maven.apache.org/pom-archives/asf-LATEST/
 
 Guide to testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html
 
 Changes since last release:
 http://svn.apache.org/viewvc/maven/pom/tags/apache-17/pom.xml?r1=HEADr2=1639452diff_format=h
 
 
 
 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] Maven 3.3.3 Release

[Mark Struberg]

+1

The problem I have with mvnDebug on OSX cmd line seems to be there in older 
3.3.x versions already. So 3.3.3 is at least better than 3.3.2. We should 
really fix this in the next version. But otherwise the release looks good.

LieGrue,
strub

 
 Am 25.04.2015 um 23:45 schrieb Mark Derricutt m...@talios.com:
 
 On 26 Apr 2015, at 9:23, Jason van Zyl wrote:
 
 Great, thanks for testing Mirko.
 
 Not seeing any binding votes?
 
 -- 
 Mark Derricutt
 http://www.theoryinpractice.net
 http://www.chaliceofblood.net
 http://plus.google.com/+MarkDerricutt
 http://twitter.com/talios
 http://facebook.com/mderricutt


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

Re: [VOTE] Maven 3.3.3 Release

[Mark Struberg]

will do tomorrow morning. Need to dig whether this already got reported first.

txs and LieGrue,
strub

 Am 26.04.2015 um 22:39 schrieb Jason van Zyl ja...@takari.io:
 
 Mark,
 
 If this is what's happening make a JIRA and mark it for 3.3.4 and we'll get 
 it in there. Seems easy enough to fix. Stuart, thanks for the analysis.
 
 On Apr 26, 2015, at 1:24 PM, Stuart McCulloch mccu...@gmail.com wrote:
 
 On Sunday, 26 April 2015 at 17:34, Jason van Zyl wrote:
 Did you create an issue in JIRA, I still don't know exactly what the 
 problem is.
 
 
 
 AFAICT the underlying issue is that the MAVEN_OPTS setting can be reset when 
 the mvn script sources .mavenrc
 
 Before 3.3.x the mvnDebug script was a tweaked copy of mvn so this didn’t 
 make any difference to debugging as MAVEN_DEBUG_OPTS was still referenced in 
 the final command.
 
 For 3.3.x onwards the mvnDebug script sets MAVEN_OPTS to “$MAVEN_OPTS 
 $MAVEN_DEBUG_OPTS” and then invokes the mvn script... which means that if 
 MAVEN_OPTS is subsequently reset by .mavenrc in the mvn script then the 
 debug settings are lost. You can recreate this by simply adding 
 MAVEN_OPTS=“-showversion” to your .mavenrc
 
 One fix could be to source /etc/mavenrc and .mavenrc early on in mvnDebug 
 (as done in the mvn script) and then set MAVEN_SKIP_RC=1 when invoking mvn 
 with the combined MAVEN_OPT setting. This should stop it getting reset in 
 the mvn script and allow the debug settings to pass through.
 
 On Apr 26, 2015, at 2:12 AM, Mark Struberg strub...@yahoo.de 
 (mailto:strub...@yahoo.de) wrote:
 
 +1
 
 The problem I have with mvnDebug on OSX cmd line seems to be there in 
 older 3.3.x versions already. So 3.3.3 is at least better than 3.3.2. We 
 should really fix this in the next version. But otherwise the release 
 looks good.
 
 LieGrue,
 strub
 
 
 Am 25.04.2015 um 23:45 schrieb Mark Derricutt m...@talios.com 
 (mailto:m...@talios.com):
 
 On 26 Apr 2015, at 9:23, Jason van Zyl wrote:
 
 Great, thanks for testing Mirko.
 
 Not seeing any binding votes?
 
 --  
 Mark Derricutt
 http://www.theoryinpractice.net
 http://www.chaliceofblood.net
 http://plus.google.com/+MarkDerricutt
 http://twitter.com/talios
 http://facebook.com/mderricutt
 
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
 (mailto:dev-unsubscr...@maven.apache.org)
 For additional commands, e-mail: dev-h...@maven.apache.org 
 (mailto:dev-h...@maven.apache.org)
 
 
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder, Takari and Apache Maven
 http://twitter.com/jvanzyl
 http://twitter.com/takari_io
 -
 
 We know what we are, but know not what we may be.
 
 -- Shakespeare
 
 
 
 
 
 
 
 
 
 
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
 (mailto:dev-unsubscr...@maven.apache.org)
 For additional commands, e-mail: dev-h...@maven.apache.org 
 (mailto:dev-h...@maven.apache.org)
 
 
 
 
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder, Takari and Apache Maven
 http://twitter.com/jvanzyl
 http://twitter.com/takari_io
 -
 
 Three people can keep a secret provided two of them are dead.
 
 -- Benjamin Franklin
 
 
 
 
 
 
 
 
 
 
 
 
 
 -
 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: mvnDebug with problems

[Mark Struberg]

+1 sounds like a plan. 

LieGrue,
strub

 Am 24.04.2015 um 18:55 schrieb Andreas Gudian andreas.gud...@gmail.com:
 
 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:;


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

Re: [VOTE] Maven 3.3.3 Release

[Mark Struberg]

Re-tested with 3.3.2 and it doesn’t work there neither on my box. 3.0.5 and 
3.1.1 work fine

not sure if this has an impact, but I have the following in my /etc/mavenrc:
export MAVEN_OPTS=-Xms128m -Xmx512m -XX:MaxPermSize=196m -client

Using OS X 10.10.3 with java7 and 8. 

LieGrue,
strub


 Am 24.04.2015 um 14:08 schrieb Jason van Zyl ja...@takari.io:
 
 Working fine here. The scripts haven't changed since the end of February.
 
 Anyone else confirm an issue with remote debugging?
 
 On Apr 24, 2015, at 3:24 AM, Mark Struberg strub...@yahoo.de wrote:
 
 maybe I missed some change, but I cannot run mvnDebug anymore. It nicely 
 says that I start in debug mode, but doesn’t open a debug port and neither 
 doesn’t wait for me to attach.
 
 Anything I missed, or is this really a regression?
 
 txs and LieGrue,
 strub
 
 
 
 Am 22.04.2015 um 14:22 schrieb Jason van Zyl ja...@takari.io:
 
 Hi,
 
 Time to release Maven 3.3.3!
 
 Here is a link to Jira with 5 issues resolved:
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922version=12332054
 
 Staging repo:
 https://repository.apache.org/content/repositories/maven-1173/
 
 The distributable binaries and sources for testing can be found here:
 https://repository.apache.org/content/repositories/maven-1173/org/apache/maven/apache-maven/3.3.3/
 
 Specifically the zip, tarball, and source archives can be found here:
 https://repository.apache.org/content/repositories/maven-1173/org/apache/maven/apache-maven/3.3.3/apache-maven-3.3.3-bin.zip
 https://repository.apache.org/content/repositories/maven-1173/org/apache/maven/apache-maven/3.3.3/apache-maven-3.3.3-bin.tar.gz
 https://repository.apache.org/content/repositories/maven-1173/org/apache/maven/apache-maven/3.3.3/apache-maven-3.3.3-src.zip
 https://repository.apache.org/content/repositories/maven-1173/org/apache/maven/apache-maven/3.3.3/apache-maven-3.3.3-src.tar.gz
 
 Source release checksum(s):
 apache-maven-3.3.3-src.zip sha1: 10cbba145a183bdbbe7073060d4c1391956ca84c
 
 Staging site:
 http://takari.io/maven-3.3.3/
 
 Vote open for 72 hours.
 
 [ ] +1
 [ ] +0
 [ ] -1
 
 Thanks,
 
 The Maven Team
 
 
 
 
 
 
 
 
 
 
 -
 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
 -
 
 Our achievements speak for themselves. What we have to keep track
 of are our failures, discouragements and doubts. We tend to forget
 the past difficulties, the many false starts, and the painful
 groping. We see our past achievements as the end result of a
 clean forward thrust, and our present difficulties as
 signs of decline and decay.
 
 -- Eric Hoffer, Reflections on the Human Condition
 
 
 
 
 
 
 
 
 
 
 
 
 
 -
 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] Maven 3.3.3 Release

[Mark Struberg]

Same result with 3.3.1. Latest working maven I have locally is 3.2.1:

~/tmp/delete/CDI-Sandbox/converter$/opt/apache/apache-maven-3.2.1/bin/mvnDebug 
clean test -Powb-1.5 -Dtest=ConvertTest
Preparing to Execute Maven in Debug Mode
Listening for transport dt_socket at address: 8000


Now the same in 3.3.1:

~/tmp/delete/CDI-Sandbox/converter$/opt/apache/apache-maven-3.3.1/bin/mvnDebug 
clean test -Powb-1.5 -Dtest=ConvertTest
Preparing to Execute Maven in Debug Mode
[INFO] Scanning for projects...
[INFO]
[INFO] 
[INFO] Building …


Will try to dig lira, but first need to finish a task at $$dayjob :(

LieGrue,
strub

 Am 24.04.2015 um 14:30 schrieb Jason van Zyl ja...@takari.io:
 
 If you can an issue in JIRA and try with 3.3.1 and it fails then we'll know 
 where it started. That's likely it as that's where we changed the scripts. 
 
 I'm using your exact MAVEN_OPTS and it's working here to startup and debug in 
 Eclipse.
 
 On Apr 24, 2015, at 8:20 AM, Mark Struberg strub...@yahoo.de wrote:
 
 Re-tested with 3.3.2 and it doesn’t work there neither on my box. 3.0.5 and 
 3.1.1 work fine
 
 not sure if this has an impact, but I have the following in my /etc/mavenrc:
 export MAVEN_OPTS=-Xms128m -Xmx512m -XX:MaxPermSize=196m -client
 
 Using OS X 10.10.3 with java7 and 8. 
 
 LieGrue,
 strub
 
 
 Am 24.04.2015 um 14:08 schrieb Jason van Zyl ja...@takari.io:
 
 Working fine here. The scripts haven't changed since the end of February.
 
 Anyone else confirm an issue with remote debugging?
 
 On Apr 24, 2015, at 3:24 AM, Mark Struberg strub...@yahoo.de wrote:
 
 maybe I missed some change, but I cannot run mvnDebug anymore. It nicely 
 says that I start in debug mode, but doesn’t open a debug port and neither 
 doesn’t wait for me to attach.
 
 Anything I missed, or is this really a regression?
 
 txs and LieGrue,
 strub
 
 
 
 Am 22.04.2015 um 14:22 schrieb Jason van Zyl ja...@takari.io:
 
 Hi,
 
 Time to release Maven 3.3.3!
 
 Here is a link to Jira with 5 issues resolved:
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922version=12332054
 
 Staging repo:
 https://repository.apache.org/content/repositories/maven-1173/
 
 The distributable binaries and sources for testing can be found here:
 https://repository.apache.org/content/repositories/maven-1173/org/apache/maven/apache-maven/3.3.3/
 
 Specifically the zip, tarball, and source archives can be found here:
 https://repository.apache.org/content/repositories/maven-1173/org/apache/maven/apache-maven/3.3.3/apache-maven-3.3.3-bin.zip
 https://repository.apache.org/content/repositories/maven-1173/org/apache/maven/apache-maven/3.3.3/apache-maven-3.3.3-bin.tar.gz
 https://repository.apache.org/content/repositories/maven-1173/org/apache/maven/apache-maven/3.3.3/apache-maven-3.3.3-src.zip
 https://repository.apache.org/content/repositories/maven-1173/org/apache/maven/apache-maven/3.3.3/apache-maven-3.3.3-src.tar.gz
 
 Source release checksum(s):
 apache-maven-3.3.3-src.zip sha1: 10cbba145a183bdbbe7073060d4c1391956ca84c
 
 Staging site:
 http://takari.io/maven-3.3.3/
 
 Vote open for 72 hours.
 
 [ ] +1
 [ ] +0
 [ ] -1
 
 Thanks,
 
 The Maven Team
 
 
 
 
 
 
 
 
 
 
 -
 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
 -
 
 Our achievements speak for themselves. What we have to keep track
 of are our failures, discouragements and doubts. We tend to forget
 the past difficulties, the many false starts, and the painful
 groping. We see our past achievements as the end result of a
 clean forward thrust, and our present difficulties as
 signs of decline and decay.
 
 -- Eric Hoffer, Reflections on the Human Condition
 
 
 
 
 
 
 
 
 
 
 
 
 
 -
 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
 -
 
 Lastly, Impossible. The lamest

Re: [VOTE] Maven 3.3.3 Release

[Mark Struberg]

maybe I missed some change, but I cannot run mvnDebug anymore. It nicely says 
that I start in debug mode, but doesn’t open a debug port and neither doesn’t 
wait for me to attach.

Anything I missed, or is this really a regression?

txs and LieGrue,
strub



 Am 22.04.2015 um 14:22 schrieb Jason van Zyl ja...@takari.io:
 
 Hi,
 
 Time to release Maven 3.3.3!
 
 Here is a link to Jira with 5 issues resolved:
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922version=12332054
 
 Staging repo:
 https://repository.apache.org/content/repositories/maven-1173/
 
 The distributable binaries and sources for testing can be found here:
 https://repository.apache.org/content/repositories/maven-1173/org/apache/maven/apache-maven/3.3.3/
 
 Specifically the zip, tarball, and source archives can be found here:
 https://repository.apache.org/content/repositories/maven-1173/org/apache/maven/apache-maven/3.3.3/apache-maven-3.3.3-bin.zip
 https://repository.apache.org/content/repositories/maven-1173/org/apache/maven/apache-maven/3.3.3/apache-maven-3.3.3-bin.tar.gz
 https://repository.apache.org/content/repositories/maven-1173/org/apache/maven/apache-maven/3.3.3/apache-maven-3.3.3-src.zip
 https://repository.apache.org/content/repositories/maven-1173/org/apache/maven/apache-maven/3.3.3/apache-maven-3.3.3-src.tar.gz
 
 Source release checksum(s):
 apache-maven-3.3.3-src.zip sha1: 10cbba145a183bdbbe7073060d4c1391956ca84c
 
 Staging site:
 http://takari.io/maven-3.3.3/
 
 Vote open for 72 hours.
 
 [ ] +1
 [ ] +0
 [ ] -1
 
 Thanks,
 
 The Maven Team
 
 
 
 
 
 
 
 
 
 
 -
 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 Release Plugin version 2.5.2

[Mark Struberg]

+1

LieGrue,
strb



 Am 19.04.2015 um 14:28 schrieb Robert Scholte rfscho...@apache.org:
 
 Hi,
 
 We solved 13 issues:
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317824version=12331215
 
 There are still a couple of issues left in JIRA:
 https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317824%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
 
 Staging repo:
 https://repository.apache.org/content/repositories/maven-1169/
 https://repository.apache.org/content/repositories/maven-1169/org/apache/maven/release/maven-release/2.5.2/maven-release-2.5.2-source-release.zip
 
 Source release checksum(s):
 maven-release-2.5.2-source-release.zip sha1: 
 ce438ce37460c97d9d2dc6255ba9f12a57f30147
 
 Staging sites:
 plugin:
 http://maven.apache.org/maven-release-archives/maven-release-LATEST/maven-release-plugin/
 maven-release: 
 http://maven.apache.org/maven-release-archives/maven-release-LATEST/
 
 Guide to testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html
 
 Vote open for 72 hours.
 
 [ ] +1
 [ ] +0
 [ ] -1
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 


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

libs in mavens /lib folder

[Mark Struberg]

Hi!

I'm quite confused by the sheer amount of libs we already have in our lib 
folder. For maven-3.2.1 this is

133957 7. Mai 2013 aether-api-0.9.0.M2.jar
12637 14. Feb 2014 aether-api.license
34117 7. Mai 2013 aether-connector-wagon-0.9.0.M2.jar
12637 14. Feb 2014 aether-connector-wagon.license
144866 7. Mai 2013 aether-impl-0.9.0.M2.jar
12637 14. Feb 2014 aether-impl.license
17703 7. Mai 2013 aether-spi-0.9.0.M2.jar
12637 14. Feb 2014 aether-spi.license
133588 7. Mai 2013 aether-util-0.9.0.M2.jar
12637 14. Feb 2014 aether-util.license
4467 7. Mai 2013 aopalliance-1.0.jar
44908 7. Mai 2013 cdi-api-1.0.jar
41123 7. Mai 2013 commons-cli-1.2.jar
173587 7. Mai 2013 commons-io-2.2.jar
284220 7. Mai 2013 commons-lang-2.6.jar
2189117 7. Mai 2013 guava-14.0.1.jar
2497 7. Mai 2013 javax.inject-1.jar
293671 24. Jul 2013 jsoup-1.7.2.jar
3555 14. Feb 2014 jsoup.license
5848 7. Mai 2013 jsr250-api-1.0.jar
18116 14. Feb 2014 jsr250-api.license
61357 14. Feb 2014 maven-aether-provider-3.2.1.jar
53651 14. Feb 2014 maven-artifact-3.2.1.jar
283790 14. Feb 2014 maven-compat-3.2.1.jar
574650 14. Feb 2014 maven-core-3.2.1.jar
59433 14. Feb 2014 maven-embedder-3.2.1.jar
159855 14. Feb 2014 maven-model-3.2.1.jar
165103 14. Feb 2014 maven-model-builder-3.2.1.jar
45831 14. Feb 2014 maven-plugin-api-3.2.1.jar
25758 14. Feb 2014 maven-repository-metadata-3.2.1.jar
42804 14. Feb 2014 maven-settings-3.2.1.jar
42738 14. Feb 2014 maven-settings-builder-3.2.1.jar
291397 23. Sep 2013 org.eclipse.sisu.inject-0.0.0.M5.jar
12637 14. Feb 2014 org.eclipse.sisu.inject.license
196544 25. Jul 2013 org.eclipse.sisu.plexus-0.0.0.M5.jar
12637 14. Feb 2014 org.eclipse.sisu.plexus.license
13350 7. Mai 2013 plexus-cipher-1.7.jar
33933 14. Feb 2014 plexus-cipher.license
4211 7. Mai 2013 plexus-component-annotations-1.5.5.jar
61697 17. Aug 2013 plexus-interpolation-1.19.jar
28555 7. Mai 2013 plexus-sec-dispatcher-1.3.jar
33933 14. Feb 2014 plexus-sec-dispatcher.license
251792 27. Jan 2014 plexus-utils-3.0.17.jar
358933 7. Mai 2013 sisu-guice-3.1.3-no_aop.jar
26084 24. Jul 2013 slf4j-api-1.7.5.jar
11207 14. Feb 2014 slf4j-api.license
10680 17. Aug 2013 slf4j-simple-1.7.5.jar
11207 14. Feb 2014 slf4j-simple.license
11288 14. Jan 2014 wagon-file-2.6.jar
1388197 14. Jan 2014 wagon-http-2.6-shaded.jar
10373 14. Jan 2014 wagon-http-shared-2.6.jar
52572 14. Jan 2014 wagon-provider-api-2.6.jar


Lets look into details:


44908 7. Mai 2013 cdi-api-1.0.jar

What for? Do we use CDI in maven now? If so, why do we still have guava and 
guice? - No then remove it


41123 7. Mai 2013 commons-cli-1.2.jar
173587 7. Mai 2013 commons-io-2.2.jar
284220 7. Mai 2013 commons-lang-2.6.jar

That might clash with many customer projects or is this very well guarded from 
any plugin classloader?

In maven-shared-utils we shaded in the few classes we used from this libs. 


2189117 7. Mai 2013 guava-14.0.1.jar
This is also used pretty often in custom projects. Same question as for 
commons-*. Is it well isolated?


2497 7. Mai 2013 javax.inject-1.jar
We are only lucky that there is atm only a single version of this spec out 
there. So currently not much of an issue but a ticking time bomb.


5848 7. Mai 2013 jsr250-api-1.0.jar

commons-annotations (JSR-250) are part of the JRE since java-1.4. So why do we 
add it?



txs and LieGrue,
strub

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

Re: [VOTE] Release Apache Maven WAR Plugin version 2.6

[Mark Struberg]

works fine over here. 

rat fine as well.

+1

LieGrue,
strub





 On Thursday, 8 January 2015, 21:21, Karl Heinz Marbaise khmarba...@gmx.de 
 wrote:
  Hi,
 
 We solved 12 issues:
 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11150version=20681
 
 There are still a couple of issues left in JIRA:
 http://jira.codehaus.org/issues/?jql=project%20%3D%20MWAR%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
 
 Staging repo:
 https://repository.apache.org/content/repositories/maven-1117
 
 https://repository.apache.org/content/repositories/maven-1117/org/apache/maven/plugins/maven-war-plugin/2.6/maven-war-plugin-2.6-source-release.zip
 
 Source release checksum(s):
 maven-war-plugin-2.6-source-release.zip sha1: 
 d687ff646f89253e79a7fa7e439ae57acd8f893
 
 
 Staging site:
 http://maven.apache.org/plugins-archives/maven-war-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
 
 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: incremental compiler questions

[Mark Struberg]

Hi Martin!

The maven-compiler plugin already does this. But once a single change is 
detected then we need to recompile the _whole_ module because of the reasons 
explained by Igor.
Pro of JDT: you can e.g. also see if there were only 'internal' changes and 
thus the other dependencies don't need to recompile. 

I'm 99.8, but not 100% convinced by that. Probably the other dependencies don't 
need any recompilation but maybe the whole internal behaviour changed and you 
still like to run your tests? Maybe we can simply ignore this and people should 
simply force a clean beforehand.


Basically al the incremental stuff boils down to the fact that the outcome is 
only determined by it's input. The problem is only to gather the right 'input'. 
E.g. your packaging relies not only on the compiled classes but also on 
resources and probably a manual include/exclude setting. Only the very plugin 
used to do the packaging will know. Thus EACH plugin in the whole chain needs 
to get adopted to incremental-awareness. Which is tons of work.


Another story is if the 'input' e.g. includes data from a database or you just 
like to re-run your unit tests for the sake of debugging. We need a switch to 
force some plugins to run even if the plugin itself cannot see a reason by 
simply looking at it's known 'input'.


LieGrue,
strub





 On Saturday, 10 January 2015, 2:04, Martin Gainty mgai...@hotmail.com wrote:
 G ood Evening Igor-
 
 Instead of implementing eclipe jdt for incremental java compilation is there:
 
 1)any ability to refactor/reconfigure javac to read Last Modified Date of 
 source 
 file to enable incremental compilation?
 2)any concerns over generated class files..are they the same?
 any deltas ..if so ...what are they?
 3)can we implement a static settings.xml or other static configuration file 
 that 
 manfred suggested for eclipse jdt?
 4)any ability to switch compiler from javac to jdt as an attribute in 
 maven-compiler-plugin?
 
 Thanks for a great presentation on Maven Dev hangout
 Martin 
 __ 
 

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

Re: javac bootclasspath and java8

[Mark Struberg]

. (The above method would be a MethodNotFoundException, or
the like.)
- Have a factory class, with code like the following:

private static final IRTUser instance = newRTUser();

private static IRTUser newInstance() {
  try {
return new JDK18RTUser();
  } catch (Throwable t0) {
try {
  return new JDK17RTUser();
} catch (Throwable t1) {
  return new JDK16RTUser();
}
 }

   public static IRTUser getInstance() { return instance; }

This approach has worked fine for me on multiple occasions.


Jochen




On Thu, Nov 27, 2014 at 9:39 PM, Mark Struberg strub...@yahoo.de wrote:
 Hi!

 Today I had a discussion with Robert about how we can solve a problem I had 
 over at Apache OpenWebBeans:

 https://issues.apache.org/jira/browse/OWB-952

 As a short summary: the classes provided in rt.jar of Java8 are slightly 
 different than the ones from Java7 and 6. Similar big differences have been 
 seen in the Java4 to 5 transition.
 Thus if you compile your project with Java8 you might get different 
 bytecode than when compiling with Java7 JDK. Even if you use target=1.7 in 
 both cases.

 There are 2 options: either use javac -bootclasspath and point it to the 
 'correct' rt.jar + other jdk libs, or just switch the whole environment.

 Roberts suggestion was to use the Maven Toolchain 
 system:http://maven.apache.org/plugins/maven-toolchains-plugin/
 http://maven.apache.org/plugins/maven-toolchains-plugin/toolchains/jdk.html


 We also elaborated about improving the Toolchain lookup in our 
 maven-compiler-plugin:
 http://maven.apache.org/plugins/maven-compiler-plugin/xref/org/apache/maven/plugin/compiler/AbstractCompilerMojo.html#427

 This could get improved to first check if a toolchain is registered for the 
 target version used in the m-compiler-p. And if there is no toolchain 
 configured especially for this version then we fallback to the one if we 
 don't specify a version.
 The effective lookup path would then be
 1.) toolchain configured via maven-toolchain-plugin
 2.) toolchain with specified target version
 3.) default toolchain


 I think we would need to slightly enhance the ToolchainManager, but first 
 would like to get some feedback.


 LieGrue,
 strub

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




--
Our time is just a point along a line that runs forever with no end.
(Al Stewart, Lord Grenville)


-
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: javac bootclasspath and java8

[Mark Struberg]

Hi Paul!

Txs, this is definitely one possible direction in which we could aim.

LieGrue,
strub





 On Saturday, 29 November 2014, 11:18, Paul Moloney pmoloney...@gmail.com 
 wrote:
  Hi
 
 I had written this rule for the enforcer plugin which actually checks the
 label of jdk version in toolchains against output of javc --version. It
 works for my limited scenario @work and definetely requires more attention
 to cope with non oracle compilers and the apache way.
 
 https://github.com/paulmoloney/maven-enforcer-toolchain-rules
 
 regards,
 Paul
 

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

Re: javac bootclasspath and java8

[Mark Struberg]

Hi!


 This lets you selectively forbid certain methods 


The problem is that the methods used are perfectly fine. The API methods used 
in our program do exist even in Java6. But they get coerced to different 
methods when compiling with Java8. And those new methods do not exist in Java7 
and older - Boom.


 Out of curiosity, why do you want to get exactly the same bytecode? 

 Does the code compiled with java8 not work under java7?


Exactly that is the case! It just blows up at runtime as the rt.jar from Java7 
does not contain those new methods/interfaces.



The best solution I could come up so far would be to implement some logic in 
maven-compiler-plugin trying to pick up the right version of the toolchain and 
only if it cannot find it fallback to the default jdk.


LieGrue,
strub




 On Friday, 28 November 2014, 8:44, Dawid Weiss dawid.we...@gmail.com wrote:
 T here is also a very cool tool from the Lucene land, written by Uwe 
 Schindler --
 
 https://code.google.com/p/forbidden-apis/
 
 This lets you selectively forbid certain methods from your codebase
 (and the default list of forbidden methods has a strong rationale to
 be discouraged -- locale-sensitive methods, etc.).
 
 Dawid
 
 
 
 On Fri, Nov 28, 2014 at 1:09 AM, Stephen Connolly
 stephen.alan.conno...@gmail.com wrote:
  On Thursday, 27 November 2014, Mark Derricutt m...@talios.com 
 wrote:
 
  On 28 Nov 2014, at 10:32, Igor Fedorenko wrote:
 
   Out of curiosity, why do you want to get exactly the same 
 bytecode? Does
   the code compiled with java8 not work under java7?
 
  Mostly - it's due to method signature resolution.  For instance in 
 the JDK
  5 - 6 change, some functions that used to take `String` were 
 changed to
  take `CharSequence` - when compiling against the JDK6 classes the byte 
 code
  binds against `CharSequence`, thus when running under JDK5 you get
  method-not-found exceptions.
 
 
  I hope animal-sniffer has your back for those cases though?
 
 
 
  --
  Mark Derricutt
  http://www.theoryinpractice.net
  http://plus.google.com/+MarkDerricutt
  http://twitter.com/talios
  http://facebook.com/mderricutt
 
 
 
  --
  Sent from my phone
 
 -
 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: Ivy style versions propagating in Maven central

[Mark Struberg]

+1 if they like to use Mavens infrastructure then they also need to play 
according to those rules.

Anyone likes to talk with the Ivy guys? They have to fix this.


Another question is what we do with those existing poms in maven.central? Do we 
convert them? What about sha1, md5 and asc in that case? Rewriting existing 
poms would lead to breaking them.



LieGrue,
strub





 On Saturday, 20 September 2014, 7:44, Mirko Friedenhagen 
 mfriedenha...@gmail.com wrote:
  +1 for checking when uploading to Central.
 
 Regards
 Mirko
 -- 
 Sent from my mobile
 
 On Sep 20, 2014 4:22 AM, Jason van Zyl ja...@takari.io 
 wrote:
 
 
  On Sep 19, 2014, at 9:35 PM, William Ferguson 
  william.fergu...@xandar.com.au wrote:
 
   Because of the rise of Gradle usage to its inclusion as the build tool 
 in
   Android Studio, there are more and more artifacts making their way 
 into
   Maven Central whose POMs contain elements that do not conform to Maven
   expectations.
  
   A good example is this POM:
  
 
 http://search.maven.org/#artifactdetails%7Ccom.squareup%7Cfest-android%7C1.0.8%7Cjar
  
   It has a dependency that uses the Gradle/Ivy version syntax of 19.1+ 
 to
   indicate a range.
   Maven does not parse this version string and dies.
  
   So the question is what should be done about it.
  
   Some ideas:
  
 1. Maven central starts verifying and rejecting malformed POMs with 
 a
 reason for rejection.
 
  +1
 
  This is just terrible syntax and doesn't follow any normal set notation
  established by any existing systems. Normal set notation works perfectly
  fine and using something else is not really a boon for anyone.
 
 2. Maven starts handling the Gradle/Ivy version syntax either as
1. an optional extra
2. a permanent move forward (configurable to support backward
compatibility)
  
   William
 
  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder,  Apache Maven
  http://twitter.com/jvanzyl
  http://twitter.com/takari_io
  -
 
  I never make the mistake of arguing with people for whose opinions I have
  no respect.
 
  -- Edward Gibbon
 
 
 
 
 
 
 
 
 
 
 

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

javac bootclasspath and java8

[Mark Struberg]

Hi!

Today I had a discussion with Robert about how we can solve a problem I had 
over at Apache OpenWebBeans:

https://issues.apache.org/jira/browse/OWB-952

As a short summary: the classes provided in rt.jar of Java8 are slightly 
different than the ones from Java7 and 6. Similar big differences have been 
seen in the Java4 to 5 transition.
Thus if you compile your project with Java8 you might get different bytecode 
than when compiling with Java7 JDK. Even if you use target=1.7 in both cases.

There are 2 options: either use javac -bootclasspath and point it to the 
'correct' rt.jar + other jdk libs, or just switch the whole environment.

Roberts suggestion was to use the Maven Toolchain 
system:http://maven.apache.org/plugins/maven-toolchains-plugin/
http://maven.apache.org/plugins/maven-toolchains-plugin/toolchains/jdk.html


We also elaborated about improving the Toolchain lookup in our 
maven-compiler-plugin:
http://maven.apache.org/plugins/maven-compiler-plugin/xref/org/apache/maven/plugin/compiler/AbstractCompilerMojo.html#427

This could get improved to first check if a toolchain is registered for the 
target version used in the m-compiler-p. And if there is no toolchain 
configured especially for this version then we fallback to the one if we don't 
specify a version.
The effective lookup path would then be
1.) toolchain configured via maven-toolchain-plugin
2.) toolchain with specified target version
3.) default toolchain


I think we would need to slightly enhance the ToolchainManager, but first would 
like to get some feedback.


LieGrue,
strub

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

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

[Mark Struberg]

+1

really like the new logo (or better any of those owls).

LieGrue,
strub





 On Tuesday, 25 November 2014, 12:02, Arnaud Héritier aherit...@gmail.com 
 wrote:
  +1
 
 thx
 
 
 On Tue, Nov 25, 2014 at 11:57 AM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:
 
  +1
 
  On 25 November 2014 at 10:57, Stephen Connolly 
  stephen.alan.conno...@gmail.com wrote:
 
   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
  
 
 
 
 
 -- 
 -
 Arnaud Héritier
 http://aheritier.net
 Mail/GTalk: aheritier AT gmail DOT com
 Twitter/Skype : aheritier


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

Re: ApacheCon EU 2014, Budapest

[Mark Struberg]

Hiho!

I will attend and arrive monday morning. Sigfried Göschl will also be in 
Budapest.

LieGrue,
strub




 On Wednesday, 5 November 2014, 9:32, Tamas Cservenak t.cserve...@gmail.com 
 wrote:
  Don’t worry about the details. All the kidnapped people will get what they 
 deserve ;)
 
 Thanks,
 ~t~
 
 
 On 1 Nov 2014 at 10:01:35 , tibor17 (tibo...@lycos.com) wrote:
 
 I like red wine, but who is paying? -:)  
 
 
 
 -  
 BR, tibor17  
 --  
 View this message in context: 
 http://maven.40175.n5.nabble.com/Re-ApacheCon-EU-2014-Budapest-tp5811661p5812094.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  


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

Re: Hangout summary?

[Mark Struberg]

I can join pretty much every time from 9:00to 23:00 CEST. Just have been on a 
conference last week.

LieGrue,
strub



On Thursday, 10 July 2014, 8:44, Hervé BOUTEMY herve.bout...@free.fr wrote:
 



Hangouts don't contain any decision nor precise deep analysis on topics or 
work to be done: they are discussions to let people think, share concerns. 
They are recorded, to be able for anybody to hear discussions back and 
eventually write down something if some points starts to give sufficiently 
precise ideas on a proposal which can be followed by concrete developments.

To me, these Hangouts are like discussions during an ApacheCon conference: 
they are discussions, which are good to let people know each other, share 
ideas. But the work to define a plan is still to be done.

I don't know when something like a plan will happen, or even if it will ever 
happen. But discussions are good.
But when a plan on a topic will be done, yes, it will have to be written down 
to be worked on not only by people who listened to the Hangout (live or 
recorded): my hope is that it will be easier to write something because a part 
of the concerns will have been already shared.

Regards,

Hervé


Le mercredi 9 juillet 2014 14:16:06 Olivier Lamy a écrit :
 I don't really mind participating.
 I just want to be able to read what happened in an async way (notes in
 our wiki or in the web site).
 As it I'm able to react on something I will read (even if I don't
 participate in this hangout or in an irc discussion)
 
 IMHO a lot of people are in the same state.
 
 Olivier
 
 On 4 July 2014 07:52, Mark Derricutt m...@talios.com wrote:
  On 4 Jul 2014, at 9:33, Robert Scholte wrote:
  If I'm correct, following have joined at least 2 times or are Maven PMC
  22:00-23:00 (CEST) Robert Scholte, Hervé Boutemy, Karl-Heinz Marbaise,
  Mark Struberg
  21:00-22:00 (IST) Stephen Connolly
  
  The current time for me is 8am Friday - with a 30-40 minute drive to the
  office before hand ( in order to start work at 9:15ish ).
  
  Any earlier would be harsh for me, but better for any .au folk.
  
  Mark
  
  
  -
  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: [DISCUSS] [apache-parent] Xdoclint for Java8 support

[Mark Struberg]

I fear there is not much to discuss. The standard handling of javadoc has not 
changed. 
It's just that the plugin now aborts with an error or reports tons of warnings 
on really peanut situations like a missing @param. 


There are 2 other points we need to take care:

1.) this must only be activated in java 8. If you set the -Xdocling=-missing on 
older javadoc versions, then they report a wrong parameter


2.) the parameters must get split due to a bug in our maven-javadoc-plugin atm.
We cannot write
-Xdoclint=all,-missing 

because the ',' leads to a parameter split and in the 'options' file it ends up 
as 2 parameters:
...

-DXdoclint
-missing
...
which javadoc cannot parse.


I played with it and found a workaround by using separate parameters:
-Xdoclint=all -Xdoclint=-missing -Xdoclint=-html

This version seems to work.
What does it do? The javadoc warnings are basically fine imo (thus enabling 
'all'). But logging a line or even breaking the build if a @param is missing is 
just ridiculous. I hate having all the empty (and thus useless) @param , 
@return, @throws lines if they contain no valuable info...
The same thing happens with html all the time. Javadoc doesn't seem to natively 
understand xhtml. So writing a /p causes an error. Which is really odd...



As you already did say: we do not like to have all 250 projects depending on 
apache-parent to implement all this on their own ;)

LieGrue,
strub

On Thursday, 1 May 2014, 22:33, Robert Scholte rfscho...@apache.org wrote:
 
Hi Mark,

I think we need to make a decision for the plugin first on how to handle  
this.

IMHO it's not the task of the maven-javadoc-plugin to maintain backwards  
compatibility because Oracle has decided to change the behavior.
However, if we keep it like it is, we'll get a huge number of jira issues  
blaming the maven-javadoc-plugin to be broken.

Since we can't tell if the javadoc errors were based old or new code  
changes, we might need to give a message/disclaimer describing that the  
build could have failed due to the changes of the javadoc executable.
Add to that message the xdoclint options to get the original behavior.

regarding the parent, we probably also want to add -reference ( as  
suggested by one of the Oracle developers )

thanks,
Robert

Op Thu, 01 May 2014 12:15:45 +0200 schreef Mark Struberg  
strub...@yahoo.de:


 Hi!

 Building with Java8 breaks buiding JavaDocs many existing maven projects.
 And thus most times also breaks releasing them.

 The reason is that they enabled all warnings and errors now by default.
 This means that we get tons of oddly broken builds because it also  
 breaks for missing @param, etc.

 I first had
 additionalparam-Xdoclint:none/additionalparam
 But this is way too strict for apache-parent

 My next try was
 additionalparam-Xdoclint:all,-missing/additionalparam
 But this triggers a bug in maven-javadoc-plugin because the comma gets  
 used for splitting the parameters. And

 -Xdoclint:all,-missing

 is really different to
 -Xdoclint:all
 -missing

 You can check it yourself in ./target/site/apidocs/options of your own  
 projects.

 What seems to work is splitting them up into 2 parameters:

 additionalparam-Xdoclint:all -Xdoclint:-missing/additionalparam


 Should we add this to apache-parent?
 Any other doclint tweaks you like to do for it?

 LieGrue,
 strub

 -
 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] Apache Maven Shade Plugin 2.3

[Mark Struberg]

+1

LieGrue,
strub





 On Thursday, 1 May 2014, 10:22, Kristian Rosenvold 
 kristian.rosenv...@gmail.com wrote:
  +1
 
 
 
 2014-05-01 6:48 GMT+02:00 Olivier Lamy ol...@apache.org:
 
  my +1
 
 
  On 29 April 2014 15:24, Olivier Lamy ol...@apache.org wrote:
   Hi,
   I'd like to release Apache Maven Shade Plugin 2.3.
   The main goal is to fix java 1.8 usage.
   We fixed 2 issues:
  
 
 http://jira.codehaus.org/secure/ReleaseNote.jspa?version=19828styleName=TextprojectId=11540
  
   Staging repository:
   https://repository.apache.org/content/repositories/maven-1021/
  
   Staged site:
  http://maven.apache.org/plugins-archives/maven-shade-plugin-LATEST/
  
   Vote open for 72H
  
   [+1]
   [0]
   [-1]
  
   Cheers,
   --
   Olivier Lamy
   Ecetera: http://ecetera.com.au
   http://twitter.com/olamy | http://linkedin.com/in/olamy
 
 
 
  --
  Olivier Lamy
  Ecetera: http://ecetera.com.au
  http://twitter.com/olamy | http://linkedin.com/in/olamy
 
  -
  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

[DISCUSS] [apache-parent] Xdoclint for Java8 support

[Mark Struberg]

Hi!

Building with Java8 breaks buiding JavaDocs many existing maven projects. 
And thus most times also breaks releasing them.

The reason is that they enabled all warnings and errors now by default.
This means that we get tons of oddly broken builds because it also breaks for 
missing @param, etc.

I first had 
additionalparam-Xdoclint:none/additionalparam
But this is way too strict for apache-parent

My next try was 
additionalparam-Xdoclint:all,-missing/additionalparam
But this triggers a bug in maven-javadoc-plugin because the comma gets used for 
splitting the parameters. And 

 -Xdoclint:all,-missing

is really different to 
 -Xdoclint:all
 -missing

You can check it yourself in ./target/site/apidocs/options of your own projects.

What seems to work is splitting them up into 2 parameters:

additionalparam-Xdoclint:all -Xdoclint:-missing/additionalparam


Should we add this to apache-parent?
Any other doclint tweaks you like to do for it?

LieGrue,
strub

-
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.17

[Mark Struberg]

+1 (binding)

LieGrue,
strub





On Wednesday, 12 March 2014, 22:53, Andreas Gudian andreas.gud...@gmail.com 
wrote:
 
Hi,

long ago since we released the last Surefire version. It's about time we
change that ;-).

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

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-1012
https://repository.apache.org/content/repositories/maven-1012/org/apache/maven/plugins/maven-surefire-plugin/2.17/maven-surefire-plugin-2.17-sources.jar
https://repository.apache.org/content/repositories/maven-1012/org/apache/maven/plugins/maven-failsafe-plugin/2.17/maven-failsafe-plugin-2.17-sources.jar
Source: https://git-wip-us.apache.org/repos/asf/maven-surefire.git tag
surefire-2.17_vote-1

Staging site:
http://maven.apache.org/surefire-archives/surefire-2.17/maven-surefire-plugin/index.html
http://maven.apache.org/surefire-archives/surefire-2.17/maven-failsafe-plugin/index.html
http://maven.apache.org/surefire-archives/surefire-2.17/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 Checkstyle Plugin version 2.12

[Mark Struberg]

+1

and thanks for pushing this, Dennis!


LieGrue,
strub





 On Saturday, 8 March 2014, 23:50, Dennis Lundberg denn...@apache.org wrote:
  Hi,
 
 We solved 15 issues:
 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11127styleName=Htmlversion=19723
 
 There are still a couple of issues left in JIRA:
 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11127status=1
 
 Staging repo:
 https://repository.apache.org/content/repositories/maven-1010/
 https://repository.apache.org/content/repositories/maven-1010/org/apache/maven/plugins/maven-checkstyle-plugin/2.12/maven-checkstyle-plugin-2.12-source-release.zip
 
 Source release checksum(s):
 maven-checkstyle-plugin-2.12-source-release.zip sha1:
 1d2c6435e214daa9bedce6d32871a8b7ac3f
 
 Staging site:
 http://maven.apache.org/plugins-archives/maven-checkstyle-plugin-LATEST/
 
 Guide to testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html
 
 Vote is 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
 

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

Re: [VOTE] Release ASF Parent POM version 14

[Mark Struberg]

+1

LieGrue,
strub





 On Thursday, 6 March 2014, 22:19, Hervé BOUTEMY herve.bout...@free.fr wrote:
  Hi,
 
 Changes since the last release: 
 http://svn.apache.org/viewvc/maven/pom/tags/apache-14/pom.xml?r1=HEADr2=1434717diff_format=h
 
 Staging repo: 
 https://repository.apache.org/content/repositories/orgapacheapache-1000/
 https://repository.apache.org/content/repositories/orgapacheapache-1000/org/apache/apache/14/apache-14-source-release.zip
 
 Source release checksum:
 apache-14-source-release.zip sha1: 6bed0856a4cc8d9ee5f4481b8a1e0a4460076073
 
 Staging site: 
 http://maven.apache.org/pom-archives/asf-LATEST/ 
 
 Guide to testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html
 
 Vote open for 72 hours.
 
 [ ] +1
 [ ] +0
 [ ] -1
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


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

Re: [VOTE] Release Apache Maven Filtering version 1.2

[Mark Struberg]

+1

LieGrue,
strub





 On Saturday, 8 March 2014, 17:13, Hervé BOUTEMY herve.bout...@free.fr wrote:
  +1
 
 Regards,
 
 Hervé
 
 Le jeudi 6 mars 2014 22:08:10 Robert Scholte a écrit :
  Hi,
 
  We solved 5 issues:
 
 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761version=187
  29styleName=Html
 
  There is still 1 issue left in JIRA:
 
 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11761sta
  tus=1component=13380
 
  Staging repo:
  https://repository.apache.org/content/repositories/maven-1009/
 
 https://repository.apache.org/content/repositories/maven-1009/org/apache/mav
  en/shared/maven-filtering/1.2/maven-filtering-1.2-source-release.zip
 
  Source release checksum(s):
  maven-filtering-1.2-source-release.zip sha1:
  50185091c5be24ee3a01296224d9d4eee77852c9
 
  Staging site:
  http://maven.apache.org/shared-archives/maven-filtering-LATEST/
 
  Guide to testing staged releases:
  http://maven.apache.org/guides/development/guide-testing-releases.html
 
  Vote open for 72 hours.
 
  [ ] +1
  [ ] +0
  [ ] -1
 
  thanks,
 
  Robert
 
  -
  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


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

Re: [VOTE] Release Maven Release version 2.5

[Mark Struberg]

+1 (binding)

src looks good, did a small local test release on a simple project which did 
run fine.

txs and LieGrue,
strub





On Sunday, 23 February 2014, 15:50, Benson Margulies bimargul...@gmail.com 
wrote:
 
Hi,

maven-release is a component that provides the maven-release-manager
and the maven-release-plugin.

This release integrates version 1.9 of Maven SCM, which addresses a
number of problems with git.

We resolved 10 issues:



** Bug
    * [MRELEASE-166] - release:prepare should always check for local
modifications
    * [MRELEASE-263] - Interactive plugins cannot work in forked executions
    * [MRELEASE-581] - Git relative pathing broken with release plugin
    * [MRELEASE-719] - No error when release:prepare with an already
existing scm tag
    * [MRELEASE-812] - prepare does not commit before tagging and
therefore deploys snapshot instead of release
    * [MRELEASE-862] - Upgrade to Apache Maven SCM 1.9



** Improvement
    * [MRELEASE-682] - support for git svn

** New Feature
    * [MRELEASE-431] - Configuration of policy for calculating next
(release) version


** Task
    * [MRELEASE-356] - deprecate the automated release profile
    * [MRELEASE-753] - Upgrade to JUnit 4.x



There are still a couple of issues left in JIRA:
http://jira.codehaus.org/browse/MRELEASE-512?jql=project%20%3D%20MRELEASE%20AND%20status%20%3D%20Open%20ORDER%20BY%20updated%20DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-1008
http://repository.apache.org/content/repositories/maven-1008/org/apache/maven/release/maven-release/2.5/maven-release-2.5-source-release.zip

Source release checksum(s):
maven-release-source-release.zip sha1: 28311e1bb0f1cee37f66e28700e03d4644d4b3ac

Staging site:
http://maven.apache.org/maven-release-archives/maven-release-2.5/

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

Vote open for 72 hours.

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

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

Re: [VOTE] Maven 2.x is end of life

[Mark Struberg]

+1

LieGrue,
strub





On Thursday, 13 February 2014, 18:42, Andreas Gudian andreas.gud...@gmail.com 
wrote:
 
+1

:-)

Am Donnerstag, 13. Februar 2014 schrieb Hervé BOUTEMY :

 +1

 Regards,

 Hervé

 Le jeudi 13 février 2014 15:14:03 Stephen Connolly a écrit :
  We have not made a release of Maven 2.x since 2.2.1 which was August
 2009.
 
  During that period no release manager has stepped up to cut a release.
 
  I would argue that we should just therefore just declare Maven 2.x as end
  of life.
 
  This vote is therefore to resolve this issue.
 
  The vote will be decided on the basis of committer votes cast. If the
  majority of votes from committers (which includes PMC members) are in
  favour then we will declare 2.x end of life.
 
  If you are a committer and voting -1, then we will assume that you are
  willing to step up and act as a release manager to get a 2.2.2 release
 out
  (which would hopefully include being able to not barf on
 maven-metadata.xml
  that uses the snapshotVersions schema generated by Maven 3.x but the
  release manager gets to decide what it is they want to release)
 
  The decision on this is actually quite simple as if there is nobody
  committer to act as a release manager for the 2.x line, then it is end of
  life.
 
  +1: Maven 2.x is end of life, I am not willing to act as release manager
  for this line of releases
  0: I have no opinion
  -1: Maven 2.x is not end of life, I am willing to act as release manager
  for this line of releases
 
  The vote will be open for 72h and may be closed earlier in the unlikely
  event that all Maven committers have cast a vote before the 72h are up.
 
  -Stephen


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

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

Re: [VOTE] Release Apache Maven SCM Publish Plugin version 1.0

[Mark Struberg]

+1

LieGrue,
strub





 On Monday, 3 February 2014, 11:21, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:
  +1
 
 spot checks to confirm that Robert beat me to my standard tests: pass
 
 
 
 On 2 February 2014 11:11, Robert Scholte rfscho...@apache.org wrote:
 
  +1
 
  rat: only approved licenses
  sha1: correct
  zip build: correct
  usage (with -Dscmpublish.skipCheckin): 'svn add' and 'svn 
 remove' confirmed
 
  regards,
 
  Robert
 
  Op Fri, 31 Jan 2014 23:28:51 +0100 schreef Hervé BOUTEMY 
  herve.bout...@free.fr:
 
 
   Hi,
 
  We solved 6 issues:
  http://jira.codehaus.org/secure/ReleaseNote.jspa?
  projectId=12730styleName=Htmlversion=18940
 
  There are still 1 issue left in JIRA:
  http://jira.codehaus.org/secure/IssueNavigator.jspa?
  reset=truepid=12730status=1
 
  Staging repo:
  https://repository.apache.org/content/repositories/maven-1002/
  http://repository.apache.org/content/repositories/maven-
  1002/org/apache/maven/plugins/maven-scm-publish-plugin/1.0/
  maven-scm-publish-plugin-1.0-source-release.zip
 
  Source release checksum(s):
  maven-scm-publish-plugin-1.0-source-release.zip sha1:
  fc295db0c38a0f8302949c272cb2586e91e7da17
 
  Staging site:
 
 http://maven.apache.org/plugins-archives/maven-scm-publish-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
 
 
  -
  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: Maven Core moving to 1.6

[Mark Struberg]

+1

LieGrue,
strub




- Original Message -
 From: Stephen Connolly stephen.alan.conno...@gmail.com
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Saturday, 5 October 2013, 9:35
 Subject: Re: Maven Core moving to 1.6
 
 +1
 
 
 On Saturday, 5 October 2013, Jason van Zyl wrote:
 
  Given the vote we had about releases after September does anyone mind if I
  update the source/target levels to 1.6 for the core?
 
  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder,  Apache Maven
  http://twitter.com/jvanzyl
  -
 
 
 
 
 
 
 
 
 
 -- 
 Sent from my phone


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

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

[Mark Struberg]

+1, that's what we also use in DeltaSpike and dozen other projects. 
pushChanges=false + localCheckout=true for the win!

LieGrue,
strub




- Original Message -
 From: Arnaud Héritier aherit...@gmail.com
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Saturday, 14 September 2013, 19:45
 Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
 
G ood practice too. I'm using it also at work and we are doing our
 releases on dedicated branches.
 
 -
 Arnaud
 
 Le 14 sept. 2013 à 19:30, Fred Cooke fred.co...@gmail.com a écrit :
 
  You're in Git now. You don't *have* to push your tag and release 
 commits up
  to the public world until AFTER you've checked they're OK. Or by 
 failed
  release do you mean voted down? They could live on branches until set in
  stone, then merge --ff-only into master at that point, if so.
 
 
  On Sat, Sep 14, 2013 at 7:24 PM, Jason van Zyl ja...@tesla.io 
 wrote:
 
  When a release fails like this it is annoying to have to rev back the
  version of the POM. I'm not sure who flipped the versions in the 
 POM and
  while it's a little more visible to see what you're moving 
 toward I prefer
  the pattern of:
 
  3.1-SNAPSHOT -- 3.1.1 -- 3.1-SNAPSHOT -- 3.1.2 -- 
 3.1-SNAPSHOT
 
  I know this may not be obvious to the casual observer as they may think
  3.1 is next, but I'm personally fine with that.
 
  Especially after a failed release because then I don't have to go 
 change
  all the POMs (whether rolling back manually, using the release 
 rollback,
  the version:set command, or whatever else). It's much easier to 
 just fix
  what's necessary and carry on.
 
  Unless anyone objects I would like to go back this pattern, what I
  previously had, because it's far easier to manage. Ideally it might 
 be nice
  if all the tools understood 3.1.z-SNAPSHOT but they don't an in 
 lieu of
  that I would prefer not to diddle POMs after a failed release.
 
  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder,  Apache Maven
  http://twitter.com/jvanzyl
  -
 
 
 
 
 
 
 
 
 
 -
 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: Leaving Maven Core POMs at major.minor-SNAPSHOT

[Mark Struberg]

In DeltaSpike I always push the release branch + tag to my personal github 
repo. After the VOTE did succeed I push the exact sha1 upstream to the ASF repo.

This is not perfect but it's good enough imo as the parent commit is verifiable 
coming from the ASF upstream repo.
Plus people can check that the tag they voted on is exactly the same I push to 
the ASF repo later. 

The only minor downside is that you really need to merge in the pom version 
upgrade to the upstream master branch which might have changes already. 


LieGrue,
strub



- Original Message -
 From: Jason van Zyl ja...@tesla.io
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Saturday, 14 September 2013, 20:47
 Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
 
 We need a slight modification of this strategy because the changes need to be 
 pushed somewhere so that people can examine the tag if they want during the 
 release. I can't keep it on my machine until the vote passes.
 
 On Sep 14, 2013, at 2:20 PM, Mark Struberg strub...@yahoo.de wrote:
 
  +1, that's what we also use in DeltaSpike and dozen other projects. 
  pushChanges=false + localCheckout=true for the win!
 
  LieGrue,
  strub
 
 
 
 
  - Original Message -
  From: Arnaud Héritier aherit...@gmail.com
  To: Maven Developers List dev@maven.apache.org
  Cc: 
  Sent: Saturday, 14 September 2013, 19:45
  Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
 
  G ood practice too. I'm using it also at work and we are doing our
  releases on dedicated branches.
 
  -
  Arnaud
 
  Le 14 sept. 2013 à 19:30, Fred Cooke fred.co...@gmail.com a 
 écrit :
 
  You're in Git now. You don't *have* to push your tag and 
 release 
  commits up
  to the public world until AFTER you've checked they're OK. 
 Or by 
  failed
  release do you mean voted down? They could live on branches until 
 set in
  stone, then merge --ff-only into master at that point, if so.
 
 
  On Sat, Sep 14, 2013 at 7:24 PM, Jason van Zyl 
 ja...@tesla.io 
  wrote:
 
  When a release fails like this it is annoying to have to rev 
 back the
  version of the POM. I'm not sure who flipped the versions 
 in the 
  POM and
  while it's a little more visible to see what you're 
 moving 
  toward I prefer
  the pattern of:
 
  3.1-SNAPSHOT -- 3.1.1 -- 3.1-SNAPSHOT -- 3.1.2 
 -- 
  3.1-SNAPSHOT
 
  I know this may not be obvious to the casual observer as they 
 may think
  3.1 is next, but I'm personally fine with that.
 
  Especially after a failed release because then I don't have 
 to go 
  change
  all the POMs (whether rolling back manually, using the release 
  rollback,
  the version:set command, or whatever else). It's much 
 easier to 
  just fix
  what's necessary and carry on.
 
  Unless anyone objects I would like to go back this pattern, 
 what I
  previously had, because it's far easier to manage. Ideally 
 it might 
  be nice
  if all the tools understood 3.1.z-SNAPSHOT but they don't 
 an in 
  lieu of
  that I would prefer not to diddle POMs after a failed release.
 
  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder,  Apache Maven
  http://twitter.com/jvanzyl
  -
 
 
 
 
 
 
 
 
 
  -
  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,  Apache Maven
 http://twitter.com/jvanzyl
 -


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

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

[Mark Struberg]

The question is not whether you do this on a branch or not, but only where to 
push this branch to and where people do the validation for the VOTE. 

GIT repos at the ASF have a strict history-rewrite policy and don't allow to 
ditch stuff. I'm not 100% sure myself if this is also for deleting upstream 
branches on the central repo. 

What might be a solution would be to have a 2nd 'sandbox' GIT repo for each of 
our 'main' GIT repos for a project. The master of this sandbox GIT repo would 
automatically get replicated from the main repo and would deny any push to 
master otherwise. This repo could be used to create temporary playground like 
feature branches etc. History rewrite and deleting branches and tags would be 
allowed on this repo. Might be a way to tackle this on ASF hardware without 
forcing people to use another repo hosting.

LieGrue,
strub




- Original Message -
 From: Fred Cooke fred.co...@gmail.com
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Saturday, 14 September 2013, 20:48
 Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
 
 Branches.
 
 
 On Sat, Sep 14, 2013 at 8:47 PM, Jason van Zyl ja...@tesla.io wrote:
 
  We need a slight modification of this strategy because the changes need to
  be pushed somewhere so that people can examine the tag if they want during
  the release. I can't keep it on my machine until the vote passes.
 
  On Sep 14, 2013, at 2:20 PM, Mark Struberg strub...@yahoo.de wrote:
 
   +1, that's what we also use in DeltaSpike and dozen other 
 projects.
   pushChanges=false + localCheckout=true for the win!
  
   LieGrue,
   strub
  
  
  
  
   - Original Message -
   From: Arnaud Héritier aherit...@gmail.com
   To: Maven Developers List dev@maven.apache.org
   Cc:
   Sent: Saturday, 14 September 2013, 19:45
   Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
  
   G ood practice too. I'm using it also at work and we are doing 
 our
   releases on dedicated branches.
  
   -
   Arnaud
  
   Le 14 sept. 2013 à 19:30, Fred Cooke fred.co...@gmail.com 
 a écrit :
  
   You're in Git now. You don't *have* to push your tag 
 and release
   commits up
   to the public world until AFTER you've checked they're 
 OK. Or by
   failed
   release do you mean voted down? They could live on branches 
 until set
  in
   stone, then merge --ff-only into master at that point, if so.
  
  
   On Sat, Sep 14, 2013 at 7:24 PM, Jason van Zyl 
 ja...@tesla.io
   wrote:
  
   When a release fails like this it is annoying to have to 
 rev back the
   version of the POM. I'm not sure who flipped the 
 versions in the
   POM and
   while it's a little more visible to see what 
 you're moving
   toward I prefer
   the pattern of:
  
   3.1-SNAPSHOT -- 3.1.1 -- 3.1-SNAPSHOT -- 3.1.2 
 --
   3.1-SNAPSHOT
  
   I know this may not be obvious to the casual observer as 
 they may
  think
   3.1 is next, but I'm personally fine with that.
  
   Especially after a failed release because then I don't 
 have to go
   change
   all the POMs (whether rolling back manually, using the 
 release
   rollback,
   the version:set command, or whatever else). It's much 
 easier to
   just fix
   what's necessary and carry on.
  
   Unless anyone objects I would like to go back this 
 pattern, what I
   previously had, because it's far easier to manage. 
 Ideally it might
   be nice
   if all the tools understood 3.1.z-SNAPSHOT but they 
 don't an in
   lieu of
   that I would prefer not to diddle POMs after a failed 
 release.
  
   Thanks,
  
   Jason
  
   --
   Jason van Zyl
   Founder,  Apache Maven
   http://twitter.com/jvanzyl
   -
  
  
  
  
  
  
  
  
  
   
 -
   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,  Apache Maven
  http://twitter.com/jvanzyl
  -
 
 
 
 
 
 
 
 


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

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

[Mark Struberg]

No, a tag and a branch is not only just a label. 

GIT internally has a kind of garbage collection. And once some commits are not 
referenced by another tree they are subject to be dropped from the repo on a 
re-pack which might happen on git-prune or git-gc. But that's nit picking.


The real problem is that our main repo is always pulled to tons of downstream 
repos. And they don't forget anything. This is why I suggest the 2nd repo which 
is a kind of throw-away repo which is not intended for downstream usage.

I fully agree with you that master should be left alone until the VOTE has 
succeeded.


LieGrue,
strub


 From: Fred Cooke fred.co...@gmail.com
To: Maven Developers List dev@maven.apache.org; Mark Struberg 
strub...@yahoo.de 
Sent: Saturday, 14 September 2013, 21:43
Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
 


I believe the strict policy only applies to master branch. The entire concept 
is different anyway, it's just a label. Leave it there, it costs nothing 
except name space. The persistent try-1 try-2 etc tags will also get mirrored 
into perpetuity anyway. Master should likely be left alone during a release 
such that a ff is possible. If changes are required from failed vote, they are 
made on master, then a new branch is forked off, and try again. If not waiting 
for that, a full merge would be OK too, there would be no conflict even if the 
POM had changed in other places. I personally prefer to avoid them where 
possible, though.




On Sat, Sep 14, 2013 at 9:15 PM, Mark Struberg strub...@yahoo.de wrote:

The question is not whether you do this on a branch or not, but only where to 
push this branch to and where people do the validation for the VOTE.

GIT repos at the ASF have a strict history-rewrite policy and don't allow to 
ditch stuff. I'm not 100% sure myself if this is also for deleting upstream 
branches on the central repo.

What might be a solution would be to have a 2nd 'sandbox' GIT repo for each 
of our 'main' GIT repos for a project. The master of this sandbox GIT repo 
would automatically get replicated from the main repo and would deny any push 
to master otherwise. This repo could be used to create temporary playground 
like feature branches etc. History rewrite and deleting branches and tags 
would be allowed on this repo. Might be a way to tackle this on ASF hardware 
without forcing people to use another repo hosting.


LieGrue,
strub




- Original Message -

 From: Fred Cooke fred.co...@gmail.com
 To: Maven Developers List dev@maven.apache.org
 Cc:

 Sent: Saturday, 14 September 2013, 20:48
 Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

 Branches.


 On Sat, Sep 14, 2013 at 8:47 PM, Jason van Zyl ja...@tesla.io wrote:

  We need a slight modification of this strategy because the changes need to
  be pushed somewhere so that people can examine the tag if they want during
  the release. I can't keep it on my machine until the vote passes.

  On Sep 14, 2013, at 2:20 PM, Mark Struberg strub...@yahoo.de wrote:

   +1, that's what we also use in DeltaSpike and dozen other
 projects.
   pushChanges=false + localCheckout=true for the win!
  
   LieGrue,
   strub
  
  
  
  
   - Original Message -
   From: Arnaud Héritier aherit...@gmail.com
   To: Maven Developers List dev@maven.apache.org
   Cc:
   Sent: Saturday, 14 September 2013, 19:45
   Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
  
   G ood practice too. I'm using it also at work and we are doing
 our
   releases on dedicated branches.
  
   -
   Arnaud
  
   Le 14 sept. 2013 à 19:30, Fred Cooke fred.co...@gmail.com
 a écrit :
  
   You're in Git now. You don't *have* to push your tag
 and release
   commits up
   to the public world until AFTER you've checked they're
 OK. Or by
   failed
   release do you mean voted down? They could live on branches
 until set
  in
   stone, then merge --ff-only into master at that point, if so.
  
  
   On Sat, Sep 14, 2013 at 7:24 PM, Jason van Zyl
 ja...@tesla.io
   wrote:
  
   When a release fails like this it is annoying to have to
 rev back the
   version of the POM. I'm not sure who flipped the
 versions in the
   POM and
   while it's a little more visible to see what
 you're moving
   toward I prefer
   the pattern of:
  
   3.1-SNAPSHOT -- 3.1.1 -- 3.1-SNAPSHOT -- 3.1.2
 --
   3.1-SNAPSHOT
  
   I know this may not be obvious to the casual observer as
 they may
  think
   3.1 is next, but I'm personally fine with that.
  
   Especially after a failed release because then I don't
 have to go
   change
   all the POMs (whether rolling back manually, using the
 release
   rollback,
   the version:set command, or whatever else). It's much
 easier to
   just fix
   what's necessary and carry on.
  
   Unless anyone objects I would like to go back this
 pattern, what I
   previously had, because it's far easier to manage.
 Ideally it might
   be nice
   if all

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

[Mark Struberg]

I think it's mainly because the maintenance and housekeeping costs on the JIRA 
front and others which use the version nr as reference.


Imagine that you would need to move all the JIRA tickets which got marked as 
fixed in a certain release as well. Otherwise the release notes would be broken 
- or would need to get maintained manually.


LieGrue,
strub



- Original Message -
 From: Fred Cooke fred.co...@gmail.com
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Saturday, 14 September 2013, 21:51
 Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
 
 I agree on skipping failed versions! I was avoiding the topic because it
 seemed popular opinion was to re-spin endlessly like a child's spinning top.
 
 
 On Sat, Sep 14, 2013 at 9:47 PM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:
 
  Why as long as you don't push the tag, there's no big deal. Pushing 
 the tag
  is when problems appear... In any case I'd prefer to just skip failed
  version numbers... Though I was voted down last time that came up, and
  given I'm not running too many releases at the moment, I don't see 
 my
  opinion as being heavyweight on that subject... Version numbers are cheap
  and we've had borked releases before (eg critical IMHO bugs in 2.1.0, 
 2.2.0
  and 3.1.0...) so I don't buy the what if a user checks out a tag 
 that was
  not released argument.
 
  In my opinion we need a release status page anyway, eg stating whether
  specific versions are considered stabilising, stable, retired or advised
  not to be used... Such a page would remove the need for recycling version
  numbers *and* provide benefit to users at the same time.
 
  But I will leave it for others to fight the relative costs of version
  numbers (given the infinite supply) against making sure JIRA release notes
  and javadoc @since tags (which is stupid, @since 3.2.3 means it should be
  there in the 3.3.0 release that 3.2.3 became, so no fix strictly
  required) are correct and saving the risk that a user checks out an
  unreleased tag and tries to build that from source and then starts trying
  to raise bugs against a non-exist any version!
 
  On Saturday, 14 September 2013, Jason van Zyl wrote:
 
   We need a slight modification of this strategy because the changes 
 need
  to
   be pushed somewhere so that people can examine the tag if they want
  during
   the release. I can't keep it on my machine until the vote passes.
  
   On Sep 14, 2013, at 2:20 PM, Mark Struberg strub...@yahoo.de 
 wrote:
  
+1, that's what we also use in DeltaSpike and dozen other 
 projects.
pushChanges=false + localCheckout=true for the win!
   
LieGrue,
strub
   
   
   
   
- Original Message -
From: Arnaud Héritier aherit...@gmail.com
To: Maven Developers List dev@maven.apache.org
Cc:
Sent: Saturday, 14 September 2013, 19:45
Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
   
G ood practice too. I'm using it also at work and we are 
 doing our
releases on dedicated branches.
   
-
Arnaud
   
Le 14 sept. 2013 à 19:30, Fred Cooke 
 fred.co...@gmail.com a écrit :
   
You're in Git now. You don't *have* to push your 
 tag and release
commits up
to the public world until AFTER you've checked 
 they're OK. Or by
failed
release do you mean voted down? They could live on 
 branches until set
   in
stone, then merge --ff-only into master at that point, if 
 so.
   
   
On Sat, Sep 14, 2013 at 7:24 PM, Jason van Zyl 
 ja...@tesla.io
wrote:
   
When a release fails like this it is annoying to have 
 to rev back
  the
version of the POM. I'm not sure who flipped the 
 versions in the
POM and
while it's a little more visible to see what 
 you're moving
toward I prefer
the pattern of:
   
3.1-SNAPSHOT -- 3.1.1 -- 3.1-SNAPSHOT -- 
 3.1.2 --
3.1-SNAPSHOT
   
I know this may not be obvious to the casual observer 
 as they may
   think
3.1 is next, but I'm personally fine with that.
   
Especially after a failed release because then I 
 don't have to go
change
all the POMs (whether rolling back manually, using 
 the release
rollback,
the version:set command, or whatever else). It's 
 much easier to
just fix
what's necessary and carry on.
   
Unless anyone objects I would like to go back this 
 pattern, what I
previously had, because it's far easier to 
 manage. Ideally it might
be nice
if all the tools understood 3.1.z-SNAPSHOT but they 
 don't an in
lieu of
that I would prefer not to diddle POMs after a failed 
 release.
   
Thanks,
   
Jason
   

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

Re: What is the correct Git SCM URL for a branch?

[Mark Struberg]

I found that most people use 
pushChangesfalse and 
localCheckouttrue

Which renders most of the tag stuff useless in GIT.

LieGrue,
strub




- Original Message -
 From: Fred Cooke fred.co...@gmail.com
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Saturday, 10 August 2013, 15:19
 Subject: Re: What is the correct Git SCM URL for a branch?
 
 Convention over configuration is fine. Dictatorships end badly. Make it the
 convention, and allow it to be configured off. This is where Maven has
 always failed from time to time, especially in the old days. The less it's
 true, the better.
 
 On Sat, Aug 10, 2013 at 3:13 PM, Olivier Lamy ol...@apache.org wrote:
 
  On 10 August 2013 23:06, Fred Cooke fred.co...@gmail.com wrote:
   Please keep such information leakage optional. The editing of, and 
 indeed
   adding of, the tag element by the release plugin should 
 already be
   optional IMO.
 
  Why?
  With such information I know which tag has been used to build
  artifacts. (
 
 http://repo.maven.apache.org/maven2/org/apache/maven/maven/3.0.5/maven-3.0.5.pom
  )
  Without this it's not possible with only the git url.
  For people/tools using scm informations for rebuilding packages etc..
  it can be very interesting.
 
 
  Especially if it breaks formatting of the POM, which it does
   in some cases, at least. And yeah, I know why, and I know it's not 
 a
   trivial fix. (Thanks to Robert for educating me many months ago).
  
   On Sat, Aug 10, 2013 at 2:54 PM, Olivier Lamy ol...@apache.org 
 wrote:
  
   On 10 August 2013 21:12, Dennis Lundberg 
 denn...@apache.org wrote:
Hi,
   
I'm looking at the sources for Maven core in Git, which 
 I'm learning
as I go along.
   
master is at version 3.1.1-SNAPSHOT and has this 
 in its pom.xml
      scm
        connectionscm:git:
   
 https://git-wip-us.apache.org/repos/asf/maven.git/connection
        developerConnectionscm:git:
   
 https://git-wip-us.apache.org/repos/asf/maven.git/developerConnection
       
 urlhttps://git-wip-us.apache.org/repos/asf?p=maven.git/url
        tagHEAD/tag
      /scm
   
The head maven-3.0.x is at version 3.0.6-SNAPSHOT 
 and has this in
  its
   pom.xml
      scm
        connectionscm:git:
   
 https://git-wip-us.apache.org/repos/asf/maven.git/connection
        developerConnectionscm:git:
   
 https://git-wip-us.apache.org/repos/asf/maven.git/developerConnection
       
 urlhttps://git-wip-us.apache.org/repos/asf?p=maven.git/url
        tagHEAD/tag
      /scm
   
Since this is identical to what is in master I 
 don't think this
would work if you tried to do a release using the Release 
 Plugin.
Wouldn't that release what is specified in tag 
 i.e. HEAD. Now, I
have looked through our documentation and used Google to find 
 a
solution, but to no avail. From what I have gathered we 
 should change
the value of tag, but to what? Would it involve
ref/heads/maven-3.0.x?
   
The head maven-2.2.x is at version 
 2.2.2-RC1-SNAPSHOT and has this
in its pom.xml
      scm
        connectionscm:svn:
   http://svn.apache.org/repos/asf/maven/maven-2/branches/maven-2.2.x
   /connection
        developerConnectionscm:svn:
   
 https://svn.apache.org/repos/asf/maven/maven-2/branches/maven-2.2.x
   /developerConnection
        url
  http://svn.apache.org/viewvc/maven/maven-2/branches/maven-2.2.x
   /url
      /scm
   
Obviously this has not been updated since the move to Git, 
 which is
one of the things I'm trying to fix.
  
   scm url will be the same for all branches.
   It simply depend of the branch you are working on locally.
   btw the tagHEAD/tag in maven-3.0.x branch is 
 wrong.
   IHMO It's something to improve in the release plugin to put 
 here the
   current branch in use.
  
   
Hopefully someone who has made a release using Maven Release 
 Plugin
from a Git branch can shed some light on this.
   
--
Dennis Lundberg
   

 -
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
   
  
  
  
   --
   Olivier Lamy
   Ecetera: http://ecetera.com.au
   http://twitter.com/olamy | http://linkedin.com/in/olamy
  
   
 -
   To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
   For additional commands, e-mail: dev-h...@maven.apache.org
  
  
 
 
 
  --
  Olivier Lamy
  Ecetera: http://ecetera.com.au
  http://twitter.com/olamy | http://linkedin.com/in/olamy
 
  -
  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.15

[Mark Struberg]

+1

LieGrue,
strub




- Original Message -
 From: Andreas Gudian andreas.gud...@gmail.com
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Friday, 7 June 2013, 8:29
 Subject: [VOTE] Release Maven Surefire Plugin version 2.15
 
 Hi,
 
 This is my first release, so please check carefully what I may have missed
 :).
 
 We solved 16 issues:
 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541version=19174
 
 This is the first release that does not support JVM versions prior 1.5 to
 be forked.
 
 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-075
 https://repository.apache.org/content/repositories/maven-075/org/apache/maven/plugins/maven-surefire-plugin/2.15/maven-surefire-plugin-2.15-sources.jar
 https://repository.apache.org/content/repositories/maven-075/org/apache/maven/plugins/maven-failsafe-plugin/2.15/maven-failsafe-plugin-2.15-sources.jar
 Source: https://git-wip-us.apache.org/repos/asf/maven-surefire.git tag
 surefire-2.15
 
 Staging site:
 http://maven.apache.org/surefire-archives/maven-surefire-2.15/maven-surefire-plugin/index.html
 http://maven.apache.org/surefire-archives/maven-surefire-2.15/maven-failsafe-plugin/index.html
 http://maven.apache.org/surefire-archives/maven-surefire-2.15/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: [VOTE] Apache 3.1.0-alpha-1 (Take 4)

[Mark Struberg]

+1

did run it the last 2 days on many of my projects without any issues.

LieGrue,
strub




- Original Message -
 From: Brian Fox bri...@infinity.nu
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Tuesday, 4 June 2013, 18:13
 Subject: Re: [VOTE] Apache 3.1.0-alpha-1 (Take 4)
 
 +1
 
 On Sat, Jun 1, 2013 at 9:13 AM, Jason van Zyl ja...@tesla.io wrote:
  Here are the release bits for 3.1.0-alpha-1:
 
  Release notes:
 
 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967
 
  Staging repository:
  https://repository.apache.org/content/repositories/maven-046/
 
  Staged distribution:
 
 https://repository.apache.org/content/repositories/maven-046/org/apache/maven/apache-maven/3.1.0-alpha-1/
 
  Staged Site:
  http://maven.apache.org/ref/3.1.0-alpha-1
 
  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder  CTO, Sonatype
  Founder,  Apache Maven
  http://twitter.com/jvanzyl
  -
 
  First, the taking in of scattered particulars under one Idea,
  so that everyone understands what is being talked about ... Second,
  the separation of the Idea into parts, by dividing it at the joints,
  as nature directs, not breaking any limb in half as a bad carver might.
 
    -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
 
 
 
 
 
 
 -
 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] Apache 3.1.0-alpha-1

[Mark Struberg]

alpha-1 to n works fine imo. We should not loose pace by holding up the effort 
with such minor stuff.

LieGrue,
strub




- Original Message -
 From: Baptiste Mathus bmat...@gmail.com
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Wednesday, 29 May 2013, 8:47
 Subject: Re: [VOTE] Apache 3.1.0-alpha-1
 
 Le 29 mai 2013 08:07, Mirko Friedenhagen 
 mfriedenha...@gmail.com a
 écrit :
 
  On May 29, 2013 7:49 AM, jieryn jie...@gmail.com wrote:
  
   Greetings,
  
   On Wed, May 29, 2013 at 1:36 AM, Hervé BOUTEMY 
 herve.bout...@free.fr
  wrote:
I'd like to work on Arnaud's idea of error message 
 enhancement in
 case a
plugin fails because of unavailable Sonatype Aether: if you can 
 let me
  12 more
hours from now, I'll do it tonight
  
   Version numbers are cheap. Can't we just make an alpha-2?
 
  +1 to Jesse's suggestion. In every other software reusing version 
 numbers
  is a nono.
 
 Though tempting, I only agree with you for pre-releases (alpha, beta ...).
 I think this would create more mess for users having non qualified versions
 in the wild that have actually been garbage from the beginning... average
 users wont look at pre-release anyway.
 
 Cheers


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

Re: [VOTE] Release Maven Release Plugin version 2.4.1

[Mark Struberg]

+1

LieGrue,
strub




- Original Message -
 From: Robert Scholte rfscho...@apache.org
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Monday, March 25, 2013 9:17 PM
 Subject: Re: [VOTE] Release Maven Release Plugin version 2.4.1
 
 +1
 
 Op Sat, 23 Mar 2013 11:57:49 +0100 schreef Robert Scholte  
 rfscho...@apache.org:
 
  Hi,
 
  We solved 4 issues:
 
 http://jira.codehaus.org/secure/ReleaseNote.jspa?styleName=HtmlprojectId=11144version=19050
 
  There are still a couple of issues left in JIRA:
 
 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11144status=1
 
  Staging repo:
  https://repository.apache.org/content/repositories/maven-016/
 
 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/release/maven-release/2.4.1/maven-release-2.4.1-source-release.zip
 
  Staging site:
  http://maven.apache.org/maven-release-archives/maven-release-2.4.1/
 
  Guide to testing staged releases:
  http://maven.apache.org/guides/development/guide-testing-releases.html
 
  Vote open for 72 hours.
 
  [ ] +1
  [ ] +0
  [ ] -1
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


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

Re: [VOTE] Release Maven Indexer 5.1.1

[Mark Struberg]

+1 (for the vote)

and +1 for waiting the full 72h ;)

LieGrue,
strub




- Original Message -
 From: Tamás Cservenák ta...@cservenak.net
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Thursday, March 7, 2013 3:11 PM
 Subject: Re: [VOTE] Release Maven Indexer 5.1.1
 
T rue, it will pass in 3 hrs from now.
 But, as the min requirement for +3 votes were already present, and the
 (bug)fixes were minor,
 I decided to lt it go as soon as votes were casted
 
 Sorry, if someone missed the too short voting.
 
 
 Thanks,
 ~t~
 
 
 On Wed, Mar 6, 2013 at 11:59 PM, Olivier Lamy ol...@apache.org wrote:
 
  Did we pass 72H vote time ? I think not.
 
  2013/3/6 Tamás Cservenák ta...@cservenak.net:
   Vote passed with 3 binding and 1 non-binding votes:
  
   binding votes: Olivier, John and Hervé
   non-binding votes: Igor
  
  
   Thanks for voting! Will continue with release.
  
  
   Thanks,
   ~t~
  
  
   On Wed, Mar 6, 2013 at 2:31 AM, Hervé BOUTEMY 
 herve.bout...@free.fr
  wrote:
  
   +1
  
   Regards,
  
   Hervé
  
   Le lundi 4 mars 2013 18:21:52 Tamás Cservenák a écrit :
Hi,
   
We solved 2 issues:
   
   
   
  
 
 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=12112version=189
88
   
   
There are still a couple of issues left in JIRA:
   
   
  
 
 http://jira.codehaus.org/issues/?jql=project%20%3D%20MINDEXER%20AND%20status
%20%3D%20Open%20ORDER%20BY%20priority%20DESC
   
Staging repo:
   https://repository.apache.org/content/repositories/maven-327/
   
   
Guide to testing staged
releases:
   
 http://maven.apache.org/guides/development/guide-testing-releases.h
tml
   
Vote open for 72 hours.
   
[ ] +1
[ ] +0
[ ] -1
   
   
   
   
Thanks,
   
~t~
  
   
 -
   To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
   For additional commands, e-mail: dev-h...@maven.apache.org
  
  
 
 
 
  --
  Olivier Lamy
  Talend: http://coders.talend.com
  http://twitter.com/olamy | http://linkedin.com/in/olamy
 
  -
  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] formally end support for Maven 1

[Mark Struberg]

+1

LieGrue,
strub




- Original Message -
 From: Ralph Goers ralph.go...@dslextreme.com
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Wednesday, March 6, 2013 8:06 PM
 Subject: Re: [VOTE] formally end support for Maven 1
 
 +1
 
 
 Ralph
 
 On Mar 2, 2013, at 7:18 AM, Benson Margulies wrote:
 
  Based on the sentiment on the discussion thread, I call a formal vote
  to end support for Maven 1.x. This is a vote to:
 
  1: Remove maven 1 release materials from the primary distribution
  area, leaving them only on the archive.
 
  2: Make appropriate changes to the web site to state clearly that the
  community no longer provides support for Maven 1.
 
  This vote will be open for until Wed March 6, 00:00 GMT (we're not in
  a hurry here).
 
  Here is my +1.
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 

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

Re: [VOTE] Apache Maven 3.0.5

[Mark Struberg]

+1

works fine. Tested with a few big real world projects.
rat looks fine, signature ok.

LieGrue,
strub




- Original Message -
 From: Olivier Lamy ol...@apache.org
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Tuesday, February 19, 2013 4:28 PM
 Subject: [VOTE] Apache Maven 3.0.5
 
 Hi,
 We fixed 1 issue:
 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=19088
 
 Staging repository:
 https://repository.apache.org/content/repositories/maven-270/
 
 Staging distribution:
 https://dist.apache.org/repos/dist/dev/maven/maven-3/3.0.5/
 
 Vote open for 72H
 
 [+1]
 [0]
 [-1]
 
 Thanks
 --
 Olivier Lamy
 Talend: http://coders.talend.com
 http://twitter.com/olamy | http://linkedin.com/in/olamy
 
 -
 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] Maven Pmd Plugin 3.0 (take 2)

[Mark Struberg]

+1

LieGrue,
strub




- Original Message -
  On Feb 15, 2013 12:40 AM, Olivier Lamy ol...@apache.org 
 wrote:
 
  ping. one binding +1 is still missing.
  Thanks
 
  2013/2/11 Olivier Lamy ol...@apache.org:
  +1
 
  2013/2/7 Olivier Lamy ol...@apache.org:
  Hi,
  I'd like to release Maven Pmd Plugin 3.0.
  Note this version is based on PMD 5.0.2 (reason for the version 
 bump).
  We fixed 18 issues:
 
 
 https://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+MPMD+AND+fixVersion+%3D+%223.0%22+AND+status+%3D+Closed+ORDER+BY+priority+DESCmode=hide
 
  NOTE: this version use PMD 5.0.2 which is not backwards 
 compatible
  with PMD 4.x (see more details here
  http://pmd.sourceforge.net/pmd-5.0.2/)
 
  Staging repository:
  https://repository.apache.org/content/repositories/maven-216/
 
  Source release:
 
 
 https://repository.apache.org/content/repositories/maven-216/org/apache/maven/plugins/maven-pmd-plugin/3.0/maven-pmd-plugin-3.0-source-release.zip
 
  Staging site:
  http://maven.apache.org/plugins-archives/maven-pmd-plugin-3.0/
 
  Vote open for 72H
 
  [+1]
  [0]
  [-1]
 
  Thanks
 
  --
  Olivier Lamy
  Talend: http://coders.talend.com
  http://twitter.com/olamy | http://linkedin.com/in/olamy
 
 
 
  --
  Olivier Lamy
  Talend: http://coders.talend.com
  http://twitter.com/olamy | http://linkedin.com/in/olamy
 
 
 
  --
  Olivier Lamy
  Talend: http://coders.talend.com
  http://twitter.com/olamy | http://linkedin.com/in/olamy
 
  -
  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
 

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

Re: EOL of 1.5 as minimum

[Mark Struberg]

What are the big features and possibilities we gain from 1.6? 
Build systems are pretty late in the chain. We should still be able to build on 
systems which are 2+ years old.

Is there a technical reason to restrict this or is it just that we don't 
actively support it anymore (not doing IT, etc)?


As comparison: we still supported 1.4 and older until not that far ago ;)


LieGrue,
strub




 From: Baptiste MATHUS m...@batmat.net
To: Maven Developers List dev@maven.apache.org 
Sent: Wednesday, February 6, 2013 10:31 PM
Subject: Re: EOL of 1.5 as minimum
 
+1, bump to JDK6 minimum for Maven.


2013/2/6 Stephen Connolly stephen.alan.conno...@gmail.com

 I think we should at least have a minor version bump on core to
 co-incide... Though I think calling it maven 4.0 might be better (that way
 we catch up with the model version ;-)

 On Wednesday, 6 February 2013, Olivier Lamy wrote:

  Hi,
  As we are now in 2013, it's probably time to think about that (again).
 
  Reading [1], even 1.6 won't be anymore updated after feb 2013.
 
  Can we say we are safe to go to 1.6 as minimum required ?
 
  NOTE: That will probably need a vote. So depending on how the thread
  move, I will start a vote (or not).
 
  Thanks
  --
  Olivier Lamy
  Talend: http://coders.talend.com
  http://twitter.com/olamy | http://linkedin.com/in/olamy
 
  [1] http://www.oracle.com/technetwork/java/eol-135779.html
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:;
  For additional commands, e-mail: dev-h...@maven.apache.orgjavascript:;
 
 

 --
 Baptiste Batmat MATHUS - http://batmat.net
 Sauvez un arbre,
 Mangez un castor ! nbsp;!




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

Re: [VOTE] ASF Parent pom 13 and Maven parent pom 23

[Mark Struberg]

Yes, exactly as Robert explained. 

Previously to this change we created broken JARs.
People always had to do mvn clean install :/

We will continue working on this area. The goal is that a mvn verify on a 
project creates reliable results and only does the work it really needs to do. 
Though in general it's better to compile a bit too much than to create broken 
JARs imo ...

LieGrue,
strub




- Original Message -
 From: Robert Scholte rfscho...@apache.org
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Sunday, January 20, 2013 12:03 PM
 Subject: Re: [VOTE] ASF Parent pom 13 and Maven parent pom 23
 
T his is the intended behavior.
 For instance, if you change a method signature of a class, only this class 
 would 
 be recompiled in the old situation, causing a false positive: classes 
 depending 
 on this method should be recompiled as well. For that reason most users run 
 mvn clean install, where they should only need to run mvn 
 verify, especially in huge multimodule projects.
 Compilers are quite fast, so the bit of loss for recompiling everything is 
 worth 
 the stability.
 But the m-compiler-p seems to be a bit too aggressive sometimes, although 
 more 
 reliable AFAIK.
 
 Robert
 
 Op Sun, 20 Jan 2013 11:15:12 +0100 schreef Tony Chemit 
 che...@codelutin.com:
 
  On Sun, 20 Jan 2013 11:11:31 +0100
  Tony Chemit che...@codelutin.com wrote:
 
  On Sat, 19 Jan 2013 16:46:09 +0100
  Olivier Lamy ol...@apache.org wrote:
 
   2013/1/19 Tony Chemit che...@codelutin.com:
On Thu, 17 Jan 2013 21:17:35 +0100
Olivier Lamy ol...@apache.org wrote:
   
+0.
   
m-compiler-p to 3.0 is it a real good idea ?
   
I tried it, and it did not pleased me to recompile all a 
 module each time there is a single modification inside it.
   
  
   You mean if module B depends on A, change in A - module B 
 recompiled
   ?
 
  No when a java file was modified in a module, then the whole module is 
 recompiled. The message is: Changes detected - recompiling the module!
  I just check doing a touch on a single java file, and the whole module was 
 recompiled :(. But may-be this is the desired behaviour (perso I don't 
 understand why and I don't like this, just really want to avoid recompiling 
 all my classes each time I touch a single one).
 
  If it is a defect, told me I will fill something about it.
 
 
  tony
 
 -
 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] ASF Parent pom 13 and Maven parent pom 23

[Mark Struberg]

+1

LieGrue,
strub




- Original Message -
 From: Olivier Lamy ol...@apache.org
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Thursday, January 17, 2013 9:17 PM
 Subject: [VOTE] ASF Parent pom 13 and Maven parent pom 23
 
 Hi,
 I'd like to release both ASF Parent pom 13 and Maven parent pom 23
 
 ASF Parent pom 13:
 * staging repository:
 https://repository.apache.org/content/repositories/orgapacheapache-142/
 * diff with previous release:
 http://svn.apache.org/viewvc/maven/pom/tags/apache-13/pom.xml?r1=HEADr2=1404788diff_format=h
 
 Maven Parent pom 23:
 * staging repository:
 https://repository.apache.org/content/repositories/maven-143/
 * diff with previous release:
 http://svn.apache.org/viewvc/maven/pom/tags/maven-parent-23/pom.xml?r1=HEADr2=1371599diff_format=h
 
 Vote open for 72H
 [+1]
 [0]
 [-1]
 
 Thanks
 --
 Olivier Lamy
 Talend: http://coders.talend.com
 http://twitter.com/olamy | http://linkedin.com/in/olamy
 
 -
 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: Logging

[Mark Struberg]

Sorry Stephen, I find this comparison unfair. 
Please look how much code has been written and is necessary to get slf4j (and 
any other non MojoLogger impl) really running. And for making it fully work it 
will need even more work because we first need to ship all plugins with an 
upgraded maven-plugin-plugin build.


And most of the log output in projects (surefire) will still funneled via a 
stdio redirecting, so all the benefit is lost for them, isn't?

LieGrue,
strub



- Original Message -
 From: Stephen Connolly stephen.alan.conno...@gmail.com
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Monday, December 17, 2012 3:58 PM
 Subject: Re: Logging
 
 On 17 December 2012 14:46, Olivier Lamy ol...@apache.org wrote:
 
  And what about working on real improvements for users ?
 
  I see:
  * incremental build
  * fixing various bugs on dependency plugin (tree doesn't work well
  since aether: http://jira.codehaus.org/browse/MDEP-392) or this very
  old one (https://jira.codehaus.org/browse/MDEP-187) which have 50
  votes. And IMHO dependency:tree is one of the most important when you
  want to debug to dependencies.
  * some jiras we have for core. link
  (
 
 https://jira.codehaus.org/browse/MNG#selectedTab=com.atlassian.jira.plugin.system.project%3Aissues-panel
  )
  says 648 open issues ! And they are some very blockers/majors here.
  * etc...
 
  Regarding logging, move to slf4j and by default add our own slf4j
  implementation based on the current plexus logging (then we can simply
  provide a plugin for users who want to choose an other impl, this
  plugin will simply update users installations).
 
 
 That sounds like somebody has to write some code... I don't want to write
 some code to handle logging, so I say go for the implementation that
 involves not writing code and be done with it. Of the two left on the table
 by Benson only one is ready without writing more code... unless somebody
 against that option wants to step up and write the code that is ;-)
 
 
  Integrators can simply made their own packaging as they do today.
 
 
 
 
 
  2012/12/16 Benson Margulies bimargul...@gmail.com:
   Since not much has been heard on the 'pick a logger' question 
 for some
   time, I'm going to stick my neck out and try to summarize some
   aspects, in the hopes of discovering how close we are to a consensus.
  
   In the following, I use the word 'want' to express 
 *preference*, not
   non-negotiable demands.
  
   We all need: reasonable performance, an acceptable license (i.e.
   category A or B), a stable, reliable, logger.
  
   Various of us want: MDCs, colorization: a package with a community
   behind it, an avoidance of of EPL, to use our fellow 
 Apache-projects'
   outputs.
  
   We know that: java.util.logging isn't going to give us MDCs or
   colorization without a great deal of effort. So I'm crossing it 
 off in
   this email.
  
   Now, I'm going to express an opinion based on all the email 
 *I've*
   seen. I don't claim to be right, but I wonder if people would be
   willing to follow my logic.
  
   Once we eliminate j.u.l from consideration, our choices are logback,
   log4j 1.x, and log4j 2.x.
  
   It seems to me that log4j 2.x is not really ready for us yet, so in
   this email I'm crossing it off. If we continue to dither for 
 another
   few months, that might change. If someone disagrees, I'm sure 
 they'll
   respond.
  
   log4j1.x is the tried and true alternative. Colorization, however,
   would require significant effort. Those of us who don't give a fig
   about colourization won't be perturbed by this.
  
   logback, on the other hand, is very widely adopted, and no one seems
   to be able to offer any *technical* objection to it. And it gives us
   colorization out of the box.
  
   The objections to logback, then, are cultural, organizational, and/or
   related to license.
  
   In my view, the very broad adoption of logback seems to me to
   neutralize the concern that it's a one-man-band. While one person
   projects present certain risks in the abstract, this particular one
   seems to me not to raise them.
  
   In my view, objecting based on EPL is, as I wrote once before, not
   appropriate. The Maven project erected a barrier to EPL dependencies
   to respond to cases in which core Maven functionality was forked and
   EPL-ified, or just proposed to be replaced by EPL code. The situation
   with logging is simply not analogous. As a project, I don't think 
 we
   need to anticipate wanting to bring the logging system into our
   source. Adding a category B logging dependency does not contribute to
   the 'hollowing out' of Maven.
  
   As a Foundation, category B licenses are just as acceptable as
   category A licenses as dependencies. (I also wonder why this barrier
   was not specifically set up in terms of 'core code replaced by 
 non-A'
   instead of 'EPL').
  
   If I add this all up, to me it amounts to a test. If some member(s) of
   

Re: [VOTE] Maven Shared Utils 0.2

[Mark Struberg]

+1

LieGrue,
strub




- Original Message -
 From: Robert Scholte rfscho...@apache.org
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Sunday, December 16, 2012 12:23 PM
 Subject: Re: [VOTE] Maven Shared Utils 0.2
 
 +1
 
 Op Sun, 16 Dec 2012 04:21:50 +0100 schreef Kristian Rosenvold  
 kristian.rosenv...@gmail.com:
 
  Thanks ! https://jira.codehaus.org/browse/MSHARED-267 created.
 
  Kristian
 
  2012/12/15 Hervé BOUTEMY herve.bout...@free.fr:
  +1
 
  a Jira issue to show which methods have been made public would be  
  useful IMHO
 
  Regards,
 
  Hervé
 
  Le jeudi 13 décembre 2012 22:39:50 Kristian Rosenvold a écrit :
   Hi,
 
 
  We solved 1 issue and made a few methods public. This release is
  necessary for surefire 2.13.
 
 
 https://jira.codehaus.org/secure/ReleaseNote.jspa?version=18942styleName=Ht
  mlprojectId=11761
 
 
  There are a few issues left in jira:
 
 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=proj
 
 ect+%3D+MSHARED+AND+component+%3D+maven-shared-utils+AND+status+%3D+Open
 
 
  Staging repo:
  https://repository.apache.org/content/repositories/maven-009/
 
 https://repository.apache.org/content/repositories/maven-009/org/apache/mave
 
 n/shared/maven-shared-utils/0.2/maven-shared-utils-0.2-source-release.zip
 
 
  Staging sites:
  http://maven.apache.org/shared-archives/maven-shared-utils-0.2/
 
 
  Guide to testing staged releases:
 
 http://maven.apache.org/guides/development/guide-testing-releases.html
 
  Vote open for 72 hours.
 
   [ ] +1
   [ ] +0
   [ ] -1
 
  Kristian
 
 
 -
  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
 
 
  -
  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


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

Re: Logback in Maven Core

[Mark Struberg]

I only do those benchmarks on a desktop linux box with the cpu governer set to 
a fixed frequency. 
Imo that's the only way to get reproducible numbers.
Especially when working on a notebook it also depends how much heat the 
notebook can dissipate. I've seen my MBP not using his full turbo when he is 
really hot after benchmarks (even singlethreaded).


LieGrue,
strub




- Original Message -
 From: Kristian Rosenvold kristian.rosenv...@gmail.com
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Wednesday, December 12, 2012 9:35 AM
 Subject: Re: Logback in Maven Core
 
 Yeah, measuring performance on modern cpu's is totally borked. To get
 any real measurements one probably needs to to average of 100 non-stop
 builds or similar, to counter for all the dark magics intel do with
 temperature-based overclocking.
 
 I think I've seen somewhere that it's possible to disable all the
 cpu-voodo in the bios. But what a pain to reboot to change those
 settings ! Or dig out the old Pentium4 from the closet.
 
 Kristian
 
 2012/12/12 Ralph Goers ralph.go...@dslextreme.com:
  I checked out Maven and used its build as a comparison.  First, I ran the 
 log4j 2 build and it was taking around 59 seconds.  I then changed the 
 log4j2.xml to remove the colors.  I then got an average time for Log4j 2 of  
 54.76s and for Logback I get an average of 55.225s.  I consider these 
 differences to be meaningless.
 
  For reference, the log4j2.xml I used is attached.
 
  Ralph
 
 
 
 
 
 
 
 
 
 
  On Dec 11, 2012, at 11:19 PM, Stephen Connolly wrote:
 
  Well I am not going to tar and feather log4j2 based on one set of runs 
 on
  my machine. I would like somebody else to repeat and confirm first as 
 there
  could have been some background OS update or other process stealing CPU
  while doing the 3 log4j2 runs.
 
  Also I do not know if I am comparing the same things. Afaik the log 
 back
  branch has the latest fixes in it, while the log4j2 branch is the 
 colorized
  one from a few weeks back and likely has not got the fixes required for 
 the
  issues you identified with the last 3.1.0 RC
 
  We need to compare like with like to make an informed decision... I am 
 just
  putting some numbers down as a starting point
 
  -Stephen
 
  On Wednesday, 12 December 2012, Kristian Rosenvold wrote:
 
  Finally some interesting numbers, and if (heaven forbid) this 
 decision
  should be based on
  technical grounds, this is one of the first significant pieces to 
 come
  up in this discussion.
 
  Since I am quite unfamiliar with logging (I use loose coupling and
  tests instead ;), I took the opportunity to read
  http://logging.apache.org/log4j/2.x/performance.html Somehow the
  real-life results don't seem to match up with the advertising 
 blurp on
  the log4j site. While it hardly surprises me, I was wondering if
  anyone actually knows why?
 
  Kristian
 
 
 
  2012/12/12 Stephen Connolly 
 stephen.alan.conno...@gmail.comjavascript:;
  :
  The consistent times (i.e. repeated runs after discarding the 
 first) are:
 
  3.0.4: 1min18sec
  logback: 1min13sec
  log4j2: 1min34sec
 
  The second test was building GIT hash
  85dd6e37456d30d2661e10b044efa9036c528023 of jszip-maven-plugin 
 (@
  jszip.org)
  with the following command line:
 
  mvn -o -X clean verify -DskipTests -Dinvoker.skip
 
  [Testing heavy logging]
 
  3.0.4: 12.1sec
  logback: 12.2sec
  log4j2: 12.5sec
 
 
 -
  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
  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


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

Re: Logback in Maven Core

[Mark Struberg]

folks, don't you see it? we cannot use logback as this is a LocationAwareLogger 
and would break all projects which use slf4j  1.6 and older. 
Please go back to the original mail from 4 month where Ceki himself explained 
it!

So -1 on logback


LieGrue,
strub



- Original Message -
 From: Anders Hammar and...@hammar.net
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Tuesday, December 11, 2012 7:57 PM
 Subject: Re: Logback in Maven Core
 
 I'm +1 for logback as the slf4j impl.
 
 /Anders
 
 
 On Tue, Dec 11, 2012 at 3:32 AM, Jason van Zyl ja...@tesla.io wrote:
 
  Hi,
 
  I looked around a bit more today and I don't think SLF4J Simple is 
 viable
  long term, I don't want to patch it anymore as I would have to do a 
 day's
  work to make changes that keep the performance levels up, get it reviewed
  and released, and I honestly don't think it's worth it anymore. I 
 would
  rather spend my time building out the plugin test cases and help to finish
  the classloader blocking of SLF4J. I don't mind spending time getting 
 it
  all working but I don't want to waste my time on an implementation 
 we're
  going to toss.
 
  After a conversation with the PMC it will require a vote to accept Logback
  which is EPL but I wanted to ask committers and interested users about
  using Logback. I believe Logback is the best choice as it's the most 
 mature
  and battle tested implementation because once it goes in it's likely 
 not
  ever to come out. Many of us are users and have integration experience with
  Logback and it's what I use everyday for logging in all my other 
 projects
  and I've been a happy user for years. I see Logback as best of breed 
 and
  widely adopted including 8 projects at Apache.
 
  There's no point in asking the PMC to vote on the acceptance of Logback 
 if
  it's not acceptable by the community. If there are interested users I 
 would
  really like to hear what you think because you're the ones who will 
 have to
  live with the choice that is made.
 
  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder  CTO, Sonatype
  Founder,  Apache Maven
  http://twitter.com/jvanzyl
  -
 
  To do two things at once is to do neither.
 
   -- Publilius Syrus, Roman slave, first century B.C.
 
 
 
 
 
 


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

Re: Logback in Maven Core

[Mark Struberg]

btw, jason mentioned that lots of apache frameworks already use SLF4J. And he 
prominently mentioned CXF.

Now here comes the bitter truth: THEY DROPPED IT AGAIN!

They now use a java.util.logging.Logger facade to redirect to log4j, slf4j or 
whatever
http://svn.apache.org/repos/asf/cxf/trunk/api/src/main/java/org/apache/cxf/common/logging/AbstractDelegatingLogger.java


And now folks please go over and read all the reasons for this move...

Just a small pointer: Why are the following projects and others NOT using slf4j?

* MyFaces
* Tomcat
* Geronimo
* Tomee
* OpenJPA
* OpenWebBeans
* CXF
* younameit

because it doesn't work for containers in all situations.
4 Month of trying to get it working. And still there are a lot cases which are 
known to create problems. Doesn't that ring a bell?

I'm perfectly fine to do the same as CXF and use jul as facade and back it with 
SLF4J or log4j. But there are only 2 ways technically to not introduce 
classpath issues: jul or our very own mojo-logger facade (which is in place 
since 2004).




- Original Message -
 From: Dan Tran dant...@gmail.com
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Tuesday, December 11, 2012 8:55 PM
 Subject: Re: Logback in Maven Core
 
 +1 on for logback.
 
 However, is it possible to switch to Log4j2 by manually repackage
 maven distribution?
 
 Thanks
 
 -D
 
 On Tue, Dec 11, 2012 at 10:57 AM, Anders Hammar and...@hammar.net wrote:
  I'm +1 for logback as the slf4j impl.
 
  /Anders
 
 
  On Tue, Dec 11, 2012 at 3:32 AM, Jason van Zyl ja...@tesla.io 
 wrote:
 
  Hi,
 
  I looked around a bit more today and I don't think SLF4J Simple is 
 viable
  long term, I don't want to patch it anymore as I would have to do a 
 day's
  work to make changes that keep the performance levels up, get it 
 reviewed
  and released, and I honestly don't think it's worth it anymore. 
 I would
  rather spend my time building out the plugin test cases and help to 
 finish
  the classloader blocking of SLF4J. I don't mind spending time 
 getting it
  all working but I don't want to waste my time on an implementation 
 we're
  going to toss.
 
  After a conversation with the PMC it will require a vote to accept 
 Logback
  which is EPL but I wanted to ask committers and interested users about
  using Logback. I believe Logback is the best choice as it's the 
 most mature
  and battle tested implementation because once it goes in it's 
 likely not
  ever to come out. Many of us are users and have integration experience 
 with
  Logback and it's what I use everyday for logging in all my other 
 projects
  and I've been a happy user for years. I see Logback as best of 
 breed and
  widely adopted including 8 projects at Apache.
 
  There's no point in asking the PMC to vote on the acceptance of 
 Logback if
  it's not acceptable by the community. If there are interested users 
 I would
  really like to hear what you think because you're the ones who will 
 have to
  live with the choice that is made.
 
  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder  CTO, Sonatype
  Founder,  Apache Maven
  http://twitter.com/jvanzyl
  -
 
  To do two things at once is to do neither.
 
   -- Publilius Syrus, Roman slave, first century B.C.
 
 
 
 
 
 
 
 -
 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: Logback in Maven Core

[Mark Struberg]

You have to distinguish between plugin dependencies and project dependencies.

For plugin dependencies this can get solved with a new switch in the 
maven-plugin-plugin.
But for user projects this is more complicated. E.g you yourself would not even 
be able to compile a bugfix version of slf4j-1.5 anymore with this new version 
of maven!


LieGrue,
strub



- Original Message -
 From: ceki c...@qos.ch
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Tuesday, December 11, 2012 10:13 PM
 Subject: Re: Logback in Maven Core
 
 On 11.12.2012 21:28, Mark Struberg wrote:
 
  Folks, don't you see it? we cannot use logback as this is a
  LocationAwareLogger and would break all projects which use slf4j  1.6
  and older.  Please go back to the original mail from 4 month where
  Ceki himself explained it!
 
 Hi Mark,
 
 You are assuming that a plugin somehow sees it's own version of
 slf4j-api on the class path but sees logback (the version that ships**
 with Maven) instead of it's preferred logging framework. Isn't that an
 overly pessimistic scenario which could not occur in practice?
 
 **subject to approval
 
  LieGrue,
  strub
 
 -- Ceki
 65% of statistics are made up on the spot
 
 -
 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: Logging

[Mark Struberg]

Another thing to remember is that logback is a LocationAwareLogger afaik 
(log4j-simple is not!) thus it suffers from the API compat problem.
By exposing it in the maven core class realm we might trash all projects with 
slf4j  1.6. This even got acknowledged by Ceki...
This was the reason why we initially picked slf4j-simple in the first place.

Hervés work is a mechanism to solve the problem in the plugins. But what about 
_projects_ using log4j-1.5 or lower? There is no simple 'fix your pom' answer. 
We would force those users to upgrade their projects. 3 possible solutions: we 
force them to update or do we auto-detect such dependencies and then _not_ 
expose slf4j in our core realm? I spare you the obvious 3rd option...

LieGrue,
strub




- Original Message -
 From: Olivier Lamy ol...@apache.org
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Monday, December 10, 2012 9:25 AM
 Subject: Re: Logging
 
 2012/12/10 Hervé BOUTEMY herve.bout...@free.fr:
  Le dimanche 9 décembre 2012 20:50:33 Jason van Zyl a écrit :
  I think it's time to stop patching SLF4J Simple. I have an 
 inefficient fix
  for the embedding problem, but we're likely to run into issues 
 concurrency
  with parallel builds and who knows what else. This will patch/change #5 
 and
  many hours of trying to get SLF4J Simple to work but I think we're 
 pushing
  the simple implementation beyond its scope. So I'd just like to put 
 in
  Logback and be done with it.
 
  There are at least three of us opposed to using a new logging 
 framework,
  logging *implementation*, please, not framework: the framework is 
 slf4j-api,
  on which our code will have much dependency. The logging implementation is 
 far
  less invasive choice (even if not completely null).
 
  but I don't think there is anyone against using Logback.
  why this provocation? (should I say lack of respect for others opinion?)
 
  I honestly don't think
  there is any rational argument for not using Logback,  so after doing 
 all
  the SLF4J work and making a best effort to use SLF4J Simple I think 
 it's
  pointless to pursue that path any longer and put in Logback.
  we'll need to wait for 3.1.1 and a vote to have a chance to stop 
 tension about
  this: whatever choice is done, there will be some devs unhappy who will 
 have
  to live with it
 
  notice I won't be able to reply for the next half day, my intent with 
 this
  reply is just to avoid one more re-spin of a feeling that the vote 
 won't
  happen and let Olivier once more jump on the case
  I just hope I won't have to read a lot of replies to this tonight when 
 I'm
  back from work and loose my time carefully reading if anything new or
  interesting is written
 
 
 I have already explained my opinion.
 Folks think log4j2 is immature and/or don't have a community of
 various people.
 
 Furthermore it looks it's not anymore possible to use immature
 libraries in core (whereas it has been done for more important part:
 sisu or aether).
 
 But now that's not anymore possible...
 Well things evolve and POV can change that's the life
 
 BTW due to our policy [1] and if I correctly read license here [2] a
 vote is mandatory. (and don't ask me to start this vote :-) ).
 
 Cheers
 --
 Olivier
 [1] http://maven.apache.org/developers/dependency-policies
 [2] http://logback.qos.ch/license.html
 
  Regards,
 
  Hervé
 
  On Dec 9, 2012, at 5:45 PM, Arnaud Héritier aherit...@gmail.com 
 wrote:
   I'm a little bit lost too.
   Thus for now in 3.1.0 we didn't want to provide a new logging 
 impl fwk
   (for
   many - good - reasons) but the last bug discovered by Kristian can 
 be
   solved only
   * by having a fix from slf4j (but it isn't sure that the patch 
 makes sense
   - to be validated by Ceki)
   * or by using a more evolved impl like logback (or log4j ...).
   I think that everyone's will prefer the first solution if 
 possible but if
   we cannot we'll have the question to select the impl.
   Do we need to vote ? Is there really a question logback vs 
 log4j(2) ?
   Like I said in another thread I'll understand if the project 
 decide to
   choose log4j2 even if it is young because we want to support 
 another ASF
   initiative (And I'm sure we won't have to regret it, and 
 we'll have a
   really good support from its team) but in a general case I would 
 prefer to
   choose logback which is today the reference logging framework (I 
 that case
   we need to have a PMC vote to accept an external component under 
 EPL
   license http://maven.apache.org/developers/dependency-policies ?).
  
   What do we need (for 3.1.0) ? What do we do ?
  
   Arnaud
  
   On Sun, Dec 9, 2012 at 10:53 PM, Anders Hammar 
 and...@hammar.net wrote:
   Not sure where to get into this thread, but I'd just like 
 to add my
   perspective on this topic.
  
   For this first release I would prefer it to not include any of 
 the more
   advanced slf4j implementations, like a few others have already 
 also
   stated.
   

Re: Logging

[Mark Struberg]

+1

LieGrue,
strub




- Original Message -
 From: Kristian Rosenvold kristian.rosenv...@gmail.com
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Monday, December 10, 2012 9:32 AM
 Subject: Re: Logging
 
 As for options; there is also the option of accepting that the
 technical challenges were slightly larger than anticipated and
 that getting things right make take some more time.
 
 In this context we could push the slf4j introduction to a 3.1 branch
 and release 3.0.5 now. Or just take the time.
 
 Kristian
 
 -
 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: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0

[Mark Struberg]

The cycle for 3.1.0 is the cycle that should be happening to prevent 

 something we're not happy with from being released.  Unlike, say, the 
compiler plugin
 which was actually released without much review only for Dan to discover 
 after the fact it doesn't work as advertised[1].


Well, the incremental work is not yet finished. And even if the 
maven-compiler-plugin works a bit to eagerly today this is much less of a 
problem than the previous behaviour where it didn't properly detect changes and 
just did not compile at all, creating broken jars, wars, ears, etc if you did 
not do a full clean upfront...


We added a few ITs for it, but obviously not enough. Hope those additional 
changes are also backed by ITs.


LieGrue,
strub


 From: Jason van Zyl ja...@tesla.io
To: Maven Developers List dev@maven.apache.org; Mark Struberg 
strub...@yahoo.de 
Sent: Saturday, December 8, 2012 6:22 PM
Subject: Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
 

Nothing has been released yet. This is what this cycle is for and frankly 
after 11 months of not releasing while adding JSR330 and SLF4J it's to be 
expected. But Hervé is working on it and I'm fixing up the error Kristian 
verified so it's getting review and if it takes 5 more re-spins so be it.


The cycle for 3.1.0 is the cycle that should be happening to prevent something 
we're not happy with from being released.  Unlike, say, the compiler plugin 
which was actually released without much review only for Dan to discover after 
the fact it doesn't work as advertised[1].


It always happens where after a huge hiatus no one really thinks about the 
release until it starts happening and then everyone wants things put in. We 
decided to call it 3.1.0 which to me signifies some breakage. For me that is 
the SLF4J API being used correctly and potentially breaking people. Hervé 
wants to try and preserve existing behavior which is fine. No rush and he's 
going to try and implement that. All in all we have still only seen one 
breakage in the field from the misuse of the SLF4J API. So I would hardly call 
this the worst state the core's been in. The only way to figure out what 
works, or doesn't, is to make a sample set of plugins with the various options 
for logging and validate their behavour.


I think we should also consider calling this 3.0.5 because there are probably 
a lot of behaviours we do want to change. A couple things I can think of are 
not automatically downloading snapshots every 24 hours, or changing the 
behaviour of local downloads to check the SHA1 and not the server it came 
from. These two behaviours cause lots of problems. If we collected all those 
together and wanted to implement them I think that is a reason to change a 
major version. Most users don't care about our API changes they care about 
feature changes and behavioural changes. People are going to look at 3.1.0 and 
ask what's different for them and the answer is nothing really.


[1]: https://jira.codehaus.org/browse/MCOMPILER-187

This is whole point of this cycle. Nothing has been released yet, folks have 
been reviewing it and we're now fixing more things. 

On Dec 7, 2012, at 9:39 AM, Mark Struberg strub...@yahoo.de wrote:

still there have been twice as many problem reports as +1.

Afaik we've never shipped a release in such a bad state to be honest.


LieGrue,
strub



- Original Message -

From: Benson Margulies bimargul...@gmail.com
To: Maven Developers List dev@maven.apache.org; Mark Struberg 
strub...@yahoo.de
Cc: 
Sent: Friday, December 7, 2012 3:04 PM
Subject: Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0

As I see it, the vote bogged down because Kristian found problems, and
I haven't seen clear evidence that those problems are sorted out. I'd
be happy to vote +1 with respect to all the design questions for the
release 'as is'.

On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote:

good idea, Benson.

Btw, this VOTE did not get enough +1 in more than a week. And this is not 
because not enough people took care if you look at the plenty of comments 
in the 
thread.


1.) Do people have any technical comment on my proposal to introduce a new 
plugin-plugin flag for exposing slf4j? Is there any technical problem with 
that?


Are there other proposals which might help increasing backward 
compatibility?




2.) what about the coloured logger with log4j2? I tried it locally and it 
worked great. What is the status? (Sorry if I missed something)




LieGrue,
strub



- Original Message -

From: Benson Margulies bimargul...@gmail.com
To: Maven Developers List dev@maven.apache.org
Cc:
Sent: Friday, December 7, 2012 2:28 PM
Subject: Re: [VOTE] Maven 3.1.0

Could we please find an appropriate subject line for this debate,
unless you all are really discussing this design question as part of
the (still?) outstanding vote on 3.1.0?


On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory

Re: Logging

[Mark Struberg]

To be honest. Slf4J is really mature. The fact that we need some 'special 
treatment' for maven worries me.
Are we are trying to do things with slf4j-simple it never was intended for? 
Again: I think sjf4j is really mature, so I guess the error is on our side.
And you also mentioned that Ceki did special changes in slf4j _itself_ and not 
only the simple logger? That worries me even more, what changes have that been?


LieGrue,
strub



- Original Message -
 From: Jason van Zyl ja...@tesla.io
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Monday, December 10, 2012 8:33 AM
 Subject: Re: Logging
 
 
 On Dec 10, 2012, at 2:11 AM, Hervé BOUTEMY herve.bout...@free.fr wrote:
 
  trying to be concise and neutral
 
  1. because slf4j-api is well known, it has lots of back-ends, that will 
  provide powerfull configuration techniques for filtering, display, 
 recording and 
  so on Maven output: precise use case still need to be described
 
  2. the discussion is not much about the api but about the default back-end 
  that will be shipped with Maven: there is no consensus, then the actual 
  strategy is to start with slf4j-simple in Maven 3.1.0 then have a vote to 
  choose which more complete implementation will go in Maven 3.1.1+
 
 
 We're blocked on using SLF4J Simple currently. We can wait for my patches to 
 be reviewed, but we should probably start the vote for the implementation if 
 that is what we require because after making several patches already I think 
 it's just time to pick an implementation. As I said in my previous email 
 we're so close to Christmas we might as well decide this and then fire up 
 the release process in the new year after the logging implementation 
 selection 
 is made. It's highly unlikely that in the next few weeks testing a new 
 version of Maven is going to be anyone's priority so we might as well take 
 our time at this point.
 
  Regards,
 
  Hervé
 
  Le dimanche 9 décembre 2012 22:18:51 Chris Graham a écrit :
  I got lost (in other work) and this thread a long time ago.
 
  Can someone please remind me just why we are changing the logging at 
 all?
 
  -Chris
 
 
  On Sun, Dec 9, 2012 at 5:52 AM, Kristian Rosenvold 
 
  kristian.rosenv...@gmail.com wrote:
  2012/12/9 Olivier Lamy ol...@apache.org:
  Perso I'm fine using log4j2.
  I use the branch I pushed for some weeks now and I'm happy.
  Log4j2 has quickly added a feature I needed and release it.
  Furthermore I'm fine working with an Apache community in 
 case of any
  issue we could have.
 
  I'm not entirely sure I follow where this discussion is 
 actually
  going,  but I'm firmly opposed
  to including a brand new logging framework as default in m3.
 
  Kristian
 
 
 -
  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  CTO, Sonatype
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -
 
 We all have problems. How we deal with them is a measure of our worth.
 
 -- Unknown


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

Re: Logging

[Mark Struberg]

sorry, you are right, should have been slf4j-simple, etc.




- Original Message -
 From: Anders Hammar and...@hammar.net
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Monday, December 10, 2012 11:20 AM
 Subject: Re: Logging
 
  Another thing to remember is that logback is a LocationAwareLogger afaik
  (log4j-simple is not!) thus it suffers from the API compat problem.
  By exposing it in the maven core class realm we might trash all projects
  with slf4j  1.6. This even got acknowledged by Ceki...
  This was the reason why we initially picked slf4j-simple in the first
  place.
 
  Hervés work is a mechanism to solve the problem in the plugins. But what
  about _projects_ using log4j-1.5 or lower? There is no simple 'fix your
  pom' answer. We would force those users to upgrade their projects. 3
  possible solutions: we force them to update or do we auto-detect such
  dependencies and then _not_ expose slf4j in our core realm? I spare you the
  obvious 3rd option...
 
 
 You're confusing me! I believe you use log4j in two places above 
 where it
 should be slf4j, right?
 
 Also, you're bringing in the perspective of projects which I 
 take it
 you're talking about the Maven projects being built. Correct? I've been
 assuming that the logging framework (slf4j) and the impl (whichever one)
 does NOT affect the Maven project being built, but only possibly the
 plugins executed. Isn't that correct? If so your point is not valid at all.
 The compat problem you're talking about I recall Ceki explained was
 extremely minor (in that sense that not very often used) and not likely to
 affect any plugin but only the ones doing advanced logging (and using an
 older slf4j version). Someone with better knowledge in this very specific
 topic should probably straighten this out; it's outside of my expertise.
 
 As this compat problem has popped up during the discussion, do you have an
 example of a real world case? That would be good so that we just don't have
 a brain ghost here.
 
 /Anders
 
 
 
 
  LieGrue,
  strub
 
 
 
 
  - Original Message -
   From: Olivier Lamy ol...@apache.org
   To: Maven Developers List dev@maven.apache.org
   Cc:
   Sent: Monday, December 10, 2012 9:25 AM
   Subject: Re: Logging
  
   2012/12/10 Hervé BOUTEMY herve.bout...@free.fr:
    Le dimanche 9 décembre 2012 20:50:33 Jason van Zyl a écrit :
    I think it's time to stop patching SLF4J Simple. I have 
 an
   inefficient fix
    for the embedding problem, but we're likely to run into 
 issues
   concurrency
    with parallel builds and who knows what else. This will 
 patch/change
  #5
   and
    many hours of trying to get SLF4J Simple to work but I think 
 we're
   pushing
    the simple implementation beyond its scope. So I'd just 
 like to put
   in
    Logback and be done with it.
  
    There are at least three of us opposed to using a new logging
   framework,
    logging *implementation*, please, not framework: the framework is
   slf4j-api,
    on which our code will have much dependency. The logging
  implementation is
   far
    less invasive choice (even if not completely null).
  
    but I don't think there is anyone against using Logback.
    why this provocation? (should I say lack of respect for others
  opinion?)
  
    I honestly don't think
    there is any rational argument for not using Logback,  so 
 after doing
   all
    the SLF4J work and making a best effort to use SLF4J Simple I 
 think
   it's
    pointless to pursue that path any longer and put in Logback.
    we'll need to wait for 3.1.1 and a vote to have a chance to 
 stop
   tension about
    this: whatever choice is done, there will be some devs unhappy 
 who will
   have
    to live with it
  
    notice I won't be able to reply for the next half day, my 
 intent with
   this
    reply is just to avoid one more re-spin of a feeling that the 
 vote
   won't
    happen and let Olivier once more jump on the case
    I just hope I won't have to read a lot of replies to this 
 tonight when
   I'm
    back from work and loose my time carefully reading if anything 
 new or
    interesting is written
  
  
   I have already explained my opinion.
   Folks think log4j2 is immature and/or don't have a 
 community of
   various people.
  
   Furthermore it looks it's not anymore possible to use 
 immature
   libraries in core (whereas it has been done for more important part:
   sisu or aether).
  
   But now that's not anymore possible...
   Well things evolve and POV can change that's the life
  
   BTW due to our policy [1] and if I correctly read license here [2] a
   vote is mandatory. (and don't ask me to start this vote :-) ).
  
   Cheers
   --
   Olivier
   [1] http://maven.apache.org/developers/dependency-policies
   [2] http://logback.qos.ch/license.html
  
    Regards,
  
    Hervé
  
    On Dec 9, 2012, at 5:45 PM, Arnaud Héritier 
 aherit...@gmail.com
   wrote:
     I'm a little bit lost too.
     Thus for now in 

Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0

[Mark Struberg]

+1, that sounds like a good balance between old compat behaviour and moving 
forward!


 Strategies to write a plugin using slf4j-api from core without requiring 
 Maven 
 3.1 still need to be found:
Maybe that's easier than you think.

Just declare an slf4j-api dependency to the plugin. If the core-realm exposes 
it then the classes from the core realm will be taken anyway (parent-first). In 
maven  3.1 which doesn't expose it the dependency will kick in.

LieGrue,
strub




- Original Message -
 From: Hervé BOUTEMY herve.bout...@free.fr
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Saturday, December 8, 2012 3:22 PM
 Subject: Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
 
 Le vendredi 7 décembre 2012 09:32:33 Jason van Zyl a écrit :
  Hervé I will assume you're looking at this. Let me know if you need any
  help.
 
 yes, I'm working on it
 from latest discussion, the ideal is:
 
 1. compatibility:
 for plugin descriptors without information, don't expose core's 
 slf4j-api, 
 like it has always been the case
 
 2. default on:
 when using future plugin-tools 3.3, the descriptor generated by default will 
 enable core's slf4j-api explosition, plugin developper will need to add an 
 annotation to hide core's slf4j-api
 
 
 Strategies to write a plugin using slf4j-api from core without requiring 
 Maven 
 3.1 still need to be found: I personnally don't see how to do that.
 That's why I wrote it in [1] Of course, this will only work when run 
 under 
 Maven 3.1.0, then this technique can be used safely only in Maven core 
 components.
 
 Regards,
 
 Hervé
 
 
 [1] http://maven.apache.org/ref/3.1-SNAPSHOT/maven-embedder/logging.html
 
 -
 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] Maven 3.1.0

[Mark Struberg]

basically all stuff which integrates maven does *funky logging stuff*...




- Original Message -
 From: Anders Hammar and...@hammar.net
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Friday, December 7, 2012 7:25 AM
 Subject: Re: [VOTE] Maven 3.1.0
 
  I'm interested to help working on adding a metadata to enable slf4j
  visibility
  from a plugin: by default, slf4j is not visible, plugins are expected to
  use
  plugin-api's Log. But if the plugin wants to use core's slf4j, he 
 would be
  able to add an annotation in the goal requiring shared core slf4j, then the
  plugin descriptor would enable slf4j api import from core.
 
 
 *If* we go this path, I think the default should be the other way around.
 I.e., the default would be to use core's slf4j and it's impl. So the 
 plugin
 developer needs to do an active choice to go outside Maven's logging. Sure,
 this could imply problems with existing plugins doing funky logging stuff
 (like the Sonar plugin), but I don't really see a problem with those
 plugins having to release a new version. I think it's more important that
 we get good defaults than trying to make every existing plugin work as they
 are implemented right now.
 
 /Anders
 
 
 
  Stephen: is this what you have in mind?
 
  Regards,
 
  Hervé
 
  Le vendredi 30 novembre 2012 12:20:35 Stephen Connolly a écrit :
   I tend to agree. There are two use-cases I see that a plugin has for
   bundling a logging implementation:
  
   1. They are wanting to shunt the logs from the build tool they are
  invoking
   on to the user. Typically if they are being good plugins they just 
 take
  the
   logging output and shunt it onto org.apache.maven.plugin.Log.info()
  
   2. They are wanting to shunt the logs from the build tool (or more 
 likely
   app server) to a separate file, or tweak the level of logs higher than
  INFO
   for that app server/mojo execution as it will just drown the user.
  
   In the first use case, Jason's point is correct. They 
 shouldn't need to
   bundle a logging implementation any more.
  
   The second case, Jason is arguing that they shouldn't be using the 
 Maven
   JVM for running that tool, they should be running it in a forked JVM 
 and
   then they can configure the logging in that JVM. I disagree. Forking a
  JVM
   for every little build tool just to control its logging is going to 
 kill
   the build time.
  
   My preference is for a metadata flag that says: Oy! I know what 
 I'm doing
   with logging, so don't pass logging on to me.
  
   While it feels like a special case the truth is logging is 
 always, and
   always will be, a special case!
  
   -Stephen
  
   On 30 November 2012 12:09, Benson Margulies 
 bimargul...@gmail.com
  wrote:
On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl 
 ja...@tesla.io
  wrote:
 On Nov 29, 2012, at 5:56 PM, Benson Margulies 
 bimargul...@gmail.com
  
   
wrote:
 Currently I'm of the mind that if you make a 
 Maven plugin that uses
   
something that employs SLF4J then the best practice is to only 
 use the
  API
and let the host choose the implementation, in our case Maven. 
 Relying
  on
SLF4J implementation specifics in a system you're embedded in 
 is not
  good
e.g. Logback in Sonar running in Maven using SLF4J Simple. If you 
 want
  to
your own logging thing while being invoked by Maven then you fork 
 the
  JVM
and then you can do whatever you want.
   
 I read Olivier's point to be this: it would be cool 
 if we could
  think
 of a way for a plugin to use the slf4j API and remain 
 independent of
 the logging workings of the maven core.

 I think you mean remain independent of the SLF4J implemented 
 used by
   
Maven's core.
   
 Sure, but my counter line of argument would be is that 
 really valid?
  If
   
you are running in the context of Maven and you're using 
 SLF4J I think
  you
should defer to what Maven has setup.
   
 As things are, that could be
 done only, I think, by using shade to  rename a copy of 
 slf4j for
  the
 guts of the plugin.

 We have the capability in the core, that is OSGi-esque, that 
 allows
  us
   
to block classes from being accessible to plugins. We can 
 block/allow
  any
classes we choose: we can effectively make anything invisible to
  plugins
if
we choose. This capability was added to Classworlds some time 
 ago.
   
 If I were less sleep-deprived, I might be able to
 put forth an idea about how an enhancement to slf4j 
 could allow
 everyone to be happy here, but I don't see a way to 
 make everyone
 happy as things are.

 My personal view is that 'giant subsystem' 
 plugins are rarities at
 most, and the attraction of saying 'the Maven 
 logging API *is*
  slf4j'
 outweighs for me the problems.

 I think everyone agrees there, it's really now a matter 
 would we let
   
plugins pick and use a different 

Re: [VOTE] Maven 3.1.0

[Mark Struberg]

The final proposal that I see is where we give a metadata flag 
(defaults to false) 
 which if true sets up an isolated classloader for 
the plugin allowing the plugin to use its own slf4j

Stephen, this is _almost_ the same as I proposed a month ago. But I'd do it the 
other way around as this would be perfectly backward compatible.

I'll try to explain again what I propose:

Any plugin could e.g. use a @Slf4JLogger in it's mojo. The plugin-plugin would 
transfer this to a useSlf4jtrue/useSlf4j inside the plugin.xml.
In this case, and _only_ in this case we would expose our internal SLF4J to the 
plugin. 


Older plugins do not need it anyway as they do not use the maven-provided slf4j 
yet!


This is a win-win solution imo:
* old integration and plugins will still work
* new plugins can use slf4j for logging via maven


Again the state of affairs of 3.1.0 today: old projects and plugins which didnt 
use slf4j so far don't get any benefit from forcing slf4j on them. And old 
projects and plugins which _did_ use slf4j already are now broken with the 
current trunk. I cannot see how we can seriously release this to users right 
now.

LieGrue,
strub



 From: Stephen Connolly stephen.alan.conno...@gmail.com
To: Maven Developers List dev@maven.apache.org; Mark Struberg 
strub...@yahoo.de 
Sent: Friday, December 7, 2012 12:48 PM
Subject: Re: [VOTE] Maven 3.1.0
 

But not all of those *need to*. At least until now they have needed to, but 
going forward they may not need to if we are giving them an slf4j impl to hang 
their hat off.


There will always be some special case plugins that have a legitimate need to 
do funky logging stuff. We need a strategy for those plugins.


Jason's proposal for those cases was that they should fork a JVM. That works 
if you don't need to channel objects back and forth. For some of the plugins 
wanting to do 'live development' style work (I am thinking my jszip.org 
experiments - I have some plans and experiments that I haven't even pushed to 
there yet ;-) ) forking a JVM is a bad plan, as you then have to basically 
resort to RMI to control the forked JVM... More ports and more sockets and 
more complexity.


The next step I could see is building a fresh classloader up from scratch 
within the plugin. That *should* work as long as we load a fresh set of 
slf4j-api classes (ceki?) then we are initialising slf4j a second time in the 
fresh classloader and we can do as we need. Again complex though one could 
argue less complex than the RMI route. Plugin developers following this route 
will have to watch out for the dreaded CCE but at least you are not having to 
deal with object serialisation and RMI


The final proposal that I see is where we give a metadata flag (defaults to 
false) which if true sets up an isolated classloader for the plugin allowing 
the plugin to use its own slf4j


Note that each proposal above retains the option for plugin developers to use 
the previous proposal.


My vote is that we need to provide a utility library that makes the first and 
second proposals facile for plugin developers and we should probably enable 
the third option also.


The correct respecting of tool chains support requires plugin developers to 
follow the first route if a tool chain JVM is applied to their plugin and to 
use the second when no tool chain JVM is in play... At least for the jetty:run 
and tomcat:run style plugins.


For the sonar style plugins, and my gut says the vast majority of these use 
cases the most they will need is the third proposal. Without seeing a 
maven-fork-utils api I cannot say that we don't need the third proposal, so I 
am forced to conclude that we should support it... IOW I think we need a 
metadata flag.


-Stephen

On Friday, 7 December 2012, Mark Struberg  wrote:

basically all stuff which integrates maven does *funky logging stuff*...




- Original Message -
 From: Anders Hammar and...@hammar.net
 To: Maven Developers List dev@maven.apache.org
 Cc:
 Sent: Friday, December 7, 2012 7:25 AM
 Subject: Re: [VOTE] Maven 3.1.0

  I'm interested to help working on adding a metadata to enable slf4j
  visibility
  from a plugin: by default, slf4j is not visible, plugins are expected to
  use
  plugin-api's Log. But if the plugin wants to use core's slf4j, he
 would be
  able to add an annotation in the goal requiring shared core slf4j, then 
 the
  plugin descriptor would enable slf4j api import from core.


 *If* we go this path, I think the default should be the other way around.
 I.e., the default would be to use core's slf4j and it's impl. So the
 plugin
 developer needs to do an active choice to go outside Maven's logging. Sure,
 this could imply problems with existing plugins doing funky logging stuff
 (like the Sonar plugin), but I don't really see a problem with those
 plugins having to release a new version. I think it's more important that
 we get good defaults than trying to make every existing

Re: [VOTE] Maven 3.1.0

[Mark Struberg]

Daniel, please think through these old project scenarios. Those old projects 
did ship their own slf4j impl + config and parsed their own logs and extracted 
information. They will now just fall on their knees because the logs are no 
longer available for them. Instead they will be somewhere in the maven logs 
which could be anywhere from a plugin point of view. 


This is not fixed, this is broken imo.

LieGrue,
strub



- Original Message -
 From: Daniel Kulp dk...@apache.org
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Friday, December 7, 2012 1:49 PM
 Subject: Re: [VOTE] Maven 3.1.0
 
 
 
  Again the state of affairs of 3.1.0 today: old projects and plugins which 
 didnt use slf4j so far don't get any benefit from forcing slf4j on them. And 
 old projects and plugins which _did_ use slf4j already are now broken with 
 the 
 current trunk. I cannot see how we can seriously release this to users right 
 now.
 
 
 
 I don't consider them broken.   I consider them fixed.    Old plugins that 
 use SLF4J now get there information properly integrated with the rest of the 
 maven information.  
 
 
 Dan
 
 
 
 On Dec 7, 2012, at 7:32 AM, Mark Struberg strub...@yahoo.de wrote:
 
  The final proposal that I see is where we give a metadata flag 
  (defaults to false) 
  which if true sets up an isolated classloader for 
  the plugin allowing the plugin to use its own slf4j
 
  Stephen, this is _almost_ the same as I proposed a month ago. But I'd 
 do it the other way around as this would be perfectly backward compatible.
 
  I'll try to explain again what I propose:
 
  Any plugin could e.g. use a @Slf4JLogger in it's mojo. The 
 plugin-plugin would transfer this to a useSlf4jtrue/useSlf4j 
 inside the plugin.xml.
  In this case, and _only_ in this case we would expose our internal SLF4J to 
 the plugin. 
 
 
  Older plugins do not need it anyway as they do not use the maven-provided 
 slf4j yet!
 
 
  This is a win-win solution imo:
  * old integration and plugins will still work
  * new plugins can use slf4j for logging via maven
 
 
  Again the state of affairs of 3.1.0 today: old projects and plugins which 
 didnt use slf4j so far don't get any benefit from forcing slf4j on them. And 
 old projects and plugins which _did_ use slf4j already are now broken with 
 the 
 current trunk. I cannot see how we can seriously release this to users right 
 now.
 
  LieGrue,
  strub
 
 
  
  From: Stephen Connolly stephen.alan.conno...@gmail.com
  To: Maven Developers List dev@maven.apache.org; Mark Struberg 
 strub...@yahoo.de 
  Sent: Friday, December 7, 2012 12:48 PM
  Subject: Re: [VOTE] Maven 3.1.0
 
 
  But not all of those *need to*. At least until now they have needed to, 
 but going forward they may not need to if we are giving them an slf4j impl to 
 hang their hat off.
 
 
  There will always be some special case plugins that have a legitimate 
 need to do funky logging stuff. We need a strategy for those plugins.
 
 
  Jason's proposal for those cases was that they should fork a JVM. 
 That works if you don't need to channel objects back and forth. For some of 
 the plugins wanting to do 'live development' style work (I am thinking 
 my jszip.org experiments - I have some plans and experiments that I haven't 
 even pushed to there yet ;-) ) forking a JVM is a bad plan, as you then have 
 to 
 basically resort to RMI to control the forked JVM... More ports and more 
 sockets 
 and more complexity.
 
 
  The next step I could see is building a fresh classloader up from 
 scratch within the plugin. That *should* work as long as we load a fresh set 
 of 
 slf4j-api classes (ceki?) then we are initialising slf4j a second time in the 
 fresh classloader and we can do as we need. Again complex though one could 
 argue 
 less complex than the RMI route. Plugin developers following this route will 
 have to watch out for the dreaded CCE but at least you are not having to deal 
 with object serialisation and RMI
 
 
  The final proposal that I see is where we give a metadata flag 
 (defaults to false) which if true sets up an isolated classloader for the 
 plugin 
 allowing the plugin to use its own slf4j
 
 
  Note that each proposal above retains the option for plugin developers 
 to use the previous proposal.
 
 
  My vote is that we need to provide a utility library that makes the 
 first and second proposals facile for plugin developers and we should 
 probably 
 enable the third option also.
 
 
  The correct respecting of tool chains support requires plugin 
 developers to follow the first route if a tool chain JVM is applied to their 
 plugin and to use the second when no tool chain JVM is in play... At least 
 for 
 the jetty:run and tomcat:run style plugins.
 
 
  For the sonar style plugins, and my gut says the vast majority of these 
 use cases the most they will need is the third proposal. Without seeing a 
 maven-fork-utils api I cannot say that we

Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0

[Mark Struberg]

good idea, Benson.

Btw, this VOTE did not get enough +1 in more than a week. And this is not 
because not enough people took care if you look at the plenty of comments in 
the thread. 

1.) Do people have any technical comment on my proposal to introduce a new 
plugin-plugin flag for exposing slf4j? Is there any technical problem with that?

Are there other proposals which might help increasing backward compatibility?



2.) what about the coloured logger with log4j2? I tried it locally and it 
worked great. What is the status? (Sorry if I missed something)



LieGrue,
strub



- Original Message -
 From: Benson Margulies bimargul...@gmail.com
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Friday, December 7, 2012 2:28 PM
 Subject: Re: [VOTE] Maven 3.1.0
 
 Could we please find an appropriate subject line for this debate,
 unless you all are really discussing this design question as part of
 the (still?) outstanding vote on 3.1.0?
 
 
 On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory garydgreg...@gmail.com 
 wrote:
  Another way of looking at this is whether this kind of behavior change in
  appropriate for a minor release, instead of a major release.
 
 
  On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg strub...@yahoo.de 
 wrote:
 
  Daniel, please think through these old project scenarios. Those old
  projects did ship their own slf4j impl + config and parsed their own 
 logs
  and extracted information. They will now just fall on their knees 
 because
  the logs are no longer available for them. Instead they will be 
 somewhere
  in the maven logs which could be anywhere from a plugin point of view.
 
 
  This is not fixed, this is broken imo.
 
  LieGrue,
  strub
 
 
 
  - Original Message -
   From: Daniel Kulp dk...@apache.org
   To: Maven Developers List dev@maven.apache.org
   Cc:
   Sent: Friday, December 7, 2012 1:49 PM
   Subject: Re: [VOTE] Maven 3.1.0
  
  
  
    Again the state of affairs of 3.1.0 today: old projects and 
 plugins
  which
   didnt use slf4j so far don't get any benefit from forcing 
 slf4j on them.
  And
   old projects and plugins which _did_ use slf4j already are now 
 broken
  with the
   current trunk. I cannot see how we can seriously release this to 
 users
  right
   now.
  
  
  
   I don't consider them broken.   I consider them fixed.    Old 
 plugins
  that
   use SLF4J now get there information properly integrated with the 
 rest of
  the
   maven information.
  
  
   Dan
  
  
  
   On Dec 7, 2012, at 7:32 AM, Mark Struberg 
 strub...@yahoo.de wrote:
  
    The final proposal that I see is where we give a metadata 
 flag
    (defaults to false)
    which if true sets up an isolated classloader for
    the plugin allowing the plugin to use its own slf4j
  
    Stephen, this is _almost_ the same as I proposed a month ago. 
 But I'd
   do it the other way around as this would be perfectly backward
  compatible.
  
    I'll try to explain again what I propose:
  
    Any plugin could e.g. use a @Slf4JLogger in it's mojo. 
 The
   plugin-plugin would transfer this to a 
 useSlf4jtrue/useSlf4j
   inside the plugin.xml.
    In this case, and _only_ in this case we would expose our 
 internal
  SLF4J to
   the plugin.
  
  
    Older plugins do not need it anyway as they do not use the
  maven-provided
   slf4j yet!
  
  
    This is a win-win solution imo:
    * old integration and plugins will still work
    * new plugins can use slf4j for logging via maven
  
  
    Again the state of affairs of 3.1.0 today: old projects and 
 plugins
  which
   didnt use slf4j so far don't get any benefit from forcing 
 slf4j on them.
  And
   old projects and plugins which _did_ use slf4j already are now 
 broken
  with the
   current trunk. I cannot see how we can seriously release this to 
 users
  right
   now.
  
    LieGrue,
    strub
  
  
    
    From: Stephen Connolly 
 stephen.alan.conno...@gmail.com
    To: Maven Developers List dev@maven.apache.org; 
 Mark Struberg
   strub...@yahoo.de
    Sent: Friday, December 7, 2012 12:48 PM
    Subject: Re: [VOTE] Maven 3.1.0
  
  
    But not all of those *need to*. At least until now they 
 have needed
  to,
   but going forward they may not need to if we are giving them an 
 slf4j
  impl to
   hang their hat off.
  
  
    There will always be some special case plugins that have 
 a legitimate
   need to do funky logging stuff. We need a strategy for those 
 plugins.
  
  
    Jason's proposal for those cases was that they should 
 fork a JVM.
   That works if you don't need to channel objects back and 
 forth. For some
  of
   the plugins wanting to do 'live development' style work (I 
 am thinking
   my jszip.org experiments - I have some plans and experiments that 
 I
  haven't
   even pushed to there yet ;-) ) forking a JVM is a bad plan, as you 
 then
  have to
   basically resort to RMI to control the forked JVM... More ports 
 and more
  sockets
   and more

Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0

[Mark Struberg]

still there have been twice as many problem reports as +1.

Afaik we've never shipped a release in such a bad state to be honest.


LieGrue,
strub



- Original Message -
 From: Benson Margulies bimargul...@gmail.com
 To: Maven Developers List dev@maven.apache.org; Mark Struberg 
 strub...@yahoo.de
 Cc: 
 Sent: Friday, December 7, 2012 3:04 PM
 Subject: Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
 
 As I see it, the vote bogged down because Kristian found problems, and
 I haven't seen clear evidence that those problems are sorted out. I'd
 be happy to vote +1 with respect to all the design questions for the
 release 'as is'.
 
 On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote:
  good idea, Benson.
 
  Btw, this VOTE did not get enough +1 in more than a week. And this is not 
 because not enough people took care if you look at the plenty of comments in 
 the 
 thread.
 
  1.) Do people have any technical comment on my proposal to introduce a new 
 plugin-plugin flag for exposing slf4j? Is there any technical problem with 
 that?
 
  Are there other proposals which might help increasing backward 
 compatibility?
 
 
 
  2.) what about the coloured logger with log4j2? I tried it locally and it 
 worked great. What is the status? (Sorry if I missed something)
 
 
 
  LieGrue,
  strub
 
 
 
  - Original Message -
  From: Benson Margulies bimargul...@gmail.com
  To: Maven Developers List dev@maven.apache.org
  Cc:
  Sent: Friday, December 7, 2012 2:28 PM
  Subject: Re: [VOTE] Maven 3.1.0
 
  Could we please find an appropriate subject line for this debate,
  unless you all are really discussing this design question as part of
  the (still?) outstanding vote on 3.1.0?
 
 
  On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory 
 garydgreg...@gmail.com
  wrote:
   Another way of looking at this is whether this kind of behavior 
 change in
   appropriate for a minor release, instead of a major release.
 
 
   On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg 
 strub...@yahoo.de
  wrote:
 
   Daniel, please think through these old project scenarios. 
 Those old
   projects did ship their own slf4j impl + config and parsed 
 their own
  logs
   and extracted information. They will now just fall on their 
 knees
  because
   the logs are no longer available for them. Instead they will 
 be
  somewhere
   in the maven logs which could be anywhere from a plugin point 
 of view.
 
 
   This is not fixed, this is broken imo.
 
   LieGrue,
   strub
 
 
 
   - Original Message -
    From: Daniel Kulp dk...@apache.org
    To: Maven Developers List dev@maven.apache.org
    Cc:
    Sent: Friday, December 7, 2012 1:49 PM
    Subject: Re: [VOTE] Maven 3.1.0
   
   
   
     Again the state of affairs of 3.1.0 today: old 
 projects and
  plugins
   which
    didnt use slf4j so far don't get any benefit from 
 forcing
  slf4j on them.
   And
    old projects and plugins which _did_ use slf4j already 
 are now
  broken
   with the
    current trunk. I cannot see how we can seriously release 
 this to
  users
   right
    now.
   
   
   
    I don't consider them broken.   I consider them 
 fixed.    Old
  plugins
   that
    use SLF4J now get there information properly integrated 
 with the
  rest of
   the
    maven information.
   
   
    Dan
   
   
   
    On Dec 7, 2012, at 7:32 AM, Mark Struberg
  strub...@yahoo.de wrote:
   
     The final proposal that I see is where we give a 
 metadata
  flag
     (defaults to false)
     which if true sets up an isolated classloader 
 for
     the plugin allowing the plugin to use its own slf4j
   
     Stephen, this is _almost_ the same as I proposed a 
 month ago.
  But I'd
    do it the other way around as this would be perfectly 
 backward
   compatible.
   
     I'll try to explain again what I propose:
   
     Any plugin could e.g. use a @Slf4JLogger in it's 
 mojo.
  The
    plugin-plugin would transfer this to a
  useSlf4jtrue/useSlf4j
    inside the plugin.xml.
     In this case, and _only_ in this case we would 
 expose our
  internal
   SLF4J to
    the plugin.
   
   
     Older plugins do not need it anyway as they do not 
 use the
   maven-provided
    slf4j yet!
   
   
     This is a win-win solution imo:
     * old integration and plugins will still work
     * new plugins can use slf4j for logging via maven
   
   
     Again the state of affairs of 3.1.0 today: old 
 projects and
  plugins
   which
    didnt use slf4j so far don't get any benefit from 
 forcing
  slf4j on them.
   And
    old projects and plugins which _did_ use slf4j already 
 are now
  broken
   with the
    current trunk. I cannot see how we can seriously release 
 this to
  users
   right
    now.
   
     LieGrue,
     strub
   
   
     
     From: Stephen Connolly
  stephen.alan.conno...@gmail.com
     To: Maven Developers List 
 dev@maven.apache.org;
  Mark Struberg
    strub...@yahoo.de
     Sent: Friday

Re: apache/maven-3 at Github

[Mark Struberg]

But to make this more clear, we will only accept pull changes if they come 
along with an identical JIRA with the diff. You also must make sure that you 
are the only one who has changed something in the contribution. It's way to 
easy to fake author Ids on github...

The committer which applies the patch or signs off the pull request must make 
sure that all IP is cleared.

Another reason for not having our cannonical repo on github - and even for 
having a cannonical repo at all - is that we do not like the the 'fork 
creeping' which we've seen on github quite often. 


As example: There are quite some codehaus mojo projects which did move from 
codehaus svn to github. Almost all of them are dead dead dead in the meantime 
:( 

Now what happened? It was obviously very easy to fork those projects and to fix 
their own problems. But most people didn't care about getting the bugfixes back 
to the 'main' git repo nor even to get feedback from the community. If you look 
at a few of those old codehaus mojo projects you will see that most of them 
have 25++ forks with changes (actually there are much more forks _without_ 
changes). Together with Fred Cooke I tried to grasp an idea what went wrong 
with the osxappbundle-maven-plugin. The result was that ALL of the forks on 
github are broken! People only fixed _their_ issue but always broke other 
scenarios! There was no single plugin which e.g. worked with OSX 1.5, 1.6 and 
1.7 (was before 1.8 came out). Serious folks, thats Kindergarten and we don't 
like this in an ASF project!



LieGrue,
strub

- Original Message -
 From: Kristian Rosenvold kristian.rosenv...@gmail.com
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Wednesday, December 5, 2012 9:47 AM
 Subject: Re: apache/maven-3 at Github
 
 Mirroring to make it available in mainstream channels is a Good Thing
 IMO. Pull requests are also nice.
 
 Git goes a long way to eradicate the committer bit barrier to
 contribution; anyone can fork and modify code
 at next to zero cost. Some will also contribute back. Pushing to
 github makes creating your own writeable fork
 as easy as pressing the fork button.
 
 Another interesting feature available by virtue of github is the
 network graph; look at
 https://github.com/apache/maven-surefire/network for an example. It
 actually keeps track
 of what the community is doing and if you're feeling social you 
 can
 drop by someone else's
 fork, leave a comment - maybe even encourage them to complete their
 work and submit
 a patch!
 
 Kristian
 
 2012/12/5 Jochen Wiedmann jochen.wiedm...@gmail.com:
  What's Apache sources got to do at Github anywyays?
 
 
 
  On Tue, Dec 4, 2012 at 8:34 AM, Anders Hammar and...@hammar.net 
 wrote:
 
  This git repo at Github mirrors the old Git repo. Is it possible to 
 change
  that to the new git repo, or should it be removed all together?
 
  /Anders
 
 
 
 
  --
  The best argument for celibacy is that the clergy will sooner or later
  become extinct.
 
 -
 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: apache/maven-3 at Github

[Mark Struberg]

if the diff is included in the mail then that would be sufficient imo. But I'd 
rather ping back to board if this is fine. 

If the mail is created with git-format-patch and later applied via git-am then 
this should be as fine as JIRA imo. Still a JIRA reference should be there for 
referencing in the release notes, etc.

My main point is that a hell lot of github forks have a pretty unclear 
provenance and a rather questionable quality :/

I really like github for some stuff, but nowadays it somehow looks like a 
dustbin which didn't get cleaned up since ages ;)

LieGrue,
strub




- Original Message -
 From: Kristian Rosenvold kristian.rosenv...@gmail.com
 To: Maven Developers List dev@maven.apache.org; Mark Struberg 
 strub...@yahoo.de
 Cc: 
 Sent: Wednesday, December 5, 2012 10:53 AM
 Subject: Re: apache/maven-3 at Github
 
 2012/12/5 Mark Struberg strub...@yahoo.de:
  But to make this more clear, we will only accept pull changes if they come 
 along with an identical JIRA with the diff. You also must make sure that you 
 are 
 the only one who has changed something in the contribution. It's way to easy 
 to fake author Ids on github...
 
  The committer which applies the patch or signs off the pull request must 
 make sure that all IP is cleared.
 
 We've been through this before ;)
 
 I understand that the important thing is that there's a clear record
 of authorship and a clear record of submission ?
 
 As far as I understand the pull request being sent to the dev@ list is
 a record of submission. It's a bit of a pity the
 actual diff isn't included in the pull request mail; I wonder why the
 asf script that dispatches these mails doesn't include fetch the
 actual diff ?
 
 As for clear record of authorship I have tended to assume that
 committer emails must clearly show an email address or a name that
 would match a name in a jira. As for /who/ that person is, we have
 never really known anyway. I am unsure if we should downright reject
 commits/pull requests that do not sufficiently identify the author,
 even if they reference a jira?
 
 Since I rebase and amend most submissions, I tend to add the details
 about the jira submitter to the extent they
 do not match the author info in git.
 
 As for the *actual* diff attached to a jira; do we really need those ?
 Wouldn't it be sufficient if the mail from pull included the diff ?
 
 Kristian
 

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

Re: Re-spinning 3.1.0

[Mark Struberg]

Downloads from central in the last 12 months:

Logback: 1,136,846
Log4J2: 6,748

Do you have the number for all log4j artifacts? log4j2 just got released but is 
a native successor of log4j1.

LieGrue,
strub







 From: Jason van Zyl ja...@tesla.io
To: Maven Developers List dev@maven.apache.org 
Sent: Sunday, December 2, 2012 12:21 AM
Subject: Re: Re-spinning 3.1.0
 

On Dec 1, 2012, at 3:11 PM, Hervé BOUTEMY herve.bout...@free.fr wrote:

 Le samedi 1 décembre 2012 10:08:21 Jason van Zyl a écrit :
 [1]:
 http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Flogging%2Flog4j%2Flog4j2
 
 
 just for side-by-side comparison:
 https://github.com/qos-ch/logback/graphs/contributors
 

Cool, thanks. A couple more data points:

Downloads from central in the last 12 months:

Logback: 1,136,846
Log4J2: 6,748

Projects integrating Logback:

http://logback.qos.ch
8 of which are Apache projects

 -
 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  CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
-

We all have problems. How we deal with them is a measure of our worth.

-- Unknown









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

Re: [VOTE] Maven 3.1.0

[Mark Struberg]

what is complex with say am openjpa enhancer mojo?
Still this will break depending what the project configures in it's 
persistence.xml.

Just an idea for now:
The safe route might be a plugin-plugin annotatation which tells us 'plugin 
uses slf4j' in that case it gets exposed, in other cases it doesn't.

Old maven versions will ignore the tag in plugin.xml and mvn-3.1++ will 
evaluate it and add slf4j injection support for those plugins.

LieGrue,
strub



- Original Message -
 From: Benson Margulies bimargul...@gmail.com
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Friday, November 30, 2012 10:15 PM
 Subject: Re: [VOTE] Maven 3.1.0
 
 At the end of the day, either Maven uses a standard logging API inside
 plugins, or it does not. Using a standard logging API has giant
 advantages - but it can inconvenience people integrating complex code
 via plugins.
 
 In this thread, there are two approaches to removing that
 inconvenience: a plugin annotation that changing the logging
 integration, and use of forking. Both work. I have some sympathy for
 the view that anything complex enough to care should fork. When people
 integrate big complex things, it has unpleasant consequences like
 System.exit() calls.
 
 So I'm entirely +1 for the code as it stands, and I see adding an
 annotation or something to avoid injecting the logging back end as a
 nice to have. As I wrote before, I'd feel better about the 'stick a
 fork' in it prescription if we had better reusable forking code.
 
 -
 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: Re-spinning 3.1.0

[Mark Struberg]

sounds great, have Oliviers branch running locally myself without issues.

LieGrue,
strub




- Original Message -
 From: Arnaud Héritier aherit...@gmail.com
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Saturday, December 1, 2012 9:17 AM
 Subject: Re: Re-spinning 3.1.0
 
 Hi Jason,
 
   Couldn't we have a look at olamy's log4j2 branch to see if we could
 sanitize / merge it to propose at least one change for the end user
 and demonstrate the interest of the change about logs : a colorized
 console.
 
   I remember you did that in mvnsh/teslashell a long time ago (as an
 extension ?) and perhaps it could be easy to add properly this feature
 in 3.1.0 (otherwise it won't be before a 3.2.0).
 
   Myself I'm using a 3.1.0 fork with this patch and I' m really
 satisfied (it's so good to quickly see highlighted warning and errors
 ). I merged it back in the last 3.1.0 tag you did without issue
 
   Wdyt?
 
 -
 Arnaud
 
 Le 1 déc. 2012 à 00:20, Jason van Zyl ja...@tesla.io a écrit :
 
  I'm done with the issues that cropped up so I'm ready to re-spin 
 3.1.0.
 
  Anyone want to add anything or discuss anything before I spin this? I'm 
 not in any rush so if folks want to talk about logging we can. But given the 
 fact once SLF4J initializes it can't change the implementation plugins 
 integrating with Maven need to use the implementation we choose. This is how 
 everything else in the world that integrates SLF4J has to operate so I don't 
 really see us being any different.
 
  I'll wait until tomorrow to re-spin.
 
  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder  CTO, Sonatype
  Founder,  Apache Maven
  http://twitter.com/jvanzyl
  -
 
 
 
 
 
 
 
 -
 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: Re-spinning 3.1.0

[Mark Struberg]

There is btw out of the box @InjectLogger support for Log4j2 in guice. A few 
projects are using this already without problems it seems. 


LieGrue,
strub



- Original Message -
 From: Arnaud Héritier aherit...@gmail.com
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Saturday, December 1, 2012 10:42 AM
 Subject: Re: Re-spinning 3.1.0
 
 Ok. Yes that's sure it has to be discussed. That's why I reopened the 
 subject.
 About the implementation :
 * as a user I have really no preference, I just want the feature
 * as a developer I played with both and for me these are just loggers
 . We may organize a fight between Ceki and Ralph but it won't help I
 think. I agree that log4j2 is in beta which is annoying (? Or not. We
 are talking about a logging lib that is doing some println - but with
 colors )
 * as PMC and ASF member I suppose I should say that our projects are
 the best and we should privilege our own stuffs for the safety of our
 ecosystem.
 
 Cheers.
 
 -
 Arnaud
 
 Le 1 déc. 2012 à 09:26, Jason van Zyl ja...@tesla.io a écrit :
 
 
  On Dec 1, 2012, at 12:17 AM, Arnaud Héritier aherit...@gmail.com 
 wrote:
 
  Hi Jason,
 
  Couldn't we have a look at olamy's log4j2 branch to see if we 
 could
  sanitize / merge it to propose at least one change for the end user
  and demonstrate the interest of the change about logs : a colorized
  console.
 
  Not without discussion about the implementation. To me the obvious choice 
 is Logback and using Log4J2 makes no sense. Olivier disagrees so there will 
 be a 
 discussion. I've been working on the release but I plan to make a branch 
 using Logback so we have a basis for discussion.
 
 
  I remember you did that in mvnsh/teslashell a long time ago (as an
  extension ?) and perhaps it could be easy to add properly this feature
  in 3.1.0 (otherwise it won't be before a 3.2.0).
 
  Myself I'm using a 3.1.0 fork with this patch and I' m really
  satisfied (it's so good to quickly see highlighted warning and 
 errors
  ). I merged it back in the last 3.1.0 tag you did without issue
 
  Wdyt?
 
  Just as easy with Logback, the only difference being Logback is a mature 
 solution. So I'm sure there's going to be a discussion.
 
 
  -
  Arnaud
 
  Le 1 déc. 2012 à 00:20, Jason van Zyl ja...@tesla.io a écrit :
 
  I'm done with the issues that cropped up so I'm ready to 
 re-spin 3.1.0.
 
  Anyone want to add anything or discuss anything before I spin this? 
 I'm not in any rush so if folks want to talk about logging we can. But given 
 the fact once SLF4J initializes it can't change the implementation plugins 
 integrating with Maven need to use the implementation we choose. This is how 
 everything else in the world that integrates SLF4J has to operate so I don't 
 really see us being any different.
 
  I'll wait until tomorrow to re-spin.
 
  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder  CTO, Sonatype
  Founder,  Apache Maven
  http://twitter.com/jvanzyl
  -
 
  -
  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  CTO, Sonatype
  Founder,  Apache Maven
  http://twitter.com/jvanzyl
  -
 
  Simplex sigillum veri. (Simplicity is the seal of truth.)
 
 
 
 
 
 
 -
 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] Maven 3.1.0

[Mark Struberg]

In that case the users cannot use plain slf4j APIs and we would not gain 
anything anyway.

This would have the same effect like not exposing the classes in our core realm 
at all.

LieGrue,
strub




 From: Arnaud Héritier aherit...@gmail.com
To: Maven Developers List dev@maven.apache.org; Mark Struberg 
strub...@yahoo.de 
Sent: Saturday, December 1, 2012 11:20 AM
Subject: Re: [VOTE] Maven 3.1.0
 

Couldn't we use the shading plugin to not expose the original implementation 
(logback, log4k, whatever ..) but a repackaged one to avoid conflicts with 
plugins which may bring (intentionally or by error) its own impl ? ?
Perhaps my idea is just stupid ...


Arnaud



On Sat, Dec 1, 2012 at 11:02 AM, Mark Struberg strub...@yahoo.de wrote:

what is complex with say am openjpa enhancer mojo?
Still this will break depending what the project configures in it's 
persistence.xml.

Just an idea for now:
The safe route might be a plugin-plugin annotatation which tells us 'plugin 
uses slf4j' in that case it gets exposed, in other cases it doesn't.

Old maven versions will ignore the tag in plugin.xml and mvn-3.1++ will 
evaluate it and add slf4j injection support for those plugins.


LieGrue,
strub



- Original Message -

 From: Benson Margulies bimargul...@gmail.com
 To: Maven Developers List dev@maven.apache.org
 Cc:

 Sent: Friday, November 30, 2012 10:15 PM
 Subject: Re: [VOTE] Maven 3.1.0


 At the end of the day, either Maven uses a standard logging API inside
 plugins, or it does not. Using a standard logging API has giant
 advantages - but it can inconvenience people integrating complex code
 via plugins.

 In this thread, there are two approaches to removing that
 inconvenience: a plugin annotation that changing the logging
 integration, and use of forking. Both work. I have some sympathy for
 the view that anything complex enough to care should fork. When people
 integrate big complex things, it has unpleasant consequences like
 System.exit() calls.

 So I'm entirely +1 for the code as it stands, and I see adding an
 annotation or something to avoid injecting the logging back end as a
 nice to have. As I wrote before, I'd feel better about the 'stick a
 fork' in it prescription if we had better reusable forking code.

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


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





-- 

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




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

Re: 3.1.0 decision making

[Mark Struberg]

@Benson
No one, as far as I recall, objected, but perhaps my memory is selective.
just for the record: I did cast -1 on the commit and explained my objections ...

I
 obviously don't like it but I wont 'veto' it as those technical 
questions are simply majority votes. And there are quite some devs who 
like it it seems...



@Kristian
  As long as the reworked plugins still work

 with older maven versions I think we're in the clear.
The new plugins will only work with maven-3.1++ as they will not find any slf4j 
logger on older versions.

What I'm more concerned is that old projects which perfectly work with 
mvn-2.2.0, mvn-2.2.1, mvn-3.0.3, mvn-3.0.4, etc don't work anymore with 
mvn-3.1. This will not be the case very often but it will happen. Of course 
nothing which cannot get fixed. Well, the LocationAwareLogger incompatibility 
might be a blow sometimes...

LieGrue,
strub


- Original Message -
 From: Kristian Rosenvold kristian.rosenv...@gmail.com
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Saturday, December 1, 2012 6:51 PM
 Subject: Re: 3.1.0 decision making
 
 Although I generally stay away from any kind of logging-discussion
 (and logging in general), I'd like to add my 0.5 NOK:
 
 The version number *is* 3.1 due to this slight compatibility change;
 we need to make this clear in release announcements to control
 community expectations.
 
 If a few plugins need reworking to stay compatible I think that's ok;
 it's the price of progress. As long as the reworked plugins still work
 with older maven versions I think we're in the clear.
 
 Furthermore I do not think maven needs to be a generalized execution
 environment that imposes no constraints on plugins. This is IMO where
 maven differs from something like an EJB container.
 
 I say 1 or 4 are the only viable options, and I'm all for 1.
 
 Kristian
 
 2012/12/1 Benson Ma rgulies bimargul...@gmail.com:
  I'm writing this to move the discussion about our next release off of
  a VOTE thread, where I don't think it belongs.
 
  Let me make a little historical summary. Jason and others made a
  series of significant changes to the core internals, including changes
  to logging that some users of some plugins may view as incompatible.
 
  No one vetoed those changes, though there's been plenty of discussion.
 
  Jason sent email announcing his intention to RM a 3.1.0.
 
  No one, as far as I recall, objected, but perhaps my memory is selective.
 
  Jason put 3.1.0 out for a vote.
 
  Two sets of objections surfaced:
 
  o The objection of those who are not happy with the logging change.
  o The objection of those who think it a problem to create a 3.x
  release with only internal improvements, but no user-visible features.
  (Footnote: fixing all the memory leakage is a big user-visible
  'feature' for M2E and other embedded users.)
 
  I wish that people had raised these objections at the time that the
  release was proposed, but the main matter at hand is to decide what to
  do about them.
 
  I offer some options:
 
  1: proceed 'as-is'. Some people won't love 3.1 because it 
 offers them
  nothing they care about, and others may object to the results of the
  logging change. So they will hang back until we make further progress.
  That's fine. If someone hits a bad-enough bug, we can even make a
  3.0.5.
 
  2: proceed 'as-is', but announce and release-note the release as
  something like: Release 3.1.0 is intended for use by plugin
  developers and advanced users to test out and exercise significant
  architectural changes. Others may prefer to stick to 3.0.4 until we go
  through a cycle of collecting feedback and push out one or more 3.1.x
  releases.
 
  3: Same idea as (2), but label it 3.1-beta1.
 
  4: Stop in our tracks until we resolve these questions.
 
  I'm opposed to option 4. I'm particularly opposed to the view that 
 a
  3.1 release must have goodies for end users, like fancy colors. I've
  no objection to (or use for) colors, but I feel quite strongly that
  it's legitimate to ship a release that pushes out architecture even if
  it has no instant gratification for end users.
 
  As for the logging argument, I'd rather take (2) or (3) than (4).
 
  -
  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


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

Re: 3.1.0 decision making

[Mark Struberg]

+1 for 3.1.0-m1


LieGrue,
strub



- Original Message -
 From: Hervé BOUTEMY herve.bout...@free.fr
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Saturday, December 1, 2012 7:03 PM
 Subject: Re: 3.1.0 decision making
 
 Le samedi 1 décembre 2012 18:52:51 Dennis Lundberg a écrit :
  I would -1 any suggestion to start using the beta moniker 
 again, at
  least for the changes made this far.
 I completely agree
 would it be more a milestone, to show the stable but work in 
 progress state?
 3.1.0-m1?
 
 -
 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: Re-spinning 3.1.0

[Mark Struberg]

 How many times does someone really need a different implementation?

Sorry Jason, thats bollocks and you know it. 



 That is the pattern of most forms of 
 integration because trying to account for many implementations interacting 
 together have unknown side affects.


You are wrong and right at the same time:
Yes it's broken and has unknown side effects. Thanks for finally acknowledging 
this. So why the hell do we force a single established framework to any user at 
all? That's the reason why any sane container I know doesn't do that.


Again: the easy solution would be a slf4j-MojoLogging bridge and all is fine. 

Plugins which like to use slf4j can simply use this bridge and all is fine. 
Other plugins will not be hurt.

LieGrue,
strub



- Original Message -
 From: Jason van Zyl ja...@tesla.io
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Saturday, December 1, 2012 10:31 PM
 Subject: Re: Re-spinning 3.1.0
 
 
 On Dec 1, 2012, at 12:39 PM, Olivier Lamy ol...@apache.org wrote:
 
  Hi,
 
  Why do we have to force our users to a specific logging implementation
  than we choose ?
 
 My counter argument is why don't we? That is the pattern of most forms of 
 integration because trying to account for many implementations interacting 
 together have unknown side affects. Just because you can do something 
 doesn't mean it's useful.
 
  We can propose variants and at least one as a workaround to maybe fix
  sonar issue.
 
  So what I do in the branch called dynamic-logging-impl is a 
 dynamic
  way of loading the implementation users prefers (default is log4j2).
  It's just a matter of modifying 
 MAVEN_OPTS=-Dmaven.logger.impl=log4j2
  or slf4-simple or logback (and thanks to our home made 
 osgi
  classworld :-) )
 
 The point again is just because you can do doesn't mean it's useful. How 
 many times does someone really need a different implementation? Just because 
 someone wants something doesn't mean you should give it to them. I believe 
 just allowing anything isn't actually helpful to anyone.
 
 
  Note: with this implementation is possible to use any other slf4j impl
  you want (IMHO good enhancement for ci servers which want to route
  logs somewhere)
  It's just a matter of adding a realm in m2.conf
 
  [thegreat-new-a-la-mode-slf4j-impl]
  load       path to my great new slf4j impl/*.jar
 
  Then
 
 MAVEN_OPTS=-Dmaven.logger.impl=thegreat-new-a-la-mode-slf4j-impl
 
 
 I don't think that's particularly easy and additionally opens us up to 
 having to specifically support any SLF4J implementation which I don't think 
 is wise.
 
 I think we need to pick one and go with it. If users want something different 
 they can change the structure of the distribution.
 
  Anyway just tested with sonar and
  [ERROR] Failed to execute goal
  org.codehaus.mojo:sonar-maven-plugin:2.0:sonar (default-cli) on
  project hello-world: Can not execute Sonar:
  ch.qos.logback.classic.LoggerContext cannot be cast to
  ch.qos.logback.classic.LoggerContext
  I always love such classloader message :-)
 
  So I need to investigate a little bit more but not so far from having
  that for sonar
  BTW works fine for classic use case.
 
  If you want to test that a build is available here:
  http://people.apache.org/~olamy/maven/dynamic-logging-impl/
 
  2012/12/1 Jason van Zyl ja...@tesla.io:
 
  On Dec 1, 2012, at 12:17 AM, Arnaud Héritier 
 aherit...@gmail.com wrote:
 
  Hi Jason,
 
  Couldn't we have a look at olamy's log4j2 branch to see if 
 we could
  sanitize / merge it to propose at least one change for the end user
  and demonstrate the interest of the change about logs : a colorized
  console.
 
  Not without discussion about the implementation. To me the obvious 
 choice is Logback and using Log4J2 makes no sense. Olivier disagrees so there 
 will be a discussion. I've been working on the release but I plan to make a 
 branch using Logback so we have a basis for discussion.
 
 
  I remember you did that in mvnsh/teslashell a long time ago (as an
  extension ?) and perhaps it could be easy to add properly this 
 feature
  in 3.1.0 (otherwise it won't be before a 3.2.0).
 
  Myself I'm using a 3.1.0 fork with this patch and I' m 
 really
  satisfied (it's so good to quickly see highlighted warning and 
 errors
  ). I merged it back in the last 3.1.0 tag you did without issue
 
  Wdyt?
 
  Just as easy with Logback, the only difference being Logback is a 
 mature solution. So I'm sure there's going to be a discussion.
 
 
  -
  Arnaud
 
  Le 1 déc. 2012 à 00:20, Jason van Zyl ja...@tesla.io a 
 écrit :
 
  I'm done with the issues that cropped up so I'm ready 
 to re-spin 3.1.0.
 
  Anyone want to add anything or discuss anything before I spin 
 this? I'm not in any rush so if folks want to talk about logging we can. But 
 given the fact once SLF4J initializes it can't change the implementation 
 plugins integrating with Maven need to use the implementation we choose. This 
 is 
 how 

Re: [VOTE] Maven 3.1.0

[Mark Struberg]

That's all broken by design as already predicted 2 months ago.

Imo the only portable way is to NOT expose slf4j in the Core Realm at all.
The other way would be to introduce a plugin-plugin configuration which says 
logging yes/no.

LieGrue,
strub




- Original Message -
 From: Stephen Connolly stephen.alan.conno...@gmail.com
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Friday, November 30, 2012 8:15 PM
 Subject: Re: [VOTE] Maven 3.1.0
 
 What about the case where a plugin needs to work with both 3.0.4 and 3.1.0
 
 Currently 3.0.4 does not provide either the api or an impl, so I need both
 as a dependency..,
 
 I'm being a good boy, so my impl is custom to route through to o.a.m.p.Log
 and part of the plugin jar (because it makes most sense to scope it there)
 
 What happens when that runs on 3.1.0?
 
 Oh and in my custom slf4j impl I actuall knock all the logging levels down
 by 1, because this tool I am using is too verbose and what it spouts at
 INFO is really DEBUG... So bypassing my impl would be a bad thing 
 for
 users
 
 On Friday, 30 November 2012, Jason van Zyl wrote:
 
  For case 2) I would say only fork if your logging is know to interfere
  with standard SLF4J practices which I think would be rare. But I'll see 
 how
  easy it is to implement a flag while I'm looking at this in general.
 
  On Nov 30, 2012, at 4:20 AM, Stephen Connolly 
  stephen.alan.conno...@gmail.com wrote:
 
   I tend to agree. There are two use-cases I see that a plugin has for
   bundling a logging implementation:
  
   1. They are wanting to shunt the logs from the build tool they are
  invoking
   on to the user. Typically if they are being good plugins they just 
 take
  the
   logging output and shunt it onto org.apache.maven.plugin.Log.info()
  
   2. They are wanting to shunt the logs from the build tool (or more 
 likely
   app server) to a separate file, or tweak the level of logs higher than
  INFO
   for that app server/mojo execution as it will just drown the user.
  
   In the first use case, Jason's point is correct. They 
 shouldn't need to
   bundle a logging implementation any more.
  
   The second case, Jason is arguing that they shouldn't be using the 
 Maven
   JVM for running that tool, they should be running it in a forked JVM 
 and
   then they can configure the logging in that JVM. I disagree. Forking a
  JVM
   for every little build tool just to control its logging is going to 
 kill
   the build time.
  
   My preference is for a metadata flag that says: Oy! I know what 
 I'm doing
   with logging, so don't pass logging on to me.
  
   While it feels like a special case the truth is logging is 
 always, and
   always will be, a special case!
  
   -Stephen
  
  
   On 30 November 2012 12:09, Benson Margulies 
 bimargul...@gmail.com
  wrote:
  
   On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl 
 ja...@tesla.io wrote:
  
   On Nov 29, 2012, at 5:56 PM, Benson Margulies 
 bimargul...@gmail.com
   wrote:
  
  
   Currently I'm of the mind that if you make a Maven 
 plugin that uses
   something that employs SLF4J then the best practice is to only use 
 the
  API
   and let the host choose the implementation, in our case Maven. 
 Relying
  on
   SLF4J implementation specifics in a system you're embedded in 
 is not
  good
   e.g. Logback in Sonar running in Maven using SLF4J Simple. If you 
 want
  to
   your own logging thing while being invoked by Maven then you fork 
 the
  JVM
   and then you can do whatever you want.
  
   I read Olivier's point to be this: it would be cool if 
 we could think
   of a way for a plugin to use the slf4j API and remain 
 independent of
   the logging workings of the maven core.
  
   I think you mean remain independent of the SLF4J implemented 
 used by
   Maven's core.
  
   Sure, but my counter line of argument would be is that really 
 valid? If
   you are running in the context of Maven and you're using SLF4J 
 I think
  you
   should defer to what Maven has setup.
  
   As things are, that could be
   done only, I think, by using shade to  rename a copy of 
 slf4j for the
   guts of the plugin.
  
   We have the capability in the core, that is OSGi-esque, that 
 allows us
   to block classes from being accessible to plugins. We can 
 block/allow
  any
   classes we choose: we can effectively make anything invisible to
  plugins if
   we choose. This capability was added to Classworlds some time ago.
  
   If I were less sleep-deprived, I might be able to
   put forth an idea about how an enhancement to slf4j could 
 allow
   everyone to be happy here, but I don't see a way to 
 make everyone
   happy as things are.
  
   My personal view is that 'giant subsystem' plugins 
 are rarities at
   most, and the attraction of saying 'the Maven logging 
 API *is* slf4j'
   outweighs for me the problems.
  
   I think everyone agrees there, it's really now a matter 
 would we let
   plugins pick and use a different implementation than the 

Re: [VOTE] Maven 3.1.0

[Mark Struberg]

I don't believe it's valid to just let everyone do whatever they want.

Well, I think this is the fundamental point we disagree on.
Maven is not only a build system but also a container which runs user specific 
stuff. And a container should try to isolate as much internal details from it's 
users as he can. So yes, imo we should let everyone do whatever they want! 

By forcing some specific logging mechanism on any users we will heavily 
restrict plugin programmers. And sometimes even the plugin programmers cannot 
change anything because the are only 'users' of the library the plugin uses.


I personally believe we will introduce quite some backward incompatibility.
Plugins which didn't use slf4j will not see any difference. And plugins and 
frameworks which used slf4j will loose control over their logging.

I'd be happy to be proved wrong...

LieGrue,
strub


 From: Jason van Zyl ja...@tesla.io
To: Maven Developers List dev@maven.apache.org; Mark Struberg 
strub...@yahoo.de 
Sent: Friday, November 30, 2012 9:08 PM
Subject: Re: [VOTE] Maven 3.1.0
 



On Nov 30, 2012, at 11:55 AM, Mark Struberg strub...@yahoo.de wrote:

That's all broken by design as already predicted 2 months ago.




It is not broken by design and you're not being helpful. Retreating into 
trying to implement all this ourselves is not a solution. Try it Mark, 
implement your system and ignore everything that's been done and I predict 
you're going to end up in the exact same place because integrating many 
systems in a common way is hard. This is the nitty gritty of integration, it's 
ugly to make it work but that's always the way it is.


We're still going to end up in the same place and it's not impossible to 
change the way the binding works in SLF4J and it's been requested, but the 
entire world of use of SLF4J doesn't seem to see it as a problem.

Imo the only portable way is to NOT expose slf4j in the Core Realm at all.
The other way would be to introduce a plugin-plugin configuration which says 
logging yes/no.




I don't believe it's valid to just let everyone do whatever they want. The 
only problem we've seen thus far is a problem where it's clearly a misuse of 
the SLF4J API. I still argue that the implementation used by the core can be 
used by plugins and letting arbitrary implementations and arbitrary 
manipulation of the logging system isn't really that valuable in compared to 
having a a consistent pattern that's used by so many others.

LieGrue,
strub




- Original Message -

From: Stephen Connolly stephen.alan.conno...@gmail.com
To: Maven Developers List dev@maven.apache.org
Cc: 
Sent: Friday, November 30, 2012 8:15 PM
Subject: Re: [VOTE] Maven 3.1.0

What about the case where a plugin needs to work with both 3.0.4 and 3.1.0

Currently 3.0.4 does not provide either the api or an impl, so I need both
as a dependency..,

I'm being a good boy, so my impl is custom to route through to o.a.m.p.Log
and part of the plugin jar (because it makes most sense to scope it there)

What happens when that runs on 3.1.0?

Oh and in my custom slf4j impl I actuall knock all the logging levels down
by 1, because this tool I am using is too verbose and what it spouts at
INFO is really DEBUG... So bypassing my impl would be a bad thing 
for
users

On Friday, 30 November 2012, Jason van Zyl wrote:


For case 2) I would say only fork if your logging is know to interfere
with standard SLF4J practices which I think would be rare. But I'll see 
how

easy it is to implement a flag while I'm looking at this in general.

On Nov 30, 2012, at 4:20 AM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:


I tend to agree. There are two use-cases I see that a plugin has for
bundling a logging implementation:

1. They are wanting to shunt the logs from the build tool they are

invoking

on to the user. Typically if they are being good plugins they just 
take

the

logging output and shunt it onto org.apache.maven.plugin.Log.info()

2. They are wanting to shunt the logs from the build tool (or more 
likely

app server) to a separate file, or tweak the level of logs higher than

INFO

for that app server/mojo execution as it will just drown the user.

In the first use case, Jason's point is correct. They 
shouldn't need to

bundle a logging implementation any more.

The second case, Jason is arguing that they shouldn't be using the 
Maven

JVM for running that tool, they should be running it in a forked JVM 
and

then they can configure the logging in that JVM. I disagree. Forking a

JVM

for every little build tool just to control its logging is going to 
kill

the build time.

My preference is for a metadata flag that says: Oy! I know what 
I'm doing

with logging, so don't pass logging on to me.

While it feels like a special case the truth is logging is 
always, and

always will be, a special case!

-Stephen


On 30 November 2012 12:09, Benson Margulies 
bimargul...@gmail.com

wrote:



On Thu, Nov 29

Re: Preserve whitespace in Maven plugin configuration?

[Mark Struberg]

That's a tricky one. 

1st: this is probably already optimized away by the XML reader.

2nd:what about this configuration
  url
    someurl_handed_over_to_scm

  /url

In this case we really must get rid of the whitespaces, otherwise we would 
probably create lots of issues with plugins.

LieGrue,
strub


- Original Message -
 From: Olivier Lamy ol...@apache.org
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Sunday, November 18, 2012 9:10 AM
 Subject: Re: Preserve whitespace in Maven plugin configuration?
 
 2012/11/18 Hervé BOUTEMY herve.bout...@free.fr:
  I just implemented MODELLO-256, which will permit to preserve whitespace in
  Maven plugins configuration: see MNG-5380 [1].
 
  The question is: should we change the overall behaviour (plugins can trim 
 when
  they need, and usually, there is no extra space in plugin configurations so
  nothing will break) or should we implement a more complex scenario where
  whitespace is trimmed by default but preserved only when 
 xml:space=preserve
  is found?
 
  WDYT?
 +1 for xml:space=preserve.
 Using real norm sounds good for me.
 
  Hervé
 
  [1] https://jira.codehaus.org/browse/MNG-5380
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 
 
 --
 Olivier Lamy
 Talend: http://coders.talend.com
 http://twitter.com/olamy | http://linkedin.com/in/olamy
 
 -
 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