Re: [DISCUSS] Removal of ineffective switch for Maven 4

[Bernd Eckenfels]

>> My idea would then be to see if any of these four are used in our own 
>> code base (core as well as plugins). If there are usages, let's remove 
>> them. That should not be hard, as they don't trigger any behaviour 
>> anymore. After that, we can continue to drop them from the Maven CLI.
>> 
>> Would that make sense?
> 
> That would make sense.

If the investigation takes longer, you can
at least remove them from usage output
I had glanced over those options more
often than I like, just to learn they are
Ineffective,

Gruß
Bernd
— 
https://bernd.eckenfels.net

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

Re: [VOTE] Require Java 17 for Maven 4

[Bernd Eckenfels]

+1 (non-binding), even better Java 21+

Benjamin Marwell wrote on 28. Feb 2024 08:30 (GMT +01:00):

> Hi Maven Devs/Users/Committers and PMC members!
> 
> After several discussions on the mailing lists, I would like to
> start a vote in favour of setting the minimal Java bytecode target
> of Maven-Core 4 to 17 and hence require Java 17 for Maven 4.

Gruß
Bernd
— 
https://bernd.eckenfels.net

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

Re: [DISCUSS] Java version for Maven

[Bernd Eckenfels]

It has been mentioned before, but just to add, since the bytecode
level is IMHO the smallest problem:

Jorge Solórzano wrote on 25. Feb 2024 00:41 (GMT +01:00):
> you can use JDK 17 to produce Java 8 bytecode using Java 8
> features, that is the distinction I made between runtime and build time,
> but it looks it's still not clear.

In the past a newer JDK version could compile for an older Bytecode version and
compatible with the source code constructs, BUT it used its own classlibrary 
which
had usually different method and therefore create NON-compat results. For that
reason you had to provide the old bootpath if you wanted a clean build (or, 
since this
Is nearly the same work than just using the old JDK always use the same 
build/target
Version, this was very typical for java7 builds and many think it is needed for 
8 as well).

But, this is no longer a problem since Java9, the new -release option does not 
only simplify
-source and -target into a single option it additionally makes the Java 
compiler use an
internal list of approved JCL signatures, therefore being save for cross 
compile (only
If you switch to the new flag).

Unfortunatelly -release 8 has still problems with removed libraries, so it is a 
bit of a
work to use newer JDKs to compile old codebase (not a drop-in in some cases 
like jaxb).

Btw Java8 POMs are a bit annoying since you can’t build them on Java 8
With maven.compiler.release and you can’t (should not) build them on 9+ with
maven.compiler.target. Luckily you can solve that with a profile activated by 
runtime version.
https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-release.html

Gruß
Bernd
— 
https://bernd.eckenfels.net

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

Re: [DISCUSS] Java version for Maven

[Bernd Eckenfels]

Hello,

thanks Jorge I fully support your summary.

 want to bring an additional points in support for newer runtime Java: Because 
Maven alone isn’t the complete ecosystem and many other tools have higher 
requirements already. Fr example both Jenkins (maven-style jobs) as well as 
SonarQube scanner plugins can’t be used with Java 8 anymore.

And yes such a shift was not only for those big tech-Gigants which are stuck on 
Java8 a pain, but also for many other users - but this is in the past. Most 
have migrated to be finally able to use the -release option as a quality of 
life improvement even though they have to target Java 8 Bytecode level.

I think there is absolutely no problem to move along with a new major version 
of maven, in fact it’s the only sane moment to do so. I am sure many plug-in 
authors are eager to raise their minimum version just to be able to use new 
external technologies. And if the whole ecosystem understands there is a 3.d 
and 4.x branch, the better…

Gruss
Bernd

Jorge Solórzano wrote on 24. Feb 2024 23:42 (GMT +01:00):

> Hi Maven Developers,
> 
> A lot has been told already from both sides, but please, please, let's
> focus on how to improve the current status and define how and what Java
> version will be required for Maven, not on trivial discussions about using
> var or virtual threads.
— 
https://bernd.eckenfels.net

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

Re: [DISCUSS] Usage of Maven Changes Plugin/Reduction of Features

[Bernd Eckenfels]

The Apache Commons Project Sites use the jira integration, the plugin works in 
principle, but does not support paging.

https://commons.apache.org/proper/commons-vfs/jira-report.html

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Michael Osipov 
Gesendet: Sunday, August 14, 2022 5:41:29 PM
An: Maven Developers List 
Betreff: [DISCUSS] Usage of Maven Changes Plugin/Reduction of Features

Guys,

does anyone of you use the extended features of MCHANGES besides the
changes.xml to HTML generation, e.g., messaging, JIRA report, Trac report?
I'd like to make it savvy for Doxia 2.0.0 and proper generation, but I
am not willing to keep the luggage of the mentioned additional features
because of:
* I don't know they do work or not work,
* the setup and testing effort of third party systems
* supporting commercial products I don't have access to.

My rough plan would be:
* Deprecate all of those in M1
* Remove all of those in M2
* Review plugin and update remaining deps in M2
* Look at open issues for M3

Personally, I have never used the messaging feature and for JIRA, et al.
I rather provide a link than duplicating the data.

Let me know what you think otherwise this plugin will not survive the
Doxia 2.0.0 stack migration.

Michael

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

Re: [VOTE] Release Maven Site Plugin version 4.0.0-M1

[Bernd Eckenfels]

BTW it would probably be good to explain the relation with other maven 4 
projects, just to not confuse people with the major number. Like can it be used 
(only) with maven 3 and so on.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Romain Manni-Bucau 
Gesendet: Saturday, April 30, 2022 7:38:34 AM
An: Maven Developers List 
Betreff: Re: [VOTE] Release Maven Site Plugin version 4.0.0-M1

+1

Le sam. 30 avr. 2022 à 07:32, Hervé BOUTEMY  a
écrit :

> +1
>
> Reproducible Build ok: reference done with Java 8 on Windows
>
> regards,
>
> Hervé
>
> Le mercredi 27 avril 2022, 23:25:36 CEST Michael Osipov a écrit :
> > Hi,
> >
> > We solved 6 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317923
> > rsion=12351657
> >
> > There are still a couple of issues left in JIRA:
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSITE%20AND%20res
> > olution%20%3D%20Unresolved
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1748/
> >
> https://repository.apache.org/content/repositories/maven-1748/org/apache/mav
> >
> en/plugins/maven-site-plugin/4.0.0-M1/maven-site-plugin-4.0.0-M1-source-rele
> > ase.zip
> >
> > Source release checksum(s):
> > maven-site-plugin-4.0.0-M1-source-release.zip
> > sha512:
> >
> 170fcefd12099f4b527b3ad9bc94098b1ee0cab7788982dfebfa69097f24746f847a6e18
> > 1dfaab3caa54f508f13994195fa44c64fe1deef66ddb723fe852
> >
> > Staging site:
> > https://maven.apache.org/plugins-archives/maven-site-plugin-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > -
> > 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: [DISCUSS] Radical Fast Forward to 3.5.4

[Bernd Eckenfels]

Hello,

I really think no sane developer should use stable distributions like EL or 
Debian für Java/Maven toolchains. But if they do, they do know they have old 
software and their vendor will do the maintenance. I would not be concerned 
with that (besides maybe clearly communicating EOLs, minimum versions and 
requirements). Of course you could try to negotiate with the biggest 
distributions on a common ground, but that will mean more versions than today 
(not less) - so why waste your cycles…

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Jorge Solórzano 
Gesendet: Monday, March 14, 2022 4:31:35 PM
An: Maven Developers List 
Betreff: Re: [DISCUSS] Radical Fast Forward to 3.5.4

FYI, it looks like RHEL-based 7 uses maven 3.0.5, RHEL-based 8 uses
3.5.4 and 3.6.3.

My guess is that even if the new upgraded plugins depend on Maven
3.5.4 it wouldn't cause major issues as if anyone is using an olver
Maven version they will likely use older versions of the
plugins/components.

Anyway, as Hervé mentioned, there is a lack of better documentation of
the compatibility of plugins, and based on this page
https://maven.apache.org/developers/compatibility-plan.html since Jun
2020, plugins can have Java 8 prerequisite, and even for Maven 3.8.x
that means a breaking change.


On Mon, Mar 14, 2022 at 3:40 PM Elliotte Rusty Harold
 wrote:
>
> FYI Debian Stable is at 3.6.3 as is Ubuntu. Homebrew is at 3.8. I've
> only checked the websites for this, not tried to install from there.
> However neither looks like a blocker.
>
> What other package managers should we check? What does Red Hat use? Windows?
>
> Also, are there any older versions of OS's likely to be in use that
> have older package managers?
>
>
>
> On Sun, Mar 13, 2022 at 7:57 PM Elliotte Rusty Harold
>  wrote:
> >
> > What do all the various package managers install? I'm pretty sure I've
> > seen one lately whose default was 3.3.1. Debian perhaps?
> >
> > I think before we make any such move it would make sense to audit what
> > people who don't manually install Maven are likely to have. First we
> > should raise all those to 3.5.4 or later. Then we can upgrade the
> > minimum version.
> >
> > Even more ambitiously, perhaps we should rethink how maven is
> > installed. Why should it come from anywhere but Maven Central, and why
> > can't a pom.xml specify the version of Maven itself? All we really
> > should install is a very simple bootstrap script. But that's probably
> > a discussion for another day. Let's get the package managers
> > straightened out first.
> >
> > On Sun, Mar 13, 2022 at 11:48 AM Michael Osipov  wrote:
> > >
> > > Folks,
> > >
> > > as you might now we are dragging old luggage over and over with every
> > > new year. We are making (little) progress with cleansing, skimming and
> > > updating of our components.
> > >
> > > I'll will make a radical proposal I have already discussed privately
> > > with other fellow committers over Slack:
> > > Raise the entire baseline to Maven 3.5.4, all of our raises have been
> > > intermediaries. Reasoning:
> > > * Maven 3.5.4 is almost 4 old, it is settled
> > > * Everything before we shouls consider ancient, if you haven't moved
> > > yet, you will not and it will be your problem.
> > > * It is the first version which uses Maven Resolver [1]
> > > * It will free resources to test with previous releases which most don't
> > > do anyway
> > > * Maybe this will make it even easier to migrate to the upcoming Maven
> > > Core API
> > >
> > > WDYT?
> > >
> > > Michael
> > >
> > > PS: I don't even mind 3.6.3 personally, thought I don't this benefit.
> > >
> > > [1]
> > > https://cwiki.apache.org/confluence/display/MAVEN/Maven+Ecosystem+Cleanup#MavenEcosystemCleanup-ResolverandMaven
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> >
> >
> > --
> > Elliotte Rusty Harold
> > elh...@ibiblio.org
>
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.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 Dependency Plugin - Log4j vulnerabilities

[Bernd Eckenfels]

All of the (known) remaining log4j1.x security bugs (none of which are as 
severe as log4shell) are fixed in reload4j 1.2.18+. If you need to stick with 
1.2 you should use that. Otherwise you can try to migrate to the log4j bridge, 
it’s compatibility was increased in 2.17.2 or 2.12.4.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Martin Gainty 
Gesendet: Thursday, March 3, 2022 1:18:50 PM
An: Maven Developers List 
Cc: David Milet ; iss...@maven.apache.org 
; VZ-Product-OneTalk ; 
Danylo Volokh 
Betreff: RE: Maven Dependency Plugin - Log4j vulnerabilities

I *thought* log4j 1.2.15 had the patch to mitigate the JNDI Security 
Vulnerabity?
Is this not the case?
Thanks John
M.



Sent from my Verizon, Samsung Galaxy smartphone



 Original message 
From: John Patrick 
Date: 3/3/22 4:07 AM (GMT-05:00)
To: Maven Developers List 
Cc: David Milet , iss...@maven.apache.org, 
VZ-Product-OneTalk , Danylo Volokh 

Subject: Re: Maven Dependency Plugin - Log4j vulnerabilities

Sorry I thought you where talking about log4j v2, not v1. I can see it
downloads the metadata about the project but non or the jars;
local-repo/log4j
local-repo/log4j/log4j
local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom
local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom.sha1
local-repo/log4j
local-repo/log4j/log4j
local-repo/log4j/log4j/1.2.12
local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom
local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom.sha1
local-repo/log4j/log4j/1.2.12/_remote.repositories

So I would still say false positive, as the jar is not actually used.

But looking at the dependency tree it would need the apache commons to
update commons-logging:commons-logging, then
ommons-digester:commons-digester then org.apache.velocity:velocity-tools,
then it gets to the 1st dependency within the maven ecosystem.
So 5 ish patches to 5 separate projects to upgrade, test and release, each
before then next pr can progress.

John


On Thu, 3 Mar 2022 at 07:53, Thomas Matthijs  wrote:

> That was just to demonstrate how i got the dependency chain, that file
> was there, but if you're going to be this hostile, i'm not interested
> anymore, muting thread
>
> On Thu, 3 Mar 2022 at 08:48, Piotr Żygieło 
> wrote:
> >
> > On Thu, 3 Mar 2022 at 08:37, Thomas Matthijs  wrote:
> > >
> > > Can confirm this project downloads log4j 1.12.12 for me
> >
> > As I see it - you confirm something else.
> >
> > > Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
> >
> > Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
> > _artifact descriptor_
> >
> > --
> > Piotrek
> >
> > -
> > 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: Formal identification of license in a POM license element

[Bernd Eckenfels]

There is some discussion about this here: 
https://github.com/spdx/spdx-maven-plugin/issues/24

Personally I used the SPX URL for the Pom entry (but that has the disadvantage 
that some auditors want a tagged Repo location to the license). I think the 
SPDX maven plug-in can compare the url.

Here are some OSI sourced entries as well:

https://github.com/OpenSourceOrg/licenses/tree/master/licenses

Gruss
Bernd

--
http://bernd.eckenfels.net

Von: Gary Gregory 
Gesendet: Friday, February 11, 2022 7:48:58 PM
An: Maven Developers List 
Betreff: Formal identification of license in a POM license element

Hi All:

While researching GitHub's citation support [1], I found that there is a
plugin to convert a pom.xml into a CFF file [2]. I'd like to generate a CFF
file for Apache Commons Components like Commons Lang, Commons IO, and so
on. This plugin works but does not generate a license field [3] because the
POM license element does not hold a slot to identify a license with a
formal ID, in this case, the Linux Foundation SPDX ID [4]
https://spdx.dev/ids/

Any thoughts about supporting such a field for example "spdxID" or even
just "id" ?


   1. 
   2. 
   3. Apache-2.0 
   4. Apache License, Version 2.0
   5. https://www.apache.org/licenses/LICENSE-2.0.txt
   6. repo
   7. A business-friendly OSS license
   8. 
   9. 


?
Gary
[1]
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-citation-files
[2] https://github.com/hexatomic/cff-maven-plugin
[3] https://github.com/hexatomic/cff-maven-plugin/issues/28
[4] https://spdx.dev/ids/

Re: MD5, SHA1, but nothing (still) safe?

[Bernd Eckenfels]

If you use trusted checksum catalogs, shoes, reference hashes or stuff this can 
be used for integrity protection (if the checksum catalogs are integrity 
protected), and for this you indeed have to use strong hashes. However this is 
not directly related to the maven artifact hash files and deployer. (You better 
not generate the trusted lists from the untrusted repository hash files).

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Mickael Istria 
Gesendet: Thursday, October 14, 2021 9:56:04 AM
An: Maven Developers List 
Betreff: Re: MD5, SHA1, but nothing (still) safe?

On Wed, Oct 13, 2021 at 8:41 PM Bernd Eckenfels 
wrote:

> There is no Security risk with weaker checksums since the checksums are
> not used for security. An attacker who messes with your binaries can also
> mess with the checksum files.


In our case, we have the checksum files that are served from a "trusted"
place, but the artifacts can come from less trusted mirrors. And we want to
ensure the artifact we get is the one we expect whichever server does serve
it. Checksums can do that, and broken checksums algorithms such as md5 or
sha1 can allow a mirror to forge a malicious artifact with the same
checksums and thus let a malicious artifact be installed in place of a good
one; while strong checksums algorithms don't allow that.


> Only the signatures are relevant here (and they depend on the PGP settings
> if they use strong hashes).
>

I disagree that from a security perspective signatures have any stronger
impact on securing the transfer than a good checksum. Signatures are here
to create a concept of "trust delegation" (I trust this artifact because X
has signed they trust it), it's basically meant for human decision, not for
automated artifact transfer verification.

And even the broken/short/fast md5 would be strong enough to detect bit
> errors, especially considering TLS is now mandatory.
>

See my point above; it's not only a bit error, it can be malicious
artifacts coming from another source (mirror) and pretending to be the
correct ones because md5 is weak enough to allow to do it.

Re: MD5, SHA1, but nothing (still) safe?

[Bernd Eckenfels]

There is no Security risk with weaker checksums since the checksums are not 
used for security. An attacker who messes with your binaries can also mess with 
the checksum files. Only the signatures are relevant here (and they depend on 
the PGP settings if they use strong hashes).

And even the broken/short/fast md5 would be strong enough to detect bit errors, 
especially considering TLS is now mandatory.

Having said that, I guess the policy should come from maven central what’s 
required for new uploads.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Mickael Istria 
Gesendet: Wednesday, October 13, 2021 4:19:09 PM
An: Maven Developers List 
Betreff: Re: MD5, SHA1, but nothing (still) safe?

On Wed, Oct 13, 2021 at 2:10 PM Michael Osipov  wrote:

> Hi Mickael,
>

Hi Michael,

>
> this is an overly complex topic I'd like to explain.
> First of all Wagon is not involved in this. It does the physical
> transport. The payload is opaque. SHA, MD5 aren't verifying any
> signatures, it is just calculating a cryptographic hash. For signatures
> we have GPG and it should be clear that those checksums are for bitrot
> only. Checksums can be faked by anyone, signatures not.
>

Sorry for being confusing. I really mean checksums and verifying data
integrity in the transfer (bitrot).

A couple of months ago I have added SHA-2 to Maven Resolver, users
> complained (see users@, Dan Tran) that the additional roundtrips (HTTP
> requests) and calculation of checksums consume too much time. I had to
> take this back.


I couldn't find this discussion; I probably miss something. Is it buried in
another thread? Ideally, do you think you could share a link?
I'm surprised about those extra HTTP requests and calculation of checksums
being a too big issue compared to the security risk.


> Maven Central first: Brian
> Fox said that this is in investigation, but as you know yourself the
> entire ecosystem needs to prepare itself for this.
>

OK thanks for the info.

As for the checksum algorithms: SHA-x, compared to other cryptographic
> algorithms, performs horribly, SHA-2 worse than SHA-1. If you are
> downloading thousands of artifacts this does matter, actually.


Sure, SHA-256 is more expansive, but now SHA-1 has been broken for some
time already and isn't worth much in term of security. Keeping reliance on
MD5 and SHA1 seems quite insecure.


> Why do
> we need a cryptographic hash at all? We don't for bitrot. It is a waste
> of cycles.


What do you use for bitrot then? Unsecure algorithms?
p2 has mirror capabilities, one does fetch the p2 metadata from a trusted
location (eg https://download.eclipse.org) and this metadata contains the
artifacts with checksums, size and other info. This metadata can also
include a lit of mirrors to use in place of the main server; those mirrors
can use unsafe protocols or even be malicious themselves. Having checksums
in a trusted locations does prevent mirrors from injecting malicious
artifacts; and also allows to keep using "unsafe" protocols in a safer way.


> Also keep in mind when this stuff has been designed, when HTTP was used
> throughout. TLS hash hashing builtin. I think the previous bitrot case
> should be much much rarer.


As mentioned above, things like mirroring make it still very relevant.

Re: system path dependency warning, accurate or not?

[Bernd Eckenfels]

I don’t agree aboot the constructed repository case, they are intended to be 
shared. But I do agree that Maven should offer a new method to deal with such 
non transitive build dependencies (but just a side note: often you can use 
other plugins to access external resources they will not have that warning)

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Romain Manni-Bucau 
Gesendet: Sunday, September 26, 2021 8:15:30 AM
An: Maven Developers List 
Betreff: Re: system path dependency warning, accurate or not?

Yep but it is not consistent since it is the same with  but
there is no warning. So means that if you use system path or a custom
repository  you have to use redefine it anyway in your project.
So if you think the warning should stay, it should be there for all
projects depending on anything else than central, no?

The thing is that in 90% of the cases, projects doing that don't have the
choice and are most of the time dev leaves so it is fine.
So it is very bothersome to have this false positive warning and it is
worrying for dev to have the last sentence so I'd like a solution for these
projects.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le dim. 26 sept. 2021 à 03:15, Bernd Eckenfels  a
écrit :

> I don’t know what your warning reads, but mine says „will be unresolvable
> by dependent projects“
>
>
> --
> http://bernd.eckenfels.net
> 
> Von: Romain Manni-Bucau 
> Gesendet: Saturday, September 25, 2021 7:50:07 PM
> An: Maven Developers List 
> Betreff: Re: system path dependency warning, accurate or not?
>
> You have a point for downside projects - which is *not* what the warning
> says (once again the message is technically wrong ;)).
>
> So what is the solution?
>
> Fix the message + document inline repo usage which is fully out of the
> warning but has the same pitfall?
>
> Le sam. 25 sept. 2021 à 17:42, Bernd Eckenfels  a
> écrit :
>
> > Hello,
> >
> > I am a Repo user and despise binaries in git, therefore I would not run
> > into this problem. It also means you might be outside of the maven
> > conventions.
> >
> >  However I can see that you might need in expectional cases to access
> > dependencies inside the project directory for building. But the warning
> is
> > exactly that: if some other project depends on yours, they won’t be able
> to
> > resolve. Maybe it is better to turn the local dependency into a new type
> > compile-file, then it is not needed by your dependent projects (and  it
> > should not produce a warning). Alternatively, maybe make it a plug-in
> > dependency?
> >
> > So all in all, the warning is a good thing unless we have a way to not
> > export that dependency into the consumer transitive tree (as those don’t
> > know anything about your base)
> >
> > Gruss
> > Bernd
> > --
> > http://bernd.eckenfels.net
> > 
> > Von: Michael Osipov 
> > Gesendet: Saturday, September 25, 2021 9:04:22 AM
> > An: dev@maven.apache.org 
> > Betreff: Re: system path dependency warning, accurate or not?
> >
> > Am 2021-09-24 um 23:43 schrieb Benjamin Marwell:
> > > Hi Michael!
> > >
> > > Setups like "${project.basedir}/m2/" are a common thing.
> > >
> > > While "system" scope was probably invented to use system
> > > (i.e. jdk-related) jar files, but otoh
> > > it is the only way to pull in artifacts
> >
> > Why aren't they installed locally or deployed to a hosted repo?
> > This breaks our convention over configuration.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: system path dependency warning, accurate or not?

[Bernd Eckenfels]

I don’t know what your warning reads, but mine says „will be unresolvable by 
dependent projects“


--
http://bernd.eckenfels.net

Von: Romain Manni-Bucau 
Gesendet: Saturday, September 25, 2021 7:50:07 PM
An: Maven Developers List 
Betreff: Re: system path dependency warning, accurate or not?

You have a point for downside projects - which is *not* what the warning
says (once again the message is technically wrong ;)).

So what is the solution?

Fix the message + document inline repo usage which is fully out of the
warning but has the same pitfall?

Le sam. 25 sept. 2021 à 17:42, Bernd Eckenfels  a
écrit :

> Hello,
>
> I am a Repo user and despise binaries in git, therefore I would not run
> into this problem. It also means you might be outside of the maven
> conventions.
>
>  However I can see that you might need in expectional cases to access
> dependencies inside the project directory for building. But the warning is
> exactly that: if some other project depends on yours, they won’t be able to
> resolve. Maybe it is better to turn the local dependency into a new type
> compile-file, then it is not needed by your dependent projects (and  it
> should not produce a warning). Alternatively, maybe make it a plug-in
> dependency?
>
> So all in all, the warning is a good thing unless we have a way to not
> export that dependency into the consumer transitive tree (as those don’t
> know anything about your base)
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> Von: Michael Osipov 
> Gesendet: Saturday, September 25, 2021 9:04:22 AM
> An: dev@maven.apache.org 
> Betreff: Re: system path dependency warning, accurate or not?
>
> Am 2021-09-24 um 23:43 schrieb Benjamin Marwell:
> > Hi Michael!
> >
> > Setups like "${project.basedir}/m2/" are a common thing.
> >
> > While "system" scope was probably invented to use system
> > (i.e. jdk-related) jar files, but otoh
> > it is the only way to pull in artifacts
>
> Why aren't they installed locally or deployed to a hosted repo?
> This breaks our convention over configuration.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: system path dependency warning, accurate or not?

[Bernd Eckenfels]

Hello,

I am a Repo user and despise binaries in git, therefore I would not run into 
this problem. It also means you might be outside of the maven conventions.

 However I can see that you might need in expectional cases to access 
