Re: Terminology proposal: "Maven module" -> "Maven sub-project"

[Andreas Sewe]

Guillaume Nodet wrote:

Maybe now is the time to re(de)fine our terminology:
https://maven.apache.org/glossary.html.


Yes, please!

In fact, I didn't even know about the glossary (after 10+ years of using 
Maven). It's not linked from the POM Reference, for example.


At any rate, I have just proposed some terms for a hypothetical glossary 
in my 'More rigorous terminology - Was: Terminology proposal: "Maven 
module" -> "Maven sub-project' post to this very thread.


Best wishes,

Andreas

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

More rigorous terminology - Was: Terminology proposal: "Maven module" -> "Maven sub-project"

[Andreas Sewe]

Hi,

just a long term Maven user here, but I'd like to chime, as I don't
think renaming module to subproject is that big an improvement. In fact,
it may actually lead to *more* confusion. Here's why:

Maven has two *orthogonal* ways how to projects can relate to each
other: aggregation and inheritance.

As they are frequently used together, terminology is unfortunately often
used in a somewhat sloppy fashion, even within the official
documentation (example below). As they are distinct concepts, however, I
think it is important to be precise.

When explaining Maven aggregation and inheritance to a co-worker, I
hence use the following glossary (my own, not in any way official):

- *project*:
  Anything that has a POM (whose root element is /project)

- *aggregator* (project):
  A POM with non-empty /project/modules element
  (always has /project /packaging = "pom")

- *module*:
  A POM referenced by an aggregator project
  (note that the same POM may be referenced by multiple aggregators,
  e.g., to select different "slices" of projects to build)

- *child* (project):
  A POM with /project/parent element

- *parent* (project):
  A POM referenced by a child project
  (always has /project/packaging = "pom")

Subject to the constraint that some projects must have packaging "pom",
you can combine these, so you may have a child module, i.e., a project
that is both a child project and a module (albeit not necessarily with
the same project as parent and aggregator, respectively).

But as I said, even the official documentation is not always that
precise. An example from the maven-site-plugin's FAQ [1]:


Why don't the links between parent and child modules work when I run
"mvn site"?

What "mvn site" will do for you, in a multi-project build, is to run
"mvn site" for the parent and all its modules individually. The
links between parent and child will not work here.


It really should be "*aggregator* and all its modules". Also, there may
be both links from an aggregator to its modules (/site/body/menu/@ref =
"modules") *and* from a child to its parent (/site/body/menu/@ref =
"parent").

Coming back from this tangent to Martin's proposal, I don't think using
the term "Maven sub-project" improves things. In fact, it makes it even
easier to mistake a module (aggregation) for a child project
(inheritance), as the difference between sub-project and child project
is very subtle.

I would hence restrict the use of "sub-something" to inheritance (think
"sub-class") and never use it to discussion aggregation. In particular,
"submodule" is really redundant, as a module is always below an
aggregator by definition.)

What I would have rather like to see is the following:

1. Some kind of glossary (maybe as part of the POM Reference [2], which
   ATM discussion these terms in only passing)

2. More rigor when talking about modules vs. children in the official
   documentation. (Would be willing to create PRs once an official
   glossary exists that the PRs can follow.)

IMHO, this would avoid a lot more confusion than a hypothetical mixup of
Maven modules with JPMS modules. (FWIW, my past Maven projects have
build JPMS modules, OSGi bundles, NetBeans modules, Eclipse plug-ins and
more without much confusion.)

Just my 2 cents.

Best wishes,

Andreas

[1]

[2] 

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

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Andreas Sewe]

On 20.07.22 15:39, Karl Heinz Marbaise wrote:

On 20.07.22 13:04, Romain Manni-Bucau wrote:

 > There is no need to use toolchain to run your build with JDK17 and
 > create code for Java 8... you can use --release 8
 > (8)...
 >
 > No toolchain needed.

So you run tests with java 17? This is not what you want if your prod is
in java 8, you can still get surprises so you need toolchain in your
build (same happen for compilation since bytecode is not 1-1, only
signatures).


First what kind of surprises?

Second can you show an example of different bytes codes?


Just a regular Maven user here, but I'll give you an example, Karl 
Heinz, where testing against different Java versions was necessary to 
avoid shipping a blocker bug -- even though the bytecode didn't differ 
at all.


Some context: We maintain a couple of plug-ins for different IDEs 
(Eclipse, IntelliJ, NetBeans). Each plugin needs to be compatible with a 
whole range of IDE versions, as not all our users (can) use the latest 
and greatest. And different IDE versions usually mean different Java 
requirements, too.


In the case of the NetBeans plug-in (the same holds for Eclipse and 
IntelliJ, but these are build with Gradle and Maven+Tycho, respectively, 
rather than with plain Maven) this means that the plug-in needs to 
target Java 8 at the lower end, as older versions of NetBeans don't even 
run on the latest version of Java. Hence, we compile against Java 8.


However, we *also* occasionally test against newer versions of Java 
(e.g., in our nightly builds) to catch errors like the following:


The plug-in classloader of NetBeans [1] (and IntelliJ [2], FWIW) does 
not support multi-release JARs, which means that the following LOG4J2 
statement fails when running on Java 9 or later.


private static final Logger LOGGER = LogManager.getLogger();

As the plug-in classloader does not support the multi-release 
capabilities of the Log4J2 JAR, we end up in the Java 8 variant of 
getLogger(), which no longer works under newer versions of Java. The 
resulting ExceptionInInitializerError completely breaks our plug-in, but 
this luckily has been found during testing -- running the tests with 
Java 9 or later.


I hope this example was useful to the discussion at hand.

Now, at the moment we run Maven itself with Java 17 (as it speeds up our 
builds) and use toolchains to compile *and* test against Java 8. During 
our nightly build, however, we also pass in a system property which 
selects a different toolchain (ATM, Java 11).


This works, but is not ideal, as our nightly sanity build not only tests 
against Java 11 but also builds against it; both maven-compiler-plugin 
and maven-surefire-plugin use the *same* toolchain. Unfortunately, this 
means that we don't have a guarantee that the test against Java 11 use 
the same bytecode that we ship, since the nightly build compiles with 
the Java 11 but we have to ship the code compiled against Java 8 (i.e., 
our lowest denominator).


In an ideal world, our setup would look like this:

- mvn: Runs with Java 17
- maven-compiler-plugin: --release 8
- maven-surefire-plugin: a Java 8/11/17 toolchain, selected by system
property

At the moment, we are not there yet, as we cannot use --release, as 
there cannot be separate toolchains for compilation and test. If that 
were to change with Maven 4, that would be great, of course.


Hope this helps.

Best wishes,

Andreas Sewe

[1] <https://issues.apache.org/jira/browse/NETBEANS-3679>
[2] <https://youtrack.jetbrains.com/issue/IDEA-220300>

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

Re: Feature proposal: Dependency deprecation indicators

[Andreas Sewe]

