Re: Build vs Consumer POM study

[Charles Honton]

Hervé,

Great work!  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

EcoSystem Impacts
projects distributing source code through maven central should include the 
build pom.  This requires updating maven source plugin.
flattened consumer pom will impact version resolution; what was a deep 
dependency will be brought to second level
how will IDEs be affected?

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

Re: Reactor safe/rally points

[Charles Honton]

Are these integration test for the plugin or do the integration tests use the 
plugin?  If the former, then the invoker plugin is appropriate.  If the latter, 
then a non-code, non-transitive dependency scope is a possibility.  Again, this 
new scope has the backwards compatibility problem..

> On Nov 5, 2017, at 11:30 PM, Stephen Connolly 
>  wrote:
> 
> Yes it would, but socially people don’t do that... and anyway, there are
> legitimate use cases, eg tomee has (or had if they gave up fighting and
> moved it out of reactor) a plugin that was tied to the container version.
> To allow integration tests in the same reactor as the main codebase, it is
> reasonable to want the plugin built at the same time.

Re: Reactor safe/rally points

[Charles Honton]

So doesn’t this require a new directive such as ‘ 
scope or similar regardless of safe/rally points?   And to provide backwards 
compatibility, there must be a split between the legacy consumer view of the 
pom and the new producer view of the pom?
  
> On Nov 5, 2017, at 11:30 PM, Stephen Connolly 
>  wrote:
> 
>> In the first case, the module creating a shaded jar can mark its
>> constituent jars as optional; preventing the transitive dependencies.
> 
> 
> Ha! That does not do what you think it does.
> 
> Optional dependencies are still there but only as a version constraint that
> gets applied if something else brings the dependency into the tree in as a
> non-optional dependency.
> 
> Normally you need a complex deep tree to see the effect (as most people use
> version hints rather than specifications... and with hints, closest wins,
> whereas specifications are globally merged)
> 
> Provided scope is more correct, but shade doesn’t operate on provided
> scope... and anyway iirc that also pushes the constraint as transitive.
> 
> With shade, the dependency is removed.

Re: Reactor safe/rally points

[Charles Honton]

Both these use cases sound like adding incredible complexity to support less 
than 1% situations, and worse, encouraging monolithic builds.  

In the first case, the module creating a shaded jar can mark its constituent 
jars as optional; preventing the transitive dependencies.
In the second case, It would be better for the plugin be an independent build 
to encourage re-use of that plugin.

> There are two sets of problems that, assuming we want to fix, both need
> some way to rally a concurrent multimodule build at.
> 
> 1. There is the shade like class of problems, where a plugin wants to
> modify the effective transitive dependencies of a module.
> 
> 2. There is the extensibility class of problems, where people want to build
> a plugin and consume the same plugin in one reactor.


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

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Charles Honton]

From a security perspective, I would expect that core classes can not be 
overridden by extensions or plugins.  Likewise, extension classes can not be 
overridden by plugins.

Given the use case of defaulting resources, I would expect that the plugin 
resources are first, followed by plugin specific extensions, followed by global 
extensions, finally core maven.  (This allows resources to be specialized.)

regards,
chas