dependencies inside the project directory for building. But the warning is 
exactly that: if some other project depends on yours, they won’t be able to 
resolve. Maybe it is better to turn the local dependency into a new type 
compile-file, then it is not needed by your dependent projects (and  it should 
not produce a warning). Alternatively, maybe make it a plug-in dependency?

So all in all, the warning is a good thing unless we have a way to not export 
that dependency into the consumer transitive tree (as those don’t know anything 
about your base)

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Michael Osipov 
Gesendet: Saturday, September 25, 2021 9:04:22 AM
An: dev@maven.apache.org 
Betreff: Re: system path dependency warning, accurate or not?

Am 2021-09-24 um 23:43 schrieb Benjamin Marwell:
> Hi Michael!
>
> Setups like "${project.basedir}/m2/" are a common thing.
>
> While "system" scope was probably invented to use system
> (i.e. jdk-related) jar files, but otoh
> it is the only way to pull in artifacts

Why aren't they installed locally or deployed to a hosted repo?
This breaks our convention over configuration.

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

Re: Removing IRC channel mentions from official website documentation

[Bernd Eckenfels]

Thanks for bringing this to our attention and I agree we should remove the irc 
channel in this case.

Not sure about the slack since I don’t use it, but the website is not only for 
the public, it’s also the primary source for committers (but if we add the 
slack we certainly need to mention who gets access and how)

On what URLs you saw the irc channel?

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Dawid Pura 
Gesendet: Wednesday, September 8, 2021 10:16:27 PM
An: dev@maven.apache.org 
Betreff: Removing IRC channel mentions from official website documentation

Hello all,

I have noticed it's misleading for new contributors to find out the proper
communication channel for this project. The documentation says there is an
IRC channel which topic says "we moved to Slack". Then, it takes some time
to figure out a newcomer cannot get in, since she has to be invited by
actual commiters.

I think I can remove any mention of IRC channel from maven-site, as this
has been deprecated comms channel, right? I am asking the more subtle
question, should the Slack channel be mentioned instead, or there is no
reason to mention it in public docs as it's not reachable by the public.

this is my very first e-mail on this mailing list and mailing lists in
Apache in general, so please share any feedback that comes to your mind :).

All the best,
Dawid Pura

Re: Request for Enhancement: Dependency Overrides

[Bernd Eckenfels]

I don't really see it convenient at all. If you have to change the source 
anyway, you can also fix the POM, that's much less confusing than having a 
project using technology x but declaring to use technology y.

The only time I see dependency overwrites as somewhat useful if you want to 
replace transitive dependencies with fixed minor updates. This is however 
seldomly needed since maven adjusts version conflicts to the closest version 
anyway.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Enno Thieleke 
Gesendet: Saturday, August 14, 2021 3:38:53 PM
An: Maven Developers List 
Betreff: Re: Request for Enhancement: Dependency Overrides

Hi Bernd,

hopefully I understand you correctly: I'd expect the artifact (and its source 
and javadoc attachment) to change, nothing more. The source would be left 
untouched. It is not the responsibility of the dependency resolution 
mechanism/engine to do anything else.

Just to make sure that we have the same understanding: If I replaced one 
dependency with another one, I would effectively alter the POM to contain that 
other dependency instead of the original. After that Maven would do its thing 
as usual.

Obviously, such a feature should be used carefully: If I replaced 
commons-logging:commons-logging with log4j:log4j, any code referencing code 
from commons-logging would not compile anymore. It's the responsibility of the 
developer to provide a working replacement. But this is fine, if you ask me, 
because if I replaced an artifact by exclusion and added a wrong dependency, 
the issue would be the same - and this is possible today already. One could say 
that an override would be a very, very convenient way the exclude and add a 
dependency.

Kind regards,
Enno


From: Bernd Eckenfels 
Sent: Saturday, August 14, 2021 2:28 PM
To: Maven Developers List 
Subject: Re: Request for Enhancement: Dependency Overrides

Would you expect to only replace artifacts or also change the java source and 
class files to actually change the used classes? Your cases are no simple 
drop-in replace compatibility. Therefore I doubt a maven feature to do so is 
any more useful than just blocking the deprecated artifacts.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Enno Thieleke 
Gesendet: Saturday, August 14, 2021 1:24:26 PM
An: Maven Developers List 
Betreff: Re: Request for Enhancement: Dependency Overrides

So, you're saying that I can replace artifact coordinates with 
dependencyManagement.dependencies already? I'm not talking about versions, 
scopes and exclusions, I'm talking about groupIds and artifactIds. My idea is, 
simply put, if artifact commons-logging:commons-logging is found, 
org.slf4j:jcl-over-slf4j is used instead. Or if artifact 
org.hibernate.javax.persistence:hibernate-jpa-2.2-api is found, 
jakarta.persistence:jakarta.persistence-api is used instead. I don't think that 
this is possible with the current version of Maven. If it is, please share a 
link to the docs covering this feature.

Feel free to look at the example I provided. I feel it makes my idea more 
comprehensible.
https://github.com/strohmattenverleger/maven-resolver/tree/MNG-4530
https://github.com/strohmattenverleger/maven/tree/MNG-4530 (requires the 
changes I made to maven-resolver)
https://github.com/strohmattenverleger/maven-MNG-4530-example (the "magic" 
happens in the parent/root POM)

Also, I don't think implementing this as an extension is the right thing to do. 
If it were to be fully implemented, it'd have to be a core feature of Maven and 
the Maven Resolver. This way the entire user base of Maven would benefit from 
it.

From: Romain Manni-Bucau 
Sent: Saturday, August 14, 2021 8:55 AM
To: Maven Developers List 
Subject: Re: Request for Enhancement: Dependency Overrides

Hmm,

 dependencyManagement.dependencies already does that today.
My point is mainly we shouldnt have two ways to do the same and even less
two chained ways to do it.

If you dont like mvn dep graph definition you can already write a mvn
extension to write it differently so can also be an option, but as of today
i dont see anything not already smoothly doable.

Le sam. 14 août 2021 à 02:01, Enno Thieleke  a
écrit :

> Hi Romain,
>
> the dependencyOverrides element is an addition. While it shares some
> characteristics, it does not duplicate the dependencyManagement element. In
> fact, it's a part of it. Come to think of it, it may even be ok to
> locate/place it "next to" the dependencyManagement element, thus making it
> a "standalone thing", but I consider this feature to be a
> dependencyManagement aspect, which is why I made a sub element of it.
>
> I'm not sure if I understand your question correctly: how to override in
> the override block?
> If you mean how would a dependencyOverrides element of on

Re: Request for Enhancement: Dependency Overrides

[Bernd Eckenfels]

Would you expect to only replace artifacts or also change the java source and 
class files to actually change the used classes? Your cases are no simple 
drop-in replace compatibility. Therefore I doubt a maven feature to do so is 
any more useful than just blocking the deprecated artifacts.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Enno Thieleke 
Gesendet: Saturday, August 14, 2021 1:24:26 PM
An: Maven Developers List 
Betreff: Re: Request for Enhancement: Dependency Overrides

So, you're saying that I can replace artifact coordinates with 
dependencyManagement.dependencies already? I'm not talking about versions, 
scopes and exclusions, I'm talking about groupIds and artifactIds. My idea is, 
simply put, if artifact commons-logging:commons-logging is found, 
org.slf4j:jcl-over-slf4j is used instead. Or if artifact 
org.hibernate.javax.persistence:hibernate-jpa-2.2-api is found, 
jakarta.persistence:jakarta.persistence-api is used instead. I don't think that 
this is possible with the current version of Maven. If it is, please share a 
link to the docs covering this feature.

Feel free to look at the example I provided. I feel it makes my idea more 
comprehensible.
https://github.com/strohmattenverleger/maven-resolver/tree/MNG-4530
https://github.com/strohmattenverleger/maven/tree/MNG-4530 (requires the 
changes I made to maven-resolver)
https://github.com/strohmattenverleger/maven-MNG-4530-example (the "magic" 
happens in the parent/root POM)

Also, I don't think implementing this as an extension is the right thing to do. 
If it were to be fully implemented, it'd have to be a core feature of Maven and 
the Maven Resolver. This way the entire user base of Maven would benefit from 
it.

From: Romain Manni-Bucau 
Sent: Saturday, August 14, 2021 8:55 AM
To: Maven Developers List 
Subject: Re: Request for Enhancement: Dependency Overrides

Hmm,

 dependencyManagement.dependencies already does that today.
My point is mainly we shouldnt have two ways to do the same and even less
two chained ways to do it.

If you dont like mvn dep graph definition you can already write a mvn
extension to write it differently so can also be an option, but as of today
i dont see anything not already smoothly doable.

Le sam. 14 août 2021 à 02:01, Enno Thieleke  a
écrit :

> Hi Romain,
>
> the dependencyOverrides element is an addition. While it shares some
> characteristics, it does not duplicate the dependencyManagement element. In
> fact, it's a part of it. Come to think of it, it may even be ok to
> locate/place it "next to" the dependencyManagement element, thus making it
> a "standalone thing", but I consider this feature to be a
> dependencyManagement aspect, which is why I made a sub element of it.
>
> I'm not sure if I understand your question correctly: how to override in
> the override block?
> If you mean how would a dependencyOverrides element of one POM be merged
> with an element of another POM, pretty much like a dependencyManagement
> element - I made sure remove redundant sub elements.
> If you mean how would an override override another override? Currently
> processing overrides is just a sequential operation. Let's say the order of
> overrides is as follows (the notation "->" is to be read as "is overridden
> with" or "is replaced by"):
>
>   *   X -> Y
>   *   Y -> Z
>
> Here having a dependency X will ultimately result in having Z. And now for
> a different order:
>
>   *   Y -> Z
>   *   X -> Y
>
> Here having a dependency X will result in having Y.
>
> I think a helpful implementation would raise an error in both cases, since
> having some sort of hyper edge here is questionable.
>
> Where I'm definitely not following you is why one would drop the
> transitiveness of an override block/element. On the contrary: I'd not touch
> transitiveness in any way. If an override brings transitive dependencies
> where an original didn't, then so be it. That'd actually be desired in my
> opinion.
>
> The final goal of overrides (if you ask me) is to manipulate a dependency
> graph in a way that is transparent to developers and plugins. If done
> right, one wouldn't be able to tell the difference between a graph, which
> is clean from the start, and a graph, which has been altered using
> overrides.
>
> Looking forward to your reply.
>
> Kind regards,
> Enno
>
>
> 
> From: Romain Manni-Bucau 
> Sent: Friday, August 13, 2021 2:41 PM
> To: Maven Developers List 
> Subject: Re: Request for Enhancement: Dependency Overrides
>
> Hmm, I probably miss a thing but it looks like you just redid
> dependencyManagement but duplicating it you created a new issue: how to
> override in the override block?
> Only neat way I see to handle that is to drop the transitiveness of the
> override block which would defeat a lot dependency usage so I'm quite mixed
> about this proposal without a more concrete use case.
>
> Romain Manni-Bucau
> 

Re: Software Heritage connector to Maven repositories

[Bernd Eckenfels]

Hello Boris.

I know that opening a Nexus JIRA is the usual way to get responses.

BTW also consider scraping the SCM URLs from the POM files and contact the 
upstream Repos, the maven -src archives are often pruned down and not builtable 
(if present at all). So it does not hurt to archive them, but don’t expect them 
to help you in all cases.

Sadly Tag parsing and SCM scraping is not the most reliable thing (we do it for 
consumed dependencies), but with some manual overwrite it’s manageable at small 
scale. Maybe you would get help if you provide such a Registry as a github 
project or ask OSSIndex for cooperation.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Boris Baldassari 
Gesendet: Montag, Juni 14, 2021 5:25 PM
An: dev@maven.apache.org
Betreff: Re: Software Heritage connector to Maven repositories

Hi Frederik,

Thanks for the kind answer and pointers.

Yes, we know that non-consensual mirroring, as well as scrapping, is
explicitly forbidden. Hence the question here. :-)

It should be noted however that our case is a bit specific: we want to
get only *some* types of artefacts (poms and src jars), but we want
*all* of them. So it's a special case of partial mirroring. Furthermore
we will only access them *once* for the archiving so the "re-use"
feature of a proxy, mirror or similar is not needed.

Maybe a repo maintainer could provide some more wisdom?


Thanks, cheers!



--
boris



On 14/06/2021 13:41, Frederik Boster wrote:
> I am not in any way affiliated with Apache or Sonatype. So take my opinion
> with a grain of salt :)
>
> Trying to mirror the entire Maven Central repository will unfortunately get
> you automatically banned.
> To circumvent that I would suggest you setup your own Maven Central mirror
> first. [1]
>
> [1]
> https://maven.apache.org/guides/mini/guide-mirror-settings.html#creating-your-own-mirror
>
> On Mon, Jun 14, 2021, 12:12 Boris Baldassari 
> wrote:
>
>> Hiho good people,
>>
>> I am currently developing a Maven repositories connector for the
>> Software Heritage Foundation [1].  In a nutshell, the SWH aims to
>> archive all existing source code in the world, and provides useful
>> publicly available services and related tools (unique IDs/DOIs, search,
>> datasets, graph tools..). It's all open-source, and many large forges
>> and software systems have already been archived (GitHub, GitLab, npm,
>> pypi, debian packages, CRAN..) [2]. Now we would like to archive the
>> Maven ecosystem.
>>
>> [1] https://www.softwareheritage.org/
>> [2] https://archive.softwareheritage.org/
>>
>> I'm reaching out to ask for wisdom and start a discussion about how this
>> could be achieved without impacting anybody, i.e. neither Maven
>> repositories maintainers nor the users. Our plan for now is to use the
>> maven indexer indexes for the listing, and then download poms and source
>> jars, in a way that we see as the most efficient and fair. We of course
>> respect all rate-limiting policies (and http error codes), and we are
>> polite and patient (although tenacious).
>>
>> So, here are my questions:
>>
>> * Who should we talk to to achieve that? i.e. are there maven repository
>> maintainers on the list, or do you know of a better place to ask?
>>
>> * Although we believe the above mentioned process is the most efficient
>> and fair one, maybe there is a better way to list, and archive artefact
>> sources? Any feedback or mere thoughts are welcome.
>>
>>
>> Thanks in advance, have a wonderful day!


--
Boris Baldassari
Castalia Solutions -- Elegant Software Engineering
Web: http://castalia.solutions
Tel: +33 6 48 03 82 89

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

Re: Security/Versioning policy proposal

[Bernd Eckenfels]

I agree, maven does not need to concern itself with branches as long as it 
stays fairly forward drop-in compatible.

Having said that, things like changing the policy for handling http might not 
be that drop-in, but on the other hand it’s just a config option and does not 
require complicated (plugin) dependency updates.

I do wonder if the version number should better reflect such incompatible 
requirement changes. (And if somebody really wants to provide security fixes 
for those incompatible older branches why not, but I don’t think you can 
require them from a project which does not offer them by themself).


--
http://bernd.eckenfels.net

Von: Ralph Goers 
Gesendet: Sunday, April 4, 2021 9:55:50 PM
An: Maven Developers List 
Betreff: Re: Security/Versioning policy proposal

More than likely you will get whatever the next version number happens to be. I 
can’t think of a case where Maven needed to go back and patch a prior release.  
That could happen however, if Maven was modified to require Java 11 to run and 
a security fix had to be applied to the last version supporting Java 8.

Ralph

> On Apr 4, 2021, at 6:25 AM, Romain Manni-Bucau  wrote:
>
> Le dim. 4 avr. 2021 à 14:10, Robert Scholte  a écrit :
>
>> To me all releases can contain security fixes.
>> Depending on the risk of the CVE we can decide to do a release with only
>> those fixes (see Maven 3.0.5 and 3.8.1)
>>
>
> I get that but it does not help users to pick versions and to get any
> stability in their build - which is the goal of this thread.
> Since you rejected a 3.6.4 for last CVE hitting us I have to admit I have a
> hard time to formalize it.
> Best I come up is "we'll do what we want" which is hopefully just a
> complete misinterpretation of what you mean but hope shows how clueless I
> am with such a statement at the moment.
> Can you try to refine it please?
>
> Concretely, today I'm starting with a 3.8.1, what am I expecting to use in
> 5 years for this project trying to get security fixes and being stable (ie
> 4.x is assumed excluded?)?
>
>
>>
>> Robert
>>
>> On 4-4-2021 12:14:39, Romain Manni-Bucau  wrote:
>> Le dim. 4 avr. 2021 à 12:09, Robert Scholte a écrit :
>>
>>> I doubt we can or should make any promises, only intentions.
>>> If we would have it, I wonder if it cover our choice to skip 3.7.0.
>>> To me we need to keep that flexibility.
>>>
>>> I want to reverse the approach: what could users expect as differences
>>> between version x and y.
>>>
>>> For Maven shouldn't be more complex than:
>>> bugfix release-change should be safe "just replace" release with bugfixes
>>> and internal improvements.
>>> minor release-change should represent relevant new features or (as we saw
>>> for 3.8.x) possible breaking builds that can be fixed with configuration.
>>> major release-change represents changes to the architecture that might
>>> change the behavior.
>>> as far as I know this defends all Maven releases up until now.
>>>
>>
>> Does not cover the last release - and is actually the issue I'm suffering
>> from right now and why i'd like we cover this case: security fixes. As of
>> today it is a mix between patch (bugfix) and minor lines AFAIK but I'd like
>> we explicit it (even just saying on each line "can include bugfixes").
>> Said differently: the reverse approach you mention only cover the feature
>> evolution but not the most important for versioning policy: the security
>> policy which is the one which hurt right now.
>> As an user, I want to be able to anticipate the versions i can need staying
>> as much as possible on a stable version (original version) but upgrading to
>> get security fixes.
>> If it is fine for you to mention lines 1 and 2 can include security fixes
>> i'd be to add this paragraph on the history page maybe?
>>
>> wdyt?
>>
>>
>>>
>>> In case of plugins: the major represents the minimal required version of
>>> Maven.
>>>
>>> Robert
>>> On 4-4-2021 11:28:30, Romain Manni-Bucau wrote:
>>> Hi Elliotte,
>>>
>>> My goal is to write what we can promise and users can rely on to work.
>>> If we can only promise any major release will get all security fixes
>>> whatever are the minor/patch versions, be it.
>>> I just want what we do to be explicit.
>>>
>>> Hervé proposed to reference history page of website, it can be a good
>> start
>>> with one or two more sentences to solve that.
>>>
>>> Le sam. 3 avr. 2021 à 23:50, Elliotte Rusty Harold a
>>> écrit :
>>>
 On Fri, Apr 2, 2021 at 4:21 PM Romain Manni-Bucau
 wrote:
>
> Hi all,
>
> What about starting from something like
> http://tomee.apache.org/security/security.html for our versioning
 policy.
>
> Goal is really to let user plan their versioning policy and ensure
>>> there
 is
> no big surprises in the needed upgrades to have bugfixes.
>

 TBH I don't think we have enough developer time and commitment to
>> promise
 this.

 --
 Elliotte Rusty 

Re: maven 4.0.0 new XML stuff

[Bernd Eckenfels]

Hello,

Not exactly sure what work you mean and I fully agree that using a core model 
should still be the API for plugins and extensions to work with, however 
specifically the consumer POM integrates with so many external ecosystems, I 
would expect it to be defined in terms of XML Schema with explicite semantic 
(and the inherent compatibility with exiting POMs).

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Matthieu BROUILLARD 
Gesendet: Thursday, December 31, 2020 3:19:09 PM
An: dev@maven.apache.org 
Betreff: maven 4.0.0 new XML stuff

Hello all,

regarding the active work occurring for maven 4.0.0 I noticed the
introduction of a lot of new stuff around SAX parsing & filtering.
I am wondering if that means that it was decided that the input format of
maven projects will be XML forever meaning probably, among others, the end
of polyglot extensions.
Could you explain such a move (or point to rationals/documents) and why you
did not leverage working on the in memory object model allowing
extensions/plugins to contribute/hook in the chain of building the BuildPOM
& ConsumePOM? In the past I really thought that this move to 'Build vs
Consumer' POM would make clear separations between the input format of
descriptors and the core system but I perhaps misunderstood things.

Also, are there plans regarding the future of core extensions?
With core extensions it was possible to hook into the POM model loading and
do transformations to do dynamic changes but by working on the XML directly
I see a shift (if not red stop) in this contribution/delegation mechanism.

Thanks for your time & answers.

Matthieu Brouillard

Re: Build windows-jdk15

[Bernd Eckenfels]

Hello,

As long as we have windows builds and jdk15+ builds I guess one can reduce the 
flaky combinations but it would still be interesting to see what’s the problem 
is, in the pipeline steps view you see the failed step

https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-dependency-plugin/job/null/2/flowGraphTable/

And it’s console log

https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-dependency-plugin/job/null/2/execution/node/315/log/

I complains about a unexpected dependency tree (this does not really look 
platform-version specific, maybe more a repository issue?)

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Elliotte Rusty Harold 
Gesendet: Thursday, December 31, 2020 12:37:18 PM
An: Maven Developers List 
Betreff: Re: Build windows-jdk15

Here's one example:

https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-dependency-plugin/job/null/

There are many others. Nothing changed between the three runs. First
Windows JDK 15 failed. Then Windows JDK 7 failed. Then they all
passed. No code changes were made between the runs. If there's a way
to see the logs from the failed runs, it's far from obvious to me.

Flaky build infrastructure is dangerous because it teaches developers
to ignore the CI.




On Wed, Dec 30, 2020 at 11:38 PM Robert Scholte  wrote:
>
> What's you analysis?
> Did you inform INFRA?
> If we have issues with these versions, most likely Maven users will have to.
>
> We've seen this in the past too and I think all the time I'm been able to 
> bring the builds back to blue.
> Disabling would be avoiding or ignoring the problem.
>
> thanks,
> Robert
> On 30-12-2020 14:59:16, Elliotte Rusty Harold  wrote:
> The Windows JDK 15 instance in jenkins seems irredeemably flaky. It
> fails more often than not for reasons that have nothing to do with the
> code being tested.
>
> As JDK 15 is not a long term support release, and has only minimal
> adoption, can we simply turn off the Windows JDK 15 build?
>
> Personally, I'd love to turn off all JDK 15 and 16 builds, but Windows
> JDK 15 is by far the worst.
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>


--
Elliotte Rusty Harold
elh...@ibiblio.org

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

Re: [DISCUSS] Allow attributes shorthand in pom.xml

[Bernd Eckenfels]

Hello,

Having includes in a format might be handy, but it does not fit the philosophy 
of maven of having a repeatable declarative style. If you need such modularity 
and imperative style you might be better off using gradle or simple pipeline 
scripts.

(With derived published POMs and changes like profiles and plugins not fitting 
into this it might have eroded over time, but coming from ANT I still value 
convention/declaration over imperative style - so every time I wish maven would 
be more open I remeber those times and I am reconsider if the task I have is 
suited for a maven Pom (after all its project model not build script)

BTW i abstain from commenting on your tone since we are all passionate about 
our experiences, it does trigger me to add this footnote, however.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Hunter C Payne 
Gesendet: Saturday, December 12, 2020 8:02:15 PM
An: Maven Developers List 
Betreff: Re: AW: [DISCUSS] Allow attributes shorthand in pom.xml

So there have been a few comments so far (yea) so I'm going to try to address 
them here:
1) choice of formatAny format that specifies a POM should have validation 
(which JSON, HOCON and XML do). YAML should be a non-starter as it has no 
validation (or types and it depends on invisible characters for formatting).  
But Unbound only translates between formats and so you can still write your 
1000s of lines of XML if you want but it allows the rest of us to have 10 line 
POM files.
But I've noticed that none of you have mentioned HOCON (which has comments) so 
far which leads me to think that none of you know this format or understand 
what it enables.  Its an extension of JSON so it picks up all the validation 
functionality.  But it also has an include primitive which allows abstracting 
of POMs in a really useful way.  I can write a block of HOCON and host it on a 
server somewhere in my infrastructure and then every project in the org can add 
an include line to use that block of POM.  That's so much nicer than the way we 
abstract POMs currently.  Multi-project POMs are often a nightmare to do mainly 
because the inheritance of POMs is so complex.
HOCON spec: https://github.com/lightbend/config/blob/master/HOCON.md

2) why we are doing thisIf you don't have problems getting teammates to use 
Maven, then you are the lucky 1%.  The rest of us have to work with folks under 
the age of 35 and its pretty impossible to get them to use or learn Maven due 
to XML.  Also, my HOCON POMs are a small fraction as long as the XML ones but 
with the same functionality.

I'm just not understanding the resistance here.  I feel like those that are 
resisting don't really understand the current developer community.  SBT is a 
slow and very poor build tool but people use it because they dislike XML that 
much more.  Not sure why folks on this list don't understand that.  XML is 
pretty universally hated at this point.  Perhaps best to just accept that 
instead of talking about features (XSD) that almost nobody ever used.

