date:20170412

Re: Check if parameter is explicitly set

2017-04-12 Thread Karl Heinz Marbaise


Hi,

On 13/04/17 02:05, András Kerekes wrote:

Hi,

I'm working on a Maven plugin and I'd like to check whether a parameter for
a Mojo has been explicitly set by the user (via POM), or it contains the
default value. Is there a way to do this?


Maybe I misunderstand a thing but why do you need to distinguish between 
those two? Isn't that why defaultValue exist?


Kind regards
Karl Heinz Marbaise

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

Fwd: [VOTE] Apache Mahout 0.13.0 Release Candidate

2017-04-12 Thread Andrew Musselman

Hi Maven team, we are having trouble getting a couple new modules included
in our release build and our former "Maven person" can't contribute any
more at their new job.

Anyone up for some troubleshooting? We release from master, our source repo
is at https://github.com/apache/mahout, and our latest artifacts are at
https://repository.apache.org/content/repositories/orgapachemahout-1042/org/apache/mahout/apache-mahout-distribution/0.13.0/
.

Thanks for any help you can offer.

Best
Andrew

-- Forwarded message -
From: Andrew Musselman 
Date: Wed, Apr 12, 2017 at 8:10 PM
Subject: Re: [VOTE] Apache Mahout 0.13.0 Release Candidate
To: 


Does anyone know anyone on the Maven project or who understands the fine
points of making things like this works?

On Wed, Apr 12, 2017 at 8:06 PM Andrew Musselman 
wrote:

> Okay consider this vote cancelled.
>
> On Wed, Apr 12, 2017 at 8:02 PM Andrew Palumbo  wrote:
>
>> The line that I suggested the other day:
>>
>>
>> mvn -Pmahout-release,apache-release,viennacl,hadoop2 release:prepare
>> release:perform
>>
>>
>> doesn't seem to have activated the viennacl profile
>>
>> 
>> From: Andrew Palumbo 
>> Sent: Wednesday, April 12, 2017 10:58:16 PM
>> To: d...@mahout.apache.org
>> Subject: Re: [VOTE] Apache Mahout 0.13.0 Release Candidate
>>
>>
>> off the top of my head i dont know if it is a regression.   My guess is
>> that they were missing before.  I think that this may have something to do
>> with activating the profile -Pviennacl at release time.
>>
>> 
>> From: Andrew Musselman 
>> Sent: Wednesday, April 12, 2017 10:48:13 PM
>> To: d...@mahout.apache.org; u...@mahout.apache.org
>> Subject: Re: [VOTE] Apache Mahout 0.13.0 Release Candidate
>>
>> Is it a regression or were they missing before, do you know?
>>
>> On Wed, Apr 12, 2017 at 7:42 PM Andrew Palumbo 
>> wrote:
>>
>> >
>> > It looks like we're missing some jars from the binary distro:
>> >
>> >
>> > bin
>> >
>> > mahout-integration-0.13.0.jar
>> >
>> > confmahout-math-0.13.0.jar derby.log
>> >  mahout-math-scala_2.10-0.13.0.jar docs
>> > mahout-mr-0.13.0.jar examples
>> > mahout-mr-0.13.0-job.jar flink
>> >  mahout-spark_2.10-0.13.0-dependency-reduced.jar h2o
>> >  mahout-spark_2.10-0.13.0.jar lib
>> >  metastore_db LICENSE.txt NOTICE.txt
>> > mahout-examples-0.13.0.jar  README.md mahout-examples-0.13.0-job.jar
>> > viennacl mahout-hdfs-0.13.0.jar  viennacl-omp
>> >
>> > 
>> > From: Andrew Musselman 
>> > Sent: Tuesday, April 11, 2017 12:05 PM
>> > To: u...@mahout.apache.org; d...@mahout.apache.org
>> > Subject: Re: [VOTE] Apache Mahout 0.13.0 Release Candidate
>> >
>> > I've checked hashes and sigs, and run a build with passing tests for
>> > vanilla, viennacl, and viennacl-omp profiles.
>> >
>> > The spark shell runs the SparseSparseDrmTimer.mscala example in the
>> binary
>> > build and all three source profiles; I saw the GPU get exercised when
>> > running the viennacl profile from source, and saw all cores on the CPU
>> get
>> > exercised when running the viennacl-omp profile from source.
>> >
>> > So far I'm +1 (binding).
>> >
>> >
>> >
>> > On Tue, Apr 11, 2017 at 8:55 AM, Andrew Musselman <
>> > andrew.mussel...@gmail.com> wrote:
>> >
>> > > This is the vote for release 0.13.0 of Apache Mahout.
>> > >
>> > > The vote will be going for at least 72 hours and will be closed on
>> > Friday,
>> > > April 17th, 2017 or once there are at least 3 PMC +1 binding votes
>> > (whichever
>> > > occurs earlier).  Please download, test and vote with
>> > >
>> > > [ ] +1, accept RC as the official 0.13.0 release of Apache Mahout
>> > > [ ] +0, I don't care either way,
>> > > [ ] -1, do not accept RC as the official 0.13.0 release of Apache
>> Mahout,
>> > > because...
>> > >
>> > >
>> > > Maven staging repo:
>> > >
>> > > *
>> >
>> https://repository.apache.org/content/repositories/orgapachemahout-1042/org/apache/mahout/apache-mahout-distribution/0.13.0/
>> > > <
>> >
>> https://repository.apache.org/content/repositories/orgapachemahout-1042/org/apache/mahout/apache-mahout-distribution/0.13.0/
>> > >*
>> > >
>> > > The git tag to be voted upon is mahout-0.13.0
>> > >
>> >
>>
>

[ANN] Apache Maven Surefire Plugin 2.20 Released

2017-04-12 Thread Tibor Digana

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

The release contains 70 bug fixes.
Again we received contributions from the community in form of bug reports
and bug fixes.
Thank you and keep them coming!

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

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


  org.apache.maven.plugins
  maven-surefire-plugin
  2.20


or for failsafe:


  org.apache.maven.plugins
  maven-failsafe-plugin
  2.20


or for surefire-report:

  org.apache.maven.plugins
  maven-surefire-report-plugin
  2.20


Release Notes - Maven Surefire - Version 2.20

