Re: Feedback sought

[Mark Derricutt]

Tangential topic - a while ago there was a thread/discussion about 
adopting something like spotless/palantir-java-format for automated 
formatting.


Whilst a massive change to the code base, which can (potentially) cause 
horrors for open branches/PRs unless rebased with care and also 
reformatted - but also quite useful /once/ adopted, as such concerns as 
the above largely disappear, and any wonky/horrible formatting that 
comes up is often more a smell that maybe the code should be cleaner, or 
split up more.


I don't recall any definitive decision being made either way, the topic 
just seemed to stalemate (at least as far as I saw).


Palantir/spotless does at least require JDK 11+ I believe so that's a 
big blocker, at least as far as the build JDK goes.


Mark (with 2cents)

On 15/10/23 3:10 pm, Joseph Kesselman wrote:
My experience is that they can actually be useful in expressing things 
like preferred code formatting style in importable/executable form. 

Re: [ANN] Apache Maven 4.0.0-alpha-7 released

[Mark Derricutt]

 On 29/06/2023 at 3:16:24 PM, Guillaume Nodet  wrote:

> Maven 4.0.0-alpha-7 is available via https://maven.apache.org/download.cgi
>


Interesting - I noticed over the weekend that under 4.0.0-alpha-7 surefire
isn’t picking up any of my Junit 5 tests, but maven 3.9.4 is.

I haven’t had a chance to look into this yet - but I wondered if anyone
else had seen anything similar?


-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

RE: Determine Maven Dependencies after a build

[Mark Derricutt]

On 16/04/2022 at 3:09:09 AM, "Creager, Greg" 
wrote:

> Is there a drawback to simply running resolve-ranges before official
> builds to ensure the pom has static versions? That seems like it would
> resolve having published poms with version ranges in production.
> mvn versions:resolve-ranges -DprocessParent=true
>

On the surface that may seem like a good approach, but what we found along
time ago, this led to:


   - The build you’re running on local dev machines, and ci servers, and on
   whatever machine does the release - may not actually be the same versions
   that were tested.
   - One concrete issue we saw early on what a spring related dependency
   that we had locked down, but that dependency itself had an open range
   dependency on spring with something like [2.0.0,] - when spring 3 was
   released, those dependencies got pulled into a build that then broke. This
   was on an associates project, but we had similar issues that tripped up
   runtime dependencies in our OSGi environment.
   - Rather than a giant multi-module project, we have multi-repos - so
   when it came to doing a hot fix of the distribution/packing, we’d take the
   bill of materials that was used in the version we’re replacing, and resolve
   ONLY a newer version of the sub-modules we’re replacing - for example:


import company:company.distribution:111-ga1;

allow unlocked /^.company:the-patched-artifact$/;


Also on that patched artefact, we’d change that import to same released
version and resolve the used dependencies specifically to what’s being
replaced in production. It’s a small amount of ceremony but it has served
to minimise the surface area of change for retesting.

The downside of forcing [] versions and no transitives, does mean
occasionally we end up with a large amount of re-releasing modules that
only contain dependency version updates, often that’s only needed if major
versions have changed, or minor versions of API specific artifacts.

One thing I have been considering adding to this was also recording the
checksums of the artifacts resolved, to help mitigate
any potential side chain attacks.




-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

Re: Determine Maven Dependencies after a build

[Mark Derricutt]

 I don’t believe there currently is a way for this is native maven.

We ended up writing a custom tool/mojo for resolution management using a
DSL like:

repository https://repo1.maven.org/maven2/ as central;

resolve highest org.antlr:antlr4-maven-plugin:[4.10,5.0.0) via central;

locked org.antlr:antlr4-maven-plugin:4.10;


Which tracks the repositories to check, a range to resolve, and what was
resolved/locked  ( also tracking deprecated/blacklisted dependencies ).

These pom.deps files get attached as artifacts and can be subsequently
imported in downstream repos:

repository https://nexus.az1.smxk8s.net/repository/maven-public-group;

import groupId:artifact.bill-of-materials:3.3.150;

locked org.antlr:antlr4-maven-plugin:4.10;


>From here, the actual pom.xml files are rewritten with
[4.10] references - locking the build to a specific,
locked range version ( for extra banality we also automatically add
 on * to prevent transitive dependencies.

This definitely has problems, but also have benefits and certainly made hot
fixes much easier to handle when we had different deployments staggered
into production between customer sites.

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree


On 14/04/2022 at 6:25:47 AM, "Creager, Greg" 
wrote:

> I am trying to reproduce a build that was done a week ago. Our maven pom
> files use range in many places ([1.0,1.1), when I go look at the pom of the
> published project, it just shows the range, not the actual version chosen:
>
> Published pom:
> 
>   com.hp.cp.dfe.shared
>   common-types
>   [1.0,1.1)
> 
>
>
> How do I determine exact versions of dependencies used in a prior build?
> In Apache ivy the published ivy.xml shows the exact version chosen, I was
> expecting maven to have the same and I am assuming I just am not using the
> right util.
>

Re: [ANN] Maven Resolver 1.7.1 released

[Mark Derricutt]

Interesting - updating to this version from 1.7.0 in my own plugin now
yields an NPE when creating a RepositorySystem - guess I know one thing I’m
working on this week :)

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

Release Notes - Maven Resolver - Version 1.7.1

>
> ** Bug
> * [MRESOLVER-96] - Dependency Injection fails after upgrading to
> Maven 3.6.2
>
>

Re: Maven moving to the next level: the build/consumer pom

[Mark Derricutt]

Love the work here - I'll definitely be keen on trying this out and see how it 
interacts with our tiles-maven-plugin.

Regarding this "reactor" bit tho - just because a module is in the reactor, 
doesn't always mean it has the same parent - the version of the dependency 
could be elided if the parent version matched AND that dependency is part of 
the reactor.

However, I have seem people use reactors purely as build-coordinators, and not 
always used. I'd much rather seeing them stay - esp. if using version ranges ( 
we force [] ranges for instance ).

Mark

On 24/06/20, 9:20 AM, "Matthieu BROUILLARD"  wrote:

> dependencies that are part of the reactor don't need a version anymore
What is meant here ? Is it that in a multimodule project a dependency from
a module to another of the same multimodule does not need the version ? For
example when having an api and impl in the same multimodule, the impl will
not require the version of the api?

Re: Surefire plugin with multi-release?

[Mark Derricutt]

Well this escalated quickly :) Now to find some time to look at this.

I'll pull the plugin code later

On 6 Apr 2019, at 19:52, Tibor Digana wrote:

> Mark, do not forget to update documentation with certain usecase(s).
> Configure your tool (prefer IntelliJ IDEA) with code style, see the
> instructions in
> https://maven.apache.org/developers/conventions/code.html#
> IntelliJ_IDEA_4.5.2B
> and download https://maven.apache.org/developers/maven-idea-codestyle.xml


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: Surefire plugin with multi-release?

[Mark Derricutt]

On 5 Apr 2019, at 6:29, Robert Scholte wrote:

> If you want to test the jar, you must use the failsafe plugin (or bind 
> surefire to the integration-test phase)

Can/could failsafe take a toolchain id as config, then you could configure 
additional executions using each toolchain you wanted?


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: [ANN] Apache Maven Install Plugin Version 3.0.0-M1 Released

[Mark Derricutt]

On 2 Oct 2018, at 4:32, Karl Heinz Marbaise wrote:

>  * [MINSTALL-118] - MavenProject with only attachments must have packaging 
> "pom"

Ik, this just hit me with the `karaf-assembly` packaging - and seemingly not 
setting a main file it seems.

Time to go lock that install plugin back down, and raise a ticket for Karaf.

Mark


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: Announcing OSSIndex plugins for Apache Maven: Scan your dependencies for known vulnerabilities

[Mark Derricutt]

On 26 Jul 2018, at 12:55, Brian Fox wrote:

> Find the Maven Plugin docs here:
> https://sonatype.github.io/ossindex-maven/maven-plugin/

This looks awesome! One nit pick tho - the XML plugin definition has a bad 
`` on the `` line.

Will be interesting to see how the results compare to the OWASP dependency 
checker.

Cheers
Mark


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: maven release plugin

[Mark Derricutt]

On 1 Mar 2018, at 23:18, Matthew Broadhead wrote:

> Thanks Mark.  looks easy enough.  i may try a maven plugin first though as i 
> like the idea of maven controlling all the git pushes etc

I tend to NOT let maven do the git pushes, for the cases we're doing releases 
on a hot fix, or a support branch - where there is no release branch, and not 
necessarily any back merging, we've found it's easier to just let maven do the 
release on the current branch, and leave any branching/merging to an outside 
force.

On hot fix/support branches we just do a standard `mvn release:prepare 
release:perform`.

Mark


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: maven release plugin

[Mark Derricutt]

On 1 Mar 2018, at 2:56, Ben Tatham wrote:

> Sounds like you're using gitflow (master, develop, feature/* branches).  If
> so, we use the jgitflow-maven-plugin instead of maven-release-plugin, which
> handles these transitions and the inherent conflicts caused by the maven
> versioning.
>
> Unfortunately, the maintainer is no longer working on it (and says he's not
> even working in java anymore), but it still works well.

For my own git-flow based releases I have the following `git-mvnrelease` script 
I have on the path:

```shell
#!/bin/sh
if ! git diff-index --quiet HEAD --; then
echo "Git is dirty, clean up your mess!"
exit 1
fi

VERSION=`xml sel -N x="http://maven.apache.org/POM/4.0.0; -t -v 
"/x:project/x:version" pom.xml`
BASEVERSION=${VERSION%-SNAPSHOT}
ARTIFACTID=`xml sel -N x="http://maven.apache.org/POM/4.0.0; -t -v 
"/x:project/x:artifactId" pom.xml`

echo "Removing non-scm files..."
git clean -fdi

echo "Checking master branch for updates..."
git checkout master
git pull origin master

git flow release start $BASEVERSION && mvn release:prepare release:perform && 
git flow release finish -n $BASEVERSION && git push origin && git push origin 
--tags
```

This first checks my working directory is clean, just for safety, extracts the 
pom.xml version for use in branch/tag names.  Switches to my `master` branch 
and makes sure it's up to date, then does a batch release/push.

I don't think I've ever had any issues with maven versioning, unless the 
version number as part of the release/merge has changed to something unexpected.

YMMV
Mark


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: When time do we need to delete .m2/repository

[Mark Derricutt]

On 15 Sep 2017, at 20:29, Baptiste Mathus wrote:

> So, yes, using dependency:purge-local-repository can help that use
> case/issue, but again IMO it's not worth it: just wipe out everything and
> redownload.

My release alias I use sets -Dmaven.repo.local=/tmp/maven-release-repository 
for every release, this way I ensure my dependencies/transitives/plugins or 
anything are all fresh, accessible, and not polluted by local builds.

/tmp gets blown away anytime I restart - sure it makes release builds a little 
bit slower, but knowing everything required to build is still available, is a 
slight comfort ( esp. from some bad experiences of a corrupt local nexus server 
and having try and source some older artefact builds ).



---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: Excluding -beta-N from a range

[Mark Derricutt]

Our rule of thumb at $work is NEVER, EVER, E V E R release a .0 artefact for 
this exact reason.

Always start with .1

Mark

-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt

On 13 Jan 2017, at 11:22, Benson Margulies wrote:

> I did not know how to tell them how to write a range that has the
> desired effect. Is there one?


signature.asc
Description: OpenPGP digital signature

Re: help with version range

[Mark Derricutt]

On 24 Sep 2016, at 1:38, Justin Georgeson wrote:

> ’m using the parent version range feature with “[1.1.0,1.2.0)” and it had 
> been going well. However I wanted to start working on 1.2.0 of the parent, so 
> I published a 1.2.0-alpha-1 version. And all the projects with te 
> “[1.1.0,1.2.0)” picked it up. I recognize that this is in keeping with the 
> implementation that x.y.z-(alpha|beta|…) precedes x.y.z, but it is 
> unintuitive to me. First in that I’ve stated I don’t want 1.2.0, and second 
> that once I do release 1.2.0 the projects which were receiving the alpha 
> builds will not get 1.2.0. I tried with both 3.2.5 and 3.3.9. Can the version 
> range syntax express the range I want?