3) ease of integrationI'm only asking to have Unbound included, not to change 
the POM format, or require significant changes in Maven itself.  I'm not sure 
why you would want this as the tooling should still use XML for reasons of 
legacy and practicality.  But forcing devs to write POMs in XML by hand is 
currently required and pretty undesirable.
 4) what is wrong with XMLFor one the way lists and maps are represented are 
very verbose and unwieldy.  But the bigger thing for me is how inheritance is 
done in Maven.  Mutli-module projects are way too hard to make work.  A simpler 
block level inheritance that HOCON enables is far more preferable.  Consider 
this example:
https://github.com/hunterpayne/maven-unbound/blob/master/examples/rpm.conf
This block of code can be included by adding this to your HOCON POM:
 include file("examples/rpm.conf")

And now my pom can build RPMs in a single line.  Pretty nifty and so much 
better than repeating 80 or so lines of XML.
Hunter




   On Saturday, December 12, 2020, 8:20:08 AM PST, Gary Gregory 
 wrote:

 On Sat, Dec 12, 2020 at 6:53 AM Robert Scholte  wrote:

> Here's my unpopular response: I'm not going to invest in attribute support
> for Maven.
> If the verbosity of the pom.xml is the first thing people complain about,
> well, then Maven is doing a pretty good job (if the build itself had
> issues, one would complain about that first, right?).
> By having elements only it is much easier to maintain Maven.
> It'll remove discussion as to: what would be an attribute and what should
> be an element? Can it be based on required versus optional? Allowing both
> for the same "fields" is probably a recipe for disaster.
>

That's simple IMO and what we usually do at my day job: XML elements and
attributes are like Types (Classes) and its attributes (instance
variables). It does not need to be more complicated than that. FWIW, I'm
baffled at the 

Re: Apache Maven Software

[Bernd Eckenfels]

Hello Keith,

Apache is a volunteer driven organisation, as long as volunteers, including 
your Organisation contribute patches (and funding) the software is supported. 
There is no guarantee or contract you can obtain for that.

You haven’t specified which projects (plugins) in particular you are interested 
in, however the general maven project is not planning to stop development. Some 
older versions however might not be actively maintained anymore, and it is 
always a good idea to stay with the latest release.

Maven 3.6.3 is recent, so I would not expect any more releases in the Maven 
3.5.x line. (However as already explained, if enough organizations invest the 
time and produce a critical fix, together with this free development community, 
why not. It would be however much easier to just upgrade)

Gruss
Bernd
(An unofficial bystander, triggered by formal requests)
--
http://bernd.eckenfels.net


Von: Crawford, Keith K CIV USARMY SEC (USA) 

Gesendet: Donnerstag, November 26, 2020 12:49 AM
An: dev@maven.apache.org
Betreff: Apache Maven Software

Maven Support,

We are going through the Assess Only process of licensed and open source client 
software for Information Assurance.  As part of the package we must submit 
dates for support End of Support for current version 3.5.3, not just the 
release date.  We need this information to install and use this software, 
required by our developers in support of multiple programs.  Can you provide 
support or End of Support dates for Apache Maven 3.5.3, please?

V/r,

Keith Crawford
Enterprise Architect
Technical Services Branch
Technical Operations Division
Army Shared Services Center
CECOM Software Engineering Center (SEC)

☎ (804) 734 - 5204Feldman Hall
 (804) 892 - 5759Govt Mobile
✉ keith.k.crawford@mail.mil

Re: Jenkins + Github

[Bernd Eckenfels]

I think this is not possible for security reasons, you cannot trust pull 
requests to have malicious code. The Jenkins builds are not that isolated.

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Elliotte Rusty Harold 
Gesendet: Thursday, February 20, 2020 1:46:50 PM
An: Maven Developers List 
Betreff: Jenkins + Github

Is it possible to integrate the Jenkins builds with Github as Traivs
and CircleCI do? That is, to have Jenkins report build status on a PR
back to Github as a hook?

--
Elliotte Rusty Harold
elh...@ibiblio.org

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

Re: Maven Wrapper

[Bernd Eckenfels]

How about adding a system property or environment variable stating the type of 
starter script and it's version, so this can be logged by Maven runs for better 
troubleshooting and potentially warnings from enforcer plugin?

BTW: I wrote a longish argument for maintainability and binaries in Repos, but 
I figured I just don't care enough :) But a official infrastructure for having 
a local selection of Maven versions would be a nice side product (I.e. 
.m2/Maven- and /opt/maven/maven-<> standard search path (independent 
of wrapper?)
--
http://bernd.eckenfels.net

Von: Robert Scholte 
Gesendet: Wednesday, February 19, 2020 9:50:14 PM
An: dev@maven.apache.org 
Betreff: Re: Maven Wrapper

I will write several integration tests matching these use cases.
Based on that we can decide what to do.

Robert

On 19-2-2020 21:04:51, Manfred Moser  wrote:
There are kinda three main use cases that need to work:

Install:

Installing the wrapper in a project by adding the .mvn/wrapper folder contents 
and the mvnw and mvnw.cmd files. This is done by the plugin by taking the 
maven-wrapper jar and extracting it in to project after downloading and so on. 
It needs to work behind proxies, repo managers...

The result is that whatever is added to the repo is committed to the source 
repo of the project. This might or might not include the wrapper jar.


The other two use cases are largely driven off the mvnw and mvnw.cmd files so 
updating those will be critical when you want to maintain how it works on 
different shells and so on.

Usage with installation of Maven:

Here the stuff added from above detects the correct Maven is installed and if 
not downloads it and installs it in ~/.m2/wrapper and then uses it to run the 
desired command passed to it. Download and install of Maven is done via Java 
code in the maven-wrapper jar. If the jar is not use it can fall back to 
curl/wget and if that fails to the java class that is compiled and used.

Usage without installation of Maven:

Same as above but the desired Maven version is detected and used straight away.


Now what that in minds.. is there a risk in completely rewriting it and 
changing how it currently works. Very much so. You might miss a use case and 
end up rebuilding it all over time.

At the same time .. is the current system maybe overly complex and ugly. 
Probably yes. Could it be improved, certainly.

So in the end its a questions of approach and taste. Do you want to just port 
what we got and then improve. Or do you want to rebuild from scratch?

Personally I would just port and improve later but it seems to me that with the 
decision to get it into core you are already largely redoing things so a 
reimplementation seems okay. I would just try to maintain the user facing 
config and behavior.

Manfred


Robert Scholte wrote on 2020-02-19 11:40 (GMT -08:00):

> Manfred, I don't understand the need for the org.apache.maven.wrapper.cli
> package.
> I would expect that all arguments after mvnw are passed as is to Maven.
> The wrapper itself doesn't have any arguments to change the behavior, only
> environment variables.
> And the ProjectPropertiesCommandLineConverter is weird, in Maven -P is for
> activating profiles.
>
> I would like to understand the need for every class, otherwise remove it,
> especially if we start over with a clean codebase.
> Do you see a risk?
>
> Robert
>
> On 19-2-2020 06:19:54, Manfred Moser wrote:
> All done. All note with pointers to both project readme files, closed all
> issues and closed all PRs. Hopefully further input and help will show up here
> now.
>
> Manfred
>
> Robert Scholte wrote on 2020-02-18 10:56 (GMT -08:00):
>
>> sure, go ahead
>> On 18-2-2020 19:47:29, Manfred Moser wrote:
>> Okay .. so then I think I should update the Takari repos with a note about
>> that
>> and send any contributors to the Maven dev list NOW. I think this has the
>> potential to drive some more help in this effort.
>>
>> If you agree I can do that tonight ..
>>
>> manfred
>>
>> Robert Scholte wrote on 2020-02-18 10:40 (GMT -08:00):
>>
>>> This will be part of 3.7.0 together with other huge changes.
>>> Having the wrapper makes it possible to start updating the defaults for our
>>> Maven plugins.
>>> I don't expect a release soon and I don't see a reason to hurry that.
>>> We've done 3.6.2 and a 3.6.3 regression release to give us time to work on
>>> 3.7.0.
>>>
>>> Robert
>>> On 18-2-2020 18:50:01, Manfred Moser wrote:
>>> Agreed... if you think now is a good time, I am happy to update the Takari
>>> repos with a redirect to the maven dev list and the sandbox repo for now.
>>>
>>> I plan to close all issues and all PR and declare the project inactive and
>>> moved to Apache Maven upstream. Just not sure what the best timing for that
>>> is.
>>>
>>> And in terms of getting the scripts in a separate repo or Maven core ... I
>>> see
>>> good reasons for both and dont really have a preference. I just would love 
>>> to

Re: Maven Pom Property replacement - possible bug?

[Bernd Eckenfels]

Hello,

I don't think it's expected that those properties are replaced as it is not 
documented. But I think it's specific to some known suffixes (GoupId). If you 
can add a "Custom" or similar keyword it might help.

I think the expansion can be avoided with ${dollar}{someGroupID} but it might 
depend on how often the plugin interpolates it. Haven't tried it, though.

Bernd


--
http://bernd.eckenfels.net

Von: Nick Stolwijk 
Gesendet: Wednesday, February 5, 2020 2:32:28 AM
An: Maven Developers List 
Betreff: Fwd: Maven Pom Property replacement - possible bug?

Hi list,

I send this e-mail last week to the userlist, but haven't heard back yet.

Do you think this is a bug or a user error?

With regards,

Nick Stolwijk

~~~ Try to leave this world a little better than you found it and, when
your turn comes to die, you can die happy in feeling that at any rate you
have not wasted your time but have done your best ~~~

Lord Baden-Powell


-- Forwarded message -
From: Nick Stolwijk 
Date: Fri, Jan 31, 2020 at 4:01 PM
Subject: Maven Pom Property replacement - possible bug?
To: Maven Users List 


Hi list,

I've seen some strange behavior with pom property replacement and I was
wondering if this is a bug or expected behaviour.

I have a sample project[1] with the build-helper-maven-plugin which I try
to configure to use the regex-property goal.

Since Java 7 the Regexp matcher of Java understands named groups, but they
use the same notation as Maven properties, i.e. ${name}

I tried:

org.codehaus.mojo
build-helper-maven-plugin

  ${regexVersion}${regexGroupId}



I expected Maven to not touch my variables if it couldn't replace them. So
I was a little confused when I executed mvn -X and saw the following output:

[DEBUG]   (f) replacement = ${regexVersion}null

It looks like Maven didn't touch the first variable but it replaced the
second with null.

First question: is this expected behaviour?
Second question: how can I escape variables so that Maven doesn't try to
escape them?

[1] https://github.com/nickstolwijk/MavenPropReplacement.git

With regards,

Nick Stolwijk

~~~ Try to leave this world a little better than you found it and, when
your turn comes to die, you can die happy in feeling that at any rate you
have not wasted your time but have done your best ~~~

Lord Baden-Powell

Re: Prevent maven-release-plugin from reformatting attributes on project element

[Bernd Eckenfels]

For the declaration element we took the easy route and use the single line 
element as it gets regenerated by the release.

 This is actually a good thing it contains absolutely nothing of value, so 
wasting only one line is ok (you just must get over the need of printing it on 
paper ,)


--
http://bernd.eckenfels.net

Von: Eric Lilja 
Gesendet: Tuesday, February 4, 2020 7:35:01 PM
An: Maven Developers List 
Betreff: Re: Prevent maven-release-plugin from reformatting attributes on 
project element

Sure! Today I did a release in a single module project. The unwanted diff
was that the release plugin changed


http://maven.apache.org/POM/4.0.0; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>

to


http://maven.apache.org/POM/4.0.0; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="
http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>

So it discarded our formatting (which had a linebreak after the
xmlns:xsi-attribute and aligned xsi:schemaLocation-attribute, column-wise,
with the xmlns-attribute, in case formatting is lost in the email) and put
all attributes on the same line as its containing element (element
"project", in this case).

I don't know if it happens only for this element or not, in our pom-files,
that is usually the only element that has so many attributes that our
formatter line splits it.

We're trying to make sure formatting is always correct in our code-base, to
get rid of unwanted noise in git diffs to make reviews smaller, that's why
this is a slight nuisance to us.

The release was done on Linux machine. All files have unix-style line
breaks, indentation is four spaces.

- Eric L

On Tue, Feb 4, 2020 at 6:47 PM Hervé BOUTEMY  wrote:

> can you provide an example of reformatting, please?
>
> in every case I saw until now, there is no reformatting, so I suppose
> you're
> in a case I did not expect
>
> Regards,
>
> Hervé
>
> Le mardi 4 février 2020, 16:24:54 CET Eric Lilja a écrit :
> > > I see.
> > > I am not aware of any such feature.
> > > If you have some tool that pretty prints XML according to your
> > > comporate rules you could invoke it in completionGoals [1]
> >
> > That could be a workaround for now. Thanks!
> >
> > - Eric L
> >
> > > Enrico
> > >
> > > [1]
> > >
> http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.ht
> > > ml#completionGoals
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Prevent maven-release-plugin from reformatting attributes on project element

[Bernd Eckenfels]

It is quite likely that it was fixed/changed and we never fixed the broken 
indentions in existing poms, that's why I am still reminded of it :) I will 
test later.


--
http://bernd.eckenfels.net

Von: Eric Lilja 
Gesendet: Tuesday, February 4, 2020 8:41:03 PM
An: Maven Developers List 
Betreff: Re: Prevent maven-release-plugin from reformatting attributes on 
project element

Ah, yes, I do remember the changed indentation of the tag element in the
past, put I don't recall seeing that lately. Have to check tomorrow when I
get to the office.

Bernd: Which version of the maven-release-plugin did you use?

- Eric L

On Tue, Feb 4, 2020 at 8:30 PM Bernd Eckenfels 
wrote:

> Hm, for me it keeps the line breaks, it does however change the intention
> for the tag element. I thought this was configurable, but can't find it at
> the moment.
>
> Anyway this is an open (and rejected) issue:
> https://issues.apache.org/jira/browse/MRELEASE-1008
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> Von: Eric Lilja 
> Gesendet: Tuesday, February 4, 2020 3:21:51 PM
> An: Maven Developers List 
> Betreff: Prevent maven-release-plugin from reformatting attributes on
> project element
>
> Hi, we noticed that maven-release-plugin changes formatting of the project
> element, it writes the element as a single line, removing existing line
> breaks on attributes. Is it possible to make it preserve original
> formatting?
>
> We're using maven-release-plugin version 3.0.0-M1
>
> - Eric L
>

Re: Prevent maven-release-plugin from reformatting attributes on project element

[Bernd Eckenfels]

Hm, for me it keeps the line breaks, it does however change the intention for 
the tag element. I thought this was configurable, but can't find it at the 
moment.

Anyway this is an open (and rejected) issue: 
https://issues.apache.org/jira/browse/MRELEASE-1008

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Eric Lilja 
Gesendet: Tuesday, February 4, 2020 3:21:51 PM
An: Maven Developers List 
Betreff: Prevent maven-release-plugin from reformatting attributes on project 
element

Hi, we noticed that maven-release-plugin changes formatting of the project
element, it writes the element as a single line, removing existing line
breaks on attributes. Is it possible to make it preserve original
formatting?

We're using maven-release-plugin version 3.0.0-M1

- Eric L

Re: Profiles, builds, and repositories

[Bernd Eckenfels]

Hello,

Yes profiles can severely affect the content of a build artifact and there is 
no way to tell the used profile in the Maven repo. This is generally the reason 
why it should not be used to influence the released build artifacts and can 
also not be relied upon.

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Elliotte Rusty Harold 
Gesendet: Friday, January 24, 2020 6:22:17 PM
An: Maven Developers List 
Betreff: Profiles, builds, and repositories

Is it possible for a profile to materially affect what gets installed
in a repository, particularly the central repo?

I'm not concerned about minutiae like builds times and other details
the reproducible build work is concerned with. I'm talking about more
major things like which classes are and are not in a jar.

My gut is that this is possible because profiles can change plugins
and plugins can do pretty much anything. Assuming that's so, is there
a way to tell from the data in the repo which profile was used to
create a particular artifact?

I'm particularly concerned about dependencies. Profiles can change
dependencies, so the runtime and compile time classpath might depend
on the active profile.


--
Elliotte Rusty Harold
elh...@ibiblio.org

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

Re: is macen repo down?

[Bernd Eckenfels]

Please  send the error message as text, the image seems not to be received via 
the mailing list. (Although Maven central repository is not managed on this 
list)


--
http://bernd.eckenfels.net


Von: Alexius Diakogiannis 
Gesendet: Freitag, November 29, 2019 7:36 PM
An: Maven Developers List
Betreff: is macen repo down?

Hi,

I am getting this error message
[image.png]

do you see anything similar?


Alexius Diakogiannis, CSM
Archer / Linux Lover / Java Geek

About me: https://about.me/diakogiannis/
Linked In: https://www.linkedin.com/in/diakogiannis/
Blog:  https://www.jee.gr
PGP Pub Key: https://pgp.key-server.io/0x669822139B6027AC

[Mailtrack] 

   Sender notified by
Mailtrack
 11/29/19, 08:36:25 PM

Re: [SUMMARY] 3 ITs permanently fail on Linux / Maven Core

[Bernd Eckenfels]

Well, the Maven project is not the only one who wants to ensure repeatable 
builds and may be surprises by things like that. It certainly would be a 
safeguard for anybody interested in explizit configurations for CI jobs.


--
http://bernd.eckenfels.net


Von: Robert Scholte 
Gesendet: Sonntag, August 4, 2019 8:26 PM
An: Maven Developers List
Betreff: Re: [SUMMARY] 3 ITs permanently fail on Linux / Maven Core

No, there's no need for that and it would over-complicate the scripts.
mavenrc can be handy, but only at INFRA level.

As said, we were able to fix it on the project-level. The project simply
wasn't aware of
- side effects and impact of creating this file on Jenkins
- the existence of .mvn/jvm.config

Robert

On Sun, 04 Aug 2019 18:51:52 +0200, Bernd Eckenfels
 wrote:

> Do we need a Maven Option to turn of processing of implicit
> configurations, just like you can turn of shellrc Files?
>
>
> --
> http://bernd.eckenfels.net
>
> 
> Von: Robert Scholte 
> Gesendet: Samstag, August 3, 2019 9:12 PM
> An: Maven Developers List
> Betreff: [SUMMARY] 3 ITs permanently fail on Linux / Maven Core
>
> Here's a very short summary and conclusion about what happened the last
> period.
>
> Half July some integration tests of Maven started to fail, but not always
> (it good happen that a certain JDK would succeed again with the next
> run).
> At that time we only noticed:
> - it failed only on the Linux nodes of Jenkins.
> - the failing tests were using MAVEN_OPTS
>
> It took quite a while, but in the end Hervé discovered the root cause:
> - On some nodes there was an unexpected ${user.home}/.m2/.mavenrc file
> that set the value of MAVEN_OPTS
>
> INFRA discovered that it was the incubator-shardingsphere that created
> this file when building there project.
>
> We've provided a PR for this project together with an explanation. This
> PR
> has been accepted and INFRA has removed the .mavenrc files.
>
> Over the past weeks a lot of changes has been done to the code for
> investigation.
> All changes that were done to change the behavior related to environments
> variables and mavenrc file should and will be reverted.
> Mavens master branch was stable, so to ensure the right things are still
> tested the need to be restored (some of them did indeed test the
> MAVEN_OPTS explicitly as issued in its JIRA).
> In general we don't change ITs, we only extend then and provide a range
> to
> control for which Maven versions the test is valid.
>
> Details and discussions can be found on the slack channel.
>
> thanks,
> 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

Re: [SUMMARY] 3 ITs permanently fail on Linux / Maven Core

[Bernd Eckenfels]

Do we need a Maven Option to turn of processing of implicit configurations, 
just like you can turn of shellrc Files?


--
http://bernd.eckenfels.net


Von: Robert Scholte 
Gesendet: Samstag, August 3, 2019 9:12 PM
An: Maven Developers List
Betreff: [SUMMARY] 3 ITs permanently fail on Linux / Maven Core

Here's a very short summary and conclusion about what happened the last
period.

Half July some integration tests of Maven started to fail, but not always
(it good happen that a certain JDK would succeed again with the next run).
At that time we only noticed:
- it failed only on the Linux nodes of Jenkins.
- the failing tests were using MAVEN_OPTS

It took quite a while, but in the end Hervé discovered the root cause:
- On some nodes there was an unexpected ${user.home}/.m2/.mavenrc file
that set the value of MAVEN_OPTS

INFRA discovered that it was the incubator-shardingsphere that created
this file when building there project.

We've provided a PR for this project together with an explanation. This PR
has been accepted and INFRA has removed the .mavenrc files.

Over the past weeks a lot of changes has been done to the code for
investigation.
All changes that were done to change the behavior related to environments
variables and mavenrc file should and will be reverted.
Mavens master branch was stable, so to ensure the right things are still
tested the need to be restored (some of them did indeed test the
MAVEN_OPTS explicitly as issued in its JIRA).
In general we don't change ITs, we only extend then and provide a range to
control for which Maven versions the test is valid.

Details and discussions can be found on the slack channel.

thanks,
Robert

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

Re: JDK 13 - Early Access build 17 is available

[Bernd Eckenfels]

How is that related to Maven Development? You should discuss the OpenJDK 
release policy on the OpenJDK mailing lists and join one of the many 
interesting OpenJDK projects: https://openjdk.java.net/contribute/

For the record, I don’t agree with your assessment of new features in the 
latest Java releases but in respect for this mailing list I refrain from 
discussing it.

Gruss
Bernd




--
http://bernd.eckenfels.net


Von: Tibor Digana 
Gesendet: Freitag, April 19, 2019 11:04 PM
An: Maven Developers List
Betreff: Re: JDK 13 - Early Access build 17 is available

Hi Enrico, the ORA could do what we usually do with features -> preview
features in minor version release as experimental releases: 10.1, 10.2,
10.3, and then one big release with latest greates version. And bug fixes
in 10.1.1, 10.1.2, etc.

On Fri, Apr 19, 2019 at 10:31 PM Enrico Olivelli 
wrote:

> Tibor,
> I suggest ou to take a look to some of the great talk from Mark R, Java
> cheif architect
>
> https://youtu.be/eOWsEHibxbU
>
>
> Enrico
>
>
> Il ven 19 apr 2019, 22:21 Tibor Digana  ha
> scritto:
>
> > Sorry guys but again, what did you change in the language?
> > Some Japaneese java.time support, some deprecations, ...
> >
> > Why the language architect does not bring something new? You wanted to
> > improve Generics. C# has features like s/getter, and Java has not.
> >
> > But this is weaker release than Java 1.6 addons and 1.6 was very weak
> > release.
> > I don't see any significant change between Java 9 and 13 because I can
> > simply skip 4 versions...
> >
> > Does it make sense to cut a release because you have to that you have
> > milestones and your manager needs to?
> > Developer normally does not care about hardware switches in jvm.
> >
> > Cheers
> > Tibor
> >
> > On Fri, Apr 19, 2019 at 2:41 PM Rory O'Donnell  >
> > wrote:
> >
> > >
> > > *Hi Robert , *
> > >
> > > *OpenJDK builds *- JDK 13 - Early Access build 17 is available at
> > > http://jdk.java.net/13/
> > >
> > > * These early-access , open-source builds are provided under the
> > > o GNU General Public License, version 2, with the Classpath
> > > Exception .
> > > * Changes in this build
> > > <
> > >
> >
> http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B16%22%3A%3A%22jdk-13%2B17%22-%22jdk-13%2B16%22%29=1000
> > > >
> > > * Release notes [1]
> > >
> > > *Significant changes since the last availability email*
> > >
> > > * build 16 - Update the default enabled cipher suites preference
> > > (JDK-8163326 )
> > > * build 16 - Add new keytool -showinfo -tls command for displaying
> TLS
> > > configuration information (JDK-8219861
> > > )
> > > * build 15 -*New Japanese Era Name **(JDK-8205432
> > > )*
> > > * build 15 - Accessing REIWA era in java.time.chrono.JapaneseEra
> > > (JDK-8174268 )
> > > * build 15 - Duplicated RSA services are no longer supported by
> > > SunJSSE provider (JDK-8220016
> > > )
> > > * build 15 - Use server cipher suites preference by default
> > > (JDK-8168261 )
> > > * build 15 - The Swing Motif Look and Feel is deprecated and
> > > unsupported on macOS (JDK-8177960
> > > )
> > > * build 15 - Remove support for javadoc "frames" mode (JDK-8215599
> > > )
> > >
> > > Bug fix reported by Open Source Projects :
> > >
> > > * build 15 - Unable to read certain PKCS12 keystores from
> > > SequenceInputStream (JDK-8157404)
> > > 
> > >
> > > *April 2019 CPU Released*
> > >
> > > * As part of the Apr 2019 Critical Patch Update we released OpenJDK
> > > 12.0.1 under the GNU General Public License, version 2, with the
> > > Classpath Exception .
> > [2]
> > > * One change previously announced in the Java Cryptographic Roadmap
> [3]
> > >
> > > *Request for feedback *- switch expressions in JDK 12 , feedback via
> > > amber-dev list [4]
> > >
> > > Rgds,Rory
> > >
> > > [1] http://jdk.java.net/13/release-notes
> > > [2] http://jdk.java.net/12
> > > [3] https://java.com/en/jre-jdk-cryptoroadmap.html
> > > [4]
> > https://mail.openjdk.java.net/pipermail/jdk-dev/2019-April/002770.html
> > >
> > > --
> > > Rgds, Rory O'Donnell
> > > Quality Engineering Manager
> > > Oracle EMEA, Dublin, Ireland
> > >
> > >
> >
>

Re: Ojdbc7 dependency issue

[Bernd Eckenfels]

You need to talk to Oracle about this. They do not upload the artifacts and the 
license does not allow it.

There is btw a WebLogic Repository at Oracle which does contain the driver 
(under a rather strange coordinate).

Since you must run your own Repository anyway to have reliable and repeatable 
builds you would normally just upload the driver there.

Gruss
Bernd

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: Paul Hammant 
Gesendet: Samstag, März 16, 2019 3:20 PM
An: Maven Developers List
Betreff: Re: Ojdbc7 dependency issue

Does 'central' need to be immutable though? Feels like an arbitrary policy
to me. Or should there be workflows to remove items from there, and replace
with a 302? While that could be to repos elswhere, they could also be to
HTML pages with mvn.exe handling that and communicating that clearly in the
build log.

Some ten years ago a mal-configured WebSense at an airline was flling a
corporate Maven cache jars and poms suffixes that were actually HTML error
pages. Maven choked silently then and I'm not sure it has ever been fixed.
In a quick test now, if I do "ls > ~/.m2/repository/foo/bar/baz.pom" (and
jar), the build fails with a proximate cause message. The jars and poms are
not checked again for correctness once in the cache. Anyway the jar/pom
ingesting side of Maven could easily handle deprecation, obsolesence and
outright deletion better than it does.

AW: Fwd: FOSDEM 19 Debian Java talk

[Bernd Eckenfels]

Hello,

according to the Apache Release Policy a release is the source and while it 
allows and defines convinience binaries there is not really a Notion of 
„official binaries“ from the ASF Point of view. So Maybe the new property 
should be something like „binary Vendor“ or „packager“ (similiar what many 
package Managers have?)

I think the number of additional support Problems because of distribution 
specific packages and the number of solved Problems by distributions doing a 
good Integration Job can not be clearly tallied.

And therefore I would stay away from language like „modified“, „official“ to 
avoid those Groups to feel unwelcome (especially in the ASF spirit of open 
SOURCE).

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Von: Michael Osipov
Gesendet: Mittwoch, 13. Februar 2019 19:36
An: Maven Developers List; Robert Scholte; Dalibor Topic; Markus Koschany
Cc: debian-j...@lists.debian.org; Matthias Klose
Betreff: Re: Fwd: FOSDEM 19 Debian Java talk

Am 2019-02-12 um 20:09 schrieb Robert Scholte:
> On Tue, 12 Feb 2019 12:34:56 +0100, Markus Koschany  wrote:
> 
>> Hello,
>>
>> Dalibor Topic (Oracle) and Robert Scholte (Apache Maven) contacted me
>> and were so kind to agree to make this discussion public, so that others
>> can chime in too. I would like to use the opportunity to answer the
>> initial question "what we are interested in seeing better supported from
>> build tools" and give some general feedback about integrating Java into
>> Debian.
>>
>>
>> First of all Ant and Maven are most likely the best supported build
>> systems at the moment. We carry only two patches for Maven, one because
>> we use a newer version of SLF4j [1] and the second one is to make Maven
>> builds reproducible. [2] It looks like [1] has been already merged
>> upstream but [2] has not been forwarded yet. It would be great of
>> course, if Maven builds would be reproducible out-of-the-box. In general
>> I would like to see reproducible builds everywhere.
> 
> Hi Markus,
> 
> first of all thanks for the insights, it is important for us to know how 
> Maven is used and in which way we can improve that way-of-work. Hervé is 
> already working hard on the reproducible builds specs with your team in 
> order to find out how we can improve our maven-plugins to get 
> reproducible artifacts.
> 
> Maven itself is not 100% reproducible. We've learned that some Linux 
> vendors rebuild Maven and the presentation confirmed that Debian is one 
> of those vendors. What we've seen in the past is that sometimes people 
> are having issues with Maven and after a while we discovered that they 
> were not using the official Apache Maven distribution[1]. For us it is 
> quite easy to say: sorry, not our official distribution, please contact 
> your Linux distributor.
> In such case we have 3 losers: the user, the Apache Maven project and 
> the Linux Distributor. If only the official Maven distribution was used, 
> then we would have had 3 winners.
> 
> When you decide to rebuild Maven, you're also taking all related 
> responsibilities. I'm also wondering how you build Maven, since Maven is 
> being built with Maven. That should be a challenge to also rebuild all 
> plugins, etc.
> And how do you test this and confirm that it works as the official 
> distribution?
> Sure, *IF* Maven is 100% reproducible then you can rely on our 
> test-infra, but that's not the situation.
> 
> So here are my main questions:
> - Are you making clear that you're not using the official Maven 
> distribution, e.g. by adjust the info from 'mvn --version'?

I expressed my proposal to Hervé that we need a new property: 
maven.vendor. Our official distribution will carry the value: ASF. 
Everyone else who modifies the content must change the value in the 
build.properties. Thus, we will quickly know that this distro has been 
modified by someone else.

Michael


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

Re: Update versions of all plugins in default-bindings.xml

[Bernd Eckenfels]

I think that’s a real bad idea if you have to do local modifications to get to 
a working build environment. Maven is all about not requiring you to do that 
(anymore). So even requiring a certain Maven Version does not fit in that 
pattern (although unavoidable if you do not want to work with wrappers).

So this means: keep old standard versions and overwrite them always in poms. 
(And it means the amount of default versions should be reduced or at least not 
add new ones)

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: Robert Scholte 
Gesendet: Samstag, Januar 12, 2019 5:07 PM
An: Maven Developers List
Betreff: Re: Update versions of all plugins in default-bindings.xml

I had chats with both Adam Bien and Sebastian Daschner asking for a better
way to work with a simple high-speed throw-away development pom.

They are both working a lot with Java EE applications and want to rely on
defaults as much as possible.
So in a way they don't care about plugin versions.
They only case about things in poms that does matter (unique to that
project): dependencies
However, with Java 9+ stuff they are forced to specify plugins with more
recent versions right now.

So here comes the idea of extensions: you can put it in your maven/lib/ext
ONCE and your pom is again as clean as possible.

This seems to be a common way of work for some kind of developers and it
would make sense if Maven could support this.

To me default plugin versions are bound to a minor Maven release, not a
major.
When starting with Maven and create your first hello world, it should work
out of the box.
Right now if you are using Java 11, you'll probably hit issues because
some defaults won't work anymore.
That's a bad thing to me and a valid reason to upgrade the plugins.

I do understand Hervé concerns. We should motivate people to lock their
plugins in their pom.
Most of all the packaging-plugin is important. AFAIK all 3.0+ versions
contain plugin bindings, in which case it should be good enough if that
plugin is at least specified.

thanks,
Robert

On Sat, 12 Jan 2019 16:24:31 +0100, Hervé BOUTEMY 
wrote:

> original idea, let's try to evaluate :)
>
> IMHO this could work for packaging plugins in default lifecycle, that are
> defined in default-bindings.xml, but would not for other lifecycles that
> are
> configured in components.xml (without copy/pasting content not related to
> plugins)
>
> I don't think an extension would be easier to use than a pom.xml, it's
> even
> IMHO worse since you have to create a new file in a new directory.
>
> one question is: is there a use case that an extension would permit that
> a
> parent pom would not?
> the only case I see is if a user does not want to change his parent pom
> (or
> cannot): since we don't have "pluginManagement import" (like we have for
> dependency management).
>
>
> I think for the moment that a parent pom would be more classical, easier
> to
> explain: I don't really see a clear benefit to do the job as an extension
> instead, this would IMHO make the change harder for users
>
> Regards,
>
> Hervé
>
> Le samedi 12 janvier 2019, 15:42:57 CET Robert Scholte a écrit :
>> Just wondering, can this be solved by an extension?
>>
>> So instead of changing this in Maven Core itself, people can add an
>> extension to Maven with the latest+stable releases.
>>
>> Hervé and I already discovered that current focus is mainly on plugins
>> right now. We should also work on extensions.
>>
>> Robert
>>
>> On Sat, 12 Jan 2019 15:37:23 +0100, Hervé BOUTEMY
>> 
>>
>> wrote:
>> > Le vendredi 11 janvier 2019, 12:55:03 CET Tibor Digana a écrit :
>> >> ok, Herve, the fact is that these plugins have been updated from
>> time to
>> >> time.
>> >
>> > yes, we did it in the past (years ago, look at the history) and went
>> to
>> > the
>> > conclusion we should not do that to improve reproducibility, unless
>> > there is a
>> > strong reason to do it sometimes on some specific plugins
>> > = what I'm trying to explain, for the moment without much success
>> >
>> >
>> > What we could do would be to create a new POM to use as parent POM,
>> that
>> > would
>> > define the versions of every plugin from the default lifecycles: this
>> > would
>> > avoid to have everybody to write the full list of plugins (which is a
>> > pain: I
>> > know because in MARCHETYPES-54 [1] I added the list in Maven
>> > Archetypes...)
>> > We could name it "maven-default-plugins", or if somebody has a better
>> > idea.
>> > This way, changing plugins versions would not be tied to changing
>> Maven
>> > version
>> >
>> > WDYT?
>> >
>> > Regards,
>> >
>> > Hervé
>> >
>> > [1] https://issues.apache.org/jira/browse/MARCHETYPES-54
>> >
>> >> How can we be on safe side with these updates? What is mandatory to
>> do
>> >> for
>> >> such upgrade?
>> >>
>> >> On Fri, Jan 11, 2019 at 7:41 AM Hervé BOUTEMY 
>> >>
>> >> wrote:
>> >> > As I wrote in many Jira issues over years on this topic, I'm not in
>> >>
>> >> favor
>> 