Hi,

I was previously just lurking here but following the discussion with
interest. Here are my 2 cents:

Chris Kilding wrote:
> I think we could begin by working out some constraints for the feature...
> 
> First, I think it should be possible to deprecate (or undeprecate) an 
> artifact without compiling a new version of it.
> 
> This is because:
> 
> - In some legacy code situations (e.g. when the code was not checked in to 
> VCS), nobody can compile the artifact any more. We would not want this to 
> prevent us deprecating the artifact.
> - Deprecation and undeprecation should be quick operations. Compiling and 
> releasing new versions can take significant time.
> 
> This constraint suggests that a deprecation indicator should be something 
> applied *to* an artifact rather than part *of* an artifact. It would lead us 
> towards putting the indicator in the repository metadata, not the POM.

Could we not simply upload an artifact with a classifier like
"deprecation" to the repository. AFAICT, this would even work after the
fact, i.e., after the initial release.

Say we have following files in our repository:

  foo-1.0.0.pom
  foo-1.0.0.jar
  foo-1.0.0-javadoc.jar
  foo-1.0.0-sources.jar

Deprecating Foo 1.0.0 would then simply add another file:

  foo-1.0.0-deprecation.xml

That way, tools that are unaware of the deprecation mechanism would
operate as before. Also, the stability requirements of the Central
Repository that Slawomir mentioned would AFAIK not we violated; none of
the artifacts (or their checksums or signatures) are touched -- only the
maven-metadata.xml needs to be updated with a new .

Slawomir Jaranowski wrote:
> Changing status / metadata of artifacts will break "Release Stability" of
> Central Repository
> Once artifacts was release should never change ...
> https://central.sonatype.org/faq/can-i-change-a-component/

Now, a tool that is aware of the deprecation mechanism would simply
download the deprecation.xml as well.

In fact, you would not even need to build this mechanism into Maven
itself; a simple maven-deprecation-plugin would do.

A goal like deprecation:deploy would upload a deprecation.xml to an
existing GAV (and might not even require a project, as the original code
may not have been checked into VCS, as Chris mentioned above).

A goal like deprecation:check could be bound to the validate phase and
warn (or fail the build) if a deprecated dependency is used. This goal
might need some extra option like  to also
include a plugin's  and not just the projects, however.
(FYI, the pgpverify-maven-plugin, which tries to verify the PGP
signatures of all dependencies, faces similar challenges [1]).

WDYT?

Best wishes,

Andreas

[1]




OpenPGP_signature
Description: OpenPGP digital signature

Re: Moving away from Modello

[Andreas Sewe]

Robert Scholte wrote:
> Well, where is the need for additional namespaces and how they be handled?
> The reader has a strict mode, should it fail or ignore unknown tags?
> I am aware of one request: adding a namespace on plugins configuration (to 
> validate its content), however the configuration-element is part of the maven 
> namespace, so I don't think this will work.

Yes, unless you want namespace prefixes, which is awkward for
 children.

However, there is one area where I would have liked better namespace
support in the past, namely when plugins need free-form XML
 elements. The most well-known use case is the
maven-antrun-plugin's  configuration element, which is of type
PlexusConfiguration.

AFAIK, the following won't work with a PlexusConfiguration target:

  http://example.org/";>

  42

  

The PlexusConfiguration would only give you access to the QName
"ex:example" with no way to determine what URI the "ex" namespace prefix
is bound to.

You would have to write it like this:

  
http://example.org/";>
  42

  

Now that might not seem like a big difference, but remember that you
could move the xmlns:ex declaration all the way up to the project
 element and thereby sharing it among multiple 
elements.

FYI, the use case I had in the past was configuring XQuery/XSLT engines,
whose external variables and configuration options are namespaced:

  
http://example.org/";
xmlsns:xs="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
  42

  

Not being able to place those namespace declarations on the root element
really hurts, in particular as the XMLSchema-instance namespace is
normally already declared there -- but you cannot "see" that from your
PlexusConfiguration.

Note that this is *not* an argument in favour of dropping Modello; it is
just an argument in favour of better namespace support (or rather
awareness) in something like PlexusConfiguration.

Best wishes,

Andreas Sewe



OpenPGP_signature
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven JXR Plugin version 3.1.1

[Andreas Sewe]

Hi Robert,

> Regarding the voting, every vote counts, maybe especially from users.
> Depending on the release manager, their negative votes might result in the 
> cancelling of the release.
> A few years ago we decided to drop the word "binding" during the vote, 
> because it doesn't motivate non-committers to verify a release.
> Instead we mention if there are enough PMC votes (for legal reasons).
> 
> With that in mind, can I turn your message into a +1?

Sure. Here you go:

+1

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven JXR Plugin version 3.1.1

[Andreas Sewe]

Hi,


> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for at least 72 hours.

just a user of the maven-jxr-plugin and not a committer, but I wanted to
let you know anyway that version 3.1.1 works fine for me, even if I
cannot participate in the voting proper. So thanks for doing a release!

Hope this helps.

Andreas



signature.asc
Description: OpenPGP digital signature

Re: Requesting release of maven-jxr-plugin and maven-changes-plugin

[Andreas Sewe]

Matt Nelson wrote:
> Requesting release of maven-jxr-plugin and maven-changes-plugin. Is there 
> anything blocking these releases that I can assist with?
> 
> Looking forward to using the contributions I made a while ago.
> https://issues.apache.org/jira/browse/JXR-143

I second that for the maven-jxr-plugin; I am also looking very much
forward to that improvement.

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Re: testing pgpverify-maven-plugin

[Andreas Sewe]

Hi,

> I just tested pgpverify-maven-plugin on maven-artifact-plugin [1].
> I was successful, really nice.

I second that. Highly useful plugin and well-documented, too, which
unfortunately isn't always the case.

I have a few suggestions for improvement, though, which I have added to
the GitHub issue tracker [1]. Hope that helps.

Best wishes,

Andreas Sewe

[1] <https://github.com/s4u/pgpverify-maven-plugin/issues/created_by/sewe>



signature.asc
Description: OpenPGP digital signature

Re: Maven Sign Plugin

[Andreas Sewe]

Hi,

> I have some experience in case of verifying pgp signatures using Bouncy
> Castle during work on my pgpverify-maven-plugin.
> So If you would, I can try to help with the sign plugin.

using Bouncy Castle or the Apache Commons OpenPGP wrapper thereof [1]
would be awesome and would make the build less dependent on its
environment, i.e., the installed "gpg" executable.

So I'm very much looking forward to this new plugin.

Best wishes,

Andreas

[1] 



signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven JXR version 3.1.0

[Andreas Sewe]

Hervé BOUTEMY wrote:
> ok, I can cancel the vote
> are you able to open a Jira issue, provide a test and eventually a fix, 
> please?

- Opened 

- Attached a small patch to it that enhances the "simple-project"
  integration test to catch this bug