We have a standing practise of NEVER releasing .0 releases for this very 
reason.  Our ranges tend to be [1.0.0,2.0.0)  but the first version would 
always be 2.0.1-SNAPSHOT.

Thinking about it, I should write an enforcement plugin rule that also traps 
that.


-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: Excluding all transitive dependencies

[Mark Derricutt]

On 7 Sep 2016, at 4:16, Benson Margulies wrote:

> In fact, I think I've seen it work. However, today, with Maven 3.3.9,
> it seems to be having no effect with the declaration below. Can anyone
> suggest a way to explain/fix/repair?

That appears to work for me in 3.3.9/3.4.0-SNAPSHOT.

No other dependencies pulling them in?

-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Mark Derricutt]

Christian, is there anywhere describing what changes there are/or planned
in Model version 4.1.0 at all?

Mark

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

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

[Mark Derricutt]

On 17 Aug 2016, at 12:32, Christian Schulte wrote:

> There is an easy way to solve this. Maven validates the model version in
> the POM to match "4.0.0". Based on that version, Maven can decide how to
> behave. I am thinking about introducing model version "4.1.0" in Maven
> 3.4. All existing 4.0.0 POMs will work the same way as before. Model

Would the deployed POM be a 4.1.0 or 4.0.0 Model? I seem to recall a long time 
ago when we were doing the Google Hangouts discussions about a mental 
separation of build/deploy POM.

If deployed as 4.1.0 then you'd be forcing all consumers of that dependency to 
use Maven 3.4.0 itself ( IMHO not in itself a bad idea ), but that might hurt 
any consuming applications like Sonar, Jenkins, or other build tools.



-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

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

[Mark Derricutt]

On Sat, Jul 23, 2016 at 3:27 AM, Karl Heinz Marbaise 
wrote:

> This is only a current state of development (Git hash:
> 90f26c279af9738735be8f84f60dcf21b6244e24) to get some feedback from the
> community...
>

Have been using daily HEAD builds as my daily driver for the past few
weeks, so far no issues on any of our projects, so here's my pre-emptive +2
:)

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing

[Mark Derricutt]

On 3 Jul 2016, at 9:40, Karl Heinz Marbaise wrote:

> I'm note sure if IDE is handling .mvn/maven.config correct?

Not sure about .mvn/maven.config - but I know IntelliJ sure doesn't seem to use 
./mvn/extensions.xml - the MavenServer they run is a single process for the 
lifetime of the IDE/project and doesn't seem to trigger ( at least, session 
level extensions ) each time to run things. Plugins with 
true seem to run tho.


-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing

[Mark Derricutt]

On 3 Jul 2016, at 11:39, Karl Heinz Marbaise wrote:

> If you started with Maven 2 and now you upgrade to Maven 3.3.9 you will get a 
> large number of new features and different behaviour compared to Maven 2 
> etc...but there are some parts in Maven 3.X+ which are working wronge for a 
> long time and which should keept the same ...to get reliable results (from 
> the users perspective)..

It's a pity we've broken that already tho - esp. with dependency resolution. 
One of the main things we all use maven for, and is one thing that is 
constantly a mystical land of hope.

It would seem that maven these days when using "3.3.9" as a version, if someone 
else wants "3.3.0" then the later is whats used, it used to be the highest 
version requested was used - this changes at some point and leads to all manner 
of confusion.

However, remaining on topic - I'd say that for 3.x we'd leave these features 
off by default, but for 4.x we turn them on.

I for one can't wait til we fix all the problems with the "compile" scope - and 
I don't care if we cause a lot of grief for end users in the process.




-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing

[Mark Derricutt]

The features look nice, the only thing I don't really like is (maybe
mistaken) it's command line only? Which would mean you have to manual
enable it every where,  ides, build servers, unless you can enable them
with some form of in-pom declaration?

>From the hip, on Android...
On 3/07/2016 09:19, "Karl Heinz Marbaise"  wrote:

> Hi,
>
> On 7/2/16 2:06 PM, Jason van Zyl wrote:
> 
> >So we need to figure out a way to deliver the new behavior while
> preserving
> >the old for a time being. Maybe a branch,
>
>
> > but I think the best way to do it is to have both behaviors exist in the
> > same codebase and turn on what we considered corrected behavior
> > with feature toggles.
> > Users can opt in early if they want to see the potential benefit
> > but it won’t affect users adversely or unintentionally.
> >Eventually over time the new behavior becomes the default and the old
> behavior
> > can be toggled for the stragglers.
>
> I have implemented as an example feature toggles as module via MNG-6056[1]
> (on a branch) which makes all this possible.
>
> So you can use things like:
>
> --activate-features MNG9991,MNG9992
>
> which can easily questioned in the code (already an example in the branch):
>
> @Requirement
> private SelectedFeatures featureToggle;
>   ...
> if (featureToggle.isFeatureActive(Feature.MNG1)) {
> // The feature is implemented here or a different selection is done.
> }}
>
>
> If we sometime in the future decied to make the feature MNG1 the
> default behaviour we can simply remove the if (...) in code and the
> enumeration entry...and it is default behaviour..those who give the
> activation via command line will only get a WARNING on a missing feature
> toggle which gives a hint to remove that from command line...like this:
>
> [WARNING] The requested feature 'MNG10001' Does not exist.
>
>
> Also you can request information like this (plus description):
>
> ~/ws-git/javaee (mvn321)$
> ~/tools/maven-test/apache-maven-3.4.0-SNAPSHOT/bin/mvn clean --list-features
>
> Currently existing feature toggles which you can enable:
>
> Issue Option   Description
> -  
> MNG-9991  MNG9991  First Feature to be toggable via command line option.
> First
>Feature to be toggable via command line option.
> MNG-9992  MNG9992  First Feature to be toggable via command line option.
> First
>Feature to be toggable via command line option. XX
> asdfa.
>asdf dsf.
> MNG-9993  MNG9993  First Feature to be toggable via command line option.
> More
>text than you think.
> MNG-1 MNG1 First Feature to be toggable via command line option.
> Here
>much more than you thing.
>
> If you like to know more about a particular issue please visit:
> issues.apache.org/jira/browse/[ISSUE]
> 
>
> so this implemented only two new command line options:
>
> --activate-features ARGS
> --list-features
>
> ...
>
> Furthermore if we identify wrong configurations etc. (not so easy or may
> be impossible) we can give a hint on the feature toggle to let the user
> make the decision if he want to have a different (correct) solution or an
> improved solutionor whatever...
>
>
> Kind regards
> Karl Heinz
>
>
> [1]: https://issues.apache.org/jira/browse/MNG-6056
>
>
>  Sure we can just throw away the old behavior but I honest think the
> downstream impact will be enormous, and in a negative way.
>
>>
>> On Jul 2, 2016, at 7:07 AM, Christian Schulte  wrote:
>>>
>>> Am 07/02/16 um 12:36 schrieb Oliver B. Fischer:
>>>
 My suggestions is based on the view of a Maven user who would like to do
 it's daily job ;-)

 In our team we have > 20 Maven projects and as a Maven 'User' you need
 the chance to fix such issues before the break your build. Everyone
 would blame Maven for this. We should have the chance to fix these
 problems before they become serious.

 WDYT?

>>>
>>> It's a matter of how you plan Maven upgrades. I understand you just want
>>> to download a newer Maven version without having to do anything else. As
>>> already said, the commits in question have been reverted for 3.4. Think
>>> about upgrading Maven is like upgrading your operating system. You are a
>>> developer yourself. How do you fix bugs without fixing them?
>>>
>>>
>>> Regards,
>>> --
>>> Christian
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>
>> Thanks,
>>
>> Jason
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Anyone using annotationProcessorPaths in maven-compiler-plugin

[Mark Derricutt]

On 27 Mar 2016, at 0:28, Andreas Gudian wrote:

> Right, in 3.5.1 I fixed an oversight that caused the modules direct
> dependencies to also show up in -processorpath.

Hrm, actually that's the reason I was looking at using this method over just 
listing the deps in the first place - since the processor in question pulls in 
things like Guava (and a different version ) as dependencies of the processor, 
and not the generated code, which was causing some issues with other parts of 
the build based on the class path.

> So anyway, in 3.5.1, it should work just as expected. Are you maybe using a
> different plexus-compiler implementation by configuring an
> addidtional plugin-dependency?

Not in that project no - will check again when I get back to the office after 
the Easter break.

> Here's another example config that does work:
> http://mapstruct.org/documentation/1.1/reference/html/index.html#setup

Hrm, that looks similar to what I had - I'll take a look at making a standalone 
project and seeing if that exhibits the same issue.

Mark


-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: Anyone using annotationProcessorPaths in maven-compiler-plugin

[Mark Derricutt]

This was using 1.8 and the 3.5.1 of the compiler plugin ( which seems to
have quite major differences in behaviour to 3.5 ), which I think it uses
the tools api and not calling javac ( I do note theres an option to force
using javac tho ) so might give that a shot.

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

On Fri, Mar 25, 2016 at 8:26 PM, Thomas Broyer <t.bro...@gmail.com> wrote:

> Have you set source and target to at least 1.6 or 6?
> You should see the -processorpath argument being passed to JavaC when
> running with -X.
>
> Le jeu. 24 mars 2016 00:37, Mark Derricutt <m...@talios.com> a écrit :
>
> > Hey all,
> >
> > Has anyone successfully used the new  setting
> > in the maven-compiler-plugin at all?
> >
> > I'm adding:
> >
> > 
> >   
> > com.google.dagger
> > dagger-compiler
> > 2.1
> >   
> >
> > to my compiler plugins configuration but it doesn't seem to work, when
> > running maven with -X I see the configuration is picked up, but it
> doesn't
> > seem to get passed to the compiler at all?
> >
> > [DEBUG] Goal:
> org.apache.maven.plugins:maven-compiler-plugin:3.5.1:compile
> (default-compile)
> > [DEBUG] Style: Regular
> > [DEBUG] Configuration:  encoding="UTF-8"?>
> >   
> > 
> >   com.google.dagger
> >   dagger-compiler
> >   2.1
> > 
> >   
> >   
> >   
> >default-value="${project.compileClasspathElements}"/>
> >   
> >default-value="javac">${maven.compiler.compilerId}
> >default-value="${reuseCreated}">${maven.compiler.compilerReuseStrategy}
> >   ${maven.compiler.compilerVersion}
> >   ${maven.compiler.debug}
> >   ${maven.compiler.debuglevel}
> >default-value="${project.build.sourceEncoding}">${encoding}
> >   ${maven.compiler.executable}
> >default-value="true">${maven.compiler.failOnError}
> >default-value="false">${maven.compiler.forceJavacCompilerUse}
> >   ${maven.compiler.fork}
> >default-value="${project.build.directory}/generated-sources/annotations"/>
> >   ${maven.compiler.maxmem}
> >   ${maven.compiler.meminitial}
> >   
> >   ${maven.compiler.optimize}
> >   
> >   
> >   
> >   
> >default-value="false">${maven.compiler.showDeprecation}
> >default-value="false">${maven.compiler.showWarnings}
> >   ${maven.main.skip}
> >default-value="false">${maven.compiler.skipMultiThreadWarning}
> >   ${maven.compiler.source}
> >   ${lastModGranularityMs}
> >   ${maven.compiler.target}
> >    default-value="true">${maven.compiler.useIncrementalCompilation}
> >default-value="false">${maven.compiler.verbose}
> >
> > When running the compiler with true I don't see the
> > dagger-compiler artefact anywhere on the paths mentioned ( to be expected
> > since it should be on the annotation path not class-path, but we don't
> > print out the annotation path ).
> >
> > Am I missing something simple? Including dagger-compiler as a normal
> > dependency works fine, but then bleeds into the class path.
> >
> > Mark
> >
> > --
> > Mark Derricutt
> > http://www.theoryinpractice.net
> > http://www.chaliceofblood.net
> > http://plus.google.com/+MarkDerricutt
> > http://twitter.com/talios
> > http://facebook.com/mderricutt
> >
>

Anyone using annotationProcessorPaths in maven-compiler-plugin

[Mark Derricutt]

Hey all,

Has anyone successfully used the new `` setting in 
the `maven-compiler-plugin` at all?

I'm adding:

```xml

  
com.google.dagger
dagger-compiler
2.1
  

```

