Re: Can properties be inherited like I expect them to be?

[Gary Gregory]

Hi Tamas,

Thank you for looking into this!

Gary

On Sun, Apr 21, 2024 at 10:27 AM Tamás Cservenák  wrote:
>
> Howdy,
>
> I did locally this
> https://gist.github.com/cstamas/25f6c978d3eb0823fd0af8ef25c08d6f
>
> And I think I got the behaviour that you expect.
>
> Given a project can be built only with Java8+ this should be ok.
>
> T
>
> On Sun, Apr 21, 2024 at 4:03 PM Gary Gregory  wrote:
>
> > Hi,
> >
> > A POM can't seem to inherit a parent POM configuration with properties
> > redefined in a child POM profile.
> >
> > Am I doing something wrong?
> >
> > For example:
> >
> > git clone https://gitbox.apache.org/repos/asf/commons-bcel.git
> > cd commons-bcel
> > git checkout eba45c05365fc89b0007296fc3ee188cca5d091d
> > maven
> >
> > This REQUIRES using Java 8, run the default goal: `mvn`
> >
> > and you'll get JaCoCo check failures because properties like
> > commons.jacoco.classRatio are not (apparently) overridden in the Java
> > 8 profile (id java-8) from 0.90 to 0.89.
> >
> > [INFO] Loading execution data file
> > /Users/garydgregory/git/commons-bcel/target/jacoco.exec
> > [INFO] Analyzed bundle 'bcel' with 408 classes
> > [WARNING] Rule violated for bundle bcel: classes covered ratio is
> > 0.89, but expected minimum is 1.00
> > [WARNING] Rule violated for bundle bcel: instructions covered ratio is
> > 0.65, but expected minimum is 0.90
> > [WARNING] Rule violated for bundle bcel: methods covered ratio is
> > 0.70, but expected minimum is 0.95
> > [WARNING] Rule violated for bundle bcel: branches covered ratio is
> > 0.59, but expected minimum is 0.85
> > [WARNING] Rule violated for bundle bcel: lines covered ratio is 0.68,
> > but expected minimum is 0.90
> > [WARNING] Rule violated for bundle bcel: complexity covered ratio is
> > 0.58, but expected minimum is 0.85
> >
> > Is there a way to get this to work?
> >
> > TY,
> > Gary
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >

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

Can properties be inherited like I expect them to be?

[Gary Gregory]

Hi,

A POM can't seem to inherit a parent POM configuration with properties
redefined in a child POM profile.

Am I doing something wrong?

For example:

git clone https://gitbox.apache.org/repos/asf/commons-bcel.git
cd commons-bcel
git checkout eba45c05365fc89b0007296fc3ee188cca5d091d
maven

This REQUIRES using Java 8, run the default goal: `mvn`

and you'll get JaCoCo check failures because properties like
commons.jacoco.classRatio are not (apparently) overridden in the Java
8 profile (id java-8) from 0.90 to 0.89.

[INFO] Loading execution data file
/Users/garydgregory/git/commons-bcel/target/jacoco.exec
[INFO] Analyzed bundle 'bcel' with 408 classes
[WARNING] Rule violated for bundle bcel: classes covered ratio is
0.89, but expected minimum is 1.00
[WARNING] Rule violated for bundle bcel: instructions covered ratio is
0.65, but expected minimum is 0.90
[WARNING] Rule violated for bundle bcel: methods covered ratio is
0.70, but expected minimum is 0.95
[WARNING] Rule violated for bundle bcel: branches covered ratio is
0.59, but expected minimum is 0.85
[WARNING] Rule violated for bundle bcel: lines covered ratio is 0.68,
but expected minimum is 0.90
[WARNING] Rule violated for bundle bcel: complexity covered ratio is
0.58, but expected minimum is 0.85

Is there a way to get this to work?

TY,
Gary

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

Re: Maven & Github codespaces

[Gary Gregory]

How about XInclude?

Gary

On Mon, Apr 1, 2024, 7:40 AM Tommy Svensson  wrote:

> Hello Tamás,
>
> The problem is in mixin-maven-plugin which I found on GitHub and is 5
> years old! In this world that is a lot :-). It suddenly fails to find a
> "StringUtils" package that does not seem to exist in Maven Central. I
> suspect that StringUtils is something that should never have been submitted
> to maven-central, and have now been removed.
>
> So I'm looking for some other solution to re-use pom segments, in a future
> compatible way.
>
> /Tommy
> __
> Tommy Svensson
> to...@natusoft.se
>
>
>
> Från: Tamás Cservenák 
> Svara: Maven Users List 
> Datum: 1 april 2024 at 13:02:43
> Till: Maven Users List 
> Cc: Bernd Eckenfels 
> Ämne:  Re: Maven & Github codespaces
>
> Hi Tommy,
>
> would be good for reference (maybe someone else hits a similar issue) to
> have on ML the "solution" as well. At least some description of what
> exactly made you think "forgett maven on GitHub codespaces" and what you
> did to fix this.
>
> Thanks
> T
>
> On Mon, Apr 1, 2024 at 12:40 PM Tommy Svensson 
> wrote:
>
> > My brain screwed upp here! I incorrectly took this to be a maven issue!
> I
> > have just figured out that Maven has nothing to do with this problem!
> > Sorry!
> >
> > When I came to that conclusion things made much more sense :-).
> > __
> > Tommy Svensson
> > to...@natusoft.se
> >
> >
> >
> > Från: Bernd Eckenfels 
> > Svara: Maven Users List 
> > Datum: 31 mars 2024 at 23:59:20
> > Till: users@maven.apache.org 
> > Ämne: Re: Maven & Github codespaces
> >
> > Tommy Svensson wrote on 31. Mar 2024 14:52 (GMT +02:00):
> >
> > > …I have old jars somewhere! I should clean my
> > > ~/.m2/repository!
> >
> > It should work regardless what you have on your local reponczche since
> > it’s versioned. But other question how is that related to what’s in a
> fresh
> > codespace? Something goes not check out. Or are you saying it does
> never
> > work?
> >
> > Gruß
> > Bernd
> > —
> > https://bernd.eckenfels.net
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
>

Re: How to include only certain test packages in a maven test-jar & all non test code in a non test jar?

[Gary Gregory]

I think the "simple" solution is to use 2 maven modules, then you don't
need to do anything special. The layout does not make sense to me so I must
be missing something. If the common code is needed for both main and test,
then it should be in main. You can put that common code in its own package
to signal its specific purpose.

Gary


On Fri, Mar 22, 2024, 3:29 AM Debraj Manna  wrote:

> I have a Maven module named synapse.
>
> main
>   java
> package1
>   A.java
>
> test
>   java
> common
>   C.java
> package1
>   ATest.java
>
> Can someone let me know if in Maven I can create a non-executable jar
> containing all non-test code (main/) and another test-jar containing only
> the code under the package test/java/common?
>
> I tried the below
>
> 
>   
>
> org.springframework.boot
> spring-boot-maven-plugin
> 
>   true
> 
>
>
>  org.apache.maven.plugins
>  maven-jar-plugin
>  3.3.0
>  
>   
> common/**
>   
> 
> 
>   
> 
>   test-jar
> 
>   
> 
>   
>  
>   
>
> I am observing that the test-jar is getting created as expected containing
> only the code from test/java/common but the non-executable, non-test jar
> does not contain the code from main/java/package1.
>
>- Maven Version - 3.8.4
>- Java 17
>

Re: [DISCUSS] Maven Dependency Plugin

[Gary Gregory]

The one I use the most from the command line is "tree" (
https://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.html)

I wish I could say "ignore test scope" to help me understand my runtime
dependencies better.

Gary


On Thu, Mar 21, 2024, 12:06 PM Tamás Cservenák  wrote:

> Howdy,
>
> I'd would be interested in how users and devs are using
> maven-dependency-plugin:
> https://maven.apache.org/plugins/maven-dependency-plugin/
>
> I collected some basic questions I'd like to have answered (but feel free
> to add more info!):
> - which goals are "must have" for you
> - which goals are "I never touched" for you (or, "I really don't need" or
> "never used" or "shrug")
> - what is missing?
>
> Thanks
> T
>

Re: [VOTE] Require Java 17 for Maven 4

[Gary Gregory]

+1

Also good idea to remind folks to stay focused in a vote thread.

Gary

On Wed, Feb 28, 2024, 2:31 AM Benjamin Marwell  wrote:

> 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.
>
> This is a procedural majority vote [1*]:
> You can also vote with fractions and negative votes are not vetoes.
>
> Please also notice:
> * Maven 3 will stay at Java 8 no matter what.
> * We may raise Maven 4 to JDK 21 later if we feel like it (depending
> on the release date).
>   This is not part of this vote.
> * The linked PR is not part of this vote (this is not a code vote).
>   But you may take a look at it to understand the intended change.
>
> PR: https://github.com/apache/maven/pull/1430
>
> Maven-Parent will not be raised with this vote, the other PR is not
> part of this vote.
>
> Please refrain from starting discussions in this thread, but do
> include a reasoning on downvotes and feel free to start a new
> discussion on the mailing list, or comment on the existing ones.
>
> ---
>
> Vote open for 72 hours:
>
> [ ] +1 (set JDK17 min version for Maven 4.x)
> [ ] +0
> [ ] -1 (please include reasoning)
>
> ---
>
> - Ben
>
> [1*]: https://www.apache.org/foundation/voting.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Maven 4.0 release timeline

[Gary Gregory]

As a fly on the wall here, not a dev, I think a kinder view would
reinterpret Maven's position not as "ridiculous" but rather
"down-priority", as in "we are busy, we like fixing bugs, adding features,
and scheduling things is not as important, otherwise this would turn into a
real job ;-)"

Gary

On Tue, Dec 19, 2023, 12:20 AM Alexander Kriegisch 
wrote:

> Karl Heinz,
>
> my thoughts on your reply:
>
> > Maven 4.0.0 will be there when it's there.
>
> This is a totally valid statement, if this is the policy in the Apache
> Maven project. No objections at all.
>
> But:
>
> > We are an open source project. We don't have a release timeline.
>
> That is suboptimal response, to say it politely. OpenJDK and Eclipse IDE
> with dozens of simultaneously released components have release cycles
> for 6 (OpenJDK) and 3 (Eclipse SimRel) months with defined dates for
> certain phases like milestones, release candidates, general availability
> dates. I.e., you can say "Maven does not have a release timeline", fine.
> But giving the reason that you do not have one because Maven is OSS, is,
> with all due respect, just ridiculous.
>
> Regards
> --
> Alexander Kriegisch
> https://scrum-master.de
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Pure curiosity

[Gary Gregory]

Hey Tamas,

The big picture here is that we, over at Xalan-J, well, Joe's doing the
work, are porting Xalan-J from Ant to Maven.

Gary

On Sun, Nov 19, 2023, 7:05 PM Tamás Cservenák  wrote:

> Now am very interested where this goes, please continue...
>
> T
>
> On Mon, Nov 20, 2023, 00:26 Joseph Kesselman  wrote:
>
> > Maven's declarative nature may be its second greatest strength, following
> > platform independence and preceding the rich plugin collection.
> >
> > The lack of any _dependency_ driven flow below the module level --
> > apparently typically solved by throwing more modules into the mix just to
> > achieve sequencing, or trying to use the fixed sequencing of the stages
> --
> > may be its greatest weakness. Note that I'm still having to play games
> with
> > when site runs; site depends on code in the package, and the download
> > zipfiles depend upon site.
> >
> > Alex grants that if you're pushing declarative build design as a Maven
> > advantage, _make_ beat you the punch by about half a century, and is
> fully
> > dependency driven; its major downsides are that it doesn't have platform
> > independence and isn't new and sexy and markup language based.
> >
> > I really expected Maven to handle that better.
> >
> > So my half-thought is what it would take to change from stages to
> > dependencies,  and how much of the Maven design would have to be thrown
> out
> > the window to achieve it... or at least to draft a prototype that could
> > leverage what's already been done.
> >
> > Maven does beat Ant. And it has the plugin tooling and auto-fetch from
> > libraries. But the lack of dependency-driven execution Bothers me.
> >
> > Vlad favors Gradle. I don't know if Gradle is better, worse, or just
> > different, but from what he's said it sounds like it does have the
> ability
> > to update just what it must, as make did, and to handle sequences that
> > don't  match the predefined stage sequences. Maybe it's time to consider
> > crossbreeding.
> >
> > I may change my mind after further exposure to Maven, but that's my
> > reaction to what I've seen of it so far and how much help I needed to
> > understand its quirks.
> >
> >
> >
> > --
> >/_  Joe Kesselman (he/him/his)
> > -/ _) My Alexa skill for New Music/New Sounds fans:
> >/   https://www.amazon.com/dp/B09WJ3H657/
> >
> > Caveat: Opinionated old geezer with overcompensated writer's block. May
> be
> > redundant, verbose, prolix, sesquipedalian, didactic, officious, or
> > redundant.
> > 
> > From: Gary Gregory 
> > Sent: Sunday, November 19, 2023 5:55:40 PM
> > To: Maven Users List 
> > Subject: Re: Pure curiosity
> >
> > You can get an idea by downloading the source zip file from
> > https://maven.apache.org/download.cgi and and counting something like
> Java
> > source files or kilobytes' worth of Java files, or LoCs...
> >
> > FWIW, I see Gradle mentioned here and there in our issues. Using
> > Gradlebwould be a huge mistake IMO... I really don't like Gradle.
> >
> > Maven has its quirks, sure, but if you implement a build using Maven's
> > philosophy of "configuration by exception", you end up with a nice easy
> to
> > maintain build.
> >
> > Gary
> >
> > On Sun, Nov 19, 2023, 5:39 PM Joseph Kesselman 
> > wrote:
> >
> > > How large is the actual Maven core application itself, without even the
> > > "standard" plugins?
> > >
> > > (I've got half an idea and am trying to guess how much work it would be
> > to
> > > prototype something.)
> > >
> > > --
> > >/_  Joe Kesselman (he/him/his)
> > > -/ _) My Alexa skill for New Music/New Sounds fans:
> > >/   https://www.amazon.com/dp/B09WJ3H657/
> > >
> > > Caveat: Opinionated old geezer with overcompensated writer's block. May
> > be
> > > redundant, verbose, prolix, sesquipedalian, didactic, officious, or
> > > redundant.
> > >
> >
>

Re: Pure curiosity

[Gary Gregory]

I don't know what issue you're struggling with for the Maven build so we
should talk this week or discuss it over email. I don't want to ask you to
explain all of this over email if it's quicker to explain via voice. Maybe
we can start with: Where is the Maven build and what's the current hurdle?

Also note that the Maven devs can be quite helpful on their mailing list.

Gary


On Sun, Nov 19, 2023, 6:26 PM Joseph Kesselman  wrote:

> Maven's declarative nature may be its second greatest strength, following
> platform independence and preceding the rich plugin collection.
>
> The lack of any _dependency_ driven flow below the module level --
> apparently typically solved by throwing more modules into the mix just to
> achieve sequencing, or trying to use the fixed sequencing of the stages --
> may be its greatest weakness. Note that I'm still having to play games with
> when site runs; site depends on code in the package, and the download
> zipfiles depend upon site.
>
> Alex grants that if you're pushing declarative build design as a Maven
> advantage, _make_ beat you the punch by about half a century, and is fully
> dependency driven; its major downsides are that it doesn't have platform
> independence and isn't new and sexy and markup language based.
>
> I really expected Maven to handle that better.
>
> So my half-thought is what it would take to change from stages to
> dependencies,  and how much of the Maven design would have to be thrown out
> the window to achieve it... or at least to draft a prototype that could
> leverage what's already been done.
>
> Maven does beat Ant. And it has the plugin tooling and auto-fetch from
> libraries. But the lack of dependency-driven execution Bothers me.
>
> Vlad favors Gradle. I don't know if Gradle is better, worse, or just
> different, but from what he's said it sounds like it does have the ability
> to update just what it must, as make did, and to handle sequences that
> don't  match the predefined stage sequences. Maybe it's time to consider
> crossbreeding.
>
> I may change my mind after further exposure to Maven, but that's my
> reaction to what I've seen of it so far and how much help I needed to
> understand its quirks.
>
>
>
> --
>/_  Joe Kesselman (he/him/his)
> -/ _) My Alexa skill for New Music/New Sounds fans:
>/   https://www.amazon.com/dp/B09WJ3H657/
>
> Caveat: Opinionated old geezer with overcompensated writer's block. May be
> redundant, verbose, prolix, sesquipedalian, didactic, officious, or
> redundant.
> 
> From: Gary Gregory 
> Sent: Sunday, November 19, 2023 5:55:40 PM
> To: Maven Users List 
> Subject: Re: Pure curiosity
>
> You can get an idea by downloading the source zip file from
> https://maven.apache.org/download.cgi and and counting something like Java
> source files or kilobytes' worth of Java files, or LoCs...
>
> FWIW, I see Gradle mentioned here and there in our issues. Using
> Gradlebwould be a huge mistake IMO... I really don't like Gradle.
>
> Maven has its quirks, sure, but if you implement a build using Maven's
> philosophy of "configuration by exception", you end up with a nice easy to
> maintain build.
>
> Gary
>
> On Sun, Nov 19, 2023, 5:39 PM Joseph Kesselman 
> wrote:
>
> > How large is the actual Maven core application itself, without even the
> > "standard" plugins?
> >
> > (I've got half an idea and am trying to guess how much work it would be
> to
> > prototype something.)
> >
> > --
> >/_  Joe Kesselman (he/him/his)
> > -/ _) My Alexa skill for New Music/New Sounds fans:
> >/   https://www.amazon.com/dp/B09WJ3H657/
> >
> > Caveat: Opinionated old geezer with overcompensated writer's block. May
> be
> > redundant, verbose, prolix, sesquipedalian, didactic, officious, or
> > redundant.
> >
>

Re: Pure curiosity

[Gary Gregory]

You can get an idea by downloading the source zip file from
https://maven.apache.org/download.cgi and and counting something like Java
source files or kilobytes' worth of Java files, or LoCs...

FWIW, I see Gradle mentioned here and there in our issues. Using
Gradlebwould be a huge mistake IMO... I really don't like Gradle.

Maven has its quirks, sure, but if you implement a build using Maven's
philosophy of "configuration by exception", you end up with a nice easy to
maintain build.

Gary

On Sun, Nov 19, 2023, 5:39 PM Joseph Kesselman  wrote:

> How large is the actual Maven core application itself, without even the
> "standard" plugins?
>
> (I've got half an idea and am trying to guess how much work it would be to
> prototype something.)
>
> --
>/_  Joe Kesselman (he/him/his)
> -/ _) My Alexa skill for New Music/New Sounds fans:
>/   https://www.amazon.com/dp/B09WJ3H657/
>
> Caveat: Opinionated old geezer with overcompensated writer's block. May be
> redundant, verbose, prolix, sesquipedalian, didactic, officious, or
> redundant.
>

Re: mvn as used in Eclipse m2e gets parse error because of mistake in Maven 4.0.0 schema

[Gary Gregory]

I've seen that in Eclipse for a long time.

Gary

On Tue, Oct 17, 2023, 2:57 PM David Karr  wrote:

> I have a feeling this has been covered before, but I'll ask just in case.
>
> I have a pom.xml that inherits from a parent pom, and the child pom has the
> following plugin definition:
> --
> 
>   maven-compiler-plugin
>   3.8.0
>   
> 11
> 
>   
> org.projectlombok
> lombok
> 1.18.30
>   
> 
>   
> 
> --
>
> Notice the "combine.self" attribute. In a command line mvn build, this does
> exactly what it needs to, completely overriding the plugin configuration
> inherited from the parent pom.  If I don't have that, it results in errors
> because it "merges" the plugin configs by default.
>
> What's annoying is that if I open this pom.xml in Eclipse, with the m2e
> plugin, I get the following error on that line:
>
> cvc-complex-type.3.2.2: Attribute 'combine.self' is not allowed to
> appear in element 'configuration'.
>
> I, along with multiple other people, assumed that this indicates a bug in
> m2e, because it clearly works in the command-line build.  However, it was
> pointed out that m2e is actually USING the defined schema defined in the
> boilerplate of a pom.xml, instead of ignoring it, and if you open up that
> schema, it clearly shows the lack of an "attribute" element in the
> "configuration" complex-type.
>
> So, clearly mvn is using that attribute, but I'm guessing it's not doing
> any schema validation, or builds using that attribute would fail.
>
> I have a feeling this situation has been in place for a long time.
>

Re: moditect-maven-plugin: duplicate package export by Maven?

[Gary Gregory]

It kind of looks like Maven jars deliver overlapping packages which is
a no-go in JPMS.

Gary

On Mon, Oct 2, 2023 at 8:20 AM sebb  wrote:
>
> Apache Commons Build Plugin fails to build:
>
> [INFO] --- moditect-maven-plugin:1.0.0.Final:add-module-info
> (add-module-infos) @ commons-build-plugin ---
> ...
> Error: Modules maven.core and maven.repository.metadata export package
> org.apache.maven.artifact.repository.metadata to module
> org.apache.maven.resolver.spi
>
> Is this a problem in Maven? Or a bug in moditect?
>
> Sebb
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

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

Re: [DISCUSSION] Multi platform deploys/releases

[Gary Gregory]

Over at the Apache Commons project, we have two components: Commons
Daemon and Commons Crypto.

On top of JAR files, these components produce native binary libraries
for various OSs (Windows, macOS, Linux) and are brutally complicated
to release.

It could be possible to improve these builds using the Docker Maven
plugin and some complex POMs, but for now, there are a lot of manual
steps. Well, you can't just host any old OS on any old platform due to
licensing so it might not be solvable without build agents running on
dedicated hardware, for macOS at least.

Gary

On Sun, Jun 25, 2023 at 5:11 PM Tamás Cservenák  wrote:
>
> Howdy,
>
> Multiple times come up on ML questions from users about "multi platform"
> deploys/releases, where, AFAIK, some (usually) OS platform
> dependant (usually native binary), comes to play. This becomes more and
> more requested, for example with GraalVM, where you have to use OS
> targeting native code to build native image.
>
> A real atypical example from the ASF Maven project is maven-mvnd release,
> where macOS native binary is being added as manual step (another atypical
> problem of mvnd build process is not using remote repository for staging as
> none of it lands in Maven Central, but that is a completely different
> story).
>
> So, questions:
> - how are people doing it today?
> - what can Maven do to help more (if not fully support) this problem?
> - where can Maven (or maybe some dedicated existing or new plugin) help
> with this problem?
>
> I'd expect responses from users doing it, how they are doing it, to at
> least collect some "common patterns". IF your solution depends on some
> vendor (like CI or MRM), it would be okay to mention/explain what it
> is, but in general this thread is not meant as "feature comparison" across
> vendors. If your regular (by-commit or daily) "snapshot" deploy and
> "release" wildly differ, please describe it as well (how and why).
>
> Ideally, Maven should provide some or maybe even full (vendor neutral,
> regarding CI or MRM) support for these patterns.
>
> Thanks
> T

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

Re: improving the Maven BOM pattern

[Gary Gregory]

I am wondering if you've looked at the CycloneDx and SPDX Maven plugins?

These two seem to be the most used ATM for SBOMs.

Gary

On Wed, Jun 14, 2023, 19:05 Garret Wilson  wrote:

> Hi, everyone. I understand this list to be a general forum for Apache
> Maven users, so as such I'm sharing some ideas I've had related to BOMs.
>
> Over the years I've changed how I define "Bill of Material" POMs for my
> large, aggregated projects. Recently I've settled on a pattern which I
> feel is a refinement of the official Maven approach
> <
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms>
>
> for putting together a BOM. I've described the technique in my blog post
> I published today: /Improving the Maven Bill of Materials (BOM) Pattern/
> .
> Here's a summary.
>
> Assuming we have a project `com.example:…` with aggregated subprojects
> `com.example:foo` and `com.example:bar`, my technique uses the following
> directory structure:
>
> |pom.xml (BOM) parent-pom.xml ├── foo/ │ └── pom.xml └── bar/ └── pom.xml|
>
> Interestingly the top-level BOM aggregates all three POMs: the two
> submodule POMs as well as `parent-pom.xml` in the project root
> directory. The two submodules `foo` and `bar` use `parent-pom.xml` as
> their parent.
>
> I see this bringing a couple of benefits over the official approach in
> the documentation:
>
>   * Aggregated modules are easy to find—in the top-level POM where they
> logically should be.
>   * Other project dependencies and configurations are located nearby, in
> the `parent-pom.xml` file in the same project root directory as the
> BOM, not relegated to a separate subdirectory.
>
> The post goes into much more detail explaining the differences, with
> example of the POM contents.
>
> I'd be interested in feedback on this technique if you have any
> comments—especially if you find a flaw in this approach.
>
> Best,
>
> Garret
>

Re: Versions maven plugin

[Gary Gregory]

You'll need to know what the binary compatibility policy is for this plugin.

Gary

On Sat, May 27, 2023, 02:57 Andrzej  wrote:

> Hi all,
>
> I've been looking at Versions Maven Plugin and I can say that there are a
> few places that could use some refactoring.
>
> For example, VersionDetails and AbstractArtifactVersions serve several
> purposes: they seem to be both a collection of cached artifact versions,
> but at the same time store the information on the current version (unless
> they don't – like PropertyVersions which is a child of
> AbstractArtifactVersions). On top of that, they offer plenty of different
> utility methods for retrieving versions which may or not duplicate
> themselves.
>
> So, let's suppose I wanted to refactor that a little bit: is it ok to use
> Aether (like e.g. org.eclipse.aether.artifact.Artifact or
> org.eclipse.aether.version.VersionRange) API there? Or should I be looking
> somewhere else?
>
> Best regards,
> Andrzej
>

Re: Using the deploy plugin to deploy an Ant-built jar to Nexus

[Gary Gregory]

Thank you for the quick response Tamás!

Yet there is one :-( as confirmed by infra in the ticket.

Gary


On Sat, Apr 29, 2023, 12:43 Tamás Cservenák  wrote:

> From repository.a.o logs:
> Got exception during processing request "PUT
>
> https://repository.apache.org/service/local/staging/deploy/maven2/xalan/xalan/2.7.3/xalan-2.7.3.jar
> ":
> Cannot find a matching staging profile
>
> Thanks
> T
>
> On Sat, Apr 29, 2023, 18:38 Gary D. Gregory  wrote:
>
> > Hi all,
> >
> > Can someone offer advice on using the deploy plugin to deploy an
> Ant-built
> > jar to Nexus, please see
> https://issues.apache.org/jira/browse/INFRA-24533
> >
> > TY!
> > Gary
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

[site] Site plugin 4.0.0-M3 does not run templates?

[Gary Gregory]

Hi All:

In order to not run into Apache RAT plugin problems mentioned here before
[1], I run the latest Maven site plugin. While this solves the issue, this
causes other problems like it apparently not running templates, I think.

To reproduce git clone https://gitbox.apache.org/repos/asf/commons-parent
Run 'mvn clean site' and open target/site/index.html
You will see a grey bar at the top with the string

$dateFormat.applyPattern( $format )$i18n.getString( "site-renderer",
$locale, "template.lastpublished" ): $dateValue|$i18n.getString(
"site-renderer", $locale, "template.version" ): 54-SNAPSHOT
I

Instead, this should be rendered obviously.

Any thoughts?
TY!
Gary

[1] https://issues.apache.org/jira/browse/RAT-300 and
https://issues.apache.org/jira/browse/RAT-309

Re: Eclipse support for Maven modules

[Gary Gregory]

Once the Eclipse m2e plugin imports a Maven project, it will create for you
a .project file, a .classpath file and possibly a .settings folder. Those
are your Eclipse artifacts.

Gary

On Mon, Dec 27, 2021 at 10:30 AM Ed Dowgiallo  wrote:

> Slawomir,
>
> Yes, all works fine at command line. All 31 modules work for mvn clean, and
> I currently get a package not found in module 25 which is my bug.
>
> It is not publicly accessible.
>
> Is this supposed to work strictly off the pom.xmls? Or are there eclipse
> configuration files involved?
>
> Ed
>
> On Mon, Dec 27, 2021 at 10:17 AM Slawomir Jaranowski <
> s.jaranow...@gmail.com>
> wrote:
>
> > Hi,
> >
> > Does your fresh project after git checkout build correctly with all
> modules
> > by standard Maven command, like
> > mvn clean verify
> > from command line?
> >
> > Is your project accessible publicly?
> >
> >
> > pon., 27 gru 2021 o 15:56 Ed Dowgiallo 
> napisał(a):
> >
> > > Hi,
> > >
> > > First time poster.
> > >
> > > I like the Maven approach to modules and am using it for my projects
> with
> > > the Eclipse IDE. Not quite getting something right though. After I have
> > > committed a project to git and do a fresh checkout of it on a different
> > > computer, it appears to forget all the module structure. The child
> > projects
> > > disappear and the main project changes the module source folders to
> > regular
> > > folders.
> > >
> > > Is there a configuration file other than pom.xml missing from my git
> > > commits?
> > >
> > > Is it possible for me to restore the lost module structure?
> > >
> > > Thank you,
> > > Ed
> > >
> >
> >
> > --
> > Sławomir Jaranowski
> >
>

Re: Wrong site skin in 3.8.2 vs 3.6.3

[Gary Gregory]

Thanks for the pointer, I'll watch the issue...

On Tue, Aug 24, 2021, 10:24 Slawomir Jaranowski 
wrote:

> Hi
>
> probably this is reason
>
> https://issues.apache.org/jira/browse/MNG-7215
>
> wt., 24 sie 2021, 15:54 użytkownik Gary Gregory 
> napisał:
>
> > When I build git master of Apache Commons DBCP, I get the old site skin
> > with 'mvn clean install site' using 3.8.2. All is well in 3.6.3.
> >
> > I did not take the time to dig in, running off to a meeting...
> >
> > Gary
> >
>

Wrong site skin in 3.8.2 vs 3.6.3

[Gary Gregory]

When I build git master of Apache Commons DBCP, I get the old site skin
with 'mvn clean install site' using 3.8.2. All is well in 3.6.3.

I did not take the time to dig in, running off to a meeting...

Gary

Re: Profile pitfall or user error?

[Gary Gregory]

I found a workaround by declaring the toolsJar property in the project
properties instead of the profile itself. I suppose I was looking for
"local" profile properties which obviously is not a thing in Maven ;-)

Gary

On Sun, Aug 1, 2021 at 1:35 PM Gary Gregory  wrote:

> Hi All:
>
> I want to use a property in a profile in a Java 8 Maven 3.8.1 project, but
> it does not work within a file activation element. In the example below
> this file activation works:
>
> ${java.home}/../lib/tools.jar
>
> but this one does not:
>
> ${toolsJar}
>
> The profile:
>
>   
> 
>   jdk9
>   
> [1.9,)
>   
>   
>   
> 
> 
>   default-jdk
>   
> ${java.home}/../lib/tools.jar
>   
>   
> 
>   
>   ${java.home}/../lib/tools.jar
> 
>   
>   
> 
>   jdk.tools
>   jdk.tools
>   system
>   8
>   ${toolsJar}
> 
>   
> 
>   
>
> Am I doing something wrong?
>
> Gary
>
>

Profile pitfall or user error?

[Gary Gregory]

Hi All:

I want to use a property in a profile in a Java 8 Maven 3.8.1 project, but
it does not work within a file activation element. In the example below
this file activation works:

${java.home}/../lib/tools.jar

but this one does not:

${toolsJar}

The profile:

  

  jdk9
  
[1.9,)
  
  
  


  default-jdk
  
${java.home}/../lib/tools.jar
  
  

  
  ${java.home}/../lib/tools.jar

  
  

  jdk.tools
  jdk.tools
  system
  8
  ${toolsJar}

  

  

Am I doing something wrong?

Gary

Re: Maven Plugins & Confusing Versioning

[Gary Gregory]

On Tue, Oct 6, 2020 at 7:46 AM Thomas Broyer  wrote:

> (sorry for the delay)
>
> On Sat, Oct 3, 2020 at 5:27 PM Karl Heinz Marbaise 
> wrote:
>
> > Hi,
> >
> > On 03.10.20 11:47, Thomas Broyer wrote:
> > > Wait, you mean that you don't even follow your own rules for versions
> ⁉️
> > > where milestones sit between beta and RC versions.
> >
> > Can you explain which rules you are referencing?
> >
>
> I meant those:
> https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning
>
> https://github.com/apache/maven/blob/maven-3.6.3/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java#L356
>
> https://github.com/apache/maven/blob/maven-3.6.3/maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java#L48
> and as shown by that command:
> $ java -jar /opt/maven/lib/maven-artifact-3.6.3.jar 3.0.0-beta1 3.0.0-M1
> 3.0.0-RC1 3.0.0
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 3.0.0-beta1 == 3-beta-1
>3.0.0-beta1 < 3.0.0-M1
> 2. 3.0.0-M1 == 3-milestone-1
>3.0.0-M1 < 3.0.0-RC1
> 3. 3.0.0-RC1 == 3-rc-1
>3.0.0-RC1 < 3.0.0
> 4. 3.0.0 == 3
>
> The part M... is from our perspective a milestone in direction to a
> > particular set of features that has nothing to do with not stable... for
>
> example see https://maven.apache.org/surefire/maven-failsafe-plugin/
>
>
>
> I'm for example using maven-release-plugin:3.0.0-M1 in production...
> > You can take a look into the CI results
> > (
> >
> https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-release/job/master/
> > )
> > or the tests which are running on them:
> >
> >
> https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-release/job/master/lastCompletedBuild/testReport/
> >
> >
> > The question based on that is comming up:
> >
> > What do you define as "unstable" ? All of those plugins are already
> > running very long (I mean very long) in production environments ... so
> > of course sometimes people find bugs ...
> >
> >
> > As Enrico alrady mentioned ...we don't release unstable plugins... (but
> > it drills down to the question: What is a unstable plugin?)
>
>
> The question to me is: should anyone use a milestone version? What are the
> "guarantees" compared to a "final" version?
> If you're saying that there's no reason not to use a milestone in
> production, that it's guaranteed to work just as well as a "final" version,
> then why isn't it labelled "final"?
> When I see a milestone version (or any "prerelease" version), I'm thinking
> "OK, they're still working on it (hey, it's not even a release candidate),
> let's use the latest "final" release" (in this case 2.5.3;
>
> https://search.maven.org/artifact/org.apache.maven.plugins/maven-release-plugin
> ).
> I also expect that if there are bugs in that latest "final" release that
> possibly there could be a "point release" fixing them (2.5.4) before the
> next major version is "stable" (3.0.0)
> So of course such a "prerelease" could be "stable enough" to be used in
> production, but who knows in which ways it could possibly break? or change
> in backwards-incompatible ways in a future 3.0.0-M2 or the final 3.0.0?
> Only people following the plugin's development closely can know.
>
> So, if the message you want to send is "use that 3.0.something version,
> it's absolutely OK for production use (and btw we'll fix 2.5.3 bugs in a
> 3.0.0-M2, not a 2.5.4)", then tag it as 3.0.0 (or 2.5.4 or 2.6.0), not
> 3.0.0-M1.
> If you want to make it clear that some feature is not "stable" yet (in its
> API/configuration, or possibly buggy), then you could add warnings in the
> docs and even issue a warning at runtime if it's being used (I know people
> don't pay attention to warnings, and I think mostly because Maven output is
> quite/too verbose, but still).
>

>From a user's POV, I agree that the messaging on "M" releases is unclear.
To me a milestone release is not stable, it's just a different way of
saying "alpha" or "beta".

Gary

>
> --
> Thomas Broyer
> /tɔ.ma.bʁwa.je/  <
> http://xn--nna.ma.xn--bwa-xxb.je/>
>

Re: 'mvn clean test' crashes

[Gary Gregory]

I've tried to deal with JVM crashes in the FailSafe (I was not having the
problem in SureFire) plugin by using:

  
org.apache.maven.plugins
maven-failsafe-plugin
${hmp.failsafe.version}

  1
  false

  

and then defining the plugin version in a property "hmp.failsafe.version"
which I can vary on the command line until I find one that works.

Gary

On Tue, Jul 7, 2020 at 6:38 AM Mukul Gandhi  wrote:

> Hi Gary,
>
> On Sun, Jul 5, 2020 at 6:52 PM Gary Gregory 
> wrote:
>
> You could try to set the fork count to 1.
> >
>
> As per Maven documentation, 'The default setting is
> forkCount=1/reuseForks=true'. Even when I explicitly specify these values
> within my Maven project's pom, I get the same build error that I mentioned
> originally within this thread. forkCount=1/reuseForks=false also doesn't
> work for me and fails my build with same sorts of error.
>
> I also don't wish to specify value of forkCount greater than 1, since I
> don't want my Maven project tests to run parallely. Because, most of my
> tests interact transactionally with a DB, and I believe parallel test
> execution would be problematic for my case.
>
> Any further thoughts would be useful to me.
>
>
>
>
> --
> Regards,
> Mukul Gandhi
>

Re: 'mvn clean test' crashes

[Gary Gregory]

You could try to set the fork count to 1.

Gary

On Thu, Jul 2, 2020, 02:51 Mukul Gandhi  wrote:

> Hi Gary,
>
> On Wed, Jul 1, 2020 at 4:26 PM Gary Gregory 
> wrote:
>
> > Have you tried the more recent version of the Maven surefire plugin?
> >
>
> I'm using Maven 3.6.3.
>
> I changed to the latest stable version of Maven surefire plugin (3.0.0-M5),
> and its producing the same build error. I was using Maven surefire plugin
> version 2.22.2 earlier.
>
> I've also debugged along the lines of latest comment by Bernd, with regards
> to available RAM on my Windows dev workstation. I've total RAM of 8 GB.
> Originally, I was working with default settings for -Xmx on MAVEN_OPTS
> environment variable (which I guess has value 512 MB). I changed that to 3
> GB, and my workstation's total RAM usage is well below 100% (it hovers
> around 70%) during my entire run of command 'mvn clean test', and I get
> same test case crash.
>
> I've also found related information at,
>
> https://maven.apache.org/surefire/maven-surefire-plugin/examples/shutdown.html
> .
> At the bottom of this link, following is mentioned,
> 
> Crashed forked JVM caused listing the crashed test(s)
>
> After the JVM exited abruptly, the console lists the message Crashed tests:
> with a list of crashed tests if the entire test-set has not been yet
> completed. This happens if a test exited, killed JVM or a segmentation
> fault crashed JVM. In such cases you may be interested in dump files
> generated in reports directory, see FAQ.
> 
>
> When I read the FAQ (the last word within above 'quote'), and according to
> that information, I see following hint in the
> file 2020-07-02T11-58-54_573.dumpstream (there are no other dump files
> created during my run of 'mvn clean test'),
> *Boot Manifest-JAR contains absolute paths in classpath
>
> 'F:\eclipseWorkspaces\haldiram_backend_sprint-19_sts\haldiram-backend\haldiram-restapis\target\test-classes'*
> *Hint:
> -Djdk.net.URLClassPath.disableClassPathURLCheck=true*
>
> According to above referred hint, I then ran the following command,
> mvn clean test -Djdk.net.URLClassPath.disableClassPathURLCheck=true
>
> But this produced the same error (although, this time the mvn test process
> crashed on a different test file than what I experienced originally).
>
> Any thoughts, what I could do next on my Windows dev workstation to solve
> the problem I've mentioned in this thread?
>
>
>
> --
> Regards,
> Mukul Gandhi
>

Re: 'mvn clean test' crashes

[Gary Gregory]

Have you tried the more recent version of the Maven surefire plugin?

Gary

On Wed, Jul 1, 2020, 05:06 Bernd Eckenfels  wrote:

> Has the machine enough ram free? Did you try a reboot (sometimes windows
> memory map seems to be fragmented in a way that java can't start). Does
> your Pom overwrite command line and/or specify a very big or very small
> heap? Any crash dumps or hs_err files?
>
> Gruss
> Bernd
>
>
> --
> http://bernd.eckenfels.net
> 
> Von: Mukul Gandhi 
> Gesendet: Wednesday, July 1, 2020 10:47:45 AM
> An: Maven Users List 
> Betreff: Re: 'mvn clean test' crashes
>
> Hi Enrico,
>
> On Wed, Jul 1, 2020 at 1:13 PM Enrico Olivelli 
> wrote:
>
> > I suggest you to debug that test, with an IDE or just by adding some
> > System.out.println
> >
>
> When I run only the tests present in offending java class
> (com.haldiram.business.helper.test.ApplnHelperTest), from within the IDE,
> all the tests in the class pass.
>
> But, when I run all the tests present within my aggregated Maven project
> (multi module Maven project), using the command 'mvn clean test', the Maven
> build failure says following,
>
> [ERROR] Crashed tests:
> [ERROR] com.haldiram.business.helper.test.ApplnHelperTest
> [ERROR] at
>
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:669)
> [ERROR] at
>
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
> [ERROR] at
>
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> ...
>
> All of the above, were done on a Windows workstation.
>
> Also, when a Jenkins build pipeline invokes the command 'mvn clean test' on
> a Linux system for all of my same codebase, all the tests pass and Maven
> build succeeds there.
>
> I've a strong feeling that, all my unit tests have no issues from the tests
> code perspective. I feel, there could be some other issue, that I'm unable
> to solve at this moment. Any further pointers to solve the issues I've
> mentioned in this thread would be welcome.
>
>
>
>
> --
> Regards,
> Mukul Gandhi
>

Re: Doxia XHTML MathML support?

[Gary Gregory]

Ok, let's leave as is for now.

Gary

On Sun, Jan 26, 2020, 11:58 Claude Warren  wrote:

> Since it is on cloudeflare I think we are safe to reference it in place.
> However we might want to put it in the site.xml file so that there is a
> common version used across the site.  On the other hand, nobody but the
> Bloom filter documentation is using the math formatting.
>
> Claude
>
> On Sun, Jan 26, 2020 at 1:20 PM Gary Gregory 
> wrote:
>
> > Would we improve our site's reliability by copying this file? It is ASL
> 2.0
> > it seems.
> >
> > Gary
> >
> > On Sun, Jan 26, 2020, 07:14 Claude Warren  wrote:
> >
> > > Just to close this question.  I found that commons-math uses the
> mathjax
> > > javascript library[1] that produces equations from LaTEX mathematical
> > > equation format[2].   The mathjax library can be included in site xdoc
> > > files by including:
> > > {noformat}
> > > 
> > > 

Re: Doxia XHTML MathML support?

[Gary Gregory]

Would we improve our site's reliability by copying this file? It is ASL 2.0
it seems.

Gary

On Sun, Jan 26, 2020, 07:14 Claude Warren  wrote:

> Just to close this question.  I found that commons-math uses the mathjax
> javascript library[1] that produces equations from LaTEX mathematical
> equation format[2].   The mathjax library can be included in site xdoc
> files by including:
> {noformat}
> 
> 

Re: Doxia XHTML MathML support?

[Gary Gregory]

Maybe look at Commons Math?

Gary

On Sat, Jan 25, 2020, 13:42 Claude Warren  wrote:

> I am attempting to use  XHTML generator as part of the commons-collections
> site generation.  The document I have requires MathML which is part of
> HTML5 now.  But the XHTML and XHTML5 generators emit a warning for each of
> the MathML tags that reads "[XHTML Sink] No HTML tag found for unknown
> event: 'math', ignoring!" or similar for other MathML tags.  Is there a way
> to emit the MathML tags using the xdoc input format?
>
> I have a work around using the snippet macro but would like a cleaner
> solution.
>
> Claude
>
> --
> I like: Like Like - The likeliest place on the web
> 
> LinkedIn: http://www.linkedin.com/in/claudewarren
>

Re: Javadoc and -Xdoclint/package:([-]) packages

[Gary Gregory]

I got it to work with a low-level option:

cls & mvn javadoc:javadoc
-DadditionalJOption=-Xdoclint/package:-org.apache.commons.configuration2.plist

Will  doclint/package be made available as a standard configuration option?

Gary

On Thu, Sep 12, 2019 at 9:38 AM Gary Gregory  wrote:

> Hi All:
>
> This does not seem to work with Apache Commons Configuration, Maven 3.6.2,
> and the Maven Javadoc Plugin 3.1.1.:
>
> mvn javadoc:javadoc
> -Ddoclint/package:-org.apache.commons.configuration2.plist.*
>
> See https://docs.oracle.com/en/java/javase/11/tools/javadoc.html
>
> Am I doing something wrong?
>
> Gary
>
>
>

Javadoc and -Xdoclint/package:([-]) packages

[Gary Gregory]

Hi All:

This does not seem to work with Apache Commons Configuration, Maven 3.6.2,
and the Maven Javadoc Plugin 3.1.1.:

mvn javadoc:javadoc
-Ddoclint/package:-org.apache.commons.configuration2.plist.*

See https://docs.oracle.com/en/java/javase/11/tools/javadoc.html

Am I doing something wrong?

Gary

Changes plugin for JIRA AND GitHub

[Gary Gregory]

Hi All:

Is there a way to craft a changes.xml file so that the plugin generates
links to both JIRA _and_ GitHub PRs?

Gary

Re: [SUREFIRE] Is net.jcip.annotations.NotThreadSafe detected in superclasses?

[Gary Gregory]

Forgot to say:

5.2.0
...

  org.junit.vintage
  junit-vintage-engine
  ${junit5.version}
  test


  org.junit.jupiter
  junit-jupiter-api
  ${junit5.version}
  test


  com.github.stephenc.jcip
  jcip-annotations
  1.0-1
  test


But my tests only use JUnit 4.

Gary

On Mon, Aug 6, 2018 at 3:57 PM Gary Gregory  wrote:

> Hi All:
>
> If I annotate a class S with net.jcip.annotations.NotThreadSafe which has
> @Test methods, and then declare a bunch of subclasses of S which also
> contain @Test methods.
>
> When I run tests for all subclasses of S, will the Maven Surefire plugin:
> - Run all @Test methods from S in a single thread?
> - Run all @Test methods from subclasses of S in a single thread?
>
> Thank you,
> Gary
>

[SUREFIRE] Is net.jcip.annotations.NotThreadSafe detected in superclasses?

[Gary Gregory]

Hi All:

If I annotate a class S with net.jcip.annotations.NotThreadSafe which has
@Test methods, and then declare a bunch of subclasses of S which also
contain @Test methods.

When I run tests for all subclasses of S, will the Maven Surefire plugin:
- Run all @Test methods from S in a single thread?
- Run all @Test methods from subclasses of S in a single thread?

Thank you,
Gary

Make Maven always print its banner

[Gary Gregory]

Hi All:

I can say 'mvn -V ,,,' but how can I always make it prints its banner? I
can't get MAVEN_OPTS to do that.

Thank you,
Gary

Re: [maven-scm-api] Looking to perform svn remote move

[Gary Gregory]

On Fri, May 18, 2018 at 8:00 PM, Hervé BOUTEMY 
wrote:

> Le vendredi 18 mai 2018, 22:36:20 CEST Rob Tompkins a écrit :
> > > On May 18, 2018, at 3:30 PM, Michael Osipov 
> wrote:
> > >
> > > Am 2018-05-17 um 15:12 schrieb Rob Tompkins:
> > > > Hello maven guys,
> > > >
> > > > Over on commons we’ve been writing our own release-plugin
> > >
> > > What is wrong with the current Maven Release Plugin and why are you
> > > writing your own whereas we could improve the current one, can't we?
> > We are trying to fit the Apache release paradigm where we are dealing
> with
> > assemblies that we don’t want to deliver to Nexus. Further we are
> > publishing the site up to our dev dist area for comparison with RC
> > validation. We could contribute it back to the release plugin, but I’m
> not
> > sure if it’s sufficiently general. Thoughts?
>
> IIUC, the "release plugin" from Commons provides 3 mojos to prepare 3
> assemblies: it does not replace "release plugin" from Maven, which
> modifies
> pom.xml to switch from -SNAPSHOT to release version then to next SNAPSHOT
>
> How is Commons release plugin used during a Commons release vs Maven
> release
> plugin?


Please see "Create the Release Candidate with the Commons Release Plugin."
here: https://commons.apache.org/releases/prepare.html

Before our plugin, you had to follow "Create the Release Candidate
Manually" (same page).

I'm not sure what is done under the covers WRT the Maven release plugin.

Do Commons use "mvn release:prepare" then "mvn release:perform", and
> the build in the release profile runs the 3 mojos to get the 3 assemblies?
>
> Because what I see in this Commons release plugin look like custom steps
> to
> add to Maven release plugin, in addition to currently provided ones: as
> Robert
> wrote, there is a WIP in Maven release plugin to document how to add new
> steps. The Maven release plugin is already organized in steps, to be
> flexible,
> but just has not documented how to add new steps.
>

It would be great to iterate with the Maven team so that we can make
releasing Commons component easier. It's a giant pain ATM IMO. Creating a
release candidate [1] is "easy" compared to what has to happens after a
successful VOTE [2]. It should be easier instead of 50 steps.

Gary

[1] https://commons.apache.org/releases/prepare.html
[2] http://commons.apache.org/releases/release.html


>
> Regards,
>
> Hervé
>
> >
> > -Rob
> >
> > > Michael
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: [maven-scm-api] Looking to perform svn remote move

[Gary Gregory]

On Fri, May 18, 2018 at 2:36 PM, Rob Tompkins  wrote:

>
>
> > On May 18, 2018, at 3:30 PM, Michael Osipov  wrote:
> >
> > Am 2018-05-17 um 15:12 schrieb Rob Tompkins:
> > > Hello maven guys,
> > >
> > > Over on commons we’ve been writing our own release-plugin
> >
> > What is wrong with the current Maven Release Plugin and why are you
> writing your own whereas we could improve the current one, can't we?
> >
>
> We are trying to fit the Apache release paradigm where we are dealing with
> assemblies that we don’t want to deliver to Nexus. Further we are
> publishing the site up to our dev dist area for comparison with RC
> validation. We could contribute it back to the release plugin, but I’m not
> sure if it’s sufficiently general. Thoughts?
>

We are also committing the RC files and site to the SVN dist repo.

Gary


> -Rob
>
> > Michael
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: [maven-scm-api] Looking to perform svn remote move

[Gary Gregory]

On Fri, May 18, 2018 at 1:30 PM, Michael Osipov  wrote:

> Am 2018-05-17 um 15:12 schrieb Rob Tompkins:
> > Hello maven guys,
> >
> > Over on commons we’ve been writing our own release-plugin
>
> What is wrong with the current Maven Release Plugin and why are you
> writing your own whereas we could improve the current one, can't we?
>

FTR: https://commons.apache.org/proper/commons-release-plugin/index.html

Gary


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

Re: [ANN] Apache Maven Doxia Sitetools 1.7.5 Released

[Gary Gregory]

OK, cool. That's what I am waiting on to release a new version of
commons-parent and httpcomponents-parent: Building on Java 9 without
blowing up.

Gary

On Sun, Oct 8, 2017 at 10:08 AM, Robert Scholte <rfscho...@apache.org>
wrote:

> Indeed, that would be the next step.
>
> Robert
>
> On Sun, 08 Oct 2017 18:07:10 +0200, Gary Gregory <garydgreg...@gmail.com>
> wrote:
>
> Can we expect a site plugin update that uses this latest version soon?
>>
>> Gary
>>
>> On Oct 8, 2017 09:54, "Robert Scholte" <rfscho...@apache.org> wrote:
>>
>> The Apache Maven team is pleased to announce the release of the Apache
>>> Maven Doxia Sitetools, version 1.7.5
>>>
>>> Doxia Sitetools is an extension of base Doxia component that generates
>>> either HTML sites, consisting of decoration and content that was
>>> generated
>>> by Doxia, or documents like RTF or PDF.
>>>
>>> In addition, Doxia Sitetools processes files with extra .vm extension
>>> with
>>> Velocity.
>>>
>>> https://maven.apache.org/doxia/doxia-sitetools/index.html
>>>
>>> You can download the appropriate sources etc. from the download page:
>>>
>>> https://maven.apache.org/doxia/doxia-sitetools/download.cgi
>>>
>>>
>>> Release Notes - Maven Doxia Sitetools - Version 1.7.5
>>>
>>> ** Bug
>>> * [DOXIASITETOOLS-172] - Width, height and border values not used for
>>> banner display
>>> * [DOXIASITETOOLS-173] - Default skin CSS maven-base.css sets
>>> border:none on all images with tag img
>>> * [DOXIASITETOOLS-175] - change Velocity engine links
>>> * [DOXIASITETOOLS-177] - Use of commons-lang 2 causes failure with
>>> JDK
>>> 9 b175+
>>>
>>> ** Improvement
>>> * [DOXIASITETOOLS-178] - Upgrade to Commons Lang 3
>>>
>>>
>>>
>>> Enjoy,
>>>
>>> -The Apache Maven team
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>

Re: [ANN] Apache Maven Doxia Sitetools 1.7.5 Released

[Gary Gregory]

Can we expect a site plugin update that uses this latest version soon?

Gary

On Oct 8, 2017 09:54, "Robert Scholte"  wrote:

> The Apache Maven team is pleased to announce the release of the Apache
> Maven Doxia Sitetools, version 1.7.5
>
> Doxia Sitetools is an extension of base Doxia component that generates
> either HTML sites, consisting of decoration and content that was generated
> by Doxia, or documents like RTF or PDF.
>
> In addition, Doxia Sitetools processes files with extra .vm extension with
> Velocity.
>
> https://maven.apache.org/doxia/doxia-sitetools/index.html
>
> You can download the appropriate sources etc. from the download page:
>
> https://maven.apache.org/doxia/doxia-sitetools/download.cgi
>
>
> Release Notes - Maven Doxia Sitetools - Version 1.7.5
>
> ** Bug
> * [DOXIASITETOOLS-172] - Width, height and border values not used for
> banner display
> * [DOXIASITETOOLS-173] - Default skin CSS maven-base.css sets
> border:none on all images with tag img
> * [DOXIASITETOOLS-175] - change Velocity engine links
> * [DOXIASITETOOLS-177] - Use of commons-lang 2 causes failure with JDK
> 9 b175+
>
> ** Improvement
> * [DOXIASITETOOLS-178] - Upgrade to Commons Lang 3
>
>
>
> Enjoy,
>
> -The Apache Maven team
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: maven-javadoc-plugin, Java 9 and maven-javadoc-plugin and java 9 and ExceptionInInitializerError

[Gary Gregory]

Thank you, updating to 3.0.0-M1 from the stagging repo fixed the Java 9
build issue!

Garfy

On Mon, Jul 17, 2017 at 1:07 PM, Robert Scholte <rfscho...@apache.org>
wrote:

> Yes, we are aware of this issue.
> I've just started a vote[1]. All feedback is appreciated!
>
> thanks,
> Robert
>
> [1] http://markmail.org/message/4nssutboqsahx5kb
>
>
> On Mon, 17 Jul 2017 18:12:22 +0200, Gary Gregory <garydgreg...@gmail.com>
> wrote:
>
> When I try to build our Apache HttpComponent HttpClient from git master
>> with Java 9 build 178 I get the maven-javadoc-plugin and java 9 and
>> ExceptionInInitializerError below. This is thanks to a bug in our old
>> Apache Commons Lang 2.x branch? Is there a plan to
>> update maven-javadoc-plugin with the current version of Apache Commons
>> Lang
>> 3 which addresses this issue?
>>
>> Thank you,
>> Gary
>>
>> [INFO] --- maven-javadoc-plugin:2.10.4:jar (attach-javadocs) @
>> httpclient5-parent ---
>> [WARNING] Error injecting: org.apache.maven.plugin.javadoc.JavadocJar
>> java.lang.ExceptionInInitializerError
>> at
>> org.apache.maven.plugin.javadoc.AbstractJavadocMojo.
>> (AbstractJavadocMojo.java:195)
>> at
>> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl
>> .newInstance0(Native
>> Method)
>> at
>> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl
>> .newInstance(NativeConstructorAccessorImpl.java:62)
>> at
>> java.base/jdk.internal.reflect.DelegatingConstructorAccessor
>> Impl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>> at
>> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:488)
>> at
>> com.google.inject.internal.DefaultConstructionProxyFactory$
>> 1.newInstance(DefaultConstructionProxyFactory.java:86)
>> at
>> com.google.inject.internal.ConstructorInjector.provision(Con
>> structorInjector.java:105)
>> at
>> com.google.inject.internal.ConstructorInjector.access$000(
>> ConstructorInjector.java:32)
>> at
>> com.google.inject.internal.ConstructorInjector$1.call(Constr
>> uctorInjector.java:89)
>> at
>> com.google.inject.internal.ProvisionListenerStackCallback$
>> Provision.provision(ProvisionListenerStackCallback.java:115)
>> at
>> com.google.inject.internal.ProvisionListenerStackCallback$
>> Provision.provision(ProvisionListenerStackCallback.java:133)
>> at
>> com.google.inject.internal.ProvisionListenerStackCallback.
>> provision(ProvisionListenerStackCallback.java:68)
>> at
>> com.google.inject.internal.ConstructorInjector.construct(Con
>> structorInjector.java:87)
>> at
>> com.google.inject.internal.ConstructorBindingImpl$Factory.
>> get(ConstructorBindingImpl.java:267)
>> at
>> com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
>> at
>> com.google.inject.internal.InjectorImpl.callInContext(Inject
>> orImpl.java:1103)
>> at
>> com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
>> at
>> com.google.inject.internal.InjectorImpl.getInstance(Injector
>> Impl.java:1051)
>> at
>> org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDef
>> erredClass.java:48)
>> at
>> com.google.inject.internal.ProviderInternalFactory.provision
>> (ProviderInternalFactory.java:81)
>> at
>> com.google.inject.internal.InternalFactoryToInitializableAda
>> pter.provision(InternalFactoryToInitializableAdapter.java:53)
>> at
>> com.google.inject.internal.ProviderInternalFactory$1.call(
>> ProviderInternalFactory.java:65)
>> at
>> com.google.inject.internal.ProvisionListenerStackCallback$
>> Provision.provision(ProvisionListenerStackCallback.java:115)
>> at
>> com.google.inject.internal.ProvisionListenerStackCallback$
>> Provision.provision(ProvisionListenerStackCallback.java:133)
>> at
>> com.google.inject.internal.ProvisionListenerStackCallback.
>> provision(ProvisionListenerStackCallback.java:68)
>> at
>> com.google.inject.internal.ProviderInternalFactory.circularG
>> et(ProviderInternalFactory.java:63)
>> at
>> com.google.inject.internal.InternalFactoryToInitializableAda
>> pter.get(InternalFactoryToInitializableAdapter.java:45)
>> at
>> com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
>>   

maven-javadoc-plugin, Java 9 and maven-javadoc-plugin and java 9 and ExceptionInInitializerError

[Gary Gregory]

When I try to build our Apache HttpComponent HttpClient from git master
with Java 9 build 178 I get the maven-javadoc-plugin and java 9 and
ExceptionInInitializerError below. This is thanks to a bug in our old
Apache Commons Lang 2.x branch? Is there a plan to
update maven-javadoc-plugin with the current version of Apache Commons Lang
3 which addresses this issue?

Thank you,
Gary

[INFO] --- maven-javadoc-plugin:2.10.4:jar (attach-javadocs) @
httpclient5-parent ---
[WARNING] Error injecting: org.apache.maven.plugin.javadoc.JavadocJar
java.lang.ExceptionInInitializerError
at
org.apache.maven.plugin.javadoc.AbstractJavadocMojo.(AbstractJavadocMojo.java:195)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:488)
at
com.google.inject.internal.DefaultConstructionProxyFactory$1.newInstance(DefaultConstructionProxyFactory.java:86)
at
com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:105)
at
com.google.inject.internal.ConstructorInjector.access$000(ConstructorInjector.java:32)
at
com.google.inject.internal.ConstructorInjector$1.call(ConstructorInjector.java:89)
at
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
at
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:133)
at
com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
at
com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:87)
at
com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:267)
at
com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)
at
com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
at
com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1051)
at
org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
at
com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:81)
at
com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:53)
at
com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:65)
at
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
at
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:133)
at
com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
at
com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:63)
at
com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45)
at
com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1092)
at
com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
at org.eclipse.sisu.inject.Guice4$1.get(Guice4.java:162)
at
org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:81)
at
org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:263)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:255)
at
org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:519)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:121)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
at

Re: problem when deploying to nexus with a password with accent

[Gary Gregory]

Make sure the XML is saved in the encoding that matches the XML processing
instruction, usually UTF-8.

Gary

On Jun 16, 2017 7:57 AM, "djeanprost" 
wrote:

> Hello,
>
> I'm meeting a problem I can't deal with, and I hope someone here will help
> me find a solution.
>
> I want to deploy an artifact to my running nexus 2.14.x. I can log in nexus
> using my login/password. My password contains a french accent 'é'.
>
> When I fill my settings.xml with my clear password and its accent, I keep
> on
> receiving error 401 unauthorized from nexus when deploying.
> If I change my password in my ldap server, by removing the accent, and
> updating settings.xml, I can deploy my artifact. I udenrstand there is no
> problem with any nexus role.
> So now there is something wrong with my settings. Why is there a problem
> with a password containing an accent ?
>
> Thank you for your help.
> dom
>
>
>
> --
> View this message in context: http://maven.40175.n5.nabble.
> com/problem-when-deploying-to-nexus-with-a-password-with-
> accent-tp5910070.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Running integration tests against a signed jar

[Gary Gregory]

Hm, so I have two choices:

- Change the POM so that the failsafe plugin runs in the test phase, which
happens before the jar signing (that works BTW).
- Change the code to repackage the IT tests and make public all that the IT
tests need (I've not done that but I'll see what breaks)

Thank you all,
Gary


On Tue, May 30, 2017 at 12:15 PM, Bernd Eckenfels <e...@zusammenkunft.net>
wrote:

> I think the maven way is not much concerned with package structure,
> however why not have a IT package? Do you have much need for package access
> in your ITs?
>
> For Unit tests sharing the packages can be helpful, but for IT I would
> expect it does not only need to be collocated, but it actually is better to
> have the public view. (Some hooks might be required to open up state for
> initilisation and verification, not sure. In the cases I have seen public
> interface (or access to external systems like file or database) was enough.
>
> Are those webstart client chars or do you use signed protection domains on
> the server or is this only signing for protecting the archives?
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> From: Martin Gainty <mgai...@hotmail.com>
> Sent: Tuesday, May 30, 2017 7:08:43 PM
> To: Maven Users List
> Subject: Re: Running integration tests against a signed jar
>
>
>
> 
> From: Gary Gregory <garydgreg...@gmail.com>
> Sent: Monday, May 29, 2017 5:01 PM
> To: Maven Users List
> Subject: Running integration tests against a signed jar
>
> Hi All:
>
> I have a POM that builds a signed jar, so far so good. Unit tests run, no
> problem.
>
> When integration tests run through fail-safe, the build fails all ITs with:
>
> java.lang.ExceptionInInitializerError
> Caused by: java.lang.SecurityException: class "com.example.MyClass"'s
> signer information does not match signer information of other classes in
> the same package
>
> MG>you are running a jar with a bad signature
> MG>you are running a jar with no signature
> MG>to confirm
> MG>for every jar in your runtime classpath
> MG>BEGIN:
> MG>for each jar expand next runtime jar
> MG>edit /META-INF/MANIFEST.MF of current jar
> MG>the signature would look something like
> MG>net/sf/jasperreports/engine/util/xml/JaxenXPathExecuterFactory.class
> SHA-256-Digest: q3B5wW+hLX/+lP2+L0/6wRVXRHq1mISBo1dkixT6Vxc=
> MG>save the first signature to outside file buffer
> MG>compare  entryFromMANIFEST.MF to first-signature
> MG>if not equal or non-existent resign current jar with algorithm from
> first signed jar
> MG>goto BEGIN
>
> As I understand it, failsafe runs the classes in test-classes against the
> built JAR, and since my ITs are in the same package as the code tested, I
> get the signing error above.
>
> What is the Maven-way to get this to work?
>
> Thank you,
> Gary
>
> --
> Java Persistence with Hibernate, Second Edition
> <https://www.amazon.com/gp/product/1617290459/ref=as_li_
> tl?ie=UTF8=1789=9325=1617290459&
> linkCode=as2=garygregory-20=cadb800f39946ec62ea2b1af9fe6a2b8>
>
> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=
> 1617290459>
> JUnit in Action, Second Edition
> <https://www.amazon.com/gp/product/1935182021/ref=as_li_
> tl?ie=UTF8=1789=9325=1935182021&
> linkCode=as2=garygregory-20=31ecd1f6b6d1eaf8886ac902a24de418%22
> >
> JUnit in Action, Second Edition: Petar Tahchiev, Felipe Leme, Vincent
> Massol, Gary Gregory: 9781935182023: Amazon.com: Books<
> https://www.amazon.com/gp/product/1935182021/ref=as_
> li_tl?ie=UTF8=1789=9325=
> 1935182021=as2=garygregory-20=
> 31ecd1f6b6d1eaf8886ac902a24de418%22>
> www.amazon.com<http://www.amazon.com>
> JUnit in Action, Second Edition [Petar Tahchiev, Felipe Leme, Vincent
> Massol, Gary Gregory] on Amazon.com. *FREE* shipping on qualifying offers.
> When JUnit was first introduced a decade ago by Kent Beck and Erich Gamma,
> the Agile movement was in its infancy
>
>
>
>
> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=
> 1935182021>
> Spring Batch in Action
> <https://www.amazon.com/gp/product/1935182951/ref=as_li_
> tl?ie=UTF8=1789=9325=1935182951&
> linkCode=%7B%7BlinkCode%7D%7D=garygregory-20=%7B%
> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> Spring Batch in Action: Arnaud Cogoluegnes, Thierry Templier, Gary
> Gregory, Olivier Bazoud: 9781935182955: Amazon.com: Books<
> https://www.amazon.com/gp/product/1935182951/ref=as_
> li_tl?ie=UTF8=1789=9325=
> 1935182951=%7B%7BlinkCode%7D%7D=garygregory-20=%7B%
> 7Blink_id%7D%7D%22%3ESpring+Batch+in

Running integration tests against a signed jar

[Gary Gregory]

Hi All:

I have a POM that builds a signed jar, so far so good. Unit tests run, no
problem.

When integration tests run through fail-safe, the build fails all ITs with:

java.lang.ExceptionInInitializerError
Caused by: java.lang.SecurityException: class "com.example.MyClass"'s
signer information does not match signer information of other classes in
the same package

As I understand it, failsafe runs the classes in test-classes against the
built JAR, and since my ITs are in the same package as the code tested, I
get the signing error above.

What is the Maven-way to get this to work?

Thank you,
Gary

-- 
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com

Re: Maven 3.4.0 dropped

[Gary Gregory]

Note that by going from 3.3.9 to 3.5.0, this will add to the confusion from
the user's POV.

Gary

On Mon, Jan 9, 2017 at 1:45 AM, Stephen Connolly 
wrote:

> After some discussion and debate, the Maven developers have agreed [1] to
> replan the next release of Maven.
>
> The original plans for Maven 3.4.0 were that it should consist of
> effectively a no-op drop in replacement of Eclipse's Aether project (which
> has been retired at the Eclipse Foundation) for the migrated code now known
> as Apache's Maven Resolver. Additionally the plans called for some other
> orthogonal changes around logging colourization and some launcher script
> bug fixes.
>
> Due to some misunderstanding, there were quite a number of other changes
> introduced which could be seen as modifying how dependencies and classpaths
> get built. While we want to get these changes released as bug fixes, it is
> also important to us to provide a clear progression of development. Some of
> the bugs we want to fix require changes to the resolver code and the
> developers feel it is important to mark the baseline of the migrated code
> such that it should be a drop-in replacement for 3.3.9.
>
> In that regard we have reset the master branches of the following GIT
> repositories to the point in time that corresponds to the 3.3.9 release:
>
> * git://git.apache.org/maven.git was reset to
> bce33aa2662a51d18cb00347cf2fb174dc195fb1
>
> * git://git.apache.org/maven-integration-testing.git was reset to
> f31241ad6cb6474e559289f1bd7110ea5d5a4fba
>
> * git://git.apache.org/maven-resolver.git was reset to
> b74f7a1e8837875b4780199f644119f55d22465d
>
> If you have clones of any of these repositories you will need to update
> them as the master branch has been force-pushed.
>
> As there have already been issues closed as fixed in 3.4.0 and a number of
> 3.4.0-SNAPSHOT releases were distributed for user feedback, it has been
> decided to burn the 3.4.0 version number as a signal of the reset. The next
> release of Maven will thus be 3.5.0
>
> We have a (mostly) agreed plan for the content of the 3.5.0 release [2]
> (there are still some issues being decided on)
>
> As all the content of 3.5.0 has already been developed on the old master
> branches (which have been retained as the pre-reset-master branches) it
> should be relatively easy to pull each of the agreed changes and merge
> them. For this reason we hope to be able to cut a release candidate of
> 3.5.0 relatively quickly.
>
> The next step will be agreeing the content of next release (which we hope
> to have follow 3.5.0 after 6-8 weeks and will either be called 3.5.1 or
> 3.6.0 depending on the agreed content).
>
> The drive is to get almost all the content that was in the pre-reset-master
> released, but in a version history that makes it easier for users to
> understand the impact and makes it easier for developers to identify the
> potential impact of the changes.
>
> - Stephen
>
> (On behalf of the Apache Maven Project)
>
> [1]:
> https://mail-archives.apache.org/mod_mbox/maven-dev/201701.
> mbox/%3CCA%2BnPnMx-e7kGYy3Hp87v8hLGdhp1q%3DtKLx_
> 6QuZ4kGUqHEBGcw%40mail.gmail.com%3E
>
> [2]: https://cwiki.apache.org/confluence/display/MAVEN/Roadmap+2017
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 2)

[Gary Gregory]

I've built Log4j 2 and some HttpComponents pieces OK. The only problem is
building on top of Java 8 which encounters the BCEL on Java bug problem we
all know about.

Gary

On Sun, Jun 12, 2016 at 1:40 PM, Karl Heinz Marbaise 
wrote:

> Hi to all Maven users,
>
> based on the issues which have been found with the first one here is
> another chance to help .
>
> It would be nice if those who have found issues to retest their scenarios.
>
> Is someone of you willing to do some testing on the current state of
> development for the upcoming Maven 3.4.0 release?
>
> Please be aware of this *** This is not an official release ***
>
> I have created downloadable packages which are available from here:
>
> Windows: https://s.apache.org/bnAi,
> Linux: https://s.apache.org/TrbK
>
>
> Every kind of feedback is helpful.
>
> This is only a current state of development (Git hash:
> 92334a1dd9f2f3df77b3c039be7742ea19a8ee81) to get some feedback from the
> community...
>
> The current list of changes can be seen in the issue tracker:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
>
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: variable doesn't work for version

[Gary Gregory]

On Tue, Mar 8, 2016 at 11:28 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> In the .mvn folder put an extension that contributes the ${rev} property
> based on whatever you seem safe
>

Where does this mystical .mvn folder reside, oh knowing one?

Is ${rev} a built in name?

Gary


>
> Then just have the project version include the ${rev} at the appropriate
> place
>
> On Tuesday 8 March 2016, Gary Gregory <garydgreg...@gmail.com> wrote:
>
> > On Mon, Mar 7, 2016 at 6:53 PM, Eric B <ebenza...@gmail.com
> <javascript:;>>
> > wrote:
> >
> > > The first question I have to ask is what you are trying to accomplish
> > with
> > > your continuous-delivery?
> >
> >
> > We have a Maven multi-module build which has thousands of unit tests. We
> > use Bamboo for CI and if we get a green build that means that all the
> tests
> > pass of course and that we successfully deployed the build to our repo
> (we
> > use Artifactory). We use the Maven's deploy to deploy, not the release
> > plugin.
> >
> > At this point anyone can use the built product out of Bamboo's saved
> > artifacts or Artifactory: our internal/external consultants, sales
> > engineers, formal QA, other downstream, products, and so on. It's up to
> the
> > PO to decide when to slap a new major or minor version label and he/she
> can
> > do at anytime.
> >
> > From development's POV, a green build is a released product, with a
> version
> > for example 3.1.201601070101 (3.1.MMDDHHMM). We used to have the SVN
> > version number as the maintenance version part but we are switching to
> Git
> > soon, hence the move to timestamps.
> >
> > Our parent POM contains what is considered a Maven "hack":
> >
> >   
> >
> > MMddHHmm
> > 3
> > 1
> > ${version.major}.${version.minor}
> > ${maven.build.timestamp}
> > ${version.main}.${revision}
> >
> > Each module then has:
> >
> > ${dv.version}
> >
> > What is the Maven way to achieve this goal?
> >
> > Gary
> >
> >
> >
> > > Are you trying to put snapshot versions into a
> > > production/release state?
> > >
> > > The biggest issue I have noticed with teams is the misunderstanding of
> > how
> > > SNAPSHOTs work, or their purpose in the development process.  Either
> > teams
> > > want to release applications in SNAPSHOT mode, or release code that is
> > > essentially in SNAPSHOT (ie: development) mode, but with fixed version
> > > numbers.  But instead of changing version numbers, they use something
> > like
> > > a timestamp to increment version numbers automatically.  But at the end
> > of
> > > it all, it kind of contravenes maven's versioning concept.
> > >
> > > Normally, if your artifact is a work in progress, you should just be
> > using
> > > a SNAPSHOT.  If you are looking to make a real release, then you should
> > be
> > > promoting your code from a SNAPSHOT to a fixed version.  Generally, the
> > > concept of continuous-delivery should only apply when in a SNAPSHOT
> mode,
> > > since anything else isn't changing (ie: a fixed release doesn't need to
> > be
> > > re-delivered).
> > >
> > > So then that begs the question why you need to constantly change your
> > > version numbers during your development phase?
> > >
> > > And if the goal is truly to have fixed versions for some other team to
> > have
> > > access to a "stable" version of your artifact (ie: they can be
> guaranteed
> > > that it isn't going to change as you continue to develop), you could
> > always
> > > use something like the maven-release-plugin to promote from SNAPSHOT
> to a
> > > fixed version, and then re-open the next version as a SNAPSHOT.
> > (Although
> > > I know there are many dissenters against the release-plugin).
> > >
> > > Thanks,
> > >
> > > Eric
> > >
> > >
> > >
> > > On Mon, Mar 7, 2016 at 7:15 PM, Gary Gregory <garydgreg...@gmail.com
> > <javascript:;>>
> > > wrote:
> > >
> > > > Is there a Maven-way to do continuous delivery then? As opposed
> > > > to continuous integration.
> > > >
> > > > Our current hack is to use the date as the maintenance version as a
> > > > variable for example 3.1.20160102
> > > >
> > > 

Re: variable doesn't work for version

[Gary Gregory]

On Mon, Mar 7, 2016 at 6:53 PM, Eric B <ebenza...@gmail.com> wrote:

> The first question I have to ask is what you are trying to accomplish with
> your continuous-delivery?


We have a Maven multi-module build which has thousands of unit tests. We
use Bamboo for CI and if we get a green build that means that all the tests
pass of course and that we successfully deployed the build to our repo (we
use Artifactory). We use the Maven's deploy to deploy, not the release
plugin.

At this point anyone can use the built product out of Bamboo's saved
artifacts or Artifactory: our internal/external consultants, sales
engineers, formal QA, other downstream, products, and so on. It's up to the
PO to decide when to slap a new major or minor version label and he/she can
do at anytime.

>From development's POV, a green build is a released product, with a version
for example 3.1.201601070101 (3.1.MMDDHHMM). We used to have the SVN
version number as the maintenance version part but we are switching to Git
soon, hence the move to timestamps.

Our parent POM contains what is considered a Maven "hack":

  

MMddHHmm
3
1
${version.major}.${version.minor}
${maven.build.timestamp}
${version.main}.${revision}

Each module then has:

${dv.version}

What is the Maven way to achieve this goal?

Gary



> Are you trying to put snapshot versions into a
> production/release state?
>
> The biggest issue I have noticed with teams is the misunderstanding of how
> SNAPSHOTs work, or their purpose in the development process.  Either teams
> want to release applications in SNAPSHOT mode, or release code that is
> essentially in SNAPSHOT (ie: development) mode, but with fixed version
> numbers.  But instead of changing version numbers, they use something like
> a timestamp to increment version numbers automatically.  But at the end of
> it all, it kind of contravenes maven's versioning concept.
>
> Normally, if your artifact is a work in progress, you should just be using
> a SNAPSHOT.  If you are looking to make a real release, then you should be
> promoting your code from a SNAPSHOT to a fixed version.  Generally, the
> concept of continuous-delivery should only apply when in a SNAPSHOT mode,
> since anything else isn't changing (ie: a fixed release doesn't need to be
> re-delivered).
>
> So then that begs the question why you need to constantly change your
> version numbers during your development phase?
>
> And if the goal is truly to have fixed versions for some other team to have
> access to a "stable" version of your artifact (ie: they can be guaranteed
> that it isn't going to change as you continue to develop), you could always
> use something like the maven-release-plugin to promote from SNAPSHOT to a
> fixed version, and then re-open the next version as a SNAPSHOT.  (Although
> I know there are many dissenters against the release-plugin).
>
> Thanks,
>
> Eric
>
>
>
> On Mon, Mar 7, 2016 at 7:15 PM, Gary Gregory <garydgreg...@gmail.com>
> wrote:
>
> > Is there a Maven-way to do continuous delivery then? As opposed
> > to continuous integration.
> >
> > Our current hack is to use the date as the maintenance version as a
> > variable for example 3.1.20160102
> >
> > G
> >
> > On Mon, Mar 7, 2016 at 11:18 AM, Eric B <ebenza...@gmail.com> wrote:
> >
> > > I personally have a pet-peeve of using system variables to define
> version
> > > numbers; I find it is counter productive to the building of maven
> > > artifacts.  There is no traceability to determine  the actual version
> of
> > an
> > > artifact once it has been built.  At least having a fixed version
> number
> > in
> > > the  element shows up in the META-INF/maven/../pom.* files.
> > >
> > > Is using a variable for the version even a good idea?
> > >
> > > Thanks,
> > >
> > > Eric
> > >
> > >
> > > On Mon, Mar 7, 2016 at 4:04 AM, Stephen Connolly <
> > > stephen.alan.conno...@gmail.com> wrote:
> > >
> > > > only specific properties are permitted for expansion in XPath paths
> > that
> > > > match the following regex
> > /project/(parent/)?(groupId|artifactId|version)
> > > >
> > > > On 2 March 2016 at 05:39, Raghu <raghunath...@yahoo.com.invalid>
> > wrote:
> > > >
> > > > > I have a POM with parent node as below: 
> > > > > com.test pom.parent
> > > > > ${test.version}
> > > > > ../scripts/pom.xml 
> > > > > This used to work till maven 3.3.3 version - mvn clean install.
> > > However,
> > > &

Re: variable doesn't work for version

[Gary Gregory]

Is there a Maven-way to do continuous delivery then? As opposed
to continuous integration.

Our current hack is to use the date as the maintenance version as a
variable for example 3.1.20160102

G

On Mon, Mar 7, 2016 at 11:18 AM, Eric B  wrote:

> I personally have a pet-peeve of using system variables to define version
> numbers; I find it is counter productive to the building of maven
> artifacts.  There is no traceability to determine  the actual version of an
> artifact once it has been built.  At least having a fixed version number in
> the  element shows up in the META-INF/maven/../pom.* files.
>
> Is using a variable for the version even a good idea?
>
> Thanks,
>
> Eric
>
>
> On Mon, Mar 7, 2016 at 4:04 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > only specific properties are permitted for expansion in XPath paths that
> > match the following regex /project/(parent/)?(groupId|artifactId|version)
> >
> > On 2 March 2016 at 05:39, Raghu  wrote:
> >
> > > I have a POM with parent node as below: 
> > > com.test pom.parent
> > > ${test.version}
> > > ../scripts/pom.xml 
> > > This used to work till maven 3.3.3 version - mvn clean install.
> However,
> > > the version 3.3.9 throws error though. When I change the version to a
> > value
> > > instead of the variable, it works fine.
> > > Won't maven support variable for version? Or is it a bug with 3.3.9?
> > > Appreciate your response...
> > > - regards,raghu
> >
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Message typo

[Gary Gregory]

I'm not sure who output this message but there is obviously a etter issing:

[INFO] -
[WARN] COMPILATION WARNING :
[INFO] -
[WARN] ootstrap class path not set in conjunction with -source 1.7

Gary

-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Offline builds nearly impossible

[Gary Gregory]

On Mon, Nov 16, 2015 at 6:37 AM, Jörg Schaible  wrote:

> Hi Jason,
>
> Jason van Zyl wrote:
>
> > If this does not work please let me know. This is what I’ve used in the
> > past and if it doesn’t work I agree it needs to be fixed. I honestly
> > haven’t tried making a hermetically sealed build in a few years but last
> > year worked on a project that did no network traversal aside from using
> > file-based repositories and it all worked fine.
>
> Worked like charm. I had to create the metadata for any plugin without a
> fixed version, but that's OK (none of those is actually involved creating
> the artifacts).
>

Can offline builds be documented in detail in the FAQ or site? It sounds
like this is not going to be as simple as saying "--offline" for a while.

Gary


> Cheers,
> Jörg
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

RE: Offline builds nearly impossible

[Gary Gregory]

On Nov 13, 2015 9:45 AM,  wrote:
>
> I just wanted to weigh in.
>
> This indeed does not function in what I would call an "intuitive" way.
>
> It would be really nice if offline mode meant just provide the switch and
everything used your local repo. No extra configuration or trickery
required.

+1

This would also help when your ISP looses service and you still want to get
some work done.

Gary
>
> I know in modern times, the idea of always being connected is the norm,
but if you KNOW you don't need any updates and you have a lot of deps, this
could speed up the build a bit. Especially if you are forced to use a 3G
connection for a build on an emergency basis in your job.
>
> Then again, it would also be nice if Santa Claus were real.
>
> When will Apache have their open source Santa project? ;)
>
> Cody Fyler
> Lending Grid Build Team
> G=Lending Grid Builds
> (515) – 441 - 0814
>
> -Original Message-
> From: Paul Benedict [mailto:pbened...@apache.org]
> Sent: Friday, November 13, 2015 11:27 AM
> To: Maven Users List 
> Cc: joerg.schai...@gmx.de
> Subject: Re: Offline builds nearly impossible
>
> I think most people, at least once in their life, try to use their local
repository cache as an offline remote repository. However, the two aren't
the same in concept though, IIRC, the last time I tried. You still need to
keep the two separate.
>
> Now it would be interesting if a tool existed to copy the contents of a
local repository and scrub its local metadata. That would then give you a
true "remote offline repo".
>
>
> Cheers,
> Paul
>
> On Fri, Nov 13, 2015 at 11:17 AM, Jason van Zyl  wrote:
>
> > If this does not work please let me know. This is what I’ve used in
> > the past and if it doesn’t work I agree it needs to be fixed. I
> > honestly haven’t tried making a hermetically sealed build in a few
> > years but last year worked on a project that did no network traversal
> > aside from using file-based repositories and it all worked fine.
> >
> > > On Nov 13, 2015, at 11:33 AM, Jörg Schaible 
> > wrote:
> > >
> > > Hi Jason,
> > >
> > > Jason van Zyl wrote:
> > >
> > >> Use a file based remote repository instead of trying to build in
> > >> offline mode.
> > >>
> > >> You can either use a repository manager to create the remote
> > >> repository
> > or
> > >> an empty local repository with a full build. As noted though, you
> > >> have
> > to
> > >> remove all local repository metadata and files if you create the
> > >> repository locally.
> > >>
> > >> Now that you have the repository that contains everything you need
> > >> to build create a settings.xml with a mirror pointing to a
> > >> file-based repository. You shouldn’t need to build in offline mode
> > >> but using a file-base repository in your mirror will effectively be
> > >> the same. This
> > way
> > >> you will not be subject to every Maven plugins potentially flaking
> > >> handling of offline mode.
> > >
> > > Good idea, thanks! And with a mirror setup to file:/// (except for
> > > that file-based remote repo) we can even verify that no offline
> > > access is required.
> > >
> > > Cheers,
> > > Jörg
> > >
> > >
> > > 
> > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> >
> > Thanks,
> >
> > Jason
> >
> > --
> > Jason van Zyl
> > Founder, Takari and Apache Maven
> > http://twitter.com/jvanzyl
> > http://twitter.com/takari_io
> > -
> >
> > To think is easy. To act is hard. But the hardest thing in the world
> > is to act in accordance with your thinking.
> >
> >  -- Johann von Goethe
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >

Re: Java 7 and 8 features

[Gary Gregory]

Hi,

What I see, is that most projects are struggling to move to Java 7, Java 8
seems out of range. There are a lot of opinions and both sides of each Java
version for and against. At the end of the day, it's about user feedback
and committer community involvement. The projects I help on also lack
manpower and maintaining more than one version is not I see folks wanting
to do. For myself, I usually want to work on the current version in
master/trunk and move that along. My work$ development is on Java 7 and
slated to switch to Java 8 in 2016 I would guess.

Gary

On Tue, Oct 27, 2015 at 9:37 AM, Oliver B. Fischer  wrote:

> Hi Vinicius,
>
> it is mostly to allow people which are bound (for any reason) to older JDK
> versions to use our software. There is a plenty number of projects which
> are not able to use newer JDK versions. I know that this is a
>  controversial topic I think that the majority of us would like to use all
> these features. But we must not forget the people using our software in
> their daily work.
>
> BYe,
>
> Oliver
>
> Am 27.10.15 um 16:49 schrieb Vinicius Corrêa de Almeida:
>
>> I analized some releases and i noticed that not using java 7 features like
>> multi catch and in java 8 do not use lambda expressions and others
>> features, so i came by this email to know why the developers not using
>> this
>> features?
>>
>>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fisc...@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fisc...@jabber.org
> X http://xing.to/obf
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Color logging in Maven 3.3.3

[Gary Gregory]

I thought this error message was no longer supposed to be displayed:

[WARN] The SLF4J binding actually used is not supported by Maven:
org.apache.logging.slf4j.Log4jLoggerFactory
[WARN] Maven supported bindings are:
[WARN] (from
jar:file:/C:/Java/apache-maven-3.3.3/lib/maven-embedder-3.3.3.jar!/META-INF/maven/slf4j-configuration.properties)
- ch.qos.logback.classic.LoggerContext
- org.slf4j.helpers.Log4jLoggerFactory
- org.slf4j.impl.SimpleLoggerFactory

I created these steps as a reminder to myself:

https://garygregory.wordpress.com/2015/03/23/watch-maven-in-color/

Am I missing something?

Thank you,
Gary

-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
http://www.manning.com/bauer3/
JUnit in Action, Second Edition http://www.manning.com/tahchiev/
Spring Batch in Action http://www.manning.com/templier/
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Adding comments to dependencies in POM

[Gary Gregory]

+1
Gary

 Original message 
From: James Green james.mk.gr...@gmail.com 
Date: 04/17/2015  04:58  (GMT-08:00) 
To: Maven Users List users@maven.apache.org 
Subject: Re: Adding comments to dependencies in POM 

[ Dragging up a really old topic. ]

https://issues.apache.org/jira/browse/MNG-5803

Incidentally I would vote against a different namespace as comments are
likely to be of use to readers of Maven POMs even if they are used for
visual purposes.


On 27 August 2014 at 12:03, Robert Scholte rfscho...@apache.org wrote:

 I think it should be solved with a separate namespace, so the model
 parsing stays pure without metadata irrelevant for Maven.
 And it should already work right now, no need for the pom xsd to change,
 since the Maven pom-parser should ignore these kinds of elements/attributes.

 Robert

 Op Wed, 27 Aug 2014 12:15:00 +0200 schreef domi d...@fortysix.ch:


  +1
 I think this would be a good idea, let us know about the issue, so we can
 vote on it.
 Domi

 On 27.08.2014, at 09:12, James Green james.mk.gr...@gmail.com wrote:

  I have in the past wasted hours of effort trying to weed out dependency
 issues where something has been added for reasons unknown. Removal leads
 to
 breakage.

 It would be helpful if, inside a POM, it were possible to add a comment
 element to a dependency. I realise this is possible as an XML comment,
 however having a POM field would let documentation engines record the
 comment.

 The same could be said for dependencies inside dependencyManagement.

 It would of course have the side effect of auto completion within IDEs
 showing authors how to officially comment on the reason for that work.

 An idea.

 James



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


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

Re: [VOTE] Name our mascot: Shotgun vs The Maven Owl

[Gary Gregory]

As cute as Shutgun might seem, for some unspecified definition of
cute, I am sick of hearing about any kind of gun...
http://www.chicagotribune.com/news/nationworld/chi-school-shootings-sandy-hook-20141211-story.html

Gary

On Mon, Dec 15, 2014 at 7:30 AM, Jeroen Hoek jer...@lable.org wrote:

 B

 2014-12-15 12:41 GMT+01:00 Martin Grigorov mgrigo...@apache.org:
  B
 
  Martin Grigorov
  Wicket Training and Consulting
  https://twitter.com/mtgrigorov
 
  On Mon, Dec 15, 2014 at 12:39 PM, Stephen Connolly 
  stephen.alan.conno...@gmail.com wrote:
 
  A
 
  On 15 December 2014 at 10:39, Stephen Connolly 
  stephen.alan.conno...@gmail.com wrote:
  
   After the run-off round, we are left with two names standing.
  
   This second vote will be a straight and simple majority wins.
  
   The vote will be open for at least 72 hours (with the potential of an
   extension until I send a message saying that the polls are closed)
  
   There will be no discussion in this thread, we have talked it all
 enough
   already. If you want to discuss something, please use a different
 thread.
  
   Vote:
  
   [A]: Shotgun
   [B]: The Maven Owl
  
   Thank you very much for your time
  
   -Stephen
  
 



 --
 Vriendelijke groeten,

 Jeroen Hoek

 Lable
 ✉ jer...@lable.org
 ℡ 088 44 20 202

 http://lable.org
 KvK № 55984037
 BTW № NL8519.32.411.B.01

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



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
http://www.manning.com/bauer3/
JUnit in Action, Second Edition http://www.manning.com/tahchiev/
Spring Batch in Action http://www.manning.com/templier/
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VOTE] Name our mascot: Shotgun vs The Maven Owl

[Gary Gregory]

I guess I should VOTE B, but I am not on the PMC so I am not sure which
votes count.

Gary

On Mon, Dec 15, 2014 at 5:26 PM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 You raise a fair point, and for that reason I am changing my vote to

 B

 On 15 December 2014 at 13:15, Gary Gregory garydgreg...@gmail.com wrote:
 
  As cute as Shutgun might seem, for some unspecified definition of
  cute, I am sick of hearing about any kind of gun...
 
 
 http://www.chicagotribune.com/news/nationworld/chi-school-shootings-sandy-hook-20141211-story.html
 
  Gary
 
  On Mon, Dec 15, 2014 at 7:30 AM, Jeroen Hoek jer...@lable.org wrote:
  
   B
  
   2014-12-15 12:41 GMT+01:00 Martin Grigorov mgrigo...@apache.org:
B
   
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
   
On Mon, Dec 15, 2014 at 12:39 PM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:
   
A
   
On 15 December 2014 at 10:39, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 After the run-off round, we are left with two names standing.

 This second vote will be a straight and simple majority wins.

 The vote will be open for at least 72 hours (with the potential of
  an
 extension until I send a message saying that the polls are closed)

 There will be no discussion in this thread, we have talked it all
   enough
 already. If you want to discuss something, please use a different
   thread.

 Vote:

 [A]: Shotgun
 [B]: The Maven Owl

 Thank you very much for your time

 -Stephen

   
  
  
  
   --
   Vriendelijke groeten,
  
   Jeroen Hoek
  
   Lable
   ✉ jer...@lable.org
   ℡ 088 44 20 202
  
   http://lable.org
   KvK № 55984037
   BTW № NL8519.32.411.B.01
  
   -
   To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
   For additional commands, e-mail: users-h...@maven.apache.org
  
  
 
  --
  E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
  Java Persistence with Hibernate, Second Edition
  http://www.manning.com/bauer3/
  JUnit in Action, Second Edition http://www.manning.com/tahchiev/
  Spring Batch in Action http://www.manning.com/templier/
  Blog: http://garygregory.wordpress.com
  Home: http://garygregory.com/
  Tweet! http://twitter.com/GaryGregory
 



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
http://www.manning.com/bauer3/
JUnit in Action, Second Edition http://www.manning.com/tahchiev/
Spring Batch in Action http://www.manning.com/templier/
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [ANN] FindBugs Maven Plugin version 2.5.5 Released

[Gary Gregory]

I still do not see the release in Maven Central. Thoughts?

Gary


On Fri, Jul 25, 2014 at 3:31 PM, Gary Gregory garydgreg...@gmail.com
wrote:

 Could you only announce after the plugins surface on MC? Right now I only
 see 2.5.4.

 Gary


 On Fri, Jul 25, 2014 at 11:34 AM, Garvin LeClaire 
 garvin.lecla...@gmail.com wrote:

 Hi,
 The Mojo team is pleased to announce the release of the FindBugs Maven
 Plugin version 2.5.5.
 FindBugs uses static analysis to inspect Java bytecode for occurrences
 of bug patterns.

 To get this update, simply specify the version in your project's
 plugin configuration:

 plugin
 groupIdorg.codehaus.mojo/groupId
 artifactIdfindbugs-maven-plugin/artifactId
 version2.5.5/version
 /plugin

 We solved the following issues:

 Release Notes - Mojo's FindBugs Maven Plugin - Version 2.5.5



 ** Bug
 * [MFINDBUGS-198] - Add maxRank to the check goal to allow eclipse
 m2e findbugs plugin to pick up this configuration



 ** Improvement
 * [MFINDBUGS-197] - Remove redundant Report word on report name
 labels



 Enjoy,,


 Garvin LeClaire
 garvin.lecla...@gmail.com




 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second Edition
 http://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory




-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
http://www.manning.com/bauer3/
JUnit in Action, Second Edition http://www.manning.com/tahchiev/
Spring Batch in Action http://www.manning.com/templier/
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [ANN] FindBugs Maven Plugin version 2.5.5 Released

[Gary Gregory]

Could you only announce after the plugins surface on MC? Right now I only
see 2.5.4.

Gary


On Fri, Jul 25, 2014 at 11:34 AM, Garvin LeClaire garvin.lecla...@gmail.com
 wrote:

 Hi,
 The Mojo team is pleased to announce the release of the FindBugs Maven
 Plugin version 2.5.5.
 FindBugs uses static analysis to inspect Java bytecode for occurrences
 of bug patterns.

 To get this update, simply specify the version in your project's
 plugin configuration:

 plugin
 groupIdorg.codehaus.mojo/groupId
 artifactIdfindbugs-maven-plugin/artifactId
 version2.5.5/version
 /plugin

 We solved the following issues:

 Release Notes - Mojo's FindBugs Maven Plugin - Version 2.5.5



 ** Bug
 * [MFINDBUGS-198] - Add maxRank to the check goal to allow eclipse
 m2e findbugs plugin to pick up this configuration



 ** Improvement
 * [MFINDBUGS-197] - Remove redundant Report word on report name
 labels



 Enjoy,,


 Garvin LeClaire
 garvin.lecla...@gmail.com




-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
http://www.manning.com/bauer3/
JUnit in Action, Second Edition http://www.manning.com/tahchiev/
Spring Batch in Action http://www.manning.com/templier/
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: maven-scm-publish-plugin - prefixing site content with project version?

[Gary Gregory]

Please post your finding back here! This is something I'd like to do for
some of the Apache Commons site too.

Gary


On Wed, May 22, 2013 at 8:12 AM, Robert Elliot r...@lidalia.org.uk wrote:

 Thanks Jörg, that looks like a promising line of investigation.

 Rob

 - Original Message -
  From: Jörg Schaible joerg.schai...@scalaris.com
  To: users@maven.apache.org
  Sent: Tuesday, 21 May, 2013 9:46:30 AM
  Subject: Re: maven-scm-publish-plugin - prefixing site content with
 project version?
  Hi Rob,
 
  Robert Elliot wrote:
 
   Is the general consensus that this is impossible?
 
  everything is published by default that is located in target/site. So
  you
  can solve this by configuring an ant task for the antrun plugin, that
  creates a copy in target/site/${version} and bind it to the post-site
  lifecycle
  (
 http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference
 ).
 
  Cheers,
  Jörg
 
  
   Rob
  
   - Original Message -
   From: Robert Elliot r...@lidalia.org.uk
   To: users@maven.apache.org
   Sent: Saturday, 18 May, 2013 10:29:25 PM
   Subject: maven-scm-publish-plugin - prefixing site content with
   project
   version? Hi,
  
   I'm using the maven-scm-publish-plugin to publish to gh-pages.
  
   I'd like to publish the site twice - once to the root of the branch
   (so that http://me.github.com/project-name is the maven site) and
   once
   to it prefixed with the version (so that
   http://me.github.com/project-name/1.2.3/ is also the maven site).
   Rationale is to have a historical record of what the project looked
   like, particularly the JavaDoc - it's nice for anyone using my
   libraries to be able to link their JavaDoc to the correct version
   of
   my JavaDoc. I certainly appreciate libraries that allow me to do
   this.
  
   Does this sound like something I ought to be able to do already?
   And
   if so, could someone give me a pointer?
  
   Thanks,
   Rob
  
  
   -
   To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
   For additional commands, e-mail: users-h...@maven.apache.org
 
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org

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




-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/
JUnit in Action, Second Edition http://www.manning.com/tahchiev/
Spring Batch in Action http://www.manning.com/templier/
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: maven-changes-plugin does not work with JIRA 5.1.1 and newer

[Gary Gregory]

Is this different from the compat issue fixed by using:

configuration
   useJqltrue/useJql

?

Gary

On Mon, Nov 19, 2012 at 2:59 PM, Benson Margulies bimargul...@gmail.comwrote:

 Atlassian made an incompatible change to JIRA that they have marked 'won't
 fix':

 https://jira.atlassian.com/browse/JRA-29152

 Unless they can provide some alternative, the maven-changes-plugin is
 essentially worthless for JIRA instances of that version or newer,
 which includes the ASF main JIRA instance. They say that they plan to
 include an alternative in 5.2; so once they release 5.2, and ASF JIRA
 runs it, someone can patch up the m-c-p to work with it. Until then,
 we are all out of luck.

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




-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0
Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

RE: [ANN] Maven Clover Plugin 1.10 released

[Gary Gregory]

Vincent: 
Thank you, 
Gary.

 -Original Message-
 From: Vincent Massol [mailto:[EMAIL PROTECTED]
 Sent: Sunday, August 07, 2005 1:29 AM
 To: users@maven.apache.org; dev@maven.apache.org
 Subject: [ANN] Maven Clover Plugin 1.10 released
 
 We are pleased to announce the Maven Clover Plugin 1.10 release!
 
 http://maven.apache.org/reference/plugins/clover/
 
 The Clover plugin allows measuring test coverage using Clover
 (http://www.cenqua.com/clover).
 
 Changes in this version include:
 
   Fixed bugs:
 
 o The ant:clover-checkAnt task requires initStringparameter. Issue:
   MPCLOVER-44.
 o When calling clover:ona second time, an updated
maven.compile.src.setwas
   ignored. Issue: MPCLOVER-30. Thanks to Eric Lapierre.
 
   Changes:
 
 o Upgrade to Clover 1.3.9. Issue: MPCLOVER-46,MPCLOVER-42.
 
 To automatically install the plugin, type the following on a single
line:
 
 maven plugin:download
   -Dmaven.repo.remote=http://www.ibiblio.org/maven,
 http://cvs.apache.org/repository/
   -DgroupId=maven
   -DartifactId=maven-clover-plugin
   -Dversion=1.10
 
 For a manual installation, you can download the plugin here:

http://www.apache.org/dyn/closer.cgi/java-repository/maven/plugins/maven
-
 clover-plugin-1.10.jar
 
 
 Have fun!
 -The Maven Clover Plugin development team
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [clover] Release a clover plugin (1.10?) for Clover 1.3.9?

[Gary Gregory]

Does an [ann] get posted here when plugins are released? Should I watch another 
list?

Thanks,
Gary

 -Original Message-
 From: Vincent Massol [mailto:[EMAIL PROTECTED]
 Sent: Monday, August 01, 2005 1:29 AM
 To: 'Maven Users List'
 Subject: RE: [clover] Release a clover plugin (1.10?) for Clover 1.3.9?
 
 Hi Gary,
 
 I'll try to release it sometime this week.
 
 Thanks
 -Vincent
 
  -Original Message-
  From: Gary Gregory [mailto:[EMAIL PROTECTED]
  Sent: lundi 1 août 2005 01:24
  To: users@maven.apache.org
  Subject: [clover] Release a clover plugin (1.10?) for Clover 1.3.9?
 
  Hello:
 
  Can we get a released version of the clover plugin (1.10?) for Clover
  1.3.9?
 
  Thanks,
  Gary
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[clover] Release a clover plugin (1.10?) for Clover 1.3.9?

[Gary Gregory]

Hello:

Can we get a released version of the clover plugin (1.10?) for Clover
1.3.9?

Thanks,
Gary