Re: Maven Doxia and minimum Java versions

[Chas Honton]

Answering my own question; it appears that you can use the animal sniffer 
plugin 
(https://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/examples/generating-java-signatures.html)

Chas

> On May 16, 2018, at 7:21 AM, Chas Honton <c...@honton.org> wrote:
> 
> Use “enforce byte code version” rule: 
> http://www.mojohaus.org/extra-enforcer-rules/enforceBytecodeVersion.html. You 
> can set ignoreScopes to test. 
> 
> Anyone know how to validate newer jdk methods are not used?
> 
> Chas
> 
>>> On May 16, 2018, at 7:08 AM, Graham Leggett <minf...@sharp.fm> wrote:
>>> 
>>> On 15 May 2018, at 11:08 PM, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
>>> 
>>> I'm maintaining Doxia and maven-site-plugin for a long time, trying to keep 
>>> the prerequisites (for end users particularly) as low as possible when I 
>>> don't 
>>> have a strong win on upgrading.
>> 
>> +1 - my feeling too.
>> 
>>> Currently, maven-site-plugin (which is what users see, without knowing much 
>>> about Doxia) requires Java 6 only.
>>> With Doxia 1.8 / maven-site-plugin 3.7, in fact, there is a little trick: 
>>> one 
>>> Doxia module (Markdown) requires Java 7, because of the library used, and I 
>>> documented how one can downgrade this module if he strictly require to use 
>>> maven-site-plugin 3.7 with Java 6.
>>> But for sure, when building maven-site-plugin, I didn't try to add a 
>>> profile 
>>> to be able to build with Java 6: Java 7 is required to build maven-site-
>>> plugin.
>>> 
>>> Honestly, for Java 6, maven-site-plugin 3.7 is the last version: now it's 
>>> time 
>>> to drop it and require Java 7 if you want newer version of the plugin.
>>> 
>>> Then I'm full ok to upgrade Doxia requirement for Doxia 1.9 and maven-site-
>>> plugin 3.8 to Java 7.
>>> 
>>> 
>>> On httpunit, AFAIK it's only for Doxia tests during its build: I don't have 
>>> any issue with building Doxia with Java 8 to produce jar that require Java 
>>> 7 
>>> only.
>> 
>> How I tripped over this was the enforcer plugin - enforcer found Java 8 code 
>> being brought in by httpunit and said “no”.
>> 
>> Not knowing a lot about the enforcer plugin, is there a way to build the 
>> primary artifacts at compliance level v1.6, but build and run the tests at 
>> v1.8?
>> 
>> Regards,
>> Graham
>> —
>> 

Re: Maven Doxia and minimum Java versions

[Chas Honton]

Use “enforce byte code version” rule: 
http://www.mojohaus.org/extra-enforcer-rules/enforceBytecodeVersion.html. You 
can set ignoreScopes to test. 

Anyone know how to validate newer jdk methods are not used?

Chas

> On May 16, 2018, at 7:08 AM, Graham Leggett  wrote:
> 
>> On 15 May 2018, at 11:08 PM, Hervé BOUTEMY  wrote:
>> 
>> I'm maintaining Doxia and maven-site-plugin for a long time, trying to keep 
>> the prerequisites (for end users particularly) as low as possible when I 
>> don't 
>> have a strong win on upgrading.
> 
> +1 - my feeling too.
> 
>> Currently, maven-site-plugin (which is what users see, without knowing much 
>> about Doxia) requires Java 6 only.
>> With Doxia 1.8 / maven-site-plugin 3.7, in fact, there is a little trick: 
>> one 
>> Doxia module (Markdown) requires Java 7, because of the library used, and I 
>> documented how one can downgrade this module if he strictly require to use 
>> maven-site-plugin 3.7 with Java 6.
>> But for sure, when building maven-site-plugin, I didn't try to add a profile 
>> to be able to build with Java 6: Java 7 is required to build maven-site-
>> plugin.
>> 
>> Honestly, for Java 6, maven-site-plugin 3.7 is the last version: now it's 
>> time 
>> to drop it and require Java 7 if you want newer version of the plugin.
>> 
>> Then I'm full ok to upgrade Doxia requirement for Doxia 1.9 and maven-site-
>> plugin 3.8 to Java 7.
>> 
>> 
>> On httpunit, AFAIK it's only for Doxia tests during its build: I don't have 
>> any issue with building Doxia with Java 8 to produce jar that require Java 7 
>> only.
> 
> How I tripped over this was the enforcer plugin - enforcer found Java 8 code 
> being brought in by httpunit and said “no”.
> 
> Not knowing a lot about the enforcer plugin, is there a way to build the 
> primary artifacts at compliance level v1.6, but build and run the tests at 
> v1.8?
> 
> Regards,
> Graham
> —
> 

Re: Build vs Consumer POM study

[Chas Honton]

Re: updating source plugin -

For Apache projects, all sources required to build and test the release must be 
part of the distribution. It would be useful to any Apache project that desires 
to build a release through the source plugin to have the build pom 
automatically packaged. 

For non-Apache projects it would be useful to encourage packaging all sources 
sufficient to build and test the release. 

Re: impacting dependency version resolution -
When multiple version are defined for the same artifact in the dependency tree, 
the nearest definition determines the version. I can imagine scenarios where 
flattening the consumer pom will change which definition is nearest, and 
therefore the version may change.  This is a corner case, but should be 
mentioned. 


Chas

> On Mar 12, 2018, at 4:13 PM, Hervé BOUTEMY  wrote:
> 
> Hi Charles,
> 
> Thanks for the feedback
> 
> Le lundi 12 mars 2018, 01:49:26 CET Charles Honton a écrit :
>> Hervé,
>> 
>> Great work!
> Thank you: it took a lot of time and discussion :)
> 
>> Some possible additions for the wiki page:
>> 
>> Naming Conventions
>> consumer pom must continue to be named pom.xml
>> build pom shall be called build.xml
>> alternate build inputs could be build.json or build.yaml
> ok, makes sense, I reworked it and added to the proposal
> 
>> 
>> EcoSystem Impacts
>> projects distributing source code through maven central should include the
>> build pom. This requires updating maven source plugin.
> why? do people building with Ant publish their build.xml?
> 
>> flattened consumer
>> pom will impact version resolution;
> no, the intent is that it does absolutely not change anything at that level: 
> that's the whole idea, for compatibility
> 
>> what was a deep dependency will be
>> brought to second level how will IDEs be affected?
> ??
> 
> Regards,
> 
> Hervé
> 
>> 
>>> On Mar 11, 2018, at 10:03 AM, Hervé BOUTEMY  wrote:
>>> 
>>> Hi,
>>> 
>>> I wrote a Proposal in the Wiki about Build vs Consumer POM [1] and coded a
>>> simplified model for the Consumer POM [2]
>>> As written in the proposal, this would permit us to create new POM
>>> versions
>>> that change everything but not the Consumer POM part without breaking any
>>> compatibility with existing Central repository users: build element is the
>>> main element that could be changed, adding new build
>>> features/configuration
>>> without affecting consumers.
>>> 
>>> In addition to reviewing choices proposed for majority of POM elements,
>>> there are 4 elements that require more discussion:
>>> - contributors
>>> - mailingLists
>>> - repositories
>>> - profiles/activation
>>> 
>>> Any thoughts?
>>> 
>>> On the code, IMHO, the only missing part is a test of flatten-maven-plugin
>>> to check that everything works as expected in any situation.
>>> And I suppose a discussion on what we do for the xsd
>>> 
>>> Then we should be able to use this strategy for our own artifacts, before
>>> updating POM model version in any newer Maven version starting with 3.6
>>> (yay!)
>>> 
>>> Regards,
>>> 
>>> Hervé
>>> 
>>> 
>>> [1]
>>> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
>>> 
>>> [2] http://maven.apache.org/studies/consumer-pom/maven-consumer.html
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 

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