to my compiler plugins configuration but it doesn't seem to work, when running 
maven with -X I see the configuration is picked up, but it doesn't seem to get 
passed to the compiler at all?

```xml
[DEBUG] Goal:  
org.apache.maven.plugins:maven-compiler-plugin:3.5.1:compile (default-compile)
[DEBUG] Style: Regular
[DEBUG] Configuration: 

  

  com.google.dagger
  dagger-compiler
  2.1

  
  
  
  
  
  ${maven.compiler.compilerId}
  ${maven.compiler.compilerReuseStrategy}
  ${maven.compiler.compilerVersion}
  ${maven.compiler.debug}
  ${maven.compiler.debuglevel}
  ${encoding}
  ${maven.compiler.executable}
  ${maven.compiler.failOnError}
  ${maven.compiler.forceJavacCompilerUse}
  ${maven.compiler.fork}
  
  ${maven.compiler.maxmem}
  ${maven.compiler.meminitial}
  
  ${maven.compiler.optimize}
  
  
  
  
  ${maven.compiler.showDeprecation}
  ${maven.compiler.showWarnings}
  ${maven.main.skip}
  ${maven.compiler.skipMultiThreadWarning}
  ${maven.compiler.source}
  ${lastModGranularityMs}
  ${maven.compiler.target}
  ${maven.compiler.useIncrementalCompilation}
  ${maven.compiler.verbose}

```

When running the compiler with `true` I don't see the 
`dagger-compiler` artefact anywhere on the paths mentioned ( to be expected 
since it should be on the annotation path not class-path, but we don't print 
out the annotation path ).

Am I missing something simple?  Including `dagger-compiler` as a normal 
dependency works fine, but then bleeds into the class path.

Mark


-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: [EXTERNAL] Use 2 pom.xml files with different names

[Mark Derricutt]