Re: JDK 11 Early Access build 12 available

[Bernd Eckenfels]

Value Objects are JEP 169 and part of Project Valhalla, there are quite a few 
projects coming at/after 11 (in the fast release model).

We already got local var types, lambda leftovers, (shadowing and underscore) 
and there are plans for switch expressions, pattern matching, generic enums and 
string literals. The language really is on the go. (Despite this being very 
complex)

http://openjdk.java.net/projects/amber/

And I am totally offtopic, sorry. I would recommend to check out the language 
architecture talks in the Oracle Code series.

Gruss
Bernd



Gruss
Bernd
--
http://bernd.eckenfels.net

From: Tibor Digana 
Sent: Wednesday, May 9, 2018 11:35:18 PM
To: dalibor topic
Cc: Maven Developers List; Robert Scholte; rory.odonn...@oracle.com; 
abdul.kolarku...@oracle.com; Balchandra Vaidya
Subject: Re: JDK 11 Early Access build 12 available

Thx Dalibor, I will try with -XX:-ShrinkHeapInSteps.
I still do not have the answer regarding language features. Why Oracle did
not implement more language improvements after Java 1.8?
For instance value objects. Is this in 9, 10 or 11? I could not find it.
What about descriptive language and features? Is it possible in Java?

On Wed, May 9, 2018 at 8:28 PM, dalibor topic 
wrote:

>
>
> On 08.05.2018 11:36, Tibor Digana wrote:
>
>> Is there any JVM which "shrinks" at least shrinks the native memory
>> consumption so that the Java Heap is cca == Native Consumption at most of
>> the time?
>>
>
> I hope that the information in https://docs.oracle.com/javase
> /10/gctuning/factors-affecting-garbage-collection-performanc
> e.htm#JSGCT-GUID-7FB2D1D5-D75F-4AA1-A3B1-4A17F8FF97D0 is helpful in that
> regard.
>
> cheers,
> dalibor topic
>
>
> --
>  Dalibor Topic | Principal Product Manager
> Phone: +494089091214  | Mobile: +491737185961
> 
>
> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 H
> 
> amburg
>
> ORACLE Deutschland B.V. & Co. KG
> Hauptverwaltung: Riesstr. 25, D
> -80992
> München
> Registergericht: Amtsgericht München, HRA 95603
>
> Komplementärin: ORACLE Deutschland Verwaltung B.V.
> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
> Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
>
>  Oracle is committed to developing
> practices and products that help protect the environment
>

Re: Speeding up Maven

[Bernd Eckenfels]

Hello,

Maven is not the fastest, but in your case it sounds unusual slow. What are 
your machine specs? Any SSD? Do you happen to have a on-access malware scanner 
active? They react very bad to Java scanning large number of JAR files.

Gruss
Bernd

Gruss
Bernd
--
http://bernd.eckenfels.net

From: Mark Raynsford 
Sent: Friday, April 13, 2018 11:21:33 PM
To: Paul Hammant
Cc: Maven Developers List
Subject: Re: Speeding up Maven

On 2018-04-13T16:29:27 -0400
Paul Hammant  wrote:

> Mark,
>
> Assuming a pre-filled Maven local cache, I've a 16 second build that's only
> longer when I run a screen recorder in order to make the video show here -
> https://paulhammant.com/2017/02/05/a-16-second-java-webapp-build-including-webdriver-tests/
>
> That one runs three WebDriver tests too after the unit and service tests -
> meaning (implicitly) it's testing JavaScript as well as Java in that time.
>
> In order to make it fast I've abandoned the fail-safe plugin and do all
> parts of the test-pyramid in surefire (see the pom).

'Ello.

So you're saying it's my problem? ;)

I'm also assuming a pre-filled Maven local cache, but this example
project (with no dependencies) takes about six seconds to build with
(usually) about ten seconds of Maven churning before the build even
begins. This is for a build that compiles one tiny file, produces a
jar, and does nothing else.

I assumed that it was happening for everyone, but apparently it isn't.

--
Mark Raynsford | http://www.io7m.com

[MJAR] please add MJAR-238 to jigsaw status as an open bug

[Bernd Eckenfels]

Hello,

On the Jigsaw-status page, it would be good to Add the Status of the m-jar-p, 
especially https://issues.apache.org/jira/browse/MJAR-238 which blocks it to be 
used for Setting the main Class of a modular JAR.

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

The Thing has quite a few discussions, for example here:

https://stackoverflow.com/questions/43671410/how-to-specify-main-class-and-module-version-in-maven-jar-plugin

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Re: Security related metadata

[Bernd Eckenfels]

There is the problem of missing CPE/maven-coordinates mappings. 
owasp,dependency check can work around that only with crude heuristics. 
Therefore it would be at least nice if we can add a CPE to the POM (or define 
an official mapping to CPEs, but last time I tried to address that on different 
lists nobody really agreed)

Having a standard way to attach annotations might do the whole eco system a 
favor.

Gruss
Bernd

Gruss
Bernd
--
http://bernd.eckenfels.net

From: Hervé BOUTEMY 
Sent: Wednesday, March 14, 2018 11:48:35 PM
To: Maven Developers List
Subject: Re: Security related metadata

using a plugin like OWASP Dependency-Check (or any other tool like it), and
its dedicated security issues storage and update workflow, avoid adding a new
management nightmare at every level of Maven

Regards,

Hervé

Le mercredi 14 mars 2018, 13:27:53 CET Jochen Wiedmann a écrit :
> Hi,
>
> recently I had an issue, where a security problem was claimed, because
> a published POM was using a jar version, for which a CVE exists. The
> reporter requested to upgrade to a current version, and publish an
> updated POM.
>
> As you know, we cannot update the POM. We only publish new POM's, so
> the case resulted in publication of a new version. However, this case
> got me thinking:
>
> 1.) Whether we like it, or not, the published POM is an artifact, that we
> have to maintain. (And, in the case of the ASF: For which we might be
> legally responsible.)
> 2.) Knowing, that one can exclude the jar file in question in a
> downstream POM, is not sufficient. You've got to know, that there is a
> problem.
>
> Point one is a simple statement of fact. Nothing much to do
> here.Regarding point two, however: Here's something, that the Maven
> world could do better.
>
> My suggestion would be:
>
>   a) Introduce a new artifact (say --issues.xml).
>
>   The idea would be, to publish such an artifact, if an issue with the
> jar, war, or whatever file (the original artifact, without
> classifier) has been
>detected.
>
>   b) On occasion, Maven would check, whether there is an issues file
> for a dependency. If so, it would issue a warning, break the build, or
> do whatever seems appropriate.
>   Of course, this action would be done in a plugin, which might be
>   skipped.
>
> Leaving out questions like update of an issues file (There might be
> other issues, later on, or more serious issues.), I think this should
> be doable with moderate efforts.
>
> Jochen
>
> -
> 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: [m-jlink-p] NPE for small project

[Bernd Eckenfels]

Hello,

just found that this is a known and fixed issue: 
https://issues.apache.org/jira/browse/MJLINK-4

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Von: Bernd Eckenfels
Gesendet: Freitag, 9. März 2018 01:37
An: Maven Developers List
Betreff: [m-jlink-p] NPE for small project

Hello,

when I use a simple POM like this:

http://maven.apache.org/POM/4.0.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
    4.0.0
    
    
   com.soebes.smpp
   smpp
   2.3.0
    
    
    net.eckenfels.etotp
    et-otp-image
    1.3-SNAPSHOT
    jlink

    
   
UTF-8
    

    
   
   
   
maven-jlink-plugin
   
3.0.0-alpha-1
   
true
   
   
true
   
   
   
    

    
   
   
net.eckenfels.etotp
   et-otp
   1.3-SNAPSHOT
   
    




The jlink plugin will crash with a NPE unless I add the soebbes parent.

Not sure whats different (it does not seem to Change any shared component 
versions).

Here is the NPE:

3153 [WARN] The POM for net.eckenfels.etotp:et-otp:jar:1.3-SNAPSHOT is missing, 
no dependency information available
3153 [INFO]
3153 [INFO] --- maven-jlink-plugin:3.0.0-alpha-1:jlink (default-jlink) @ 
et-otp-image ---
3591 [INFO] Toolchain in maven-jlink-plugin: jlink [ C:\Program 
Files\Java\jdk-9.0.4\bin\jlink.exe ]
3591 [INFO] 

3591 [INFO] BUILD FAILURE
3591 [INFO] 

3591 [INFO] Total time: 1.741 s
3591 [INFO] Finished at: 2018-03-09T01:34:58+01:00
3691 [INFO] Final Memory: 8M/28M
3691 [INFO] 