Re: RFC: Maven to raise a notification if downloading vulnerable content

[Chas Honton]

If you want the package repository to add the header, you will need to make 
your request to Sonatype (Nexus) and JFrog (Artifactory)

Chas

> On Mar 6, 2018, at 4:12 AM, Peter Muryshkin  wrote:
> 
> Hi, all,
> 
> currently you can run OWASP dependency check plugin against your projects.
> 
> Though, this seems to make security more or less optional: unaware either
> lightheaded teams could miss this.
> 
> What if a package repository would integrate with this dependency checking
> and issue a warning, say a special HTTP response code or a header?
> 
> Then, Maven would raise the warning in the console log, like "this
> component is known to have CVE-XYZ! consider upgrading"
> 
> What do you think?

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

Gitbox pull requests

[Chas Honton]

Pull requests for new project are not sent to the dev mailing list (e.g. 
https://github.com/apache/maven-deploy-plugin/pull/1). Are these PRs supposed 
to be forwarded to some mailing list?  Are these PRs supposed to be 
automatically built?

Thanks,
Chas

Re: Jenkins and Maven 3.0.5 or JDK 7

[Chas Honton]

Is it usual to need all dozen repositories or is a single repository (or a 
handful) more likely?

Chas

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

Re: Jenkins and Maven 3.0.5 or JDK 7

[Chas Honton]

What are the concerns with separate git repository per artifact?  Is it the 
monolithic build?

Chas

> On Oct 7, 2017, at 1:20 PM, Arnaud Héritier  wrote:
> 
> +1
> 
>> On Sat, Oct 7, 2017 at 7:11 PM, Hervé BOUTEMY  wrote:
>> 
>> we can start with naming the future git repos: I suppose adding a table at
>> the
>> end of the Git migration Wiki page can give a good view of the result
>> (with 78
>> new repos + existing 7 repos + the 6 in migration if nobody objects = 91
>> repos)
>> 
>> once we're all convinced of the target, we'll see how to work with infra
>> and I suppose they already have the right authors list, given the current
>> mirrors already published
>> 
>> Regards,
>> 
>> Hervé
>> 
>> Le samedi 7 octobre 2017, 16:05:45 CEST Tibor Digana a écrit :
>>> Herve,
>>> 
>>> I think, first of all, we should write a list with exact names of git
>>> repositories for which INFRA will crate them in
>>> git1-us-west.apache.org/repos/asf
>>> and mirror in github.com/apache
>>> 
>>> And then the authors.txt.
>>> 
>>> In my case I did not migrate tags and branches which is my problem given
>> in
>>> my example with previous e-mail.
>>> 
>>> On Sat, Oct 7, 2017 at 3:48 PM, Tibor Digana 
>> wrote:
 Herve,
 I think making the tag as I wanted would not be possible in git.
 
 Let's make it with all 78 projects.
 In 2016 I migrated my svn project "audit" located in sub-folder behind
 trunk (trunk/libs/audit) to git which is exactly what we need to do in
 ASF.
 
 In our case the commands would be 99% the same. The 1% is the source
>> SVN
 URL and target GitHub URL. That's all. Then if we provide INFRA with
>> bunch
 of commands like these then they will only execute them with their
 permissions.
 I do not think they will give me admin permissions to make it.
 
 git svn clone --no-metadata --authors-file=E:\*authors.txt* http://
 ***/svn/***/*trunk/libs/audit audit*
 git config --global user.name "*** ***"
 git config --global user.email "***@***.***"
 git remote add origin https://***@github.com/apache/
>> *maven-clean-plugin*
 .git
 git push -u origin --all
 
 I observed the *authors.txt* from command
 *svn log -q*
 Each person from between first two pipes, e.g.:
 r1234567 | tibordigana | 2015-10-19 02:20:00
 
 Every developer added e-mail and full name, i.e.:
 tibordigana = Tibor Digana 
 etc.
 
 This list of users which should be created in prior to contact INFRA.
 Not all users are active after years but it would be nice to include
>> them
 too.
 This list of users is one thing which cannot be automated!
 
 
 
 
 On Sat, Oct 7, 2017 at 2:48 PM, Tibor Digana 
 
 wrote:
> In my company I have such situation in SVN. Making a tag from
>> subfolder.
> Git always makes the tag from the root, right?
> Let's google something...
> 
> On Sat, Oct 7, 2017 at 2:47 PM, Tibor Digana <
>> tibor.dig...@googlemail.com
> 
>> wrote:
>> In my company I have such situation.
>> Making a tag from subfolder.
>> Git always makes the tag from the root, right?
>> Let's google something...
>> 
>> On Sat, Oct 7, 2017 at 2:05 PM, Hervé BOUTEMY >> 
>> 
>> wrote:
>>> thanks for your interest and feedback
>>> 
>>> Le samedi 7 octobre 2017, 12:00:32 CEST Tibor Digana a écrit :
 78 is too much.
>>> 
>>> notice that there would also be a question on the git repos naming
>>> convention,
>>> to avoid flat 78 names but keep at least 3 meaningful groups
>> (plugins,
>>> shared,
>>> resources: I think this is not absolutely necessary for doxia-tools)
>>> 
 There is no problem to trigger release over sub-folders and tag it
>>> 
>>> with
>>> 
 prefix which is already done in SVN.
>>> 
>>> is it supported by maven-release plugin with git?
>>> 
>>> notice I did not know that git was able to tag only a subtree: but I
>>> knew I
>>> don't yet understand every aspect of git magic... :)
>>> 
 The CI build can always trigger the root and Jenkinsfile would
>> have
 41
 stages for plugins, 26 stages for Shared, etc.
 It can be done in Jenkinsfile and so the shell would not throw
>>> 
>>> exception
>>> 
 but status would be set instead and goes to the next stage.
 I do not know how to detect in GitSCM which sub-folder(s) received
>>> 
>>> but I
>>> 
 guess this can be investigated.
>>> 
>>> +1
>>> but I don't know where to look for myself: on that point, I hope to
>>> have some
>>> help from Jenkinsfile experts
>>> and eventually start with svn, to have something before the git
>>> migration

Re: main-class + module-version

[Chas Honton]

Jar plugin is used more often than shade plugin.  (I dis-recommend shade since 
provenance of classes is difficult or impossible to trace.). If module version 
is required to make jar useful, then jar plugin appears more appropriate. 
Chas

> On Aug 22, 2017, at 6:10 PM, Olivier Lamy  wrote:
> 
> +1 for shade plugin looks to be the most appropriate location to do this.
> 
>> On 23 August 2017 at 06:03, Robert Scholte  wrote:
>> 
>> On Tue, 22 Aug 2017 21:23:10 +0200, Plamen Totev <
>> plamen.iv.to...@gmail.com> wrote:
>> 
>> Hi,
>>> 
>>> I've experimented with Maven and Java 9 the last weekend and actually one
>>> of the things I noticed is that currently I could not set the module
>>> version.
>>> 
>>> I do agree that the packaging should be stupid action and the module-info
>>> transformation should happen before that. But I'm not sure why the Maven
>>> Shade plug-in is the place to do that. Probably I'm missing something,
>>> would you explain a bit?
>> 
>> The maven-shade-plugin has the ability to re-package a jar and manipulate
>> any type of file, including class files. The best example is relocation,
>> where you give a set of classes a different package to prevent potential
>> class collisions when the original dependency (probably with other version)
>> is added again.
>> So this is a good match for the module-info.class adjustments.
>> 
>> 
>> 
>>> Or should these extra (basic?) features require an extra setup of a
>>> maven-plugin so all transformations are done by one plugin only.
>>> 
>>> My thoughts exactly. While it makes sense to have separate plugin for that
>>> (maybe in the future the module-info.class will contain more
>>> information?),
>>> I'm not sure it's worth to have separate plugin just for that. And if we
>>> don't have separate plugin then I think the Jar plugin is the better place
>>> because:
>>> 1. this way it's consistent with the JDK tools
>>> 2. up until Java 9 the usual place to put meta-information about the
>>> package was to place in in the META-INF directory and package it. Of
>>> course
>>> the processing
>>> 
>>> An interesting question (no matter which plugin does the transformation)
>>> is
>>> that if the module-version should be added by default? I feel a bit
>>> uncomfortable about the idea to enable it by default but on other hand
>>> the module-info is a new class so it's unlikely to break anything and it
>>> may prove tiresome to have to set the version explicitly. I mean why would
>>> you want not to have the version set? I personally think that the majority
>>> of the projects would like to have the version set.
>>> 
>>> Regards,
>>> Plamen Totev
>>> 
>>> On Tue, Aug 22, 2017 at 8:17 PM, Robert Scholte 
>>> wrote:
>>> 
>>> Hi,
 
 The JDK 9 jar packager comes with 2 extra options: main-class and
 module-version.
 The first one is used in case of an executable modular jar, the latter is
 just for display/analysis to show which version of a specific module is
 used.
 To support these 2 values, the module-info.class must be adjusted (yes,
 the bytecode!).
 
 It is not that hard to support this as well with a little help from ASM,
 but the question is: which plugin should do this: maven-jar-plugin or
 maven-shade-plugin?
 If you consider this kind of information to be part of the packaging
 process, maven-jar-plugin seems to be the best fit.
 However, if you consider this as a resource transformation, then
 maven-shade-plugin seems better.
 
 Personally I think packaging should be quite a stupid action: making a
 jar
 from a set of files. And it should be very reliable, since it is part of
 the lifecycle of the most used packaging type. Of course you can control
 this when exposed as parameters...
 
 Or should these extra (basic?) features require an extra setup of a
 maven-plugin so all transformations are done by one plugin only.
 
 WDYT?
 Robert
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 
> -- 
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy


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

Re: Loading providers in named modules with ServiceLoader using a plugin class realm

[Chas Honton]

Under what circumstances would a plugin not want the platform classloader?

Chas

> On Jun 25, 2017, at 12:40 PM, Robert Scholte  wrote:
> 
> Hi Guillaume,
> 
> I don't know all the details about the Platform classloader, but it has been 
> introduced with a reason.
> So I don't think we should switch to it by default. I think the plugin is 
> well aware which classloaders / modules it wants to use (it should be), so I 
> think we need to find a mechanism for plugins to select their classloaders 
> and modules.
> 
> thanks,
> Robert
> 
>> On Sun, 25 Jun 2017 17:19:07 +0200, Guillaume Boué  wrote:
>> 
>> Hi,
>> 
>> With the introduction of modules in JDK 9, there were changes with
>> regard to how classloading works, and this impacts class realms created
>> in Maven. Today, the parent (as per ClassLoader.getParent()) of a class
>> realm is null, which represents the bootstrap classloader. In JDK 9, the
>> change is that some classes were moved to a named module other than
>> java.base, and they are not loaded with the bootstrap classloader
>> anymore, but with the platform classloader (which was previously the
>> extension classloader, see JDK-814637).
>> 
>> This has consequences, like MANTRUN-200, where locating providers with
>> the ServiceLoader API, using the plugin class realm, will miss JDK
>> internal implementation classes. In the case of MANTRUN-200, it is
>> Nashorn of the jdk.scripting.nashorn module, that cannot be found
>> because of the way ServiceLoader works
>> http://download.java.net/java/jdk9/docs/api/java/util/ServiceLoader.html#load-java.lang.Class-java.lang.ClassLoader-.
>> During the search in named modules, the class realm will not be able to
>> use its strategy since that process relies on parent delegation
>> implemented as explicit calls to ClassLoader.getParent()
>> (http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/f3cf7fd26baa/src/java.base/share/classes/java/util/ServiceLoader.java#l1062),
>> which, for a class realm, corresponds to the base classloader, i.e. the
>> bootstrap classloader. And since the Nashorn script engine factory was
>> loaded with the platform classloader, it is missed.
>> 
>> It seems that the fix here would be to make all class realms have as
>> base classloader the platform classloader starting with JDK 9, instead
>> of the bootstrap classloader (there is a new utility method in
>> ClassLoader to obtain the platform classloader). I verified that this
>> solves the problem described in MANTRUN-200, but before I create an MNG
>> issue, I'm wondering if this is the correct approach.
>> 
>> What do you think of this change to class realms? The other possibility
>> I can think of would be to have a way in the JDK to override the search
>> in named modules, so that our ClassRealm can also delegate to its parent
>> classloader. It is possible for unnamed modules (since the search
>> process then relies on the ClassLoader.getResources method, that can be
>> overriden) but it doesn't look like (and probably intentionally so) to
>> be possible for named modules.
>> 
>> Guillaume
>> 
>> 
>> ---
>> L'absence de virus dans ce courrier électronique a été vérifiée par le 
>> logiciel antivirus Avast.
>> https://www.avast.com/antivirus
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 


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

Re: [MNG-6169] Lifecycle/binding plugin version updates

[Chas Honton]

Can we declare explicitly that this pom does not inherit from super pom?

Chas

> On May 12, 2017, at 4:50 AM, Michael Osipov  wrote:
> 
>> Am 2017-05-12 um 08:25 schrieb Hervé BOUTEMY:
>> Jenkins build is not flaky: it is strict on dependency resolution from cache,
>> which is an intent, not a bug
> 
> This pretty much explains why a lot of ITs fail here at work with a empty 
> repo. I will to work this through.
> 
>> that's why I don't like changing default plugins versions:
>> 
>> 1. depending on default plugins versions is a bad practice: IMHO, having old
>> plugins helps people know that they should not rely on it
> 
> This basically means that people would need to provide versions explicitly in 
> the POMs starting with Maven 4. Looks like a lot of hassle, doesn't it? I'd 
> better see this in the Super POM rather embedded in a JAR.
> 
>> 2. people who do a "dependency:go-offline" with a previous Maven version but 
>> run
>> offline with updated Maven version will see their build fail and report about
>> dependency:go-offline not being reliable, which is technically not true, but 
>> is
>> sensitive to Maven version (something that is hard to explain)
> 
> Pretty good point. We should actually ad this information to the goal doc. 
> This will also fail if your change your POM.
> 
>> On the first objection, it's a question of choice on how to promote the good
>> practice about explicitely choosing your plugins versions
>> 
>> On the second objection, I had an idea of Maven core improvement that would 
>> fix
>> the go-offline dependency on Maven version used: what if Maven core 
>> distribution
>> did contain a (read-only) local repo with default plugins already resolved?
>> 
>> With such a feature, go-offline would not be dependant on Maven version used
>> (starting from the Maven version that has this pre-built repo). And user 
>> would
>> better see the default dependencies by looking at this pre-builot repo =
>> something I'm sure they will do (but they don't have a look at lifecycle
>> definition files, which are opaque for them)
>> 
>> I didn't have time to work on implementing this idea, I suppose this would
>> just require a new default repository with file://${maven.home}/default-
>> plugins/ url, and to fill this repo at build time with appropriate go-offline
> 
> Sounds like a good idea but would produce a lot of bloat, wouldn't it? All 
> plugin dependency trees. This should be configurable in settings.xml and MDEP 
> should provide a goal to populate such a repo.
> I am afraid that no one will pick this up anytime soon.
> 
> Do you know completely reject the issue to be merged?
> 
> Michael
> 
>> Le jeudi 11 mai 2017, 22:30:43 CEST Michael Osipov a écrit :
>>> Who seconds MNG-6169 for 3.5.1? I have a fully working branch
>>> (MNG-6169_2/not-updated-MJAR-MCOMPILER) passing all ITs on Windows 10
>>> and FreeBSD 10.3-RELEASE.
>>> 
>>> Jenkins build is flaky with notorious file://target/null artifact not found.
>>> 
>>> Some bindings haven't been updated because they cause several ITs to
>>> fail (regressions). I will report them separately.
>>> 
>>> 
>>> Michael
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 


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

Re: [MNG-6169] Lifecycle/binding plugin version updates

[Chas Honton]

How can the super pom be explicitly added to the project's pom?

Chas

> On May 12, 2017, at 4:50 AM, Michael Osipov  wrote:
> 
>> Am 2017-05-12 um 08:25 schrieb Hervé BOUTEMY:
>> Jenkins build is not flaky: it is strict on dependency resolution from cache,
>> which is an intent, not a bug
> 
> This pretty much explains why a lot of ITs fail here at work with a empty 
> repo. I will to work this through.
> 
>> that's why I don't like changing default plugins versions:
>> 
>> 1. depending on default plugins versions is a bad practice: IMHO, having old
>> plugins helps people know that they should not rely on it
> 
> This basically means that people would need to provide versions explicitly in 
> the POMs starting with Maven 4. Looks like a lot of hassle, doesn't it? I'd 
> better see this in the Super POM rather embedded in a JAR.
> 
>> 2. people who do a "dependency:go-offline" with a previous Maven version but 
>> run
>> offline with updated Maven version will see their build fail and report about
>> dependency:go-offline not being reliable, which is technically not true, but 
>> is
>> sensitive to Maven version (something that is hard to explain)
> 
> Pretty good point. We should actually ad this information to the goal doc. 
> This will also fail if your change your POM.
> 
>> On the first objection, it's a question of choice on how to promote the good
>> practice about explicitely choosing your plugins versions
>> 
>> On the second objection, I had an idea of Maven core improvement that would 
>> fix
>> the go-offline dependency on Maven version used: what if Maven core 
>> distribution
>> did contain a (read-only) local repo with default plugins already resolved?
>> 
>> With such a feature, go-offline would not be dependant on Maven version used
>> (starting from the Maven version that has this pre-built repo). And user 
>> would
>> better see the default dependencies by looking at this pre-builot repo =
>> something I'm sure they will do (but they don't have a look at lifecycle
>> definition files, which are opaque for them)
>> 
>> I didn't have time to work on implementing this idea, I suppose this would
>> just require a new default repository with file://${maven.home}/default-
>> plugins/ url, and to fill this repo at build time with appropriate go-offline
> 
> Sounds like a good idea but would produce a lot of bloat, wouldn't it? All 
> plugin dependency trees. This should be configurable in settings.xml and MDEP 
> should provide a goal to populate such a repo.
> I am afraid that no one will pick this up anytime soon.
> 
> Do you know completely reject the issue to be merged?
> 
> Michael
> 
>> Le jeudi 11 mai 2017, 22:30:43 CEST Michael Osipov a écrit :
>>> Who seconds MNG-6169 for 3.5.1? I have a fully working branch
>>> (MNG-6169_2/not-updated-MJAR-MCOMPILER) passing all ITs on Windows 10
>>> and FreeBSD 10.3-RELEASE.
>>> 
>>> Jenkins build is flaky with notorious file://target/null artifact not found.
>>> 
>>> Some bindings haven't been updated because they cause several ITs to
>>> fail (regressions). I will report them separately.
>>> 
>>> 
>>> Michael
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 


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