On 11 Aug 2015, at 3:25, Alex Ditu wrote:

 No, but is irrelevant, because the search on the install phase is purely
 based on the name pom.xml (it dosent take into account the -f option, or
 the pom's content). later I will look into the sources for a better
 understanding.

So the root cause here is that the maven-install-plugin ( and possibly, the 
maven-deploy-plugin ) need someway of knowing to use this alternate pom.xml 
instead of the normal one.

Is that configurable at all? At a long shot, can use of the build-helper-plugin 
replace the pom.xml artifact in the build?


-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: Are tiles the way?

[Mark Derricutt]

On 4 Jun 2015, at 14:19, Sander Verhagen wrote:

 Hi group,


 I'm toying with ideas to clean up a bunch of build configuration that we 
 have. There's some duplication going on, and I could push that into the 
 parent project. But since composition over inheritance is a good approach in 
 general, I'm thinking about using the Tiles Maven Plugin to do the same to my 
 build. I've played with it a long time 

Thanks for the reminder - I have a bunch of reviews in the gerrit queue to fix 
the fact that the current release is kinda broken. Work has been keeping me 
hell busy lately.

The incoming/pending patches fix a whole raft of issues I found with tiles in 
using them daily at work - the biggest being that I now disallow a tile being 
defined in a parent pom - forcing you to put them in the children ( solves 
issues with -pl etc. ) but currently gives me a maven warning about duplicate 
dependencies ( due to some mangling we do ).

Ideally native composition would be far better than tiles, but that requires 
POM format changes.

 So: are tiles still the way to go? (If they ever were)

Tiles ( as they are ) do pose some interesting quirks and limitations esp. if 
you're already using a custom lifecycle ( we had to stop using 
`packagingbundle/packaging` for our OSGi tiles in favour of the tile 
overriding the default jar plugin execution. And we can't seem to use release 
information in a tile ( I should remove that from the webpage actually since it 
looks like it won't actually work ).

Mark


-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: Running ALL tests in a multi-module , then failing the entire build.

[Mark Derricutt]

On 23 Apr 2015, at 17:12, Kevin Burton wrote:

 My understanding , is that I can enable this, but then the result of the
 run is a successful build?  Is that true?

 what’s the easiest way to set this up?

You could use:

  mvn --fail-at-end

which will run all modules regardless of if any fail, and only fail the build 
at the end.

or

  mvn --fail-never

if you want to run everything, but have the build succeed and some other 
process looks at the logs...

Does that help?

Mark

-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: Minimum RPM Version for rpm-maven-plugin?

[Mark Derricutt]

On 7 Apr 2015, at 10:07, Dan Tran wrote:

 I can run rpm-m-p at Linux sles 11 and 12,  and rpmbuild executable is
 required

We use redline-rpm ant tasks - pure-jvm RPM implementation.  The forums mention 
3-4 people have in the past made 'private' maven plugins, but no ones yet open 
sources one.

http://redline-rpm.org/usage.html


-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: Help with warning: 'Failed to getClass for org.apache.maven.plugin.source.SourceJarMojo'

[Mark Derricutt]

On 11 Mar 2015, at 21:32, Karl Heinz Marbaise wrote:

 I assume you are using a single local repository on your slave for all your 
 jenkins jobs? If so change the job configuration to use a repository localy 
 to the workspace of Jenkins...

If you want to talk craziness - on my build server I have this gem inside my 
~/.m2/settings.xml:

  
localRepository/build/m2repository/${env.GERRIT_BRANCH}-${env.GERRIT_TOPIC}/localRepository

Forcing a different m2 local repository based on branch/topic of code 
reviews/builds.  This means has the benefit of letting common branch+topics 
across multiple projects/jobs share the same SNAPSHOTS in isolation.

It _seams_ to work - even tho I have to manually clean out old directories 
after awhile.

-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: maven 3.0.6 release date

[Mark Derricutt]

On 3 Feb 2015, at 4:05, David Hoffer wrote:

 On a somewhat related note, one feature I'd like to see added to Maven is
 the ability to easily upgrade the version of Maven used.  I want the build
 to specify the version of Maven used and automatically download and use
 that version.  Currently it's the system that determines what version is
 installed on the path.  The best a project can do is require a (min)
 version of Maven.  This makes it hard to upgrade as we have several
 projects to support and some will never be upgraded as they are older
 branches.  Is this feature on the Maven radar?

Could this be handled in the /bin/mvn script - have a new mvn upgrade that 
could download into ~/.m2/install and run from there if newer than the system 
install.

This could also maven allow you to define a environment variable for M2_VERSION 
and have it download run against that?

Mark


-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: Resolving classpath hell issues by allowing libraries to only use the version they request?

[Mark Derricutt]

On 6 Jan 2015, at 12:29, Kevin Burton wrote:

 I agree.  in this case the issue is testing. I need to embed cassandra so I
 can test it but it’s conflicting with spark.

As a total side issue - have you considered using Docker?

http://blog.xebia.com/2014/10/13/fast-and-easy-integration-testing-with-docker-and-overcast/

I'm sorely tempted to switch a lot of our integration tests over to using 
overcast, assuming I can create a local registry of docker images ( I believe 
Artifactory can do it, but not nexus (yet?) ).

Mark

-- 
Mark Derricutt
http://www.theoryinpractice.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

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

[Mark Derricutt]

On 15 Dec 2014, at 23:39, Stephen Connolly wrote:

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

B.

-- 
Mark Derricutt
http://www.theoryinpractice.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Run-off for mascot's name

[Mark Derricutt]

B A D

gets my vote.

On 10 Dec 2014, at 14:00, Manfred Moser wrote:

 Someone has to kick off the voting..

 1. Shotgun
 2. Shotgun
 3. Shotgun

 or alternatively .. ;-)

 1. Shotgun
 2. Boo
 3. Kaboom


 Manfred

 Stephen Connolly wrote on 09.12.2014 02:52:

 This is a run-off vote to select the top two options for our new mascot's
 name.

 The entries with the highest number of votes will be selected for the final
 round. If there is only one entry with the highest number of votes then the
 entries with the second highest number of votes will also be included in
 the final round.

 The vote will be open for 72 hours.

 The entries are as follows:

 A. Abraham
 B. Boo
 C. Darth Mowl
 D. Jacob
 E. Kaboom
 F. Moses
 G. Rap
 H. Shotgun
 K. The Maven Owl
 L. Ty

 It is not clear whether all of the above suggestions were completely
 serious, but I have included them anyway for this first round.

 Please respond with at most your top three in order of preference. I may
 not use second or third preferences if we get a sufficient number of votes,
 but in the case of a small poll the additional preferences will help.

 In the event of repeated votes from an individual, only the last cast vote
 as determined by me will count.

 Any other discussion should happen in a separate thread.

 Thanks

 -Stephen



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


-- 
Mark Derricutt
http://www.theoryinpractice.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: [DISCUSS] Adopt Mr Couché-Tard as our mascot, change the logo font to Alte Haas Grotesk, change the colour letter to v

[Mark Derricutt]

+100 - Bring on the tard.

On 20 Nov 2014, at 23:49, Stephen Connolly wrote:

 The closest thing to a mascot that we have is

 http://maven.apache.org/images/maven-logo-2.gif
 Arse on desk behind laptop while waiting for Maven to finish downloading
 the interwebs


-- 
Mark Derricutt
http://www.theoryinpractice.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: API-s/Maven plugins for generation of REST API documentation

[Mark Derricutt]

On 19 Nov 2014, at 3:32, Jason van Zyl wrote:

 The RAML tools look great and I have a lot of respect for the guys at 
 MuleSoft but just haven't had time to play with it.

Online friend Jason Lee wrote a recent post on contract first with RAML:

  http://blogs.steeplesoft.com/posts/2014/10/15/contract-first-with-raml/

We're looking to go that route as well, altho due to some legacy we're using 
JAX-RS ( and switching would be epic ) so looking to write my own code-gem 
based of using the RAML parser to fit our existing setup.

This would at least put us in the position of when switching to JAX-RS ( or 
something else ) then its largely swapping out the code generator and stubs to 
services.

-- 
Mark Derricutt
http://www.theoryinpractice.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: Apache Maven - Checkstyle Plugin - Java 8

[Mark Derricutt]

On 4 Nov 2014, at 2:59, Joachim Van der Auwera wrote:

 You can overwrite the checkstyle version. My configuration looks like this:

Unfortunately this doesn't work with the latest checkstyle version _if_ you use 
inline configuration, and the DTD version has changed and no longer matches, so 
you end up with broken behaviour.

-- 
Mark Derricutt
http://www.theoryinpractice.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: release of git folder

[Mark Derricutt]

On 25 Oct 2014, at 23:05, Robert Scholte wrote:

 the only workaround I can think of is specifying the developerConnection in 
 this project as well.

I was meaning to post about this bug the other week - which we came across when 
working on the tiles-maven-plugin - this was introduced in the 
DefaultInheritanceAssemble somewhere in 3.1.x cycle.

For some reason - for every parent in the chain it appends the artifactId to 
the parents SCM section fields ( connection, developerConnection etc. ).

-- 
Mark Derricutt
http://www.theoryinpractice.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: Maven, Dependencies and Vulnerabilities

[Mark Derricutt]

On 1 Oct 2014, at 7:44, David Dillard wrote:


Hi,

I've been working on an internal presentation on how letting Maven's 
dependency mediation feature select versions of transitive 
dependencies can introduce vulnerabilities into a product and how to 
deal with that problem.  Unfortunately, it's a very manual process and 
I was thinking that perhaps changes could be made to Maven that would 
provide better automation.  To that end I'm wondering if the team has 
ever considered adding a section to the POM that would list 
significant changes in that release.  This would include a list of 
vulnerabilities fixed (e.g. CVE--) or serious bugs fixed.  
Each one could include a known set of versions affected (ala how CVEs 
work today) thus allowing tooling to say: the version of artifact XYZ 
you're using has a known vulnerability, would you like to upgrade to 
this new version with that vuln fixed?


There already exists a plugin covering a lot of this, using the CVE 
databases:


  https://github.com/jeremylong/DependencyCheck

This comes with a CLI, Jenkins, Maven, and Ant tasks for checking your 
dependencies/jars against CVE vulnerabilities.


Does this cover all the things you're working on?  Maybe join forces?


Mark

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

Re: Release fails with maven-javadoc-plugin 2.10

[Mark Derricutt]

You've updated to the 2.10 javadoc plugin, which is - sadly, showing a 
lot of problems ( exactly what you're seeing ).  I'd roll back to 2.9.1 
like most people are.


Mark


On 25 Sep 2014, at 18:36, Antti O. wrote:

Hi all, I've started seeing failures when doing a release during this 
week.

The projects released just fine previously.
The release fails at the perform stage when it's doing 
attach-javadocs.
Usually the error is something like this, the javadoc plugin fails 
with

dependencies:
[INFO] [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:2.10:jar 
(attach-javadocs) on
project MyProj: MavenReportException: Error while creating archive:  
[INFO]

[ERROR] Exit code: 1 -
E:\jenkins-work\release_MyProj-1.2\workspace\target\checkout\src\main\java\...\MyController.java:3:
package javax.portlet does not exist  [INFO] [ERROR] import
javax.portlet.RenderRequest;  [INFO] [ERROR] ^  [INFO] [ERROR]
E:\jenkins-work\release_aulis-Portlets-1.2\workspace\target\checkout\src\main\java\...\MyController.java:4:
package javax.portlet does not exist
A workaround is to skip the javadoc generation but it has to be 
configured
for each project. There are quite a number of those in my 
environment.. But

why does javadoc generation even need the dependencies?
Anyone else having the same problem?



--
View this message in context: 
http://maven.40175.n5.nabble.com/Release-fails-with-maven-javadoc-plugin-2-10-tp5806511.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: Tell maven to not have the parent pom as a dependency?

[Mark Derricutt]

You don't need N windows, I just add the pom in the maven projects tool 
window, and have open in my generated IDEA project my core project, plus 
any F/OSS project I may be forking/working on in the process.


Find Anywhere then works across all projects.

![Cloud Email Hosting  Security](http://smxemail.com/images/smxsig.png)
On 13 Sep 2014, at 3:58, Kevin Burton wrote:

Now I have two projects to maintain.  And the number is increasing… 
From an

IDE perspective, I have to have N windows and switch between them, and
remember which file is in which project.

Re: Importing Maven plugins and profiles

[Mark Derricutt]

You could do this with the tiles-maven-plugin:

  https://github.com/repaint-io/maven-tiles

We recently forked the old broken plugin and rehomed it under our 
repaint.io banner.


This provides mixins for maven.

On 13 Sep 2014, at 9:52, mavenarch wrote:


Hi,

Is there a way to import plugins and profile from another pom in Maven 
3.0

as we do for dependencies?

thanks  Regards



--
View this message in context: 
http://maven.40175.n5.nabble.com/Importing-Maven-plugins-and-profiles-tp5804776.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


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

Re: CD, version numbers, IDE integration

[Mark Derricutt]

Currently IntelliJ embeds 3.0.5 and gets perplexed over anything 3.2.x 
specific ( it really doesn't like the tiles plugin ).


I have a fork of Idea where I've bumped the embedded version of Maven 
but as yet, it dies horribly with RMI Classloader issues :(


On 1 Sep 2014, at 4:57, Benson Margulies wrote:


sure that IntelliJ would be most perplexed by
version${our-version}/version at the top of a project hierarchy. I
gave up on Eclipse some time ago, but I'd be nearly as surprised if



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

Re: maven 3.1.1 crashes on GC overhead limit exceeded with millions of org.eclipse.aether.graph.DefaultDependencyNode

[Mark Derricutt]

Sounds exactly like the problem I've been having locally on our 
integration tests, only in that instance its lots of version ranges ( 
using SNAPSHOTs ) that have transitive ranges (also using SNAPSHOTs ).


Maven would just lock up, altho it's really just taking a LNG 
time walking the combinatorial explosion of dependencies. We didn't get 
your ultimate result tho.


Here's hoping that new aether update works like a charm.

On 29 Aug 2014, at 14:29, Juven Xu wrote:

The background is, i’m helping migrating a huge project from maven2 
to maven3, and I noticed this project is using dozens of SNAPSHOT 
dependencies, and more than hundred  transitive SNAPSHOT dependencies, 
after updating most of the SNAPSHOT direct dependencies to RELEASE 
dependencies, the crash issue is mitigated a lot, but build is still 
slow, but at least it can pass.


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

Re: Remove old snapshots under local repository

[Mark Derricutt]

So not using the dependency plugin like I suggested?

On 20 Aug 2014, at 10:14, Dan Tran wrote:

 After all consideration.  I use Ron's advice and create a internal plugin
 to clean it up.

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

Re: Remove old snapshots under local repository

[Mark Derricutt]

Nope, it's takes the dependencies from your project pom.xml:

   mvn dependency:purge-local-repository -DresolutionFuzziness=artifactId

Mark

On 20 Aug 2014, at 14:11, Dan Tran wrote:

 the problem here is I have to enter artifactId, am I missing any thing?
 specially for a developer who is very clueless about Maven

 -D


 On Tue, Aug 19, 2014 at 7:09 PM, Mark Derricutt m...@talios.com wrote:

 So not using the dependency plugin like I suggested?

 On 20 Aug 2014, at 10:14, Dan Tran wrote:

 After all consideration.  I use Ron's advice and create a internal plugin
 to clean it up.

 -
 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: Remove old snapshots under local repository

[Mark Derricutt]

I tend to use:

mvn dependency:purge-local-repository

when sitting in a project directory, it'll go thru and delete all the 
SNAPSHOTs and re-resolve.


The only problem with it in the default mode, is that is _only_ deletes 
the `.jar`. files and doesn't rebuild any metadata, so if you're using 
version ranges you're kinda f**ked.


However, I usually use it with the following setting:

mvn dependency:purge-local-repository 
-DresolutionFuzziness=artifactId


which will delete ALL files related to the artifact - all versions, all 
meta data - it doesn't mean there's more to download again but works 
wonderfully.


MaRK

On 18 Aug 2014, at 21:10, Adrien Rivard wrote:


Or delete all directories that end with -SNAPSHOT



On Sun, Aug 17, 2014 at 8:18 AM, Dan Tran dant...@gmail.com wrote:


sounds like a good option.

Thanks

-D


On Sat, Aug 16, 2014 at 11:11 PM, Ron Wheeler 
rwhee...@artifact-software.com wrote:


On 17/08/2014 1:50 AM, Dan Tran wrote:

Hi I need to find a way to walk into local repository and remove 
all old

snapshots.

This is very helpful for developer to clean up his/her local rep.

how safe it is by blindly remove any file with timestamp format ( 
ie

xxx-1.0.0-20140816.071953-49.jar)?

Thanks

-D

Easiest thing to do is to delete the entire organization or project

branch (com.mycompany.project.*) from the local repo.

This will not likely delete anything of great value or anything that 
can

not be easily retrieved from your company repo.


Ron

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


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








--
Adrien Rivard

Re: Discovering/updating component file versions in maven dependencies

[Mark Derricutt]

The versions-maven-plugin has some good goals for this:

http://mojo.codehaus.org/versions-maven-plugin/

such as:

$ mvm versions:display-dependency-updates
$ mvm versions:display-plugin-updates

Mark

On 8 Aug 2014, at 15:20, Les Gasser wrote:

 3. Failing that, I suppose I have to survey repositories like central
 myself and notice when new versions appear. OK so a year from now I
 see needed-component-3.0.3 is in central. Is there any way via maven
 or maven/eclipse to update the original dependency, changing it from
 needed-component-2.3.4 to needed-component-2.3.4?  Or do I have to
 go in and edit the dependency spec in the project's pom.xml file
 myself?

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

Re: Remote repositories protocols

[Mark Derricutt]

I wonder if anyones considered doing a bit-torrent based repository.

Each GAV entry could be its own entry in a tracker. *ponders*

On 9 Jul 2014, at 19:48, Stephen Connolly wrote:

wagon is the extension point to implement additional protocols. You 
need to
register wagon implementations as extensions in order to use them in 
your
pom (or register them as additional dependencies of specific plugins 
in

your pom to use them for a specific plugin)


On 9 July 2014 07:42, Eric Cornely ericcorn...@gmail.com wrote:


Hi,

I read in the documentation (

https://maven.apache.org/guides/introduction/introduction-to-repositories.html
)
that maven repositories can be accessed by a variety of protocols 
such as

file:// and http://;

By curiosity I'm wondering what are the other protocols supported by 
maven.
Is there a list of them or a way I could make it ? by listing 
existing

wagon ? (Is wagon used only when deploy ?)

I'm really wondering about ftp://, ftps://, ssh://, sftp:// and 
smb://

support. If you know one of these works as a repository url, tell me.

Kind regards,

Eric Cornely
--
Eric Cornely
ericcorn...@gmail.com

Please consider the environment before printing this e-mail



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

Re: Maven 3.2.1 and java 1.5?

[Mark Derricutt]

You could use the maven-tools-chains plugin to make the 
maven-compiler-plugin etc. use JDK 1.5 even tho Maven itself is running 
with 1.6+.


Do you need to use JDK 1.5 or do you need to compile against 1.5?

On 14 Apr 2014, at 20:13, Ben Caradoc-Davies wrote:


http://maven.apache.org/download.cgi
System Requirements
JDK 	Maven 3.2 requires JDK 1.6 or above, while Maven 3.0/3.1 requires 
JDK 1.5 or above (this is to execute Maven - it still allows you to 
build against 1.3 and prior JDK's)


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

Re: [MNG-5551] Java 8 + Maven status

[Mark Derricutt]

What version of the maven-dependency-plugin?  I'm using 2.8 fine under 
JDK8 and have been for some time - this is using the `copy-dependencies` 
goal and nothing else tho...



On 27 Mar 2014, at 6:15, Steven Schlansker wrote:

Java 8 has now been out for a week and Maven is still not really 
compatible.
In particular, the maven-shade-plugin and maven-dependency-plugin do 
not work
due to an old version of ASM that throws 
ArrayIndexOutOfBoundsException on Java 8 class files.

Re: Incremental build API

[Mark Derricutt]

Looking interesting - will definitely take a look at this for my various 
language plugins ( coffee script, clojure, frege ).


On 26 Mar 2014, at 6:44, Jason van Zyl wrote:

A note to those interested that the use of the API in Maven requires 
3.2.1+.


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

Re: [ANN] Apache Maven Release 2.5 Released

[Mark Derricutt]

On 6 Mar 2014, at 0:44, Benson Margulies wrote:


http://maven.apache.org/maven-release/maven-release-manager/


I don't think I've ever actually come across the maven-release-manager 
before - is there any information about how/what it does - the 
introduction on the project page is rather.   hopeless.


Mark

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

Re: [ANN] Reflow Maven Skin 1.1.0 Released

[Mark Derricutt]

Wow - super shiny!

Can this work with asciidoc as well?

On 18 Feb 2014, at 13:07, Andrius Velykis wrote:

 Reflow Maven skin builds on Bootstrap and offers responsive design, modern
 web components, JavaScript goodies and wide customisation options. See it
 in action and read the documentation at Reflow skin website:

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

Re: Maven process stuck on MacOS with Java8

[Mark Derricutt]

You're not by any chance using fish as your shell are you?

For awhile some strange bug in fish ( at least on my old machine, along 
with a combination of prompt settings ) would hang on the termination 
of processes, more often than not maven but also others.  Something 
about it being stuck reading a char from stdin or something - only it 
wasn't time related, sometimes resizes/splitting the terminal would kick 
it back into gear.


On 31 Jan 2014, at 23:12, Stephane Nicoll wrote:

I am definitely impatient because looking at that closer, the shell is 
not
stuck but it takes several seconds to give back hand. Sometimes it's 
ok,

sometimes is 5 sec or so.


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

Re: Maven process stuck on MacOS with Java8

[Mark Derricutt]

That's the terminal, not the shell ( bash, zsh, fish, csh etc. ).

I was also using iTerm when I had my issue, and now I think about it - 
since the last beta update/release I've not seen the issue again, but I 
also changed laptops so can't recall if its only on the new install I've 
not had the issue.


I suspect they're not the same issue tho...  maybe.

On 1 Feb 2014, at 0:05, Stephane Nicoll wrote:


Mark,

I am using iTerm2 (1.0.0.20130622)

S.


On Fri, Jan 31, 2014 at 11:56 AM, Mark Derricutt m...@talios.com 
wrote:



You're not by any chance using fish as your shell are you?

For awhile some strange bug in fish ( at least on my old machine, 
along
with a combination of prompt settings ) would hang on the 
termination of
processes, more often than not maven but also others.  Something 
about it
being stuck reading a char from stdin or something - only it wasn't 
time
related, sometimes resizes/splitting the terminal would kick it back 
into

gear.


On 31 Jan 2014, at 23:12, Stephane Nicoll wrote:

I am definitely impatient because looking at that closer, the shell 
is not
stuck but it takes several seconds to give back hand. Sometimes it's 
ok,

sometimes is 5 sec or so.



-
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 process stuck on MacOS with Java8

[Mark Derricutt]

Can't say I've seen that with any of the 1.8 builds I've been trailing, 
either the official dev builds or the ones I'm compiling up myself...


Have you tried looking at a thread dump and seeing where in Maven it's 
hanging?


Mark

On 31 Jan 2014, at 0:13, Stephane Nicoll wrote:


Hi,

Has anybody else noticed an issue with Java8 running Maven?

I am using 1.8.0-ea-b124 and a maven command does not complete 
properly. It
does not matter which plugin or phase is invoked, the process is stuck 
at

the end and I have to ctrl-Z to go back to the shell.

Switching back to Java 1.7 fixes the problem for me.

Any idea?

Thanks,
S.


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

Re: Misunderstanding modules: Two or more projects in the reactor have the same identifier

[Mark Derricutt]

 When the project is relatively new and the internally-developed dependency
 A is no where near being mature, nearly every change being made to
 Project X requires a corresponding change to A. At this point in the
 development cycle (and for many months in the foreseeable future) I actually
 /do/ need to rebuild A every time I build X.

What I've often done here is create a new workspace area that contains symlinks 
( or git submodule checkouts ) of each of the modules I'm working on, and 
having a simple pom.xml in the top level that sets up a reactor build, then 
just build that.


signature.asc
Description: OpenPGP digital signature

Re: New logo?

[Mark Derricutt]

I'm favouring maven-15 here, the maven raven! Ok, it's not a raven, but maybe 
it should be :) heh.

The bird can quite easily stand alone from the text, and be usable - overlaid, 
underlaid, watermarked etc better than the others IMHO ( except 14 ).


 I like maven-12


signature.asc
Description: OpenPGP digital signature

Re: New logo?

[Mark Derricutt]

Is it me or are a lot of these purely changing the icon, not the logo.

i.e. is the logo inclusive of the mAven name ( side question - why is the A 
always a different colour, historic Ant reference? )

On 3 Jan 2014, at 2:18, Stephen Connolly wrote:

 As 9 is particularly problematic I have sketched -14 which is not a direct
 copy of a silhouette. This still has the issue w.r.t. other marks called
 maven using a silhouetted raven...


signature.asc
Description: OpenPGP digital signature

Re: Unable to use the maven-release-plugin to release

[Mark Derricutt]

My guess is you've got a new/recent git?

If so, you'll need to add:

dependencies
  dependency
groupIdorg.apache.maven.scm/groupId
artifactIdmaven-scm-provider-gitexe/artifactId
version1.8.1/version
  /dependency
/dependencies

so that you get the new version that actually picks up modified files ( git 
1.8.x finally drops the leading # from its output and broke the old scm 
provider.


On 26 Dec 2013, at 1:28, Martijn Dashorst wrote:

 I have tried to revert to maven-release-plugin:2.3.2 (the 6.12.0
 release was baked with this one), I have tried to apply apache-parent
 pom v13, and both failed with the same result.


signature.asc
Description: OpenPGP digital signature

Re: Unable to use the maven-release-plugin to release

[Mark Derricutt]

You're correct - 1.8.1 is not related to Git 1.8, however it is the latest 
release - and a fix that SUPPORTS Git 1.8 was actually released back in 
something like scm-provider 1.5 earlier in the year - only the Maven Release 
Plugin DOES NOT USE IT.

We should really have a new release of m-r-p that forces the use of current 
scm-providers cause I can see this problem only increasing as more people a) 
upgrade git or b) move to git and get pissed off with maven+git

This work around works, but really - goes against convention over configuration.


On 27 Dec 2013, at 1:43, Robert Scholte wrote:

 I don't think this will fix the issue.

 SCM 1.8.1[1] is not related to GIT 1.8.x

 It's a coincidence that the most recent version of SVN, GIT and SCM are all 
 1.8.x

 Robert


signature.asc
Description: OpenPGP digital signature

Re: Release plugin 2.4.2 ignores pushChanges=false

[Mark Derricutt]

This is the config I use:

plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-release-plugin/artifactId
  version2.4.1/version
  dependencies
dependency
  groupIdorg.apache.maven.scm/groupId
  artifactIdmaven-scm-provider-gitexe/artifactId
  version1.8.1/version
/dependency
  /dependencies
  configuration
autoVersionSubmodulestrue/autoVersionSubmodules
goalsdeploy/goals
pushChangesfalse/pushChanges
localCheckouttrue/localCheckout
  /configuration
/plugin

without issue. I've not yet updated to 2.4.2 tho...   I'm forcing the latest 
maven-scm-provider-gitexe artifact in order to use git 1.8+ which finally 
brought in a breaking change, the provider was updated some time ago to NOT use 
the output of git diff but m-r-p never uses the new versions automatically.

I believe the two relevant options you're looking for directly are pushChanges 
and localCheckout - pushChanges controls whether m-r-p will do a 'git push 
origin' during release after the prepare and perform goals.

localCheckout will cause m-r-p to clone FROM your working copy into the 
./target directory when doing the release goal, if you change the former you 
REALLY need to change the later, as the tags won't exist on the remote 
repository...

Sadly I think these options should be the default values when using git ( 
and.or mercurial, darcs, bazaar etc. ) since origin is not always accessible, 
or maybe even not exist (yet) - not everyone uses 'origin' as a remote name 
either.

Mark


On 27 Dec 2013, at 7:23, Mirko Friedenhagen wrote:

 Martijn, just a guess:

 - there is a setting in release:prepare for remote tagging which must be
 false as well if I remember correctly.

 Regards
 Mirko
 --
 Sent from my mobile
 On Dec 26, 2013 4:49 PM, Martijn Dashorst martijn.dasho...@gmail.com
 wrote:

 Is it me or does the maven-release-plugin ignore the pushChanges setting?

 Running the release process actually pushes the changes to the git
 repo. And I *really* don't want that to happen.

 Relevant configuration:

 plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-release-plugin/artifactId
  version2.4.2/version
  inheritedtrue/inherited
  configuration
  pushChangesfalse/pushChanges
  tagNameFormatwicket-@{project.version}/tagNameFormat
  updateWorkingCopyVersionsfalse/updateWorkingCopyVersions
  /configuration
 /plugin


 $ git --version
 git version 1.8.5.2

 $ mvn --version
 Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a;
 2013-09-17 17:22:22+0200)
 Maven home: /usr/local/Cellar/maven/3.1.1/libexec
 Java version: 1.7.0_45, vendor: Oracle Corporation
 Java home:
 /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre
 Default locale: en_US, platform encoding: UTF-8
 OS name: mac os x, version: 10.9.1, arch: x86_64, family: mac

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




signature.asc
Description: OpenPGP digital signature

Re: How to run a script only for top-level project using maven-antrun-plugin?

[Mark Derricutt]

As a side question - is there a way to get something to ONLY run in inherited 
projects?

I have a few things in my parent POM I'd like to propagate down without needing 
to put them in plugin-management and redeclaring them.

On 24 Dec 2013, at 12:30, Stephen Connolly wrote:

 inheritfalse/inherit


signature.asc
Description: OpenPGP digital signature

Re: maven-release-plugin oddity - no git commit under mvn 3.1.1

[Mark Derricutt]

I was speaking with Olivier on IRC earlier, so far I've managed to work around 
the issue by adding a dependency/ on the latest maven-scm-providers-gitexe 
inside my maven-release-plugin plugin/ block and that seems to have resolved 
the issue.

Simply dropping back to 2.3.2 of the release plugin didn't help as that still 
picked up the older maven-scm version which was looking for a git status output 
starting with #.

Mark

On 9 Dec 2013, at 22:00, Stephen Connolly wrote:

 There is a know issue with Git and release plugin 2.4.2 and something to do
 with SCM version bundled in Maven 3.1.1? (or maybe 3.1.x) Olivier may know
 more.


signature.asc
Description: OpenPGP digital signature

maven-release-plugin oddity - no git commit under mvn 3.1.1

[Mark Derricutt]

Hey all,

Just encountered a strange issue with the maven-release-plugin, when doing a 
release:prepare from my machine using Maven 3.1.1, and maven-release-plugin 
2.4.2 I get the following output:

[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd 
/Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git add -- 
pom.xml
[INFO] Working directory: 
/Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
[INFO] Executing: /bin/sh -c cd 
/Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git status
[INFO] Working directory: 
/Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
[INFO] Tagging release with the label com.smxemail.translation-13.2.9...
[INFO] Executing: /bin/sh -c cd 
/Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git tag -F 
/var/folders/bq/jtxn4t511xz7l_t3t4q4c634gn/T/maven-scm-596385603.commit 
com.smxemail.translation-13.2.9
[INFO] Working directory: 
/Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
[INFO] Executing: /bin/sh -c cd 
/Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git ls-files
[INFO] Working directory: 
/Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
[INFO] Transforming 'com.smxemail.translation'...
[INFO] Not removing release POMs
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd 
/Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git add -- 
pom.xml
[INFO] Working directory: 
/Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
[INFO] Executing: /bin/sh -c cd 
/Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git status
[INFO] Working directory: 
/Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
[INFO] Release preparation complete.
[INFO] 
[INFO] BUILD SUCCESS

You can see here that there are no git commit commands being run, this in 
turn breaks the build.

A coworker who is still using Maven 3.0.4 was able to prepare and release the 
artefact fine however, so I'm wondering if there's some issue at the SCM layer 
of maven that's breaking when running under 3.1.1 that isn't an issue when 
using 3.0.4.

Has anyone else seen any behaviour like this?

Mark


signature.asc
Description: OpenPGP digital signature

Re: maven-release-plugin oddity - no git commit under mvn 3.1.1

[Mark Derricutt]

Ok - so this looks to be an issue introduced in Git 1.8.5, from
https://raw.github.com/git/git/master/Documentation/RelNotes/1.8.5.txt

 * git status now omits the prefix to make its output a comment in a
   commit log editor, which is not necessary for human consumption.
   Scripts that parse the output of git status are advised to use
   git status --porcelain instead, as its format is stable and easier
   to parse.

From looking at the git log of
./maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/status/GitStatusConsumer.java
I see that the has been using the newer git status --porcelain command
for some time now, however from walking the dependencies of
maven-release-plugin, I appear to find 1.7 being resolved ( at least via
IntellliJ ).

It looks like Olivier Lamy updated the git status support in [1] in git
commit 5c58908896a1b82bc6ee0af005adf0d6ef326395

Up until this week this didn't appear to be a problem, until Git 1.8.5 was
released and removed the leading # from the status messages

How do we get Maven to start using the newer releases of SCM - is that just
a matter of declaring a dependency in my parent pom?

Mark



[1] [SCM-686] Maven SCM failed to parse git status output if git messages
are translated - Submitted by Ralf Thielow.

-- 
Great artists are extremely selfish and arrogant things — Steven Wilson,
Porcupine Tree


On Mon, Dec 9, 2013 at 3:40 PM, Mark Derricutt m...@talios.com wrote:

 Hey all,

 Just encountered a strange issue with the maven-release-plugin, when doing
 a release:prepare from my machine using Maven 3.1.1, and
 maven-release-plugin 2.4.2 I get the following output:

 [INFO] Checking in modified POMs...
 [INFO] Executing: /bin/sh -c cd
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git add
 -- pom.xml
 [INFO] Working directory:
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
 [INFO] Executing: /bin/sh -c cd
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git
 status
 [INFO] Working directory:
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
 [INFO] Tagging release with the label com.smxemail.translation-13.2.9...
 [INFO] Executing: /bin/sh -c cd
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git tag
 -F
 /var/folders/bq/jtxn4t511xz7l_t3t4q4c634gn/T/maven-scm-596385603.commit
 com.smxemail.translation-13.2.9
 [INFO] Working directory:
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
 [INFO] Executing: /bin/sh -c cd
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git
 ls-files
 [INFO] Working directory:
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
 [INFO] Transforming 'com.smxemail.translation'...
 [INFO] Not removing release POMs
 [INFO] Checking in modified POMs...
 [INFO] Executing: /bin/sh -c cd
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git add
 -- pom.xml
 [INFO] Working directory:
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
 [INFO] Executing: /bin/sh -c cd
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git
 status
 [INFO] Working directory:
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
 [INFO] Release preparation complete.
 [INFO]
 
 [INFO] BUILD SUCCESS

 You can see here that there are no git commit commands being run, this
 in turn breaks the build.

 A coworker who is still using Maven 3.0.4 was able to prepare and release
 the artefact fine however, so I'm wondering if there's some issue at the
 SCM layer of maven that's breaking when running under 3.1.1 that isn't an
 issue when using 3.0.4.

 Has anyone else seen any behaviour like this?

 Mark

Re: plugin version ranges errors with Maven 3.1.1

[Mark Derricutt]

Unless you need them, and limit their usage to your OWN packages.

However - you did fail to mention simply that: version ranges are not, and 
AFAIK have NEVER been supported for plugins or parents.

Mark

On 7 Dec 2013, at 9:19, Ron Wheeler wrote:

 Version ranges are generally a bad idea.


signature.asc
Description: OpenPGP digital signature

Jenkins unable to download maven 3.1.1

[Mark Derricutt]

Hey all,

I just told my Jenkins server to use Maven 3.1.1 and am seeing it hang when 
trying to download and install, from multiple machines on our network wget'ing

http://archive.apache.org/dist/maven/binaries/apache-maven-3.1.1-bin.zip

gives us:

http://archive.apache.org/dist/maven/binaries/apache-maven-3.1.1-bin.zip
--2013-10-17 15:42:23--  
http://archive.apache.org/dist/maven/binaries/apache-maven-3.1.1-bin.zip
Resolving archive.apache.org... 192.87.106.229, 140.211.11.131, 
2001:610:1:80bc:192:87:106:229
Connecting to archive.apache.org|192.87.106.229|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 6297277 (6.0M) [application/zip]
Saving to: ‘apache-maven-3.1.1-bin.zip’

…  and then hangs.

We get the length headers but then nothing - and this is now preventing jenkins 
from starting up :(

I got around this my taking my already downloaded version and just unzipping it 
into ./jenkins/data/tools/hudson.tasks.Maven_MavenInstallation

but thought I'd mention it….

signature.asc
Description: OpenPGP digital signature

Re: Is there a Maven plugin for the Java debugger (jdb)?

[Mark Derricutt]

You could run it via the maven-exec-plugin, which allows you to pass down the 
classpath.

On 11 Oct 2013, at 3:52, Andrew Pennebaker wrote:

 Yes. I'm looking for a task like `mvn jdb:debug Class` that starts a jdb
 session on Class.main().

 I can run jdb on individual Java code outside of a Maven structure, but I'm
 not sure how to inform jdb of Java code in a Maven project, Maven's
 CLASSPATH handling, etc. etc.


signature.asc
Description: OpenPGP digital signature

Re: Multiple JDK versions

[Mark Derricutt]

-1 on this. The JDK is *not* 100% backwards compatible.  It's FORWARDS 
compatible yes, but not backwards.


One case I know of is that certain String methods in JDK6 went from 
taking (String s) as an arg, to taking (CharSequence c) as arguments, if 
compiled against JDK6 -even if targetting 1.5 bytecode- the compiled 
method signature looks for CharSequence, which when run on JDK5 fails 
with method-not-found and blows up.


There -are- legitimate cases for compiling with JDK5/JDK6 as your 
boot-class-path - for this - the toolchains plugin is your answer.


Mark


Baptiste MATHUS wrote:

+1  on the question, do you really need to build for both versions? As JDK
is backward compatible, you could for example build only with1.5.


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

Re: Multiple JDK versions

[Mark Derricutt]

Ron Wheeler wrote:
So always compile with 1.5 and make a package for 1.5 and copy it to 
files with 1.6 and 1.7 names.
If the managers don't know how Java JVM works they will be impressed 
by how fast you can deliver new packages in so many operating systems 
and really impressed at the speed with which you can bring out 1.8 
support. 
Well yes generally - however this week I had code that when compiled ON 
JDK7 but targetting JDK6 worked fine, but targetting JDK7 failed to even 
compile.


This was the in part my discovery of this new javac error message:

[ERROR] .../TransactionFilter.java:[112,11] exception 
javax.validation.ConstraintViolationException has already been caught


turns out, javac now enforces/tracks the loss of visibility in catch 
blocks, in this case, above the ConstraintViolationException catch block 
was one for ValidationException , this is ConstraintViolationExceptions 
super class.


However, I was pointing out the just compiling to JDK5 doesn't really 
help much, but you are correct and I got my terms backwards - I refer to 
this quote that I posted on my own darn blog ;p


http://www.theoryinpractice.net/post/18036749530/java-has-never-been-future-compatible-and-will

Java has never been future compatible, and will never be. I just want to 
make sure that is clear, because if you've been under the impression 
that it was 100% future compatible or that there was an implied contract 
I can assure you that is not the case. There are numerous times in each 
release where fixing a bug will break somebody. It is just the nature, 
or physics, of the situation.

-- Richard Bair on bundling a JRE per-application for desktop applications.

If you want to be JDK5 compatible, compile for, and WITH JDK5.

Re: Unpacking jars into target/classes

[Mark Derricutt]

Stephen Connolly wrote:

Just for you, I have taken the 30 minutes out of my life and written a
Maven Plugin that will solve your issues with those pesky non-maven
dependencies.

https://github.com/stephenc/non-maven-jar-maven-plugin

You will need to wait a couple of hours for the sync to central before you
can use that plugin.

Stephen - thank you for this plugin! I was actually struck with a 
similar issue last night writing up a sample project to demonstrate 
maven to someone elses non-maven project, and started down the file:// 
repo route and gave up in disgust at myself after having it not quite 
work with multi-module builds.


This is a simple plugin, but elegantly solves a -temporary- transitional 
issue.


Big props to you.

Mark


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

Re: git release:prepare does not commit the poms (Linux)

[Mark Derricutt]

The 2.4 git problems are related to the release plugin ignoring local 
checkout/disabling push settings primarily, so that your release is 
tagged locally, but then MRP tries to clone the tag from upstream and fails.


Either way, dropping back to 2.3.2 to eliminate those issues would be a 
good point of call.


One thing I've also noticed that sounds familiar, make sure you don't 
have a release.properties in your working directory prior to a new 
release - sometimes I've noticed it gets left behind somehow and 
depending on whats in that file, MRP will resume the release from a 
point where it thinks your version number has already been updated - and 
thus releases/deploys a -SNAPSHOT to your release repo.


Mark


Robert Scholte wrote:

could you try to use maven-release-plugin 2.3.2?
There are some known issues with GIT and the maven-release-plugin 2.4, 
which need to be fixed in the SCM project first. 


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

Re: Git Repositories

[Mark Derricutt]

From personal experience single artifact repositories work best. Mostly 
due to the way git's branching/tagging model works ( over the whole 
repository ).


Also, the maven-release-plugin in its default configuration only 
releases from the root of the repository so unless you want ALL your 
models to have the same version number ALL the time, a multi-module 
project just doesn't really work too well in git land.


Mark


Eric Kolotyluk wrote:


I'm a git newbie and I was wondering if there are any best practices
around using maven with git people could point me to?

For example, if I have a project with several artifacts/modules

net.kolotyluk.coolapp
- client.jar
- common.jar
- service.jar

is it better to create a single repository net.kolotyluk.coolapp for
the project, or several repositories such as
net.kolotyluk.coolapp.client net.kolotyluk.coolapp.common and
net.kolotyluk.coolapp.service for each artifact?

Cheers, Eric

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

Re: Merging between branches but keep versions intact?

[Mark Derricutt]

Git-flow is your friend.  A very nice automated branching model for 
working with feature/release branches.


I made a short intro video some time ago:

http://vimeo.com/16018419

The AVH branch is the most up to date maintained version:

http://blog.avirtualhome.com/git-flow-avh-edition-1-3-0-released/


motes motes wrote:

We are working on automating a branch/release plan using git and
nexus. Using the maven-release-plugin is pretty simple for creating
tags.

But we also need to have multiple branches and merge between these
branches during development up to a release. Further these branches
needs to have separate versions so they don't get mixed up when
deploying to nexus.

The problem is that a merge from one branch to another should NOT
overwrite the versions. Anyone facing the same challenges - merging
between branches but keep the versions intact?

-
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: [ANN] Maven Release Plugin 2.4 Released

[Mark Derricutt]

Hrm - reading your post makes it sound like the two options I mentioned 
I'm using ( pushChangesfalse/pushChanges and 
localCheckouttrue/localCheckout ) are possibly now applied by 
default - which was proposed ages ago as the preferred behaviour for 
distributed version control systems ( as their may not be an upstream 
repo, or multiple ).


Altho I don't see that change being mentioned anywhere if it is...

Julien Silland wrote:


[-announce]

There are known issues between the 2.4 plugin and the SCM integration 
for git. See 
http://mail-archives.apache.org/mod_mbox/maven-users/201301.mbox/%3CA94BB529DDA042A281B039C400250037%40turn.com%3E 
and following messages for open bugs tracking at least one issue which 
appears different from yours but is equally concerning. Your options 
are to stay on 2.3.2 or to try explicitly defining the git scm 
dependency of the release plug-in to a previous version.


Cheers,
-jsi


--
Julien Silland


On Sunday, January 6, 2013 at 2:30 PM, Mark Derricutt wrote:



Hey all,

First day back at work and first up we're doing a release - at the end of
the year I'd bumped our poms to use the 2.4 plugin but never did any
releases, and now - I find it appears to be broken with git.

In my release config we have:

pushChangesfalse/pushChanges
localCheckouttrue/localCheckout

however, when release:perform runs, the mojo tries to clone from the 
REMOTE

repository which doesn't have the new tag, dropping back to 2.3.2 and
everything works fine and we can release.

Is this a known issue?


--
Great artists are extremely selfish and arrogant things — Steven 
Wilson,

Porcupine Tree


On Wed, Dec 19, 2012 at 12:04 PM, Robert Scholterfscho...@apache.org 
(mailto:rfscho...@apache.org)wrote:




The Apache Maven team is pleased to announce the release of the Maven
Release Plugin, version 2.4

This plugin is used to release a project with Maven, saving a lot of
repetitive, manual work. Releasing a project is made in two steps: 
prepare

and perform.

http://maven.apache.org/**plugins/maven-release-plugin/http://maven.apache.org/plugins/maven-release-plugin/

You should specify the version in your project's plugin configuration:

plugin
groupIdorg.apache.maven.**plugins/groupId
artifactIdmaven-release-**plugin/artifactId
version2.4/version
/plugin

Release Notes - Maven 2.x Release Plugin - Version 2.4

** Bug
* [MRELEASE-186] - Active profiles are not carried through into the
release descriptor
* [MRELEASE-260] - Profiles given on command-line not added to
exec.additionalArguments
* [MRELEASE-415] - Plugin fails to activate profiles in submodules.
* [MRELEASE-459] - releaseProfiles has no effect without passing
profiles in the command line
* [MRELEASE-511] - release:prepare Error parsing version, cannot
determine next version: Unable to parse the version string when 
running in

batch mode.
* [MRELEASE-571] - When collecting active profiles, the active
profiles from parent poms are not considered
* [MRELEASE-614] - releaseProfiles works only if at least one
(default) profile is activated in the same pom.xml
* [MRELEASE-619] - release:branch doesn't work as expected with
multi-module projects
* [MRELEASE-667] - Profiles activated in settings.xml can't be
deactivated for release
* [MRELEASE-750] - String index out of range: -1 in 
ReleaseUtils.**loadResolvedDependencies()

when using Parent-Module-Layout
* [MRELEASE-755] - When passing arguments to underlying maven
executions not all maven options are accepted
* [MRELEASE-772] - mvn release:prepare fails with IOException and a
write error (Access is denied)
* [MRELEASE-775] - IllegalStateException while checking for
modifications if multiple exclusion patterns match
* [MRELEASE-785] - Arguments containing spaces and quotes cause the
forked maven process to fail
* [MRELEASE-786] - -Darguments doesn't allow -T to be passed to forked
builds for multi threading
* [MRELEASE-787] - release:prepare-with-pom fails when
suppressCommitBeforeTag is used (SVN)
* [MRELEASE-795] - Wrong level when using release:branch
* [MRELEASE-808] - Can't generate release-pom.xml when custom
finalName contains ${project.version}

** Improvement
* [MRELEASE-559] - Clarify parameter documentation for release:branch
* [MRELEASE-734] - When releaseVersion and developmentVersion are
passed in command-line but are empty should be treated as not-defined
* [MRELEASE-783] - release:update-versions should not need SCM config
* [MRELEASE-796] - Add AbstractScmReleaseMojo

** New Feature
* [MRELEASE-592] - Please allow de-activation of profiles

** Task
* [MRELEASE-776] - use maven-plugin-tools' java 5 annotations


Enjoy,

-The Apache Maven team

--**--**-
To unsubscribe, e-mail: dev-unsubscribe@maven.apache 
(mailto:dev-unsubscribe@maven.apache).**orgdev-unsubscr...@maven.apache.org 
(mailto:dev-unsubscr...@maven.apache.org)
For additional commands, e-mail: dev-h...@maven.apache.org 
(mailto:dev-h

Re: [ANN] Maven Release Plugin 2.4 Released

[Mark Derricutt]

Hey all,

First day back at work and first up we're doing a release - at the end of
the year I'd bumped our poms to use the 2.4 plugin but never did any
releases, and now - I find it appears to be broken with git.

In my release config we have:

pushChangesfalse/pushChanges
localCheckouttrue/localCheckout

however, when release:perform runs, the mojo tries to clone from the REMOTE
repository which doesn't have the new tag, dropping back to 2.3.2 and
everything works fine and we can release.

Is this a known issue?


-- 
Great artists are extremely selfish and arrogant things — Steven Wilson,
Porcupine Tree


On Wed, Dec 19, 2012 at 12:04 PM, Robert Scholte rfscho...@apache.orgwrote:

 The Apache Maven team is pleased to announce the release of the Maven
 Release Plugin, version 2.4

 This plugin is used to release a project with Maven, saving a lot of
 repetitive, manual work. Releasing a project is made in two steps: prepare
 and perform.

 http://maven.apache.org/**plugins/maven-release-plugin/http://maven.apache.org/plugins/maven-release-plugin/

 You should specify the version in your project's plugin configuration:

 plugin
   groupIdorg.apache.maven.**plugins/groupId
   artifactIdmaven-release-**plugin/artifactId
   version2.4/version
 /plugin

 Release Notes - Maven 2.x Release Plugin - Version 2.4

 ** Bug
 * [MRELEASE-186] - Active profiles are not carried through into the
 release descriptor
 * [MRELEASE-260] - Profiles given on command-line not added to
 exec.additionalArguments
 * [MRELEASE-415] - Plugin fails to activate profiles in submodules.
 * [MRELEASE-459] - releaseProfiles has no effect without passing
 profiles in the command line
 * [MRELEASE-511] - release:prepare Error parsing version, cannot
 determine next version: Unable to parse the version string when running in
 batch mode.
 * [MRELEASE-571] - When collecting active profiles, the active
 profiles from parent poms are not considered
 * [MRELEASE-614] - releaseProfiles works only if at least one
 (default) profile is activated in the same pom.xml
 * [MRELEASE-619] -  release:branch doesn't work as expected with
 multi-module projects
 * [MRELEASE-667] - Profiles activated in settings.xml can't be
 deactivated for release
 * [MRELEASE-750] - String index out of range: -1 in 
 ReleaseUtils.**loadResolvedDependencies()
 when using Parent-Module-Layout
 * [MRELEASE-755] - When passing arguments to underlying maven
 executions not all maven options are accepted
 * [MRELEASE-772] - mvn release:prepare fails with IOException and a
 write error (Access is denied)
 * [MRELEASE-775] - IllegalStateException while checking for
 modifications if multiple exclusion patterns match
 * [MRELEASE-785] - Arguments containing spaces and quotes cause the
 forked maven process to fail
 * [MRELEASE-786] - -Darguments doesn't allow -T to be passed to forked
 builds for multi threading
 * [MRELEASE-787] - release:prepare-with-pom fails when
 suppressCommitBeforeTag is used (SVN)
 * [MRELEASE-795] - Wrong level when using release:branch
 * [MRELEASE-808] - Can't generate release-pom.xml when custom
 finalName contains ${project.version}

 ** Improvement
 * [MRELEASE-559] - Clarify parameter documentation for release:branch
 * [MRELEASE-734] - When releaseVersion and developmentVersion are
 passed in command-line but are empty should be treated as not-defined
 * [MRELEASE-783] - release:update-versions should not need SCM config
 * [MRELEASE-796] - Add AbstractScmReleaseMojo

 ** New Feature
 * [MRELEASE-592] - Please allow de-activation of profiles

 ** Task
 * [MRELEASE-776] - use maven-plugin-tools' java 5 annotations


 Enjoy,

 -The Apache Maven team

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

maven-exec-plugin and VM args

[Mark Derricutt]

Hey all,

Seeing some odd behaviour with maven-exec-plugin and JVM arguments that 
seem to be eluding me. I have the following config:


plugin
groupIdorg.codehaus.mojo/groupId
artifactIdexec-maven-plugin/artifactId
version1.2.1/version
configuration
executablejava/executable
classpathScopetest/classpathScope
longClasspathtrue/longClasspath
arguments
argument-Dcom.sun.management.jmxremote -Djava.awt.headless=true -Xmx1024m
-XX:MaxPermSize=256m 
-XX:+HeapDumpOnOutOfMemoryError

/argument
argument-Xdebug 
-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005

/argument

/configuration
executions
execution
idintegration-tests/id
phasetest/phase
goals
goalexec/goal
/goals
/execution
/executions

and yet when I run the plugin, I see all the arguments being passed to 
the command line of the process, but the process never seems to setup 
the debug options, or suspend the server till I connect, or update the 
permgen.


Looking at the output of ps on my Mac everything looks like it should be 
ok   am I missing something blindingly obvious?


Cheers
Mark


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

Re: maven-exec-plugin and VM args

[Mark Derricutt]

Anders,

Mmm that sounds plausible altho so far I don't seem to see any 
difference in behaviour, my ps aux output shows


amrk 6040 0.0 5.7 4054184 478464 s000 S+ 10:53am 3:57.72 /usr/bin/java 
-Dcom.sun.management.jmxremote -Djava.awt.headless=true -Xmx1024m 
-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled 
-XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -Xdebug 
-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005 
-Dconcordion.output.dir=target/concordion 
-Dsmx3.config.dir=/Users/amrk/IdeaProjects/securemx/smx3/smx3-integration/integration/../../config 
-Dsmx3.database.host=localhost -Dsmx3.database.name=smx3 
-Dintermail.enabled=true -Dintermail.password= 
-Dintermail.url=ldap://localhost:1024 
-Dintermail.user=uid=admin,ou=system -jar 
/var/folders/vx/7v3qnlc53lgbm19_nn0g59_rgn/T/maven-exec36536174902264218.jar


which all looks like it should be starting a debug session and 
suspending. hrm.


Anders Hammar wrote:


I think I ran into something similar the other day. You need to put 
each of

the arguments in a separate argument element.

argument-Dcom.sun.management.jmxremote/argument
argument-Djava.awt.headless=true/argument
argument-Xmx1024m/argument

Re: Why does mvn compiile using java 1.3?

[Mark Derricutt]

Surely the change here is ONLY with the maven-compiler-plugin and 
affects what it puts as the --source and --target arguments to javac 
when compiler - I don't see why that should affect core?


I admit I'm not really sure how m-c-p relates down into plexus-compiler 
and the compiler infrastructure, is javac always run in the same JVM as 
the one maven runs under?


Personally - even if one is -targetting- an older JVM they should at 
least HAVE the new JVM - runs much faster IMHO.


Ron Wheeler wrote:

If you have a JRE7 VM available, then sure. If JRE7 is not available for
your platform, then it must remain possible to run Maven with an older JRE,
or else no more Maven for you. I do not know enough about Maven internals
to know if it would be feasible to increase the default source/target
version to1.7  while keeping Maven core itself compatible with1.5,  though.
 From Jochen  Stephen's exchange, it sounds like maybe not. If so, then my
vote is for Maven core to remain compatible with Java1.5,  as Stephen
suggested.


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

Re: Why does mvn compiile using java 1.3?

[Mark Derricutt]

Not would but I hazard an argument to say could, there are subtle 
API -signature- changes that make targetting older bytecode problematic, 
aka from JDK5-6 I believe there were some methods ( class escapes me now 
) that used to take a String but now take a CharSequence, source 
compatible but runtime-linker incompatible when resolving the method.


If building an older -target IMHO one should always use the toolchains 
plugin or switch the whole VM to ensure the bootclasspath of the 
compile uses the appropriate one.


If we did do this change - could we not have m-c-p make a big visible 
WARNING about not locking down the source/target like we have with 
no-versions for plugins?


Ron Wheeler wrote:

On 29/11/2012 12:48 PM, Stephen Connolly wrote:
You only get the new language features from after 1.5 if target  
1.5, so switching core to use the newer features would make core 
incompatible with running on 1.5



Not sure that I understand how this follows.

The target compiler should not determine the Java VM that Maven runs in.
I believe that I can compile 1.5 while running maven in a Java 7 VM.


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

Re: Why does mvn compiile using java 1.3?

[Mark Derricutt]

Now that Oracle are controlling Java on OSX we can no longer blame Apple - 
I'd love to see the default become Java 7 now.

And if one needs to lock down to the older versions, lock them down.


On 29/11/2012, at 7:07 AM, Curtis Rueden ctrue...@wisc.edu wrote:

 Good to know that Maven is now only 8 years behind.
 
 I blame Apple.

Re: Why does mvn compiile using java 1.3?

[Mark Derricutt]

Do users often accidentally upgrade major releases of maven without care or 
thought?


….maybe I shouldn't ask that tho :)

On 29/11/2012, at 9:47 AM, Manfred Moser manf...@mosabuam.com wrote:

 +1 even though that would trip up lots if users IMHO. 

Re: Maven is in no danger of being replaced :-)

[Mark Derricutt]

Surely Tesla's going to revolutionise the world and take over? :-)

Are there any -SNAPSHOT dists anywhere at all?

On 28/09/2012, at 6:03 AM, Jason van Zyl ja...@tesla.io wrote:

 I was curious to see what the breakdown is of Maven, Ivy and Gradle use so I 
 took the block of traffic from last week and filtered down the unique IPs per 
 tool across its versions.

Re: Version ranges not working

[Mark Derricutt]

Wait,

You're suggesting we starting encoding VERSION NUMBERING into the artefact NAME 
now? Isn't that just as bad, if not worse than the abuse of classifiers we 
already see out there?

We have the exact same issue being discussed here, and also as mentioned by 
others use OSGi. One of the key things to think of in all these situations to 
also let your artefacts work FOR you.

1) Separate out APIs from implementations - two artefacts
2) Users depend ONLY on API - NEVER implementations - mock those 
implementations for testing, or have a third fake/test impl.
3) Use composite artefacts for grouping common dependencies - a POM only 
artefact with dependencies, i.e. a testing pom that deps on testng, fest-assert 
etc. etc.
4) Often its only really the packaging/distribution that really needs the range 
to be resolved so maybe we should enhance the assembly plugin, or some other 
new packaging plugin.