3691 [ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink (default-jlink) 
on project et-otp-image: Execution default-jlink of goal 
org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink failed. 
NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink (default-jlink) 
on project et-otp-image: Execution default-jlink of goal 
org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink failed.
    at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
    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:116)
    at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
    at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
    at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
    at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:564)
    at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
    at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(L

[m-jlink-p] NPE for small project

[Bernd Eckenfels]

Hello,

when I use a simple POM like this:

http://maven.apache.org/POM/4.0.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0


com.soebes.smpp
smpp
2.3.0


net.eckenfels.etotp
et-otp-image
1.3-SNAPSHOT
jlink



UTF-8





maven-jlink-plugin
3.0.0-alpha-1
true

true







net.eckenfels.etotp
et-otp
1.3-SNAPSHOT






The jlink plugin will crash with a NPE unless I add the soebbes parent.

Not sure whats different (it does not seem to Change any shared component 
versions).

Here is the NPE:

3153 [WARN] The POM for net.eckenfels.etotp:et-otp:jar:1.3-SNAPSHOT is missing, 
no dependency information available
3153 [INFO]
3153 [INFO] --- maven-jlink-plugin:3.0.0-alpha-1:jlink (default-jlink) @ 
et-otp-image ---
3591 [INFO] Toolchain in maven-jlink-plugin: jlink [ C:\Program 
Files\Java\jdk-9.0.4\bin\jlink.exe ]
3591 [INFO] 

3591 [INFO] BUILD FAILURE
3591 [INFO] 

3591 [INFO] Total time: 1.741 s
3591 [INFO] Finished at: 2018-03-09T01:34:58+01:00
3691 [INFO] Final Memory: 8M/28M
3691 [INFO] 

3691 [ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink (default-jlink) 
on project et-otp-image: Execution default-jlink of goal 
org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink failed. 
NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink (default-jlink) 
on project et-otp-image: Execution default-jlink of goal 
org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink failed.
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
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:116)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
default-jlink of goal 
org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink failed.
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 19 more
Caused by: java.lang.NullPointerException
at 
org.codehaus.plexus.languages.java.jpms.ResolvePathsRequest$1.toPath(ResolvePathsRequest.java:52)
at 
org.codehaus.plexus.languages.java.jpms.ResolvePathsRequest$1.toPath(ResolvePathsRequest.java:48)
at 

Re: [VOTE] Release Apache Maven PDF Plugin version 1.4

[Bernd Eckenfels]

Hello,

(Not a Release showstopper I guess)

There is some text about maven3 report shortcomings which has a jira link which 
is marked as fixed, maybe the documentation needs an update, too?

https://issues.apache.org/jira/browse/MPDF-41
https://gitbox.apache.org/repos/asf?p=maven-pdf-plugin.git;a=blob;f=src/site/xdoc/examples/configuring-reports.xml.vm;h=1fcfbd17a69a3cec133a2f0a77de55bc59e9007a;hb=d7cec4572fdaecc0d6e0438cc77db4e55319dc00

Also the old SVN version is available on Git/github mirrors, it should maybe 
have a URL to the gitbox Repository?

https://github.com/apache/maven-plugins/blob/trunk/maven-pdf-plugin/MOVED_TO_GIT

Gruss
Bernd

Gruss
Bernd
--
http://bernd.eckenfels.net

From: Hervé BOUTEMY 
Sent: Friday, December 22, 2017 10:11:32 AM
To: Maven Developers List
Subject: [VOTE] Release Apache Maven PDF Plugin version 1.4

Hi,

We solved 12 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?
projectId=12317620=1238=Text

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

Staging repo:
https://repository.apache.org/content/repositories/maven-1385/
https://repository.apache.org/content/repositories/maven-1385/org/apache/
maven/plugins/maven-pdf-plugin/1.4/maven-pdf-plugin-1.4-source-release.zip

Source release checksum(s):
maven-pdf-plugin-1.4-source-release.zip sha1:
88d2d254e674938b197df6b37b54c75ec817fcf4

Staging site:
https://maven.apache.org/plugins-archives/maven-pdf-plugin-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1

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

AW: Maven 4.0.0

[Bernd Eckenfels]

Hello,

Adding annotations and processor as a compiletime dependency sounds like a 
reasonable thing. It would however be cool if the JAR could describe which 
package needs to go on the classpath and which is processor impl. (and having a 
different artifact for runtime)

Gruss
Bernd

Von: Mark Derricutt
Gesendet: Sonntag, 5. November 2017 22:20
An: Maven Developers List
Betreff: Re: Maven 4.0.0

On 5 Nov 2017, at 10:42, Robert Scholte wrote:
I would like to drop strict scopes in general and give plugins the opportunity 
to depend on
specific scoped dependencies.
How would this help with annotations tho? The main issue I'm facing is having a 
standard m-c-p plugin definition in a parent ( or tile ) but needing different 
annotation processors used per project. With the current plugin, this means 
either listing them as standard dependencies and have them auto-scanned, and 
pollute the compilation classpath, or list every possible annotation processor 
dependency we may use in our projects in the parent, which is less than ideal.
I hope you are aware that modules already end up on the modulepath based on the 
moduledescriptor(s). So I don't see the need for this scope. (unless you have 
this wish that in the end Maven will create the module descriptor based on 
this, but I still think we shouldn't do that)
I remembered reading something about this, and assumed it was the case if there 
was a module-info.class, but what if its a standard jar with an 
Automatic-Module-Name header? Does that fall into the module path or classpath? 
Having control for this case may be useful.
I recognize this wish. The best solution is to make the dependency optional.
The problem with this is that the dependency is still on the classpath for say 
surefire, which can influence behaviour.
Mark

"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time." — Mark 
Reinhold.
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


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

Re: Building a Java9 project just using JDK9

[Bernd Eckenfels]

You recreate a limited modules JRE with jlink. Haven't tried it but maybe you 
can generate an image with Java.se.ee as root that way, too.

Gruss
Bernd
--
http://bernd.eckenfels.net

From: Tibor Digana 
Sent: Wednesday, August 16, 2017 8:28:02 AM
To: Maven Developers List
Subject: Re: Building a Java9 project just using JDK9

Btw. Can be JRE/JDK configures after installation in terms not doing these
things and so that non-modular application would have access to java.se.ee
by default?

And second question, which would be cool feature to have, is some script
which allows me to recreate a new JRE from installed one but much smaller
with the only *java.base* module and all binaries like *bin/modules, src,
jmods* sudenly become much smaller.

On Wed, Aug 16, 2017 at 8:19 AM, Tibor Digana 
wrote:

> Still I do not understand what is the difference between *all_system* and 
> *java.se.ee
> *.
> Is it a bug that proprietary package *jdk.incubator.httpclient* is in the
> warning? It looks like it wants to be exposed out of the jdk to our
> application which is not legal but then why jdk allows.
>
> On Wed, Aug 16, 2017 at 8:06 AM, Enrico Olivelli 
> wrote:
>
>> Il mer 16 ago 2017, 02:44 Tibor Digana  ha
>> scritto:
>>
>> > Hi Enrico,
>> >
>> > It does not appear on console output however it is stored as native
>> std/out
>> > in target/surefire-reports/2017-08-13T23-52-13_184.dumpstream
>> >
>>
>> Yep, it is as I suspected. If we want ro get rid of it we have to only add
>> java.se.ee module
>>
>>
>> > On Tue, Aug 15, 2017 at 5:51 PM, Enrico Olivelli [via Maven] <
>> > ml+s40175n5912520...@n5.nabble.com> wrote:
>> >
>> > > Il dom 13 ago 2017, 17:31 Tibor Digana <[hidden email]
>> > > > ha
>> > > scritto:
>> > >
>> > > > I found an issue. JDK printed this on std/out:
>> > > > WARNING: Using incubator modules: jdk.incubator.httpclient
>> > > >
>> > >
>> > > IMHO This is because we are importing all system modules. Maybe
>> importing
>> > > only java.se.ee would cover most of the cases.
>> > > I did not notice the warning on test I have run today
>> > >
>> > > Enrico
>> > >
>> > >
>> > > > It hapens after my test:
>> > > >
>> > > > import org.junit.Test;
>> > > >
>> > > > public class J9Test
>> > > > {
>> > > > @Test
>> > > > public void testMiscellaneousAPI() throws java.sql.SQLException
>> > > > {
>> > > > System.out.println( "loaded class " +
>> > > > java.sql.SQLException.class.getName() );
>> > > > System.out.println( "loaded class " +
>> > > > javax.xml.ws.Holder.class.getName() );
>> > > > System.out.println( "loaded class " +
>> > > > javax.xml.bind.JAXBException.class.getName() );
>> > > > System.out.println( "loaded class " +
>> > > > org.omg.CORBA.BAD_INV_ORDER.class.getName() );
>> > > > System.out.println( "loaded class " +
>> > > > javax.xml.xpath.XPath.class.getName() );
>> > > > System.out.println( "java.specification.version=" +
>> > > > System.getProperty( "java.specification.version" ) );
>> > > > }
>> > > >
>> > > > @Test
>> > > > public void test_corba_mod() throws org.omg.CORBA.BAD_INV_ORDER
>> > > > {
>> > > > }
>> > > > }
>> > > >
>> > > >
>> > > > On Sun, Aug 13, 2017 at 5:29 PM, Tibor Digana <[hidden email]
>> > > 
>> > > > >
>> > > > wrote:
>> > > >
>> > > > > But why to add it? It's a hack. I do not use module-info.java and
>> so
>> > > > there
>> > > > > is no reason to break the backwards compatibility.
>> > > > >
>> > > > > This is no more about Maven. It is about entire Java world.
>> > > > > If we in Maven do it then everybody has to.
>> > > > > And I am sure that the voices says that Kotlin is better and
>> Scala is
>> > > > > better would make sense. Why to help these attempts to happen? No
>> > > reason!
>> > > > >
>> > > > > On Sun, Aug 13, 2017 at 5:11 PM, Gary Gregory <[hidden email]
>> > > >
>> > > > > wrote:
>> > > > >
>> > > > >> Is there a Maven way to add ALL-SYSTEM to everything? Using
>> plugin
>> > > > >> specific
>> > > > >> tags like below is going to be painful.
>> > > > >>
>> > > > >> Gary
>> > > > >>
>> > > > >> On Aug 13, 2017 07:30, "Tibor Digana" <[hidden email]
>> > > > wrote:
>> > > > >>
>> > > > >> > Hi @Enrico,
>> > > > >> >
>> > > > >> > I am very unhappy with Java 9 status and very afraid.
>> > > > >> > I do not like the style how Oracle has changed Java to Java 9
>> and
>> > > > forced
>> > > > >> > all the world to use additional effort to adapt to Oracle
>> > > activities.
>> > > > >> >
>> > > > >> > I am facing more unhappy Java development teams with Java 9 in
>> the
>> > > > >> future.
>> > > > >> > For instance as I have tried to 

Re: Taking Security Seriously

[Bernd Eckenfels]

Having artifact checksums (hashes not signatures) in POM dependency 
declarations would be cool, but that is not what .md5 or .asc is used for. 

Gruss
Bernd
-- 
http://bernd.eckenfels.net




On Mon, Dec 5, 2016 at 10:45 PM +0100, "Alexander Kjäll" 
 wrote:










Maybe we are talking about different attack scenarios?

The vector I would like to protect against is that someone is able to
inject false binaries in a caching nexus server (or over the network
if https is not used).

The way I envision the trust to be established is:

The developer goes either to maven central or the projects homepage
and copies the  block needed to add the dependency to
pom.xml. The dependency block includes information that can be used to
cryptographically guarantee that the binary that ends up in the build
is the same one that the original developer published.

I think it would be possible to simplify the verification of gpg
signatures and make it be possible to automate it in a resonable
manner.

best regards
Alexander Kjäll


2016-12-05 18:29 GMT+01:00 Hervé BOUTEMY :
> I fear the proposed change would not improve security but lower it:
> if the pom contains the reference to a key "to be used to sign the artifact",
> anybody wanting to change the content will just change the key reference to a
> value it owns
>
> yes, knowing which keys you should trust to sign which artifact is not easy,
> but I fear there is no automagic way to automate trust
>
> What I'd want to do is to improve the dependencies report to show the key used
> to sign the artifact: that would improve people knowledge of who they are
> trusting: but that would not mean that they can trust them...
>
> Regards,
>
> Hervé
>
> Le lundi 5 décembre 2016, 09:31:20 CET Alexander Kjäll a écrit :
>> Regarding verifying the gpg signature, as a contributor to the gpg
>> verify plugin here:
>>
>> http://www.simplify4u.org/pgpverify-maven-plugin/index.html
>>
>> I have some thoughts on why the current infrastructure doesn't really
>> help us to verify the signatures in practice:
>>
>> 1) Very hard to know what key are the correct one, as it's not specified
>> anywhere in the pom, you need to contact the developer of the jar that
>> you want to verify and ask them to publish what key they used to sign
>> the project with. It would be nice to have a  tag in the pom
>> in order to resolve this.
>>
>> 2) Verifying the signature can't really be done with a maven plugin, as
>> those are downloaded over the same channels that the jar's are
>> downloaded over, and there is no method for maven to verify that it
>> downloaded the correct plugin.
>>
>> I opened a bug about this problem a couple of years ago, but since it's
>> not really possible to fix this without changing the structure of the
>> pom i didn't even bother to write a patch for it.
>>
>> If there is a chance that a fix for this problem would be included, then
>> I would be happy to try to write a patch for it.
>>
>> best regards
>> Alexander Kjäll
>>
>> On 05. des. 2016 08:23, Hervé BOUTEMY wrote:
>> > AFAIK, checksums are there only to avoid stupid download/upload
>> > distorsion.
>> > What gives real security is *signature* done by developers, ie .asc files,
>> > that use other hash algorithms than these little .md5 and .sha1 files.
>> > That's why we recommend to verify *the signature* [1].
>> >
>> > Another topic: https://www.apache.org/dev/release-signing.html is not
>> > about
>> > Maven repository but is about Apache releases that are distributed as part
>> > of Apache official (source) releases, distributed by Apache mirrors [2]
>> >
>> > AFAIK, security is taken seriously: checksums are just not really part of
>> > that security, they are only checksums.
>> >
>> > Regards,
>> >
>> > Hervé
>> >
>> > [1] http://maven.apache.org/download.cgi
>> >
>> > [2] https://www.apache.org/mirrors/
>> >
>> > Le lundi 5 décembre 2016, 00:56:22 CET John Patrick a écrit :
>> >> Hiya,
>> >>
>> >> So currently checksum's are not generated by default... I've submitted
>> >> a ticket which switched the install plugin to generate them by
>> >> default.
>> >>
>> >> Next step stop using md5 which most have considered dead for several
>> >> years, and checking apache
>> >> (https://www.apache.org/dev/release-signing.html) sha512 should be
>> >> being used.
>> >>
>> >> So either;
>> >> 1) add support so md5, sha1, sha256 and sha512 are all generated
>> >> 2) plugin defines which is generated
>> >> 3) plugin defines a list which are generated
>> >> 4) settings.xml defines which is generated
>> >> 5) settings.xml defines a list which are generated?
>> >>
>> >> Thoughts???
>> >>
>> >> Next;
>> >> Currently when downloading we have ignore, warn or error if checksum's
>> >> don't match. I propose adding a checksum min level options? i.e. allow
>> >> MD5 > SHA1, SHA256 > SHA512
>> >>
>> >> So;
>> >> 1) Default to MD5
>> >> 2) Wait till all maven plugins deploy a sha512 to central
>> >> 3) Switch default to 

Re: Discussion: Resource-only artifacts

[Bernd Eckenfels]

Hello,

the proposal looks fine (if the scope system will be that open). How
would you differentiate between artifacts and artifact archives (i.e.
those you want to explode)?

BTW: just a usecase:

In our buildsystem I have POMs which produce articles which can contain
dozent of files. They are in a classifier=distribution type=zip file. An
aggregator project depends on them and unpacks them:

 
org.apache.maven.plugins
maven-dependency-plugin


create-distribution
package

unpack-dependencies



${project.build.directory}/distribution

junit,hamcrest-core
distribution
zip
false
groupId

true





So I only need to add a dependency to that classifier/type. Those
dependencies are in a POM. The only problem there is that I need to
define a wildcard exclude for each of them or the build step will pull
in all those transitive dependencies for no reason. When I import them
in a dedicated scope it would be good if that can be avoided (and
dependencies-plugin can still enumerate them)


groupX
permission-api
${version.groupX.permission-api}


*
*



...

Gruss
Bernd


 Am Thu,
18 Aug 2016 23:06:30 +0200 schrieb "Robert Scholte"
:

> On Thu, 18 Aug 2016 21:27:38 +0200, Paul Benedict
>  wrote:
> 
> > On Thu, Aug 18, 2016 at 11:53 AM, Robert Scholte
> >  wrote:
> >
> >> IMO any artifact with the compile-scope should end up on the
> >> classpath. If
> >> such artifact shouldn't end up there, that artifact should have a  
> >> different
> >> scope.
> >> All current scopes are related to the classpath, which is
> >> certainly too strict.
> >
> >
> > Agreed. So far, as of today, Maven only has scopes that relate to a
> > code.
> >
> >
> >> You've just described a case where a zip-file should not end up on
> >> the classpath, but it should have a scope recognizable by the  
> >> maven-war-plugin
> >> to understand what it should do with that artifact.
> >>
> >
> > Agreed, but only if your understanding of "do" includes do nothing.
> > I wouldn't expect the maven-war-plugin to assume it knows what to
> > do with my
> > resource-only artifacts. Do you think it should do something? And,
> > if so, is that a justifiable assumption?
> >
> 
> Based on my proposal of MPLUGIN-302 I would expect something like:
> 
> /**
>   * Content of archives is places in the root of the war
>   */
> @Dependencies( scope="overlay" )
> private List staticContentArchives;
> 
> The name of the scope could be anything. Since every plugin
> requiring artifacts must specify the scopes in which it is
> interested, plugin designer could choose its own scopes. It is up to
> us if we can identify commons usage of artifacts besides
> classpath(/modulepath) and can specify a general scope for it.
> 
> >> I don't think the types matter.
> >
> >
> > Sorry, I was unclear on my point. I was kind of straying onto a
> > different topic but it is closely related. Let me try again
> >
> > Since MNG-5567 is introducing a new "zip" type, POMs will then be
> > publishable with zip. Christian wisely noted
> > there are really two types of resources: archived (like a zip) and
> > non-archived (I'll call these "raw" for now). I'm just trying to
> > stretch my thoughts here and wonder aloud if the packaging type is
> > too specific --- should it really be about any resource in general?
> 
> Every packaging type has an ArtifactHandler which holds an Archiver
> and an UnArchiver (besides pom). Based on that you know what you can
> do with the resource and how to handle it.
> 
> Robert
> 
> >
> > Cheers,
> > Paul
> 
> -
> 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: Discussion: Resource-only artifacts

[Bernd Eckenfels]

Am Thu, 18 Aug 2016 14:27:38 -0500
schrieb Paul Benedict :
> Agreed, but only if your understanding of "do" includes do nothing. I
> wouldn't expect the maven-war-plugin to assume it knows what to do
> with my resource-only artifacts. Do you think it should do something?
> And, if so, is that a justifiable assumption?

It could have a config option for embedding/exploding such additional
archives, just like assembly plugin or copy-deendencies can work on
dependencies.

Gruss
Bernd

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

Re: Maven Memory Consumption

[Bernd Eckenfels]

Hello,

I wondered about that as well. It was discussed 2012 on maven-dev. The
statement looks like this:

# Runtime r = Runtime.getRuntime();
# long MB = 1024 * 1024;
# "Final Memory: " + ( r.totalMemory() - r.freeMemory() ) / MB + "M/" +
r.totalMemory() / MB + "M"

So this basically prints the currently used memory (which is pretty
useless as it depends on the last time the GC was run) and the memory
commit. This is the largest memory needed before a GC was kicked off.
The later one should be a pretty usefull indicator of the commited
memory. It is as least as big as Xms, so you should set it low.

It is however not an indication if you can decrease Xmx. If it tells
you the total memory commited was 1,5GB it is possible that it would
run with Xmx 1G as well.

Gruss
Bernd


 Am Sun, 17 Apr 2016 17:50:05 +0200
schrieb Karl Heinz Marbaise :

> Hi to all,
> 
> i have a question concerning the memory consumption...
> 
> If i run maven with the same JDK and the same reactor and build with
> the same parameter and plugins...
> 
> will the printout at the end of the build (Final Memory) something 
> realiable about the consumption of the JVM during the build ?...Or is
> it at least a hint...or would i need to do something different (BTW: 
> Someone has a hint about that?) ...
> 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 6.431 s
> [INFO] Finished at: 2016-04-17T17:46:58+02:00
> [INFO] Final Memory: 47M/638M
> 
> So if i ran the same build with different Maven versions so could
> this give us a hint where more memory is consumed ...(to identify
> where and why is a different story)...
> 
> Kind regards
> Karl Heinz
> 
> -
> 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: Reproducibility versus ranges

[Bernd Eckenfels]

Hello,

you dont need to remeber the ranges if you will not touch the ranged pom
on the trunk/master/devel branch, only the release
tags/commits/branches have that expanded version. (Just like the
version tag, its the only pom incarnation with a non-snapshot one).

Gruss
Bernd

Am Mon, 26 Oct 2015
22:39:14 + schrieb Stephen Connolly
<stephen.alan.conno...@gmail.com>:

> Shoot me for not giving the full response.
> 
> Release.properties is too hacky to contain all the info to be
> restored/restored with modifications.
> 
> Never mind that if you lost the release.properties file and had to
> resume elsewhere you might get stuck.
> 
> So in my view you need to stash the original range in the pom...
> XMLPI is the logical holder as it is a processing instruction for the
> release plugin (or versions plugin)
> 
> You need to bump the lower limit to whatever the range got resolved
> to when switching back to development.
> 
> The only remaining issue is how would people resolve conflicts of
> multiple dependencies all have conflicting hard ranges? (Ok you add
> excludes... But still could get hairy... Ok likely alerting of
> potential issue too there)
> 
> On Monday 26 October 2015, Fred Cooke <fred.co...@gmail.com> wrote:
> 
> > In our case, we don't want the original range back exactly, we want
> > the current version of that, ie, higher lower bound to currently
> > released things.
> >
> > Do not forget the transient ranges that need to be locked in our
> > modified pom, either. Without this any tooling would be severely
> > limited in use.
> >
> > Fred.
> >
> > On Tue, Oct 27, 2015 at 11:02 AM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com <javascript:;>> wrote:
> >
> > > The idea I had in versions-m-p was to put XML PI with the
> > > original range beside the resolved value so that the range can be
> > > set back post prepare (see completionGoals)
> > >
> > > Oh where is my elusive time
> > >
> > > On Monday 26 October 2015, Bernd Eckenfels <e...@zusammenkunft.net
> > <javascript:;>> wrote:
> > >
> > > > Am Mon, 26 Oct 2015 13:03:03 -0400
> > > > schrieb Benson Margulies <bimargul...@gmail.com <javascript:;>
> > <javascript:;>>:
> > > > > Do we have any tooling for this? In my imagination, the top
> > > > > pom for a product to be released could be auto-decorated with
> > > > > dependencyManagement locks.
> > > >
> > > > I think besides the release-with-pom from the release plugin
> > > > but also versions:resolve-ranges:
> > > >
> > > > http://www.mojohaus.org/versions-maven-plugin/resolve-ranges-mojo.html
> > > >
> > > > Gruss
> > > > Bernd
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > <javascript:;> <javascript:;>
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > <javascript:;>
> > > <javascript:;>
> > > >
> > > >
> > >
> > > --
> > > Sent from my phone
> > >
> >
> 
> 


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

Re: Reproducibility versus ranges

[Bernd Eckenfels]

Hello,

if you lock down ranges on release your dependencies will also have no
ranges and you do not need to lock them down transitively.

BTW: I really think tis is a topic for the maven-user list.

Gruss
Bernd

 Am Tue, 27
Oct 2015 11:21:09 +1300 schrieb Fred Cooke <fred.co...@gmail.com>:

> In our case, we don't want the original range back exactly, we want
> the current version of that, ie, higher lower bound to currently
> released things.
> 
> Do not forget the transient ranges that need to be locked in our
> modified pom, either. Without this any tooling would be severely
> limited in use.
> 
> Fred.
> 
> On Tue, Oct 27, 2015 at 11:02 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
> 
> > The idea I had in versions-m-p was to put XML PI with the original
> > range beside the resolved value so that the range can be set back
> > post prepare (see completionGoals)
> >
> > Oh where is my elusive time
> >
> > On Monday 26 October 2015, Bernd Eckenfels <e...@zusammenkunft.net>
> > wrote:
> >
> > > Am Mon, 26 Oct 2015 13:03:03 -0400
> > > schrieb Benson Margulies <bimargul...@gmail.com <javascript:;>>:
> > > > Do we have any tooling for this? In my imagination, the top pom
> > > > for a product to be released could be auto-decorated with
> > > > dependencyManagement locks.
> > >
> > > I think besides the release-with-pom from the release plugin but
> > > also versions:resolve-ranges:
> > >
> > > http://www.mojohaus.org/versions-maven-plugin/resolve-ranges-mojo.html
> > >
> > > Gruss
> > > Bernd
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > <javascript:;> For additional commands, e-mail:
> > > dev-h...@maven.apache.org
> > <javascript:;>
> > >
> > >
> >
> > --
> > Sent from my phone
> >
> 

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

Re: Reproducibility versus ranges

[Bernd Eckenfels]

If you do not release POMs with ranges there are no poms with ranges to
depend on.

Am Tue, 27 Oct 2015 14:03:01 +1300
schrieb Fred Cooke <fred.co...@gmail.com>:

> False, you've locked to a specific version of a thing which depends on
> ranges. This does not lock down those ranges, as it doesn't have
> enough information to do that.
> 
> On Tue, Oct 27, 2015 at 1:42 PM, Bernd Eckenfels
> <e...@zusammenkunft.net> wrote:
> 
> > Hello,
> >
> > if you lock down ranges on release your dependencies will also have
> > no ranges and you do not need to lock them down transitively.
> >
> > BTW: I really think tis is a topic for the maven-user list.
> >
> > Gruss
> > Bernd
> >
> >  Am Tue, 27
> > Oct 2015 11:21:09 +1300 schrieb Fred Cooke <fred.co...@gmail.com>:
> >
> > > In our case, we don't want the original range back exactly, we
> > > want the current version of that, ie, higher lower bound to
> > > currently released things.
> > >
> > > Do not forget the transient ranges that need to be locked in our
> > > modified pom, either. Without this any tooling would be severely
> > > limited in use.
> > >
> > > Fred.
> > >
> > > On Tue, Oct 27, 2015 at 11:02 AM, Stephen Connolly <
> > > stephen.alan.conno...@gmail.com> wrote:
> > >
> > > > The idea I had in versions-m-p was to put XML PI with the
> > > > original range beside the resolved value so that the range can
> > > > be set back post prepare (see completionGoals)
> > > >
> > > > Oh where is my elusive time
> > > >
> > > > On Monday 26 October 2015, Bernd Eckenfels
> > > > <e...@zusammenkunft.net> wrote:
> > > >
> > > > > Am Mon, 26 Oct 2015 13:03:03 -0400
> > > > > schrieb Benson Margulies <bimargul...@gmail.com
> > > > > <javascript:;>>:
> > > > > > Do we have any tooling for this? In my imagination, the top
> > > > > > pom for a product to be released could be auto-decorated
> > > > > > with dependencyManagement locks.
> > > > >
> > > > > I think besides the release-with-pom from the release plugin
> > > > > but also versions:resolve-ranges:
> > > > >
> > > > >
> > http://www.mojohaus.org/versions-maven-plugin/resolve-ranges-mojo.html
> > > > >
> > > > > Gruss
> > > > > Bernd
> > > > >
> > > > > -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > > <javascript:;> For additional commands, e-mail:
> > > > > dev-h...@maven.apache.org
> > > > <javascript:;>
> > > > >
> > > > >
> > > >
> > > > --
> > > > Sent from my phone
> > > >
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
> 

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

Re: Reproducibility versus ranges

[Bernd Eckenfels]

Am Mon, 26 Oct 2015 13:03:03 -0400
schrieb Benson Margulies :
> Do we have any tooling for this? In my imagination, the top pom for a
> product to be released could be auto-decorated with
> dependencyManagement locks.

I think besides the release-with-pom from the release plugin but also
versions:resolve-ranges:

http://www.mojohaus.org/versions-maven-plugin/resolve-ranges-mojo.html

Gruss
Bernd

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

Re: Help getting started contributing to maven

[Bernd Eckenfels]

Hello,

Am Mon, 28 Sep 2015 21:40:54 +0100
schrieb ivange larry :

> 1 - Is the code hosted here
> https://git-wip-us.apache.org/repos/asf/maven.git, the same as the
> code hosted on github with this url https://github.com/apache/maven.

Yes, github receives a copy of the ASF repository. You can see it on
the startpage it states "mirrored from ...". This also means nobody can
check in changes to github, they will be send to git-wip-us and from
there propagated to Github.

> 2 - In order to contribute, can i just fork the repository on github
> and submit pull requests instead of patches.

Yes, thats possible. A PR on github can be turned into a patch and
commited by a commiter. For larger changes it might be best to first
find someone willing to work with you in merging it. You always can
download the PR as patch file and append it in addition to JIRA.

Gruss
Bernd

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

Re: Unable to deploy to repository.apache.org using Java 6 any more

[Bernd Eckenfels]

issues.apache.org (JIRA) has the same problem. The 4096bit DHE prime
is not supported by Java (not even 1.8). It helps to disable DHE
completely in jre/lib/security/java.security:

jdk.tls.disabledAlgorithms=MD5, RC4, SSLv3, DSA, RSA keySize  2048, DHE

Gruss
Bernd


Am
Thu, 25 Jun 2015 20:35:46 +0200 schrieb Dennis Lundberg
denn...@apache.org:

 Hi
 
 I finally sat down today to start the release of maven-pmd-plugin.
 Unfortunately I didn't get very far. When I try to mvn deploy the
 latest SNAPSHOT I get this error:
 
 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy
 (default-deploy) on project maven-pmd-plugin: Failed to retrieve
 remote metadata
 org.apache.maven.plugins:maven-pmd-plugin:3.5-SNAPSHOT/maven-metadata.xml:
 Could not transfer metadata
 org.apache.maven.plugins:maven-pmd-plugin:3.5-SNAPSHOT/maven-metadata.xml
 from/to apache.snapshots.https
 (https://repository.apache.org/content/repositories/snapshots): peer
 not authenticated - [Help 1]
 
 First I checked my credentials and they looked good. After some
 googling I suspected an SSL certificate problem, so I checked the cert
 for repository.apache.org and found that it is relatively new. At
 least more recent than my last release... Then I tried SSLPoke [1]
 which is small and simple to use in such cases. With Java 6 I get this
 error:
 
 G:\java SSLPoke repository.apache.org 443
 javax.net.ssl.SSLException: java.lang.RuntimeException: Could not
 generate DH keypair
 at
 com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
 at
 com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1747)
 at
 com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1708)
 at
 com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1691)
 at
 com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1617)
 at
 com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:105)
 at
 com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:114)
 at SSLPoke.main(SSLPoke.java:31) Caused by:
 java.lang.RuntimeException: Could not generate DH keypair at
 com.sun.net.ssl.internal.ssl.DHCrypt.init(DHCrypt.java:114) at
 com.sun.net.ssl.internal.ssl.ClientHandshaker.serverKeyExchange(ClientHandshaker.java:559)
 at
 com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:186)
 at
 com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
 at
 com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
 at
 com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:943)
 at
 com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1188)
 at
 com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:654)
 at
 com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:100) 
 ...
 2 more Caused by: java.security.InvalidAlgorithmParameterException:
 Prime size must be multiple of 64, and can only range from 512 to
 1024 (inclusive) at
 com.sun.crypto.provider.DHKeyPairGenerator.initialize(DashoA13*..) at
 java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:627)
 at com.sun.net.ssl.internal.ssl.DHCrypt.init(DHCrypt.java:107) ...
 10 more
 
 and with Java 7 it works fine
 
 G:\java SSLPoke repository.apache.org 443
 Successfully connected
 
 One solution that usually works is to copy the cacerts file from a
 more recent Java version, so that you get the most recent list of CA
 certificates. I did that, and got the same error as before.
 
 So, where does that leave us? Well it seems that the certificate that
 has been deployed to repository.apache.org uses some kind of
 encryption technique that Java 6 cannot handle. See the stack trace
 above for the details, but my guess that the new cert uses a prime
 that is more than 1024 in size.
 
 AFAICT that means that anyone at the ASF wanting to to a release via
 repository.apahce.org must do so using Java 7. It would be great if
 someone could confirm and even greater if you could reject my
 findings...
 
 
 [1]
 https://confluence.atlassian.com/display/FISHKB/PKIX+Path+Building+Failed+-+Cannot+Set+Up+Trusted+Applications+To+SSL+Services
 


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