- Ran "git bisect" and narrowed it down to this (rather large) commit:

> commit b4117e7ef0795eed02e2ace3c9c4c310f5391aac
> Author: rfscholte 
> Date:   Fri Jul 5 00:11:29 2019 +0200[JXR-142] Switch to JSR330 
> Dependency Injection,
> [JXR-144] Require Maven 3.1.0:04 04 
> 9bd9a415b2e3d94406911ca475603de67b504be9 
> dc78032a3f63c806041f360da96e9468c955f421 M   maven-jxr-plugin

Not sure whether I can figure out how to fix this regression.

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven JXR version 3.1.0

[Andreas Sewe]

Andreas Sewe wrote:
> Hervé BOUTEMY wrote:
>> We solved 6 issues:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317527&version=12344185&styleName=Text
> 
> thanks for staging the release. The new jxr-no-fork and test-jxr-no-fork
> goals work like a charm for me. :-)

Spoke too soon. Found one issue where the test-jxr-no-fork goal (and
test-jxr as well) generates "Class Summary" entries (in
target/site/xref-test/index.html) for classes from src/main/java and not
just from src/test/java. This is not only unexpected, but moreover, the
links to the non-test classes are broken. :-(

This seems to be a regression from 3.0.0 and would IMHO be a release
blocker.

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven JXR version 3.1.0

[Andreas Sewe]

Hervé BOUTEMY wrote:
> We solved 6 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317527&version=12344185&styleName=Text

thanks for staging the release. The new jxr-no-fork and test-jxr-no-fork
goals work like a charm for me. :-)

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Re: Release maven-jxr-plugin please?

[Andreas Sewe]

Hi,

> would it be possible to release the maven-jxr-plugin? The last release
> is from September 2018 and since then (15 months ago, in fact) it
> finally got "jxr-no-fork" goals, bringing it on par with
> maven-javadoc-plugin and maven-source-plugin.

just an addendum: Is there anything I can do to help with a release? Run
any tests? Something along those lines?

Best wishes.

Andreas



signature.asc
Description: OpenPGP digital signature

Release maven-jxr-plugin please?

[Andreas Sewe]

Hi,

would it be possible to release the maven-jxr-plugin? The last release
is from September 2018 and since then (15 months ago, in fact) it
finally got "jxr-no-fork" goals, bringing it on par with
maven-javadoc-plugin and maven-source-plugin.

Best wishes,

Andreas

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

Re: [DISCUSS] Merging small plugins

[Andreas Sewe]

Hi Enrico,

> What about creating some maven-ext-plugins git repository with a parent and
> reactor pom and move all of those plugins that are really never released?
> 
> I am thinking to side plugins like jdeps, checkstyle, pmd, enforcer

that's a bad idea as multiple otherwise unrelated goals then share their
dependencies.

Assume, for the moment, that the maven-ext-plugin has both checkstyle
and pmd goals and that I specify both a specific version of Checkstyle
and PMD in the plugin's  element. Now what happens if
Checkstyle and PMD have conflicting transitive dependencies?

And, no, this is not hypothetical. I have this exact problem with the
xml-maven-plugin: Its validate and transform goals often require
, e.g., to support Relax NG validation or XSLT 2.0
transformation and those dependencies *do* have conflicting
dependencies. AFAIK, there is no workaround for this, as 
are unfortunately not -level; you only can specify them for
the plugin as a whole. :-(

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Re: Dynamic phases proposal

[Andreas Sewe]

Stephen Connolly wrote:
> https://cwiki.apache.org/confluence/display/MAVEN/Dynamic+phases
> 
> Thoughts?

Very nice. I like this a lot. In particular, it still feels like Maven
with its well-known phases rather than like the "every project rolls
their own" approach of Ant or Gradle.

And to answer one specific question from your proposal: "Do we need a
differentiation between validate and initialize?"

I would argue that the answer is Yes; the two phases are for different
things.

To initialize I would bind something like buildnumber:create or pretty
much all of the build-helper-maven-plugin's goals. My intuition would be
that the initialize phase is where you programmatically augment the
project model.

In contrast, the validate phase is for validating your input (or
environment). Now in the common case (Java), inputs are already
validated by the compiler, but if my compile goal is xml:transform, then
it makes sense to have xml:validate bound to the validate phase, as XSL
Transforms typically don't check that diligently that their input
adheres to some expected format. (It also makes sense to bind
xml:validate bound to test or verify, too, to check the output's format.)

Just my 2 cents.

But overall, a really nice proposal.

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Re: last review of Reproducible Builds proposal

[Andreas Sewe]

Hi,

> but the format of the timestamp is completely different ... doesn't that 
> matter?

I don't think so; at least I don't think the Bnd-LastModified header is
meant to be parsed by machines.

But I have _removeheaders>Bnd-* (yes, wildcards are
supported) in my , so what do I know...

> I was currently going for the option number 1 with removing the header.
> 
> In order to be 100% happy with this, I would prefer a setup where the normal 
> mechanisms are used if no maven.build.outputTimestap is defined, but if it is 
> (because a future version of the maven release plugin set it there) it uses 
> that.

You could use a  that is activated when
maven.build.outputTimestap is defined (or not defined) to implement this
behavior. I haven't tested this, however.

Best wishes,

Andreas





signature.asc
Description: OpenPGP digital signature

Re: last review of Reproducible Builds proposal

[Andreas Sewe]

Christofer Dutz wrote:
> Well I have a new candidate:
> 
> maven-bundle-plugin
>  
> Creates: Bnd-LastModified in the MANIFEST.MF
> 
> Gotta find out a way to either suppress that entry (Would be great if it 
> could consume the same property)


  
<_removeheaders>Bnd-LastModified
  


Alternatively


  
${maven.build.outputTimestap}
  

Re: last review of Reproducible Builds proposal

[Andreas Sewe]

Emmanuel Bourg wrote:
> Le 16/10/2019 à 08:35, Hervé BOUTEMY a écrit :
>> last question: now that we seem to fully understand each other, does it mean 
>> that you don't need any more "seconds since the epoch" format support for 
>> the 
>> property?
> 
> If Maven supports the SOURCE_DATE_EPOCH environment variable I don't
> think that's necessary, otherwise it would be nice to be able to invoke
> Maven with:
> 
>mvn package -Dproject.build.outputTimestamp=$SOURCE_DATE_EPOCH
> 
> and this means supporting a timestamp formatted as seconds since the epoch.

+1

The above would be a nice, simple way of bridging the gap between
SOURCE_DATE_EPOCH and project.build.outputTimestamp.

If it is not too much trouble to implement the "\d+ -> seconds since
epoch" heuristic, them I would love to see it included.

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Re: last review of Reproducible Builds proposal

[Andreas Sewe]

Hi,

Hervé BOUTEMY wrote:
> based on the feedback I got, I updated the proposal:
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318
> 
> The archives entries timestamp is now configured with 
> project.build.outputTimestamp property, in ISO-8601 format
> 
>   
> 
> 2019-10-02T08:04:00Z
>   
> 

nice work, Hervé.

Two comments:

- We already have maven.build.timestamp [1], so I wonder whether it
should be maven.build.outputTimestap, too. Although one may argue that
this *output* timestamp is a property of the project being built, not
the Maven execution (in particular if the property becomes a POM element
in POM version 5).

- Can we get something analogous to maven.build.timestamp.format? One
could then write the following to be compatible with env.SOURCE_DATE_EPOCH:


  

${env.SOURCE_DATE_EPOCH}

...
  


Unfortunately, SimpleDateFormat or its java.time equivalents do not seem
to have a format string for "seconds since the epoch", so we may want to
make "seconds since the epoch" the default for
project.build.outputTimestamp's format and only parse according to
project.build.outputTimestamp.format when that property is indeed set.

WDYT?

Best wishes.

Andreas





signature.asc
Description: OpenPGP digital signature

Re: Build vs Consumer POM study

[Andreas Sewe]

Hi,

as a user of Maven and a researcher analyzing what's in Maven central, I
would prefer to see

  

in the "kept by choice" category as well. While  may be
more useful for end-user facing tools, in this day and age of badges
pointing to CI servers on Github, I can still see this as useful for
consuming tools (or just researchers gathering statistics ;-)

As for

  

I agree with removing
distributionManagement/(repositories|snapshotRepositories) from the
consumer POM, but am left wondering about
distributionManagement/downloadUrl. Alas, from the documentation [1] I
don't quite understand, what downloadUrl means:

> is the url of the repository from whence another POM may point to in order to 
> grab this POM's artifact. In the simplest terms, we told the POM how to 
> upload it (through repository/url), but from where can the public download 
> it? This element answers that question.

But  seems to be directed at "the public" somehow, so
it may be a candidate for the consumer POM.

Hope this helps.

Andreas

[1] 



signature.asc
Description: OpenPGP digital signature

Re: Build vs Consumer POM study

[Andreas Sewe]

Hi,

> Naming Conventions
> consumer pom must continue to be named pom.xml
> build pom shall be called build.xml 

Please don't re-use a name already occupied by another build tool (in
this case, Ant). Many IDEs associate editors based on file name and this
would confuse them. Eclipse, for example, associates "build.xml" with
its Ant Editor.

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Re: main-class + module-version

[Andreas Sewe]

Robert Scholte wrote:
> Plexus Archiver is an archiver fully written in Java, so there has never
> been the need to add toolchain support.
> 
> It would be very nice if this could be solved without the need of the
> external jartool or using it via a ToolProvider[1].

Also, if two separate tools modify the JAR, the goal of reproducible
builds is again a bit harder to accomplish. So, please try to use an
internal, written-in-Java solution if possible.

Just my 2 cents.

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Re: Allowed characters in GAV and how/where to sanitize?

[Andreas Sewe]

Fred Cooke wrote:
> Re versions, I know the background on it, but it annoys me that maven can't
> handle 4 part versions, 1.2.3.4 as sometimes it's handy to do a patch level
> that deep. Lots of messed up software in the world :-)