On 29/09/2012, at 8:21 AM, Ron Wheeler rwhee...@artifact-software.com wrote:

 Not acceptable. If a developer is not going to provide upward compatibility, 
 then they should change the Artifact id to be sure that no one gets hurt 
 because of the laziness or lack of thoughtfulness or just plain bad design of 
 the older version.
 Major versions are not incompatible in most libraries.
 Hibernate is a good example where the developers realized that version 3 was 
 completely different from versions.
 If they wanted to have reasonably method names without the danger of people 
 getting hurt by trying to run code written to version 2 specs against version 
 3, they had to rename the artifacts.

Re: Version ranges not working

[Mark Derricutt]

This idea would require a POM change, but similar to repository definitions 
having the option of declaring release or snapshot's being enabled, maybe 
something similar could be provided for dependencies.

Or, with modifying the POM itself, we could extend the capability of the 
classifier attribute to somehow express NO CLASSIFIER which would exclude 
-SNAPSHOT, -alpha etc. etc.

Maybe classifier/ or classifier/classifier could handle that, which is 
different to it being absent.

This does beg the question of weather -SNAPSHOT is or is not a classifier or 
not - having -SNAPSHOT just be a magically part of the version and not a 
classifier has always been a bug bear, esp. with timestamp'd SNAPSHOTs breaking 
the 1-1 mapping of direction/filenames


