Re: Beginning the process of updating maven-pmd-plugin

[Anders Hammar]

Create an account on Xircles [1] and then file a JIRA ticket [2] with your
patch. Please include integration tests or similar to verify the new
functionality.

[1] https://xircles.codehaus.org/
[2] http://jira.codehaus.org/browse/MPMD

/Anders

On Mon, Jan 19, 2015 at 2:15 AM,  wrote:

> I've developed an update to the maven-pmd-plugin 3.3 project which allows
> it to check JSP files - I'd like to begin the process of getting the
> plugin updated, but I'm not sure what the next step is.  Is there someone
> who can guide me on this process or direct me to the documentation?
>
> Thanks -
>
>
> Tom Williamson
> Senior Developer
> O'Reilly Automotive
> twilliamso...@oreillyauto.com
>
>
> This communication and any attachments are confidential, protected by
> Communications Privacy Act 18 USCS § 2510, solely for the use of the
> intended recipient, and may contain legally privileged material. If you
> are not the intended recipient, please return or destroy it immediately.
> Thank you.

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

[Andreas Gudian]

Hi Norbert,

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

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

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

Thanks,
Andreas

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

2015-01-18 22:56 GMT+01:00 Norbert Wnuk :

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

Re: Releasing the Checkstyle Plugin

[Henning Schmiedehausen]

Thanks, will do.

On Sun, Jan 18, 2015 at 8:12 AM, Dennis Lundberg  wrote:
> Henning,
>
> Please try the latest 2.14-SNAPSHOT version from the ASF repository.
> You should be able to just override the Checkstyle version by adding a
> dependency on Checkstyle 6.2 to the Maven Checkstyle Plugin in your
> project's POM.
>
> On Sat, Jan 17, 2015 at 6:39 PM, Henning Schmiedehausen
>  wrote:
>> As long as I can just drop in 6.2 and the plugin does not break (as it
>> does today), I am fine.
>>
>> We are running our own checkstyle ruleset anyway, it is just the
>> default that does not work well.
>>
>> Where are your changes, I haven't seen them on the trunk @ github.
>>
>> -h
>>
>>
>> On Sat, Jan 17, 2015 at 9:30 AM, Hervé BOUTEMY  wrote:
>>> yes, i know you did that in the branch to test upgrade for a release with
>>> Checkstyle 6.2 as default version
>>>
>>> I did it in trunk, even without changing Checkstyle version: even if maven-
>>> checkstyle-plugin ships with an older Checkstyle version as default
>>> dependency, end-users can now upgrade the dependency when using the plugin
>>>
>>> Regards,
>>>
>>> Hervé
>>>
>>>
>>> Le samedi 17 janvier 2015 09:17:08 Henning Schmiedehausen a écrit :
 I already did that. See https://github.com/apache/maven-plugins/pull/42

 -h

 On Sat, Jan 17, 2015 at 9:02 AM, Hervé BOUTEMY 