Re: [ANN] Apache Maven 3.5.0 Released

[Chas Honton]

Congratulations on a successful release!  Thanks to all of the maven core team 
for your work, particularly for the willingness to abandon 3.4 and reset to a 
more iterative approach. 

Thanks,
Chas

> On Apr 7, 2017, at 2:07 PM, Stephen Connolly <steph...@apache.org> wrote:
> 
> The Apache Maven team would like to announce the release of Apache Maven
> 3.5.0.
> 
> You can download the appropriate sources etc. from the download page
> 
> http://maven.apache.org/download.cgi
> 
> Notable changes
> ===
> 
> - ANSI colors added to the console output
> - Fix various bugs in mvn scripts regarding spaces, quotations, special
> characters, etc. also in combination with .mvn/ -files
> - Switch from Eclipse Aether to Maven Artifact Resolver
> 
> What happened to Maven 3.4.0?
> =
> 
> After Maven 3.3.9 was released, the Eclipse Aether project was retired and
> the code base was migrated to the Apache Maven project.
> 
> The original goal for the 3.4.0 release was to replace Aether with the
> exact same code after migration to the Apache Maven project and then
> proceed with bug fixes to the resolver code as well as other areas of Maven.
> 
> The migration of the code between the two foundations took longer than
> expected and as a result there were other changes committed to Maven core
> that were outside the scope of intent for 3.4.0.
> 
> In order to refocus on the original intent for 3.4.0, the decision was
> taken to revert the Maven core history to the point of the 3.3.9 release
> and merge in the desired changes one at a time.
> 
> Because there had been a lot of communication about different features
> being delivered and bugs fixed in Maven 3.4.0 and the new history may not
> contain them in the first release, the decision was taken to forever burn
> the 3.4.x release line.
> 
> More detail on this decision can be read in the mailing list archive[1].
> 
> Contributors
> 
> 
> The Apache Maven team would like to thank the following contributors,
> without whom this release would not have been possible:
> 
> Code contributors:
> 
> - Alex Henrie
> - Andriy
> - Archimedes Trajano
> - Arlo Louis O'Keeffe
> - August Shi
> - Christoph Böhme
> - Harald Wellmann
> - Jason Dillon
> - Joseph Walton
> - Josh Soref
> - Miriam Lee
> - Nemo Chen
> - Sébastian Le Merdy
> - Stuart McCulloch
> - Tobias Oberlies
> - Robert Patrick
> 
> Issue reporters:
> 
> - Alex Henrie
> - Andreas Sewe
> - Andrew Haines
> - Andriy
> - Anthony Whitford
> - Archimedes Trajano
> - August Shi
> - Ben Caradoc-Davies
> - Christoph Böhme
> - Daniel Spilker
> - Falko Modler
> - Fred Bricon
> - Harald Wellmann
> - Jeffrey Alexander
> - Josh Soref
> - Kengo TODA
> - Konrad Windszus
> - Laird Nelson
> - Larry Singer
> - Meytal Genah
> - Mike Drob
> - Miriam Lee
> - Nemo Chen
> - Peter Kjær Guldbæk
> - Rahul Thakur
> - Richard Raumberger
> - Stuart McCulloch
> - Tobias Oberlies
> - Zac Thompson
> 
> Community testers participating in voting for this release series:
> 
> -  Grzegorz Grzybek
> -  Petr Široký
> -  Mark Derricutt,
> -  Dejan Stojadinović
> -  Thomas Collignon
> -  Fred Cooke
> -  Raphael Ackermann
> -  Elliot Metsger
> -  Chas Honton
> -  Dennis Kieselhorst
> 
> The Apache Maven Project Management Committee would also like to thank all
> the committers to the project for their efforts during the chaos that was
> the great reset when the 3.4.x release lines were burned.
> 
> Release Notes - Maven - Version 3.5.0
> =
> 
> Bugs:
> 
>* [MNG-5297] - Site should tell 'prerequisites.maven is deprecated'
>* [MNG-5368] - UnsupportedOperationException thrown when version range
> is not correct in dependencyManagement definitions
>* [MNG-5629] - ClosedChannelException from
> DefaultUpdateCheckManager.read
>* [MNG-5815] - "mvn.cmd" does not indicate failure properly when using
> "&&"
>* [MNG-5823] - mvnDebug doesn't work with M2_HOME with spaces - missing
> quotes
>* [MNG-5829] - mvn shell script fails with syntax error on Solaris 10
>* [MNG-5836] - logging config is overridden by $M2_HOME/lib/ext/*.jar
>* [MNG-5852] - mvn shell script invokes /bin/sh but requires Bash
> functions
>* [MNG-5895] - Problem with CI friendly usage of ${..} which is already
> defined via property in pom file.
>* [MNG-5958] - java.lang.String cannot be cast to
> org.apache.maven.lifecycle.mapping.LifecyclePhase
>* [MNG-5961] - Maven possibly not aware of log4j2
>* [MNG-5962] - mvn.

Re: [VOTE] Release Apache Maven 3.5.0

[Chas Honton]

+1

Java 1.8.0_74
Mac OS X 10.12.3

Multi-module project with 562 goals (50 unique)

Chas

> On Apr 3, 2017, at 3:14 PM, Stephen Connolly 
>  wrote:
> 
> Hi,
> 
> We solved 86 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12336084=Text
> 
> In there are 324 issues left in JIRA for Maven core:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1326
> 
> The distributable binaries and sources for testing can be found here:
> https://repository.apache.org/content/repositories/maven-1326/org/apache/maven/apache-maven/3.5.0/
> 
> Specifically the zip, tarball, and source archives can be found here:
> https://repository.apache.org/content/repositories/maven-1326/org/apache/maven/apache-maven/3.5.0/apache-maven-3.5.0-bin.zip
> https://repository.apache.org/content/repositories/maven-1326/org/apache/maven/apache-maven/3.5.0/apache-maven-3.5.0-bin.tar.gz
> https://repository.apache.org/content/repositories/maven-1326/org/apache/maven/apache-maven/3.5.0/apache-maven-3.5.0-src.zip
> https://repository.apache.org/content/repositories/maven-1326/org/apache/maven/apache-maven/3.5.0/apache-maven-3.5.0-src.tar.gz
> 
> Source release checksum(s):
> apache-maven-3.5.0-src.tar.gz sha1: 1730812af1cdd77493e269b371ef8ac536230c15
> apache-maven-3.5.0-src.zip sha1: 40b18ca1d4e14a04a5b872c822f37f6578a17cb9
> 
> Git tag:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=ff8f5e7444045639af65f6095c62210b5713f426
> 
> Staging site:
> https://maven.apache.org/components/ref/3-LATEST/
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> 
> Thanks,
> -Stephen

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

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

[Chas Honton]

Not testing maven core ITs.  Using multi-module project with 562 goal 
invocations (50 unique goals) including three integration test suites run with 
invoker plugin. 

+1 tested on OS X 10.12.3, Java 1.8.0_074

++1: 3.5.0 warned about a dependent Pom problem which was not found with 3.3.9

Chas

> On Mar 24, 2017, at 8:54 AM, Karl Heinz Marbaise  wrote:
> 
> Hi,
> 
>> On 24/03/17 02:17, Hervé BOUTEMY wrote:
>> we have absolutely no OSX user building Maven core ITs on his personal
>> computer?
>> seriously?
>> Or is there no core IT that shows the issue? then it has to be discovered by
>> hand?
> 
> I can test today evening or tomorrow...on my Mac..
> 
> If this helps?
> 
> Kind regards
> Karl Heinz Marbaise
>> 
>> Notice: to me, this does not mean we need a beta-2: 3.5.0 will have bugs, 
>> like
>> any past or future release
>> 
>> Regards,
>> 
>> Hervé
>> 
>> Le jeudi 23 mars 2017, 19:21:45 CET Christian Schulte a écrit :
 Am 03/23/17 um 19:20 schrieb Christian Schulte:
> Am 03/23/17 um 10:08 schrieb Stephen Connolly:
> Hervé do you think this ordering issue is serious enough to drop and run
> a
> beta-2?
> 
> IMHO no as it is just a beta and we can add it as a known issue in the
> release notes.
 
 Unrelated to this issue there has been another report regarding the
 launcher scripts: MNG-6191
 
 We maybe should do a -beta-2 before the final release with this fixed as
 well.
 
 Seems "readlink" does not support the "-f" option on OSX. Can someone
 with a OSX installation take a look please? The launcher scripts are in
 scope for 3.5.0.
 
 Regards,
>>> 
>>> This would not have happened with an OSX Jenkins build node, BTW.
> 
> -
> 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: POM 5: The problems with mixins

[Chas Honton]

What problems are you trying to solve with mixins?  What is missing from the 
current inheritance scheme?

It appears to me that you are putting the "how before the "what". 

My personal experience is that mixins lead to jar hell rather fast. 

Chas

> On Dec 5, 2016, at 4:28 AM, Christian Schulte  wrote:
> 
> Not having read all of this for now, but that's what I was referring to
> with "relaxing a constraint is easier than enforcing a new one". When in
> doubt how to process conflicting elements or something like that, just
> error out and fail the build with a descriptive error message. If we
> later find out about such a constraint making a valid use-case
> impossible, we can relax that easily.
> 
> 
>> Am 05.12.2016 um 01:31 schrieb Hilco Wijbenga:
>> On 4 December 2016 at 14:56, Stephen Connolly
>>  wrote:
>>> I'm currently trying to figure out how to make mixins possible in POM 5.
>> 
>> This is wonderful news!
>> 
>>> Mixins basically bring a form of multiple inheritance to the POM... which
>>> leads to the problems of how to solve conflicts.
>> 
>> Why allow both inheritance and mixins? Why not simply allow only one
>> or the other? Or rather, allow inheritance only until mixins enter the
>> picture. So you could have a grandparent POM (without mixins), a
>> parent POM (without mixins), and then a child POM (potentially with
>> mixins). I don't really see the value in inheritance if mixins are
>> available. (But I can see why it would be nice to try and re-use an
>> existing company POM or similar.)
>> 
>> That still leaves the problem of including contradicting mixins. I
>> would simply disallow any contradictions. Keep it as simple as
>> possible, you can always make it more complex later. It is already
>> going to be quite difficult to clearly explain any encountered
>> problems to the user without any additional complexity.
>> 
>> Some more thoughts:
>> 
>> 1. Mixin A says A but Mixin B says
>> B. Maven should disallow that. The solution for
>> this would be to reference a property. Then both A and B could simply
>> state ${element.value}. Obviously, this may clash
>> (there may have been a very good reason for requiring "A" or "B") but
>> it is now up to the user to set ${element.value} appropriately or
>> change the combination of mixins. I don't see how Maven would be able
>> to resolve this.
>> 
>> 2. Mixin A says  but Mixin B says
>> . Again, this should not be allowed.
>> Maven can't possibly tell whether the order is relevant.
>> 
>> I have been thinking of a tool to do exactly this. It would use mixins
>> to generate the entire POM. With the above restrictions it seems
>> possible to achieve a real "define it once" type of build. Obviously,
>> it would be much nicer if Maven simply supported this natively. :-)
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


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

Re: maven-gpg-plugin updates

[Chas Honton]

Already there. 

Chas

> On Dec 4, 2016, at 4:22 AM, Christian Schulte  wrote:
> 
>> Am 12/04/16 um 06:27 schrieb Charles Honton:
>> Who can work with me to get maven-gpg-plugin updated?  In particular, I’d 
>> like to add goals to sign and checksum files that are not artifacts.  See 
>> MGPG-43 .  
>> 
> 
> Could you add ITs to that patch as well, please?
> 
> 
> -
> 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: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Chas Honton]

I use the current Pom to automate checking license policy and checking  owasp 
database for known security flaws. The scm and website metadata is also very 
useful. Automated download of source for debugging is essential. As a consumer, 
I don't want to lose these abilities. 

Chas

> On Aug 25, 2016, at 10:11 AM, Paul Benedict  wrote:
> 
> Is it really correct to call a dependency-only (more of less) file a POM if
> it ceases to contain project information? A project is (or should be!)
> synonymous with a build. Is that why someone referred to it as a DOM? A DOM
> makes way more sense to me than overloading the usage of POM and calling it
> a "consumer POM"
> 
> Cheers,
> Paul
> 
> On Thu, Aug 25, 2016 at 11:53 AM, Robert Scholte 
> wrote:
> 
>> For both the flattened-pom and consumer-pom the idea is to remove build
>> related information. Most of it is only used during build.
>> The question is: is there other information which should be added?
>> e.g. In case of JARs: the major version number of the class file format
>> being used. Is it interesting to know this BEFORE downloading the jar? And
>> if so, there should be a possibility to make choices based on that
>> information. The choice-option doesn't exist and would make it all too
>> complex.
>> I would say that it is indeed all about dependencies.
>> 
>> thanks,
>> Robert
>> 
>> 
>> On Thu, 25 Aug 2016 18:25:36 +0200, Paul Benedict 
>> wrote:
>> 
>> The only (minor?) issue I have with the term "consumer POM" is that it
>>> implies one type of consumption. What is the kind of consumption we're
>>> addressing -- is it merely the GAV and dependencies?
>>> 
>>> Cheers,
>>> Paul
>>> 
>>> On Thu, Aug 25, 2016 at 3:34 AM, Robert Scholte 
>>> wrote:
>>> 
>>> On Thu, 25 Aug 2016 01:10:36 +0200, Stephen Connolly <
 stephen.alan.conno...@gmail.com> wrote:
 
> On 24 August 2016 at 04:50, Robert Scholte  wrote:
> 
> 
> I realized last ApacheCon that I wasn't clear about my definiton of the
> 
>> consumer-pom.
>> I don't think it should be a flattened pom with only the dependency
>> information. Instead it shouldn't be a pom  (matching the pom.xsd) at
>> all.
>> 
>> 
>> I am not in disagreement, but as a concept the name "consumer pom" has
> more
> traction.
> 
> 
 I'd prefer consumer pom too, but it has led to confusion due to the
 assumption that consumer pom and flattened pom are the same thing. To me
 it
 makes sense to consider a new fileformat for the consumer pom which
 matches
 better the requirements. And yes, the "provides" would fit here.
 
 
 
 I see the builder pom as probably ending up not even being XML at all.
> Rather IMHO it will end up being a DSL that is easy to author and not
> verbose... and certainly not XML
> 
> So the consumer pom should be stripped back to include two sets of
> information:
> 
> * dependencies - we are mostly familiar with this... though we may not
> expose all the scopes... depends on how we think about things and how we
> view scopes moving forward
> 
> * provides - this is vitally important IMHO and not handled currently.
> 
> To understand provides we have to look at things like JavaEE (but the
> concept has general utility... though I suspect only for about 10-25% of
> projects)
> 
> If I have a project that says: provides javax.servlet:servlet-api:3.1
> then
> that is saying that my project is providing the equivalent content as in
> javax.servlet:servlet-api:3.1 so for example
> org.jboss.spec.javax.servlet:
> jboss-servlet-api_3.1_spec:1.0.0.Final would say
> javax.servlet:servlet-api:3.1
> 
> When resolving the dependency tree, maven then knows that any transitive
> requirement for javax.servlet:servlet-api:3.1 has already been met by my
> direct dependency on org.jboss.spec.javax.servlet:j
> boss-servlet-api_3.1_spec
> :1.0.0.Final if we have a direct dependency on
> org.apache.tomcat:tomcat-servlet-api:8.5.4 (which would also say
> javax.servlet:servlet-api:3.1) then Maven can report an error and fail
> the
> build due to dependency conflict.
> 
> There are lots of other improvements we can add, but to start we need to
> have a way to declare when a project includes duplicate content of
> another
> artifact. Convention will be required to make this work correctly...
> perhaps we can even introduce a new project type that provides needs to
> point at so that a provides has to point at an "empty" specification
> project...
> 
> Finally, for the consumer pom refactoring I believe we need to address
> architecture specific artifacts as these are a sort of implicit
> provides.
> 
> 
> Maybe it should be 

Re: Profile Activation

[Chas Honton]

The behavior is AND. You can have multiple profiles for OR. 

Chas

> On Aug 15, 2016, at 11:45 AM, Christopher  wrote:
> 
> If there could be "AND" and "OR" primitives for profile activation
> conditions, you could do something like:
> 
>   
> 
>   !profilea
> 
> 
>   profilea
>   !true
> 
>   
> 
> Sadly, this feature does not exist.
> 
>> On Fri, Aug 12, 2016, 11:45 Karl Heinz Marbaise  wrote:
>> 
>> Hi to all,
>> 
>> I have the following profile:
>> 
>> 
>>   
>>   profile-not-value-true
>>   
>> 
>>   profilea
>>   !true
>> 
>>   
>>   
>> 
>>   
>> com.soebes.maven.plugins
>> echo-maven-plugin
>> 
>>   
>> initialize
>> 
>>   echo
>> 
>>   
>> 
>> 
>>   
>> profile not value true
>>   
>> 
>>   
>> 
>>   
>> 
>> 
>> So the question is: What would you expect you need to do to activate
>> this profile?
>> 
>> Currently this profile is activated cause if I don't define the property
>> "profilea" at all it seemed to that Maven is assuming this means "not
>> value 'true'" ?
>> 
>> I have assumed it should be activated if the property exists which means
>> giving it on command line like this:
>> 
>> mvn -Dprofilea
>> 
>> 
>> 
>> WDYT ?
>> 
>> Kind regards
>> Karl Heinz Marbaise
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>> 

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

Re: opinions on MJAVADOC-451

[Chas Honton]

+1

Chas

> On Aug 5, 2016, at 7:37 AM, Christopher  wrote:
> 
> I'm always in favor of adding skip properties. They are very useful for
> manipulating builds for debugging, running on CI servers, controlling
> executions in child poms, etc. Even if it's not recommended to run
> unattended, it's still possible, so a skip option is useful.
> 
>> On Thu, Aug 4, 2016, 11:47 Richard Sand  wrote:
>> 
>> Anyone want to give this a quick read/opinion? :-)
>> 
>> -Richard
>> 
>> -- Original Message --
>> 
>> From: "Richard Sand" 
>> To: dev@maven.apache.org
>> Sent: 8/1/2016 6:33:30 PM
>> Subject: opinions on MJAVADOC-451
>> 
>>> Hi all,
>>> 
>>> I'd like to ask for opinions on
>>> https://issues.apache.org/jira/browse/MJAVADOC-451. Robert Scholte and
>>> I have been discussing this off list and essentially disagree on it.
>>> 
>>> The request is very simple - to add a "skip" parameter to the
>>> javadoc:fix goal. In my projects we are using the fix goal unattended,
>>> i.e. with the parameter "force=true", as part of the regular build
>>> lifecycle.
>>> 
>>> Most goals (including javadoc) that run in the regular lifecycle have a
>>> skip option. Robert's position (and forgive me if I misrepresent this
>>> at all Robert and please weigh in) is that javadoc:fix should not be
>>> used in the lifecycle and that the goal should in fact have
>>> requireDirectInvocation=true. He also pointed out to me that I can
>>> create a profile to enable/disable the goal as an alternative.
>>> 
>>> My opinion is that, since the goal does not require direct invocation,
>>> then running within the lifecycle has to be considered acceptable use
>>> of the goal. And having a skip parameter adds 5 lines of code, is a
>>> common and normal pattern used by many other plugins/goals, and allows
>>> the goal to be used in this fashion without introducing even more
>>> profiles.
>>> 
>>> I've submitted patches for this issue and also several other issues in
>>> the javadoc plugin as I continue to work through getting the goal to
>>> work well automated. Just pointing out that I'm not just asking for the
>>> larger community to do stuff to make my life easier - I'm trying to
>>> contribute as best I can and provide patches for what I uncover.
>>> 
>>> Best regards,
>>> 
>>> Richard
>>> 
>>> 

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