On 29/09/2012, at 3:06 PM, Hervé BOUTEMY herve.bout...@free.fr wrote:

 I'm not comfortable with the idea of excluding SNAPSHOT from ranges: if we do 
 so, it's not a *range* any more but a range + a filter
 (1.7.1-SNAPSHOT is in [1.7,1.8] range,in plain english)

Re: Version ranges not working

[Mark Derricutt]

+1 - we've mentioned this on the IA podcast a few times in the past - compile 
against the lower bound, run against the upper bound.

How to express that however


On 30/09/2012, at 5:31 AM, Stephen Connolly stephen.alan.conno...@gmail.com 
wrote:

 In general at build time you want the lowest version in the range (assuming
 the api is versions correctly) to ensure you are compatible with the
 smallest set of api method signatures.

maven-remote-resources-plugin and version ranges

[Mark Derricutt]

Hi all,

Does anyone know if theres a way to get the maven-remote-resources-plugin to 
use version ranges to resolve the artifact to include?

It doesn't appear that the groupId:artifactId:version syntax for 
resourceBundle/ supports a range.

Mark


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

Re: maven-jar-plugin refuses to include META-INF/persistence.xml ! - Problem solved

[Mark Derricutt]

If you use the packagingbundle/packaging style in your pom, then its bnd 
that does the actual jar creation, and NOT the traditional jar plugin.