Re: Maven structure plugin

[Bernd Eckenfels]

Hello,

thanks for the work.

Can you describe whats your  typical usecase is?


I think in your readme the last sample is not detailed files (but
c+p duplication).

I would recommend to make a linespacing=0,1,2 setting (no empty lines in
between, empty lines only between last child and next level and empty
lines between all entries)

Is outputDirectory actually an outputFile parameter? (like
dependency:tree uses).

Gruss
Bernd




Am Tue, 23 Jun 2015 01:58:19 +0200 schrieb burak sarac
bu...@linux.com:
  Since few days I was working on a maven plugin to print project
 structure in ascii format ignoring external dependencies. Plugin has 3
 goal:modules,folders or files. You can get also detailed output or
 ignores files by regex pattern. Currently its available on central
 repository (I have commited 0.0.2 release, probably will be available
 in few hours). I am not very social person so I didnt know where to
 share after I finish:) I will be glad about your inputs also I would
 like to ask if there is any possiblity to include my project into
 core maven plugins? If yes I am willing to improve functionalities.
 
 readme,example and source here:
 
 https://github.com/buraksarac/MavenStructurePlugin

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

Re: Do we want to go for gitpubsub?

[Bernd Eckenfels]

Hello,

when searching around for special constructs or when I have to need to
understand some third party error messages I like to visit Java code on
the Web as it safes me the need to check it out and especially it
offers (usually) a good search and navigation.

So this is by definition not for projects I work in, and typically it
is via aggregator sides like grepcode.

It is good to have code online for search index to index. But it does
not have to be in a site build. (Unfortunatelly the usual web repo
browsers are not so good in creating type links).

For javadoc-xrefs it is most valuable for samples.

Gruss
Bernd


Am Sun, 3 May 2015
20:22:04 +0200 schrieb Andreas Gudian andreas.gud...@gmail.com:

 5 gig? wow...
 
 I think a whole lot of of the pages is garbage that no one ever really
 reads. No, not the docs itself ;-) - I'm talking about the many many
 source xref and javadoc pages (both main and test code) And every
 single of those pages is updated on every release because they all
 contain the version number or a timestamp somewhere.
 
 If we could stop adding source xrefs and javadocs to the site
 reports, that would already help a lot. I haven't read any javadoc
 pages in the browser for years... and when I look for source code, I
 use the quick search on github or browse through the web-cvs. When I
 actually use a library, then the sources are downloaded automatically
 anyway in the IDE - together with the Javadocs if necessary.
 
 Or does anyone see that there's still need for those pages? Do we
 maybe have some statistics on visits to those pages?
 
 2015-05-03 10:52 GMT+02:00 Hervé BOUTEMY herve.bout...@free.fr:
 
  Le vendredi 1 mai 2015 15:14:05 Andreas Gudian a écrit :
   Anyone who has ever done a release of a large plugin like
   surefire from a european location knows what a pain it is to
   svn-commit a couple of thousand files. It takes hours, but only
   if you're lucky and the process
  is
   not interrupted by the server.
   I had to dance around that by zipping up the locally generated
   site, scp
  it
   to people.a.o and commit it from there. Every time I did that, I
   thought about how cool it would be to just push one git-commit -
   it would be done in seconds.
  +1
 
  
   So I'd be all in favour of that. Depends on how that would be
   structured, though. Everything in one big repository? Or could it
   be sliced into
  parts
   of the different areas of the sites, like main maven pages, the
   single-module plugins, and dedicated repositories for the bigger
   plugins?
  you're pointing to the key good question
 
  There was a discussion last month on infrastructure mailing list
  about eventually deprecating CMS: that is the starting point of my
  work on .htaccess
  and /content vs /components for merging main site content with
  components documentations (both latest and versioned in *-archives/)
 
  And from the discussion I had with infra, having multiple SCM
  entries (one for
  the main site and one for each and every component) would cause
  issues for infra, since it means infra would have to configure a
  lot of *pubsub listeners:
  it's not part of infra plan to have so much listeners, and being in
  the loop
  every time we add one component.
  Notice I don't see how versioned content (in *-archives) could be
  done: but that's another issue, perhaps we could find a strategy.
 
 
  Then if we switched to git, this would be one big git repo with
  absolutely everything in it: I counted, there are 475 000 files,
  for 5 GB. Not sure we'll
  have the performance improvement we expected from git...
 
 
  Notice that we have curently 2 html repos: /content and /components
  We could migrate /content, ie the main site content, to gitpubsub
  But I think we would loose the CMS, since CMS doesn't support git,
  AFAIK Not that I'm a big CMS fan, but what I like is the main site
  automatic build
  (not done from personal desktop but from buildbot [1] ), which is
  part of the
  CMS workflow
 
 
  Then I fear the dream we all have to improve component documentation
  publication performance won't come from this
 
 
  But during the discussion with infra, this huge performance issue
  was clearly
  shared and there was an idea expressed by Joe Schaefer:
  Supporting tar/zip files with svnpubsub is straightforward with the
  built-in
  hook support.  Someone would just need to write a custom hook that
  expands zip
  files for websites (a list of where to find these files needs to be
  supplied or
  conventionalized).
 
  The way I'd envision this working is that,
 
  1) projects add their compressed archives listings to a specific
  file similar to
  extpaths for the cms.  Each entry would be a target path and a
  source tarball.
 
  2) when a project commits a new entry with a new tarball, the hook
  will look
  at each entry in the tarball file and compare timestamps against
  what's on disk.  If the directory is older than the tarball it
  nukes the directory 

OS Family DOS not windows with Java 8

[Bernd Eckenfels]

Hello,

did you notice, that with Java 8 all Maven versions will print Dos
instead of Windows as the OS Familiy of an (german) Win7 (x64) system:

mvn -v
Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1;
2014-12-14T18:29:23+01:00)
Maven home: C:\devenv\apache-maven-3.2.5
Java version: 1.8.0_40, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_40\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: dos

Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da;
2013-02-19 14:51:28+0100)
Maven home: C:\devenv\apache-maven-3.0.5 Java
version: 1.8.0_40, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_40\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: dos

Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da;
2013-02-19 14:51:28+0100)
Maven home: C:\devenv\apache-maven-3.0.5
Java version: 1.7.0_72, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_72\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: windows


I think the problem here is, that the sequence has changed (and Maven
never bothered all families which apply).

I could imagine two (or do nothing as the third) options here, first
would be to print all families which apply, not only the first one
and secondly using a different data structure to hold the list of
families to make them sorted (again).

https://github.com/sonatype/plexus-utils/blob/f2beca21c75084986b49b3ab7b5f0f988021dcea/src/main/java/org/codehaus/plexus/util/Os.java#L392

Gruss
Bernd

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

Re: maven-release-plugin does not build cleanly - M2_HOME is missing

[Bernd Eckenfels]

Am Wed, 25 Mar 2015 21:01:53 +0100
schrieb Mirko Friedenhagen mfriedenha...@gmail.com:
 - however this will not help with IDEs like Eclipse or Intellij which
 use their own code to invoke stuff.

I guess it is better when you pass it as a system property:

-Dmaven.home=${M2_HOME}

that way you dont need to export it and the configuration is consistent
(with the settings the IDEs typically set as well).

Gruss
Bernd

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

Re: [DISCUSS] To SemVer or not to SemVer, that is the question

[Bernd Eckenfels]

Hello,

I know its not your problem domain, but I wanted to point out that the
OSGi bnd-tool can do exactly that. It can even differentiate for
interface providers and consumers.

http://www.aqute.biz/Bnd/Versioning

However the question is, if it really works all automatic if you are
not strictly developing with that in mind (and if you do it it is still
in the interest of your users).

Gruss
Bernd


Am Sat, 21 Feb 2015 23:05:37
+0100 schrieb Dennis Lundberg denn...@apache.org:

 Hi,
 
 Although I strongly feel that SemVer [1] is the way to go when it
 comes to versioning, I still haven't started using it though. That got
 me thinking about why that is the case. I've come to the conclusion
 that I'm lazy :)
 
 It all comes down to tooling. Being accustomed to, and spoiled by,
 using the Release Plugin, I don't want to do anything manually any
 more. That includes as simple a thing as changing the next version
 (or developmentVersion) manually during the interactive command line
 session when using the Release Plugin. I want it to be the guessed
 correctly for me. Let me outline an example to show you what I mean.
 The vast majority of releases I make, both here and at my day job, are
 minor releases. So I want the Release Plugin to work for me, and not
 against me.
 
 
 Not using SemVer
 
 1.0-SNAPSHOT -- 1.0 -- 1.1-SNAPSHOT
 
 No problems here, the Release Plugin will correctly guess that
 1.1-SNAPSHOT is the next version that I want to use. Just hit enter
 a couple of times during the release process.
 
 
 Using SemVer
 
 1.0.0-SNAPSHOT -- 1.0.0 -- 1.0.1-SNAPSHOT
 
 This is not what I want. The Release Plugin will guess that the next
 version should be 1.0.1-SNAPSHOT. To change it I have to type in the
 value that I want on the command line. I'm too lazy for that. Instead
 I want the Release Plugin to do this:
 
 1.0.0-SNAPSHOT -- 1.0.0 -- 1.1.0-SNAPSHOT
 
 
 How can we solve this? The solution that I have come up with is a new
 parameter for release:prepare tentatively called versionIncrement
 that can take the values major, minor and patch, with patch
 being the default value for backwards compatibility.
 
 In my use case above I would simply set versionIncrement=minor and the
 Release Plugin would then do things my way.
 
 What are your thoughts on this?
 
 I would like for us to start using SemVer for all releases in the
 Maven project, not just in core. What do you think?
 
 
 [1] http://semver.org/
 


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

Re: maven git commit: .mvn/ for project specific jvm options and maven parameters

[Bernd Eckenfels]

Am Sun, 08 Feb 2015 07:57:03 -0500
schrieb Igor Fedorenko i...@ifedorenko.com:

 What if there was single real mvn script and mvnDebug/mvnyjp were
 just symlinks pointing back to it? The script will behave differently
 based on the script name. Any objections to this plan?

I am all for having only one script. They have diverged too much
anyway (the java_home fix I did for Max OS was missing in two of them
for example). Not sure how common the old names are used (never
encountered them, at least not for normal usage), so having them as
wrappers (or symlinks) calling the common script is optional. But
having the logic only in one place is a big win.

Gruss
Bernd

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

Re: Build failed in Jenkins: core-it-maven-3-win

[Bernd Eckenfels]

Hello,

Ping? The mails still nag me. Maybe it is enough to clean the workspace
for this job? Who should be responsible, so I can contact them directly?

Gruss
Bernd

 Am Tue, 27 Jan 2015 21:46:12 +0100
schrieb Bernd Eckenfels e...@zusammenkunft.net:

 Hello,
 
 the core-it-maven-3-win are failing because of some get setup problem
 (it seems). The job sent a lot of failed mail messages. It looks like
 I do get a copy because one of my patches was commited meanwhile.
 
 Can somebody have a look?
 
 Gruss
 Bernd
 
 --
 Datum: Mon, 26 Jan 2015 23:27:07 + (UTC)
 Von: Apache Jenkins Server  jenk...@builds.apache.org
 An: notificati...@maven.apache.org, be...@eckenfels.net
 Betreff: Build failed in Jenkins: core-it-maven-3-win #746
 
 
 See https://builds.apache.org/job/core-it-maven-3-win/746/
 
 --
 Started by an SCM change
 Building remotely on windows1 (Windows) in workspace
 https://builds.apache.org/job/core-it-maven-3-win/ws/  git
 rev-parse --is-inside-work-tree # timeout=10 Fetching changes from
 the remote Git repository  git config remote.origin.url
 https://git-wip-us.apache.org/repos/asf/maven.git # timeout=10 FATAL:
 Failed to fetch from https://git-wip-us.apache.org/repos/asf/maven.git
 hudson.plugins.git.GitException: Failed to fetch from
 https://git-wip-us.apache.org/repos/asf/maven.git at
 hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:647) at
 hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:889) at
 hudson.plugins.git.GitSCM.checkout(GitSCM.java:914) at
 org.jenkinsci.plugins.multiplescms.MultiSCM.checkout(MultiSCM.java:118)
 at hudson.model.AbstractProject.checkout(AbstractProject.java:1252) at
 hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:615)
 at
 jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
 at
 hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:524)
 at hudson.model.Run.execute(Run.java:1706) at
 hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at
 hudson.model.ResourceController.execute(ResourceController.java:88) at
 hudson.model.Executor.run(Executor.java:232) Caused by:
 hudson.plugins.git.GitException: Command git config remote.origin.url
 https://git-wip-us.apache.org/repos/asf/maven.git; returned status
 code 4: stdout: stderr: error: could not commit config
 file .git/config
 
   at
   
 org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1435)
   at
   
 org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1411)
   at
   
 org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1407)
   at
   
 org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1110)
   at
   
 org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1120)
   at
   
 org.jenkinsci.plugins.gitclient.CliGitAPIImpl.setRemoteUrl(CliGitAPIImpl.java:832)
   at hudson.plugins.git.GitAPI.setRemoteUrl(GitAPI.java:120) at
   sun.reflect.GeneratedMethodAccessor801.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
   Source) at java.lang.reflect.Method.invoke(Unknown Source) at
   
 hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:310)
   at
   
 hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:290)
   at
   
 hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:249)
   at hudson.remoting.UserRequest.perform(UserRequest.java:118)
 at hudson.remoting.UserRequest.perform(UserRequest.java:48) at
   hudson.remoting.Request$2.run(Request.java:328) at
   
 hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
   at java.util.concurrent.FutureTask$Sync.innerRun(Unknown
   Source) at java.util.concurrent.FutureTask.run(Unknown Source)
   at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
   Source) at
   java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
   Source) at hudson.remoting.Engine$1$1.run(Engine.java:63) at
   java.lang.Thread.run(Unknown Source)


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

Fw: Build failed in Jenkins: core-it-maven-3-win

[Bernd Eckenfels]

Hello,

the core-it-maven-3-win are failing because of some get setup problem
(it seems). The job sent a lot of failed mail messages. It looks like I
do get a copy because one of my patches was commited meanwhile.

Can somebody have a look?

Gruss
Bernd

--
Datum: Mon, 26 Jan 2015 23:27:07 + (UTC)
Von: Apache Jenkins Server  jenk...@builds.apache.org
An: notificati...@maven.apache.org, be...@eckenfels.net
Betreff: Build failed in Jenkins: core-it-maven-3-win #746


See https://builds.apache.org/job/core-it-maven-3-win/746/

--
Started by an SCM change
Building remotely on windows1 (Windows) in workspace
https://builds.apache.org/job/core-it-maven-3-win/ws/  git rev-parse
--is-inside-work-tree # timeout=10 Fetching changes from the remote Git
repository  git config remote.origin.url
https://git-wip-us.apache.org/repos/asf/maven.git # timeout=10 FATAL:
Failed to fetch from https://git-wip-us.apache.org/repos/asf/maven.git
hudson.plugins.git.GitException: Failed to fetch from
https://git-wip-us.apache.org/repos/asf/maven.git at
hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:647) at
hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:889) at
hudson.plugins.git.GitSCM.checkout(GitSCM.java:914) at
org.jenkinsci.plugins.multiplescms.MultiSCM.checkout(MultiSCM.java:118)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1252) at
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:615)
at
jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:524)
at hudson.model.Run.execute(Run.java:1706) at
hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at
hudson.model.ResourceController.execute(ResourceController.java:88) at
hudson.model.Executor.run(Executor.java:232) Caused by:
hudson.plugins.git.GitException: Command git config remote.origin.url
https://git-wip-us.apache.org/repos/asf/maven.git; returned status code
4: stdout: stderr: error: could not commit config file .git/config

at

org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1435)
at

org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1411)
at

org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1407)
at

org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1110)
at

org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1120)
at

org.jenkinsci.plugins.gitclient.CliGitAPIImpl.setRemoteUrl(CliGitAPIImpl.java:832)
at hudson.plugins.git.GitAPI.setRemoteUrl(GitAPI.java:120) at
sun.reflect.GeneratedMethodAccessor801.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
Source) at java.lang.reflect.Method.invoke(Unknown Source) at

hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:310)
at

hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:290)
at

hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:249)
at hudson.remoting.UserRequest.perform(UserRequest.java:118) at
hudson.remoting.UserRequest.perform(UserRequest.java:48) at
hudson.remoting.Request$2.run(Request.java:328) at

hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown
Source) at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
Source) at
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
Source) at hudson.remoting.Engine$1$1.run(Engine.java:63) at
java.lang.Thread.run(Unknown Source)

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

AW: 3.2.3 not available thoughhttp://archive.apache.org/dist/maven/binaries/?

[Bernd Eckenfels]

Hello,

It is on the archive site ob the new coordinates:

http://archive.apache.org/dist/maven/maven-3/3.2.3/binaries/

Greetings
bernd

-- 
http://bernd.eckenfels.net

- Ursprüngliche Nachricht -
Von: Milos Kleint mkle...@gmail.com
Gesendet: ‎29.‎12.‎2014 09:02
An: Maven Developers List dev@maven.apache.org
Betreff: Re: 3.2.3 not available 
thoughhttp://archive.apache.org/dist/maven/binaries/?

On Mon, Dec 29, 2014 at 6:25 PM, Hervé BOUTEMY herve.bout...@free.fr
wrote:

 we generally switched Maven release canonical download area to
 https://dist.apache.org/repos/dist/release/maven/maven-3/

 IIRC, http://archive.apache.org/dist/maven/binaries/ was used by Jenkins
 folks
 for automatic Maven version discovery and download, before the change

 seems like we didn't took the effort to copy latest releases to this legacy
 location

 is this legacy location still useful?


well, the legacy location is being referenced from the main download
page.

and looking at https://dist.apache.org/repos/dist/release/maven/maven-3/ I
don't see 3.2.3 either. At our company we currently standardise on 3.2.3
and it's weird that it cannot be currently downloaded from anywhere.

Milos




 notice we should add a HEADER or README in the legacy directory to explain
 the
 story

 Regards,

 Hervé

 Le lundi 29 décembre 2014 16:51:07 Milos Kleint a écrit :
  Hello,
 
  for some reason 3.2.3 is not available in the archives, is that
 intentional
  or something went wrong with the 3.2.5 release?
 
  Thanks
 
  Milos


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

Re: Why is distributionManagement inside the pom?

[Bernd Eckenfels]

Am Sun, 21 Dec 2014 21:30:49 +0100
schrieb Mirko Friedenhagen mfriedenha...@gmail.com:

 My question here: if you do not define distributionManagement (via a
 property) in a pom, all users of Maven would have to fiddle around
 with their settings to deploy anything.

I think you have to do that in some way anyway, as you need to define
servers and logins. I guess it only works for ssh without special
setup.

But you are correct some form for distributing those settings would be
a good addition. Something like an environment mechanism which could
also cover staging/localtest/snapshot/release differences would be cool.

Gruss
Bernd

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

Re: Build Failing of Maven

[Bernd Eckenfels]

