Re: Publishing to Maven Central and non-OSS plugin dependencies

[Manfred Moser]

The documentation for publishing to Central is very comprehensive. I 
suggest you take a closer look. Specifically


https://central.sonatype.org/register/central-portal/

https://central.sonatype.org/publish/producer-terms/

https://repo1.maven.org/terms.html

And maybe contact a lawyer and Sonatype if unclear.

Manfred


On 2/29/2024 8:44 PM, Stanimir Stamenkov wrote:

Fri, 1 Mar 2024, /Olivier Lamy/:


users will not be able to rebuild from sources.
is it a requirement? No real idea as already said in this thread, you 
need to ask Sonatype.
But it breaks the concept of opensource as you cannot build from the 
sources :)


The sources uploaded to Maven Central are generally not sufficient for 
a rebuild.  They are convenient for debugging and quick look up, 
however one almost always need to go to the project's website, and 
download full sources necessary for a complete build.  The project's 
website could be just a source repository with a top-level README.


I don't think Sonatype has or can have a requirement of "online 
project site available".  There are older artifacts people still rely 
on, that may never be rebuilt because the original sites are long 
gone.  Does it mean they should be removed from Maven Central, for 
example?  I think it should be mainly up to the users to decide 
whether they want to use a particular artifact.


As far as I'm aware there could be Free Open-source and Non-free 
Open-source.  I don't know if complete build instructions are 
requirement for the latter, and Open-source in general?




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

Re: Browsing Maven central buggy?

[Manfred Moser]

Well.. you cant really just show this video without pointing to more 
help. So to get started ...


https://github.com/maveniverse/mima

used with

https://www.jbang.dev/

Any other tips Tamas?

Manfred


On 2024-01-24 09:22, Tamás Cservenák wrote:

Or something like this:
https://asciinema.org/a/0dLOAfWxyxTg6zgcYSDX6FQwm

;)

T

On Wed, Jan 24, 2024 at 6:13 PM Manfred Moser 
wrote:


I suggest to use the maintained search and browse frontend from Sonatype
instead.

https://search.maven.org/ .. same as https://central.sonatype.com/

And browse at https://central.sonatype.com/search

It sits on top of the same data and is very nice indeed .. props to
Brian Fox and team btw!

Manfred

On 2024-01-24 08:57, Tamás Cservenák wrote:

Howdy,

Yes, this is a known problem, but it does not affect Maven, as it does

not

"browse".
Basically you have to go directly to the directory you are looking for,

and

not rely on HTML "index page" as that seems not maintained since a while.

T

On Wed, Jan 24, 2024 at 5:50 PM Thorsten Heit 

wrote:

Hi,

browsing Maven Central using a webbrowser seems, well, a bit buggy:

In https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-bom/
for example I only see versions 2.x up to 2.22.0 and 3.0.0-alpha1
whereas 2.22.1 and 3.0.0-beta1 both exist; they are simply not visible.

The same happens for a few other GAV coordinates such as
https://repo1.maven.org/maven2/org/apache/tika/tika-bom/3.0.0-BETA/ or



https://repo1.maven.org/maven2/me/qoomon/maven-git-versioning-extension/9.7.0

:
The directories exist, but one level above these versions are not shown.

Is this a known problem?


Thorsten

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



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




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

Re: Browsing Maven central buggy?

[Manfred Moser]

I suggest to use the maintained search and browse frontend from Sonatype 
instead.


https://search.maven.org/ .. same as https://central.sonatype.com/

And browse at https://central.sonatype.com/search

It sits on top of the same data and is very nice indeed .. props to 
Brian Fox and team btw!


Manfred

On 2024-01-24 08:57, Tamás Cservenák wrote:

Howdy,

Yes, this is a known problem, but it does not affect Maven, as it does not
"browse".
Basically you have to go directly to the directory you are looking for, and
not rely on HTML "index page" as that seems not maintained since a while.

T

On Wed, Jan 24, 2024 at 5:50 PM Thorsten Heit  wrote:


Hi,

browsing Maven Central using a webbrowser seems, well, a bit buggy:

In https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-bom/
for example I only see versions 2.x up to 2.22.0 and 3.0.0-alpha1
whereas 2.22.1 and 3.0.0-beta1 both exist; they are simply not visible.

The same happens for a few other GAV coordinates such as
https://repo1.maven.org/maven2/org/apache/tika/tika-bom/3.0.0-BETA/ or

https://repo1.maven.org/maven2/me/qoomon/maven-git-versioning-extension/9.7.0
:
The directories exist, but one level above these versions are not shown.

Is this a known problem?


Thorsten

-
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] Apache Maven Wrapper 3.1.1 Released

[Manfred Moser]

Awesome work everyone. I am glad this made it to the users from Apache now.

Manfred

Hervé Boutemy wrote on 2022-05-14 07:06 (GMT -07:00):

> The Apache Maven team is pleased to announce the release of the Apache Maven 
> Wrapper, version 3.1.1.
> 
> The Maven Wrapper is an easy way to ensure a user of your Maven build has 
> everything necessary to run your Maven build.
> 
> This is the first release of this project in its Apache Maven new home: it 
> was 
> previously maintained by community at https://github.com/takari/maven-wrapper 
> and was kindly donated to the Maven team. Thank you to all people who 
> permitted this.
> 
> See https://maven.apache.org/wrapper/ for instructions on how to use this 
> updated Maven Wrapper.
> 
> You can download the appropriate sources etc. from the download page:
> 
> https://maven.apache.org/wrapper/download.cgi
> 
> 
> Release Notes - Maven Wrapper - Version 3.1.1
> 
> ** Bug
> * [MWRAPPER-21] - Arbitrary file write during archive extraction ("Zip 
> Slip") in wrapper
> * [MWRAPPER-38] - build from source-release has different result from Git
> * [MWRAPPER-40] - Wrapper Properties File License system dependant line 
> separator
> * [MWRAPPER-41] - Goals documentation missing from site
> * [MWRAPPER-42] - maven-wrapper fails to self-update maven-wrapper.jar
> * [MWRAPPER-44] - maven-wrapper may use outdated 
> MavenWrapperDownloader.class
> * [MWRAPPER-58] - curl cannot follow 302 code when downloading wrapper jar
> 
> ** Improvement
> * [MWRAPPER-39] - release as maven-wrapper instead of maven-wrapper-parent
> * [MWRAPPER-43] - Download of jar must be quiet by default
> * [MWRAPPER-47] - Use name wrapperUrl consistently in Maven Wrapper files/
> scripts
> * [MWRAPPER-49] - add Wrapper version in mvnw/mvnw.cmd scripts
> * [MWRAPPER-51] - Refactor using Java Path API (NIO.2)
> * [MWRAPPER-53] - cygwin path tidy for java and class
> 
> ** Task
> * [MWRAPPER-56] - Remove M2_HOME from mvnw script
> 
> ** Dependency upgrade
> * [MWRAPPER-62] - Upgrade Parent to 35
> * [MWRAPPER-63] - Upgrade Parent to 36
> 
> 
> Enjoy,
> 
> -The Apache Maven team
> 
> 
> 
> -
> 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: Question for Maven Plugin developers/maintainers

[Manfred Moser]

Fair enough and good examples for using beanshell in the pom. My point was 
mostly that there are alternatives.

Also from all I understand Tamás asked about implementing part of a plugin in 
beanshell. That is what you are 
avoiding by doing it in the POM. And if you were to implement a plugin I would 
assume would also choose Java.
I know I would ;-) 


Manfred
Alexander Kriegisch wrote on 2022-01-31 16:57 (GMT -08:00):

> I am replying to Manfred rather than to Tamás, because I am only
> contributing to one plugin, and it is not using any Beanshell stuff. But
> I do use Beanshell scripting in a few projects where it is difficult too
> avoid, because I have not found any proper plugins to do what I need.
> Examples include:
> 
>   -- Using org.codehaus.mojo:build-helper-maven-plugin, goal
>  bsh-property, in order to unpack certain classes from Java 9+ JREs,
>  using the jimage executable. I am doing this in order to instrument
>  same classes and then prepend them to the bootclasspath using
>  '--path-module' in some situations. If Maven JMOD Plugin was not
>  dead, maybe that would be an alternative. But today it is not. You
>  cannot do a lot with that plugin. Besides, for the Java 8 profile
>  in the same project, I use Antrun with a simple unzip task in order
>  to extract the same classes from tools.jar. That is easier, no
>  extra BeanShell scripting needed.
> 
>   -- Using org.codehaus.mojo:build-helper-maven-plugin, goal
>  bsh-property, in order to create a marker file after some expensive
>  steps (downloading and unpacking certain dependencies in order to
>  create a specific directory structure), so that in later builds a
>  file-based property does not activate the same profile again,
>  avoiding the downloading and unpacking in later builds. Why I am
>  doing that is complicated. Basically, it is because not all the
>  files I am downloading are available on Maven Central, so I cannot
>  simply use the Dependency plugin.
> 
> An alternative to Beanshell would be Groovy scripting in the above
> cases, but pulling in heavy Groovy stuff for a little script in projects
> which otherwise do not use Groovy seems to be a bit costly.
> 
> So Beanshell as such might be dead to some people, but even I who
> otherwise claims to hate scripted builds cannot avoid it sometimes,
> basically because I am too lazy to write my own Maven plugins, because I
> do not wish to learn how to do so. Sometimes I just want to get
> something done and usually have tried 5 other ways to solve the same
> problem before yielding and resorting to Beanshell inside a POM.
> 
> -- 
> Alexander Kriegisch
> https://scrum-master.de
> 
> 
> Manfred Moser schrieb am 01.02.2022 05:12 (GMT +07:00):
> 
>> I think beanshell is long dead. Any plugin that uses it would be for a
>> very old Maven version and would need a lot of work when upgrading. So
>> we should be okay to deprecate
>> 
>> And in terms of ANT .. if there are any out there.. similar things
>> will apply and https://maven.apache.org/plugins/maven-antrun-plugin/
>> is available as escape hatch as well.
>> 
>> And there is also
>> https://maven.apache.org/plugins/maven-scripting-plugin/
>> 
>> So overall.. I would say we are ok to deprecate that support.
>> 
>> 
>> Tamás Cservenák wrote on 2022-01-28 05:52 (GMT -08:00):
>> 
>>> We'd like to get some feedback from anyone who implemented,
>>> maintained or plans to implement a Maven Plugin (Mojo):
>>> 
>>> Did any of you see a Maven Plugin that is NOT implemented in Java
>>> (but uses Ant or Beanshell scripting)?
>>> 
>>> Currently implementing Maven Plugins with these scripting solutions
>>> is possible, we are not aware of any uses of it. Hence, we would like
>>> to deprecate support for these (naturally, based on user responses).
> 
> -
> 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: Question for Maven Plugin developers/maintainers

[Manfred Moser]

I think beanshell is long dead. Any plugin that uses it would be for a very old 
Maven version and would need a lot of work when upgrading. So we should be okay 
to deprecate

And in terms of ANT .. if there are any out there.. similar things will apply 
and https://maven.apache.org/plugins/maven-antrun-plugin/ is available as 
escape hatch as well. 

And there is also https://maven.apache.org/plugins/maven-scripting-plugin/

So overall.. I would say we are ok to deprecate that support.

manfred

Tamás Cservenák wrote on 2022-01-28 05:52 (GMT -08:00):

> Howdy,
> 
> We'd like to get some feedback from anyone who implemented, maintained or
> plans to implement a Maven Plugin (Mojo):
> 
> Did any of you see a Maven Plugin that is NOT implemented in Java (but uses
> Ant or Beanshell scripting)?
> 
> Currently implementing Maven Plugins with these scripting solutions is
> possible, we are not aware of any uses of it. Hence, we would like to
> deprecate support for these (naturally, based on user responses).
> 
> Thanks in advance
> T
> 

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

Re: Maven Book recommendation

[Manfred Moser]

Just keep in mind that we have stopped maintenance on these books a long time 
ago and things like plugin versions and such are outdated. The general concepts 
and so however all still apply.

manfred

Thad Humphries wrote on 2022-01-27 16:29 (GMT -08:00):

> I started with "Maven by Example" which is free from Sonatype:
> https://books.sonatype.com/mvnex-book/reference/index.html
> 
> I worked by way though this book over two days, then using it and "Maven:
> The Complete Reference" (
> https://books.sonatype.com/mvnref-book/reference/index.html) and Apache's
> web site I began moving a library of eight projects from Ant to Maven.
> 
> Good luck!
> 
> On Thu, Jan 27, 2022 at 5:23 PM Bruno Melloni  wrote:
> 
>> It became very clear to me that my current approach of googling
>> tutorials, guides and solutions is a wildly inadequate approach to learn
>> Maven.  Mainly because all of those are either far too basic for "real
>> life" projects, or because they assume prior knowledge that I don't yet
>> have.
>>
>> So, I am looking to buy a good book to methodically learn all I need
>> about Maven.
>>
>> Because of how I learn best I would like to find a book that uses the
>> following as its presentation approach:
>>
>>   * It must be gradual, starting from the assumption that I know nothing
>> and only learn what is taught in the book.
>>   * New concepts must include sample code that I can type and test,
>> either complete code or as an extension to a previous example.
>> Absolutely no "loose snippets" that assume prior knowledge (for
>> example this is what makes most formal Spring documentation
>> completely useless to me, as I often can't follow it to a complete
>> functioning solution, and I had similar but not as severe issues
>> with the formal Apache Maven documentation).
>>   * The end of each chapter must have exercises that I can code and run
>> to test my understanding, with the ability to download the solution
>> from a website in those cases when my code fails to function correctly.
>>   * Not essential but it would be ideal if the book was available in
>> electronic form and readable through an ebook reader that functions
>> on a Microsoft Surface tablet (Windows 10/11) and remembers the last
>> page I read (even better if position syncs between the tablet and my
>> desktop so that I can continue reading on either).
>>
>> If _you learned Maven from a book that matches at least the first 3
>> criteria_, please recommend it.  I'd greatly appreciate it.
>>
> 
> 
> -- 
> "Hell hath no limits, nor is circumscrib'd In one self-place; but where we
> are is hell, And where hell is, there must we ever be" --Christopher
> Marlowe, *Doctor Faustus* (v. 111-13)
> 

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

Re: Using Maven/Aether resolver programmatically outside Maven environment

[Manfred Moser]

I wrote (and kind of still maintain) the maven repository tools .. it does 
that. Just have a look at the code.


https://github.com/simpligility/maven-repository-tools

Manfred

Shahim Essaid wrote on 2021-05-06 22:08 (GMT -07:00):

> Hi all,
> 
> I'm getting familiar with using the Maven/Aether resolver API outside the
> Maven build environment. I need help understanding what additional steps
> are needed to process the dependency graph obtained from:
> 
> org.eclipse.aether.RepositorySystem.resolveDependencies(...)
> 
> to be able to have the same resolution of the dependency as it is done
> during a maven build.
> 
> I'm working on some tooling that will be run inside a Maven project build
> (by a plugin) and outside a maven build and I need the tooling to be able
> to consume exactly the same dependency graph and artifacts.
> 
> I'm assuming I can get the same results by using the "maven-resolver" API
> and won't need additional "maven-core" APIs. Is that correct? If not, what
> else is needed?
> 
> Any hints will be much appreciated and thank you in advance.
> 
> Shahim
> 

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

Re: Advice or examples on using aether

[Manfred Moser]

- Use Maven resolver .. not aether .. aether is deprecated and replaced by 
resolver
- Check out my project https://github.com/simpligility/maven-repository-tools

Farid Zakaria wrote on 2020-08-19 16:32 (GMT -07:00):

> Hello!
> 
> I'm seeking to use aether (not through Maven plugin) to collect the
> transitive closure given a top level `pom.xml`
> 
> (I'd like the version resolution strategy to mimic however maven does it
> for transitive dependencies)
> 
> I see simple examples online that show that much however where I am stumped
> are I need additional information:
> 
> - the plugins (used by the top level pom.xml)
> - the .pom files for each dependency
> 
> I'm trying to collect the remote repository information necessary to
> reconstruct a local repo for a separate program.
> 
> Thanks in advance for your help. 
> 

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

Re: Maven Artifact Resolver Ant Tasks - Transitive Dependency Versions

[Manfred Moser]

As long as you are comparing the maven artifact resolver task using same 
version as whatever Maven and dependency plugin you are using .. the results 
will be the same.

Resolution changed over time so older Maven versions and older Maven plugin 
have these difference.

Maven Ant Tasks is VERY old and uses an very old resolving mechanism .. so all 
bets are off.

Manfred

Tim N wrote on 2020-02-26 17:27 (GMT -08:00):

> I've noticed Maven Artifact Resolver Ant Tasks resolves artifacts
> differently to both pure maven and Maven Ant Tasks.
> 
> For example, in one project I'm looking at, both pure maven and Maven Ant
> Tasks resolves a jar to be "activation-1.1.1.jar", but Maven Artifact
> Resolver Ant Tasks resolves to "activation-1.1.jar". The dependency tree
> gives the following:
> mvn dependency:tree -Dverbose -Dincludes=javax.activation:activation
> Using Maven 2 dependency tree to get verbose output, which may be
> inconsistent with actual Maven 3 resolution
> company:core:jar:1.0.0-SNAPSHOT
> \- company:model:jar:1.0.0-SNAPSHOT:compile
>\- com.sun.mail:javax.mail:jar:1.5.6:compile
>   \- javax.activation:activation:jar:1.1.1:compile (version managed
> from 1.1)
> 
> I gather pure maven does the "version managed from 1.1" change that Maven
> Artifact Resolver Ant Tasks isn't doing. Is there any way to get the same
> behavior? Can you point me to the documentation on this behavior?
> 
> The same command above without "verbose":
> mvn dependency:tree -Dincludes=javax.activation:activation
> company:core:jar:1.0.0-SNAPSHOT
> \- company:model:jar:1.0.0-SNAPSHOT:compile
>\- com.sun.mail:javax.mail:jar:1.5.6:compile
>   \- javax.activation:activation:jar:1.1.1:compile
> 
> The pure maven command I used to download the JARs is:
> mvn -U dependency:copy-dependencies -DoutputDirectory=lib-compile
> -DincludeScope=compile
> 
> In some cases, the JAR is a minor version out and the project won't compile.
> 

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

Re: repo.maven.apache.org returning 403 forbidden when running maven

[Manfred Moser]

HTTP has bee†n deprecated a while ago .. just use HTTPS.

See 

https://central.sonatype.org/articles/2019/Nov/01/announcement-insecurerepo1mavenorg/

https://central.sonatype.org/articles/2019/Apr/30/http-access-to-repo1mavenorg-and-repomavenapacheorg-is-being-deprecated/

Manfred
https://www.simpligility.com


Henke, Zachary wrote on 2019-12-30 06:04 (GMT -08:00):