>>> wrote:
 > Le mercredi 14 janvier 2015 11:08:40 Henning Schmiedehausen a écrit :
 >> The 6.2 checkstyle requires java 7 and it also removes (!) at least
 >> one of the checks (RedundantThrows) which is used in all shipped
 >> checkstyle sets and one of the integration tests. So you can no longer
 >> use any of the builtin styles but have to use a custom style which has
 >> the RedundantThrows check removed.
 >
 > the RedundantThrows check causes a lot of false positives: it is maked as
 > "ingore" in Maven parent pom
 > I'll remove it from default configs for next release: see MCHECKSTYLE-276
 >
 >> Having code that can dynamically discover whether a given check exists
 >> or not and change the configuration accordingly is something that
 >> probably would need to be done inside checkstyle proper, not the
 >> plugin driving it.
 >>
 >> I have a pull request prepared (not pushed yet) which would upgrade
 >> checkstyle and the build to java 7 for a possible 2.16 release. One of
 >> the problems here is that at least one integration test will not pass
 >> until the patch was applied to trunk (because it remote-loads the rule
 >> set from the svn repo which in turn currently still has the bad rule).
 >>
 >> It is all a mess and prolonging it to accomodate the one hold-out on
 >> Java 5 (which is EOLed for > 5 years now) and the few that insist on
 >> using Java 6 (which is EOLed for ~ 2 years) makes no sense to me. We
 >> should lead, not lag behind.
 >>
 >> -h
 >>
 >> On Tue, Jan 13, 2015 at 11:09 PM, Hervé BOUTEMY 
 >
 > wrote:
 >> > question: is upgrading only a question of changing dependency version?
 >> > or
 >> > does it require code change?
 >> > and if it requires code change, can we do it with reasonable 
 >> > reflection
 >> > or
 >> > is it really too much change?
 >> >
 >> > because if we can let the end user upgrade his config (and better
 >> > document), we would get the best of every choice
 >> >
 >> > Regards,
 >> >
 >> > Hervé
 >> >
 >> > Le mardi 13 janvier 2015 19:52:35 Henning Schmiedehausen a écrit :
 >> >> I would pretty much abandon anything pre-Java 6 at this point and
 >> >> start moving towards Java 7 soon. The checkstyle plugin right now has
 >> >> three open releases with only the third being really useful ("upgrade
 >> >> to latest checkstyle") and given the previous release cadence it 
 >> >> makes
 >> >> me fear that this release will not show before Mid-2015.
 >> >>
 >> >> -h
 >> >>
 >> >> On Fri, Jan 9, 2015 at 4:29 AM, Dennis Lundberg 
 >
 > wrote:
 >> >> > I've started going through the open issues and have found a problem
 >> >> > that I need som help with. It turns out that Checkstyle 5.9 uses
 >> >> > Java
 >> >> > 6 classes, even though it is not mentioned in the release notes. 
 >> >> > How
 >> >> > do we want to handle this? I see two possible options:
 >> >> >
 >> >> > 1. Make version 2.14 of the plugin require Java 6, and update it to
 >> >> > use the latest available version of Checkstyle that runs on Java 6.
 >> >> >
 >> >> > 2. Revert the plugin back to Checkstyle 5.8 and release 2.14 of the
 >> >> > plugin with a Java 5 requirement. After that release 2.15 of the
 >> >> > plugin fairly straight away with a Java 6 requirement, and using 
 >> >> > the
 >> >> > latest available version of Checkstyle that runs on Java 6. It
 >> >> > should

Beginning the process of updating maven-pmd-plugin

[twilliamson32]

I've developed an update to the maven-pmd-plugin 3.3 project which allows 
it to check JSP files - I'd like to begin the process of getting the 
plugin updated, but I'm not sure what the next step is.  Is there someone 
who can guide me on this process or direct me to the documentation?

Thanks - 


Tom Williamson
Senior Developer
O'Reilly Automotive
twilliamso...@oreillyauto.com


This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the 
intended recipient, and may contain legally privileged material. If you 
are not the intended recipient, please return or destroy it immediately. 
Thank you.

Surefire Plugin does not handle workingDirectory in fork mode properly

[Norbert Wnuk]

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

directory_${surefire.forkNumber}

Regards,
Norbert

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

Re: [VOTE] Release Apache Maven GPG Plugin version 1.6 - Take 2

[Hervé BOUTEMY]

+1

Regards,

Hervé

Le jeudi 15 janvier 2015 20:26:50 Dan Tran a écrit :
> Hi,
> 
> We solved 4 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?
> projectId=11431&version=20125
> 
> There are still a couple of issues left in JIRA:
> http://jira.codehaus.org/issues/?jql=project%20%3D%
> 20MGPG%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%
> 20DESC%2C%20priority%20DESC
> 
> Staging repo:
> *https://repository.apache.org/content/repositories/maven-1124
> *
> 
> https://repository.apache.org/content/repositories/maven-1124/org/apache/mav
> en/plugins/maven-gpg-plugin/1.6/maven-gpg-plugin-1.6-source-release.zip
> 
> Source release checksum(s):
> maven-gpg-plugin-source-release.zip sha1:
> c721825f656d0cf27d0fcba394a5542937545b60
> 
> Staging site:
> http://maven.apache.org/plugins-archives/maven-gpg-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
> 
> Thanks
> 
> Dan Tran


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

Re: [VOTE] Release Apache Maven Shared Component: Maven Dependency Analyzer Version 1.6

[Anders Hammar]

+1 (non-binding)

Verified with m-dependency-p ITs.

/Anders

On Sun, Jan 18, 2015 at 3:34 PM, Karl Heinz Marbaise 
wrote:

> Hi,
>
> We solved 3 issues:
> https://jira.codehaus.org/secure/ReleaseNote.jspa?
> projectId=11761&version=20721
>
> There are still a couple of issues left in JIRA:
> https://jira.codehaus.org/browse/MSHARED/component/13265
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1127
>
> https://repository.apache.org/content/repositories/maven-
> 1127/org/apache/maven/shared/maven-dependency-analyzer/1.6/
> maven-dependency-analyzer-1.6-source-release.zip
>
> Source release checksum(s):
> maven-dependency-analyzer-1.6-source-release.zip sha1:
> 5b7c90f1fdf048dbeb8a4016a4c403b5501e257b
>
> Staging site:
> http://maven.apache.org/shared-archives/maven-dependency-analyzer-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
>
>

Re: [VOTE] Release Apache Maven GPG Plugin version 1.6 - Take 2

[Jason van Zyl]

+1

On Jan 16, 2015, at 9:33 AM, Karl Heinz Marbaise  wrote:

> Hi Dan,
> 
> checked SHA1 Ok.
> 
> Checked with Maven 3.2.5, 3.1.1, 3.0.5, 2.2.1 via:
> 
> mvn -Prun-its clean verify
> 
> without any issue..
> 
> +1 from me.
> 
> Kind regards
> Karl Heinz Marbaise
> 
> On 1/16/15 5:26 AM, Dan Tran wrote:
>> Hi,
>> 
>> We solved 4 issues:
>> http://jira.codehaus.org/secure/ReleaseNote.jspa?
>> projectId=11431&version=20125
>> 
>> There are still a couple of issues left in JIRA:
>> http://jira.codehaus.org/issues/?jql=project%20%3D%
>> 20MGPG%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%
>> 20DESC%2C%20priority%20DESC
>> 
>> Staging repo:
>> *https://repository.apache.org/content/repositories/maven-1124
>> *
>> 
>> https://repository.apache.org/content/repositories/maven-1124/org/apache/maven/plugins/maven-gpg-plugin/1.6/maven-gpg-plugin-1.6-source-release.zip
>> 
>> Source release checksum(s):
>> maven-gpg-plugin-source-release.zip sha1:
>> c721825f656d0cf27d0fcba394a5542937545b60
>> 
>> Staging site:
>> http://maven.apache.org/plugins-archives/maven-gpg-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
>> 
>> Thanks
>> 
>> Dan Tran
>> 
> 
> 
> -
> 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
-

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

Re: [VOTE] Release Apache Maven GPG Plugin version 1.6 - Take 2

[Dan Tran]

Hi

We need a couple more PMC votes

Thanks

-D



On Fri, Jan 16, 2015 at 9:59 AM, Dan Tran  wrote:

> +1 ( none binding).
>
> -D
>
> On Fri, Jan 16, 2015 at 6:33 AM, Karl Heinz Marbaise 
> wrote:
>
>> Hi Dan,
>>
>> checked SHA1 Ok.
>>
>> Checked with Maven 3.2.5, 3.1.1, 3.0.5, 2.2.1 via:
>>
>> mvn -Prun-its clean verify
>>
>> without any issue..
>>
>> +1 from me.
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>> On 1/16/15 5:26 AM, Dan Tran wrote:
>>
>>> Hi,
>>>
>>> We solved 4 issues:
>>> http://jira.codehaus.org/secure/ReleaseNote.jspa?
>>> projectId=11431&version=20125
>>>
>>> There are still a couple of issues left in JIRA:
>>> http://jira.codehaus.org/issues/?jql=project%20%3D%
>>> 20MGPG%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%
>>> 20DESC%2C%20priority%20DESC
>>>
>>> Staging repo:
>>> *https://repository.apache.org/content/repositories/maven-1124
>>> *
>>>
>>> https://repository.apache.org/content/repositories/maven-
>>> 1124/org/apache/maven/plugins/maven-gpg-plugin/1.6/maven-
>>> gpg-plugin-1.6-source-release.zip
>>>
>>> Source release checksum(s):
>>> maven-gpg-plugin-source-release.zip sha1:
>>> c721825f656d0cf27d0fcba394a5542937545b60
>>>
>>> Staging site:
>>> http://maven.apache.org/plugins-archives/maven-gpg-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
>>>
>>> Thanks
>>>
>>> Dan Tran
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>

Re: [VOTE] Release Apache Maven Shared Component: Maven Dependency Analyzer Version 1.6

[Jason van Zyl]

+1

On Jan 18, 2015, at 9:34 AM, Karl Heinz Marbaise  wrote:

> Hi,
> 
> We solved 3 issues:
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761&version=20721
> 
> There are still a couple of issues left in JIRA:
> https://jira.codehaus.org/browse/MSHARED/component/13265
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1127
> 
> https://repository.apache.org/content/repositories/maven-1127/org/apache/maven/shared/maven-dependency-analyzer/1.6/maven-dependency-analyzer-1.6-source-release.zip
> 
> Source release checksum(s):
> maven-dependency-analyzer-1.6-source-release.zip sha1: 
> 5b7c90f1fdf048dbeb8a4016a4c403b5501e257b
> 
> Staging site:
> http://maven.apache.org/shared-archives/maven-dependency-analyzer-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
-

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: Releasing the Checkstyle Plugin

[Dennis Lundberg]

Henning,

Please try the latest 2.14-SNAPSHOT version from the ASF repository.
You should be able to just override the Checkstyle version by adding a
dependency on Checkstyle 6.2 to the Maven Checkstyle Plugin in your
project's POM.

On Sat, Jan 17, 2015 at 6:39 PM, Henning Schmiedehausen
 wrote:
> As long as I can just drop in 6.2 and the plugin does not break (as it
> does today), I am fine.
>
> We are running our own checkstyle ruleset anyway, it is just the
> default that does not work well.
>
> Where are your changes, I haven't seen them on the trunk @ github.
>
> -h
>
>
> On Sat, Jan 17, 2015 at 9:30 AM, Hervé BOUTEMY  wrote:
>> yes, i know you did that in the branch to test upgrade for a release with
>> Checkstyle 6.2 as default version
>>
>> I did it in trunk, even without changing Checkstyle version: even if maven-
>> checkstyle-plugin ships with an older Checkstyle version as default
>> dependency, end-users can now upgrade the dependency when using the plugin
>>
>> Regards,
>>
>> Hervé
>>
>>
>> Le samedi 17 janvier 2015 09:17:08 Henning Schmiedehausen a écrit :
>>> I already did that. See https://github.com/apache/maven-plugins/pull/42
>>>
>>> -h
>>>
>>> On Sat, Jan 17, 2015 at 9:02 AM, Hervé BOUTEMY 
>> wrote:
>>> > Le mercredi 14 janvier 2015 11:08:40 Henning Schmiedehausen a écrit :
>>> >> The 6.2 checkstyle requires java 7 and it also removes (!) at least
>>> >> one of the checks (RedundantThrows) which is used in all shipped
>>> >> checkstyle sets and one of the integration tests. So you can no longer
>>> >> use any of the builtin styles but have to use a custom style which has
>>> >> the RedundantThrows check removed.
>>> >
>>> > the RedundantThrows check causes a lot of false positives: it is maked as
>>> > "ingore" in Maven parent pom
>>> > I'll remove it from default configs for next release: see MCHECKSTYLE-276
>>> >
>>> >> Having code that can dynamically discover whether a given check exists
>>> >> or not and change the configuration accordingly is something that
>>> >> probably would need to be done inside checkstyle proper, not the
>>> >> plugin driving it.
>>> >>
>>> >> I have a pull request prepared (not pushed yet) which would upgrade
>>> >> checkstyle and the build to java 7 for a possible 2.16 release. One of
>>> >> the problems here is that at least one integration test will not pass
>>> >> until the patch was applied to trunk (because it remote-loads the rule
>>> >> set from the svn repo which in turn currently still has the bad rule).
>>> >>
>>> >> It is all a mess and prolonging it to accomodate the one hold-out on
>>> >> Java 5 (which is EOLed for > 5 years now) and the few that insist on
>>> >> using Java 6 (which is EOLed for ~ 2 years) makes no sense to me. We
>>> >> should lead, not lag behind.
>>> >>
>>> >> -h
>>> >>
>>> >> On Tue, Jan 13, 2015 at 11:09 PM, Hervé BOUTEMY 
>>> >
>>> > wrote:
>>> >> > question: is upgrading only a question of changing dependency version?
>>> >> > or
>>> >> > does it require code change?
>>> >> > and if it requires code change, can we do it with reasonable reflection
>>> >> > or
>>> >> > is it really too much change?
>>> >> >
>>> >> > because if we can let the end user upgrade his config (and better
>>> >> > document), we would get the best of every choice
>>> >> >
>>> >> > Regards,
>>> >> >
>>> >> > Hervé
>>> >> >
>>> >> > Le mardi 13 janvier 2015 19:52:35 Henning Schmiedehausen a écrit :
>>> >> >> I would pretty much abandon anything pre-Java 6 at this point and
>>> >> >> start moving towards Java 7 soon. The checkstyle plugin right now has
>>> >> >> three open releases with only the third being really useful ("upgrade
>>> >> >> to latest checkstyle") and given the previous release cadence it makes
>>> >> >> me fear that this release will not show before Mid-2015.
>>> >> >>
>>> >> >> -h
>>> >> >>
>>> >> >> On Fri, Jan 9, 2015 at 4:29 AM, Dennis Lundberg 
>>> >
>>> > wrote:
>>> >> >> > I've started going through the open issues and have found a problem
>>> >> >> > that I need som help with. It turns out that Checkstyle 5.9 uses
>>> >> >> > Java
>>> >> >> > 6 classes, even though it is not mentioned in the release notes. How
>>> >> >> > do we want to handle this? I see two possible options:
>>> >> >> >
>>> >> >> > 1. Make version 2.14 of the plugin require Java 6, and update it to
>>> >> >> > use the latest available version of Checkstyle that runs on Java 6.
>>> >> >> >
>>> >> >> > 2. Revert the plugin back to Checkstyle 5.8 and release 2.14 of the
>>> >> >> > plugin with a Java 5 requirement. After that release 2.15 of the
>>> >> >> > plugin fairly straight away with a Java 6 requirement, and using the
>>> >> >> > latest available version of Checkstyle that runs on Java 6. It
>>> >> >> > should
>>> >> >> > be noted that Checkstyle 5.8 does NOT work on Java 8 source code.
>>> >> >> >
>>> >> >> > Perhaps there are other alternatives? What do you think?
>>> >> >> >
>>> >> >> > On Thu, Jan 8, 2015 at 3:51 PM, Dennis Lundberg 
>>> >> >
>>>

Re: Releasing the Checkstyle Plugin

[Dennis Lundberg]

There are now 3 issues left for the 2.14 version in JIRA. I've
commented on two of them. Unless someone wants to include them (and
are willing to do the work shortly) I will move them to the backlog.

After that I will start the release of 2.14.

Then I plan to do 2.15 (Java 6) and 2.16 (Java 7) in quick succession.
So if you have issues you want to add to those versions that are not
already in the road map, please add them now.

The road map is here:
http://jira.codehaus.org/browse/MCHECKSTYLE#selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel


On Thu, Jan 8, 2015 at 8:12 PM, Hervé BOUTEMY  wrote:
> if nobody beats me at it, I'll work on it in 1 or 2 weeks: nothing really
> complex, just "to do"
>
> Regards,
>
> Hervé
>
> Le jeudi 8 janvier 2015 15:51:57 Dennis Lundberg a écrit :
>> Hi,
>>
>> I'd like to release version 2.14 of Maven Checkstyle Plugin. The main
>> motive for 2.14 is the ability to check Java 8 source code.
>>
>> According to the road map there are 5 unresolved issues scheduled for 2.14.
>>
>> https://jira.codehaus.org/browse/MCHECKSTYLE#selectedTab=com.atlassian.jira.
>> plugin.system.project%3Aroadmap-panel
>>
>> If anyone is interested in fixing one or more of these for 2.14 now
>> would be a good time to do it. Just reply here with an estimated time
>> frame. If noone has the time for this now, I'll reschedule those
>> issues for 2.15, which will require Java 6.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>



-- 
Dennis Lundberg

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

Re: Plugin exposing API - best practise?

[Lennart Jörelid]

Hello Igor,

Well - there is certainly a point of requiring the plugin API to require
same dependencies (including versions) as are mandatory for correct
execution of the plugin itself. A common parent defining maven GAVs and
standard dependency management can probably solve that without too much
hazzle.

However, I'm more concerned with the case where the extensions do not
require most/any of the plugin's dependencies at all. The NodeProcessor
example above implies only SAX/DOM dependencies - no JAXB/plexus or other
framework stuff is required at all, since the NodeProcessor specification
does not deal with anything JAXB'ish. Instead, this particular plugin
extension manages post-processing results generated by SchemaGen.
Therefore, I felt it was far from optimal to drench the implementation
project in the JAXB plugin's compile-scope dependencies by not moving the
extensino specifications to separate projects.

It would likely be simpler to just have a single project, and let the users
deal with the complexities of dependency fiddling - but it seems a rather
poor example of applied modularisation.

2015-01-18 14:00 GMT+01:00 Igor Fedorenko :

> I probably wouldn't use this for my plugins
>
> Today, plugin extensions are loaded in the same classloader as the rest
> of plugin dependencies. Hiding plugin dependencies from extensions
> during compile-time does not reflect runtime and can do more harm than
> good. If, for example, a plugin depends on Guava 14, it is probably a
> good idea to compile plugin extensions against the same Guava version.
>
> I also believe most extensibility APIs start as small experiments and
> insisting on separate API module from the get-go seems unnecessary. And
> even for well-defined extensibility API, I will still probably use
> separate "public API" package(s) and move the rest of plugin
> implementation to private packages extensions not supposed to use.
>
> --
> Regards,
> Igor
>
> On 2015-01-18 6:17, Lennart Jörelid wrote:
>
>> Hello folks,
>>
>> I need a best practise here - hope you can assist me with some ideas and
>> suggestions.
>>
>> *APIs for extensible-configuration plugins*
>>
>> I believe that plugins that exposes extensible configuration options
>> should
>> publish the APIs of those options as a separate project, to keep the set
>> of
>> transitive dependencies pushed onto any implementors small.
>>
>> If not extracting the configuration of the plugin to a separate project,
>> you force the entire stack of transitive dependencies from the plugin
>> project onto the implementing project - which might complicate things
>> unnecessarily. I'm making the following assumptions
>>
>>
>> 1. A plugin (say jaxb2-maven-plugin) should expose its API in a
>> project
>> whose GAV connects it to the plugin project. While the artifactID
>> "jaxb2-maven-plugin-configuration-api" is a mouthful, the naming
>> standard
>> clearly connects it to the plugin project itself.
>> 2. The PluginAPI project can contain default implementations - if
>> required - of the  configuration objects which will serve to
>> de-mystify the
>> potentially complex plugin configuration extension implementations.
>> 3. When generating the documentation within the plugin project, it is
>> nice to have all documentation concerning usage and configuration in
>> the
>> same location.
>>
>>
>> *Example*
>>
>>
>> Suppose you define the interface NodeProcessor within the PluginAPI
>> project, and use it within the Plugin project as follows:
>>
>> @Parameter
>> private List postProcessors;
>>
>> .. and that the specification interface is trivial enough:
>>
>> /**
>>   * Processor/visitor pattern specification for DOM Nodes.
>>   *
>>   * @author mailto:l...@jguru.se";>Lennart Jörelid
>>   */
>> public interface NodeProcessor {
>>
>>  /**
>>   * Defines if this visitor should process the provided node.
>>   *
>>   * @param aNode The DOM node to process.
>>   * @return true if the provided Node should be
>> processed by this NodeProcessor.
>>   */
>>  boolean accept(Node aNode);
>>
>>  /**
>>   * Processes the provided DOM Node.
>>   *
>>   * @param aNode The DOM Node to process.
>>   */
>>  void process(Node aNode);
>> }
>>
>> Since the NodeProcessor interface has nothing to do with Maven-esque APIs
>> or JAXB dependencies, I feel that this specification - as well as the few
>> standard existing implementations of the NodeProcessor interface - should
>> be placed in a PluginAPI project instead of the plugin project. This
>> implies that folks wanting to implement their own NodeProcessor does not
>> need to handle/combat any JAXB/Plexus/[whatever] dependencies needed by
>> the
>> plugin project.
>>
>>
>> 1. Do you agree?
>> 2. If not - why? ... and
>> - How else would you suggest we should manage this?
>>
>>
>>
> -
> To unsubscribe, e-mail: dev-

[VOTE] Release Apache Maven Shared Component: Maven Dependency Analyzer Version 1.6

[Karl Heinz Marbaise]

Hi,

We solved 3 issues:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761&version=20721

There are still a couple of issues left in JIRA:
https://jira.codehaus.org/browse/MSHARED/component/13265

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

https://repository.apache.org/content/repositories/maven-1127/org/apache/maven/shared/maven-dependency-analyzer/1.6/maven-dependency-analyzer-1.6-source-release.zip

Source release checksum(s):
maven-dependency-analyzer-1.6-source-release.zip sha1: 
5b7c90f1fdf048dbeb8a4016a4c403b5501e257b


Staging site:
http://maven.apache.org/shared-archives/maven-dependency-analyzer-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

Re: Releasing the dependency plugin?

[Karl Heinz Marbaise]

Hi,

On 1/18/15 2:42 PM, Anders Hammar wrote:

MDEP-466 [1] is the regression I was talking about. The issue has been
fixed in source but it requires a new release of maven-dependency-analyzer.


Ok...Than i will start VOTE for maven-dependency-analyzer...

First ...




[1] https://jira.codehaus.org/browse/MDEP-466

/Anders

On Sun, Jan 18, 2015 at 10:22 AM, Anders Hammar mailto:and...@hammar.net>> wrote:

There's a regression in the last release that would be great to have
fixed as well. I'm not by a computer right now though to dig up the
jira.

/Anders (mobile)

Den 17 jan 2015 09:41 skrev "Karl Heinz Marbaise" mailto:khmarba...@gmx.de>>:

Hi,

On 1/17/15 6:16 AM, Henning Schmiedehausen wrote:

Hi,

any chance to do a dependency plugin release?


Just release it or special issue to be fixed ?


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

Re: Releasing the dependency plugin?

[Anders Hammar]

MDEP-466 [1] is the regression I was talking about. The issue has been
fixed in source but it requires a new release of maven-dependency-analyzer.

[1] https://jira.codehaus.org/browse/MDEP-466

/Anders

On Sun, Jan 18, 2015 at 10:22 AM, Anders Hammar  wrote:

> There's a regression in the last release that would be great to have fixed
> as well. I'm not by a computer right now though to dig up the jira.
>
> /Anders (mobile)
> Den 17 jan 2015 09:41 skrev "Karl Heinz Marbaise" :
>
> Hi,
>>
>> On 1/17/15 6:16 AM, Henning Schmiedehausen wrote:
>>
>>> Hi,
>>>
>>> any chance to do a dependency plugin release?
>>>
>>
>> Just release it or special issue to be fixed ?
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>

Re: Plugin exposing API - best practise?

[Kristian Rosenvold]

2015-01-18 12:17 GMT+01:00 Lennart Jörelid :
> Hello folks,
>
> I need a best practise here - hope you can assist me with some ideas and
> suggestions.
>
> *APIs for extensible-configuration plugins*
>
> I believe that plugins that exposes extensible configuration options should
> publish the APIs of those options as a separate project, to keep the set of
> transitive dependencies pushed onto any implementors small.
>
> If not extracting the configuration of the plugin to a separate project,
> you force the entire stack of transitive dependencies from the plugin
> project onto the implementing project - which might complicate things
> unnecessarily. I'm making the following assumptions

This is pretty much what we've been discussing within surefire; I've
been calling it "surefire-client-api".
As for the exact scope of the deps of the "client-api" module, we're
all in favour of keeping it tight, but as Igor points out - at some
point reality bites anyway :) I really think it's the api definition
that decides the dependencies; so the "classic" api rules apply.
There's no point in piling up unnecessary stuff :)

>
>
>1. A plugin (say jaxb2-maven-plugin) should expose its API in a project
>whose GAV connects it to the plugin project. While the artifactID
>"jaxb2-maven-plugin-configuration-api" is a mouthful, the naming standard
>clearly connects it to the plugin project itself.

Standard naming sounds nice.

>2. The PluginAPI project can contain default implementations - if
>required - of the  configuration objects which will serve to de-mystify the
>potentially complex plugin configuration extension implementations.

I'd say anything goes in this respect.


>3. When generating the documentation within the plugin project, it is
>nice to have all documentation concerning usage and configuration in the
>same location.

We have been discussing the issue of java8 lambdas and api's somewhat;
since we're basically inviting for user supplied hooks - and *most* of
our users will be on java8 within a 0-2 years. Assuming straight
service discovery through plexus component.xml definition of
implementations and injection there will be no such thing; one
interface defines a single extension point and the end user implements
this in one java class which is plexus-injected into the host plugin.

Systematically expressing the client-api as single-method interfaces
does not really provide any value as long as you don't change some
premises. It /would/ be possible to use setter-based injection and
make a single interface "SurefireClientExtensions" that would have
several setters to inject all the various extension points for
instance "setNodeProcessor(NodeProcessor nodeProcessor)". The client
extension project would just implement this one interface and supply
"implementations" of whatever interfaces it needs. This actually has
some potential in supplying custom registration methods that provide
"better" registration options; e.g:

SurefireClientExtensions#addNodeProcessors(NodeProcessor... nodeProcessor)
SurefireClientExtensions#setNodeProcessors(NodeProcessor... nodeProcessor)

This would allow the client-api user to use lambdas and all sorts of
modern goodness. But I must admit I am a bit uncertain as to the
overall gain of this approach.

I am a bit torn in this issue. I probably think the service
registration interface may be a better long-term solution; nice place
to keep all the docs about registration details.

Kristian

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

Re: Plugin exposing API - best practise?

[Igor Fedorenko]

I probably wouldn't use this for my plugins

Today, plugin extensions are loaded in the same classloader as the rest
of plugin dependencies. Hiding plugin dependencies from extensions
during compile-time does not reflect runtime and can do more harm than
good. If, for example, a plugin depends on Guava 14, it is probably a
good idea to compile plugin extensions against the same Guava version.

I also believe most extensibility APIs start as small experiments and
insisting on separate API module from the get-go seems unnecessary. And
even for well-defined extensibility API, I will still probably use
separate "public API" package(s) and move the rest of plugin
implementation to private packages extensions not supposed to use.

--
Regards,
Igor

On 2015-01-18 6:17, Lennart Jörelid wrote:

Hello folks,

I need a best practise here - hope you can assist me with some ideas and
suggestions.

*APIs for extensible-configuration plugins*

I believe that plugins that exposes extensible configuration options should
publish the APIs of those options as a separate project, to keep the set of
transitive dependencies pushed onto any implementors small.

If not extracting the configuration of the plugin to a separate project,
you force the entire stack of transitive dependencies from the plugin
project onto the implementing project - which might complicate things
unnecessarily. I'm making the following assumptions


1. A plugin (say jaxb2-maven-plugin) should expose its API in a project
whose GAV connects it to the plugin project. While the artifactID
"jaxb2-maven-plugin-configuration-api" is a mouthful, the naming standard
clearly connects it to the plugin project itself.
2. The PluginAPI project can contain default implementations - if
required - of the  configuration objects which will serve to de-mystify the
potentially complex plugin configuration extension implementations.
3. When generating the documentation within the plugin project, it is
nice to have all documentation concerning usage and configuration in the
same location.


*Example*

Suppose you define the interface NodeProcessor within the PluginAPI
project, and use it within the Plugin project as follows:

@Parameter
private List postProcessors;

.. and that the specification interface is trivial enough:

/**
  * Processor/visitor pattern specification for DOM Nodes.
  *
  * @author mailto:l...@jguru.se";>Lennart Jörelid
  */
public interface NodeProcessor {

 /**
  * Defines if this visitor should process the provided node.
  *
  * @param aNode The DOM node to process.
  * @return true if the provided Node should be
processed by this NodeProcessor.
  */
 boolean accept(Node aNode);

 /**
  * Processes the provided DOM Node.
  *
  * @param aNode The DOM Node to process.
  */
 void process(Node aNode);
}

Since the NodeProcessor interface has nothing to do with Maven-esque APIs
or JAXB dependencies, I feel that this specification - as well as the few
standard existing implementations of the NodeProcessor interface - should
be placed in a PluginAPI project instead of the plugin project. This
implies that folks wanting to implement their own NodeProcessor does not
need to handle/combat any JAXB/Plexus/[whatever] dependencies needed by the
plugin project.


1. Do you agree?
2. If not - why? ... and
- How else would you suggest we should manage this?




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

Plugin exposing API - best practise?

[Lennart Jörelid]

Hello folks,

I need a best practise here - hope you can assist me with some ideas and
suggestions.

*APIs for extensible-configuration plugins*

I believe that plugins that exposes extensible configuration options should
publish the APIs of those options as a separate project, to keep the set of
transitive dependencies pushed onto any implementors small.

If not extracting the configuration of the plugin to a separate project,
you force the entire stack of transitive dependencies from the plugin
project onto the implementing project - which might complicate things
unnecessarily. I'm making the following assumptions


   1. A plugin (say jaxb2-maven-plugin) should expose its API in a project
   whose GAV connects it to the plugin project. While the artifactID
   "jaxb2-maven-plugin-configuration-api" is a mouthful, the naming standard
   clearly connects it to the plugin project itself.
   2. The PluginAPI project can contain default implementations - if
   required - of the  configuration objects which will serve to de-mystify the
   potentially complex plugin configuration extension implementations.
   3. When generating the documentation within the plugin project, it is
   nice to have all documentation concerning usage and configuration in the
   same location.


*Example*

Suppose you define the interface NodeProcessor within the PluginAPI
project, and use it within the Plugin project as follows:

@Parameter
private List postProcessors;

.. and that the specification interface is trivial enough:

/**
 * Processor/visitor pattern specification for DOM Nodes.
 *
 * @author mailto:l...@jguru.se";>Lennart Jörelid
 */
public interface NodeProcessor {

/**
 * Defines if this visitor should process the provided node.
 *
 * @param aNode The DOM node to process.
 * @return true if the provided Node should be
processed by this NodeProcessor.
 */
boolean accept(Node aNode);

/**
 * Processes the provided DOM Node.
 *
 * @param aNode The DOM Node to process.
 */
void process(Node aNode);
}

Since the NodeProcessor interface has nothing to do with Maven-esque APIs
or JAXB dependencies, I feel that this specification - as well as the few
standard existing implementations of the NodeProcessor interface - should
be placed in a PluginAPI project instead of the plugin project. This
implies that folks wanting to implement their own NodeProcessor does not
need to handle/combat any JAXB/Plexus/[whatever] dependencies needed by the
plugin project.


   1. Do you agree?
   2. If not - why? ... and
   - How else would you suggest we should manage this?


-- 

--
+==+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: l...@jguru.se
| URL:   www.jguru.se
| Phone
| (skype):jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==+

[VOTE] Release Apache Maven Shared Component: Maven JarSigner Version 1.4

[Karl Heinz Marbaise]

Hi,

We solved 4 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761&version=19864

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

Staging repo:
https://repository.apache.org/content/repositories/maven-1125
https://repository.apache.org/content/repositories/maven-1125/org/apache/maven/shared/maven-jarsigner/1.4/maven-jarsigner-1.4-source-release.zip

Source release checksum(s):
maven-jarsigner-1.4-source-release.zip sha1: 
fba2091740bc6acd1c118fbbece107004c2abb16


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

Re: Releasing the dependency plugin?

[Anders Hammar]

There's a regression in the last release that would be great to have fixed
as well. I'm not by a computer right now though to dig up the jira.

/Anders (mobile)
Den 17 jan 2015 09:41 skrev "Karl Heinz Marbaise" :

> Hi,
>
> On 1/17/15 6:16 AM, Henning Schmiedehausen wrote:
>
>> Hi,
>>
>> any chance to do a dependency plugin release?
>>
>
> Just release it or special issue to be fixed ?
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>