Am Sat, 6 Dec 2014 17:36:45 +0530
schrieb kapil Ashiwal kapilashiwal1...@gmail.com:
 BUILD FAILED
 /usr/local/apache-maven-3.2.3/*build.xml:231: Syntax error in
 property: ${*

Obvious question, what is the content of line 231? (and surrounding)

Gruss
Bernd

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

Re: Build Failing of Maven

[Bernd Eckenfels]

Hello,

Oh I can actually answer my question myself :) 

build:231 contains a copy with filter. So I guess it is not about a
syntax error in the ant script but the filtered resources. So you need
to provide more context: can you see before the error which file
actually failed?


Gruss
Bernd

PS: what maven, ant and jave version you use?


 Am Sat, 6 Dec 2014 17:36:45 +0530
schrieb kapil Ashiwal kapilashiwal1...@gmail.com:

 Operating System - Centos-6
 The M2_HOME and JAVA_HOME is set.
 Ant is executed from the M2_HOME and the build fails like : -
 
 BUILD FAILED
 /usr/local/apache-maven-3.2.3/*build.xml:231: Syntax error in
 property: ${*
 
 I am a mere beginner and cant get through this error. Please tell me
 what is this and how it can be removed.
 
 Thanks :)
 

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

Re: Logging in Maven 3.1.1

[Bernd Eckenfels]

Hello,

you need to escape : and \ in properties files:

org.slf4j.simpleLogger.logFile=E\:\\Mavenlogs\\Mavenlog.txt

BTW: this is a maven users question.

Gruss
Bernd



Am Thu, 20 Nov 2014 14:37:08 +
schrieb Held, James E. jh...@dtcc.com:

 We'd like to log all maven activity to one common place by changing
 the logging.properties settings as shown below
 
 org.slf4j.simpleLogger.showDateTime=false
 org.slf4j.simpleLogger.showLogName=false
 org.slf4j.simpleLogger.logFile=E:\Mavenlogs\Mavenlog.txt
 
 Running under Win 7
 
 Except it writes the logs in the directory that the command was
 written in, not the E Drive directory.
 
 Am I doing something wrong?
 
 
 Jim Held
 IT Architecture
 DTCC Jersey City
 212-855-5733
 jh...@dtcc.commailto:jh...@dtcc.com
 
 [cid:image003.jpg@01CE0F89.AB571430]
 
 DTCC Confidential (Yellow)
 
 Learn what's new at DTCC: Visit us at
 www.dtcc.comhttp://www.dtcc.com/ or follow us on Twitter @The_DTCC
 https://twitter.com/The_DTCC  and on
 LinkedInhttp://www.linkedin.com/company/6915?trk=saber_s01e_1000.
 
 
 
 
 DTCC DISCLAIMER: This email and any files transmitted with it are
 confidential and intended solely for the use of the individual or
 entity to whom they are addressed. If you have received this email in
 error, please notify us immediately and delete the email and any
 attachments from your system. The recipient should check this email
 and any attachments for the presence of viruses.  The company accepts
 no liability for any damage caused by any virus transmitted by this
 email.
 


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

Re: [SUREFIRE] List of simple issues to fix

[Bernd Eckenfels]

Am Sat, 15 Nov 2014 15:31:17 -0700 (MST)
schrieb tibor17 tibo...@lycos.com:

 It makes sense to me to close these bugs without a fix.
 I will wait one week for a response.
 If somebody want to prevent from closing them, let me know.

All but one seem to be a clear close for me:

SUREFIRE-1001 - unconfigured MaxPerm. Probably OK to close, especially
as there is a Mojo documentation about vmargs and form mode, close ok.

SUREFIRE-904 - unconfigured groups/categories. OK to close, is kind of
support issue.

SUREFIRE-595 - I wonder, is skipTests honored only by the default value
for the parameter? If yes the original poster could reconfigure it to
false in the pom. In all cases: not really a surefire issue, close ok.

SUREFIRE-1054 - usage problem of excludegroups, close ok

SUREFIRE-620 - verify manifests, in failsafe/verify instead. close ok.

SUREFIRE-757 - sourceEncofing  not picked up. I would argue it makes
sense to change the warning to actually mention reorting.outputEncoding.

Gruss
Bernd

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

Re: Toolchains part of Maven distribution / global toolchains

[Bernd Eckenfels]

Hello,

i can see advantage and disadvantage to having it in the settings file.
In my case I have multiple settings files for different repo and
security settings but only one toolchain describes the host
installed software.

One option would be to allow includes in the settings.xml, then you can
point to a shared toolchain.xml file but still get the whole resolving
hierachy of settings.xml.

(And you can use it to share or seperate other things. It is only a
question on how to merge the DOMs).

Gruss
Bernd



 Am Sat, 01 Nov 2014 16:10:19 +0100 schrieb Robert
Scholte rfscho...@apache.org:

 Very interesting suggestion.
 And it shouldn't be a problem since the settings.xml is a Maven
 specific file (unlike the pom.xml).
 
 Robert
 
 Op Sat, 01 Nov 2014 16:02:02 +0100 schreef Hervé BOUTEMY  
 herve.bout...@free.fr:
 
  this makes me have another idea:
  why are toolchains configured in a specific toolchains.xml file
  instead as
  settings.xml?
 
  Regards,
 
  Hervé
 
  Le samedi 1 novembre 2014 15:53:16 Robert Scholte a écrit :
  Op Sun, 19 Oct 2014 20:19:07 +0200 schreef Karl Heinz Marbaise
 
  khmarba...@gmx.de:
   Hi,
  
   On 10/19/14 7:25 PM, Robert Scholte wrote:
   Maybe I found an explanation for the location.
   Current 'global' isn't really global. It's bound to the Maven
   installation. So for instance: whenever you upgrade your Maven,
   you shouldn't forget to copy the settings.xml.
  
   That's exactly the point...
  
   I have at the moment 150 developers which are currently runing
   against this wall cause the package which is delivered contains
   the  
  settings.xml
   in the conf folder of the maven installationnow i have to
   change  
  the
   nexus server ...
  
   By putting it under the user.home, you'll never have to change
   it.
  
   This will work for developers as well for build server like in
   Jenkins via Config-File-Provider[1] which already handles the
   setting.xml perfectly...this includes the toolchains.xml as
   wellFurthermore  
  this
   supports the usage on slaves as well...
  
   So it works, but IMHO for the wrong reason.
  
   Hm..what do you mean by that? Are you talking about security
   (passwords..) in settings.xml ? (Config-File-Provider supports
   also credentials etc.)...
 
  I consider user settings as settings specific for this user (e.g.
  passwords) and global settings as settings specific for the
  system. So in
  case you're using a system with multiple users, you don't have to  
  redefine
  these settings for every user.
  However, global settings aren't that global, they're bound to the
  Maven Distribution.
  The good thing about this, is that is makes it a lot easier to  
  distribute
  a company preconfigured Maven. Just unpack
  apache-maven-3.2.1-acme.zip and
  your repo manager is already set up for you.
 
  It would make sense if there would be something like
  ${env.ALLUSERSPROFILE}\.m2 , but I think that would
  overcomplicate things.
 
  Anyhow, I think we should treat toolchains.xml just like
  settings.xml and
  allow it to be located under conf/ of the Maven distribution.
 
   Makes we wonder if we need to think of a real global location
   as  
  well...
  
   I don't think so ...there are already existing solutions which
   work  
  well
   and are supported by the tools (Jenkins etc.)...
  
   Ok they might not be accepted by useers as a good solutions this
   is a different story...
  
   But if you introduce a new thing...update of tools etc. needed...
  
   But we have to promote the existing solution
  
   [1]

  https://wiki.jenkins-ci.org/display/JENKINS/Config+File+Provider+Plugin
  
  
   Kind regards
   Karl Heinz Marbaise
  
   Robert
  
   Op Sun, 19 Oct 2014 18:18:34 +0200 schreef Robert Scholte
  
   rfscho...@apache.org:
   Hi,
  
   since we're slowly upgrading the minimum JDK to run Maven it
   becomes more and more important to let our users know how they
   can compile with an ancient/older version of the JDK. I think
   we all agree that toolchains is the way to go.
   I proposed to add the toolchains to the Maven distribution
   and  
  already
   got a couple of +1's for that idea.
   However, it seems like the toolchain.xml is a user specific
   file and not a global file. [1]
   Putting this file under /conf of the distribution (next to
   the  
  global
   settings.xml) would probably confuse a lot of people it that
   file is not picked up from that location.
   Actually, I would say that tools are system specific and not
   just  
  user
   specific.
  
   Is there any historic reason to configure it per user?
   Should we support global toolchains as well?
  
   thanks,
   Robert
  
   [1]
   http://maven.apache.org/guides/mini/guide-using-toolchains.html  
  (
   The toolchains.xml file (see below) is the configuration file
   where you set the installation paths of your toolchains. This
   file should  
  be
   put in your $user.home/.m2 directory. )
  
   

Re: Toolchains part of Maven distribution / global toolchains

[Bernd Eckenfels]

Hello,

I think the user config has already a very big meaning because of
multiple reasons:

Typically developer workstations and CI servers all are single-user
only. So the builds are always executed with the same user. So there is
nobody complayning if the system is not configured on a system level.
This is especially true as people stay away from modifying system
config files if they are part of the software distribution and get
updated.

This is (in my thinking) the main reason why the focus on ~/.m2.
However of course I would agree the configuration is symmetric, so it
should also look for a system wide toolchain file.

BTW: I see there another problem. Toolchains are seldomly used. There
is still a lot of dicussions on enforcers/source/target versions.
Having a toolchain declaration would fix all of them at the same time,
so it is much preferred. Maybe all plugins should mention toolchain as
the better alternative for those parameters?

(And if would be good to actually fill the gaps on this wiki page:
https://cwiki.apache.org/confluence/display/MAVENOLD/Toolchains).

Related to this, can a system dependency refer to a toolchain home?
(especially rt.jar or similiar needs).

Gruss
Bernd

 Am Sun, 19 Oct 2014 18:18:34 +0200
schrieb Robert Scholte rfscho...@apache.org:

 Hi,
 
 since we're slowly upgrading the minimum JDK to run Maven it becomes
 more and more important to let our users know how they can compile
 with an ancient/older version of the JDK. I think we all agree that
 toolchains is the way to go.
 I proposed to add the toolchains to the Maven distribution and
 already got a couple of +1's for that idea.
 However, it seems like the toolchain.xml is a user specific file and
 not a global file. [1]
 Putting this file under /conf of the distribution (next to the
 global settings.xml) would probably confuse a lot of people it that
 file is not picked up from that location.
 Actually, I would say that tools are system specific and not just
 user specific.
 
 Is there any historic reason to configure it per user?
 Should we support global toolchains as well?
 
 thanks,
 Robert
 
 [1] http://maven.apache.org/guides/mini/guide-using-toolchains.html
 ( The toolchains.xml file (see below) is the configuration file where
 you set the installation paths of your toolchains. This file should
 be put in your $user.home/.m2 directory. )
 
 -
 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: Q: Maven Toolchain

[Bernd Eckenfels]

Am Wed, 19 Feb 2014 19:17:03 +0100
schrieb Anders Hammar and...@hammar.net:

 One thing it can be used for is to define a different JDK to be used
 (than the one used for executing Maven itself). More info here:
 http://maven.apache.org/guides/mini/guide-using-toolchains.html

What is quite interesting on this page, it talks about
exec-maven-plugin, but not the maven-invoker-plugin. The later does
require JDK homes and Maven Homes, both could be toolchained. In fact
there is already a bug about it:

https://jira.codehaus.org/browse/MINVOKER-100

We could think about providing the toolchain entries as special
properties, then one could use:

 mavenHome${toolchain.mavenhome.3.0.x}/mavenHome
 javaHome${toolchain.jdkhome.1.7.0.51}/javaHome

Or similiar?

Gruss
Bernd




 maven-invoker-plugin



 
 /Anders
 
 
 On Wed, Feb 19, 2014 at 7:12 PM, Karl Heinz Marbaise
 khmarba...@gmx.dewrote:
 
  Hi,
 
  maybe i didn't see a thing, but can someone explain me the
  intention of the maven toolchain in relationship with a plugin ...
 
  Currently i only see that it can find some kind of executable which
  is configured in somekind of buildcontext...which i currently don't
  understand how to configure (I've taken a look into the
  maven-toolchains-plugin which didn't enlighten me)...
 
  But what are the advantages / disadvantages of that ?
 
  May be i just be blockhead ...;-(
 
 
  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: Maven deploy does not respect finalName

[Bernd Eckenfels]

Hello,

I dont think you can (or should) use arbitrary file names for artifacts
in a maven-style repository. They have to follow the
artifactid-classifier-version.type pattern.

It is usually the best to pack those files in an archive *-bin.zip or
similiar to keep their folder structure and file names in a maven-repo
compliant way.

This is btw better asked in the maven-users mailing list.

Gruss
Bernd

- Am Thu, 25 Sep 2014 06:51:21
-0700 (PDT) schrieb Victor victoralvare...@gmail.com:

 Hi,
 
 When you run the maven deploy phase, maven upload to nexus the final
 file with the name ${artifactId}-${version}, and does not respect the
 finalName set in the build. 
 
 How could I indicate to maven deploy plugin to upload to nexus with
 the name, for example PREFIX_${artifactId}-${version}
 
 Does anyone know how to do?
 
 
 Thanks and regards.
 
 
 
 --
 View this message in context:
 http://maven.40175.n5.nabble.com/Maven-deploy-does-not-respect-finalName-tp5806549.html
 Sent from the Maven Developers mailing list archive at Nabble.com.
 
 -
 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: Release javadoc-plugin

[Bernd Eckenfels]

Hello,

yes I think if the fix is in a version specific handling, then it
should not be applied. (If the fix would be to always keep the slash
or not to alter the given link, then I would say add it).

BTW: wondering if lastIndexOf is really needed, in this context it can
only be the last char, and therefore link.length-1 would do. This is
true for both versions.

Gruss
Bernd


Am Sat, 13 Sep
2014 21:25:47 +0200 schrieb Dennis Lundberg denn...@apache.org:

 Hi
 
 Maven Javadoc Plugin is one of our components that currently does not
 work with Java 8. I have had a look at the issues in JIRA [1] and
 there is now only one unresolved issue scheduled for 2.10:
 MJAVADOC-393 [2]. As I have indicated in the issue I would like to
 close it as Won't fix, but I would like others opinion first.
 
 Once that issue has been settled I would like to start the release
 process. So if someone has other issues they would like to fix for
 this release, now would be a good time to do it.
 
 
 [1]
 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidejqlQuery=project+%3D+MJAVADOC+AND+fixVersion+%3D+%222.10%22
 [2] http://jira.codehaus.org/browse/MJAVADOC-393
 


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

Maven Central artifacts list

[Bernd Eckenfels]

Hello Jason,

a somewhat related question. would it be possible to publish a SHAxSUM file of 
all the artifacts of the repository? I figured this would be much more 
efficient than walking any of the repos to validate local mirrors. It also can 
be used to detect modifications to released artifacts without the need of 
guessing PGP keys.

Maybe the index process already has that information available...

Bernd

-- 
http://bernd.eckenfels.net

- Ursprüngliche Nachricht -
Von: Jason van Zyl ja...@takari.io
Gesendet: ‎27.‎08.‎2014 14:11
An: Maven Developers List dev@maven.apache.org
Betreff: [Proposal] New Mirror for Maven Central

Hi,

As part of our discussions with Sonatype I would like to propose a new location 
for our agreed upon 3rd party mirror for Maven Central.

About a year ago a friend of mine, Matt Stephenson, who was at Google (he now 
works at Square), asked if there was a way to get a copy of Maven Central for 
Google to do some analysis and prototyping. I always have an up-to-date copy of 
Maven Central and what they wanted to do sounded interesting and generally 
useful so I said sure and that I would drop off a drive for Matt at the SF 
office. Instead they suggested that I use the new Cloud infrastructure and 
setup the mirroring on one of their machines and so we did that. Over the last 
year I've worked with Matt and met more people at Google and ultimately they 
offered to pay for any of the machines and bandwidth required to house the 
mirror of Maven Central. Why would Google pay for this? They have made some 
developer tools based on the data, they have done their own security analysis 
for the protection of their own systems that use Java, and they want to 
leverage a near-copy of Maven Central for systems like Google App Engine. The 
cost of storage is nominal (40 dollars a month for 2TB) and if the cost of the 
whole system is less than one FTE (150-200k/year) it's not even going to 
register.

I think Google is generally to be thought of as a good OSS partner and they 
have supported many programs and efforts for many years. I asked them a few 
months ago if they would support the Maven PMC in having a long-term location 
for a mirror of Maven Central for our purposes and they liked the idea. It's 
mutually beneficial.

So I would like to propose that we use this infrastructure for the place for 
our agreed upon 3rd party mirror location. A few weeks ago I showed this to 
Hervé to see what he thought and if it was even a good idea to propose and we 
both agreed it would be. I relinquished my admin access to Hervé in the console 
so, as the Maven PMC Chair,  he can provide access to anyone who wants to check 
it out. I believe it would be a great place to do validation and an easy way 
for us to provide anyone with copies of Maven Central who wish it.

I think it would be a relatively simple change where we can give Sonatype a 
key, and then the push moves content to this new infrastructure.

Matt also setup an experiment to push the content of Maven Central to Google's 
CDN which has an HTTPS/S3 interface which you can see here[1]. So the 
equivalent access to Ibiblio can be provided by Google. From here we can also 
manage a push to Ibiblio to maintain consistency.

I encourage folks to get access and take a look around, but I think it's a nice 
offer from Google.

[1]: https://central-repo.storage.googleapis.com

Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.

 -- Buddha

Re: Central and Man-in-the-middle

[Bernd Eckenfels]

Hello,

I have started a POC a while back which can lock dependencies by a
special checksum file. However it is not really secure as a plugin, as
you cannot avoid other plugins overwrite yourself.

It is not finished, it was an execise in some internal maven apis:

https://github.com/ecki/lockdep-maven-plugin

There is a productive plugin which can generate checksums, but not
check them: 

https://github.com/nicoulaj/checksum-maven-plugin

Greetings
Bernd

BTW: Bintray' jcenter mirrors central and other stuff and offers SSL, of
course it adds additional possibilities to inject malicious stuff.
And yes, there are PGP files, but not really a good way to verify
them. I wish ASF infra would publish a md5sum of their maven2
directory.

 Am Tue, 29 Jul 2014
22:14:33 +0200 schrieb Hervé BOUTEMY herve.bout...@free.fr:

 direct control by Maven while downloading dependencies seems ideal,
 but I fear it's hard to have normal users aware of keys and manage it
 while building their artifacts
 
 I imagine something useful would be some report too, to display the
 status of actual dependencies: imagine adding key reference to every
 dependency in dependencies report [1]
 
 Anybody interested in coding such improvement?
 or any other idea?
 
 Definitely, seems the right moment to improve users awareness about
 security: IMHO, people will discover that security isn't automagic
 and will require involvement to decide what to trust and what to not
 trust, and that trust is a personal choice
 
 Regards,
 
 Hervé
 
 [1]
 http://maven.apache.org/plugins/maven-dependency-plugin/dependencies.html
 
 Le mardi 29 juillet 2014 13:31:30 Brett Porter a écrit :
  On 29 Jul 2014, at 12:14 pm, Mark Derricutt m...@talios.com wrote:
   Hey all,
   
   Just been reading [1] after it was mentioned in both #scala and
   #clojure on irc.freenode.org now, is there anything that can be
   done to alleviate some of these issues?
   
   oss.sonatype.org now requires everything to be GPG signed before
   being uploaded to central, but I'm not sure about any of the
   other means of getting artifacts uploaded.
   
   Are there any plugins out there to verify GPG signings of
   dependencies?
  
  If anyone is interested in picking up work on this, I pulled some
  things together some years ago:
  http://docs.codehaus.org/display/MAVEN/Repository+Security
  
  There was a working prototype against Maven 2, but for various
  reasons didn't get further than that.
  
  - Brett
  
  
  -
  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: POM 5.0 and Maven.next idea - re: repository's

[Bernd Eckenfels]

Am Thu, 26 Jun 2014 21:44:55 +0200
schrieb Michael Osipov micha...@apache.org:

 Am 2014-06-26 21:41, schrieb Mark Derricutt:
  On 27 Jun 2014, at 7:27, Michael Osipov wrote:
 
  2) Deploy transitive runtime dependencies along with your release

... or make sure they are centrally available. I think this is an
(important) best practice since years: 

http://blog.sonatype.com/2010/03/why-external-repos-are-being-phased-out-of-central/

And it is really good if it is enforced on MC.

Gruss
Bernd

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

Re: Processing Pull Request

[Bernd Eckenfels]

Am Sat, 24 May 2014 19:06:24 +0200
schrieb Michael Osipov micha...@apache.org:

 Am 2014-05-24 18:57, schrieb Igor Fedorenko:
  Please don't use Github PL merge functionality. This will create
  merge commits... and I seriously dislike merge commits, hate them,
  actually.
 
 Are you able to share your experience by improving the Git Convention
 on the Maven website? Me and others want a patch merged and not
 fiddling with Git issues actually.

I agree, that the merge button has some limitations. It encourages
commits without running local checks before (unless you set up a CI to
check-build PRs automatically). And, as already pointed out, it does
not easily allow to rebase.

But, using the merge button is not the only permission on a Github
repo which would be good for commiters: beeing able to close a PR if it
is rejected or merged differently and maintaining issues would be a
good thing to be able.

I am not sure if Infra actually wants to maintain
single-developer-to-repo-role permissions. After all GitHub is regarded
as a mirror not a primary workflow participant.

I have currently a PR open (for commons) and I am not sure if I want to
open a Infra ticket for it to be closed or not,thats why I am
interested in this topic as well.

Greeetings
Bernd

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

Re: Processing Pull Request

[Bernd Eckenfels]

Am Sat, 24 May 2014 13:46:42 -0400
schrieb Igor Fedorenko i...@ifedorenko.com:

 Second, pull-requests encourage multiple commits, when in most cases
 each pull-request corresponds to single logic change. This, too, makes
 commit history harder to comprehend for no good reason.

That is actually not a requirement, as a contributor you can propose
a PR and as a commiter you can ask for fine-tuning the commit. This
includes squashing, re-commenting and rebasing. You can do the dance
back and forth until the commit meats your standard. This is the same
as adding diffs and actually encourages a review workflow and is
exactly the same as in Gerrit.

Gruss
Bernd

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

Re: Let's fix the Rat Check usability fail

[Bernd Eckenfels]

Currently the Rat Report in the Site phase of commons-vfs takes enormous time, 
for really no good use when the commits are reviewed anyway (and it has all 
kinds of excludes and warnings you manually need to check).

 So I argue it would be better to run it only in relase (candidate) builds. Not 
sure if the same process applies to maven development.

Greetings
Bernd

Am 18.05.2014 um 19:43 schrieb Jason Pyeron jpye...@pdinc.us:

 -Original Message-
 From: Jason van Zyl 
 Sent: Sunday, May 18, 2014 13:05
 
 Right now though we require all files to have license headers 
 we do not run the check to verify this by default.
 
 Can it be turned off by option?
 
 It kept dinging me until I turned it on by default in Maven 
 core. Someone currently trying to contribute has no idea this 
 is a requirement and is not told so because it doesn't run by 
 default. If it's required how about we just run all the time 
 everywhere?
 
 What phase? 
 
 
 I would like to change the POMs so that it always runs. 
 Having to run RAT separately is a usability fail. The chances 
 of anyone contributing knowing they have to run it are pretty 
 close to zero.
 
 Anyone see a reason not to always run it?
 
 How much time do they take (add)?
 
 -Jason
 
 --
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 -   -
 - Jason Pyeron  PD Inc. http://www.pdinc.us -
 - Principal Consultant  10 West 24th Street #100-
 - +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
 -   -
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 This message is copyright PD Inc, subject to license 20080407P00.
 
 
 
 
 -
 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: Let's fix the Rat Check usability fail

[Bernd Eckenfels]

Hello,

I was speaking about the Rat report for the whole project (which is the parent 
of the core). The Rat-Plugin in the site creation seems to run for 107s on my 
machine (the Javadoc runs 17s).

But maybe I read the output wrong, maven logs can be quite confusing:

73090 [INFO] Generating Rat Report report--- apache-rat-plugin:0.10
73112 [DEBUG] Adding plexus default exclusions...
73112 [DEBUG] Adding exclusions often needed by Maven projects...
73112 [DEBUG] Adding exclusions often needed by projects developed in Eclipse...
73112 [DEBUG] Adding exclusions often needed by projects developed in IDEA...
73113 [DEBUG] Finished creating list of implicit excludes.
73113 [INFO] 54 implicit excludes (use -debug for more details).
73114 [INFO] Exclude: site-content/**
73114 [INFO] Exclude: .pmd
73114 [INFO] Exclude: src/site/resources/download_*.cgi
73114 [INFO] Exclude: src/site/resources/profile.*
73895 [DEBUG] Excluded 4081 resources:
...
73984 [DEBUG]  - excluded target\site\xref-test\stylesheet.css
73984 [INFO] 206 resources included (use -debug for more details)
...
73987 [DEBUG]  - included test.txt
Warning:  org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser: Property 
'http://www.oracle.com/xml/jaxp/properties/entityExpansionLimit' is not 
recognized.
Compiler warnings:
  WARNING:  'org.apache.xerces.jaxp.SAXParserImpl: Property 
'http://javax.xml.XMLConstants/property/accessExternalDTD' is not recognized.'
Warning:  org.apache.xerces.parsers.SAXParser: Feature 
'http://javax.xml.XMLConstants/feature/secure-processing' is not recognized.
Warning:  org.apache.xerces.parsers.SAXParser: Property 
'http://javax.xml.XMLConstants/property/accessExternalDTD' is not recognized.
Warning:  org.apache.xerces.parsers.SAXParser: Property 
'http://www.oracle.com/xml/jaxp/properties/entityExpansionLimit' is not 
recognized.
180110 [DEBUG] Multipage report: 0 subreports
180134 [DEBUG] Velocimacro : added #relreplace(  text ) : source = 
META-INF/maven/site.vm
...
180145 [DEBUG] Velocimacro : added #forkMeOnGitHub(  ) : source = 
META-INF/maven/site.vm
180205 [INFO] Generating Checkstyle report--- 
maven-checkstyle-plugin:2.9.1

Greetings
Bernd


Am Sun, 18 May 2014 14:38:56 -0400
schrieb Jason van Zyl ja...@takari.io:

 It's the site phase itself that takes a long time.
 
 On the commons-vfs core module it's takes little time:
 
 https://gist.github.com/jvanzyl/69c038c0f100803f10db
 
 I argue that the release should always be in a ready state to
 release, all requirements need to be met at all times in order for
 this to be the case. Aside from the surprise factor at release time
 when something doesn't work.
 
 On May 18, 2014, at 2:15 PM, Bernd Eckenfels e...@zusammenkunft.net
 wrote:
 
  Currently the Rat Report in the Site phase of commons-vfs takes
  enormous time, for really no good use when the commits are reviewed
  anyway (and it has all kinds of excludes and warnings you manually
  need to check).
  
  So I argue it would be better to run it only in relase (candidate)
  builds. Not sure if the same process applies to maven development.
  
  Greetings
  Bernd
  
  Am 18.05.2014 um 19:43 schrieb Jason Pyeron jpye...@pdinc.us:
  
  -Original Message-
  From: Jason van Zyl 
  Sent: Sunday, May 18, 2014 13:05
  
  Right now though we require all files to have license headers 
  we do not run the check to verify this by default.
  
  Can it be turned off by option?
  
  It kept dinging me until I turned it on by default in Maven 
  core. Someone currently trying to contribute has no idea this 
  is a requirement and is not told so because it doesn't run by 
  default. If it's required how about we just run all the time 
  everywhere?
  
  What phase? 
  
  
  I would like to change the POMs so that it always runs. 
  Having to run RAT separately is a usability fail. The chances 
  of anyone contributing knowing they have to run it are pretty 
  close to zero.
  
  Anyone see a reason not to always run it?
  
  How much time do they take (add)?
  
  -Jason
  
  --
  -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  -   -
  - Jason Pyeron  PD Inc. http://www.pdinc.us -
  - Principal Consultant  10 West 24th Street #100-
  - +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
  -   -
  -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  This message is copyright PD Inc, subject to license 20080407P00.

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

Re: Thoughts on MNG-5626 and the need for a log file

[Bernd Eckenfels]

Sorry I was not clear, what I was trying to say is: maven has logging
built in, if you need a logfile you can pass the -l switch or
re-configure slf4j. It also has some control over the loglevel (-X).
Most users dont need it because they (think CI Server) just catch
stdout.

http://maven.apache.org/maven-logging.html

Gruss
Bernd

Am Mon, 5 May 2014 15:14:33 -0500 schrieb Paul
Benedict pbened...@apache.org:

 -X is debug/stack traces, right? That's great when you want a
 slosh-load of debug information, but that's only useful when you're
 looking for a problem. There's no recourse when problems oddball
 conditions occur with -X not enabled. My point is Maven and Maven
 plugins should be able to log those abnormal conditions in the course
 of a normal build. We shouldn't have to dump the world -- especially
 when the problem is not always repeatable.
 
 
 
 
 Cheers,
 Paul
 
 
 On Mon, May 5, 2014 at 2:38 PM, Bernd Eckenfels
 e...@zusammenkunft.netwrote:
 
  Am Mon, 5 May 2014 14:17:50 -0500
  schrieb Paul Benedict pbened...@apache.org:
 
   What should be logged? Warnings. I actually would propose
   exceptions too because them on the screen only help if you have
   logging like a Hudson instance to view them.
 
  Uh, what is wrong with mvn -X -l?
 
  Gruss
  Bernd
 
  -
  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: Thoughts on MNG-5626 and the need for a log file

[Bernd Eckenfels]

Am Mon, 5 May 2014 14:17:50 -0500
schrieb Paul Benedict pbened...@apache.org:

 What should be logged? Warnings. I actually would propose exceptions
 too because them on the screen only help if you have logging like a
 Hudson instance to view them.

Uh, what is wrong with mvn -X -l?

Gruss
Bernd

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

Re: Thoughts on MNG-5626 and the need for a log file

[Bernd Eckenfels]

Sorry I was not clear, what I was trying to say is: maven has logging
built in, if you need a logfile you can pass the -l switch or
re-configure slf4j. It also has some control over the loglevel (-X).
Most users dont need it because they (think CI Server) just catch
stdout.

http://maven.apache.org/maven-logging.html

Gruss
Bernd

Am Mon, 5 May 2014 15:14:33 -0500 schrieb Paul
Benedict pbened...@apache.org:

 -X is debug/stack traces, right? That's great when you want a
 slosh-load of debug information, but that's only useful when you're
 looking for a problem. There's no recourse when problems oddball
 conditions occur with -X not enabled. My point is Maven and Maven
 plugins should be able to log those abnormal conditions in the course
 of a normal build. We shouldn't have to dump the world -- especially
 when the problem is not always repeatable.
 
 
 
 
 Cheers,
 Paul
 
 
 On Mon, May 5, 2014 at 2:38 PM, Bernd Eckenfels
 e...@zusammenkunft.netwrote:
 
  Am Mon, 5 May 2014 14:17:50 -0500
  schrieb Paul Benedict pbened...@apache.org:
 
   What should be logged? Warnings. I actually would propose
   exceptions too because them on the screen only help if you have
   logging like a Hudson instance to view them.
 
  Uh, what is wrong with mvn -X -l?
 
  Gruss
  Bernd
 
  -
  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

help text maven-javadoc-plugin contains (lost) link

[Bernd Eckenfels]

Hello,

I noticed in the output of javadoc:help a sentence which I could not
understand:

# javadoc:fix
#   Fix Javadoc documentation and tags for the Java code for the
#   project. See Where Tags Can Be Used.

When looking at the generated site it is more clear, as this is a HTML
link.

http://maven.apache.org/plugins/maven-javadoc-plugin/fix-mojo.html

-
http://docs.oracle.com/javase/1.5.0/docs/tooldocs/windows/javadoc.html#wheretags


BTW: the 8 version is here:
http://docs.oracle.com/javase/8/docs/technotes/tools/windows/javadoc.html#CHDHJGAH


Should I report this as an bug?

Bernd

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

Re: help text maven-javadoc-plugin contains (lost) link

[Bernd Eckenfels]

Am Wed, 30 Apr 2014 02:31:21 +0200
schrieb Bernd Eckenfels e...@zusammenkunft.net:

 # javadoc:fix
 #   Fix Javadoc documentation and tags for the Java code for the
 #   project. See Where Tags Can Be Used.

Another thing I notices is, it inserts single-line comments like this:

+/**
+ * pConstructor for FileFilterSelector./p
+ */