> Hello,
> 
> My name is Zach Henke and I work at Verisign. I am currently receiving ERROR
> 403: Forbidden when attempting to access http://repo.maven.apache.org/maven2/
> via linux server. On that same server, I am able to access the maven website
> (http://maven.apache.org/) which indicates public internet access. I am able 
> to
> reach http://repo.maven.apache.org/maven2/ in browser from my local machine on
> a different IP/network than the linux server. These points make me think there
> is a blacklist of IPs in front of the maven repo causing the 403 Forbidden 
> from
> the linux server. Anyone know how to confirm my IP isn’t in a blacklist? Any
> other suggestions to avoid the repo 403 issue would be great.
> 
> Thanks,
> Zach
> 


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

Re: Configure default execution phase

[Manfred Moser]

What I am trying to say is that you can just add all these invocations to one 
profile and bind them to different phases or just the same phase and have them 
in order in the pom file and then you just invoke the one profile.

Plugin invocations can all be bound to specific phases in the pom and can be 
bound to a default phase in the code of the plugin.

Manfred

Stanimir Stamenkov wrote on 2019-12-24 08:47 (GMT -08:00):

> Tue, 24 Dec 2019 17:27:18 +0100 (CET), /Manfred Moser/:
> 
>> Typically a separate invocation like needing to update the data schema
>> involves more than one plugin.
>> 
>> The best and most common example is a release profile. It often includes
>> things like javadoc, signing, obfustcating, creating additional files and so
>> on. And you just run it with a profile.
>> 
>> 
>> If you truly want to invoke only the one plugin, it wont matter. But in
>> practice .. most of time it will be more than one plugin at a time.
> 
> In my use case the (liquibase) maven plugin is only used for 
> development.  The development of a new database change generally 
> involves multiple command invocations:
> 
> # Prepare source change
> mvn liquibase:update
> mvn liquibase:rollback
> # Update the change in the source, then
> mvn liquibase:updateTestingRollback
> 
> Rinse and repeat, and mix other goals into the cycle.  This would happen 
> even if the plugin is otherwise programmed into a release profile.  So 
> I've asked if it is possible to configure the default behavior to always 
> execute process-resources phase with this plugin, but seems it is 
> currently not.
> 
> -- 
> Stanimir
> 


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

Re: Configure default execution phase

[Manfred Moser]

Typically a separate invocation like needing to update the data schema involves 
more than one plugin.

The best and most common example is a release profile. It often includes things 
like javadoc, signing, obfustcating, creating additional files and so on. And 
you just run it with a profile. 


If you truly want to invoke only the one plugin, it wont matter. But in 
practice .. most of time it will be more than one plugin at a time.

Stanimir Stamenkov wrote on 2019-12-24 05:09 (GMT -08:00):

> Mon, 23 Dec 2019 21:43:36 +0100 (CET), /Manfred Moser/:
> 
>> well... with using the profile you can add more plugins and all sorts of 
>> other
>> stuff and the command will stay that long
> 
> I must admit I'm completely puzzled by your suggestion – why I would be 
> adding all sorts of stuff gaining nothing but adding complexity to the 
> build script.  Anyway, thanks for your comments.
> 
> -- 
> Stanimir
> 


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

Re: Configure default execution phase

[Manfred Moser]

well... with using the profile you can add more plugins and all sorts of other 
stuff and the command will stay that long 

Manfre

Stanimir Stamenkov wrote on 2019-12-23 09:50 (GMT -08:00):

> Mon, 23 Dec 2019 18:16:13 +0100 (CET), /Manfred Moser/:
> 
>> Just make a profile and add it all in there.
> 
> Are you suggesting adding something like:
> 
> 
> 
> liquibase-update
> 
> 
> 
> org.liquibase
> liquibase-maven-plugin
> 
> 
> process-resources
> 
> update
> 
> 
> 
> 
> 
> 
> 
> 
> 
> then using command like:
> 
> mvn process-resources -P liquibase-update
> 
> ?
> 
> It doesn't appear shorter than:
> 
> mvn process-resources liquibase:update
> 
> and I guess I'll have to replicate the profile for all possible 
> liquibase goals (possibly 5-10 of them).  All in all, it doesn't appear 
> feasible unless I'm missing something with your suggestion?
> 
> 
>> Stanimir Stamenkov wrote on 2019-12-22 09:04 (GMT -08:00):
>> 
>>> I'm having a POM like:
>>>
>>>  
>>>  
>>>  
>>>  
>>>  org.liquibase
>>>  liquibase-maven-plugin
>>>  3.8.3
>>>  
>>>  ...
>>>  
>>>  
>>>  
>>>  
>>>  
>>>
>>> I don't want the plugin executed as part of the build but I want to be 
>>> able to execute its goals [1] explicitly.  The goals get executed 
>>> directly (no build phases get triggered), f.e.:
>>>
>>>  mvn liquibase:update
>>>
>>> but then it usually (while not necessarily, depending on project 
>>> configuration) require "process-resources" to be completed, so I have to:
>>>
>>>  mvn process-resources liquibase:update
>>>
>>> Is it possible to trigger "process-resources" automatically via plugin 
>>> configuration in POM (a`la Gradle's dependsOn [2]), or this is just 
>>> hard-coded in the plugin itself?
>>>
>>> [1] https://www.liquibase.org/documentation/maven/index.html
>>> [2] https://docs.gradle.org/current/userguide/more_about_tasks.html
> 
> -- 
> Stanimir
> 
> -
> 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: Configure default execution phase

[Manfred Moser]

Just make a profile and add it all in there.

Stanimir Stamenkov wrote on 2019-12-22 09:04 (GMT -08:00):

> I'm having a POM like:
> 
> 
> 
> 
> 
> org.liquibase
> liquibase-maven-plugin
> 3.8.3
> 
> ...
> 
> 
> 
> 
> 
> 
> I don't want the plugin executed as part of the build but I want to be 
> able to execute its goals [1] explicitly.  The goals get executed 
> directly (no build phases get triggered), f.e.:
> 
> mvn liquibase:update
> 
> but then it usually (while not necessarily, depending on project 
> configuration) require "process-resources" to be completed, so I have to:
> 
> mvn process-resources liquibase:update
> 
> Is it possible to trigger "process-resources" automatically via plugin 
> configuration in POM (a`la Gradle's dependsOn [2]), or this is just 
> hard-coded in the plugin itself?
> 
> [1] https://www.liquibase.org/documentation/maven/index.html
> [2] https://docs.gradle.org/current/userguide/more_about_tasks.html
> 
> -- 
> Stanimir
> 
> -
> 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: Publishing Maven site as an docker image

[Manfred Moser]

Maven sites are just static HTML. Why would you publish that as a Docker image? 

You can of course ... just run nginx or apache httpd and put the files in the 
root web server folder.. 

Manfred

Nick Stolwijk wrote on 2019-12-23 00:58 (GMT -08:00):

> Hi folks,
> 
> Has anyone tried to publish the site generated by Maven as a docker image?
> Are there examples of such a setup?
> 
> With regards,
> 
> Nick Stolwijk
> 
> ~~~ Try to leave this world a little better than you found it and, when
> your turn comes to die, you can die happy in feeling that at any rate you
> have not wasted your time but have done your best ~~~
> 
> Lord Baden-Powell
> 


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

New Maven wrapper release

[Manfred Moser]

I just release a new version which now default to use Maven 3.6.3.

Update your projects with 

mvn -N io.takari:maven:0.7.7:wrapper

and enjoy.

More info at https://github.com/takari/maven-wrapper

Manfred

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

Re: Regression: Maven 3.6.2 breaks Tycho pomless builds

[Manfred Moser]

Yes .. we seem to be having a similar problem with polyglot-maven..

https://github.com/takari/polyglot-maven/issues/200

I have not had a chance to look at all yet, and probably wont be for a while 
either.

Manfred


Jörg Schaible wrote on 2019-09-09 05:55:

> Hi,
> 
> Maven 3.6.2 breaks builds using Tycho with pomless extension completely. 
> When it is scanning for projects I get an error message for every pomless 
> project like.
> 
> [ERROR]   The project  (/home/me/work/branches/master/plugins/
> org.vafada.swtcalendar/.polyglot.build.properties) has 1 error
> [ERROR] Non-readable POM /home/me/work/branches/master/plugins/
> org.vafada.swtcalendar/.polyglot.build.properties: input contained no data
> 
> Regards,
> Jörg
> 
> 
> -
> 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

Kotlin pom

[Manfred Moser]

Shipped 0.4.1 of polyglot-maven with more kotlin goodness ;-) 

https://www.simpligility.com/2019/06/kotlin-improvements-for-polyglot-maven/

Enjoy

Manfred

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

Re: Would it make sense to publish a WAR to maven central?

[Manfred Moser]

Yes.. publishing war files, executable jar files or install/distribution 
archives of your app and so on is all within the scope of publishing to Central

Manfred

Matthieu BROUILLARD wrote on 2019-05-30 23:09:

> Why couldn't you publish as a war?
> AFAIK Central is not restricted to be a jar library.
> You can already find wars in central :
> https://search.maven.org/search?q=p:war
> 
> Regards
> 
> Matthieu
> 
> On Thu, May 30, 2019 at 2:40 PM Russell Gold 
> wrote:
> 
>> The open source Weblogic Monitoring Exporter <
>> https://github.com/oracle/weblogic-monitoring-exporter> is a set of
>> servlets that works as an exporter for Prometheus. Building it involves two
>> steps: one build compiles the servlets and the second assembles them into a
>> WAR, in which a configuration file is embedded. Currently, users clone the
>> repository and run both builds, but that means that they generally work
>> with the latest commits. I am thinking that it makes more sense to publish
>> it to maven central, but am looking for guidance. Is it customary to
>> publish WARs to central? In such a case, I would combine the builds, and a
>> simple shell command or script could supply the configuration. Or would it
>> be best to publish the JAR containing the servlets and have users run the
>> second build to create the WAR?
>>
>> Thanks,
>> Russ
> 


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

Re: polyglot extension pom.yml fails to build parent and nested children projects from scratch

[Manfred Moser]

Thats a known issue with the polyglot support. Not sure if it still exists with 
the latest release ..please test and if yes file a bug and send a PR with a fix.

https://github.com/takari/polyglot-maven

manfred

Adam Hardy wrote on 2019-05-17 04:24:

> Hi Listers
> 
> I just converted a project over to polyglot yml poms. It is a new project
> anyway, so it's really quite simple, just a parent pom and two child projects
> and our team has been sharing it via git but nobody has packaged it or
> installed the jars anywhere. We've just been testing stuff and that's it.
> 
> So I was surprised after converting the poms to yml that suddenly my IDE
> couldn't build it anymore and started complaining that it couldn't find the
> parent artifact in the local repo.
> 
> After tearing my hair out thinking I'd done something wrong, I figured I'd
> prove that I can actually fork a maven project from git into my IDE without
> needing to do a "mvn install" (which I actually can't do anyway because of 
> this
> bug).
> 
> I created the minimal viable directories and pom.xml files and it worked.
> 
> I then created the minimal viable pom.yml files and no deal.
> 
> [FATAL] Non-resolvable parent POM for
> com.umusic.testing:test-child-1:0.0.1-SNAPSHOT: Failure to find
> com.umusic.testing:test-parent:pom:0.0.1-SNAPSHOT in
> http://maven-repository.umpgapps.com:8082/nexus/content/groups/public was
> cached in the local repository, resolution will not be reattempted until the
> update interval of Nexus has elapsed or updates are forced and
> 'parent.relativePath' points at wrong local POM @
> 
> While writing this email (rubber-ducking!) I noticed the tail end of the error
> message about the wrong relative path.
> 
> So I added:
> 
> parent:
>  relativePath: ../pom.yml
> 
> in the child projects' poms, and it worked.
> 
> In XML poms, no relativePath is required.
> 
> Thought I'd flag this one up.
> 
> Regards
> Adam
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


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

Re: [VOTE] Retired Maven Artifact Resolution API (Maven2)

[Manfred Moser]

+1 

Robert Scholte wrote on 2019-05-08 11:25:

> Hi,
> 
> The Apache Maven project consist of about 100 (sub)projects. Due to the small
> number of volunteers and the huge amount of code to maintain we're missing
> enough space to make real progress on all these projects, including
> our ambitious ideas for the next major version(s) of Maven itself.
> To be able to gain more focus we need to criticize the current subprojects and
> decide if it is worth maintaining.
> 
> The Maven Artifact Resolution API (maven-artifact-resolver) is a shared
> component that could be used to easily resolve Maven project dependencies. The
> last (and only) released version is 1.0 in September
> 2009.( https://maven.apache.org/shared/maven-artifact-resolver/
> [https://maven.apache.org/shared/maven-artifact-resolver/] ).
> This library should not be confused with Artifact Resolver (maven-resolver),
> previously known as Aether. As you can see the naming will cause confusion.
> The library that aims the same goal for Artifact Resolver is another shared
> component called maven-artifact-transfer (which by now is not just the 
> transfer
> part or Artifact Resolver, but a bridge for both Sonatype Aether as used in
> Maven 3.0.x and Eclipse Aether as used in Maven 3.1.x+. This way Maven plugins
> and extensions can be compatible with any Maven 3 release)
> 
> I therefore propose that we retire the maven-artifact-resolver.
> 
> I don't think it makes sense to do a final release. Instead we should update
> the documentation and the freeze the codebase.
> 
> The process for retiring a plugin is described here:
> https://maven.apache.org/developers/retirement-plan-plugins.html
> [https://maven.apache.org/developers/retirement-plan-plugins.html]
> 
> The vote is open for 72 hours.
> 
> [ ] +1 Yes, it's about time
> [ ] -1 No, because...


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

Re: [VOTE] Retire Maven Repository Plugin

[Manfred Moser]

+1

Robert Scholte wrote on 2019-04-23 12:43:

> Hi,
> 
> The Apache Maven project consist of about 100 (sub)projects. Due to the small
> number of volunteers and the huge amount of code to maintain we're missing
> enough space to make real progress on all these projects, including
> our ambitious ideas for the next major version(s) of Maven itself.
> To be able to gain more focus we need to criticize the current subprojects and
> decide if it is worth maintaining.
> 
> One of those subprojects is the maven-repository-plugin, last released on
> February 22, 2015. It's main purpose: a plugin that can be used to create
> bundles of artifacts that can be uploaded to the central repository.
> Based on that it seems that the maven-assembly-plugin is a better fit for 
> that.
> 
> I therefore propose that we retire the maven-repository-plugin.
> 
> I don't think it makes sense to do a final release. Instead we should update
> the documentation and the freeze the codebase.
> 
> The process for retiring a plugin is described here:
> https://maven.apache.org/developers/retirement-plan-plugins.html
> 
> The vote is open for 72 hours.
> 
> [ ] +1 Yes, it's about time
> [ ] -1 No, because...


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

Maven Wrapper updated to Apache Maven Version 3.6.1

[Manfred Moser]

I just cut a new release of maven wrapper and the plugin for installing it. It 
now defaults to the shiny new 3.6.1

Enjoy

manfred

Karl Heinz Marbaise wrote on 2019-04-13 03:03:

> The Apache Maven team is pleased to announce the release of the Apache
> Maven 3.6.1.
> 
> Apache Maven is a software project management and comprehension tool.
> Based on the concept of a project object model (POM), Maven can manage a
> project's build, reporting and documentation from a central piece of
> information.
> 
> You can find out more about Apache Maven at https://maven.apache.org
> 
> You can download the appropriate sources etc. from the download page:
> https://maven.apache.org/download.cgi
> 
> Release Notes - Apache Maven Version 3.6.1
> 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12344378=12316922
> 
> Code Contributors of this release:
> 
>  * Gabriel Belingueres (indirectly via plexus-utils PR)
>  * Michael Istria
>  * Michael Istria
>  * Guy Brand
>  * Fabiano C. de Oliveira
>  * Michael Istria
> 
> Issue Reporters of this release:
> 
>  * Ondra Žižka
>  * Matthias Scmalz
>  * Andreas Sewe
>  * Christian Aistleitner
>  * Jin Kwon
>  * Christoph Etzel
>  * Dawid Weiss
>  * Gene Smith
>  * Patrik Jetzer
>  * Rohan Padhye
>  * Elliotte Rusty Harold
>  * Andreas Veithen
>  * Olaf Otto
>  * Michael Istria
>  * Michael Istria
>  * Michael Istria
>  * Romain Manni-Bucau
>  * Guy Brand
>  * Rohan Padhye
>  * Olaf Otto
>  * Gunnar Wagenknecht
>  * Viacheslav Yakunin
> 
> Many thanks to contributors and reporters for the support and time.
> 
> Participants to the VOTE of the Maven 3.6.1 Release:
> 
>  * Gabriel Belingueres
>  * Francois Papon
>  * Eric Lilja
> 
> 
> Many thanks to those who tested the Maven releases
> and thanks for their support as well.
> 
> (Please send an email to the dev list if we missed one to mention).
> 
> Release Notes for Apache Maven 3.6.1
> 
> 
> https://maven.apache.org/docs/3.6.1/release-notes.html
> 
> Bugs:
>  * [MNG-5705] - NPE on parallel build in
> BuilderCommon.handleBuildError(BuilderCommon.java:147)
>  * [MNG-5965] - Parallel build multiplies work if multiple goals are given
>  * [MNG-5995] - Maven itself cannot run without maven-compat
>  * [MNG-6256] - Maven script can break if “-f” path contains special
> characters
>  * [MNG-6261] - Relative parent POM resolution failing in 3.5.0 with
> complex multimodule builds
>  * [MNG-6262] - getCanonicalFile() is not used consistently during
> project resolution
>  * [MNG-6346] - … was unexpected at this time when using -f option and
> path contains brackets
>  * [MNG-6374] - ModelBuilder hangs with malformed pom.xml
>  * [MNG-6429] - Integration Test site publishing requires Java 7 (or
> javadoc errors ignored)
>  * [MNG-6495] - ModelResolver cannot be null
>  * [MNG-6505] - child.(x.y).inherit.append.path value should be inherited
>  * [MNG-6506] - Mojos are unable to load package annotations on Java >= 9
>  * [MNG-6529] - ProjectBuilder.build(List projects, boolean,
> ProjectBuildingRequest) doesn’t honor
> ProjectBuildingRequest.isResolveDependencies()
>  * [MNG-6530] - Regression in ProjectBuilder when file change between
> invocations (introduced by MNG-6311)
>  * [MNG-6533] - ProjectBuilder.build(list_of_projects,...) does not
> contain MavenProject in exception report
>  * [MNG-6543] - Upgrade plexus classworld to support java 9+
> ClassLoader.findClass(String moduleName, String name) in Mojos
>  * [MNG-6558] - ToolchainsBuildingResult event is not sent on EventSpy
>  * [MNG-6577] - pom.xml: Uncaught IllegalArgumentException when parsing
> unicode entity ref
>  * [MNG-6590] - DefaultProjectArtifactsCache
> java.lang.IllegalStateException: Duplicate artifact resolution result
>  * [MNG-6599] - unknown version in model id when version is defined
> from parent
> 
> Improvements:
> 
>  * [MNG-6059] - Important use cases not covered, as
> child.inherit.append.path affects all children
>  * [MNG-6159] - Child path adjustments break git scm urls
>  * [MNG-6213] - Maven doesn’t check the validity of scope value
>  * [MNG-6481] - Allow to compile and test Maven with Java 11
>  * [MNG-6513] - Replace depreated Plexus javadoc tags with annotations
> in ITs
>  * [MNG-6515] - Fix javadoc build errors under Java 8 and 11
>  * [MNG-6520] - Update assembly descriptors to 2.0.0
>  * [MNG-6522] - Prepare Maven’s Core Integration Test Suite to test
> with Java 12 and 13-ea
>  * [MNG-6572] - use int or long instead of BigIntegers for little
> numbers in ComparableVersion
>  * [MNG-6593] - track input location for super-pom
>  * [MNG-6597] - add input location tracking for plugins configuration
>  * [MNG-6600] - add input location tracking for default lifecycle
> bindings executions
>  * [MNG-6601] - add input location tracking for site’s reportPlugins
> injected by reports conversion
>  * [MNG-6605] - Allow to suppress download messages in interactive mode
>  * [MNG-6611] - Update 

Re: Kotlin for your pom

[Manfred Moser]

Supposedly IntelliJ Idea has good support for Kotlin DSL usage already. There 
is an experimental support feature for Eclipse that used to work for some 
dialects, but I have not tried it recently.

I am not sure about other dialects or IDEs to be honest. 

If you find out anything while playing around, I would love to update the docs 
with a PR from you ;-) 

Manfred

Oliver B. Fischer wrote on 2019-03-30 08:59:

> Hi Manfred,
> 
> do you know far Polyglot Maven is already supported by the various IDE?
> 
> Bye,
> 
> Oliver
> 
> Am 30.03.19 um 05:50 schrieb Manfred Moser:
>> Hi all,
>> 
>> Just a quick heads up that the new polyglot-maven release I cut recently
>> features a MUCH improved support for Kotlin. So with the help of
>> polyglot-maven you can write your pom in yaml, ruby, scala, kotlin and a 
>> bunch
>> of other formats now. 
>> 
>> Check it out and send us any feedback ...
>> 
>> https://www.simpligility.com/2019/03/kotlin-for-polyglot-maven/
>> 
>> https://github.com/takari/polyglot-maven
>> 
>> Manfred
>> 
>> 
>> 
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
> 
> -- 
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fisc...@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fisc...@jabber.org
> X http://xing.to/obf
> 
> 


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

Maven Repository Provisioner 1.4.0

[Manfred Moser]

Just a quick heads up for those of you interested in targeted artifact and 
dependency migration between repositories and repository managers.

I cut a new release for the Maven Repository Provisioner with some new features 
and dependency updates and blogged about it on my site..

https://www.simpligility.com/2019/04/maven-repository-provisioner-1-4-0/

Hth

Manfred

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

Kotlin for your pom

[Manfred Moser]

Hi all,

Just a quick heads up that the new polyglot-maven release I cut recently 
features a MUCH improved support for Kotlin. So with the help of polyglot-maven 
you can write your pom in yaml, ruby, scala, kotlin and a bunch of other 
formats now. 

Check it out and send us any feedback ...

https://www.simpligility.com/2019/03/kotlin-for-polyglot-maven/

https://github.com/takari/polyglot-maven

Manfred






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

Update to the new Maven wrapper

[Manfred Moser]

Hi all,

Just wanted to give you a heads up about the recent Maven wrapper and plugin 
releases. 

https://www.simpligility.com/2019/03/recent-maven-wrapper-updates/

Some pretty nice features worth checking out imho.

Go update your projects to this latest version!

Manfred

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

Re: Repository and Dependency

[Manfred Moser]

Best practice is to do it with a repository manager.

Or settings.xml

Or worst case .. pom.xml

Manfred

Eng. Bilal Ghayad wrote on 2018-11-15 17:11:

> Hello All;
> 
> 
> 
> I need to add a class file that is required to be able to add combobox in
> vaadin grid and it is mentioned the requirements to be added in the
> dependency and in the repository.
> 
> I know that dependency can be added in the pom.xml but where I will add the
> repository?
> 
> Below is the requirements for this class:
> 
> 
> 
> 
> 
>   de.datenhahn.vaadin
> 
>   componentrenderer
> 
>   2.0.0
> 
> 
> 
> 
> 
> 
> 
> 
>   vaadin-addons
>   http://maven.vaadin.com/vaadin-addons
> 
> 
> 
> 
> 
> 
> Regards
> 
> Bilal
> 
> 


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

Re: How do I skip site-generation for modules?

[Manfred Moser]

You can use the skip parameter in the individual modules..

https://maven.apache.org/plugins/maven-site-plugin/site-mojo.html#skip

That said ... I think since you want some resources from the you are better off 
NOT skipping but instead just making it work for the multi module setup.

You just need to fix up naming of folder and artifact id and a few paths. Its 
definitely possible to do this.. 

Manfred

Russell Gold wrote on 2018-11-08 11:11:

> And at the same time, I would like to copy to the site directory some files
> that were generated during the build (and are now in one of the module jars). 
> 
>> On Nov 8, 2018, at 1:31 PM, Russell Gold  wrote:
>> 
>> I want to generate a site for my multi-module project only from the 
>> top-level.
>> How do I tell maven to skip running the site plugin on each module?
> 
> 
> -
> 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: Differenz between mvn clean install and mvn clean install deploy

[Manfred Moser]

The difference is that the first invocation is just simply wrong. When you call 
a mvn lifecycle phase it will run through all prior phases. If you specify 2 
lifecycle phase from the same lifecycle (the default cycle) .. you run through 
things twice.. 

E.g. 

mvn install 

runs 

initialize, .. validate ..  compile,  install

mvn deploy

runs

initialize, .. validate ..  compile,  install deploy


So when you use

mvn install deploy 

you get

initialize, .. validate ..  compile,  install .. initialize, .. validate .. 
 compile,  install .. deploy

As you can see you duplicate a whole lot of stuff and that lead to confusing 
results and issues.

So .. just do that and learn more about Maven lifecycle phases and such.. 

Manfred



Oliver B. Fischer wrote on 2018-09-17 14:53:

> Hi all,
> 
> I stumbled on a strange problem with Maven. Therefore I would like to 
> know if the following commands should have the same result or not:
> 
> 1. mvn clean install deploy
> 2. mvn clean deploy
> 
> Best,
> 
> Oliver
> 
> 
> -
> 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 assembly Plugin - ignore pom packaging

[Manfred Moser]

You should NOT have a plugin execution defined in a pom packaging project if it 
works as an aggregator. Instead just define it in pluginManagement and add it 
where you want the exection to be happening.

Manfred

Rahamim, Ben wrote on 2018-05-23 02:03:

> Hi all,
> 
> TL;DR – why isn’t a flag in the Maven assembly Plugin allowing to skip POMs
> with packaging “pom” ?
> 
> I have a question about using the Maven assembly Plugin.
> 
> We have a parent POM, called “super-parent”, which is being used as a
> parent to all of our projects. It includes all of the dependencies & the maven
> assembly plugin, set to create a tar.gz.
> 
> One of its children the “runtime-super-parent”, which all of the other
> projects use as a parent, and it has “pom” as packaging type, as required.
> Now, even though we don’t need it, the assembly plugin creates a tar.gz to
> this POM as well, taking a lot of space in our repositories.
> 
> The logical thing to me was to have a flag allowing us to exclude the pom
> packaged projects from the plugin, hence the name “pom” packaging.
> 
> Is there any way to achieve this? I haven’t found one.
> 
> Thanks in advance,
> Ben
> 


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

Re: Maven JAVA_HOME

[Manfred Moser]

You probably want to make sure the operating system JDK is the same. Depending 
on OS that is different .. 

Manfred

Preston, Dale wrote on 2018-03-20 11:13:

> On my server, I have JAVA_HOME set to jdk1.8.0_161.0.  When I execute echo
> $JAVA_HOME, it shows the right path to my jdk1.8.0_161.0.  When I run java
> -version, it shows the right version 8 as well.
> 
> When I run maven -version, it shows this:
> 
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
> 2018-02-24T13:49:05-06:00)
> Maven home: /opt/maven/latest
> Java version: 1.8.0_161, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/jdk1.7.0_79/jre
> 
> Note the Java home path to the wrong version but Java version shows the right
> version.
> 
> Any tips on where Maven is getting that jdk1.7.0_79/jre path?
> 
> 


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

Polyglot Maven 0.3.0 released

[Manfred Moser]

Hi all,

Just a quick heads up that a new version of Polyglot Maven has been released 
with various fixes and the experimental addition of a Java dialect. 

With polyglot Maven you can use Groovy, Scala, Ruby, YML, XML, Java, Atom and 
Clojure to write your POM file.

Find out more on our site.

https://github.com/takari/polyglot-maven

Manfred

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

Re: Is it poor practice to use Maven repo (ie: Nexus) to store non maven artifacts?

[Manfred Moser]

I think it is a common and good practice. Specifically if you take advantage of 
using a good structure in terms of the use GAV coordinates and release 
versioning. And also with regards to potentially restricting access based on 
that.. 

manfred

Eric B wrote on 2017-11-26 11:36:

> I have a need to store some binary objects (ex: zip files) in a central
> repository that can be easily accessed by a build or deployment system.
> Both Chef and/or Docker need access to these binary objects in order to
> build out the environment needed for my application.
> 
> The binary objects are not code or libraries.  They are purely a zip file
> of static resources (ex: gifs or help documentation/templates/etc, GeoIP
> database, etc).  I need them somewhere centrally accessible so that my
> deployment system can easily retrieve them and explode them in the
> container/environment to make accessible to my application.
> 
> At the moment, they are being hosted in a "raw" Nexus repo.  But the
> problem with a raw repo is that there is no classification of
> artifacts/versioning/etc.  So I am considering giving them all a GAV id and
> putting it in the Maven repo as a maven artifact.
> 
> But is this poor practice?  I've always considered Maven artifacts as
> "code-related" - that is artifacts that are the output of some code
> development.  Could be compiled sources, javadocs, generated artifacts,
> etc.  But putting in these static binaries just seems "wrong".  However, I
> don't really see a good alternative.
> 
> I realize that this "can" be done.  I guess my question is rather "should"
> it be done?  How is everyone else handling these types of resources?
> 
> Thanks,
> 
> Eric
> 


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

Re: Maven-Indexer 6.0 Release

[Manfred Moser]

+1 .. imho before the release .. 

Manfred

Tamás Cservenák wrote on 2017-11-24 06:54:

> Hi,
> 
> All merged, but there is one more thing:
> 
> I'd like to fully reformat indexer codebase to maven codestyle before
> release:
> https://github.com/apache/maven-indexer/pull/23
> (not much to see, but someone eyeball please)
> 
> Main reason is not only annoying checkstyle errors (this PR gets rid of
> most but not all of them, javadoc ones still remain :), but also to align
> formatting of sources, makes IDEs not loose their sanity. Currently we have
> one pending PR (the lucene 7) but rebasing it against master (once this
> reformat PR is merged) should be easy, if the other problems are fixed.
> 
> Am not "blocking" the release with reformat -- so am fine doing 6.0 without
> it --, but i think would be "nice thing to do", and would ease later PR
> reviews too, by having codestyle aligned across whole project.
> 
> WDYT?
> 
> T
> 
> On Fri, Nov 24, 2017 at 11:01 AM Olivier Lamy  wrote:
> 
>> sounds good!
>> Thanks!
>> Olivier
>>
>> On 24 November 2017 at 02:14, Tamás Cservenák  wrote:
>>
>> > Hi there,
>> >
>> > I think with this PR 6.0 should be ready to go:
>> > https://github.com/apache/maven-indexer/pull/21
>> >
>> > Then, we can "jump" to 7 :)
>> > - make it java8
>> > - consume the lucene update PR
>> > https://github.com/apache/maven-indexer/pull/19
>> >
>> >
>> > WDYT?
>> >
>> >
>> > On Tue, Nov 21, 2017 at 3:13 PM Andreas Sewe <
>> > s...@st.informatik.tu-darmstadt.de> wrote:
>> >
>> > > Hi,
>> > >
>> > > > I am "ressurecting" an old topic. I wonder if it is possible to
>> > have
>> > > some news for 6.0 release of maven indexer.
>> > > >
>> > > > The old version of maven indexer make a plugin fail at runtime
>> with
>> > > maven 3.1.1+  (see [2]). And works well with 6.0.
>> > >
>> > > FWIW, I'm also quite keen on proper release of 6.0 (currently working
>> > > with a locally-built 6.0 snapshot).
>> > >
>> > > Best wishes,
>> > >
>> > > Andreas
>> > >
>> > >
>> > >
>> > > --
>> > Thanks,
>> > ~t~
>> >
>>
>>
>>
>> --
>> Olivier Lamy
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
> -- 
> Thanks,
> ~t~
> 


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