> On Sep 18, 2017, at 3:20 AM, Stephen Connolly 
>  wrote:
> 
> Hmmm, so I did some experiments:
> 
> If you want to ride along, the experiments are at:
> 
> https://github.com/stephenc/mng-6209
> 
> So basically I have a plugin that does three different tests:
> 
>getLog().info("Injected by @Component:");
>for (Lifecycle l : lifecycles) {
>if (l.getId().startsWith("mng-6209-")) {
>getLog().info("  " + l.getId().substring(9));
>}
>}
>getLog().info("");
>getLog().info("On Plugin Class Loader:");
>try {
>ClassLoader tccl = ListMojo.class.getClassLoader();
>for (URL url :
> Collections.list(tccl.getResources("META-INF/probe.txt"))) {
>InputStream is = url.openStream();
>try {
>getLog().info("  " + IOUtil.toString(is).trim());
>} finally {
>is.close();
>}
>}
>} catch (IOException e) {
>throw new MojoExecutionException(e.getMessage(), e);
>}
>getLog().info("");
>getLog().info("On Thread Context Class Loader:");
>try {
>ClassLoader tccl =
> Thread.currentThread().getContextClassLoader();
>for (URL url :
> Collections.list(tccl.getResources("META-INF/probe.txt"))) {
>InputStream is = url.openStream();
>try {
>getLog().info("  " + IOUtil.toString(is).trim());
>} finally {
>is.close();
>}
>}
>} catch (IOException e) {
>throw new MojoExecutionException(e.getMessage(), e);
>}
> 
> 
> First off, I hijack the @Component injection with some fake "lifecycles" to
> see what "plexus" exposes to the plugins.
> 
> Second, I look at the resources visible from the plugin's classloader.
> 
> Finally, I look at the resources visible from the TCCL.
> 
> Here's what 3.5.0 outputs:
> 
> [INFO]
> 
> [INFO] Building Both extensions. Order: plugin1, plugin2 1.0-SNAPSHOT
> [INFO]
> 
> [INFO]
> [INFO] --- plugin1:1.0-SNAPSHOT:list (default) @ probe1 ---
> [INFO] Injected by @Component:
> [INFO]   plugin1
> [INFO]
> [INFO] On Plugin Class Loader:
> [INFO]   plugin1
> [INFO]
> [INFO] On Thread Context Class Loader:
> [INFO]   plugin1
> [INFO]
> [INFO] --- plugin2:1.0-SNAPSHOT:list (default) @ probe1 ---
> [INFO] Injected by @Component:
> [INFO]   plugin2
> [INFO]
> [INFO] On Plugin Class Loader:
> [INFO]   plugin2
> [INFO]
> [INFO] On Thread Context Class Loader:
> [INFO]   plugin2
> [INFO]
> [INFO]
> 
> [INFO] Building Only plugin1 extensions. Order: plugin1, plugin2
> 1.0-SNAPSHOT
> [INFO]
> 
> [INFO]
> [INFO] --- plugin1:1.0-SNAPSHOT:list (default) @ probe2 ---
> [INFO] Injected by @Component:
> [INFO]   plugin1
> [INFO]
> [INFO] On Plugin Class Loader:
> [INFO]   plugin1
> [INFO]
> [INFO] On Thread Context Class Loader:
> [INFO]   plugin1
> [INFO]
> [INFO] --- plugin2:1.0-SNAPSHOT:list (default) @ probe2 ---
> [INFO] Injected by @Component:
> [INFO]   plugin2
> [INFO]   plugin1
> [INFO]   extjar2
> [INFO]   extjar1
> [INFO]
> [INFO] On Plugin Class Loader:
> [INFO]   plugin2
> [INFO]   extjar2
> [INFO]   extjar1
> [INFO]
> [INFO] On Thread Context Class Loader:
> [INFO]   plugin2
> [INFO]   extjar2
> [INFO]   extjar1
> [INFO]
> [INFO]
> 
> [INFO] Building Both extensions. Order: plugin2, plugin1 1.0-SNAPSHOT
> [INFO]
> 
> [INFO]
> [INFO] --- plugin2:1.0-SNAPSHOT:list (default) @ probe3 ---
> [INFO] Injected by @Component:
> [INFO]   plugin2
> [INFO]
> [INFO] On Plugin Class Loader:
> [INFO]   plugin2
> [INFO]
> [INFO] On Thread Context Class Loader:
> [INFO]   plugin2
> [INFO]
> [INFO] --- plugin1:1.0-SNAPSHOT:list (default) @ probe3 ---
> [INFO] Injected by @Component:
> [INFO]   plugin1
> [INFO]
> [INFO] On Plugin Class Loader:
> [INFO]   plugin1
> [INFO]
> [INFO] On Thread Context Class Loader:
> [INFO]   plugin1
> [INFO]
> [INFO]
> 
> [INFO] 

maven-gpg-plugin updates

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

Can a committer to another Apache project commit to maven plugin repositories?

regards,
chas 

Plugin embedded configuration property configuration (cross posted after no response in maven users)

[Charles Honton]

I'm creating a new plugin where i would like the to have "embedded" 
configuration. 

public abstract class MyAbstractMojo extends AbstractMojo {

@Parameter
private Embedded embedded;

Where the ”embedded" configuration pojo has property injection with default 
values.

@Named
public class Embedded {

@Parameter(property=“embedded.name", defaultValue= "default")
private String name;

@Parameter(property=“embedded.autoCreate", defaultValue= "false")
private Boolean autoCreate;

I expect the configuration xml would look like:

  
my-group/groupId>
my-artifact
${my.version}
 
  
true
  

I have been unsuccessful in getting the property injection or default values to 
work.  Should
this work?  What am I missing?

thanks,
chas