But I am not sure if p.../p - especially in the first line - is
the wanted syntax?

I also did not find a way to not generate the default @author tag. In
the description of the defaultVersion property it looks like a SVN
keyword was expanded unexpectetly.

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

Re: Not a local repository. It is a local repository cache. (was: Fwd: Why Is Maven Ignoring My Local Repo?)

[Bernd Eckenfels]

Am Thu, 17 Apr 2014 07:43:13 -0400
schrieb Igor Fedorenko i...@ifedorenko.com:

 My problem with current behaviour is that the same location is used as
 both cache for remote artifacts and repository for locally installed
 artifacts.

Actually I agree, it would be good to have a real cache which is 1:1
existing for each defined remote repo, and the default local repo,
which only contains stuff you installed in.

This would also reduce checksum conflicts, avoids the special from
where is it properties and allows to more selectively purge cache
content (by deleting for example only the cache of the 'snapshot-repo')

(But I guess this would slow down searching/resolution?)

Bernd

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

Re: Not a local repository. It is a local repository cache. (was: Fwd: Why Is Maven Ignoring My Local Repo?)

[Bernd Eckenfels]

Am Thu, 17 Apr 2014 13:40:38 +0200
schrieb Jörg Schaible joerg.schai...@swisspost.com:
  Clearly, removing the ability to install artifacts locally would be
  a very bad idea since it would make it more difficult for casual
  users to use Maven for casual builds (e.g., I regularly use it to
  build sample projects for customers that I never intend to do
  anything else with once I send it to the customer).
 
 A remote repository is specified with an URL. Nobody prevents you
 from using a file URL i.e. having a real local repository on your
 disk.

Or using mvn verify and pick up the artifacts in target/ where they
are easier to find anyway. (which does of course not work if multiple
ad-hoc projects depend on each other)

(This is BTW a personal pet peeve, any idea why eclipse e2m offers some
default targets but the verfiy (or at least package) goal is none of
them.)

Gruss
Bernd

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

Re: Model Version 5.0.0

[Bernd Eckenfels]

Hello,

it is not yet finished, and I am not sure if it actually would work for
most scenarios. But I was starting a plugin which allows to maintain
and create a checksum lock file for dependencies.

The basic idea is, that when I distribute a released maven project
(source) via for example Git, I want to enable the builders to check if
they are actually using the same dependencies than I was locking.

https://github.com/ecki/lockdep-maven-plugin

This is somewhat inspired by this:
https://github.com/nicoulaj/checksum-maven-plugin

The idea is especially to catch overwritten repository releases and
rough proxies. With the extra lock file it should be easier to adopt to
new versions.

Greetings
Bernd


 Am Mon, 24 Mar 2014 11:19:30 +0100
schrieb Baptiste Mathus bmat...@batmat.net:

 Hi,
 
 Sorry if it's the wrong thread, just let me know.
 
 I thought I'd dump that thought I've had for some time here: was
 enriching a bit the dependency block already discussed?
 
 So that one can somehow express a checksum tag. I'm posting this
 here since this would also require a pom upgrade.
 I've re-read the recent threads but didn't find anything about it.
 Also crawled JIRA without luck (though I guess this has already been
 reported somewhere).
 
 Something like
 
 *dependency*
 *  groupId...*
 *  artifactId...*
 *  version...*
 *  checksumsha1:2cfc5458ff56d559316b901a348bbcad01d3ce62/checksum*
 */dependency*
 
 WDYT?
 
 Cheers
 
 
 2014-02-26 21:50 GMT+01:00 Robert Scholte rfscho...@apache.org:
 
  Hi,
 
  I think this is good start and I would expect that the planned
  consumer pom.xml would still validate against the model 4.0.0 xsd,
  since now it is the standard file being uploaded and used by a lot
  of build management tools.
  If there are some flaws in the current XML, this could be the right
  moment to design a new consumer specific XML, maybe together with
  the Aether team for example.
 
  Robert
 
  Op Wed, 26 Feb 2014 01:59:29 +0100 schreef Stephen Connolly 
  stephen.alan.conno...@gmail.com:
 
 
   That is a modelVersion 4.0.0 consumer pom unless I am mistaken.
  What we/I
  want from a consumer pom is more than modelVersion 4.0.0 pom with
  inheritance interpolated and properties resolved
 
  On Tuesday, 25 February 2014, Jörg Hohwiller jo...@j-hohwiller.de
  wrote:
 
   Hi there,
 
  just for the record to this thread:
  I wrote consumer-maven-plugin and added it to MOJOs sandbox.
  The plugin allows to generate a consumer POM and apply it to the
  current MavenProject (via setFile).
  So we can already test various impacts of what can, will and
  should happen
  when a consumer POM is installed, signed, deployed instead of
  the original pom.xml file that can later on be in future model
  formats.
 
  See thread on dev mojo with subject consumer-maven-plugin added
  to sandbox.
  Hope to hear from you.
 
  Kind regards
Jörg
 
  Am 24.11.2013 23:04, schrieb Barrie Treloar:
 
   On 25 November 2013 03:28, Stephen Connolly
  stephen.alan.conno...@gmail.com wrote:
  [del]
 
   Given that we have decided that the reporting stuff possibly
  was a
  mistake... Well let's drop that
 
  Given that profiles do not make sense in deployed poms... Drop
  them too
 
  We think repositories is evil... Let's drop that... We've
  dropped build
  and reporting= no need for pluginRepositories at all so.
 
   I'm in favour of cleaning out elements that cause problems
  when they
  are tweaked in a the non-Maven Way.
  The emails to the users list would be reduce and there is less
  chance of causing confusion.
 
  Applying the current best practises and baking them into the
  poms is a good thing.
 
 
 
 
 
  -
  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: [VOTE] Release ASF Parent POM version 14

[Bernd Eckenfels]

Hello,

not a vote but a question, where is the point in still supporting
maven2? That additional profile makes the file harder to read. And it
somewhat is encouraging to use such a old version.

Since this is a new major version and it is not expected anybody would
switch to that version if he still maintains maven 2.x POMs I am not
sure where that is coming from I wonder?

Bernd


 Am Thu, 06 Mar 2014 22:18:56
+0100 schrieb Hervé BOUTEMY herve.bout...@free.fr:


 Hi,
 
 Changes since the last release: 
 http://svn.apache.org/viewvc/maven/pom/tags/apache-14/pom.xml?r1=HEADr2=1434717diff_format=h
 
 Staging repo: 
 https://repository.apache.org/content/repositories/orgapacheapache-1000/
 https://repository.apache.org/content/repositories/orgapacheapache-1000/org/apache/apache/14/apache-14-source-release.zip
 
 Source release checksum:
 apache-14-source-release.zip sha1:
 6bed0856a4cc8d9ee5f4481b8a1e0a4460076073
 
 Staging site: 
 http://maven.apache.org/pom-archives/asf-LATEST/ 
 
 Guide to testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html
 
 Vote open for 72 hours.
 
 [ ] +1
 [ ] +0
 [ ] -1
 
 -
 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: [VOTE] Release ASF Parent POM version 14

[Bernd Eckenfels]

Am Thu, 6 Mar 2014 16:56:27 -0500
schrieb Benson Margulies bimargul...@gmail.com:

 This is the POM for all of Apache. It's not for us to tell the rest of
 Apache to stop using Maven 2.2.1 just yet.

I understand that, but if somebody wants to use maven2 would it
actually switch to this major version? 

(Is there actually a test which checks if all those upgraded plugin
dependencies still work with 2.x? It seems to not come with a
integration test)

Gruss
Bernd

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

Re: Exposing security vulnerability information (CVEs) when building with Maven

[Bernd Eckenfels]

Hello Mark,

Just wanted to point you to a redhat project which I recently discovered, as it 
seems to have potential for this (even if the approach is not the most 
decentralized one): 

The Victims Database maps JAR Signatures to known vulnerabilities, if this is 
extended with maven coordinates  it would be a real helpfull static analysis 
tool for build time.

https://securityblog.redhat.com/2013/01/02/detecting-vulnerable-java-dependencies-at-build-time/
http://victi.ms

Greetings
Bernd

 Am 27.02.2014 um 11:34 schrieb Mark Thomas ma...@apache.org:
 
 Hi,
 
 For those of you that don't know me, one of my roles at the ASF is as a
 member of the Apache Security Team. One of the common problems we face
 when processing a security vulnerability report is how to identify the
 projects that depend on the vulnerable library. What I wanted to explore
 with the Maven dev community is the possibility of doing something along
 the following lines:
 
 1. Add the ability to publish vulnerability information to a Maven
 repository.
 
 2. Enhance Maven to check that vulnerability information when building a
 project and warn users that that are building using a library with known
 vulnerabilities.
 
 As an aside, it might be nice to be able to publish de-support notices
 or similar along the same sort of lines so users building with old,
 unsupported libraries are also warned.
 
 Users would, of course, need an option to silence individual warnings if
 they are happy that they do not apply to their product.
 
 Does something like the above sound possible? Is it already possible and
 I have just missed it?
 
 Cheers,
 
 Mark
 
 
 -
 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: What is in a version? (was Towards faster releases)

[Bernd Eckenfels]

Hello,

If you include new functionality this means that according to semver you 
increase the second digit, which means conservative users will do this upgrade 
step not so easy anymore  (and therefore miss all future fixes).

I would rather include enhancements anyway but divert from strict semver: The 
most visible change would be that the minimum prerequisites for a plugin needs 
to observe the last digit (like it is today). So the meanings of the digits are 
more risk than compatibility oriented.

Applying stricter semver would require to not ship enhancements until a new 
functional release is cut (and then deciding if older functional releases still 
get bugfixes or not).

Bernd

BTW: I think this is totally Independent of the topic if running Integration 
builds with automatic promotions.

 Am 19.02.2014 um 15:36 schrieb Paul Benedict pbened...@apache.org:
 
 I don't see any necessity to restrict patch releases to patches only -- as
 long as any new functionality is a tiny enhancement and doesn't make
 incompatibilities. Save medium/major structural changes for a new minor
 version.
 
 
 On Wed, Feb 19, 2014 at 7:37 AM, Benson Margulies 
 bimargul...@gmail.comwrote:
 
 A bit of a recap:
 
 Let's say that our goal as a group was to be very responsive to user's
 bug reports.
 
 So, we'd want to make fixes and releases, 'promptly', for some
 definition of prompt.
 
 But no one will install those releases if they are not confident that
 they are, in fact, not going to have unexpected consequences.
 
 From a black-box standpoint, this can only be achieved with really
 strong integration tests.
 
 From a white-box standpoint, it seems to me that the Maven core has a
 tendency towards complex interactions in which a fix to problem (a)
 can have unexpected consequence (b).
 
 So, either way, Jason's views about testing seem spot-on. This leaves
 a question: should we be trying, still, to follow up a 3.2.0 with a
 pure bugfix 3.2.1, and holding off on structural repairs or new
 features until 3.3? One view is that we should try to get some of the
 tests improved and some of the structural repairs done before we make
 any attempt at semver/responsive releases. The other view is that
 should try to deliver on semver as best we can.
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 -- 
 Cheers,
 Paul

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

Getting a list of used artifacts

[Bernd Eckenfels]

Hello,

I want to write a plugin which does dump/verify the hashes of all
dependencies and plugins used in the build. That way I can lock
dependencies in the source not only by version, but also by checksum.

I have currently the following

@Mojo(requiresDependencyCollection=TEST)
project.getArtifacts()
project.getPluginArtifacts()

This looks about right, I get the dependencies of my project as well as
some plugins. For the Artifacts of the plugins I dont see a file
location, what would be the best way to get a file handle. Or is there
an alternate method where I can get the SHA1 hash of the (used) files?

Do you think this is a robust method to get hold of the most resolved
dependencies?

Gruss
Bernd

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

Re: Getting a list of used artifacts

[Bernd Eckenfels]

Am Thu, 13 Feb 2014 02:19:17 +0100
schrieb Bernd Eckenfels e...@zusammenkunft.net:
 @Mojo(requiresDependencyCollection=TEST)
 project.getArtifacts()
 project.getPluginArtifacts()

Actual test  source is here:
https://github.com/ecki/lockdep-maven-plugin

Gruss
Bernd

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

Re: JDK 8 Build 121 JDK 7 Update 60 build 02 are available on java.net

[Bernd Eckenfels]

Hello Rory,

after having repeatingly problems in our WebStart Application (die to  
changed behaviour in Updates) I have tested with U60 and I havent seen any  
new problems compared to U45. I did not do server side (performance) tests  
yet.


With JDK8 I did only a  few smaller (default maven JAR phase based)  
compile tests (for example adding OracleJDK8 to the build environemnt  
matrix on Travis-CI.org - but without using -target 1.8). I havent seen  
problems in this area.


I think it is a but confusing that the manage site list dialog contains a  
textfield (which allows edit) when the list is empty but I guess thats not  
a critical problem.


Greetings
Bernd


Am 30.12.2013, 13:19 Uhr, schrieb Rory O'Donnell Oracle, Dublin Ireland  
rory.odonn...@oracle.com:



Hi,

I am from the OpenJDK QA group at Oracle, and I'm trying to get an idea
about how much community
testing is happening on JDK 8 EA builds (either those published by
Oracle, or your own) and to encourage
more of it to happen see:
http://mail.openjdk.java.net/pipermail/quality-discuss/2013-November/000152.html


I'm curious if you have begun testing against JDK 8 or JDK 7u60 EA
builds, if you've run into showstopper
issues, and if you'd like to continue to discuss the subject on the
quality-discuss mailing list in OpenJDK,
of course.

I am aware of https://bugs.openjdk.java.net/browse/JDK-8030781 , if
there are any other issues please let
me know.

JDK 8 Build b121 Early Access Build is now available for download
http://jdk8.java.net/download.html  test.
JDK 7u60 b02 Early Access Build is also available for download
https://jdk7.java.net/download.html test.

Rgds,Rory




--
http://www.zusammenkunft.net

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

Re: [VOTE] Apache Maven SCM 1.9 (take 2)

[Bernd Eckenfels]

Am 03.12.2013, 02:47 Uhr, schrieb Olivier Lamy ol...@apache.org:

For some reasons I don't understand yet why defaultExclude=false
doesn't work for CVS directories.


Uh, isnt that supposed to be yes to enable the exclusion of default  
patterns?


Gruss
Bernd

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

Re: More hard problems...

[Bernd Eckenfels]

Am 26.11.2013, 22:02 Uhr, schrieb Robert Scholte rfscho...@apache.org:
In addition to this story: There's an open issue called MDEPLOY-118  
which describes a related issue: how to release the same version for  
different platforms?


Related there is also the need for features. Larger projects typically  
have a lot of optional dependencies but dont help to requesat a specific  
subset. For example a Scheduler like Quartz offers a core engine but also  
EJB APIs or a Servlet manager implementation. In an ideal world the  
project would be split into multiple artifacts, but even then there can be  
a complexity explosion. Depending on the core scheduler feature of  
quartz would then skip all optional dependencies (like servlet and EJB  
API).


(This is similiar to the testing scope, which could be implemented as a  
well known feature). And this also goes in line with  
platforms/implementations: the jdk1.4 feature can depend on a  
concurrent-backport wherees the java7 does not.


Gruss
Bernd

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

Re: [VOTE] Apache Maven SCM 1.9

[Bernd Eckenfels]

I sometimes have the problem that the explorer extension tgitcache from 
Tortoise keeps handles open in git directories. Maybe your test machine has 
that installed?

 Am 25.11.2013 um 19:46 schrieb Robert Scholte rfscho...@apache.org:
 
 I have an appointment tonight, will try it afterwards or tomorrow with a 
 clean checkout.
 
 Robert
 
 Op Mon, 25 Nov 2013 19:43:58 +0100 schreef Dominik Bartholdi 
 d...@fortysix.ch:
 
 Thats really disappointing, specially as I have finally managed to get hold 
 on a windows PC and I just run everything 10times in row without any issues… 
 :(
 I’m pretty much out of ideas :(
 If anyone has any hand he can share, that would be great!
 I tried with: Windows 7, Java 1.6.0_17-b04, maven 3.1.1
 Domi
 
 
 On 24.11.2013, at 21:01, Robert Scholte rfscho...@apache.org wrote:
 
 Hmm, maybe I cheered too early. A second run gave me 6 errors.
 Still unsure what is keeping a lock of the files.
 Both 'mvn clean' and 'rmdir /S target' fail.
 
 F:\java-workspace\apache-maven-scm\maven-scm\maven-scm-providers\maven-scm-provi
 ders-git\maven-scm-provider-jgitrmdir /S target
 target. Weet u het zeker (J/N)? j
 target\scm-test\WORKIN~1\GIT~1\objects\pack\pack-3ecde7a8782b53b94510513a4b1275d
 7e33392a9.idx - Toegang geweigerd.
 target\scm-test\WORKIN~1\GIT~1\objects\pack\pack-3ecde7a8782b53b94510513a4b1275d
 7e33392a9.pack - Het proces heeft geen toegang tot het bestand omdat het 
 door ee
 n ander proces wordt gebruikt.
 
 translations:
 - Are you sure (Y/N)
 - Access denied
 - The process has no access to the file because it is used by another 
 process.
 
 Robert
 
 
 Op Sun, 24 Nov 2013 20:43:35 +0100 schreef Robert Scholte 
 rfscho...@apache.org:
 
 We're getting closer, only one error left:
 
 Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.926 sec 
  FA
 ILURE! - in 
 org.apache.maven.scm.provider.git.jgit.command.tag.JGitTagCommandTck
 Test
 testTagCommandTest(org.apache.maven.scm.provider.git.jgit.command.tag.JGitTagCom
 mandTckTest)  Time elapsed: 1.817 sec   ERROR!
 java.io.IOException: Could not delete file 
 F:\java-workspace\apache-maven-scm\ma
 ven-scm\maven-scm-providers\maven-scm-providers-git\maven-scm-provider-jgit\targ
 et\scm-test\updating-copy\.git\objects\pack\pack-3ecde7a8782b53b94510513a4b1275d
 7e33392a9.idx
   at org.eclipse.jgit.util.FileUtils.delete(FileUtils.java:180)
   at org.eclipse.jgit.util.FileUtils.delete(FileUtils.java:147)
   at org.eclipse.jgit.util.FileUtils.delete(FileUtils.java:149)
   at org.eclipse.jgit.util.FileUtils.delete(FileUtils.java:149)
   at org.eclipse.jgit.util.FileUtils.delete(FileUtils.java:149)
   at 
 org.apache.maven.scm.provider.git.jgit.command.tag.JGitTagCommandTckT
 est.deleteDirectory(JGitTagCommandTckTest.java:52)
 
 
 Results :
 
 Tests in error:
 JGitTagCommandTckTestScmTckTestCase.setUp:106-ScmTestCase.setUp:71-deleteDi
 rectory:52 ╗ IO
 
 Even when Maven has finished I still can't delete these files.
 
 Robert
 
 Op Sun, 24 Nov 2013 19:30:22 +0100 schreef Dominik Bartholdi 
 d...@fortysix.ch:
 
 Hi everyone,
 I think I solved all the issues we had on windows with the jgit-provider
 @Robert can you have another try now?
 The build https://builds.apache.org/job/maven-scm/ currently fails, but 
 this is related to an issue with the upload to the snapshot repository at 
 https://repository.apache.org/content/repositories/snapshots/
 regards Domi
 
 
 On 29.10.2013, at 09:27, Olivier Lamy ol...@apache.org wrote:
 
 for the record vote cancel.
 
 
 On 29 October 2013 17:20, Domi d...@fortysix.ch wrote:
 I was pointed to Matthias Sohn (jgit commiter) let's see if he has an 
 idea, before we do a release of this.
 His first thought was the WindowCache.reconfigure() - but Robert 
 already fixed that.
 /Domi
 
 Am 28.10.2013 um 20:51 schrieb Robert Scholte rfscho...@apache.org:
 
 @Kristian: Brilliant data!
 
 @Dennis: the statistics have changed[1]. I managed to fix it a bit, 
 but as Kristian mentioned: some parts are out of reach and can't be 
 closed by our code (let's avoid reflection!).
 
 I believe that in this case the Windows behavior is the preferred one: 
 if you open a stream, you should close it too.
 Anyhow, we need a fix from JGit.
 
 Since the JGit is not yet part of the Maven SCM Standard Providers I 
 think we are safe.
 Users need to explicitly add this provider if they want to use it.
 So a non Windows compatible warning on the website is fine by me.
 
 Robert
 
 [1] https://builds.apache.org/job/maven-scm-windows/
 
 Op Mon, 28 Oct 2013 16:15:06 +0100 schreef Dennis Lundberg 
 denn...@apache.org:
 
 Thanks a lot Kristian!
 
 Do I understand you correctly that the leak is in the jgit Checkout 
 command?
 If so, there are probably more leaks in there since 9 of our tests
 fail, each testing a different command. Some tests do succeed though.
 
 So how do we proceed with this?
 Submit patches for jgit?
 Release maven-scm as is? If so we need to inform our users about the