Re: Maven Docker Images

[Manfred Moser]

No. As you can see from the github URL this is NOT an apache URL.

https://github.com/carlossg/docker-maven


Mike Drob wrote on 2017-10-18 16:32:

> Hello,
> 
> Are the images at https://hub.docker.com/r/_/maven/ considered to be official
> maven docker images and blessed/published by the PMC?
> 
> Thanks,
> Mike
> 
> -
> 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: Version Information needed.

[Manfred Moser]

The version for the cobertur and any other non-core plugin is set in the pom of 
your project (or a parent of it). You can see the version in the log output of 
an invocation of it (typically your normal build log)

manfred

jayant sable wrote on 2017-09-19 05:06:

> Hey folks,
> 
> I'm using maven 3.2.5 and with that I'm using cobertura-maven-plugin to
> generate code coverage report.
> 
> I want to know which version of cobertura-maven-plugin is used in maven
> 3.2.5??
> How can I do that.
> 
> Thanks.
> 


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

Re: If anyone ever wanted to download a bunch of deps specified in a Maven POM for an Ant build

[Manfred Moser]

Why not use the Maven Resolver (formerly Eclipse Aether) Ant Tasks? 

https://maven.apache.org/resolver-archives/resolver-ant-tasks-LATEST/

Paul Hammant wrote on 2017-06-11 11:53:

> If your 'current directory' is a Maven checkout, I have a Python script
> that will download the dependencies into a libs/ folder. Well,
> libs/compile/ libs/test/ etc - one subfolder per scope.
> 
> See here:
> https://github.com/paul-hammant/spring-jetty-integrationtest-ant-example/blob/master/mavdl.py
> 
> I asked a question on Stackoverflow then answered it myself when my bash
> skills fell short of a bash one-liner for the same: -
> https://stackoverflow.com/questions/44390253
> 
> In the case of my demo project 'spring-jetty-integrationtest-ant-example' I
> checked all the jars into Git again, like it was still the early 2000's :)
> 
> - Paul
> 


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

Takari Maven Wrapper and Plugin

[Manfred Moser]

Hello all,

We are pleased to announce a new release of the Maven Wrapper (0.2.1) and the 
Takari Maven Plugin (0.4.1) with the helping wrapper goal to install the Maven 
Wrapper in your project.

The new release brings numerous changes that bring the wrapper up to using 
Maven 3.5.0, add support for numerous shell systems and operating systems and a 
number of other improvements.

Please have a look at the changelogs and documentation in both repositories for 
further information on changes, usage and more.

https://github.com/takari/maven-wrapper
https://github.com/takari/takari-maven-plugin


Manfred and numerous other helpers

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

Re: Maven Shell

[Manfred Moser]

jline3 integration is in the works right now. 

https://github.com/jdillon/gshell/pull/8

manfred

Paul King wrote on 2017-04-20 16:08:

> OK, cool. Is the jline3 integration likely before the final?
> 
> Cheers, Paul.
> 
> On Fri, Apr 21, 2017 at 8:05 AM, Manfred Moser <manf...@simpligility.com>
> wrote:
>> This is a snapshot (=development) build - so no.
>>
>> Manfred
>>
>> Paul King wrote on 2017-04-20 14:30:
>>
>>> Nice Jason. Is it available via sdkman?
>>>
>>> Cheers, Paul.
>>>
>>> On Thu, Apr 20, 2017 at 4:08 PM, Jason Dillon <ja...@planet57.com> wrote:
>>>> Folks, just a quick not that I’ve updated Maven Shell for the latest
>>>> release, can be found with the latest SNAPSHOT:
>>>>
>>>> https://oss.sonatype.org/content/repositories/snapshots/com/planet57/maven/shell/dist/mvnsh-assembly/1.2.0-SNAPSHOT/
>>>>
>>>> Locally seems to be fully functional.  I’ve been updating GShell (which
>>>> mvnsh is based on) as well.
>>>>
>>>> I’m considering augmenting the release versions of mvnsh to match the
>>>> upstream versions.
>>>>
>>>> I’m also eventually gonna update the jline support as I think jline3 is
>>>> much
>>>> much improved, thanks to gnodet, but I haven’t done that yet.
>>>>
>>>> If there are folks that may still be using older versions of the shell,
>>>> I’d
>>>> like to ask them to test the latest SNAPSHOTS and report back any issues.
>>>>
>>>> Cheers,
>>>>
>>>> —jason
>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


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

Re: Maven Shell

[Manfred Moser]

This is a snapshot (=development) build - so no.

Manfred

Paul King wrote on 2017-04-20 14:30:

> Nice Jason. Is it available via sdkman?
> 
> Cheers, Paul.
> 
> On Thu, Apr 20, 2017 at 4:08 PM, Jason Dillon  wrote:
>> Folks, just a quick not that I’ve updated Maven Shell for the latest
>> release, can be found with the latest SNAPSHOT:
>>
>> https://oss.sonatype.org/content/repositories/snapshots/com/planet57/maven/shell/dist/mvnsh-assembly/1.2.0-SNAPSHOT/
>>
>> Locally seems to be fully functional.  I’ve been updating GShell (which
>> mvnsh is based on) as well.
>>
>> I’m considering augmenting the release versions of mvnsh to match the
>> upstream versions.
>>
>> I’m also eventually gonna update the jline support as I think jline3 is much
>> much improved, thanks to gnodet, but I haven’t done that yet.
>>
>> If there are folks that may still be using older versions of the shell, I’d
>> like to ask them to test the latest SNAPSHOTS and report back any issues.
>>
>> Cheers,
>>
>> —jason
>>
> 
> -
> 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 Shell

[Manfred Moser]

Thanks Jason. This is great. For those that don't know 

mvnsh is a shell environment that has a JVM with Maven constantly running so 
you will get nice performance and usability improvments on the command line. 
This new version is using Maven 3.5.0.

Installation is easy - extract the archive and put the bin folder on your path.

More details and filing issues and so on at

https://github.com/jdillon/mvnsh

And from my testing so far .. it rocks. Try it out!

Manfred

Jason Dillon wrote on 2017-04-19 23:08:

> Folks, just a quick not that I’ve updated Maven Shell for the latest release,
> can be found with the latest SNAPSHOT:
> 
> https://oss.sonatype.org/content/repositories/snapshots/com/planet57/maven/shell/dist/mvnsh-assembly/1.2.0-SNAPSHOT/
> 
> Locally seems to be fully functional.  I’ve been updating GShell (which
> mvnsh is based on) as well.
> 
> I’m considering augmenting the release versions of mvnsh to match the
> upstream versions.
> 
> I’m also eventually gonna update the jline support as I think jline3 is much
> much improved, thanks to gnodet, but I haven’t done that yet.
> 
> If there are folks that may still be using older versions of the shell, I’d
> like to ask them to test the latest SNAPSHOTS and report back any issues.
> 
> Cheers,
> 
> —jason
> 
> 


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

Re: Maven 3.5.0 and the versions plugin

[Manfred Moser]

Yeah. Provided you have tested this with the latest version of the versions 
plugin and it still shows that problem... 