We hit this same issue awhile ago when including compiled coffee-script into 
our jars, just putting them directly in target/classes doesn't just work.

Mark

On 13/08/2012, at 2:29 AM, Tommy Svensson to...@natusoft.se wrote:

 I didn't know that the bundle-plugin affected jar:ing. I thought it just 
 packaged things correctly under target and then the maven-jar-plugin did the 
 rest. 


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

Re: Release Management with Many, Independent Projects...

[Mark Derricutt]

Step 1) Separate your API interfaces into their own bundles, with their 
own release cadence.
Step 2) Code solely against APIs, and against version ranges ( we use 
[1.0.0,2.0.0) style.


Given things in OSGi land are service/interface orientated this works well.

We try to follow the semver style of version number, changing the major 
(1.0.0-2.0.0) for backwards incompatible changes, and a minor 
(1.0.0-1.1.0) for backward compatible, but forward-incompatible 
changes.  Any downstream bundle that requires the new API changes and 
simply change their lower-bound in the range: [1.1.0,2.0.0)





On 19/06/12 1:19 PM, James Carman wrote:

We are an OSGi shop.  Thus, we have a lot of bundle projects that
have their own independent release cycles.  We have a hierarchy of
parent POMs and many utility libraries.  When we change one of the
upper-level POMs (like the base for all of our OSGi bundles), it is
very time-consuming to point all of the downstream projects at the new
version.  How do folks typically handle this?  There has to be an
easier way.  I found the versions plugin [1], but that can only get
you so far.  You still have to cut each of the releases and re-point
everyone at them.  Yuck!

[1] http://mojo.codehaus.org/versions-maven-plugin/

-
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: Which is the BEST Approach to define Global POM.XML

[Mark Derricutt]

I'm almost tempted to write an enforcer plugin to block repository 
declarations from ANY pom.  Corporate or project


On Thu Mar 15 22:09:24 2012, Anders Hammar wrote:

You should NOT declare repositories (or plugin repositories) in a
corporate pom. That should be handled in settings.xml.



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

Re: [ANN] Clirr Maven Plugin 2.4 Released

[Mark Derricutt]

For some reason I've never been able to get this plugin to actually do 
what I think it should be doing.


For example, I just commented out a method declaration in an interface, 
thinking to myself well surely THAT breaks the previous API... but 
clirr just ignores it.


I do see an odd message tho:

[INFO] --- clirr-maven-plugin:2.4:check (default-cli) @ smx3.api ---
[INFO] Comparing to version: 5.0.20

[INFO] smx3.api.ApplicationManager: Class smx3.api.ApplicationManager added

This is the interface I changed, in fact - ALL classes in the various 
artifacts list here saying added, however - since they were in the 
previous released artifact, are they really added?


Mark

PS: I probably should take this to a clirr specific list, but I'm here 
currently :)