Are you sure that's still the case (the parts-restriction, not the
messiness of software ;-)?

At least the Maven Resolver uses a versioning scheme that's quite
flexible [1]. Not sure if the flexibility at this low level bubbles up
all the way to the top, though. Maybe one the Maven developers can chime in.

> Format should be N[.N as many times as needed][optional hyphen and
> qualifier of some sort] or something like that. Not hard limited to 1 2 or
> 3 parts.

AFAICT, that's what GenericVersionScheme does.

Hope this helps,

Andreas

[1]




signature.asc
Description: OpenPGP digital signature

Re: Allowed characters in GAV and how/where to sanitize?

[Andreas Sewe]

Hervé BOUTEMY wrote:
> notice that Central contains artifacts produced by Maven but also by other 
> tools: I did some analysis myself and found strange things also that are 
> clearly not produced by Maven. Scala for example produces some artifacts that 
> I doubt could be referenced by Maven.

Yes, Maven is not the only tool that can deploy artifacts to Central --
and that's a good thing.

> Then: what do we call "broken"?
> Something that seems "clearly" related to a typo?
> Something that can't be consumed by Maven?
> Something that people who produced the release (with any tooling) won't 
> consume for syntactic reasons on the result? Something that they won't 
> consume 
> for other reasons? (like for example because it's continuous deployment and 
> it's the 4th version of the day)

I wouldn't go so far to treat version=1.6.2.1 as an illegal version
(after all, I can image someone using legitimately using a qualifier
scheme like 1.2.3-os=linux), but there are IMHO two cases which I always
consider broken:

- Spaces in any of the components of a GAV
- A colon in any of the components of a GAV

Spaces are just likely to cause trouble for some tool further down the line.

And for colons we know that they will cause trouble, being the default
separator for GAVs when written as a single string.

Aside from those characters, I would probably just ban a few characters
(non-printable control characters). A bit similar to what XML did with a
its NCName (non-colon name) production [1].

However, for groudId and artifactId we already have much stricter rules
(A-Z, a-z, 0-9, ., -, _), so the argument can be made that
versions/classifiers/extensions should also be made up of a more limited
character set as well.

In particular, care should to be taken that the path component can still
be parsed unambiguously, so allowing '.' in a classifier is probably
asking for trouble.

> And what can we do?
> On the past artifacts, removing anything is not really an option: IMHO, the 
> issue does not deserve the effort and to break our base rule about 
> inalterability.
> On the future, perhaps we can do something:
> - at Maven level, sure we can and we should improve controls as much as 
> possible

Yes, if only that at this level we can provide the best error messages,
as the error is recognized closest to the user.

> - on other build tools: perhaps we should try not only to implement checks in 
> Maven but also document rules for other tools to implement same rules

The Maven Resolver is a great place to enforce some rules in
DefaultArtifact (or whatever replaces it). Granted, not everyone deploys
using the Maven Resolver, but its *the* place that knows about all the
intricacies of the repository layout already.

> - on repo managers used by the publishers: same rules documentation 
> prerequisite, but other tools target

Well, Nexus already has some checks in place, to avoid versions like
"1/../../other-artifact/2". However, groupIds like "org...example" are
still accepted (deployed under org/example).

> - on sync to central: this is the only location where some rules can be 
> checked for absolutely any new artifact then really interesting at a first 
> glance. But making rules evolve at this level is really hard since there is 
> no 
> real feedback process I know of when base Central publication rules are not 
> met. Base Central publication rules were defined from the beginning 
> (signature, 
> ...), then are implemented by publishers' repo managers. I suppose failed 
> controls done by sync to central (then sync blocked) are rare: I'm not sure 
> there is a strong process/tooling. And adding it would cost some management: 
> not easy. IMHO, we should start by first detecting if there are really issues 
> on new artifacts these days before trying to take actions at this level.

That being said, I think the first step is to document the syntax for
GAVs somewhere (e.g., at [2] or [3]).

Best wishes,

Andreas

[1] 
[2] 
[3] 




signature.asc
Description: OpenPGP digital signature

Re: Allowed characters in GAV and how/where to sanitize?

[Andreas Sewe]

Hi Stephen,

> In an url path segment space is mapped to +

not quite. This holds only for the query part of an URI which is
typically encoding according to the application/x-www-form-urlencoded
scheme. Elsewhere in a URI, e.g., the path component, a space is simply
percent-encoded a %20.

> The repo manager should be blocking those... likely not doing it’s job.

I agree. IMHO the repo manager should block (if only as a last resort
for people using something to deploy that doesn't do the check earlier).

That being said, the situation on Maven Central is not that dire; there
are very few versions in the wild that I consider broken:

Additional quotes:

- "1.0.0
- '1.0'

CLI trouble:

- mvn+release:perform
- version=1.6.2.1

Commas instead of dots as separator

- 1,0

Expressions or expression-like constructs:

- ${env.VERSION}
- ${parent.version}
- @metro.version@
- $%7Bcucumber-jvm.version%7D

If you are interested, I have a more complete list (about 30 entries
overall), together with a histogram of characters used in versions.
Interestingly, no non-ASCII characters are used, not even in qualifiers.

> We probably should also barf on : in a version. There is validation on
> artifactId and groupId when last I checked

Different validators barf on different things. The
org.apache.maven.*project*.validation.DefaultModelValidator used by
deploy:deploy-file is happy with *any* non-empty version, whereas
org.apache.maven.*model*.validation.DefaultModelValidator does a bit
more; in particular, it checks for certain filesystem-unsafe characters,
including the colon: \ / : " < > | ? *

I don't really know why deploy:deploy-file prefers one ModelValidator
over the other, though. Is this a bug in the the maven-deploy-plugin?

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Allowed characters in GAV and how/where to sanitize?

[Andreas Sewe]

Hi Maven developers,

doing a large-scale analysis of Maven Central, I've come across a couple
of "weird" GAVs like this one: groupId=com.knappsack,
artifactId=swagger4spring-web, version=mvn+release:perform [1].

The colon in the version raises the question as to the allowed
characters in the different components of a GAV. AFAICT, a colon in the
version is at least rejected by the
org.eclipse.aether.artifact.DefaultArtifact(String) constructor, so that
seems to be illegal, but DefaultModelValidator doesn't complain. Also,
querying the index of Central returns an
org.apache.maven.index.ArtifactInfo with a version of
"mvn+release:perform" just fine.

What's the best way to handle this?

Should every plug-in that consumes, say, a Maven Index sanitize the results?

Or should this be handled upstream in the repository manager? (Note that
the POM of [1] has a  of "mvn release:perform", but the
ArtifactInfo's version is "mvn+release:perform", so some sanitation has
already happened somewhere, probably in Nexus.)

Best wishes,

Andreas

[1]




signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Maven Indexer 6.0.0

[Andreas Sewe]

Olivier Lamy wrote:
> probably no issues for sure.
> I just don't know if we will be able to still download the index from
> central and use it with this new version
> TBH I haven't done any testing etc so it's just questions :-)

FYI, my testing included downloading the index from Central (to be
precise: its uk.maven.org mirror) with the staged Indexer 6.0.0. So, the
current code its able to consume the index currently produced for
Central, presumably by Indexer 5.x.

Hope that helps.

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Maven Indexer 6.0.0

[Andreas Sewe]

Tamás Cservenák wrote:
> [VOTE] Release Maven Indexer 6.0.0

Tested this in two applications: a Maven plugin and a Spring
application. In both cases, I experienced no trouble.

Thanks for doing the release, Tamás.

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Re: Dependency scopes and conflict resolution: Possible bug?

[Andreas Sewe]

Jonathan Haber wrote:
> As a workaround you can check out the dependency-scope-maven-plugin we
> wrote:
> https://github.com/HubSpot/dependency-scope-maven-plugin

Thanks for the pointer; this indeed looks like a useful plugin.

That being said, I wasn't experiencing this bug/misfeature myself.
Rather, I'm simply trying to understand how Maven works in this
corner-case to ensure that a research project of mine, a large scale
analysis of third-party projects, has correct input data (classpaths).

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Re: Dependency scopes and conflict resolution: Possible bug?

[Andreas Sewe]

Robert Scholte wrote:
> You're hitting MNG-5739
> 
> Within a dependency-tree a groupId+artifactId is unique (nearest wins).
> Such a dependency has 1 version, but also 1 scope.
> By setting it explicit to test, you reduce the scope and it is not
> available during compile anymore.
> 
> Is this correct?

Yes, this is what I observe.

> Well, this concept ensures that you test with exactly the same set of
> dependencies as the ones available at runtime.

That's a reasonable goal; you wouldn't want to use different versions
between in compile and test classpath.

> On the other hand, reducing the scope implies that you'll be missing one
> or more dependencies at runtime.
> 
> We could think of making dependencies *always* scope-context-aware.
> Using your case one could suggest that at compile-time hamcrest-core:1.1
> is used, but at test-time hamcrest-core:1.2

I don't think that's a good solution, as it misses the goal of using the
*same* version of a library in compile and test classpaths.

IMHO, the better solution would be if the direct, test-scoped
hamcrest-core:1.2 dependency promoted the transitive, compile-scoped
hamcrest-core:1.1 to version 1.2 -- even if it itself were excluded from
the compile classpath.

Granted, this would mean that one part of the dependency graph overrides
versions in another part of the graph, which seems unexpected, but with
dependencies being "omitted for conflict" we already have something similar.

> To me this makes more sense, but at the same time it is hard to predict
> the impact of such a change.

That being said, I can understand when you don't want to change this
behavior, as that would potentially change the meaning of existing POMs.
However, it would only *add* compile-scoped dependencies that weren't
there previously, so I think the change wouldn't break anything but
merely add dependencies to the classpath that logically should have been
there all along -- but whose absence just didn't cause any compilation
or runtime error.

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Dependency scopes and conflict resolution: Possible bug?

[Andreas Sewe]

Hi Maven developers,

I a trying to wrap my head around Maven's handling of dependency scopes
and was wondering the following: Is the test-classpath always a
super-sequence of the compile-classpath?

AFAICT, this is the case. However, my experiments (using Maven 3.5.2)
left me wondering whether I may have stumbled upon a bug.

My (somewhat contrived) scenario is this:

>   
> 
>   junit
>   junit
>   4.9
>   compile
>   
> 
> 
>   org.hamcrest
>   hamcrest-core
>   1.2
>   test
> 
>   

The *test* classpath that compiler:testCompile sees is junit:junit:4.9 +
org.hamcrest:hamcrest-core:1.2. This is as expected, as the direct
hamcrest-core dependency beats the transitive one; hence, version 1.2
gets picked.

Now, the *compile* classpath that compile:compile sees is just
junit:junit:4.9. While this affirms my super-sequence hypothesis, it
seems like a bug: Without the direct, test-scoped
org.hamcrest:hamcrest-core:1.2 dependency the compile classpath would
have been junit:junit:4.9 + org.hamcrest:hamcrest-core:1.1, but with it
hamcrest-core has vanished completely.

Do you consider this a bug as well?

If so, what's the desired behavior here?

1. A compile classpath of junit:junit:4.9 +
org.hamcrest:hamcrest-core:1.1 would be confusing, as the super-sequence
assumption seems very natural.

2. But a compile classpath of junit:junit:4.9 +
org.hamcrest:hamcrest-core:1.2 seems harder to implement (to my as a
maven-resolver layman, at least), because a pruned part of the
dependency graph may now still exert influence on the versions in other
parts of the graph.

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Re: Thoughts on MR-Jar support in Maven

[Andreas Sewe]

Hi,

> I would have thought that it was not Maven's responsibility to ascertain
> that test passed in various JDKs, old and new.

I agree that is is not Maven's responsibility to (out of the box)
execute the tests against multiple JREs. If you think it is, one can
just as well argue that it should run tests for OSGi bundles built with
Maven using all different permutations that the bundle's Import-Package
version ranges allow.

Yes, there are projects where that level of double-checking is
warranted, but IMHO this is the domain of Jenkins matrix projects or
similar mechanisms.

The bigger issue with the "multiple source folder per project" approach
is whether popular IDEs can express the fact that src/main/java needs to
be compiled against one JRE whereas src/main/java-9 needs to be compiled
against another.

Just my two cents.

Andreas



signature.asc
Description: OpenPGP digital signature

Re: [EXTERNAL] [ANN] Apache Maven Version 3.5.0-alpha-1 Released

[Andreas Sewe]

Hi,

> Any chance the Aether work would somehow enable declaring server credentials 
> only once in settings.xml and then reusing them for multiple 
> build.repositories.repository nodes in pom.xml (such as when you have 
> multiple independent repositories within the same authentication realm of a 
> single host)? 

FYI, Eclipse Tycho has recently (version 1.0.0) introduced a similar
feature for sharing mirror settings for multiple repositories [1]. As
the above feature request is similar (sharing settings for multiple
repositories), the configuration syntax chosen by the Tycho developers
(treating a URI repository/id specially) may serve as inspiration.

Hope this helps,

Andreas

[1]




signature.asc
Description: OpenPGP digital signature

Re: Some thoughts on Maven 5

[Andreas Sewe]

Stephen Connolly wrote:
> * we should let the user define lifecycles directly in the Pom (ok, maybe we 
> don't *encourage it*)

More packaging-related phases in the default lifecycle.

I very much like the idea of a standard lifecycle, as it often forces
you to rethink your project's structure. (me: "Why can't I have two
compile phases in the same build, on compiling the code generator and
one compiling the generated code?" Maven: "Because this is not Ant and
you really have two different projects." me: "Of course; makes much more
sense!").

Alas, the current default lifecycle doesn't cope well with builds that
need to selectively (profiles) sign and pack200 their artifacts. See [1]
for an example where the exact declaration order in the POM matters
(which it really shouldn't), just because there are no suitable phases
after "package".

Best wishes,

Andreas

[1] 




signature.asc
Description: OpenPGP digital signature

Re: Some thoughts on Maven 5

[Andreas Sewe]

Stephen Connolly wrote:
> So now that I have a spec for the PDTs drafted, I have been thinking of how 
> that could influence Maven 5. Some things that came to mind, in no particular 
> order:

May I suggest support for custom "transformation rules" when inheriting
a value from the parent POM. Have a look at what I outlined in MNG-5951 [1].

The current solution for project/src/url, project/scm/connection, etc.
[2] is horrible:

1.) Having to define attributes like
@child.scm.developerConnection.inherit.append.path on the parent rather
than the child element they apply to leads to ridiculously long
attribute names, but had to be done to avoid changing the Modello model
[3]. Placing those on the element they actually refer to would avoid any
ambiguity.

2.) Attributes like @child.scm.developerConnection.inherit.append.path
solve special cases for special elements. IMHO, there should be a
generic and customizable way to describe how a POM's values are inherited.

Just my 2 cents,

Andreas

[1]

[2] 
[3]




signature.asc
Description: OpenPGP digital signature

Re: Some thoughts on Maven 5

[Andreas Sewe]

Stephen Connolly wrote:
> https://hjson.org/ was what I had in mind... but it would be awesome if for
> dependencies we didn't have to quote, e.g.
> 
> scopes {
>   compile: [
> org.slf4j:slf4j-api::1.8.0::jar
>   ]
>   test: [
> junit:junit::4.12::jar
>   ]
> }
> 
> which is not valid hjson as in hjson you would have to write
> 
> scopes {
>   compile: [
> "org.slf4j:slf4j-api::1.8.0::jar"
>   ]
>   test: [
> "junit:junit::4.12::jar"
>   ]
> }

Personally, I still like XML better (Schema-based editing support out of
the box :-), although the current POM 4.0.0 format with its almost
exclusive use of elements over attributes consumes too much vertical space.

Best wishes,

Andreas




signature.asc
Description: OpenPGP digital signature

Re: Some thoughts on Maven 5

[Andreas Sewe]

Stephen Connolly wrote:
> Hmmm shower thinking now has me pondering if a custom DSL might be
> better... something close to human friendly JSON with exceptions for
> dependency declaration so that they are always specified as g:a:p:v:c:t
> with the optional p and c being empty, e.g. g:a::v::t

For me, human-friendly would mean "allows comments", which is something
that plain JSON doesn't have but XML has (and which I use a lot in my POMs).

Just something to think about.

Best wishes,

Andreas




signature.asc
Description: OpenPGP digital signature

Re: Project Dependency Trees schema...

[Andreas Sewe]

Stephen Connolly wrote:
> I am toying with having the format be xml.gz rather than xml

> OTOH transport GZ should be easy and makes the file easier for users > to 
> inspect
> 
> Thought?

If you mean by "transport GZ", serving the XML with "Content-Encoding:
gzip" by the repository manager, than that is IMHO the way to go, as it
allows to transparently transition to another (better) compression
scheme later (e.g., Content-Encoding: br).

The experience with Eclipse p2 update sites, whose
(content|artifacts).xml can also be served as .jar and nowadays also as
.xml.xz shows that is cumbersome to generate the same metadata in
different compression formats for newer and legacy clients. But this
experience also shows that the ability to transition to a better
compression format is something that is indeed desirable, as newer
formats may offer real-world benefits (~50% savings in download size).
See [1] for details.

Just my 2 cents,

Andreas

[1] 



signature.asc
Description: OpenPGP digital signature

Re: [DISCUSSION] finishing Aether import: help find a new name

[Andreas Sewe]

Jason van Zyl wrote:
> It’s all Maven specific, it’s always been Maven specific and that’s
> unlikely to change after how many years? Even if it can employ
> different strategies it’s still the Maven Artifact Resolution API. No
> one is going to use this API to resolve from NuGet, NPMJS, PyPi or
> anything else. Let’s just make it better for our specific use cases
> instead of imagining this is going to be a general purpose tool. It
> is clear that this never happened and probably never will.

I think the confusion stems from the fact that there is both Maven (the
tool) and the Maven repository format (the combination of directory
structure, maven-metadata.xml, checksums files, etc.).

The API we are talking about is for the Maven repository format and not
some other repository format (like p2, NuGet, ...). It may be used by
Maven *and* other tools (like Gradle, sbt, ...). In that sense, it is
*not* specific to the Maven tool, but it is specific to the Maven
repository format. Hence, calling it something with Maven in the name
makes sense to me.

FWIW, we (the Eclipse Code Recommenders project) have been using (first
Sonatype, then Eclipse) Aether since ~2010 to download recommendation
models stored in a repository which does follow the Maven repository
format, but which does not store your typical artifacts (JARs with
pom.xml). If that use case is still supported by the new API, I really
don't care how the API is called. ;-)

Best wishes,

Andreas

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

Re: Maven Server matching

[Andreas Sewe]

Hi,

> 1. Running several *different* flavours of SCMs on the same host. Say you 
> have a host called "repohost" which is both an SVN and a Git host. Ok, not 
> very likely, but alas not something possible today.

FYI, Github does just that. In particular, they support "git clone" and
"svn checkout" under the same *URI*
(), not just the same host.

Best wishes,

Andreas

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

Re: Resolving properties in published poms

[Andreas Sewe]

Hi Mark,

> Is there anyway in current maven (3.3.9) that I can replace the
> |DefaultDependencyCollector| with one of my own, that can use
> maven-filtering and demangle the versions as appropriate? Can I register
> a replacement in my |META-INF/plexus/components.xml| file for my
> lifecycle extension at all?

even if there is (I've no clue), what about all the consumers of your
artifacts? They will fetch you POMs from a Maven repository and have no
idea where to get the dependencies from, as *they* use the
DefaultDependencyCollector. But maybe the flatten-maven-plugin can help
in such cases, so that you use you "magic" properties only during the
build but the published POMs have all properties replaced.

Best wishes,

Andreas


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

Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

[Andreas Sewe]

Hi,

>> FYI, Hudson 3.2.2 (in use for most builds at the Eclipse Foundation)
>> does use the mvn script:

BTW, this is the same with the latest Hudson (version 3.3.3) as well, so
this seems to be a place where it diverged from Jenkins.

>>> [INFO] Using Maven 3 installation: apache-maven-latest
>>> [INFO] Checking Maven 3 installation environment
>>> [JavaSE-1.8] $ /shared/common/apache-maven-latest/bin/mvn --help
>>> [INFO] Checking Maven 3 installation version
>>> [INFO] Detected Maven 3 installation version: 3.3.9
>>> [JavaSE-1.8] $ /shared/common/apache-maven-latest/bin/mvn ...
>>> [DEBUG] Waiting for connection on port: 52641
>>> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
>>> 2015-11-10T11:41:47-05:00)
>>> Maven home: /shared/common/apache-maven-latest
>>> Java version: 1.8.0_51, vendor: Oracle Corporation
>>> Java home: /opt/public/common/jdk1.8.0_51.x64/jre
>>> Default locale: en_US, platform encoding: UTF-8
>>> OS name: "linux", version: "3.0.101-0.47.71-default", arch: "amd64",
>>> family: "unix"
> 
> Ah ok, what about JAVA_HOME? Set or from PATH?

I am not the admin of our Hudson instance (it's managed by the Eclipse
Foundation), but I think JAVA_HOME is set. See [1] for the intricacies
of our project's particular setup.

That being said, we specifically requested a change to the setup; I
don't know what Hudson instances at Eclipse do by *default*; AFAIK, they
just use the Java install Hudson runs on, but if Hudson itself requires
JAVA_HOME to be set or if it also allows for Java to be autodiscovered I
don't know.

Hope this helps.

Andreas

[1] 

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

Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

[Andreas Sewe]

Hi,

> Please go ahead and test it.
> 
> Jenkins does not use the script as it seems:
> [maven-3.x] $
> /home/jenkins/jenkins-slave/tools/hudson.model.JDK/jdk-1.7u51/bin/java
> -Xmx2g -Xms256m -XX:MaxPermSize=512m -cp
> /home/jenkins/jenkins-slave/maven3-agent.jar:/home/jenkins/jenkins-slave/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.0.5/boot/plexus-classworlds-2.4.jar
> org.jvnet.hudson.maven3.agent.Maven3Main
> /home/jenkins/jenkins-slave/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.0.5
> /home/jenkins/jenkins-slave/slave.jar
> /home/jenkins/jenkins-slave/maven3-interceptor.jar
> /home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 36465

FYI, Hudson 3.2.2 (in use for most builds at the Eclipse Foundation)
does use the mvn script:

> [INFO] Using Maven 3 installation: apache-maven-latest
> [INFO] Checking Maven 3 installation environment
> [JavaSE-1.8] $ /shared/common/apache-maven-latest/bin/mvn --help
> [INFO] Checking Maven 3 installation version
> [INFO] Detected Maven 3 installation version: 3.3.9
> [JavaSE-1.8] $ /shared/common/apache-maven-latest/bin/mvn ...
> [DEBUG] Waiting for connection on port: 52641
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-10T11:41:47-05:00)
> Maven home: /shared/common/apache-maven-latest
> Java version: 1.8.0_51, vendor: Oracle Corporation
> Java home: /opt/public/common/jdk1.8.0_51.x64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.0.101-0.47.71-default", arch: "amd64", family: 
> "unix"