Mark Eggers wrote on 2017-04-13 14:00:

> Folks,
> 
> I'm working on upgrading an environment to maven 3.5.0. With
> prerequisites in pom.xml, I get the expected message:
> 
>   [WARNING] The project org.mdeggers:CSEquity:war:1.0-SNAPSHOT
>   uses prerequisites which is only intended for maven-plugin projects
>   but not for non maven-plugin projects. For such purposes you should
>   use the maven-enforcer-plugin. See
>   https://maven.apache.org/enforcer/enforcer-
>   rules/requireMavenVersion.html
> 
> I then remove the prerequisites tag and replace it with the
> appropriately configured enforcer plugin. The project builds cleanly.
> 
> However, one of the things that we do in Jenkins is run a series of mvn
> versions:display--updates (plugins, dependencies) and mail the
> results to developers.
> 
> When I run mvn versions:display-plugin-updates, I get the expected
> output as well as the following:
> 
>   [WARNING] Project does not define minimum Maven version, default is:
>   2.0
> 
>   [ERROR] Project does not define required minimum version of Maven.
>   [ERROR] Update the pom.xml to contain
>   [ERROR] 
>   [ERROR]   3.0
>   [ERROR] 
> 
> Is there a way to resolve this? Should I file an issue with the maven
> versions plugin?
> 
> . . . just my two cents
> /mde/
> 
> 


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

Re: Maven central and indexing

[Manfred Moser]

Laird Nelson wrote on 2017-03-10 13:03:

> On Fri, Mar 10, 2017 at 12:23 PM Bernd Eckenfels 
> wrote:
> 
>> Hello,
>> Related:
>> http://blog.sonatype.com/2008/12/central-repository-downloading-the-nexus-index/
>> And especially the news of a public available dataset (by Google):
>> http://takari.io/2015/10/28/google-maven-central.html
> 
> 
> Thank you!  I'm aware of the Nexus index, though I haven't probed it
> deeply; perhaps it has more that the simple GAV-oriented index exposed by
> search.maven.org (if it does not, then it doesn't solve my problem).

It does not.. 

> I am also not sure I'm smart enough to grok all the implications of the
> Google-related post.  That itself still does not expose an index, say, of
> the contents of all MANIFEST.MF files, right?  Do I read properly that such
> tools are in development, and to the best of everyone's knowledge an index
> of the contents of the contents :-) of Maven central does not exist?

No publically available one at this stage that I am aware of.. 

manfred

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

Re: Download an artifact and its dependencies without a pom.xml

[Manfred Moser]

I have a similar tool that can be used to provision from and to a repository. 

https://github.com/simpligility/maven-repository-tools/tree/master/maven-repository-provisioner

hth

Manfred

Curtis Rueden wrote on 2017-03-02 14:29:

> Hi everyone,
> 
>> My use case is that I want to run a class from a Maven artifact.
> 
> I turned my "synthesize a dummy POM" approach into a full-blown shell
> script called jrun [1].
> 
> You can use it to conveniently run Java code from any remote Maven
> repository. For example, to spin up the Jython REPL:
> 
>$ jrun org.python:jython-standalone
> 
> If you add the ImageJ Maven repository to your ~/.jrunrc:
> 
>[repositories]
>imagej.public = https://maven.imagej.net/content/groups/public
> 
> Then you can launch ImageJ (https://imagej.net/):
> 
>$ jrun net.imagej:imagej
> 
> Or even the entire Fiji distribution of ImageJ (https://fiji.sc/), which as
> of this writing consists of 346 components!
> 
>$ jrun sc.fiji:fiji:LATEST
> 
> All without explicitly downloading or installing anything apart from Maven
> and this one shell script [2].
> 
> If anyone knows a better / standard / best-practices way of doing this,
> please let me know! But I am pretty pumped about how convenient this is. I
> hope that jrun is useful to other developers too.
> 
> Regards,
> Curtis
> 
> P.S. If the Mojohaus devs are interested, perhaps we could fold in
> something like this as a new goal of the exec-maven-plugin.
> 
> [1] https://github.com/ctrueden/jrun
> 
> [2] Windows users need POSIX-compliant shell, though. I did not test it yet.
> 
> --
> Curtis Rueden
> LOCI software architect - https://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
> 
> 
> On Thu, Mar 2, 2017 at 9:50 AM, Curtis Rueden  wrote:
> 
>> Hi everyone,
>>
>> Is there an easy way to download an artifact and its dependencies to a
>> folder locally?
>>
>> * dependency:get will download a single artifact without needing a pom.xml.
>> * dependency:copy-dependencies will copy the dependencies of the current
>> project to a target location.
>>
>> But can these two functionalities be combined?
>>
>> My use case is that I want to run a class from a Maven artifact.
>>
>> The best I have come up with so far is to synthesize a dummy POM:
>>
>> g=org.scijava; a=scijava-common; v=RELEASE; m=org.scijava.script.ScriptREPL;
>> echo "4.0.0x> pId>x0<
>> dependencies>$g$a<
>> version>$v" > pom.xml;
>> mvn -DoutputDirectory=. dependency:copy-dependencies; rm pom.xml; java -cp
>> '*' "$m"
>>
>> Can this be done more elegantly?
>>
>> Thanks,
>> Curtis
>>
>> --
>> Curtis Rueden
>> LOCI software architect - https://loci.wisc.edu/software
>> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
>>
>>
> 


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

Re: Plugin specific command line options?

[Manfred Moser]

No ... all plugins pick up all user properties. If two plugins use the same 
name then both will pick it up and react however implemented. Thats why you 
should establish plugin specific parameter names for user properties in your 
specific plugin. So if you have a plugin called foo with the goal bar and you 
want to enable that goal to be skipped the property name could be foo.bar.skip 
...

On the other hand that allows for such things as shared reaction to parameters. 
E.g. maven.test.skip is picked up by the compiler and surefire plugins and 
skips test compilation and test run... 

hth

Manfred

Kevin Burton wrote on 2017-01-27 16:11:

> Is there a way to pass command line options but only have one plugin see it?
> 
> My understanding is that plugins just read from system properties.
> 
> So to pass 'skip' to a plugin I would use -Dskip but what if two plugins
> use the same 'skip' ?
> 
> -- 
> 
> We’re hiring if you know of any awesome Java Devops or Linux Operations
> Engineers!
> 
> Founder/CEO Spinn3r.com
> Location: *San Francisco, CA*
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> 
> 


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

Re: Takari Maven Lifecycle

[Manfred Moser]

Hilco Wijbenga wrote on 2016-12-23 09:42:

> On 23 December 2016 at 08:58, Manfred Moser <manf...@simpligility.com> wrote:
>> From what I remember this is mostly a PoC feature and by default it doesnt
>> complain or break things.
> 
> Indeed, you have to explicitly enable it and use the Eclipse compiler ...
> 
>> The docs are here
>> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
> 
> ... as explained here. :-)
> 
>> But I think it will be more helpful to watch the demo from Igor. He showed it
>> at one our our past Maven developer hangouts. Unfortunately I dont remember
>> which one...
> 
> I don't really want to sit through hours of videos just to find one
> tidbit of configuration. :-) Do you remember (roughly) when this
> elusive hangout took place?

Sorry... I dont really remember and when looking at the recordings I could not 
locate it either.

> Is Takari still being developed? The one release is from 2014 and the
> last hangout was April 30, 2015. If not, then that would be
> disappointing because I think it has a lot of promise.

I know that it is being used at some Fortune 100 companies and usage is in fact 
increasing. There is still development going on as well albeit slowly and 
carefully as the projects involved are very large.

> I tried to install TEAM but the installation page
> (http://takari.io/book/20-introduction.html#installing-team) is very
> clearly wrong in several places (and "mvn team:install or whatever"
> does not inspire confidence). Not that installing it was difficult but
> I don't see anything different when running a build.

I have to get back to revisit the docs. There is definitely a need to update 
them. I hope to get to it within the next months and will work with Jason and 
Igor to firm things up a bit. 

That all said.. we definitely are open to improvements from the community. So 
if you spot any issues like the above feel free to let us know via email or on 
github e.g. at https://github.com/takari/takari-lifecycle as an issue or pull 
request. 

Hth
Manfred



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

Re: Takari Maven Lifecycle

[Manfred Moser]

>From what I remember this is mostly a PoC feature and by default it doesnt 
>complain or break things.

The docs are here 
http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation

But I think it will be more helpful to watch the demo from Igor. He showed it 
at one our our past Maven developer hangouts. Unfortunately I dont remember 
which one...

Here is the list of all of them

http://takari.io/events.html

and here the playlist 

https://www.youtube.com/user/takariinc/videos?shelf_id=0=0=dd

hth

Manfred

Hilco Wijbenga wrote on 2016-12-23 08:27:

> On 22 December 2016 at 16:06, Hilco Wijbenga  wrote:
>> Hi all,
>>
>> Has anyone used the Takari Maven Lifecycle? Today, I added it to our
>> build to find out which transitive dependencies really should be
>> direct dependencies but I don't get a single failure. I'm not buying
>> that... :-)
>>
>> In my base POM (in ) I have this:
>>
>> 
>> io.takari.maven.plugins
>> takari-lifecycle-plugin
>> 1.11.12
>> true
>> 
>> proc
>> error
>> jdt
>> 1.7
>> 1.7
>> 
>> 
>>
>> I can't use 1.12.x because we are still on JDK 1.7. The  and
>>  are probably redundant but ToolChains is apparently not
>> supported so this seems like the best solution for when we move to JDK
>> 1.8.
>>
>> If I comment out a Test or Compile dependency that I know we depend on
>> directly then I get no error. I had a look at the source on GitHub and
>> my "accessRulesViolation" and "compilerId" settings seem correct (it
>> certainly matches the documentation).
>>
>> Has anyone tried this and did it work for you? Am I missing some
>> additional configuration or plugin? Does any reference of, say, the
>> maven-compiler-plugin somehow invalidate the accessRulesViolation
>> setting?
> 
> Oh, and I should add that I'm using packaging "takari-jar", not "jar".
> I see that the plugin is running, I just don't see anything about
> access rule violations.
> 
> -
> 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 PMD, Checkstyle multimodel configuration.

[Manfred Moser]

I dont know about the instructions but an example config for checkstyle with a 
build tools config in a multi module project can be found here

https://github.com/simpligility/ksoap2-android

hth

Manfred
simpligility.com

Artem Barger wrote on 2016-10-26 08:16:

> Hi all,
> 
> I'm trying to follow the tutorial regarding multimodule configuration for
> PMD and checkstyle plugins from here:
> https://maven.apache.org/plugins-archives/maven-pmd-plugin-LATEST/examples/multi-module-config.html
> 
> And I have a problem with last instruction, once I've done suggested
> configuration and trying to run "mvn site" it fails, since it has missing
> dependency of "build-tools". It looks like I have to run "mvn install"
> prior to "mvn site" in order to have "mvn site" succeeded.
> 
> Does my observation correct? What am I doing wrong?
> 
> Best regards,
>  Artem Barger.
> 


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

Re: Comparing specifying repositories in pom vs. settings.xml?

[Manfred Moser]

The best way is to sync your stuff to the Central Repository imho. 

Otherwise you are probably best off with using repositories in the POM or a 
checked in settings file and build.sh reference command build like mvn -s ... 

manfred

Curtis Rueden wrote on 2016-10-17 15:00:

> Hi everyone,
> 
> I have an OSS project with "mixed" dependencies—some in central, and some
> in our public Maven repo (because they are still in incubation or
> beta). Every time this discussion arises, I find myself wondering the same
> thing: how can you achieve an "out-of-the-box" build for such a project,
> without specifying ? All the alternatives I see people
> suggest (e.g., checking in settings.xml to the repository) would require
> each and every new developer to perform some one-time bootstrap before the
> project will build. This will turn away many new & inexperienced developers
> if they try to import the project into their favorite IDE and it fails to
> build.
> 
> Regards,
> Curtis
> 
> --
> Curtis Rueden
> LOCI software architect - http://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
> 
> 
> On Mon, Oct 17, 2016 at 4:48 PM, Manfred Moser <manf...@simpligility.com>
> wrote:
> 
>> If you really feel you need to control the source of where you download
>> components from within the source control system
>> I would still NOT use the repositories definition in the POM since that is
>> them transferred to the target repo on deployment (unless you use flatten).
>>
>> Instead I would check in a specific settings.xml as part of the project...
>> or even multiple ones for different build scenarios..
>>
>> Manfred
>>
>> KARR, DAVID wrote on 2016-10-17 14:42:
>>
>> >> -Original Message-
>> >> From: Manfred Moser [mailto:manf...@simpligility.com]
>> >> Sent: Monday, October 17, 2016 1:35 PM
>> >> To: users@maven.apache.org
>> >> Subject: Re: Comparing specifying repositories in pom vs. settings.xml?
>> >>
>> >> http://blog.sonatype.com/2009/02/why-putting-repositories-in-your-poms-
>> >> is-a-bad-idea/
>> >
>> > The point about open-source projects is well-taken.  I would never
>> specify
>> > repositories in a POM for a public project.
>> >
>> > The section about "Enterprise" just seems odd to me.  It seems very
>> focused on
>> > "central", when that might not be the case at all.  We use many
>> open-source
>> > projects, but those aren't very volatile.  We use dozens of internal
>> artifacts,
>> > and there isn't a lot of doubt about what repos to get particular kinds
>> of
>> > artifacts from.  I find build repeatability more important (specifying
>> all
>> > requirements in the build script).  The requirement about "generally
>> will want
>> > all your developers using the same set of repositories" is pretty
>> important to
>> > me, but the recommended solution just seems counterproductive.
>> Specifying it
>> > in the POM for the project seems to be the most direct way to ensure
>> that.
>> >
>> >> KARR, DAVID wrote on 2016-10-17 13:03:
>> >>
>> >> > One thing I run into when jumping between different projects is
>> >> > different expectations for what maven repos I need to be using.  In
>> >> > the past, I had to have multiple copies of "~/.m2/settings.xml" lying
>> >> > around, and I would hack the specified repos when I needed to.
>> >> >
>> >> > Recently, I saw a situation where the required repositories were
>> >> > simply defined in the top-level pom for the project.  If this is done
>> >> > consistently, there's no longer any need to hack the settings.xml
>> >> file.
>> >> >
>> >> > I seem to remember seeing some advice that specifying repositories in
>> >> > the POM is a bad practice.  If I'm remembering this correctly, this
>> >> > seems odd.  Forcing the correct repos to be defined in the
>> >> > settings.xml works against "repeatable builds".
>> >> >
>> >> > What is the recommended advice here?
>> >> >
>> >> > -
>> >> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> >> > For additional commands, e-mail: users-h...@maven.apache.org
>> >> >
>> >>
>> >>
>> >> -
>> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> >> For additional commands, e-mail: users-h...@maven.apache.org
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: users-h...@maven.apache.org
>> >
>>
>>
>> -
>> 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: Comparing specifying repositories in pom vs. settings.xml?

[Manfred Moser]

If you really feel you need to control the source of where you download 
components from within the source control system 
I would still NOT use the repositories definition in the POM since that is them 
transferred to the target repo on deployment (unless you use flatten).

Instead I would check in a specific settings.xml as part of the project... or 
even multiple ones for different build scenarios.. 

Manfred

KARR, DAVID wrote on 2016-10-17 14:42:

>> -Original Message-
>> From: Manfred Moser [mailto:manf...@simpligility.com]
>> Sent: Monday, October 17, 2016 1:35 PM
>> To: users@maven.apache.org
>> Subject: Re: Comparing specifying repositories in pom vs. settings.xml?
>> 
>> http://blog.sonatype.com/2009/02/why-putting-repositories-in-your-poms-
>> is-a-bad-idea/
> 
> The point about open-source projects is well-taken.  I would never specify
> repositories in a POM for a public project.
> 
> The section about "Enterprise" just seems odd to me.  It seems very focused on
> "central", when that might not be the case at all.  We use many open-source
> projects, but those aren't very volatile.  We use dozens of internal 
> artifacts,
> and there isn't a lot of doubt about what repos to get particular kinds of
> artifacts from.  I find build repeatability more important (specifying all
> requirements in the build script).  The requirement about "generally will want
> all your developers using the same set of repositories" is pretty important to
> me, but the recommended solution just seems counterproductive.  Specifying it
> in the POM for the project seems to be the most direct way to ensure that.
> 
>> KARR, DAVID wrote on 2016-10-17 13:03:
>> 
>> > One thing I run into when jumping between different projects is
>> > different expectations for what maven repos I need to be using.  In
>> > the past, I had to have multiple copies of "~/.m2/settings.xml" lying
>> > around, and I would hack the specified repos when I needed to.
>> >
>> > Recently, I saw a situation where the required repositories were
>> > simply defined in the top-level pom for the project.  If this is done
>> > consistently, there's no longer any need to hack the settings.xml
>> file.
>> >
>> > I seem to remember seeing some advice that specifying repositories in
>> > the POM is a bad practice.  If I'm remembering this correctly, this
>> > seems odd.  Forcing the correct repos to be defined in the
>> > settings.xml works against "repeatable builds".
>> >
>> > What is the recommended advice here?
>> >
>> > -
>> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: users-h...@maven.apache.org
>> >
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


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

Re: Comparing specifying repositories in pom vs. settings.xml?

[Manfred Moser]

http://blog.sonatype.com/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/

KARR, DAVID wrote on 2016-10-17 13:03:

> One thing I run into when jumping between different projects is different
> expectations for what maven repos I need to be using.  In the past, I had to
> have multiple copies of "~/.m2/settings.xml" lying around, and I would hack 
> the
> specified repos when I needed to.
> 
> Recently, I saw a situation where the required repositories were simply 
> defined
> in the top-level pom for the project.  If this is done consistently, there's 
> no
> longer any need to hack the settings.xml file.
> 
> I seem to remember seeing some advice that specifying repositories in the POM
> is a bad practice.  If I'm remembering this correctly, this seems odd.  
> Forcing
> the correct repos to be defined in the settings.xml works against "repeatable
> builds".
> 
> What is the recommended advice here?
> 
> -
> 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: Jenkins and Maven

[Manfred Moser]

I agree with Stephen .. avoid the Maven job type. In fact I would install 
Daniel's 

https://github.com/daniel-beck/hide-maven-plugin\

I have spent many hours trying to fix broken builds with the Maven job type 
only to switch to Freestyle jobs and they just work. There is a reason why 
Eclipse Hudson declared the job type legacy and has an improved Maven freestyle 
integration (but thats kind of beside the point when you look at Jenkins).

Also in terms of settings management and such I suggest to use the config file 
provider plugin.

I recorded a demo video about that stuff some while ago (for Sonatype in the 
context of deploying to Nexus but applies generically). Its part of the tips 
from the trenches series

http://www.sonatype.org/nexus/members-only/video-gallery-2/free-training-sonatype-nexus-and-clm-tips-from-the-trenches/

Here are the two Jenkins videos

https://www.youtube.com/watch?v=JpXksHynouk
https://www.youtube.com/watch?v=xHJrqKf0cLk

Also if you want to invoke maven from a shell script or so you might want to 
look at the wrapper.

https://github.com/takari/maven-wrapper

Hth

Manfred



Benson Margulies wrote on 2016-10-13 06:59:

> We've about had it with bamboo, and are dusting off our old Jenkins instance.
> 
> I recall some messages here about things _not_ to do with Jenkins and
> Maven. Do we avoid the 'maven build type' altogether and just run
> Maven from the shell, or is my memory faulty? Anything else.
> 
> -
> 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: Use cache Squid proxy with maven

[Manfred Moser]

I would suggest to use a proper repository manager as a caching proxy instead. 

There are over 110.000 installations of Sonatype Nexus Repository Manager doing 
exactly that and its free. 

Get version 2.14 from https://www.sonatype.com/download-oss-sonatype

It will save you a lot of hazzle trying to get squid to do what you want and 
provide a number of other benefits as well.

Manfred

Olivier Haegi wrote on 2016-10-06 08:42:

> Hello,
> 
> I have a squid proxy and i want than maven used it. But squid cache is
> never used.
> 
> I saw than header request send by maven contain : cache-control : max-age=0
> I think it is the problem.
> 
> It seems to me than the maven documentation said  it is the default
> configuration.
> 
> I tryed to configure setting.xml maven file but i never change
> cache-control setting
> (I followed this documentation :  http://maven.apache.org/
> guides/mini/guide-http-settings.html#Taking_Control_of_Your_HTTP_Headers).
> 
> So, i search  some help to configure header send by maven.
> 
> Thank you
> 
> -- 
> Olivier Haegi
> 


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

Re: [EXTERNAL] Re: help with version range

[Manfred Moser]

Fair enough. From the purely engineering/mathematical point of view it might 
not make sense. But I dont see a way to get that changed with breaking a TON of 
other stuff. And I am not even sure if it would be more intuitive instead of 
just being different.

Manfred

Robert Patrick wrote on 2016-09-23 09:38:

> No, you are making an invalid assumption about what I understand!  I 
> completely
> understand the relationship of SNAPSHOTs and other pre-release artifacts and
> released versions.  
> 
> What I am questioning is the "engineer's approach" to version range resolution
> without a valid use case for why Maven should consider pre-released versions 
> as
> within the "not including 2.0" version range semantics.
> 
> 
> -Original Message-
> From: Manfred Moser [mailto:manf...@simpligility.com] 
> Sent: Friday, September 23, 2016 11:32 AM
> To: users@maven.apache.org
> Subject: Re: [EXTERNAL] Re: help with version range
> 
> What you are misunderstanding is how snapshots are meant to be used.
> 2.0-SNAPSHOT means that it is a development version working towards the 
> release
> of 2.0 and as such the version 2.0-SNAPSHOT is smaller than 2.0.
> 
> If you mislike this you can change how you work with your own projects at
> least. .. you can just call your snapshot version 1.99-SNAPSHOT or whatever
> while developing and at releas time switch to 2.0 .. 
> 
> Manfred
> 
> Robert Patrick wrote on 2016-09-23 08:56:
> 
>> This does seem non-intuitive.If I say that I want versions  between 1.0
>> and
>> up to but NOT including 2.0 by saying [1.0,2.0), in what use case 
>> would I ever want this to resolve to 2.0-SNAPSHOT or any other pre-release 
>> 2.0
>> artifact?
>> Personally, I cannot think of a single one.
>> 
>> Typically, what I mean when I say [1.0,2.0) is any 1.x version but 
>> nothing related to 2.0...
>> 
>> -Original Message-
>> From: Justin Georgeson [mailto:jgeorge...@lgc.com]
>> Sent: Friday, September 23, 2016 10:11 AM
>> To: Maven Users List
>> Subject: RE: [EXTERNAL] Re: help with version range
>> 
>> Yeah, I was hoping there was something more elegant like 1.1+ or 
>> something, so I can at least move forward with that.
>> 
>> Logically, does it make sense to resolve 1.2.0-alpha-1 when the user 
>> has excluded 1.2.0 from their range? If I explicitly don't want the 
>> release version why would I want the pre-release versions?
>> 
>> -Original Message-
>> From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On 
>> Behalf Of Curtis Rueden
>> Sent: Friday, September 23, 2016 9:01 AM
>> To: Maven Users List
>> Subject: [EXTERNAL] Re: help with version range
>> 
>> Hi Justin,
>> 
>> You could write "[1.1.0,1.1.9]", no? A bit hacky, but would match 
>> the versions you want in practice.
>> 
>> Regards,
>> Curtis
>> 
>> On Sep 23, 2016 8:38 AM, "Justin Georgeson" <jgeorge...@lgc.com> wrote:
>> 
>>> I’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?
>>>
>>>
>>>
>>> *Justin Georgeson*
>>> Landmark Cloud Platforms & DevOps - RM
>>>
>>> Email: *jgeorge...@lgc.com* <jgeorge...@lgc.com>
>>>
>>> Follow Halliburton: *LinkedIn*
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dho
>>> s 
>>> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
>>> e 
>>> s-255d-26url-3Dhttp-3A__www.linkedin.com_company_halliburton=DQIFaQ
>>> & 
>>> c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_O
>>> V 
>>> ZL1uyui4QoEmBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8
>>> = 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM= >
>>> | *Facebook*
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dh
>>> o 
>>>

Re: [EXTERNAL] Re: help with version range

[Manfred Moser]

What you are misunderstanding is how snapshots are meant to be used. 
2.0-SNAPSHOT means that it is a development version working towards the release 
of 2.0 and as such the version 2.0-SNAPSHOT is smaller than 2.0.

If you mislike this you can change how you work with your own projects at 
least. .. you can just call your snapshot version 1.99-SNAPSHOT or whatever 
while developing and at releas time switch to 2.0 .. 

Manfred

Robert Patrick wrote on 2016-09-23 08:56:

> This does seem non-intuitive.If I say that I want versions  between 1.0 
> and
> up to but NOT including 2.0 by saying [1.0,2.0), in what use case would I ever
> want this to resolve to 2.0-SNAPSHOT or any other pre-release 2.0 artifact? 
> Personally, I cannot think of a single one.
> 
> Typically, what I mean when I say [1.0,2.0) is any 1.x version but nothing
> related to 2.0...
> 
> -Original Message-
> From: Justin Georgeson [mailto:jgeorge...@lgc.com] 
> Sent: Friday, September 23, 2016 10:11 AM
> To: Maven Users List
> Subject: RE: [EXTERNAL] Re: help with version range
> 
> Yeah, I was hoping there was something more elegant like 1.1+ or something, so
> I can at least move forward with that.
> 
> Logically, does it make sense to resolve 1.2.0-alpha-1 when the user has
> excluded 1.2.0 from their range? If I explicitly don't want the release 
> version
> why would I want the pre-release versions?
> 
> -Original Message-
> From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On Behalf Of
> Curtis Rueden
> Sent: Friday, September 23, 2016 9:01 AM
> To: Maven Users List
> Subject: [EXTERNAL] Re: help with version range
> 
> Hi Justin,
> 
> You could write "[1.1.0,1.1.9]", no? A bit hacky, but would match the
> versions you want in practice.
> 
> Regards,
> Curtis
> 
> On Sep 23, 2016 8:38 AM, "Justin Georgeson"  wrote:
> 
>> I’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?
>>
>>
>>
>> *Justin Georgeson*
>> Landmark Cloud Platforms & DevOps - RM
>>
>> Email: *jgeorge...@lgc.com* 
>>
>> Follow Halliburton: *LinkedIn*
>> > t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
>> s-255d-26url-3Dhttp-3A__www.linkedin.com_company_halliburton=DQIFaQ&
>> c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OV
>> ZL1uyui4QoEmBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=
>> 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM= >
>> | *Facebook*
>> > st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
>> es-255d-26url-3Dhttps-3A__www.facebook.com_halliburton=DQIFaQ=Pskv
>> ixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyu
>> i4QoEmBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=NgT-wO
>> jrb7gpKDJVcRDMmKUQqGfR-PSnXe3I98Lp1c4= >
>> | *Twitter*
>> > st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
>> es-255d-26url-3Dhttps-3A__twitter.com_halliburton=DQIFaQ=PskvixtEU
>> DK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoE
>> mBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=-swEvm-8NW2
>> 18tPAkOpg46kdPblTNts2y7dbe_w82wM= >
>> | *YouTube*
>> > t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
>> s-255d-26url-3Dhttp-3A__youtube.com_halliburton=DQIFaQ=PskvixtEUDK
>> 7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmB
>> CjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=dTvvV1RKdjYSK
>> _Hc5JX55QI7b2j-A4O9RAX2Dg9qbrU= >
>> | *Blog*
>> > t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
>> s-255d-26url-3Dhttp-3A__halliburtonblog.com=DQIFaQ=PskvixtEUDK7wuW
>> U-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCm
>> EiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=Or-LJ9tIt99DaFT0-
>> BpnvVYmC73xtz0gLUBwIg5Woho= >
>>
>>
>> > utions_=DQIFaQ=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM
>> 3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDD
>> 

Re: Packaging a directory in Maven

[Manfred Moser]

Use the Maven Assembly plugin and run the build whereever.. locally or on a CI 
server... 

Upload will happen automatically as part of your deploy runs.

Magnanao, Hector wrote on 2016-09-07 14:32:

> I need to have Maven package a directory in Bitbucket that will eventually be
> uploaded to Artifactory.  How do I do this in Maven ? I'd need to run this in
> Bamboo.
> 
> Hector Magnanao Jr.
> SCM Analyst
> 
> Fieldglass, Inc.
> O: (331) 702-6142
> M: (773) 474-3051
> hector.magna...@sap.com
> www.fieldglass.com
> 
> Fieldglass is now part of SAP
> 
> This email contains confidential information.  If you are not the intended
> recipient, do not read, distribute or reproduce this transmission (including
> any attachments). If you have received this email in error, please notify the
> sender by email reply.
> 
> 


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

New Releases - Android Maven Plugin and Android NDK Maven Plugin

[Manfred Moser]

Hi all, 

Just a quick heads up that we cut two new releases of the Android-related Maven 
plugins. 

Android NDK Maven Plugin 1.1.2 - see 
http://www.simpligility.com/2016/07/android-ndk-maven-plugin-1-1-2-released/
Android Maven Plugin 4.4.3 - see 
http://www.simpligility.com/2016/07/android-maven-plugin-4-4-3-released/

The release announcements as well as the changelogs and web sites of the two 
project provide further detail as usual .

Enjoy

Manfred

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

Re: How does maven choose which plugin version to use?

[Manfred Moser]

And you can use some open source organization pom from Apache or Maven itself

http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache%22%20AND%20a%3A%22apache%22
http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.maven%22%20AND%20a%3A%22maven-parent%22

or a more complete one like my own

https://github.com/simpligility/progressive-organization-pom

and override what you want yourself or even fork and maintain your own copy. 

There are lots of parents like that around ...

Manfred


Ron Wheeler wrote on 2016-07-03 16:40:

> A quick google gets you
> https://maven.apache.org/pom.html#Plugin_Management
> 
> You can add a plug-in management section to your parent pom to control 
> the version used in all of your project poms.
> 
> https://maven.apache.org/guides/introduction/introduction-to-the-pom.html
> 
> Ron
> 
> On 03/07/2016 5:45 PM, Alex Ditu wrote:
>> Hello,
>>
>> Can anyone provide some help regarding plugin versions? I want to use
>> the latest version of maven-war-plugin (or at least one greater than
>> 2.3); so i decided to install the latest version of maven, 3.3.9.
>> But when I execute "mvn help:effective-pom" I see it still uses 2.3
>> version of maven-war-plugin.
>> My first question is: where does maven read wich plugin version to
>> use, if I don't specify one?
>> I tought it was in the super-pom, but I didn't find anything
>> there...Can anyone help me understand what is happening?
>>
>> Alex
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
> 
> 
> -- 
> 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
> 


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

Re: deployment to local repository

[Manfred Moser]

Do not use install-file and package like that.

Just run

mvn install

that will package the jar and install the jar and pom into the local repo. That 
way the dependency info in the pom will not get lost.

manfred

Philipp Kraus wrote on 2016-05-25 13:14:

> Hello,
> 
> I’m working on my first Maven framework, I would like to test the framework
> in another project,
> so I build a jar file with „mvn package", and then I install the jar into my
> local repository with „mvn install:install-file -Dfile=myjar.jar“.
> 
> I can use the package in another project with a dependency entry, but my
> framework has got different dependencies e.g. to AntLR, Guava
> or Apache Commons, but in my project the dependencies are not found.
> 
> The pom of the framework is defined with:
> 
> mygroup
> framework
> 0.1-SNAPSHOT
> jar
> 
> and the project has got
> 
> 
>mygroup
>framework
>0.1-SNAPSHOT
>compile
> 
> 
> IMHO I create a incomplete pom.xml on my framework, but I don’t know how I
> can create it with the correct
> way, so I can deploy the framework to my local repository only for
> testing-case. Two other test projects should
> use this deployed framework.
> 
> Can you help me to create a correct pom.xml?
> 
> Thanks for help
> 
> Phil
> 


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

Re: Create own Maven repository

[Manfred Moser]

I totally agree with that. If you run into any problems with that please reach 
out to me and I can help in detail as I wrote most of the linked docs and also 
created a video series with tips and just recently did a fully automated setup 
with Atlassian Pipelines for example.

http://www.sonatype.org/nexus/2016/05/24/sonatype-automated-deployments-with-atlassian-bitbucket-pipelines/

Manfred



Jeff Jensen wrote on 2016-05-13 05:13:

>>
>> I want to offer my library also via a Maven repository - snapshots as well
>> as releases.
> 
> 
> Use Sonatype's free OSS repo hosting [0].  It also provides the easiest and
> fastest path for deploying artifacts into Central.
> 
> Essentially:
> 1. Deploy snapshots and releases to it.
> 2. Promote successful releases from it to Central when desired.
> 
> 
> [0] http://central.sonatype.org/pages/ossrh-guide.html
> 
> 
> On Fri, May 13, 2016 at 2:16 AM, Barrie Treloar  wrote:
> 
>> A snapshot repository won't behave how you think it will behave.
>> I recommend not providing one.
>>
>> As a developer you want your code base to be in a known configured state.
>> Having a snapshot repository will mean that Maven will pull in a new
>> snapshot occasionally (you have some control over when they might be) and
>> if that snapshot is SNAFU then you have just stopped that developer from
>> being productive. If a developer wants a snapshot let them pull your code
>> down and built it themselves, then if the code is SNAFU they can choose a
>> previous revision from source control to use instead.
>>
>> Since you are talking about a sourceforge project then you are providing an
>> open source, so you are better off deploying your releases to central.
>> Your users will thank you for not slowing their build times down with your
>> custom repo.
>>
> 

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

Re: Problem With Maven Compiler Plugin

[Manfred Moser]

Just to confirm though.. latest versions of M2e need Java 1.8... 

Anders Hammar wrote on 2016-05-12 09:25:

> As Mark pointed out, m2e requires a JDK. Initially you were using a JRE and
> it will then not work. Now you changed to a JDK and it works. It has
> nothing to do with the Java version.
> 
> /Anders (mobile)
> On May 12, 2016 18:08,  wrote:
> 
>> I thought I'd post one last comment about this.
>>
>> For a brief period I was under the impression that fixing my dependencies
>> somehow fixed this problem.  That was not the case.
>>
>> It appears the root cause was that in Eclipse I configured the installed
>> JRE for Java 1.8.  Since I have several versions of the Java JDK installed
>> I simply changed my JAVA_HOME environment variable to point to the 1.7 JDK
>> and then changed my installed JRE in Eclipse to also point to JDK 1.7.
>> problem solved!
>>
>> I assume the Maven plug-ins for Eclipse (at least the version I'm using,
>> 1.5.1) require Java 1.7!!!
>>
>> It would be great if someone would confirm this.
>>
>> Thanks
>>
>> Michael Tarullo
>> Contractor (Engility Corp)
>> Software Engineer
>> FAA WJH Technical Center
>> (609)485-5294
>>
>> -Original Message-
>> From: Martin Gainty [mailto:mgai...@hotmail.com]
>> Sent: Wednesday, May 11, 2016 1:13 PM
>> To: users@maven.apache.org
>> Subject: RE: Problem With Maven Compiler Plugin
>>
>> Nota Bene: to detect missing dependencies i run dependency:tree and  bind
>> to initialize phase before compilation
>> http://stackoverflow.com/questions/17978768/how-to-determine-which-maven-dependency-is-needing-a-missing-dependency
>> HTH!
>> Martin (decidedly left of CTR) Gainty
>>
>>
>>
>> > From: michael.ctr.taru...@faa.gov
>> > To: users@maven.apache.org
>> > Subject: RE: Problem With Maven Compiler Plugin
>> > Date: Wed, 11 May 2016 15:14:24 +
>> >
>> > Thank you for the reply Mark.
>> >
>> > This problem "fixed itself".  Just thought I'd explain here in the event
>> anyone else was having the same problem.
>> >
>> > There were some dependencies I was missing in my POM.  They were
>> libraries needed by the app (I'm new to this app and it is not normally
>> built with Maven) and I had not included them in the POM or our repo yet.
>> But they were not related to a plugin in any way.
>> >
>> > When I added these dependencies to the POM and tried a compile from the
>> command line, the build worked.  Then with no changes to Eclipse I
>> submitted the compile using Run As. Maven build and it also worked fine.
>> >
>> > So the error message about not being able to find tools.jar, and the
>> fact that it appeared to be looking for it in the wrong place, appears to
>> be just a distraction from the actual problem, in this case not including
>> all the dependencies.  I'm not sure why that would result in the error
>> message I was seeing, but at this stage, that's a moot point.
>> >
>> > Mike
>> >
>> > Michael Tarullo
>> > Contractor (Engility Corp)
>> > Software Engineer
>> > FAA WJH Technical Center
>> > (609)485-5294
>> >
>> > -Original Message-
>> > From: Mark Prins [mailto:mc.pr...@gmail.com]
>> > Sent: Tuesday, May 10, 2016 10:24 AM
>> > To: users@maven.apache.org
>> > Subject: Re: Problem With Maven Compiler Plugin
>> >
>> > On 10-05-16 16:12, michael.ctr.taru...@faa.gov wrote:
>> > > When attempting to build with Maven from Eclipse I am getting the
>> following error:
>> > >
>> > > [ERROR] Failed to execute goal
>> > > org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile
>> > > (default-compile) on project camel-activemq: Fatal error compiling:
>> > > tools.jar not found: C:\Dev\Java\jre1.8.0_51\..\lib\tools.jar ->
>> > > [Help 1]
>> > >
>> > > I'm confused about why the plugin is looking in the JRE for tools.jar,
>> when this JAR exists in the JDK.
>> > >
>> >
>> > I think the eclipse maven plugin uses the JVM that eclipse is running
>> > in, so you need to specify either a specific JDK or run eclipse in a
>> > JDK VM (this is configured in eclipse.ini if I recall correctly)
>> >
>> > (or -not recommended- specify a specific compiler in your pom/compiler
>> > plugin)
>> >
>> > -M
>> >
>> > -
>> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: users-h...@maven.apache.org
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: users-h...@maven.apache.org
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
> 


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

Maven Repository Provisioner 1.1.1

[Manfred Moser]

Hi all,

I just thought I let you know that my Maven Repository Provisioner tool 
recently got a few updates and is not at version 1.1.1.

It allows you to provision a Maven repository from the filesystem into a repo 
manager or one or number of artifacts (specified by GAV coordinates) including 
all transitive dependencies and required parent pom from a source to a target 
repo. You can use this for audit/archival or similar usage as well as for 
manual provisions with some sort of approval flow.

More details are in a blog post at 
http://www.simpligility.com/2016/04/maven-repository-provisioner-goes-1-0-0/

I would appreciate any feedback, issue or remarks about usage.. 

Manfred

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

Re: Publishing to Central

[Manfred Moser]

Unfortunately the decision to have the registration is out of my control. It 
just requires an email and the videos are entirely free. They will be linked 
straight from the doc site at central.sonatype.org site soon though.

manfred

Christopher wrote on 2016-04-27 16:09:

> It looks like the videos are "members only" and you need a community access
> code to view them. Is that intended? The blog post is a nice pointer to the
> videos, but it's kinda useless without the videos themselves.
> 
> On Wed, Apr 27, 2016 at 2:49 PM Manfred Moser <manf...@simpligility.com>
> wrote:
> 
>> Hi all,
>>
>> I recently recorded some videos that explain some of the rules and steps
>> around publishing to Central. Now I finally got around to writing a blog
>> post.
>>
>> Check it out here
>>
>>
>> http://www.simpligility.com/2016/04/easy-publishing-to-the-central-repository/
>>
>> And as usual find the rest of the docs on the site at
>> http://central.sonatype.org/
>>
>> Hth
>>
>> Manfred
>>
>> -
>> 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

Publishing to Central

[Manfred Moser]

Hi all,

I recently recorded some videos that explain some of the rules and steps around 
publishing to Central. Now I finally got around to writing a blog post.

Check it out here

http://www.simpligility.com/2016/04/easy-publishing-to-the-central-repository/

And as usual find the rest of the docs on the site at 
http://central.sonatype.org/

Hth

Manfred

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

Re: "conditional" parent POM?

[Manfred Moser]

How so? The flatten plugin just flattens the poms right. If they point to an 
internal repo manager .. its still wrong.. 

Manfred

Robert Patrick wrote on 2016-03-10 14:43:

> Take a look at the flatten plugin...this is a much simpler way to solve that
> problem!
> 
> Robert Patrick 
> Sent from my iDevice
> 
>> On Mar 10, 2016, at 2:38 PM, Max Spring  wrote:
>> 
>> Hi Curtis,
>> 
>> I don't want to have the URL of my in-house Maven repository manager out in
>> the open.
>> 
>> Regards,
>> -Max
>> 
>> 
>>> On 03/10/2016 12:29 PM, Curtis Rueden wrote:
>>> Hi Max,
>>> 
>>> Why do you need two different parents? What configuration is different
>>> between your "wild" parent and your internal one?
>>> 
>>> Would it be sufficient to enclose the internal-specific configuration
>>> (e.g., distributionManagement) in a profile? This technique is what my OSS
>>> projects do [1].
>>> 
>>> Regards,
>>> Curtis
>>> 
>>> [1]
>>> https://github.com/scijava/pom-scijava/blob/pom-scijava-9.6.0/pom.xml#L1686-L1701
>>> 
>>> 
 On Thu, Mar 10, 2016 at 2:20 PM, Max Spring  wrote:
 
 What's the best structure for a (multi-module) Maven project which should
 build "in the wild" without any Maven repository manager and can easily
 build within my organization where deployments should happen to my Maven
 repository manager?
 
 Ideally, I would have two different paren POMs for each situation. But
 unfortunately, I can't use a Maven property to pass the correct value for
 each situation, because the property expression in the parent POM reference
 doesn't get interpolated, if I try something like
 
   
 org.example
 ${root.pom}
 1.0-SNAPSHOT
 
   
   ...
   
 wild-parent
   
 
 Added a minimalistic project which shows a crude approach to solve this by
 patching the parent POM via sed:
 https://github.com/m2spring/wild-inhouse-hybrid-example
 
 -Max
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


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

Re: "conditional" parent POM?

[Manfred Moser]

You should not use different rool poms. The whole upstream parents for your 
open source project should be open source as well. 

And if you want to deploy to a different repo manager you can make the URLs 
configurable as a property that you set in the pom and e.g. override in your 
internal setup via settings.xml.

Manfred

Max Spring wrote on 2016-03-10 12:20:

> What's the best structure for a (multi-module) Maven project which should 
> build
> "in the wild" without any Maven repository manager and can easily build within
> my organization where deployments should happen to my Maven repository 
> manager?
> 
> Ideally, I would have two different paren POMs for each situation. But
> unfortunately, I can't use a Maven property to pass the correct value for each
> situation, because the property expression in the parent POM reference doesn't
> get interpolated, if I try something like
> 
>   
> org.example
> ${root.pom}
> 1.0-SNAPSHOT
> 
>   
>   ...
>   
> wild-parent
>   
> 
> Added a minimalistic project which shows a crude approach to solve this by
> patching the parent POM via sed:
> https://github.com/m2spring/wild-inhouse-hybrid-example
> 
> -Max
> 
> 
> -
> 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: plugin and executable jar

[Manfred Moser]

And


Learn about multi module projects .. this is essential Maven knowledge.


http://books.sonatype.com/mvnex-book/reference/multimodule.html

Manfred


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

Re: plugin and executable jar

[Manfred Moser]

do NOT use profiles.. therin lies madness


youssef boujallab wrote on 2016-03-01 14:06:
> You can't do it with a standard approach.
> You should use two distinct Maven projects or use profiles with two
> differents configurations ( one for executable jar and other for your
> mojo)
> Le 1 mars 2016 22:04, "Philipp Kraus"  a
> écrit :
> 
> > Hi,
> >
> > Am 01.03.2016 um 22:47 schrieb youssef boujallab <
> > youssef.boujal...@gmail.com>:
> >
> > > Did you have a look on shade plugin?
> >
> > thanks for your answer, I’m using the shade plugin at the moment, but I
> > cannot
> > create the different Jar files
> >
> > Phil
> > -
> > 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: plugin and executable jar

[Manfred Moser]

Just do this

1 jar project with the functionality

1 maven-plugin project that uses the jar and wraps it in a maven plugin

1 jar project that has the main() method wrapper and command line parser=
 or whatever for the executable

1 pom that acts as parent and aggregator to tie it all together


Manfred

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

Android Maven Plugins released

[Manfred Moser]

The Android Maven Plugin team is pleased to announce the releases of

Android Maven Plugin 4.4.1 - 
http://www.simpligility.com/2016/01/android-maven-plugin-4-4-1-released/

Android NDK Maven Plugin 1.1.0 - 
http://www.simpligility.com/2016/02/android-ndk-maven-plugin-1-1-0-released/

With help of over a dozen contributors and rather large new features and 
improvements we are happy to bring you these releases.

As usual please check out the web sites and changelogs for more information and 
join the Android Maven Developer mailing list.

http://simpligility.github.io/android-maven-plugin/

http://simpligility.github.io/android-ndk-maven-plugin/

Thanks again to everyone involved.

manfred

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

Re: Copy-dependencies goal error

[Manfred Moser]

Michael,

Please refrain from insulting the efforts of the people on this list trying
to help you. If you are not happy with the help you receive here, you are
free to look for it elsewhere. I would like the discussions here to stay
civil and on topic.

I hope you provide us all here with the same respect that you would expect
us to have towards you.

We are all volunteers here.

Thank you

Manfred


michael.ctr.taru...@faa.gov wrote on 2015-10-05 15:28:
> That is fine with me, because your either wrong or incomprehensible
> answers are
> wasting my time.
> 
> Michael Tarullo
> Contractor (Engility Corp)
> Enterprise Architect
> NSRR System Administrator
> FAA WJH Technical Center
> (609)485-5294
> 
> 
> -Original Message-
> From: Jörg Schaible [mailto:joerg.schai...@gmx.de]
> Sent: Monday, October 05, 2015 6:23 PM
> To: users@maven.apache.org
> Subject: RE: Copy-dependencies goal error
> 
> michael.ctr.taru...@faa.gov wrote:
> 
> > What are you talking about?
> >
> > Of course I don't pay. It's an open source product.
> 
> OK, then I don't answer anymore, because it's my free time and you're
> wasting it.
> 
> Cheers,
> Jörg
> 
> 
> -
> 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

Android Maven Plugin 4.3.0 released

[Manfred Moser]

The Android Maven Plugin team is pleased to announce the release of version 
4.3.0 of the plugin:

plugin
  groupIdcom.simpligility.maven.plugins/groupId
  artifactIdandroid-maven-plugin/artifactId
  version4.3.0/version
  extensionstrue/extensions
/plugin

New features/bug fixes for the specific release are

- Fixed processing of duplicate resources from dependencies
- Ability to choose the build tools version
- Added x86_64 and mips64 architectures to NDK support
- Migrated rest of the Google Code project content into site content - the old 
site is now defunct and deleted

We would like to thank the contributors to this release for their valuable help 
and invite you all to help us out as well:

Specifically for this release we would like to thank the following contributors 
for their awesome work.

Committers for this release

Marek Kedzierski https://github.com/kedzie
Benoit Billington https://github.com/Shusshu
Marek Kedzierski http://kedzie.github.io/
Manfred Moser http://www.simpligility.com

Core Committers

Benoit Billington https://github.com/Shusshu
Manfred Moser http://www.simpligility.com
Malachi de AElfweald https://github.com/malachid
Johan Lindquist https://github.com/johanlindquist
William Ferguson http://github.com/william-ferguson-au

We would also like to thank the Maven and Android community members and 
everybody else out there for any help we received in our issue tracker and 
beyond.

Release build done by Manfred Moser http://www.simpligility.com

Documentation, issue tracker and more can be found on the plugin websites at

https://github.com/simpligility/android-maven-plugin/
http://simpligility.github.io/android-maven-plugin/

Please join the Maven Android Mailing List for relevant discussions:

https://groups.google.com/forum/?fromgroups#!forum/maven-android-developers

Enjoy and congratulations to everyone involved. 

Manfred Moser
http://www.simpligility.com


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

Re: Why are extensions project based and not global?

[Manfred Moser]

Use cases I can think of (there are probably more)

- use concurrent safe local repo access for all builds on a CI server without 
having to modify all projects
- enabling extension for multi thread logging or any other feature like 
coloring or so across all projects I work on locally
- allow different pom DSL's even when creating a new project and 
.mvn/extensions.xml was not yet added
- easily manage version of extensions to be used across a number of projects 
- allow to take advantage of extensions even when you dont have full access to 
a project repository

I am not certain these justify the problems you mention .. which is why I think 
we should just let the usage of extensions get wider before we make any 
decisions. 

Manfred

Graham Leggett wrote on 28.05.2015 11:21:

 On 28 May 2015, at 16:58, Manfred Moser manf...@mosabuam.com wrote:
 
 I think having a global config for this would be good. Personally I think
 having .m2/extensions.xml would be a good way to do it.
 
 Can you describe the use case?
 
 It seems this only makes sense if you only ever do work for one organization,
 ever. As soon as you need to do work for multiple clients, or perhaps your
 corporate client and an open source project, using maven becomes difficult.
 
 Even with a single organization having config outside the project is a right
 pain. Instead of it's maven, you know what to do, you have some weird site
 specific ritual to perform, and this creates friction.
 
 Regards,
 Graham
 --
 
 
 -
 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: Why are extensions project based and not global?

[Manfred Moser]

True ... with great power comes 

But to lighten that we could by default say that project based extensions 
override global ones.

Realistically I think we just have to use it all more and get more practical 
experience with extensions to see where we might want to head next.

Manfred

Jason van Zyl wrote on 28.05.2015 09:21:

 The downside here is that what you might have configured locally, personally,
 may conflict with what a project might have setup.
 
 At the project level it's safe, organizationally it can be if curated but a
 personal setup working with something not explicitly configured for a specific
 project is asking for support problems.
 
 On May 28, 2015, at 11:58 AM, Manfred Moser manf...@mosabuam.com wrote:
 
 I think having a global config for this would be good. Personally I think
 having .m2/extensions.xml would be a good way to do it.
 
 You could introduce e.g. Igor's logging here, add the Takari concurrent local
 repo access and so on in a declarative fashion and truly customize your Maven
 installation. Installation rather than project usage! 
 
 And it would be fine to switch between Maven installations and it would also
 be applicable e.g. to an embedded Maven in M2e or another tool.
 
 The loading problem of e.g. starting the groovy extension on each project
 exists but that comes down to carefully choosing which extensions you always
 want and which ones you have project specific. And we can maybe look at each
 extension doing a quick check first before a full start. E.g. No pom.groovy
 file .. exit.
 
 The problem with using the settings file is that we then have two different
 syntax for specifiying the extensions and that we have to change settings so
 that would probably not be backwards compatible.. 
 
 Manfred
 
 Jason van Zyl wrote on 28.05.2015 05:08:
 
 So just to be clear you don't actually have to add the artifact itself but a
 declaration of the artifact and it will be downloaded. We really only first
 thought about project specific extensions, making sure the mechanism worked
 with the type of bootstrapping required, proper classloader isolation, that 
 a
 complex project I was working on functioned, and that polyglot worked for
 JRuby. We have discussed in the hangouts how an extension might work on an
 organizational basis but never really decided anything. 
 
 So how would an organization say they wanted to use the Groovy DSL? The POM
 is
 likely ideal but we have obvious bootstrapping issues doing that as you can
 imagine with extensions like Polyglot which actually need to read the POM. 
 
 I think the options are:
 
 - user level
 - .m2/extensions.xml: i think it is hard here to enforce what projects to
 operate on, i don't think you want the groovy extension loaded for every
 project
 
 - distribution level: you have to ensure that everyone actually uses the 
 same
 distribution. this is possible with the Maven Wrapper
 (http://github.com/takari/maven-wrapper)
 
 - project level
 - .mvn/extensions.xml: what is currently implemented
 
 - organization level
 - ${url}/extensions.xml: we need to use something outside the POM currently.
 we might be able to get clever making a couple passes but we're not 
 currently
 doing that.
 
 Jordan, what do you think would be most convenient and least error prone?
 
 On May 27, 2015, at 2:52 PM, Jordan Zimmerman jor...@jordanzimmerman.com
 wrote:
 
 What is the reason that .mvn/extensions.xml has to be added to every
 project?
 It would be much more useful to add it globally in the .m2 directory. If I
 want to standardize, say, on Groovy polyglot I don’t want to have to have
 every developer in our org remember to add the extension to every project.
 That would be a big pain.
 
 
 
 
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder, Takari and Apache Maven
 http://twitter.com/jvanzyl
 http://twitter.com/takari_io
 -
 
 In short, man creates for himself a new religion of a rational
 and technical order to justify his work and to be justified in it.
 
 -- Jacques Ellul, The Technological Society
 
 
 
 
 
 
 
 
 
 
 
 
 
 -
 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
 
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder, Takari and Apache Maven
 http://twitter.com/jvanzyl
 http://twitter.com/takari_io
 -
 
 What matters is not ideas, but the people who have them. Good people can fix
 bad ideas, but good ideas can't save bad people. 
 
 -- Paul Graham

Re: Why are extensions project based and not global?

[Manfred Moser]

I think having a global config for this would be good. Personally I think 
having .m2/extensions.xml would be a good way to do it.

You could introduce e.g. Igor's logging here, add the Takari concurrent local 
repo access and so on in a declarative fashion and truly customize your Maven 
installation. Installation rather than project usage! 

And it would be fine to switch between Maven installations and it would also be 
applicable e.g. to an embedded Maven in M2e or another tool.

The loading problem of e.g. starting the groovy extension on each project 
exists but that comes down to carefully choosing which extensions you always 
want and which ones you have project specific. And we can maybe look at each 
extension doing a quick check first before a full start. E.g. No pom.groovy 
file .. exit.

The problem with using the settings file is that we then have two different 
syntax for specifiying the extensions and that we have to change settings so 
that would probably not be backwards compatible.. 

Manfred

Jason van Zyl wrote on 28.05.2015 05:08:

 So just to be clear you don't actually have to add the artifact itself but a
 declaration of the artifact and it will be downloaded. We really only first
 thought about project specific extensions, making sure the mechanism worked
 with the type of bootstrapping required, proper classloader isolation, that a
 complex project I was working on functioned, and that polyglot worked for
 JRuby. We have discussed in the hangouts how an extension might work on an
 organizational basis but never really decided anything. 
 
 So how would an organization say they wanted to use the Groovy DSL? The POM is
 likely ideal but we have obvious bootstrapping issues doing that as you can
 imagine with extensions like Polyglot which actually need to read the POM. 
 
 I think the options are:
 
 - user level
  - .m2/extensions.xml: i think it is hard here to enforce what projects to
  operate on, i don't think you want the groovy extension loaded for every
  project
 
 - distribution level: you have to ensure that everyone actually uses the same
 distribution. this is possible with the Maven Wrapper
 (http://github.com/takari/maven-wrapper)
 
 - project level
  - .mvn/extensions.xml: what is currently implemented
 
 - organization level
  - ${url}/extensions.xml: we need to use something outside the POM currently.
  we might be able to get clever making a couple passes but we're not currently
  doing that.
 
 Jordan, what do you think would be most convenient and least error prone?
 
 On May 27, 2015, at 2:52 PM, Jordan Zimmerman jor...@jordanzimmerman.com
 wrote:
 
 What is the reason that .mvn/extensions.xml has to be added to every project?
 It would be much more useful to add it globally in the .m2 directory. If I
 want to standardize, say, on Groovy polyglot I don’t want to have to have
 every developer in our org remember to add the extension to every project.
 That would be a big pain.
 
 
 
 
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder, Takari and Apache Maven
 http://twitter.com/jvanzyl
 http://twitter.com/takari_io
 -
 
 In short, man creates for himself a new religion of a rational
 and technical order to justify his work and to be justified in it.
 
  -- Jacques Ellul, The Technological Society
 
 
 
 
 
 
 
 
 
 
 
 
 
 -
 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: setup a (end user) website for maven project

[Manfred Moser]

The Maven site plugin can use any content written in e.g. asciidoc, markdown 
and so on to create a site and you can use a skin to change the look and feel. 
Maven itself and most plugins do that.

If that is not what you are looking for you could e.g. use the Maven site 
plugin for the docs and then add usage of the jbake maven plugin for the site 
itself and have it all in a multi module build.

manfred

Johannes Ernst wrote on 25.05.2015 21:46:

 What’s a simple way to set up a website for a couple of related maven
 projects that has documentation, examples, howtos, and the like? I don’t want
 to publish the gory details of the build there, but something “pretty” and
 informative for the end users of the libraries.
 
 I’m thinking of putting together a Makefile that invokes maven (for JavaDoc
 purposes), and jekyll (for the rest of the documentation) and knows how to
 rsync to the host.
 
 But I’m hoping there’s a simpler way. E.g. I would love to avoid having to
 write code that keeps JavaDoc output for different project versions in
 different directories (so users can choose which version of the JavaDoc to
 browse) etc. It seems I can’t be the first person who wants to do this?
 
 I looked at what the log4j guys do, but from what I can tell, maven only
 generates some of the content on that site.
 
 All pointers appreciated.
 
 Thanks,
 
 
 
 Johannes.
 
 
 -
 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: How to properly use a custom maven archetype

[Manfred Moser]

It should be listed but if you know the GAV coordinates for it you can also 
specify them

Like

mvn archetype:generate -DarchetypeGroupId=com.example.maven 

the rest of the parameters are here

http://maven.apache.org/archetype/maven-archetype-plugin/generate-mojo.html

manfred

Maven User wrote on 14.05.2015 16:43:

 Hi all -
 
 Now that I've created and released my archetype to my nexus server, I
 can see it listed in the catalog file.
 
 How can I reference that archetype via maven?
 
 I've tried filtering the archetype listings by my groupId of the
 archetype but it's never found.
 
 -
 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: [EXTERNAL] dependency management with ant quick question

[Manfred Moser]

Do NOT use the Maven Ant tasks.. they are outdated and based on Maven 2.

Instead use the dep resolution library used in Maven itself called Eclipse 
Aether and its Ant tasks..

http://eclipse.org/aether/

http://wiki.eclipse.org/Aether/Ant_Tasks



Zk W wrote on 13.05.2015 20:25:

 Hi Justin
 
 Thanks for replying.
 Let us think more of your suggestion here and update.
 
 Thanks
 
 On Wed, May 13, 2015 at 8:14 PM, Justin Georgeson jgeorge...@lgc.com
 wrote:
 
 https://maven.apache.org/ant-tasks/

 1. There is a task to resolve/retrieve dependencies.

 2. The dependency task can create classpath and fileset refids for the
 dependencies, and per-dependency properties, so you shouldn't have to worry
 about copy jars to and fro.

 3. There are examples at the link above.

 
 From: Zk W [mpc8...@gmail.com]
 Sent: Wednesday, May 13, 2015 10:00 PM
 To: users@maven.apache.org
 Subject: [EXTERNAL] dependency management with ant quick question

 Hi All

 We are new to Maven and we are an ant shop.
 We like to use Maven's dependency management feature, not ivy.

 1- Can we just use Maven's dependency management feature to work with our
 ant build script ?

 2- Since .m2 is the default folder for all the jars, do we use ant copy
 task to copy jars from .m2 folder to different project folders to compile
 properly ?

 3. Are there examples out there that use ant for build purpose in
 conjunction with maven's dependency management ?

 Thank you.

 --
 This e-mail, including any attached files, may contain confidential and
 privileged information for the sole use of the intended recipient.  Any
 review, use, distribution, or disclosure by others is strictly prohibited.
 If you are not the intended recipient (or authorized to receive information
 for the intended recipient), please contact the sender by reply e-mail and
 delete all copies of this message.

 -
 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: use of exec in multiple phases

[Manfred Moser]

You should be able to just add another execution into the project pom. The 
plugin mgt will be inherited and merged and voila.

manfred

Johannes Ernst wrote on 13.05.2015 14:17:

 I’d like to invoke exec-maven-plugin with different arguments during
 different phases of the build, and I’m failing. I hope somebody can help me.
 
 This is what works:
 
 parent pom: (invokes a code generator)
 
pluginManagement
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdexec-maven-plugin/artifactId
version1.4.0/version
executions
execution
idgenerate-sources/id
phasegenerate-sources/phase
goals
goalexec/goal
/goals
configuration

 executablecode-generator-executable/executable
….
 
 project pom:
 
build
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdexec-maven-plugin/artifactId
/plugin
….
 
 Now I’d like to also invoke exec just prior to surefire running tests, but
 only in the project pom (not in other projects that use the same parent). So I
 want to attach it to
 
phaseprocess-tests-classes/phase
 
 and for argument’s sake, let’s say I simply want it to invoke “echo ‘I
 succeeded in attaching another exec’”
 
 Where would I declare what?
 
 Thanks,
 
 
 
 Johannes.
 
 P.S. I haven’t gotten any responses to two previous questions on this list
 this month; I hope this one will fare better.
 
 
 -
 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: use of exec in multiple phases

[Manfred Moser]

Correct. If you use the same id it should override the config in the inherited 
one and stick to have one config.

Btw. just run 

mvn help:effective-pom 

to see the inheritance in action. 

Or use the M2e pom editor and check out the effctive pom tab. 

manfred

Christopher wrote on 13.05.2015 16:15:

 You'll probably have to give each execution a unique id.
 
 On Wed, May 13, 2015, 18:32 Manfred Moser manf...@mosabuam.com wrote:
 
 You should be able to just add another execution into the project pom. The
 plugin mgt will be inherited and merged and voila.

 manfred

 Johannes Ernst wrote on 13.05.2015 14:17:

  I’d like to invoke exec-maven-plugin with different arguments during
  different phases of the build, and I’m failing. I hope somebody can help
 me.
 
  This is what works:
 
  parent pom: (invokes a code generator)
 
 pluginManagement
 plugins
 plugin
 groupIdorg.codehaus.mojo/groupId
 artifactIdexec-maven-plugin/artifactId
 version1.4.0/version
 executions
 execution
 idgenerate-sources/id
 phasegenerate-sources/phase
 goals
 goalexec/goal
 /goals
 configuration
 
 executablecode-generator-executable/executable
 ….
 
  project pom:
 
 build
 plugins
 plugin
 groupIdorg.codehaus.mojo/groupId
 artifactIdexec-maven-plugin/artifactId
 /plugin
 ….
 
  Now I’d like to also invoke exec just prior to surefire running tests,
 but
  only in the project pom (not in other projects that use the same
 parent). So I
  want to attach it to
 
 phaseprocess-tests-classes/phase
 
  and for argument’s sake, let’s say I simply want it to invoke “echo
 ‘I
  succeeded in attaching another exec’”
 
  Where would I declare what?
 
  Thanks,
 
 
 
  Johannes.
 
  P.S. I haven’t gotten any responses to two previous questions on this
 list
  this month; I hope this one will fare better.
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 


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


 


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

Android Maven Plugin 4.2.1 released

[Manfred Moser]

The Android Maven Plugin team is pleased to announce the release of version 
4.2.1 of the plugin:

plugin
  groupIdcom.simpligility.maven.plugins/groupId
  artifactIdandroid-maven-plugin/artifactId
  version4.2.1/version
  extensionstrue/extensions
/plugin

New features/bug fixes for the specific release are

- Refactored code base to com.simpligility to follow groupId
- Fixed NPE for undefined versionNamingPattern in ManifestMojo
- Fixed Error generating BuildConfig (ZipException: zip file is empty) if one 
of the dependent AARs has an empty classes.zip
- Updated Android SDK libraries 1.2.2 / 24.2.2
- Support for Junit4 Test Runner based tests

More details on the site in the changelog. 
http://simpligility.github.io/android-maven-plugin/changelog.html

We would like to thank the contributors to this release for their valuable help 
and invite you all to help us out as well:

Specifically for this release we would like to thank the following contributors 
for their awesome work.

Committers for this release

- Manfred Moser http://www.simpligility.com
- Leonid https://github.com/greek1979
- William Ferguson https://github.com/william-ferguson-au
- Hoyt Summers Pittman https://github.com/secondsun

Core Committers and Project Maintainers

- Benoit Billington https://github.com/Shusshu
- Manfred Moser http://www.simpligility.com
- Malachi de AElfweald https://github.com/malachid
- Johan Lindquist https://github.com/johanlindquist
- William Ferguson http://github.com/william-ferguson-au

We would also like to thank the Maven and Android community members and 
everybody else out there for any help we received in our issue tracker and 
beyond.

Release build done by Manfred Moser http://www.simpligility.com

Documentation, issue tracker and more can be found on the plugin websites at

https://github.com/simpligility/android-maven-plugin/
http://simpligility.github.io/android-maven-plugin/

Please join the Maven Android Mailing List for relevant discussions:

https://groups.google.com/forum/?fromgroups#!forum/maven-android-developers

Enjoy and congratulations to everyone involved. 

Manfred Moser
http://www.simpligility.com


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

Android Maven Plugin 4.2.0 released

[Manfred Moser]

The Android Maven Plugin team is pleased to announce the release of version 
4.2.0 of the plugin:

plugin
  groupIdcom.simpligility.maven.plugins/groupId
  artifactIdandroid-maven-plugin/artifactId
  version4.2.0/version
  extensionstrue/extensions
/plugin

New features/bug fixes for the specific release are

- New default value to include internal jars from aar libraries by default
- Don’t include internal libs from transitive AAR deps into an AAR
- Better doco for destinationAndroidManifest parameter
- Project META-INF artifacts are included in APK
- Support for specifying debug port - automatically forward JDWP connection
- Configurable encoding for publish mojo listing files
- Checkstyle - removed deprecated check
- Add NDK support for arm64-v8a APP_ABI
- Log warning about using dependencies conflicting with packaged libraries in 
android jar
- Allow AAR provided proguard configuration to be automatically integrated
- Updated Android SDK libraries 1.1.3 / 24.1.3
- Regex support for VersionGenerator used in AndroidManifest manipulations

For more details please check out the website: 

https://github.com/simpligility/android-maven-plugin/blob/master/src/site/asciidoc/changelog.adoc

We would like to thank the contributors to this release for their valuable help 
and invite you all to help us out as well:

Specifically for this release we would like to thank the following contributors 
for their awesome work.

Committers for this release

- Benoit Billington https://github.com/Shusshu
- Manfred Moser http://www.simpligility.com
- Philip Schiffer https://github.com/hameno
- Matthias Stevens https://github.com/mstevens83
- Marek Kedzierski https://github.com/kedzie
- Jaroslav Tulach https://github.com/jtulach
- Csaba Kozák https://github.com/WonderCsabo
- Arnaud Soulard https://github.com/arnaud-soulard
- Wang Xuerui https://github.com/xen0n

Core Committers
- Benoit Billington https://github.com/Shusshu
- Manfred Moser http://www.simpligility.com
- Malachi de AElfweald https://github.com/malachid
- Johan Lindquist https://github.com/johanlindquist
- William Ferguson http://github.com/william-ferguson-au

We would also like to thank for the help we received from the Maven and Android 
community members and everybody else out there for any help we received in our 
issue tracker and beyond.

Release build done by Manfred Moser http://www.simpligility.com

Documentation, issue tracker and more can be found on the plugin websites at

https://github.com/simpligility/android-maven-plugin/
http://simpligility.github.io/android-maven-plugin/

Please join the Maven Android Mailing List for relevant discussions:

https://groups.google.com/forum/?fromgroups#!forum/maven-android-developers

Enjoy and congratulations to everyone involved. 

Manfred Moser
http://www.simpligility.com

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

Re: Wrong info in Maven: The Complete Reference, chapter 3.6.1

[Manfred Moser]

Just for reference. Sonatype controls this book and I act as the curator of 
changes. There is no active work going on but it is all CC licensed and the 
github repo is available to the public. 

https://github.com/sonatype/maven-reference-en

We do appreciate any pull requests and contributions and I can get them merged 
and published.

The same applies for the example book btw.

https://github.com/sonatype/maven-example-en

Regards

manfred

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

Re: Minimum JDK for mojos

[Manfred Moser]

Sounds like a good idea for the site.. 

manfred

offbynull-maven wrote on 19.03.2015 22:03:

 I understand that. But, shouldn't this be explicitly stated somewhere? 
 Some official guide somewhere essentially saying that if you're planning 
 on releasing your mojo publicly...
 
 to support Maven2 you should be using JDK1.5 or lower (don't actually 
 know if this is correct)
 to support Maven3.0 to 3.2 you should be using JDK1.6 or lower
 to support Maven3.3+ you should be using JDK1.7 or lower
 
 On 3/19/2015 9:47 PM, Ron Wheeler wrote:
 How else will it work?
 If you compile it into Java 8 byte-code, the Java 6 run-time is going 
 to have a tough time running it.

 Ron
 On 20/03/2015 12:31 AM, offbynull-maven wrote:
 If the minimum JDK for Maven3 is JDK1.6, should my custom mojo always 
 be built against JDK1.6 or lower?

 Are there any guidelines around this?

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




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


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

Re: [ANNOUNCEMENT] End Of Life of Maven 2.2.1 - Plugins / JDK Roadmap

[Manfred Moser]

So long, and thanks for all the fish.

And a recommendation for all those embarking on an upgrade. 

Get with the times and take advantage of all the advantages from the latest and 
greatest and move to Maven 3.3.1.

http://blog.soebes.de/blog/2015/03/17/apache-maven-3-dot-3-1-features/
http://takari.io/2015/03/19/core-extensions.html
http://takari.io/2015/03/19/polyglot-maven.html
http://takari.io/2015/03/20/mmp.html

See you on the other side

Manfred

PS: For reference to my quotes.. 
http://www.urbandictionary.com/define.php?term=see+you+on+the+other+side
https://en.wikipedia.org/wiki/So_Long,_and_Thanks_for_All_the_Fish


Karl Heinz Marbaise wrote on 20.03.2015 14:39:

 Dear Maven Users,
 
 based on the End of Life of Maven 2.2.1 (a year ago) now the time has
 come to make the final releases of Apache Maven Plugins which support
 Maven 2.X.
 
 If you continue to use Maven 2.2.1 or earlier you have to be aware of
 using an completely unsupported Maven version as well as unsupported
 Maven plugins for the future.
 
 If you want to have access to new features and bug fixes it is really
 necessary to update to new Maven versions.
 
 The next Maven version which will go the same way as Maven 2.2.1 
 will be Maven 3.0.5.
 
 We have documented the final releases of plugins which support Maven
 2.2.1 in relationship with JDK 1.5.
 
 The complete list can be found here:
 
 http://maven.apache.org/maven-2.x-eol.html
 
 The next step on our roadmap is to lift all plugin versions to 3.0.0 to
 make clear those plugins will only work with Maven 3.0+ furthermore the
 Java minimum requirement will be lifted to JDK 1.6 as well.
 
 No rule without exceptions. Here they come:
 
 * maven-site-plugin (Version 3.4)
   See the docs of the plugin for usage in Maven 2.X
 
 * maven-compiler-plugin (Version 3.2)
   which works with Maven 2.2.1.
 
 * maven-plugin-plugin (Version 3.4)
   which works with Maven 2.2.1
 
 * maven-pmd-plugin (Version 3.4)
   which works with Maven 2.2.1 but needs JDK 1.6
 
 The following plugins already have the Maven 3.0+ requirement:
 
 * maven-scm-publish-plugin (Version 1.1)
 * maven-shade-plugin (Version 2.3)
 
 Currently the plan is to make those plugins which are already at 3.X
 being lifted to version 3.5.0 for Maven 3.X only:
 
 * maven-site-plugin (Version 3.5.0)
 
 * maven-compiler-plugin (Version 3.5.0)
 
 * maven-plugin-plugin (Version 3.5.0)
 
 * maven-pmd-plugin (Version 3.5.0)
 
 All other plugins will get a version 3.0.0 to identify Maven 3.X only
 plugins and the JDK minimum will be 1.6.
 
 Example:
  So to make things more clearer here is an example:
 
  Currently we have the maven-clean-plugin with version 2.6.1.
 
  This plugin supports Maven 2.2.1 and JDK 1.5 minimum.
 
  This plugin will get a new major release with version 3.0.0 
  which has the Maven minimum 3.0 AND Java minimum 1.6.
 
 Kind regards 
 - The Apache Maven Team 
 
 -
 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 3.3.1 Release

[Manfred Moser]

Great news. I love how Maven has picked up the pace and is really moving 
forward a lot again. 

Now given that 3.2.5 is the last relase with Java 6 support .. should that not 
be on the downloads page somewhere? Either replacing 3.1.1 or as an addition.

Personally I think that page should ONLY contain 3.3.1 and all the old releases 
show be on the archive page. Wdyt? 

manfred


Jason van Zyl wrote on 17.03.2015 20:37:

 Hi! 
  
 The Apache Maven Team is pleased to announce the release of 3.3.1 
  
 The official release notes can be found here: 
 http://maven.apache.org/docs/3.3.1/release-notes.html
  
 But Karl Heinz has written up better release notes here:
 http://blog.soebes.de/blog/2015/03/17/apache-maven-3-dot-3-1-features/
 
 The release can be downloaded from: 
 http://maven.apache.org/download.cgi
  
 Full list of changes can be viewed in JIRA: 
 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=21013
 
 Thanks, 
 
 The Maven Team 
 
 
 
 
 
 
 
 
 
 
 
 
 
 -
 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: Do people actually use markdown or should I abandon it and migrate to xdocs?

[Manfred Moser]

I find markdown as a format just too restricted and painful to use. We had good 
success with using asciidoc for the Android Maven Plugin for site generation. 
It uses the very active asciidoctor project for rendering in the site.

http://simpligility.github.io/android-maven-plugin/
 

The Maven and Nexus books are also using asciidoc as a format btw.

https://github.com/sonatype/maven-reference-en
https://github.com/sonatype/nexus-book
https://github.com/sonatype/maven-example-en

Hope that helps. 

Manfred

Kevin Burton wrote on 12.03.2015 14:11:

 I really wanted to live in the future but I think Markdown support in Maven
 is really lacking.
 
 1. it’s super slow.  I have a moderate sized project (10 small files) and
 it takes like 10 minutes to generate my site.
 
 2.  It’s buggy.  If you have two projects and a multi-module build you
 can’t use threaded builds.
 
 Now it looks as if my documentation generation has completely locked up.
 I’m not sure what change I made but 9/10 times I run it locks up in an
 infinite loop.
 
 I imagine if no one else is actually using it then I should probably just
 use what the community is running.
 
 -- 
 
 Founder/CEO Spinn3r.com
 Location: *San Francisco, CA*
 blog: http://burtonator.wordpress.com
 … or check out my Google+ profile
 https://plus.google.com/102718274791889610666/posts
 http://spinn3r.com
 

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

Re: artifactasc/artifactId missing ?

[Manfred Moser]

I can not find it on https://oss.sonatype.org/ or 
https://repository.sonatype.org/ even when logged in.

Manfred

Martin Gainty wrote on 12.03.2015 15:07:

 flex-compiler-mojo identitifies dependency
 dependency
groupIdorg.sonatype.flexmojos/groupId
artifactIdasc/artifactId
version3.0/version
/dependency
 
 which I cannot locate
 any suggestions where to find this artifact would be GREATLY appreciated
 
 thanks/bedankt
 Martin 
 __ 
   

 

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

Re: Maven phase that runs before dependency resolution

[Manfred Moser]

You can do that with a LifecycleParticipant.. the Android Maven Plugin has an 
example that works with the dependencies and deals with resolving transitive 
dependencies of AAR and APKLIB artifacts.

Check it out at 

https://github.com/simpligility/android-maven-plugin/blob/master/src/main/java/com/jayway/maven/plugins/android/phase_prebuild/ClasspathModifierLifecycleParticipant.java

richard_senior wrote on 10.03.2015 09:03:

 There is currently no phase in which you can run a plugin that is before
 dependency resolution.
 I believe this is a problem for Maven.
 Imagine I wanted to create a plugin which could be used by the whole
 company, and enforced a particular version naming strategy.
 So take Spring for example, they are using an RC and RELEASE naming
 convention.
 Imagine I wanted to allow people to name their artifacts _BRANCH_5.
 My plugin with find that and realise that a repository named
 'http://blah/blah/BRANCH_5' should be added to the repositories list (before
 resolution obviously).
 Also, I can now get my plugin to add a different distrubutionManagement
 section allowing the artifacts to be deployed to
 http://blah/blah/BRANCH_5.
 
 By the simple act of naming artifacts I can now manage multiple workstreams
 in my pipeline with ease, and without requiring special settings files or
 parent POM's.
 
 While I'm on the subject of Maven deficiencies, why is it not possible to
 specify distrubutionManagement in settings?
 In fact.. it doesn't matter why... it's wrong.
 Sometimes ... just sometimes.. I do believe I might try Gradle.
 
 
 
 --
 View this message in context:
 http://maven.40175.n5.nabble.com/Maven-phase-that-runs-before-dependency-resolution-tp5828729.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: Why would maven download a pom and not a jar?

[Manfred Moser]

I recently released a first version of my Maven Repository Provisioner tool. It 
can download and subsequently upload all dependencies of any artifact. So you 
should be able to use it or at least code snippets of it to achieve what you 
need.

https://github.com/simpligility/maven-repository-tools/tree/master/maven-repository-provisioner

manfred

Dan wrote on 11.03.2015 08:22:

 Thanks again for the help.  I understand that what I'm doing is not 
 standard, but I still have to implement.
 So I know if i run dependency:tree on a simple pom with no deps, I still 
 get well over 200 artifacts downloaded. So I am also under the 
 assumption that the majority are requirements of maven or the dep plugin 
 rather then my app.
 
 What I really need is a way to determine only the deps (and sub deps) 
 for the application itself.
 
 I have two approaches I'm thinking of taking.
 1. (Doesn't meet the all the requirements, but gets me out of a jam 
 temporarily).   Instead of creating rpms for every artifact, only 
 package up the ones which actually have a jar file in the directory.
 
 2. Parse the output of dependency:tree, and package up only what is 
 listed in that visual ascii tree. (ie: grep '^\[INFO\]').  I'm just 
 don't know if I can be 100% sure that the tree does in fact list 
 everything that I need.
 
 
 
 Here are the somewhat sanitized pom files, and the output i'm getting.
 
 # App 1
 http://pastebin.com/raw.php?i=Dg3Fbaue
 http://pastebin.com/raw.php?i=NEhrtwF4
 
 
 # App 2
 http://pastebin.com/raw.php?i=180zUFLe
 http://pastebin.com/raw.php?i=VEueXysC
 
 
 
 
 
 
 
 
 
 
 
 On 03/11/2015 02:19 AM, Baptiste Mathus wrote:
 Oh right, I didn't get your meaning. You're right, could be that, indeed.
 Should check the plugin sources to be sure.

 2015-03-11 7:06 GMT+01:00 Cintia Del Rio miladyarte...@gmail.com:

 When you invoke the dependency:tree, maven will download the dependency
 tree plugin and all the dependencies it needs to run that plugin.


 So I'd expect that every jar you now have in your local repository (~/.m2)
 is a dependency of the dependency:tree plugin.

 On 11 March 2015 at 17:02, Baptiste Mathus m...@batmat.net wrote:

 Could you rephrase? You think pom.xml is a dependency of the
 dependency:tree goal? If so, then the answer is no.

 Cheers

 2015-03-11 6:59 GMT+01:00 Cintia Del Rio miladyarte...@gmail.com:

 Isn't it a dependency of the dependency plugin itself?

 On 11 March 2015 at 16:51, Baptiste Mathus bmat...@batmat.net wrote:

 Well, in that case, since you're asking for the dependency:tree I'm
 even
 surprised there's any jar downloaded. Maven would only need pom to
 compute
 that. Downloading Jars is only done when needed (say for compiling,
 etc.)
 Btw, do you really type mvn dependency:tree pom.xml ? What do you
 expect?
 The pom.xml part is gonna lead to an error since pom.xml is not a
 goal
 and that's what's supposed to be listed after mvn.

 As for your question: I suppose oro is a transitive dependency of one
 of
 the things you depend on. mvn dependency:tree should generally show
 it
 btw.
 Cheers

 2015-03-10 15:22 GMT+01:00 D C dc12...@gmail.com:

 I am trying to download all dependencies from a pom file.  My steps
 are:
 1. delete .m2/repository
 2. mvn dependency:tree pom.xml

 Everything looks good, however as I browse the .m2 directory I can
 see
 that
 for some artifacts  maven only downloaded the pom file, and did not
 download the associated jar.  I then repeat the process on another
 pom
 file.  This time the jar file is present for that same artifact.

 There are multiple artifacts that this happens on, but for
 troubleshooting
 I'm just focusing on oro-2.0.8.   Neither of my poms declare oro,
 so
 this
 is a sub-dependency somewhere down the chain.  The process can be
 reproduced every time,  and I can see from the output that the
 oro-2.0.8
 pom file is downloaded from the same location (local artifactory)
 in
 both
 cases.


 Does anyone know why maven would download a pom file, and then not
 attempt
 to download the associated jar?


 Thanks,
 Dan



 --
 ---
 Sent from TARDIS. Typos might be a timey whyney thingy.
 Enviado da TARDIS, podem existir erros devido à diferenças de
 espaço-tempo.

 Cintia Del Rio



 
 
 -
 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: TFS or NuGet repository for Maven

[Manfred Moser]

Dale,

At one of my clients we have a large TFS deployment for TFVC and GIT as well as 
a lot of the other SDLC support. However TFS does NOT include support for a 
binary component repository manager like Artifactory or Nexus. And we also 
ended up using Jenkins fyi.

I think you have no real choice but to use repository manager in parallel to 
your TFS server. If you try to put the component/repository management aspect 
into TFS/TFVC with some manual/custom setup you will spend considerable time 
and money getting that working and supporting it.

My suggestion would be to get the development infrastructure support team (same 
team as TFS admins, often called build mgt team, or dev infrastructure or 
SCM...) to take on the role of managing a repo manager.

When it comes to choice of repo manager my suggestions would be to use Sonatype 
Nexus OSS since it gives you support for Maven and NuGet repositories without 
any licensing requirements and is the most widely used repo manager. Nexus OSS 
also includes yum, npm and rubygems support in case you need those. 

Here is the Nexus docs.
http://books.sonatype.com/nexus-book/reference/index.html 

You might also want to read some of the blogs posts regarding Nexus and Nuget 
from Damir Arh.

http://www.sonatype.org/nexus/author/d-arh/

I hope that helps

Manfred

Disclaimer: I also work with Sonatype as Nexus trainer and author among other 
things.


Preston, Dale wrote on 02.03.2015 11:57:

 The .net world uses NuGet for dependency resolution in a way similar, but not
 exactly like, Maven would use Artifactory or Maven repositories.  The newest
 version of TFS will support Maven builds and Java - though all the old 
 versions
 did as well; it was just not as well integrated and required custom build
 scripting.  We'd like to dump our GIT/Artifactory/Jenkins for TFS so that the
 TFS team can support our SDLC environment and our development team doesn't 
 have
 to.
 
 We believe we can do everything except the dependency resolution/repository
 functionality that Artifactory provides in TFS 2015.  The TFS team doesn't 
 want
 to support Artifactory though so we'd end up with split support for our
 environment.  I'd rather keep our SDLC stack than to just give part of it to
 them but I'd love to hand it all off to someone outside of our developer team
 for support so developers can work on coding.
 
 I hope that makes it clearer what it is that I'm trying to accomplish.
 
 Dale
 
 -Original Message-
 From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de] 
 Sent: Monday, March 02, 2015 13:07
 To: Maven Users List
 Subject: [EXTERNAL]Re: TFS or NuGet repository for Maven
 
 Hi,
 
 What do you exactly mean by TFS / NuGet integration for Maven 
 repositories...
 
 A maven repository either in Artifactory or in other repository manager 
 don't need any integration into TFS (version control?) ?
 
 
 Kind regards
 Karl Heinz Marbaise
 On 3/2/15 8:03 PM, Preston, Dale wrote:
 Is anyone aware of any TFS or NuGet integration for Maven repositories?  We
 currently have an Artifactory repository internally for use with Maven but
 would like to integrate with our corporate TFS or NuGet servers for our Jave
 and Maven projects.

 Thanks,

 Dale

 Dale Preston
 Senior Integration Analyst
 Alaska Data Integrator
 918-661-1346 (Desk)
 918-931-9182 (Mobile)


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

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

Re: Do I need to write a plugin for this?

[Manfred Moser]

The Android Maven Plugin and the Android NDK Maven Plugin both implement custom 
packaging types. Albeit they are a bit more complex to look at.. 

http://simpligility.github.io/android-maven-plugin/

http://simpligility.github.io/android-ndk-maven-plugin/

Greg Trasuk wrote on 01.03.2015 23:47:

 
 Hi Anders and Benson:
 
 Nothing to do with this question, but I’m curious for another project - could
 you point me towards a good example of a custom packaging type plugin?
 
 Thanks,
 
 Greg Trasuk
 
 On Mar 2, 2015, at 1:30 AM, Anders Hammar and...@hammar.net wrote:
 
 In that case you do, yes. That's called a custom packaging type and is
 implemented via a plugin.
 But you can also accomplish the upload by having a pom packaging and
 specify the cba file with the build-helper plugin as Benson wrote.
 
 /Anders (mobile)
 Den 2 mar 2015 07:25 skrev Bruce Albrecht br...@maven.zuhause.org:
 
 However, if I want my pom to have packaging of cba, it's my impression
 that I need to write a plugin.  It's the only artifact I want to upload
 to Nexus.
 
 On 03/01/15 20:42, Benson Margulies wrote:
 I don't understand your question at all. In Maven, you can just use the
 build-helper-maven-plugin to attach any file to the project, causing it
 to
 upload. So, you can certainly use antrun to run the ant build, and the
 helper to attach the result as an artifact.
 
 On Sun, Mar 1, 2015 at 4:18 PM, Bruce Albrecht br...@maven.zuhause.org
 wrote:
 
 I am working on a project that creates OSGI bundles with an extension of
 .cba and today uses ant to invoke a workbench to build the .cba file.  I
 want to upload the .cba file to my Nexus repository. My initial take on
 this is that if IBM didn't use its own extension for this, I would be
 able to just use the antrun 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
 
 
 
 
 -
 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: write developers contributors into Jar

[Manfred Moser]

If you want to just have the information in the jar somewhere, the pom file 
will already be in the jar by default. This is due to the archiver config 
addMavenDescriptor set to true.

See http://maven.apache.org/shared/maven-archiver/index.html for the location 
of the pom file and further archiver config details. 

manfred

Philipp Kraus wrote on 01.03.2015 03:41:

 
 Hello,
 
 I use Maven 3.0 with the developers and contributors inside the pom.xml. I use
 also the manifestEntries with the maven-assembly-plugin to add some flags to
 the Jar manifest file.
 I would like to add the developer and contributors list to the Jar, but I
 don’t know in which way I can add a list with name, email, and role types. My
 idea is that I create a comma separated list
 list with the data, but how can I create within the pom.xml the correct output
 list? E.g. the pom.xml stores:
 
 developers
   developer
   idmyID/id
   namemyName/id
   emailmyName@myDomain/email
   roles
rolearchitect/role
roledeveloper/role
  /role
   /developer
 /developers
 
 so in the manifest should be a line e.g.
 
 Developers = myName - myName@myDomain - architect / developer,
 
 I have tried to define it with
 
 manifestEntries
 Developers${project.developers}/Developers
 /manifestEntries
 
 but this writes only the Java object items to the entry. How can I create a
 loop / xquery within the pom.xml to iterate over the developer items?
 
 Thanks
 
 Phil
 
 
 

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

Re: takari-plugin-integration-testing requires one takari-jar project ?

[Manfred Moser]

Olivier Lamy wrote on 26.02.2015 15:26:

 As it looks the question is related to an other project which is not hosted
 within the Apache Maven project neither developed by Apache Maven
 committers.
 I believe this mailing list is related to the Apache Maven project.
 So my goal was only to help Cristiano and tell him to ask in the place
 where this project is hosted and to the people who maintained it.
 It's probably better to have more accurate answers.

Hm.. I tend to disagree. Imho this mailing list is about using Apache Maven. 
Not matter what plugins your are using, where they are hosted, or whatever. If 
there is a more specific mailing list then we can redirect, but generally this 
should be the big bucket of it all. 

E.g. the Android Maven Plugin and related projects has its own mailing list, 
but I still send release announcements here and answer questions here as well 
and I think the same should apply for all other plugins. 

Manfred

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

Re: takari-plugin-integration-testing requires one takari-jar project ?

[Manfred Moser]

Yes... but we should be inclusive and generally allowing the questions and were 
needed redirect to better forums if we are aware of them. 

And when comparing it to Ubuntu... there are the big mailing lists that answer 
all these kind of questions are a general busy hub of everything. 

I think such a busy hub would be good for Maven. Currently everything is way 
dispersed and that harms the project in my opinion since it looks like there is 
nothing going on. 

The main users mailing list/forum for Maven should be busy considering how many 
users there are and not quiet like the list currently is.  

Manfred

Curtis Rueden wrote on 27.02.2015 15:15:

 Hi Manfred,
 
 I think the same should apply for all other plugins.
 
 By that logic, an Ubuntu Linux mailing list should answer all questions
 about all packages available for Ubuntu, even multiverse packages. Seems
 impossible to me.
 
 That said, of course the people here are friendly and make a best effort to
 help. But you can't really help much with some random third party closed
 source Maven plugin. I agree with Olivier that asking the authors in cases
 like that would be much more likely to yield a solution.
 
 Regards,
 Curtis
 
 On Fri, Feb 27, 2015 at 1:18 PM, Manfred Moser manf...@mosabuam.com wrote:
 


 Olivier Lamy wrote on 26.02.2015 15:26:

  As it looks the question is related to an other project which is not
 hosted
  within the Apache Maven project neither developed by Apache Maven
  committers.
  I believe this mailing list is related to the Apache Maven project.
  So my goal was only to help Cristiano and tell him to ask in the place
  where this project is hosted and to the people who maintained it.
  It's probably better to have more accurate answers.

 Hm.. I tend to disagree. Imho this mailing list is about using Apache
 Maven. Not matter what plugins your are using, where they are hosted, or
 whatever. If there is a more specific mailing list then we can redirect,
 but generally this should be the big bucket of it all.

 E.g. the Android Maven Plugin and related projects has its own mailing
 list, but I still send release announcements here and answer questions here
 as well and I think the same should apply for all other plugins.

 Manfred

 -
 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: takari-plugin-integration-testing requires one takari-jar project ?

[Manfred Moser]

Cristiano,

You can have them all in one project. E.g. the Android Maven Plugin does that. 

https://github.com/simpligility/android-maven-plugin

Olivier,

I thought this is a Maven users mailing list and as such open to all questions 
regarding usage of Maven. I would understand the need to separate things out if 
there is tons of traffic ( 100 posts a day or so) but as it stands the list is 
rather quiet so I think it should be fine to discuss anything related to Maven 
usage here.

Do you agree?

Manfred

Olivier Lamy wrote on 25.02.2015 18:23:

 Hi,
 AFAIK this Takari project is not hosted neither maintained here at Apache
 by Apache Maven developers.
 So for any questions please ask directly maintainers or find a user group
 related to it (maybe it's documented on their website).
 
 Cheers
 Olivier
 
 On 26 February 2015 at 03:52, Cristiano Gavião cvgav...@gmail.com wrote:
 
 Hi,

 It is necessary to concentrate the maven plugin integration tests in its
 own  takari-jar project ?

 I'm asking because I have test poms inside src/test/projects being
 duplicated on both Plugin and Plugin IT projects.
 Maybe I could put both UT and IT in the same plugin project ?

 thanks,

 Cristiano

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


 
 
 -- 
 Olivier Lamy
 http://twitter.com/olamy | http://linkedin.com/in/olamy
 

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

Android Maven Plugin 4.1.1. released

[Manfred Moser]

The Android Maven Plugin team is pleased to announce the release of version 
4.1.1 of the plugin:

plugin
  groupIdcom.simpligility.maven.plugins/groupId
  artifactIdandroid-maven-plugin/artifactId
  version4.1.1/version
  extensionstrue/extensions
/plugin


New features/bug fixes for the specific release are

- Added Manifest Merger v2 example (tictactoe)  Deprecated merge manifest v1
- Added proguard support from library (AAR) projects
- Corrected unpackedLibsFolder default value
- Documentation updates for the site rendering
- Change default value for aidlSourceDirectory to src/main/aidl
- Fix to allow both release-plugin and IDEs to correctly consume AAR deps.
- Updated Takari lifecyle and integration testing setup to new releases
- Improvement of versionCode generator

https://github.com/simpligility/android-maven-plugin/blob/master/src/site/asciidoc/changelog.adoc

We would like to thank the contributors to this release for their valuable help 
and invite you all to help us out as well:

Specifically for this release we would like to thank the following contributors 
for their awesome work.

Core Committers
- Benoit Billington https://github.com/Shusshu
- Manfred Moser http://www.simpligility.com
- Malachi de AElfweald https://github.com/malachid
- Johan Lindquist https://github.com/johanlindquist
- William Ferguson http://github.com/william-ferguson-au

Committers for this release

- Benoit Billington https://github.com/Shusshu
- Manfred Moser http://www.simpligility.com
- David Sobreira Marques https://github.com/dpsm
- Igor Fedorenko https://github.com/ifedorenko
- Hoyt Summers Pittman https://github.com/secondsun
- Csaba Kozák https://github.com/WonderCsabo
- Pappy Stanescu https://github.com/pa314159

We would also like to thank for the help we received from the Maven community 
members and everybody else out there for any help we received in our issue 
tracker and beyond.

Release build done by  Manfred Moser http://www.simpligility.com

Documentation, issue tracker and more can be found on the plugin websites at

https://github.com/simpligility/android-maven-plugin/
http://simpligility.github.io/android-maven-plugin/

Please join the Maven Android Mailing List for relevant discussions:

https://groups.google.com/forum/?fromgroups#!forum/maven-android-developers

Enjoy and congratulations to everyone involved. 

Manfred Moser
http://www.simpligility.com

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

Re: Kudos to Takari's http://takari.io/book/70-testing.html#plugin-integration-testing

[Manfred Moser]

We are glad you enjoy using it. If you have any feedback or suggestions 
regarding the plugin, documentation and so on please create issues related 
projects on github.

https://github.com/takari/takari-lifecycle

https://github.com/takari/takari-plugin-testing-project

It would also be great if you could share where you are using it. E.g. I have 
implemented the usage of this in the Android Maven Plugin.

https://github.com/simpligility/android-maven-plugin

It runs through a number of tests there that create Android libraries and 
applications, deploys them to all attached devices and runs integration test 
including screenshot creation and more there.

Manfred


Jason van Zyl wrote on 16.01.2015 12:22:

 Thanks!
 
 On Jan 16, 2015, at 12:43 PM, Dan Tran dant...@gmail.com wrote:
 
 I started to use this plugin for my plugin IT test. Writing maven plugin is
 now much more fun
 
 Very much appreciate the work
 
 
 -Dan
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder, Takari and Apache Maven
 http://twitter.com/jvanzyl
 http://twitter.com/takari_io
 -
 
 Be not afraid of growing slowly, be only afraid of standing still.
 
 -- Chinese Proverb
 
 
 
 
 
 
 
 
 
 
 
 
 
 -
 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