On 12/03/12 7:27 AM, Dennis Lundberg wrote:

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




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

Re: [ANNOUNCEMENT] Maven Skins v6 have been released!

[Mark Derricutt]

Awesome.

However I see the Stylus Skin's sample site is 404ing..

-- 
Great artists are extremely selfish and arrogant things — Steven Wilson,
Porcupine Tree


On Mon, Jan 23, 2012 at 4:30 AM, Simone Tripodi simonetrip...@apache.orgwrote:

 Hi all,
 The Apache Maven team is pleased to announce the release of Apache
 Skins v6, which include

  * Maven Application Skin 1.0
 (http://maven.apache.org/skins/maven-application-skin/)
  * Maven Default Skin 1.1 (
 http://maven.apache.org/skins/maven-default-skin/)
  * Maven Classic Skin 1.1 (
 http://maven.apache.org/skins/maven-classic-skin/)
  * Maven Stylus Skin 1.4 (http://maven.apache.org/skins/maven-stylus-skin/
 )
  * Maven Fluido Skin 1.1 (http://maven.apache.org/skins/maven-fluido-skin/
 )

 Sites are up-to-date and artifacts are already available on Maven Central
 repo.

 Happy skinning!!!
 -Simo, on behalf of the Apache Maven team

 http://people.apache.org/~simonetripodi/
 http://simonetripodi.livejournal.com/
 http://twitter.com/simonetripodi
 http://www.99soft.org/

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

Re: [ANN] Apache Maven 3.0.4 released

[Mark Derricutt]

+1  Would vote again - Congrats on the release.

-- 
Great artists are extremely selfish and arrogant things — Steven Wilson,
Porcupine Tree


On Sat, Jan 21, 2012 at 7:53 AM, Manfred Moser manf...@mosabuam.com wrote:

 Great. Thanks to all involved for their efforts.

Re: WARNING: Cannot use Maven 3.0.3 with Maven Release Plugin 2.2.2 (MNG-5224)

[Mark Derricutt]

Is this still broken under the 3.0.4-RC4 builds, or just 3.0.3?


-- 
Great artists are extremely selfish and arrogant things — Steven Wilson,
Porcupine Tree


On Wed, Jan 4, 2012 at 4:18 AM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 Hi,

 I just found a regression:

 http://jira.codehaus.org/browse/MNG-5224

 I think it is serious enough to recommend users avoid using the above
 combination if you rely on properties in a settings.xml profile to GPG
 sign your releases. (i.e. anyone pushing to Central)

 -Stephen

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

Re: WARNING: Cannot use Maven 3.0.3 with Maven Release Plugin 2.2.2 (MNG-5224)

[Mark Derricutt]

Surely something as egregious as allowing releases to break should block
3.0.4 from being released tho.  As someone who uses GPG in that manner for
some of his releases I'd certainly want 3.0.4 to be able to release...

-- 
Great artists are extremely selfish and arrogant things — Steven Wilson,
Porcupine Tree

On Wed, Jan 4, 2012 at 5:23 AM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 I have checked in a fix towards 3.0.5...

 Pester olamy to backport...

 though he may want to wait for me to write the tests of the fix
 (manual testing confirms the fix... just have to figure out how to get
 automated testing!)

 On 3 January 2012 16:03, Mark Derricutt m...@talios.com wrote:
  Is this still broken under the 3.0.4-RC4 builds, or just 3.0.3?
 
 
  --
  Great artists are extremely selfish and arrogant things — Steven
 Wilson,
  Porcupine Tree
 
 
  On Wed, Jan 4, 2012 at 4:18 AM, Stephen Connolly 
  stephen.alan.conno...@gmail.com wrote:
 
  Hi,
 
  I just found a regression:
 
  http://jira.codehaus.org/browse/MNG-5224
 
  I think it is serious enough to recommend users avoid using the above
  combination if you rely on properties in a settings.xml profile to GPG
  sign your releases. (i.e. anyone pushing to Central)
 
  -Stephen
 
  -
  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: [CALL FOR TEST] Apache Maven 3.0.4-RC3 staged

[Mark Derricutt]

I'm +1ing this - have been doing releases all day without issue.

Someone did make a comment about memory usage the other day, I am seeing
OOM exceptions more often in my large reactor build under the RC, but
that's mostly Rhino stuff that has an evil leak in it.

I did see a Permgen in Javac yesterday but never saw it again
strangeness.

-- 
Great artists are extremely selfish and arrogant things — Steven Wilson,
Porcupine Tree


On Tue, Dec 6, 2011 at 3:28 AM, Olivier Lamy ol...@apache.org wrote:

 Hello,

 Apache Maven 3.0.4-RC3 has been staged for testing purpose (this is a
 preview of the coming 3.0.4 official release)

 The repository is available here:
 https://repository.apache.org/content/repositories/maven-292

 For convenience, binaries have been copied here:
 http://people.apache.org/~olamy/maven/3.0.4-RC3/

 This test phase will be for one week (until
 http://s.apache.org/MVN-3.0.4-RC3 )

 Changes are available here:

 http://jira.codehaus.org/secure/ReleaseNote.jspa?version=17215styleName=TextprojectId=10500Create=Create
 .

 Feel free to report any regressions in http://jira.codehaus.org/browse/MNG

 Have Fun,
 --
 Olivier Lamy
 Talend: http://coders.talend.com
 http://twitter.com/olamy | http://linkedin.com/in/olamy

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

Re: [ANN] Maven Archetype 2.2 Released

[Mark Derricutt]

Is this new 2.2 release included in the pending Maven 3.0.4 superpom?

-- 
Great artists are extremely selfish and arrogant things — Steven Wilson,
Porcupine Tree


On Sat, Nov 26, 2011 at 6:52 AM, Michael Heuer heue...@gmail.com wrote:

 Hello Benson,

 I'm still bothered that

 http://jira.codehaus.org/browse/ARCHETYPE-70

 hasn't been resolved.  Any chance you might be able to look at it?

 Thanks,

   michael


 On Wed, Nov 23, 2011 at 6:35 AM, Benson Margulies
 bimargul...@apache.org wrote:
  The Maven team is pleased to announce the release of the Maven
 Archtetype 2.2
 
  Architype is a collection of tools that allow you to create templates
  for maven projects.
 
  Release Notes - Maven Archetype - Version 2.2
 
 
 
  ** Bug
 * [ARCHETYPE-390] - Several parameters of the create-from-project
  mojo lack documentation
 * [ARCHETYPE-391] - The defaultEncoding parameter is never used.
 
 
  ** Improvement
 * [ARCHETYPE-382] - when selecting an archetype, display archetype
  groupId and artifactId before choosing version
 * [ARCHETYPE-387] - IntegrationTestMojo has hardcoded
  target/test-classes/projects for resources
 * [ARCHETYPE-389] - add some various options to improve how Maven
  is invoked in IntegrationTestMojo
 
  ** New Feature
 * [ARCHETYPE-383] - Use velocity expressions in descriptor properties
 * [ARCHETYPE-388] - enhance IntegrationTestMojo to be able to run
  verify script to do some asserts
 
 
  ** Task
 * [ARCHETYPE-386] - use plexus java 5 annotations instead of
  old-style javadoc annotations
 
  To use the new version, specify version '2.2' explicitly from the
  command-line or in your POM.
 
  Enjoy,
 
  -The Maven team

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

Re: maven-resources-plugin not retaining unix permissions?

[Mark Derricutt]

From memory git also doesn't support permissions as it tracks file CONTENTS
only.

-- 
Great artists are extremely selfish and arrogant things — Steven Wilson,
Porcupine Tree


On Wed, Oct 26, 2011 at 11:27 AM, Andrew Hunt andrew.h...@nab.com.auwrote:

 I have a project in which our run scripts are in src/main/resources/.  The
 code is in a GIT repo and I found out how to set the file permission include
 execute permission in GIT.