Hope that helps.

Andreas

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

Re: [DISCUSS] SCM child-project URL composition

[Andreas Sewe]

Hi,

here's a use case/convention which neither the current "append child's 
artifactId" strategy nor the "static:" prefix can handle.


The parent project uses something like

  /scm-root/

and the modules/children use

 /scm-root/modules/${project.artifactId}

IMHO, the only fully flexible solution is to have an *absolute* URI 
which is used for the current project and an extra attribute which 
specifies the *relative* URI to be appended by child projects.


This extra attribute would simply default to "./${project.artifactId}", 
thereby making the "append child's artifactId" strategy explicit. The 
"static" use case could then be handled by a value of 
"../${project.artifactId}".


Of course, this relies on SCM providers properly handling path 
components like "." and "..". Also, when property expansion happens 
needs to be hashed out. (I think, the parent's relative path attribute 
should be expanded in the child's context.)


But while the above convention is maybe not a common case in SCM URIs, 
the relations between  parent and child *site* URIs (which currently 
also use the "append child's artifactId" strategy) are more diverse, 
which I think warrants thinking about a flexible solution.


Just my $0.02.

Andreas

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

Re: SCM info and modules

[Andreas Sewe]

Hi,


I'm not 100% sure it should be inherited at all. Inheriting unchanged is
only valid for something like Git, but probably never for SVN. However,
as you point out, Maven's current guess is usually not good enough either.


the problem is really that Maven currently has only a single element for 
something that requires two: one containing an absolute path to the 
current project's SCM, and one containing the relative path used to move 
from the aggregator's SCM to the child's.


Just my $0.02.

Andreas

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

Re: peri

[Andreas Sewe]

Hi all.

As a side-note: the current "provided" scope is not transitive, which 
IMHO doesn't make much sense. After all, if your environment magically 
provides dependency A that assures you that it also provides dependency 
B, then this should effectively mean that both A and B are provided. Or 
am I missing something?


Having a scope that's like "provided" but is transitive would be a 
usefully addition to the current list of scopes.


FWIW, a plugin I wrote to bundle up Java benchmarks (as JARs within 
JARs) would benefit from this. See 
 
for a description of how "provided" is currently used.


Best wishes,

Andreas

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

Re: Legitimate use of ToolchainManagerPrivate?

[Andreas Sewe]

Hi all,

sorry it took so long to reply, but here are my findings:

> I remember when I was writing that plugin I found a couple of use cases
for
> tool chains that the initial spec had missed... there could be some hack
I'm
> doing... also are you using maven 2 or 3.

I am using Maven 3; while animal-sniffer:check works just fine,
animal-sniffer:build has problems. :-(

> I have not tested animal-sniffer-maven-plugin for generating signatures
with
> maven 3 so it might be that it only works in 2.0.10-2.2.1

Yes, it looks like that is the case: when asking explicitly for a toolchain
in the plugin's configuration, I get the following error:

[ERROR] Failed to execute goal
org.codehaus.mojo:animal-sniffer-maven-plugin:1.6:build (build) on project
test: Incompatible toolchain API:
org.apache.maven.toolchain.DefaultToolchainManager.getToolchainsForType(java.lang.String)
-> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.6:build (build) on
project test: Incompatible toolchain API
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:534)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoExecutionException: Incompatible
toolchain API
at
org.codehaus.mojo.animal_sniffer.maven.BuildSignaturesMojo.getToolchains(BuildSignaturesMojo.java:686)
at
org.codehaus.mojo.animal_sniffer.maven.BuildSignaturesMojo.getToolchainFromConfiguration(BuildSignaturesMojo.java:637)
at
org.codehaus.mojo.animal_sniffer.maven.BuildSignaturesMojo.getToolchain(BuildSignaturesMojo.java:600)
at
org.codehaus.mojo.animal_sniffer.maven.BuildSignaturesMojo.execute(BuildSignaturesMojo.java:286)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: java.lang.NoSuchMethodException:
org.apache.maven.toolchain.DefaultToolchainManager.getToolchainsForType(java.lang.String)
at java.lang.Class.getMethod(Class.java:1605)
at
org.codehaus.mojo.animal_sniffer.maven.BuildSignaturesMojo.getToolchains(BuildSignaturesMojo.java:679)
... 24 more

This is due to the fact that an instance of class
org.apache.maven.toolchain.DefaultToolchainManager is injected into the
ToolchainManager @component, which is not a ToolchainManagerPrivate. So it
looks like one has to explicitly request a ToolchainManagerPrivate
@component; just asking for a ToolchainManager does not get one a
ToolchainManagerPrivate.

That being said, I found the "jdk"-type toolchains lacking some information
for my purpose. You only get the jdkHome, but not, e.g., JVM arguments
(like -client or -server). This way is it quite hard to run you tests on
different JVM configurations, as all you get is just the paths to the
"java" executables. :-(

So I am switching back to a single toolchain (obtained via
ToolchainManager) for now.

Best wishes,

Andreas


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

Re: Legitimate use of ToolchainManagerPrivate?

[Andreas Sewe]

Hi all,

> OK, now I get it. Thanks. I'll have a look at the code and come back if 
> I still have some questions.

I did have a look a the animal-sniffer-maven-plugin. Very interesting.

One thing that I do not understand, however, is how to obtain access to an
implementation of ToolchainManagerPrivate (besides @component
ToolchainManagerPrivate). As far as I can see, the plugin only declares a
dependency on the ToolchainManager (w/o Private) component.

  /**
   * @component
   */
  private ToolchainManager toolchainManager;

Still, the plugin later on continues to call
toolchainManager.getClass().getMethod("getToolchainsForType", String.class,
MavenSession.class), a call which can only succeed (instead of throwing a
NoSuchMethodException) if the toolchainManager component actually
implements ToolchainManagerPrivate instead of only ToolchainManager.

If I do the above in my own code, however, toolchainManager is of class
DefaultToolchainManager instead of DefaultToolchainManagerPrivate. So why
does it work in the BuildSignaturesMojo? What am I missing?

Best wishes,

Andreas


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

Re: Legitimate use of ToolchainManagerPrivate?

[Andreas Sewe]

Hi Stephen, hi Jörg,


yep the code. there's some advanced use of tool chains in animal sniffer...
no other plugin that I know of is as advanced in using tool chains


OK, now I get it. Thanks. I'll have a look at the code and come back if 
I still have some questions.


Best wishes,

Andreas

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

Re: Legitimate use of ToolchainManagerPrivate?

[Andreas Sewe]

Hi Stephen,


have a look at animal sniffer @mojo


the animal-sniffer-maven-plugin is definitely a very useful plugin, but 
just not for my use case; what I want is to verify that the benchmark 
being build *behaves* the same on different JVMs (produces identical 
outputs, doesn't crash the JVM). Simply conforming to an API standard 
unfortunately does not guarantee this. (This is exemplified very well by 
the sanity run results of a popular research benchmark suite: 
.)


I hope this clarifies things a bit.

Andreas

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

Legitimate use of ToolchainManagerPrivate?

[Andreas Sewe]

Hi all,

I am using Maven to build benchmarks for JVM research. I have already 
written a plugin that bundles up the benchmarks harness, dependencies, 
and input data. This works like a charm. :-)


To integration-test the benchmarks, I would like my plugin to run 
benchmark just build on a whole range of JVMs. To this end, Maven's 
toolchain support seems like a perfect fit. Alas, the 
maven-toolchain-plugin can configure only one toolchain of a given type 
and the ToolchainManager only gives me access to a single "jdk" type 
toolchain. What I want, instead, is to retrieve a list of all "jdk" type 
toolchains matching some requirements from my plugin's configuration.


This can be done by using ToolchainManagerPrivate (and duplicating some 
functionality of the maven-toolchain-plugin), but 
ToolchainManagerPrivate doesn't look like its intended to be used that 
way. Is there are better one?


Best wishes,

Andreas


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