Bug

   - [SUREFIRE-725 ] -
   Test result output ist sent to System.out instead of using logger
   - [SUREFIRE-1198 ]
   - Failsafe does not allow to configure the jar file to use
   - [SUREFIRE-1216 ]
   - TEST-*.xml files generated by Surefire are invalid
   - [SUREFIRE-1217 ]
   - Differentiate XML schema for failsafe and surefire
   - [SUREFIRE-1239 ]
   - ExecutionException java.lang.RuntimeException:
   org.apache.maven.surefire.report.ReporterException: When writing xml report
   stdout/stderr (No such file or directory)
   - [SUREFIRE-1244 ]
   - NumberFormatException in parallel test run with runOrder = failedFirst
   - [SUREFIRE-1250 ]
   - Regex testcase filtering: exception when hashmark is regex-quoted
   - [SUREFIRE-1252 ]
   - Tests not being run when using XML suite file with TestNG
   - [SUREFIRE-1268 ]
   - With JUnit listener, redirectTestOutputToFile is ignored
   - [SUREFIRE-1278 ]
   - TestNG tests are run with group name that ends with specified group
   - [SUREFIRE-1284 ]
   - Statistics file should not be determined as (directory of
   surefire-reports).getParentFile().getParentFile(). It is a problem if
   report directory is customized. Statistics file should be located in
   project dir.
   - [SUREFIRE-1289 ]
   - forkedProcessTimeoutInSeconds should not use ping timer of 10 seconds but
   0.1 sec period timer
   - [SUREFIRE-1290 ]
   - Orphan Fork JVMs should be killed after any previous finished with fatal
   error
   - [SUREFIRE-1295 ]
   - JVM crashes in forks do not log the name of the failing test
   - [SUREFIRE-1296 ]
   - The project build directory should not be determined as (directory of
   surefire-reports).getParentFile(). It is a problem if report directory is
   customized.
   - [SUREFIRE-1305 ]
   - surefire fails on parallel tests when newline character is in test
   description
   - [SUREFIRE-1312 ]
   - Classpath containing url special characters with Reflections not working
   - [SUREFIRE-1313 ]
   - Unify console report result in SurefirePlugin and VerifyMojo
   - [SUREFIRE-1315 ]
   - Fix stylistic errors in DefaultReporterFactory
   - [SUREFIRE-1322 ]
   - Surefire and Failsafe should dump critical errors in dump file and console
   - [SUREFIRE-1324 ]
   - Surefire incorrectly suppresses exceptions when closing resources.
   - [SUREFIRE-1333 ]
   - Process pending events from forked process after exited and then finish
   forked Thread.
   - [SUREFIRE-1341 ]
   - Documentation of configuration parameters in Failsafe should mention IT
   instead or Test.java
   - [SUREFIRE-1342 ]
   - Acknowledge normal exit of JVM and drain shared memory between processes
   - [SUREFIRE-1349 ]
   - FreeBSD cross process communication needs to commit stdout data in forked
   JVM within a synchronized block
   - [SUREFIRE-1352 ]
   - Dump file [date]-jvmRun[N] where N should be real fork number
   - [SUREFIRE-1354

[GitHub] maven-plugins pull request #112: MWAR-405 Workaround XStream incompatibility...

2017-04-12 Thread eolivelli

Github user eolivelli closed the pull request at:

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


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

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

[GitHub] maven-plugins pull request #112: MWAR-405 Workaround XStream incompatibility...

2017-04-12 Thread eolivelli

GitHub user eolivelli reopened a pull request:

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

MWAR-405  Workaround XStream incompatibility with Java9

This is a proof-of-concept implementation of a possible way to word-around 
the actual incompatibility of xstreams default converters with java9.
As the maven-war-plugin does not need all of the converters (like 
TreeMapConverter which is the primary cause of the issue) we can just register 
only the needed ones and bypass the java9 issue

see

Caused by: java.lang.reflect.InaccessibleObjectException: Unable to 
make field private final java.util.Comparator java.util.TreeMap.comparator 
accessible: module java.base does not "opens java.util" to unnamed module
Happens while initializing 
org.apache.maven.plugins.war.util.WebappStructureSerializer

at
https://cwiki.apache.org/confluence/display/MAVEN/Java+9+-+Jigsaw

this PR is just a proof-of-concept, there is an email thread on the dev 
list. If the idea is accepted I will submit a JIRA and official PR (some code 
cleanup is needed at least)

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

$ git pull https://github.com/eolivelli/maven-plugins 
maven-war-plugin-easy-fix

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

https://github.com/apache/maven-plugins/pull/112.patch

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

This closes #112


commit 9bd4409a309d461ffc77dda06b11d295797d3b27
Author: eolivelli 
Date:   2017-04-11T08:07:36Z

MWAR-405 Workaround XStream incompatibility with Java9
Register only used Converters




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

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

Re: Check if parameter is explicitly set

2017-04-12 Thread Tibor Digana

Try to put a break point to setter but you won't distinguish between user
and default value.

On Thu, Apr 13, 2017 at 2:06 AM, András Kerekes [via Maven] <
ml-node+s40175n5905937...@n5.nabble.com> wrote:

> Hi,
>
> I'm working on a Maven plugin and I'd like to check whether a parameter
> for
> a Mojo has been explicitly set by the user (via POM), or it contains the
> default value. Is there a way to do this?
>
> Thanks,
>  András
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/Check-if-parameter-is-
> explicitly-set-tp5905937.html
> To start a new topic under Maven Developers, email
> ml-node+s40175n142166...@n5.nabble.com
> To unsubscribe from Maven Developers, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://maven.40175.n5.nabble.com/Check-if-parameter-is-explicitly-set-tp5905937p5905947.html
Sent from the Maven Developers mailing list archive at Nabble.com.

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

2017-04-12 Thread Tibor Digana

Hi,

The vote has passed with the following result:

+1 : Petr Široký (non-binding), Andreas Gudian (binding), Michael Osipov
(binding), Dan Tran (non-binding), Manfred Moser (binding), Hervé BOUTEMY
(binding), Tibor Digana (binding)

PMC quorum: Andreas Gudian, Michael Osipov, Manfred Moser, Hervé BOUTEMY,
Tibor Digana
I will promote the artifacts to the central repo.
I will add the release to the next board report.

Cheers
Tibor

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

2017-04-12 Thread Tibor Digana

+1 (binding)

On Sat, Apr 8, 2017 at 12:53 PM, Tibor Digana 
wrote:

> Hi,
>
> We solved 70 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12317927&version=12334636
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/i#issues/?jql=project+%
> 3D+SUREFIRE+AND+status+%3D+Open+ORDER+BY+priority+DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1330/
> https://repository.apache.org/content/repositories/maven-
> 1330/org/apache/maven/surefire/surefire/2.20/surefire-2.20-source-release.
> zip
>
> Source release checksum(s):
> surefire-2.20-source-release.zip sha1: fda994228c52dcb581d8ce6d4664f8
> 4a29d78797
>
> Git tag:
> https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=
> 8c786523414018099b54a0868ae1bc3d64847411
>
> Staging site:
> http://maven.apache.org/surefire-archives/surefire-LATEST/
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Cheers,
> Tibor
>

Check if parameter is explicitly set

2017-04-12 Thread András Kerekes

Hi,

I'm working on a Maven plugin and I'd like to check whether a parameter for
a Mojo has been explicitly set by the user (via POM), or it contains the
default value. Is there a way to do this?

Thanks,
 András

Re: Github mirror broken

2017-04-12 Thread Hervé BOUTEMY

Le mercredi 12 avril 2017, 22:05:02 CEST Michael Osipov a écrit :
> Am 2017-04-12 um 08:54 schrieb Hervé BOUTEMY:
> > yes, that's what I tried to say (there were 4 branches iin MNG-6169/)
> > 
> > I finally renamed the 4 branches and replaced / with _: now there won't be
> > any stupid failure on Jenkins, and I just checeked that the github mirror
> > is up to date also
> 
> Hell, seriously? You have renamed my dev branches without talking to me
> first?
yes, I fixed a lot of broken tools (many Jenkins jobs, github mirror) without 
breaking anything from your work

> you should have raised this with INFRA because they have to have
> a look at the shortcoming.
how do you intend to fix Jenkins clones?
renaming is easy, fixes a lot of things and does not break anything: I'm 
pragmatic, I prefer an easy workaround now instead of a fight against I don't 
know how many tools, in how much time

> 
> > issue fixed
> > and not to the team: warning about / use in branch names, that may not be
> > such a good idea
> 
> Not at all, using slashes to separate branches are a common approach.
perhaps nobody starts by creating a branch named "mybranch" then renaming to 
"mybranch/subbranch"
And when some unexpected failure happens, that causes tons of Jenkins 
failures, we need to have a quick fix: I did it

Regards,

Hervé


> 
> > Le mercredi 12 avril 2017, 06:08:55 CEST Stephen Connolly a écrit :
> >> I think it was the use of nested name that contributed too:
> >> origin/MNG-6169/updated-MCOMPILER
> >> 
> >> On Wed 12 Apr 2017 at 05:47, Karl Heinz Marbaise  
wrote:
> >>> Hi Hervé,
> >>> 
> >>> On 12/04/17 04:35, Hervé BOUTEMY wrote:
>  I suppose this is tied to lots of intermittent failures on git clone
> >>> 
> >>> updates
> >>> 
>  that Jenkins has [1]
>  error: cannot lock ref 'refs/remotes/origin/MNG-6169/all-updated':
>  'refs/
>  remotes/origin/MNG-6169' exists; cannot create
> >>> 
> >>> 'refs/remotes/origin/MNG-6169/
> >>> 
>  all-updated'
>  
>   ! [new branch]  MNG-6169/all-updated ->
>   origin/MNG-6169/all-updated
>  
>  (unable to update local ref)
>  
>  This creation of branches in MNG-6169/ after having removed MNG-6169
>  has
> >>> 
> >>> bad
> >>> 
>  impact on every clone that does not correctly prune remote references:
>  I
>  suppose the github cloning script has the same issue.
>  
>  I see 2 options:
>  1. try to fix the github cloning script (I don't know where it is) and
> >>> 
> >>> any
> >>> 
>  other failing update (I'm fighting with Jenkins on this for a few days,
> >>> 
> >>> since
> >>> 
>  it seems it keeps copies every here and there...)
>  2. rename MNG-6169/* branches to something like MNG-6169_* to
>  workaround
> >>> 
> >>> the
> >>> 
>  issue
>  
>  Any other idea?
> >>> 
> >>> ~/ws-git/apache/maven (master)$ git fetch --prune origin
> >>> 
> >>>  From https://git-wip-us.apache.org/repos/asf/maven
> >>>  
> >>>   x [deleted] (none) -> origin/MNG-6169/all-updated
> >>>   x [deleted] (none) ->
> >>> 
> >>> origin/MNG-6169/not-updated-MJAR-MCOMPILER
> >>> 
> >>>   x [deleted] (none) -> origin/MNG-6169/updated-MCOMPILER
> >>>   x [deleted] (none) -> origin/MNG-6169/updated-MJAR
> >>>   x [deleted] (none) -> origin/MNG-6185
> >>>   x [deleted] (none) -> origin/MNG-6198
> >>> 
> >>> remote: Counting objects: 93, done.
> >>> remote: Compressing objects: 100% (32/32), done.
> >>> remote: Total 47 (delta 16), reused 0 (delta 0)
> >>> Unpacking objects: 100% (47/47), done.
> >>> 
> >>> 08f3c76..567af0d  master -> origin/master
> >>>   
> >>>   * [new branch]  MNG-6209_multiple-build-extensions ->
> >>> 
> >>> origin/MNG-6209_multiple-build-extensions
> >>> 
> >>> That helped me...
> >>> 
> >>> Kind regards
> >>> Karl Heinz
> >>> 
>  Regards,
>  
>  Hervé
>  
>  [1]
> >>> 
> >>> https://builds.apache.org/job/core-integration-testing-maven-3-jdk-1.8/1
> >>> 00
> >>> 7/console>
> >>> 
>  Le lundi 10 avril 2017, 22:42:47 CEST Mario Krizmanić a écrit :
> > Hi,
> >>> 
> > Could one check and update Github's mirror:
> >>> https://github.com/apache/maven
> >>> 
> >  (g...@github.com
> > :apache/maven.git)
> > 
> > The last commit in the master branch is 87cf1ee while the last one in
> >>> 
> >>> the
> >>> 
> > origin's master is 08f3c76a.
> > 
> > Thanks,
> > Mario
> >>> 
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>> For additional commands, e-mail: dev-h...@maven.apache.org
> >>> 
> >>> --
> >> 
> >> Sent from my phone
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mai

Re: Re[2]: Configurable Dependencies for Maven Plugins?

2017-04-12 Thread Dirk Mahler

Hi Lennart,

that sounds feasible, will give it a try and come back with the result.

Thanks so far to all of you!

Dirk

Am Mittwoch 12. April 2017 schrieb Lennart Jörelid:
> Hello Dirk,
> 
> There are always options for doing this, although they may not be
> considered elegant.
> 
> To solve your problem in a practical way I would recommend defining two
> profiles within your pom (say "neo4jV2" and "neo4jV3").
> One of the properties should be included ("Conditional profiles") using the
> value (or existence/non-existence) of a command-line property (typically
> something like -Dneo4jVersion=2).
> 
> The neo4jv2 profile includes the three neo4j2 dependencies, and the neo4jv3
> profile includes the two neo4j3 dependencies.
> Include the neo4jV3 profile unless the property "neo4jVersion" is set on
> the command line.
> 
> Done.
> 
> 
> 2017-04-12 21:50 GMT+02:00 Dirk Mahler :
> 
> > Hi Stephen,
> >
> > I need to declare the dependency to static directly, so I'm on the
> > Sorry-Out-Of-Luck path...
> >
> > But your suggestion makes me  thinking of providing an artifact myself
> > (just pom packaging) in two different versions that pulls in the different
> > dependencies and which can be overridden by the user. This should be
> > possible then, right?
> >
> > In that case I have to think about how to organize my own builds because I
> > assume that within one reactor I won't be able to build two modules with
> > same groupId and artifactId but different versions.
> >
> > Cheers,
> >
> > Dirk
> >
> > PS: Thanks for the 3.5.0 release, works like a charm for me!
> >
> > Am Mittwoch 12. April 2017 schrieb Stephen Connolly:
> > > On Wed 12 Apr 2017 at 20:21, Dirk Mahler 
> > wrote:
> > >
> > > > Hi Bindul,
> > > >
> > > > sadly it's not that easy (or it's so easy that I don't see the
> > > > solution...). As a default and for compatibility reasons I'd like to
> > > > declare the dependencies of the Neo4j 2.x artifacts for my Maven
> > plugin:
> > > >
> > > > - org.neo4j:neoj
> > > > - org.neo4j.app:neo4j-server
> > > > - org.neo4j.app:neo4j-server:static *
> > >
> > >
> > > Do you declare a direct dependency on static or a transitive one?
> > >
> > > If direct, then yes you are Sorry-out-of-Luck
> > >
> > > If transitive, then the  in the user's  will override
> > > the neo4j-server and you are sorted as the newer version will not pull in
> > > the static stuff
> > >
> > > >
> > > >
> > > > For a user it would be possible to override only the first two
> > > > dependencies with the Neo4j 3.x versions: the third artifact (*) does
> > > > not exist for Neo4j 3.x (the Neo guys merged the static content into
> > > > neo4j-server.jar, i.e. into the main artifact without classifier). In
> > > > this case I would need to exclude "org.neo4j.app:neo4j-server:static"
> > > > which is still there as a 2.x artifact and pulls in some other deps
> > that
> > > > are conflicting with the 3.x stuff. Any idea?
> > > >
> > > > Cheers,
> > > >
> > > > Dirk
> > > >
> > > > -- Originalnachricht --
> > > > Von: "Bindul Bhowmik" 
> > > > An: "Maven Developers List" ; "Dirk Mahler"
> > > > 
> > > > Gesendet: 12.04.2017 20:28:16
> > > > Betreff: Re: Configurable Dependencies for Maven Plugins?
> > > >
> > > > >Dirk,
> > > > >
> > > > >On Wed, Apr 12, 2017 at 7:06 AM, Dirk Mahler
> > > > > wrote:
> > > > >>  Hi all,
> > > > >>
> > > > >>  is there a way to provide users of a plugin a way of easily
> > switching
> > > > >>  dependencies of it?
> > > > >>
> > > > >>  Background: I'm developing a Maven plugin (jQAssistant) that comes
> > > > >>with a
> > > > >>  dependency to Neo4j (graph database). Currently I'm using Neo4j
> > 2.3.x
> > > > >>which
> > > > >>  has been compiled against Java 7 but I would like to offer users of
> > > > >>the
> > > > >>  Maven plugin an easy option to use the newer Neo4j 3.x releases
> > which
> > > > >>offer
> > > > >>  some new features but require Java 8.
> > > > >>
> > > > >>  I know that it's possible to overwrite an existing dependency for a
> > > > >>plugin,
> > > > >>  e.g.
> > > > >>
> > > > >>  
> > > > >>com.buschmais.jqassistant
> > > > >>jqassistant-maven-plugin
> > > > >>1.3.0
> > > > >>
> > > > >>  
> > > > >>org.neo4j
> > > > >>neo4j
> > > > >>3.1.3 
> > > > >>  
> > > > >>
> > > > >>  
> > > > >
> > > > >As long as your code can handle the different versions of the
> > > > >dependency, I think this is absolutely doable. In fact the Maven
> > > > >Checkstyle Plugin uses the same approach to allow upgrading checkstyle
> > > > >versions without upgrading the plugin version [1].
> > > > >
> > > > >>
> > > > >>  The problem is that in my case the old version comes with another
> > set
> > > > >>of
> > > > >>  dependencies than the new one:
> > > > >
> > > > >I do not think this will be a problem.
> > > > >
> > > > >>
> > > > >>  old:
> > > > >>
> > > > >>  
> > > > >>   
> > > > >>   org.neo4j
> > > > >>   neo4j
> > >

Re: Re[2]: Configurable Dependencies for Maven Plugins?

2017-04-12 Thread Lennart Jörelid

Hello Dirk,

There are always options for doing this, although they may not be
considered elegant.

To solve your problem in a practical way I would recommend defining two
profiles within your pom (say "neo4jV2" and "neo4jV3").
One of the properties should be included ("Conditional profiles") using the
value (or existence/non-existence) of a command-line property (typically
something like -Dneo4jVersion=2).

The neo4jv2 profile includes the three neo4j2 dependencies, and the neo4jv3
profile includes the two neo4j3 dependencies.
Include the neo4jV3 profile unless the property "neo4jVersion" is set on
the command line.

Done.


2017-04-12 21:50 GMT+02:00 Dirk Mahler :

> Hi Stephen,
>
> I need to declare the dependency to static directly, so I'm on the
> Sorry-Out-Of-Luck path...
>
> But your suggestion makes me  thinking of providing an artifact myself
> (just pom packaging) in two different versions that pulls in the different
> dependencies and which can be overridden by the user. This should be
> possible then, right?
>
> In that case I have to think about how to organize my own builds because I
> assume that within one reactor I won't be able to build two modules with
> same groupId and artifactId but different versions.
>
> Cheers,
>
> Dirk
>
> PS: Thanks for the 3.5.0 release, works like a charm for me!
>
> Am Mittwoch 12. April 2017 schrieb Stephen Connolly:
> > On Wed 12 Apr 2017 at 20:21, Dirk Mahler 
> wrote:
> >
> > > Hi Bindul,
> > >
> > > sadly it's not that easy (or it's so easy that I don't see the
> > > solution...). As a default and for compatibility reasons I'd like to
> > > declare the dependencies of the Neo4j 2.x artifacts for my Maven
> plugin:
> > >
> > > - org.neo4j:neoj
> > > - org.neo4j.app:neo4j-server
> > > - org.neo4j.app:neo4j-server:static *
> >
> >
> > Do you declare a direct dependency on static or a transitive one?
> >
> > If direct, then yes you are Sorry-out-of-Luck
> >
> > If transitive, then the  in the user's  will override
> > the neo4j-server and you are sorted as the newer version will not pull in
> > the static stuff
> >
> > >
> > >
> > > For a user it would be possible to override only the first two
> > > dependencies with the Neo4j 3.x versions: the third artifact (*) does
> > > not exist for Neo4j 3.x (the Neo guys merged the static content into
> > > neo4j-server.jar, i.e. into the main artifact without classifier). In
> > > this case I would need to exclude "org.neo4j.app:neo4j-server:static"
> > > which is still there as a 2.x artifact and pulls in some other deps
> that
> > > are conflicting with the 3.x stuff. Any idea?
> > >
> > > Cheers,
> > >
> > > Dirk
> > >
> > > -- Originalnachricht --
> > > Von: "Bindul Bhowmik" 
> > > An: "Maven Developers List" ; "Dirk Mahler"
> > > 
> > > Gesendet: 12.04.2017 20:28:16
> > > Betreff: Re: Configurable Dependencies for Maven Plugins?
> > >
> > > >Dirk,
> > > >
> > > >On Wed, Apr 12, 2017 at 7:06 AM, Dirk Mahler
> > > > wrote:
> > > >>  Hi all,
> > > >>
> > > >>  is there a way to provide users of a plugin a way of easily
> switching
> > > >>  dependencies of it?
> > > >>
> > > >>  Background: I'm developing a Maven plugin (jQAssistant) that comes
> > > >>with a
> > > >>  dependency to Neo4j (graph database). Currently I'm using Neo4j
> 2.3.x
> > > >>which
> > > >>  has been compiled against Java 7 but I would like to offer users of
> > > >>the
> > > >>  Maven plugin an easy option to use the newer Neo4j 3.x releases
> which
> > > >>offer
> > > >>  some new features but require Java 8.
> > > >>
> > > >>  I know that it's possible to overwrite an existing dependency for a
> > > >>plugin,
> > > >>  e.g.
> > > >>
> > > >>  
> > > >>com.buschmais.jqassistant
> > > >>jqassistant-maven-plugin
> > > >>1.3.0
> > > >>
> > > >>  
> > > >>org.neo4j
> > > >>neo4j
> > > >>3.1.3 
> > > >>  
> > > >>
> > > >>  
> > > >
> > > >As long as your code can handle the different versions of the
> > > >dependency, I think this is absolutely doable. In fact the Maven
> > > >Checkstyle Plugin uses the same approach to allow upgrading checkstyle
> > > >versions without upgrading the plugin version [1].
> > > >
> > > >>
> > > >>  The problem is that in my case the old version comes with another
> set
> > > >>of
> > > >>  dependencies than the new one:
> > > >
> > > >I do not think this will be a problem.
> > > >
> > > >>
> > > >>  old:
> > > >>
> > > >>  
> > > >>   
> > > >>   org.neo4j
> > > >>   neo4j
> > > >>   2.3.10
> > > >>   
> > > >>   
> > > >>   org.neo4j.app
> > > >>   neo4j-server
> > > >>   2.3.10
> > > >>   
> > > >>   
> > > >>   org.neo4j.app
> > > >>   neo4j-server
> > > >>   static-web
> > > >>   2.3.10
> > > >>   
> > > >>  
> > > >>
> > > >>  new:
> > > >>
> > > >>  
> > > >>   
> > > >>   org.neo4j
> > > >>   neo4j
> > > >>   3.1.3
> >

Re: Github mirror broken

2017-04-12 Thread Michael Osipov


Am 2017-04-12 um 08:54 schrieb Hervé BOUTEMY:

yes, that's what I tried to say (there were 4 branches iin MNG-6169/)

I finally renamed the 4 branches and replaced / with _: now there won't be any
stupid failure on Jenkins, and I just checeked that the github mirror is up to
date also


Hell, seriously? You have renamed my dev branches without talking to me 
first? you should have raised this with INFRA because they have to have 
a look at the shortcoming.



issue fixed
and not to the team: warning about / use in branch names, that may not be such
a good idea


Not at all, using slashes to separate branches are a common approach.


Le mercredi 12 avril 2017, 06:08:55 CEST Stephen Connolly a écrit :

I think it was the use of nested name that contributed too:
origin/MNG-6169/updated-MCOMPILER

On Wed 12 Apr 2017 at 05:47, Karl Heinz Marbaise  wrote:

Hi Hervé,

On 12/04/17 04:35, Hervé BOUTEMY wrote:

I suppose this is tied to lots of intermittent failures on git clone


updates


that Jenkins has [1]
error: cannot lock ref 'refs/remotes/origin/MNG-6169/all-updated':
'refs/
remotes/origin/MNG-6169' exists; cannot create


'refs/remotes/origin/MNG-6169/


all-updated'

 ! [new branch]  MNG-6169/all-updated -> origin/MNG-6169/all-updated

(unable to update local ref)

This creation of branches in MNG-6169/ after having removed MNG-6169 has


bad


impact on every clone that does not correctly prune remote references: I
suppose the github cloning script has the same issue.

I see 2 options:
1. try to fix the github cloning script (I don't know where it is) and


any


other failing update (I'm fighting with Jenkins on this for a few days,


since


it seems it keeps copies every here and there...)
2. rename MNG-6169/* branches to something like MNG-6169_* to workaround


the


issue

Any other idea?


~/ws-git/apache/maven (master)$ git fetch --prune origin

 From https://git-wip-us.apache.org/repos/asf/maven

  x [deleted] (none) -> origin/MNG-6169/all-updated
  x [deleted] (none) ->

origin/MNG-6169/not-updated-MJAR-MCOMPILER

  x [deleted] (none) -> origin/MNG-6169/updated-MCOMPILER
  x [deleted] (none) -> origin/MNG-6169/updated-MJAR
  x [deleted] (none) -> origin/MNG-6185
  x [deleted] (none) -> origin/MNG-6198

remote: Counting objects: 93, done.
remote: Compressing objects: 100% (32/32), done.
remote: Total 47 (delta 16), reused 0 (delta 0)
Unpacking objects: 100% (47/47), done.

08f3c76..567af0d  master -> origin/master

  * [new branch]  MNG-6209_multiple-build-extensions ->

origin/MNG-6209_multiple-build-extensions

That helped me...

Kind regards
Karl Heinz


Regards,

Hervé

[1]


https://builds.apache.org/job/core-integration-testing-maven-3-jdk-1.8/100
7/console>

Le lundi 10 avril 2017, 22:42:47 CEST Mario Krizmanić a écrit :

Hi,



Could one check and update Github's mirror:

https://github.com/apache/maven


 (g...@github.com
:apache/maven.git)

The last commit in the master branch is 87cf1ee while the last one in


the


origin's master is 08f3c76a.

Thanks,
Mario


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

--


Sent from my phone




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






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

Re: Re[2]: Configurable Dependencies for Maven Plugins?

2017-04-12 Thread Dirk Mahler

Hi Stephen,

I need to declare the dependency to static directly, so I'm on the 
Sorry-Out-Of-Luck path...

But your suggestion makes me  thinking of providing an artifact myself (just 
pom packaging) in two different versions that pulls in the different 
dependencies and which can be overridden by the user. This should be possible 
then, right?

In that case I have to think about how to organize my own builds because I 
assume that within one reactor I won't be able to build two modules with same 
groupId and artifactId but different versions. 

Cheers,

Dirk

PS: Thanks for the 3.5.0 release, works like a charm for me!

Am Mittwoch 12. April 2017 schrieb Stephen Connolly:
> On Wed 12 Apr 2017 at 20:21, Dirk Mahler  wrote:
> 
> > Hi Bindul,
> >
> > sadly it's not that easy (or it's so easy that I don't see the
> > solution...). As a default and for compatibility reasons I'd like to
> > declare the dependencies of the Neo4j 2.x artifacts for my Maven plugin:
> >
> > - org.neo4j:neoj
> > - org.neo4j.app:neo4j-server
> > - org.neo4j.app:neo4j-server:static *
> 
> 
> Do you declare a direct dependency on static or a transitive one?
> 
> If direct, then yes you are Sorry-out-of-Luck
> 
> If transitive, then the  in the user's  will override
> the neo4j-server and you are sorted as the newer version will not pull in
> the static stuff
> 
> >
> >
> > For a user it would be possible to override only the first two
> > dependencies with the Neo4j 3.x versions: the third artifact (*) does
> > not exist for Neo4j 3.x (the Neo guys merged the static content into
> > neo4j-server.jar, i.e. into the main artifact without classifier). In
> > this case I would need to exclude "org.neo4j.app:neo4j-server:static"
> > which is still there as a 2.x artifact and pulls in some other deps that
> > are conflicting with the 3.x stuff. Any idea?
> >
> > Cheers,
> >
> > Dirk
> >
> > -- Originalnachricht --
> > Von: "Bindul Bhowmik" 
> > An: "Maven Developers List" ; "Dirk Mahler"
> > 
> > Gesendet: 12.04.2017 20:28:16
> > Betreff: Re: Configurable Dependencies for Maven Plugins?
> >
> > >Dirk,
> > >
> > >On Wed, Apr 12, 2017 at 7:06 AM, Dirk Mahler
> > > wrote:
> > >>  Hi all,
> > >>
> > >>  is there a way to provide users of a plugin a way of easily switching
> > >>  dependencies of it?
> > >>
> > >>  Background: I'm developing a Maven plugin (jQAssistant) that comes
> > >>with a
> > >>  dependency to Neo4j (graph database). Currently I'm using Neo4j 2.3.x
> > >>which
> > >>  has been compiled against Java 7 but I would like to offer users of
> > >>the
> > >>  Maven plugin an easy option to use the newer Neo4j 3.x releases which
> > >>offer
> > >>  some new features but require Java 8.
> > >>
> > >>  I know that it's possible to overwrite an existing dependency for a
> > >>plugin,
> > >>  e.g.
> > >>
> > >>  
> > >>com.buschmais.jqassistant
> > >>jqassistant-maven-plugin
> > >>1.3.0
> > >>
> > >>  
> > >>org.neo4j
> > >>neo4j
> > >>3.1.3 
> > >>  
> > >>
> > >>  
> > >
> > >As long as your code can handle the different versions of the
> > >dependency, I think this is absolutely doable. In fact the Maven
> > >Checkstyle Plugin uses the same approach to allow upgrading checkstyle
> > >versions without upgrading the plugin version [1].
> > >
> > >>
> > >>  The problem is that in my case the old version comes with another set
> > >>of
> > >>  dependencies than the new one:
> > >
> > >I do not think this will be a problem.
> > >
> > >>
> > >>  old:
> > >>
> > >>  
> > >>   
> > >>   org.neo4j
> > >>   neo4j
> > >>   2.3.10
> > >>   
> > >>   
> > >>   org.neo4j.app
> > >>   neo4j-server
> > >>   2.3.10
> > >>   
> > >>   
> > >>   org.neo4j.app
> > >>   neo4j-server
> > >>   static-web
> > >>   2.3.10
> > >>   
> > >>  
> > >>
> > >>  new:
> > >>
> > >>  
> > >>   
> > >>   org.neo4j
> > >>   neo4j
> > >>   3.1.3
> > >>   
> > >>   
> > >>   org.neo4j.app
> > >>   neo4j-server
> > >>   3.1.3
> > >>   
> > >>  
> > >>
> > >>  Is there a good way to deal with it such that a user of the
> > >>  jqassistant-maven-plugin can easily switch between both variants?
> > >>
> > >>  Cheers,
> > >>
> > >>  Dirk
> > >>
> > >>  Senior Consultant IT
> > >>  buschmais GbR
> > >
> > >
> > >- Bindul
> > >
> > >[1]
> > >
> > http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/upgrading-checkstyle.html
> > >
> > >>
> > >>  -
> > >>  Inhaber Torsten Busch, Frank Schwarz, Dirk Mahler, Tobias Israel
> > >>  Adresse buschmais GbR, Leipziger Straße 93, 01127 Dresden
> > >>  Telefon  +49 (0) 351 3209 23-0
> > >>  Fax  +49 (0) 351 3209 23-29
> > >>  Mobil+49 (0) 177 3137411
> > >>  E-Mail   dirk.mah...@buschmais.com
> > >>  Internet http://www.buschmais.de

Re: Re[2]: Configurable Dependencies for Maven Plugins?

2017-04-12 Thread Stephen Connolly

On Wed 12 Apr 2017 at 20:21, Dirk Mahler  wrote:

> Hi Bindul,
>
> sadly it's not that easy (or it's so easy that I don't see the
> solution...). As a default and for compatibility reasons I'd like to
> declare the dependencies of the Neo4j 2.x artifacts for my Maven plugin:
>
> - org.neo4j:neoj
> - org.neo4j.app:neo4j-server
> - org.neo4j.app:neo4j-server:static *


Do you declare a direct dependency on static or a transitive one?

If direct, then yes you are Sorry-out-of-Luck

If transitive, then the  in the user's  will override
the neo4j-server and you are sorted as the newer version will not pull in
the static stuff

>
>
> For a user it would be possible to override only the first two
> dependencies with the Neo4j 3.x versions: the third artifact (*) does
> not exist for Neo4j 3.x (the Neo guys merged the static content into
> neo4j-server.jar, i.e. into the main artifact without classifier). In
> this case I would need to exclude "org.neo4j.app:neo4j-server:static"
> which is still there as a 2.x artifact and pulls in some other deps that
> are conflicting with the 3.x stuff. Any idea?
>
> Cheers,
>
> Dirk
>
> -- Originalnachricht --
> Von: "Bindul Bhowmik" 
> An: "Maven Developers List" ; "Dirk Mahler"
> 
> Gesendet: 12.04.2017 20:28:16
> Betreff: Re: Configurable Dependencies for Maven Plugins?
>
> >Dirk,
> >
> >On Wed, Apr 12, 2017 at 7:06 AM, Dirk Mahler
> > wrote:
> >>  Hi all,
> >>
> >>  is there a way to provide users of a plugin a way of easily switching
> >>  dependencies of it?
> >>
> >>  Background: I'm developing a Maven plugin (jQAssistant) that comes
> >>with a
> >>  dependency to Neo4j (graph database). Currently I'm using Neo4j 2.3.x
> >>which
> >>  has been compiled against Java 7 but I would like to offer users of
> >>the
> >>  Maven plugin an easy option to use the newer Neo4j 3.x releases which
> >>offer
> >>  some new features but require Java 8.
> >>
> >>  I know that it's possible to overwrite an existing dependency for a
> >>plugin,
> >>  e.g.
> >>
> >>  
> >>com.buschmais.jqassistant
> >>jqassistant-maven-plugin
> >>1.3.0
> >>
> >>  
> >>org.neo4j
> >>neo4j
> >>3.1.3 
> >>  
> >>
> >>  
> >
> >As long as your code can handle the different versions of the
> >dependency, I think this is absolutely doable. In fact the Maven
> >Checkstyle Plugin uses the same approach to allow upgrading checkstyle
> >versions without upgrading the plugin version [1].
> >
> >>
> >>  The problem is that in my case the old version comes with another set
> >>of
> >>  dependencies than the new one:
> >
> >I do not think this will be a problem.
> >
> >>
> >>  old:
> >>
> >>  
> >>   
> >>   org.neo4j
> >>   neo4j
> >>   2.3.10
> >>   
> >>   
> >>   org.neo4j.app
> >>   neo4j-server
> >>   2.3.10
> >>   
> >>   
> >>   org.neo4j.app
> >>   neo4j-server
> >>   static-web
> >>   2.3.10
> >>   
> >>  
> >>
> >>  new:
> >>
> >>  
> >>   
> >>   org.neo4j
> >>   neo4j
> >>   3.1.3
> >>   
> >>   
> >>   org.neo4j.app
> >>   neo4j-server
> >>   3.1.3
> >>   
> >>  
> >>
> >>  Is there a good way to deal with it such that a user of the
> >>  jqassistant-maven-plugin can easily switch between both variants?
> >>
> >>  Cheers,
> >>
> >>  Dirk
> >>
> >>  Senior Consultant IT
> >>  buschmais GbR
> >
> >
> >- Bindul
> >
> >[1]
> >
> http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/upgrading-checkstyle.html
> >
> >>
> >>  -
> >>  Inhaber Torsten Busch, Frank Schwarz, Dirk Mahler, Tobias Israel
> >>  Adresse buschmais GbR, Leipziger Straße 93, 01127 Dresden
> >>  Telefon  +49 (0) 351 3209 23-0
> >>  Fax  +49 (0) 351 3209 23-29
> >>  Mobil+49 (0) 177 3137411
> >>  E-Mail   dirk.mah...@buschmais.com
> >>  Internet http://www.buschmais.de
> >>  -
> >>
> >>  Diese E-Mail enthält vertrauliche undoder rechtlich geschützte
> >>  Informationen. Wenn Sie diese E-Mail irrtümlich erhalten haben,
> >>  bitten wir Sie diese E-Mail umgehend zu löschen. Das unerlaubte
> >>  Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht
> >>  gestattet.
> >>
> >>  This e-mail may contain confidential or privileged information. If
> >>  you are not the intended recipient we kindly request you to delete
> >>  this e-mail immediately. Any unauthorized copying, disclosure or
> >>  distribution of the material in this e-mail is strictly forbidden.
> >>
> >>
> >
> >-
> >To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-un

Re[2]: Configurable Dependencies for Maven Plugins?

2017-04-12 Thread Dirk Mahler


Hi Bindul,

sadly it's not that easy (or it's so easy that I don't see the 
solution...). As a default and for compatibility reasons I'd like to 
declare the dependencies of the Neo4j 2.x artifacts for my Maven plugin:


- org.neo4j:neoj
- org.neo4j.app:neo4j-server
- org.neo4j.app:neo4j-server:static *

For a user it would be possible to override only the first two 
dependencies with the Neo4j 3.x versions: the third artifact (*) does 
not exist for Neo4j 3.x (the Neo guys merged the static content into 
neo4j-server.jar, i.e. into the main artifact without classifier). In 
this case I would need to exclude "org.neo4j.app:neo4j-server:static" 
which is still there as a 2.x artifact and pulls in some other deps that 
are conflicting with the 3.x stuff. Any idea?


Cheers,

Dirk

-- Originalnachricht --
Von: "Bindul Bhowmik" 
An: "Maven Developers List" ; "Dirk Mahler" 


Gesendet: 12.04.2017 20:28:16
Betreff: Re: Configurable Dependencies for Maven Plugins?


Dirk,

On Wed, Apr 12, 2017 at 7:06 AM, Dirk Mahler 
 wrote:

 Hi all,

 is there a way to provide users of a plugin a way of easily switching
 dependencies of it?

 Background: I'm developing a Maven plugin (jQAssistant) that comes 
with a
 dependency to Neo4j (graph database). Currently I'm using Neo4j 2.3.x 
which
 has been compiled against Java 7 but I would like to offer users of 
the
 Maven plugin an easy option to use the newer Neo4j 3.x releases which 
offer

 some new features but require Java 8.

 I know that it's possible to overwrite an existing dependency for a 
plugin,

 e.g.

 
   com.buschmais.jqassistant
   jqassistant-maven-plugin
   1.3.0
   
 
   org.neo4j
   neo4j
   3.1.3 
 
   
 


As long as your code can handle the different versions of the
dependency, I think this is absolutely doable. In fact the Maven
Checkstyle Plugin uses the same approach to allow upgrading checkstyle
versions without upgrading the plugin version [1].



 The problem is that in my case the old version comes with another set 
of

 dependencies than the new one:


I do not think this will be a problem.



 old:

 
  
  org.neo4j
  neo4j
  2.3.10
  
  
  org.neo4j.app
  neo4j-server
  2.3.10
  
  
  org.neo4j.app
  neo4j-server
  static-web
  2.3.10
  
 

 new:

 
  
  org.neo4j
  neo4j
  3.1.3
  
  
  org.neo4j.app
  neo4j-server
  3.1.3
  
 

 Is there a good way to deal with it such that a user of the
 jqassistant-maven-plugin can easily switch between both variants?

 Cheers,

 Dirk

 Senior Consultant IT
 buschmais GbR



- Bindul

[1] 
http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/upgrading-checkstyle.html




 -
 Inhaber Torsten Busch, Frank Schwarz, Dirk Mahler, Tobias Israel
 Adresse buschmais GbR, Leipziger Straße 93, 01127 Dresden
 Telefon  +49 (0) 351 3209 23-0
 Fax  +49 (0) 351 3209 23-29
 Mobil+49 (0) 177 3137411
 E-Mail   dirk.mah...@buschmais.com
 Internet http://www.buschmais.de
 -

 Diese E-Mail enthält vertrauliche undoder rechtlich geschützte
 Informationen. Wenn Sie diese E-Mail irrtümlich erhalten haben,
 bitten wir Sie diese E-Mail umgehend zu löschen. Das unerlaubte
 Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht
 gestattet.

 This e-mail may contain confidential or privileged information. If
 you are not the intended recipient we kindly request you to delete
 this e-mail immediately. Any unauthorized copying, disclosure or
 distribution of the material in this e-mail is strictly forbidden.




-
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: Configurable Dependencies for Maven Plugins?

2017-04-12 Thread Bindul Bhowmik

Dirk,

On Wed, Apr 12, 2017 at 7:06 AM, Dirk Mahler  wrote:
> Hi all,
>
> is there a way to provide users of a plugin a way of easily switching
> dependencies of it?
>
> Background: I'm developing a Maven plugin (jQAssistant) that comes with a
> dependency to Neo4j (graph database). Currently I'm using Neo4j 2.3.x which
> has been compiled against Java 7 but I would like to offer users of the
> Maven plugin an easy option to use the newer Neo4j 3.x releases which offer
> some new features but require Java 8.
>
> I know that it's possible to overwrite an existing dependency for a plugin,
> e.g.
>
> 
>   com.buschmais.jqassistant
>   jqassistant-maven-plugin
>   1.3.0
>   
> 
>   org.neo4j
>   neo4j
>   3.1.3 
> 
>   
> 

As long as your code can handle the different versions of the
dependency, I think this is absolutely doable. In fact the Maven
Checkstyle Plugin uses the same approach to allow upgrading checkstyle
versions without upgrading the plugin version [1].

>
> The problem is that in my case the old version comes with another set of
> dependencies than the new one:

I do not think this will be a problem.

>
> old:
>
> 
>  
>  org.neo4j
>  neo4j
>  2.3.10
>  
>  
>  org.neo4j.app
>  neo4j-server
>  2.3.10
>  
>  
>  org.neo4j.app
>  neo4j-server
>  static-web
>  2.3.10
>  
> 
>
> new:
>
> 
>  
>  org.neo4j
>  neo4j
>  3.1.3
>  
>  
>  org.neo4j.app
>  neo4j-server
>  3.1.3
>  
> 
>
> Is there a good way to deal with it such that a user of the
> jqassistant-maven-plugin can easily switch between both variants?
>
> Cheers,
>
> Dirk
>
> Senior Consultant IT
> buschmais GbR


- Bindul

[1] 
http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/upgrading-checkstyle.html

>
> -
> Inhaber Torsten Busch, Frank Schwarz, Dirk Mahler, Tobias Israel
> Adresse buschmais GbR, Leipziger Straße 93, 01127 Dresden
> Telefon  +49 (0) 351 3209 23-0
> Fax  +49 (0) 351 3209 23-29
> Mobil+49 (0) 177 3137411
> E-Mail   dirk.mah...@buschmais.com
> Internet http://www.buschmais.de
> -
>
> Diese E-Mail enthält vertrauliche undoder rechtlich geschützte
> Informationen. Wenn Sie diese E-Mail irrtümlich erhalten haben,
> bitten wir Sie diese E-Mail umgehend zu löschen. Das unerlaubte
> Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht
> gestattet.
>
> This e-mail may contain confidential or privileged information. If
> you are not the intended recipient we kindly request you to delete
> this e-mail immediately. Any unauthorized copying, disclosure or
> distribution of the material in this e-mail is strictly forbidden.
>
>

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

[GitHub] maven pull request #113: [MNG-6127] Fix plugin execution configuration inter...

2017-04-12 Thread mkrizmanic

GitHub user mkrizmanic opened a pull request:

https://github.com/apache/maven/pull/113

[MNG-6127] Fix plugin execution configuration interference

PR for maven-integration-testing: 
https://github.com/apache/maven-integration-testing/pull/21

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

$ git pull https://github.com/mkrizmanic/maven MNG-6127

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

https://github.com/apache/maven/pull/113.patch

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

This closes #113


commit a7c17b6ef0d75e49a34e207dd68a81fe20e6b172
Author: Mario Krizmanic 
Date:   2017-04-10T19:06:12Z

[MNG-6127] Fix plugin execution configuration interference




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

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

[GitHub] maven-integration-testing pull request #21: [MNG-6127] Add plugin execution ...

2017-04-12 Thread mkrizmanic

GitHub user mkrizmanic opened a pull request:

https://github.com/apache/maven-integration-testing/pull/21

[MNG-6127] Add plugin execution configuration interference test



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

$ git pull https://github.com/mkrizmanic/maven-integration-testing MNG-6127

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

https://github.com/apache/maven-integration-testing/pull/21.patch

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

This closes #21


commit 33b3681c7ed55481cdfd0f7c8ec61781f979babd
Author: Mario Krizmanic 
Date:   2016-11-23T21:25:34Z

[MNG-6127] Add plugin execution configuration interference test




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

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

Re: Building a Java9 project just using JDK9

2017-04-12 Thread Robert Scholte


Yes, I think that makes sense. Will do so.

Robert

On Wed, 12 Apr 2017 03:15:41 +0200, Hervé BOUTEMY   
wrote:



Robert,

Should this war plugin be added to the Java 9 - Jigsaw Wiki page in the
plugins section?
https://cwiki.apache.org/confluence/display/MAVEN/Java+9+-+Jigsaw

Regards,

Hervé

Le mardi 11 avril 2017, 10:14:12 CEST Enrico Olivelli a écrit :

Thank you all for your quick answers

@Robert
I have checked out the code and took a deeper look:
the implementation of MWAR-397 is complex and will take some time, on  
the

mid term I agree that it will an awesome solution
https://issues.apache.org/jira/browse/MWAR-397

@Jörg
The option --permit-illegal-access will not work for me as it will hide
most of the problems of Java9 fo

I would like to propose a simpler patch which prevents the  
maven-war-plugin

from crashing at clinit
https://github.com/apache/maven-plugins/pull/112

this will make it work just by disabling the cache
I see it is a very temporary fix but lets everyone go on with Java9  
Webapps


If the idea is good a can file a JIRA, clean up the code respecting the
conventions or the project and file a clean PR

Another fallback would be to use the Kryo library, which let's you
serialize non-serializable objects, but I have not tests

2017-04-10 22:46 GMT+02:00 Jörg Schaible :
> Enrico Olivelli wrote:
> > Il lun 10 apr 2017, 18:57 Karl Heinz Marbaise  ha
> >
> > scritto:
> >> Hi,
> >>
> >> On 10/04/17 17:37, Enrico Olivelli wrote:
> >> > Hi,
> >> > I would like be able to build an existing project developed for  
java8

> >> > by simple running Maven on jdk9.
> >> >
> >> > Actually it is not possible, I am aware of that and I am  
currently

> >> > following all the news about Maven and Java9
> >>
> >> What is not possible ? Do you have an error message / log file  
etc. ?

> >
> > Actually I am blocked on the TreeMap issue with xstream and
> > maven-war-plugin.
> > Is there any active work on that issue?
> >
> >  I see it is marked as an external dep problem but on xstream issue
> >  tracker
> >
> > it seems that it is not a priority
>
> You should be able to run it with  
MAVEN_OPTS="--permit-illegal-access" -

> at
> least until a solution is available.
>
> Cheers,
> Jörg
>
>
> -
> 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

Configurable Dependencies for Maven Plugins?

2017-04-12 Thread Dirk Mahler


Hi all,

is there a way to provide users of a plugin a way of easily switching 
dependencies of it?


Background: I'm developing a Maven plugin (jQAssistant) that comes with 
a dependency to Neo4j (graph database). Currently I'm using Neo4j 2.3.x 
which has been compiled against Java 7 but I would like to offer users 
of the Maven plugin an easy option to use the newer Neo4j 3.x releases 
which offer some new features but require Java 8.


I know that it's possible to overwrite an existing dependency for a 
plugin, e.g.



  com.buschmais.jqassistant
  jqassistant-maven-plugin
  1.3.0
  

  org.neo4j
  neo4j
  3.1.3 

  


The problem is that in my case the old version comes with another set of 
dependencies than the new one:


old:


 
 org.neo4j
 neo4j
 2.3.10
 
 
 org.neo4j.app
 neo4j-server
 2.3.10
 
 
 org.neo4j.app
 neo4j-server
 static-web
 2.3.10
 


new:


 
 org.neo4j
 neo4j
 3.1.3
 
 
 org.neo4j.app
 neo4j-server
 3.1.3
 


Is there a good way to deal with it such that a user of the 
jqassistant-maven-plugin can easily switch between both variants?


Cheers,

Dirk

Senior Consultant IT
buschmais GbR

-
Inhaber Torsten Busch, Frank Schwarz, Dirk Mahler, Tobias Israel
Adresse buschmais GbR, Leipziger Straße 93, 01127 Dresden
Telefon  +49 (0) 351 3209 23-0
Fax  +49 (0) 351 3209 23-29
Mobil+49 (0) 177 3137411
E-Mail   dirk.mah...@buschmais.com
Internet http://www.buschmais.de
-

Diese E-Mail enthält vertrauliche undoder rechtlich geschützte
Informationen. Wenn Sie diese E-Mail irrtümlich erhalten haben,
bitten wir Sie diese E-Mail umgehend zu löschen. Das unerlaubte
Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht
gestattet.

This e-mail may contain confidential or privileged information. If
you are not the intended recipient we kindly request you to delete
this e-mail immediately. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.

Re: Github mirror broken

2017-04-12 Thread Stephen Connolly

I think the issue was changing from MNG-6169 to MNG-6169/something and then
back again

using names with a slash in them *should* be fine... reusing the part
before the slash can cause issues during the same sync

On 12 April 2017 at 07:54, Hervé BOUTEMY  wrote:

> yes, that's what I tried to say (there were 4 branches iin MNG-6169/)
>
> I finally renamed the 4 branches and replaced / with _: now there won't be
> any
> stupid failure on Jenkins, and I just checeked that the github mirror is
> up to
> date also
>
> issue fixed
> and not to the team: warning about / use in branch names, that may not be
> such
> a good idea
>
> Regards,
>
> Hervé
>
> Le mercredi 12 avril 2017, 06:08:55 CEST Stephen Connolly a écrit :
> > I think it was the use of nested name that contributed too:
> > origin/MNG-6169/updated-MCOMPILER
> >
> > On Wed 12 Apr 2017 at 05:47, Karl Heinz Marbaise 
> wrote:
> > > Hi Hervé,
> > >
> > > On 12/04/17 04:35, Hervé BOUTEMY wrote:
> > > > I suppose this is tied to lots of intermittent failures on git clone
> > >
> > > updates
> > >
> > > > that Jenkins has [1]
> > > > error: cannot lock ref 'refs/remotes/origin/MNG-6169/all-updated':
> > > > 'refs/
> > > > remotes/origin/MNG-6169' exists; cannot create
> > >
> > > 'refs/remotes/origin/MNG-6169/
> > >
> > > > all-updated'
> > > >
> > > >  ! [new branch]  MNG-6169/all-updated ->
> origin/MNG-6169/all-updated
> > > >
> > > > (unable to update local ref)
> > > >
> > > > This creation of branches in MNG-6169/ after having removed MNG-6169
> has
> > >
> > > bad
> > >
> > > > impact on every clone that does not correctly prune remote
> references: I
> > > > suppose the github cloning script has the same issue.
> > > >
> > > > I see 2 options:
> > > > 1. try to fix the github cloning script (I don't know where it is)
> and
> > >
> > > any
> > >
> > > > other failing update (I'm fighting with Jenkins on this for a few
> days,
> > >
> > > since
> > >
> > > > it seems it keeps copies every here and there...)
> > > > 2. rename MNG-6169/* branches to something like MNG-6169_* to
> workaround
> > >
> > > the
> > >
> > > > issue
> > > >
> > > > Any other idea?
> > >
> > > ~/ws-git/apache/maven (master)$ git fetch --prune origin
> > >
> > >  From https://git-wip-us.apache.org/repos/asf/maven
> > >
> > >   x [deleted] (none) -> origin/MNG-6169/all-updated
> > >   x [deleted] (none) ->
> > >
> > > origin/MNG-6169/not-updated-MJAR-MCOMPILER
> > >
> > >   x [deleted] (none) -> origin/MNG-6169/updated-MCOMPILER
> > >   x [deleted] (none) -> origin/MNG-6169/updated-MJAR
> > >   x [deleted] (none) -> origin/MNG-6185
> > >   x [deleted] (none) -> origin/MNG-6198
> > >
> > > remote: Counting objects: 93, done.
> > > remote: Compressing objects: 100% (32/32), done.
> > > remote: Total 47 (delta 16), reused 0 (delta 0)
> > > Unpacking objects: 100% (47/47), done.
> > >
> > > 08f3c76..567af0d  master -> origin/master
> > >
> > >   * [new branch]  MNG-6209_multiple-build-extensions ->
> > >
> > > origin/MNG-6209_multiple-build-extensions
> > >
> > > That helped me...
> > >
> > > Kind regards
> > > Karl Heinz
> > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > [1]
> > >
> > > https://builds.apache.org/job/core-integration-testing-
> maven-3-jdk-1.8/100
> > > 7/console>
> > > > Le lundi 10 avril 2017, 22:42:47 CEST Mario Krizmanić a écrit :
> > > >> Hi,
> > >
> > > >> Could one check and update Github's mirror:
> > > https://github.com/apache/maven
> > >
> > > >>  (g...@github.com
> > > >> :apache/maven.git)
> > > >>
> > > >> The last commit in the master branch is 87cf1ee while the last one
> in
> > >
> > > the
> > >
> > > >> origin's master is 08f3c76a.
> > > >>
> > > >> Thanks,
> > > >> Mario
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > > --
> >
> > Sent from my phone
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Building a Java9 project just using JDK9

2017-04-12 Thread Enrico Olivelli

I have created the JIRA to better track my proposal

https://issues.apache.org/jira/browse/MWAR-405


2017-04-12 3:15 GMT+02:00 Hervé BOUTEMY :

> Robert,
>
> Should this war plugin be added to the Java 9 - Jigsaw Wiki page in the
> plugins section?
> https://cwiki.apache.org/confluence/display/MAVEN/Java+9+-+Jigsaw
>
> Regards,
>
> Hervé
>
> Le mardi 11 avril 2017, 10:14:12 CEST Enrico Olivelli a écrit :
> > Thank you all for your quick answers
> >
> > @Robert
> > I have checked out the code and took a deeper look:
> > the implementation of MWAR-397 is complex and will take some time, on the
> > mid term I agree that it will an awesome solution
> > https://issues.apache.org/jira/browse/MWAR-397
> >
> > @Jörg
> > The option --permit-illegal-access will not work for me as it will hide
> > most of the problems of Java9 fo
> >
> > I would like to propose a simpler patch which prevents the
> maven-war-plugin
> > from crashing at clinit
> > https://github.com/apache/maven-plugins/pull/112
> >
> > this will make it work just by disabling the cache
> > I see it is a very temporary fix but lets everyone go on with Java9
> Webapps
> >
> > If the idea is good a can file a JIRA, clean up the code respecting the
> > conventions or the project and file a clean PR
> >
> > Another fallback would be to use the Kryo library, which let's you
> > serialize non-serializable objects, but I have not tests
> >
> > 2017-04-10 22:46 GMT+02:00 Jörg Schaible :
> > > Enrico Olivelli wrote:
> > > > Il lun 10 apr 2017, 18:57 Karl Heinz Marbaise  ha
> > > >
> > > > scritto:
> > > >> Hi,
> > > >>
> > > >> On 10/04/17 17:37, Enrico Olivelli wrote:
> > > >> > Hi,
> > > >> > I would like be able to build an existing project developed for
> java8
> > > >> > by simple running Maven on jdk9.
> > > >> >
> > > >> > Actually it is not possible, I am aware of that and I am currently
> > > >> > following all the news about Maven and Java9
> > > >>
> > > >> What is not possible ? Do you have an error message / log file etc.
> ?
> > > >
> > > > Actually I am blocked on the TreeMap issue with xstream and
> > > > maven-war-plugin.
> > > > Is there any active work on that issue?
> > > >
> > > >  I see it is marked as an external dep problem but on xstream issue
> > > >  tracker
> > > >
> > > > it seems that it is not a priority
> > >
> > > You should be able to run it with MAVEN_OPTS="--permit-illegal-access"
> -
> > > at
> > > least until a solution is available.
> > >
> > > Cheers,
> > > Jörg
> > >
> > >
> > > -
> > > 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
>
>

[GitHub] maven-plugins pull request #112: MWAR-405 Workaround XStream incompatibility...

2017-04-12 Thread eolivelli

Github user eolivelli closed the pull request at:

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


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

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

[GitHub] maven-plugins pull request #112: MWAR-405 Workaround XStream incompatibility...

2017-04-12 Thread eolivelli

GitHub user eolivelli reopened a pull request:

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

MWAR-405  Workaround XStream incompatibility with Java9

This is a proof-of-concept implementation of a possible way to word-around 
the actual incompatibility of xstreams default converters with java9.
As the maven-war-plugin does not need all of the converters (like 
TreeMapConverter which is the primary cause of the issue) we can just register 
only the needed ones and bypass the java9 issue

see

Caused by: java.lang.reflect.InaccessibleObjectException: Unable to 
make field private final java.util.Comparator java.util.TreeMap.comparator 
accessible: module java.base does not "opens java.util" to unnamed module
Happens while initializing 
org.apache.maven.plugins.war.util.WebappStructureSerializer

at
https://cwiki.apache.org/confluence/display/MAVEN/Java+9+-+Jigsaw

this PR is just a proof-of-concept, there is an email thread on the dev 
list. If the idea is accepted I will submit a JIRA and official PR (some code 
cleanup is needed at least)

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

$ git pull https://github.com/eolivelli/maven-plugins 
maven-war-plugin-easy-fix

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

https://github.com/apache/maven-plugins/pull/112.patch

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

This closes #112


commit d26db922d07425eb74d0cf1b42c1234f6953cd96
Author: eolivelli 
Date:   2017-04-11T08:07:36Z

Load only useful XStream converters




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

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

Re: Check if parameter is explicitly set

Fwd: [VOTE] Apache Mahout 0.13.0 Release Candidate

[ANN] Apache Maven Surefire Plugin 2.20 Released

[GitHub] maven-plugins pull request #112: MWAR-405 Workaround XStream incompatibility...

[GitHub] maven-plugins pull request #112: MWAR-405 Workaround XStream incompatibility...

Re: Check if parameter is explicitly set

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

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

Check if parameter is explicitly set

Re: Github mirror broken

Re: Re[2]: Configurable Dependencies for Maven Plugins?

Re: Re[2]: Configurable Dependencies for Maven Plugins?

Re: Github mirror broken

Re: Re[2]: Configurable Dependencies for Maven Plugins?

Re: Re[2]: Configurable Dependencies for Maven Plugins?

Re[2]: Configurable Dependencies for Maven Plugins?

Re: Configurable Dependencies for Maven Plugins?

[GitHub] maven pull request #113: [MNG-6127] Fix plugin execution configuration inter...

[GitHub] maven-integration-testing pull request #21: [MNG-6127] Add plugin execution ...

Re: Building a Java9 project just using JDK9

Configurable Dependencies for Maven Plugins?

Re: Github mirror broken

Re: Building a Java9 project just using JDK9

[GitHub] maven-plugins pull request #112: MWAR-405 Workaround XStream incompatibility...

[GitHub] maven-plugins pull request #112: MWAR-405 Workaround XStream incompatibility...

25 matches

Site Navigation

Mail list logo

Footer information