Re: Can a plugin permit a dependency override by the user setting a simple option?

[Jörg Schaible]

On Wednesday, 7. February 2024, 01:00:50 CET Alexander Kriegisch wrote:
> 3rd party parent? Are you maybe mixing up my questions about different
> topics? There is not parent POM involved here, it is about a plugin and an
> application using it.

You talk about "override by the user" which implies some kind of inheritance, 
at least 
for me.

> Very simple and straightforward. I even gave an
> example of what does not work for me but you say should.

So strait forward:

 
  org.acme
  xy-compiler-plugin
  1.2.3
  

  org.xy
  xy-compiler
  ${xy.compilerVersion}

  
 

... somewhere in a child ...


  4.5


> So does it?

It does. If this is not, what you want, you will have to ask in a different 
way, since Lasse 
also understood your question the way I answered.

> If you do not know, it is OK. But if you want to help, the ball
> is in your court now. A counter-example showing me how to do what you
> suggested right would be most welcome.

Actually I don't like your tone and I get the impression that we waist each 
other's time.

So I'll shut up,
Jörg

Re: Can a plugin permit a dependency override by the user setting a simple option?

[Jörg Schaible]

Hi Alexander,

On Tuesday, 6. February 2024, 02:39:09 CET Alexander Kriegisch wrote:
> Jörg,
> 
> I asked for a working example and not theory for a reason: The plugin
> POM already uses properties, and it simply does not work to override
> them.

Since you seem to use a 3rd party parent, is it public? Then you could tell us 
which one...

[snip example]

> Overriding the property in the project using the plugin does not seem to
> have any effect. I verified that the plugin POM still contains the
> property and the version number is not flattened in any way.
> 
> Is this even supposed to work like that? Are plugin properties
> overridable like this? It would be nice, but I guess they are not part
> of the reactor. That is also the reason why my project can use one
> version of a dependency and a plugin can use another one without them
> affecting each other.

This failed for me only, when I tried to make the version of a Maven extension 
configurable.

> So please, if you have a working example for what you say should work,
> please provide it, so I can reproducer what you recommend me to do.

Give me a head start by pointing me to the parent pom.

Regards,
Jörg



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

Re: How to completely override/replace parent's site.xml

[Jörg Schaible]

Hi Alexander,

On Tuesday, 6. February 2024, 02:18:36 CET Alexander Kriegisch wrote:
> Thanks Jörg,
> 
> but that does not answer my question. I do not want to generate a site
> for the parent. I am talking about the module using the parent POM. BTW,
> the parent POM is not even under my control, it is from another
> organisation.

OK, this is something I absolutely avoid. Typically I have a standalone parent 
for the company/entity/whatever that can be used for all projects sharing 
global stuff like emails, SCM URLs, URLs for distributions sites, versions, 
etc. And it is a great place for profile definitions with preconfigured plugins 
to build all kind of artifact types relevant for your entity.

> I am consuming it, because I like the defaults for plugin
> and dependency versions and configurations.

If I really need something, I copy it over and adjust it to our naming 
conventions. Always keep control of your own build.

I know that projects like spring-boot give a different advice, but typically 
you're then left alone with all the other configuration stuff. Then you will 
have to add entries to your own POMs everywhere e.g. for deployment, 
distribution, etc. and cannot use properties for the shared stuff like domains 
in emails, all kind of URLs. Maintenance is getting harder, if something of 
this changes.

> Only the site.xml annoys me.
> I do not want their menu structure and logo in my app's Maven site. The
> problem is, as I described: I do not know how to use the parent POM
> without also being forced to use the paren site.xml, which is attached
> to the artifact. This inheritance is nice, but I need a way to avoid,
> override or overrule it and make Maven Site Plugin use my own site.xml
> exclusively.

No help for this case, sorry.

Regards,
Jörg



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

Re: How to completely override/replace parent's site.xml

[Jörg Schaible]

Hi Alexander,

On Monday, 5. February 2024, 05:36:35 schrieb Alexander Kriegisch wrote:
> Neither in [1] nor in [2] I can find a way to completely disregard or
> override a site.xml from the parent POM. I want to inherit a lot from a
> specific parent POM, such as dependency management and properties, but not
> the site.xml. Is there a way to do that?
> 
> E.g., [2] seems to imply that if I define my own breadcrumbs, they override
> the parent's ones, but that is not true. I also cannot eliminate the
> bannerLeft from the parent, only override it. But I do not want any banner
> at all. Sorry for asking a maybe simple-minded question like this, but for
> the life of me, I cannot find the solution using web search, documentation
> or trial & error.
> 
> [1]
> https://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.
> html [2]
> https://maven.apache.org/plugins/maven-site-plugin/examples/multimodule.htm
> l

You can achieve a separate site generation for the parent only by using a 
profile and an own site directory:

1/ use src/site-parent in the parent pom's project for its site content
2/ define a profile that us automatically activated id the directory src/site-
parent exists
3/ configure the site plugin's siteDirectory parameter to use src/site-parent

The trick is that the profile is automatically enabled, when you build the 
parent project, but it is never active in any other project, since none has an 
existing src/site-parent directory.

Regards,
Jörg



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

Re: Can a plugin permit a dependency override by the user setting a simple option?

[Jörg Schaible]

Hello Alexander,

On Sunday, 4. February 2024, 04:20:22 CET Alexander Kriegisch write:
> Hi Jörg.
> 
> Thanks for the reply. Can you please elaborate with examples? Option 1
> is what I need, but that does not work. Or maybe we have a
> misunderstanding about the term "property". Are we talking about a
> simple Maven property or a mojo configuration property?

We're talking about "simple" Maven properties. However, since we talk about 
dependencies of a plugin, there's one important thing to know: A plugin is 
loaded only once in a reactor, i.e. its first usage will define its 
dependencies. And, the property approach will not work, if you flatten your 
parent pom, i.e. the property is replaced by its value before deploying to a 
repository.

Regards,
Jörg




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

Re: Can a plugin permit a dependency override by the user setting a simple option?

[Jörg Schaible]

Hi Alexander,

On Saturday, 3. February 2024, 06:03:27 CET Alexander Kriegisch wrote:
> Many plugins, e.g. compiler plugins, depend on other libraries, in this
> case compilers. This is true for plugins such as Plexus Compiler,
> AspectJ Maven, GMaven+. Usually, what a user needs to do to override the
> default provided by the plugin (which is almost never exactly the
> version the user wants), the user does something like:
> 
> 
>   org.acme
>   xy-compiler-plugin
>   1.2.3
>   
> 
>   org.xy
>   xy-compiler
>   4.5
> 
>   
> 
> 
> While this is not so much work, I was wondering if there is any way to
> make it a little bit easier for the user as a plugin developer, so she
> can do this instead:
> 
> 
>   org.acme
>   xy-compiler-plugin
>   1.2.3
>   
> 4.5
>   
> 
> 
> My current knowledge of the Maven Way says, this is not possible. But I
> am asking anyway, just because I am curious and did not find any helpful
> resources online.

There are several approaches, depending on the use case:

1/ It is always the same dependency, the user just wants to use different 
versions. Solution: Use a property for the version. The user can then 
overwrite the property in his pom.

2/ The user should be able to use a different dependency. The approach with the 
property works here also, just use it also for the groupId and artifactId.

3/ The user must not use a single dependency that varies, but several. Here 
you may take an approach with different profiles. Best practice here is to 
activate the profiles by existing of a (relative) file e.g. in a local profile 
folder.

And you may combine these approaches. Check the result with help:effective-pom 
where you can see, what Maven internally generates as pom for an individual 
project.

Regards,
Jörg

Regards,
Jörg



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

Re: Modifying classifiers of transitive dependencies

[Jörg Schaible]

On Wednesday, 31. January 2024, 16:34:22 CET Mansour Al Akeel wrote:
> We have a large number of legacy dependencies that we need to sign. I am
> trying to cache those that are not signed into an internal repository to
> reduce build time.
> 
> So I created another project to sign them and load them into our private
> repository. I am using a classifier to indicate the signed ones. For
> example, signed. Those are pulled properly.
> However, those dependencies have many transitive dependencies that are
> signed as well, but not pulled. The reason is because in the original pom,
> they point to the unsigned ones.
> 
> What is the best (maven) way to resolve this? I can simply ignore the
> classifier part I guess as a simple solution.
> 
> I will appreciate a better approach.

Using the classifier is a really bad choice, since it is used for all kind of 
supplemental artifacts, like source, javadoc, etc. and it will spoil 
completely any kind of transitive dependency management.

You may instead use own versions, just append "-signed" to it. While you have 
now still the old version in the poms, you can have yourself common a parent 
pom that declares all required dependencies in a dependencyManagement section. 
Here you can also overwrite the version to use (the one with the postfix) for 
each dependency transitively. Now you can declare in your projects still the 
directly required dependencies and you will nevertheless get anything that is 
required transitively. And you will immediately see, if something unsigned is 
used looking at the dependency tree.

Downside is, that you will always have to monitor, what other/new transitive 
dependencies are used, when you want to update one of your directly used ones. 
But with your signing you will have to do this anyway.

As best practice: Declare the versions with properties and do never declare 
directly any version the dependencies of a local pom, just omit the version 
element completely. As benefit you're able to overwrite any version from 
command line using that property.

You may even have a profile to build anything with unsigned dependencies. Just 
declare the postfix itself as property that can be overwritten e.g. using a 
profile:

 
   
 unsigned
 
   
 
   
 

 
   -signed
   2-6${version.postfix}
 

Regards,
Jörg





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

Re: Version Management in 'mvn dependency:tree'

[Jörg Schaible]

On Wednesday, 1. November 2023, 06:37:31 CET yukai zhao wrote:
> Thank you for your response!
> Additionally, I've noticed that in this situation, if I delete 3.12.0 from
> my local repository and then recompile the project, Maven still downloads
> 3.12.0. Is this behavior normal?

In this case, yes, because the core of Maven 3.9.4 is actually  *using* this 
version when you run it. This has nothing to do with the classpath of a 
project where you're using maven-core as dependency.

Regards,
Jörg



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

Re: Confused about how to override a transient artifact version

[Jörg Schaible]

Hi David,

On Saturday , 29. July 2023, 01:29:14 CEST David Karr wrote:
> In general, I know how to override transient artifact versions. You add an
> "exclusion" for the artifact on the dependency that is including that
> dependency, and then you manually add that dependency in the same pom where
> you added the exclusion.

Well, no. You do have to use exclusions only, if group or artifact is 
different, but not for the version. For all artifacts you want to maintain the 
version yourself, you add a managementDependencies section to  your current 
POM or even better to a common parent POM where you maintain versions for a 
couple of (sub-)projects.

> In my case, the version I want is defined in a
> bom in our parent pom, so I don't have to specify the version in that
> dependency.
> 
> This works fine, if I do this exclusion and inclusion in the overall "child
> pom".
> 
> However, I maintain the parent pom and platform, and there will be dozens
> of "child poms" that will need to do this.  I would much rather do this
> "fixup" in the poms for the libraries in our platform.  Those poms specify
> the dependencies whose versions I need to control.

This is exactly the right lace for a common dependencyManagement section.

> I've been struggling with trying to do this, along with trying to
> understand the output of "mvn dependency:tree" and the apparently
> functionally similar output in the "Dependency Hierarchy" view in Eclipse
> using the m2e plugin.

I'd not rely on that, since AFAICS Eclipse (resp. m2e) will do its own thing 
resolving Maven deps.

> Although I can loosely see the hierarchical output
> from these, I find determining the actual details of where dependencies are
> coming from is very mystifying.
> 
> To get down to actual details, my problem is that I'm ending up with
> different versions of "jackson-core" and "jackson-databind".  I need to
> ensure that I have the same versions of both.  I am getting v2.14.1 of
> jackson-databind and v2.13.5 of jackson-core.  We are specifying v2.13.5 in
> our parent pom, but somehow something in the tree is giving us v2.14.1 of
> jackson-databind.

The only thing that might affect your own definitions in a dependencyManagement 
section are imports of other POMs (typically called BOMs) in this section, 
since their dependencies will behave as if they where defined in your 
dependencyManagement section also.

Currently I am not sure if your own definitions take precedence if you define 
those before or after importing a bom, but that you can easily check with the 
dependency:tree

So simply add the two jackson artifacts with the required version to your own 
depMgmnt section.

[snip]

> 
> I'm very confused.
> 
> I think I remember seeing discussions in the dev list about improving the
> output of dependency:tree to be clearer, I don't know if there's been any
> progress on that.

Regards,
Jörg



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

Re: AW: [m-deploy-plugin] Deploy javadoc archive only

[Jörg Schaible]

Hi Bernhard,

[snip]

> Initially I tried to find a solution with a short command to produce and
> deploy the javadoc archive manually. However, the next step is anyway to
> automate this process and then it's less of a problem to split creation of
> the javadoc archive and deploying it into two steps – and use
> deploy:deploy-file with all needed parameters ('file', 'url', etc.) – which
> I intended to avoid, I thought I'd rather configure it in the POM (like
> distributionManagement) instead of command arguments.

as alternative you may use package of type pom and create the javadoc as part 
of this project. They you can configure the build-helper plugin to attach this 
jar file with classifier javadoc. Now you have a "proper" Maven project that 
deploys the attached jar file as part of its deployment phase.

Cheers,
Jörg

BTW: Gruß aus dem Schwarzwald :-)




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

Re: Tricky dependencies in multi module projects

[Jörg Schaible]

Hi,

simply declare the dependency with scope "provided" in the project that shades 
it.

Regards,
Jörg

On Fritday, 8. July 2022, 17:43:16 CEST Francois Marot wote:
> Hello Niels,
> 
> I believe you used the shade maven plugin or equivalent. I faced this
> problem multiple times and to my knowledge, there is no "good" solution.
> The problem is that Maven computes the dependency graph for all modules of
> the reactor right at the start. But when the shade plugin integrates ANTLR
> inside your library, this library should not depend onto ANTLR anymore. But
> because the dependency graph was computed at the start,
> other modules of the reactor depending onto your library still depend onto
> ANTLR even if there is already a shaded version of ANTLR inside your
> library.
> 
> So in the end, in the same reactor execution, module MUST NOT depend onto a
> shaded module. They must be considered as 'final' modules.
> 
> I hope this may help
> François
> 
> 
> *- - - - -François Marot06 50 91 96 38*
> 
> Le ven. 8 juil. 2022 à 16:51, Niels Basjes  a écrit :
> > Hi,
> > 
> > I have a library project that uses dependencies that are prone to cause
> > conflicts when another project wants to use my software.
> > Antlr4 is a common example because it enforces the versions of the
> > generated code and the runtime to be an exact match.
> > 
> > In my maven project I have a main library and to avoid conflicts in
> > downstream applications the antlr4-runtime has been shaded and relocated
> > to
> > a different package name.
> > Using this modified jar in any project works as expected.
> > 
> > When I want to use this in a different maven module of the same project it
> > does not work like that.
> > In my multi module maven project I found that the other modules (UDFs,
> > demo
> > webservlet, etc)  use the unshaded variant of the library, which sometimes
> > causes conflicts.
> > I think this is how the maven reactor is intended to work.
> > 
> > Essentially I think I want to have the option to make a specific module of
> > my project be built as-if it is an external project (i.e. "outside" the
> > reactor).
> > 
> > So far I have only found the invoker plugin to be a way to make this
> > happen.
> > 
> > What is the recommended way to handle this?
> > 
> > --
> > Best regards / Met vriendelijke groeten,
> > 
> > Niels Basjes





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

Re: How to produce a pom.xml that is guaranteed to fail, with specific error messages

[Jörg Schaible]

Hi David,

On Wednesday, 30. March 2022, 19:46:35 CEST David Karr wrote:
> I work in a large company on a large project with hundreds of services,
> most of which are Java Maven projects.  We have an "archetype" we use for
> new services. It doesn't use the Maven archetype process.  There are
> particular areas in the pom.xml that is generated that really need to be
> modified by the developer to reflect their actual application.
> 
> We could certainly put comments in the template that tell the developer
> what sort of changes need to be made, but I wonder if there's any way we
> can ensure that they notice and handle particular areas of the pom.xml.
> Just generating a comment with directions isn't enough.  I wish there was
> some way I could ensure that running the build would fail with a specific
> error message if they haven't dealt with each area. I suppose I could
> create an XML syntax error in each area that should be addressed, with text
> near the error that explains what to do, but that seems like a bit of a
> hack, although it may be the only strategy I can use.  Is there a cleaner
> way to do this sort of thing that I'm not aware of?

Add the maven-verifier-plugin and a verification file to your archetype, bind 
it 
to the validation phase and check the content of the pom.xml. If it still 
contains your placeholders, it can fail your build.

Regards,
Jörg




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

Re: Maven 3.6.3 configuration enquiry

[Jörg Schaible]

Am Donnerstag, 7. Januar 2021, 20:23:27 CET schrieb Bernd Eckenfels:
> You did not say what build servers you use, but normally you can have many
> different maven versions installed in different directories. Usually CI
> servers are fine to pick one (some like Jenkins can even install them
> dynamically).
> 
> If you do it, you need to watch out for not using/inheriting environment
> variables (especially PATH, java and maven home), when using a user/global
> settings.xml it should be valid for all versions (it usually is) or specify
> a unique file for each environment with the -s flag. Also make sure to
> specify the full path to the mvn launcher. Some plugins like maven release
> plugin also prefer if you set the correct M2_HOME env variable.

Best is not to set it at all. Then it is automatically set by the individual 
shell script that starts Maven (bin/mvn or bin/mvn.cmd) and will automatically 
point to the current Maven in use.

[snip]

Cheers,
Jörg




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

Re: [ANN] Apache Maven JLink Plugin Version 3.0.0 Released

[Jörg Schaible]

Hallo Karl- Heinz,

Am Mittwoch, 25. November 2020, 20:49:52 CET schrieb Karl Heinz Marbaise:
> The Apache Maven team is pleased to announce the release of the Apache Maven
> JLink Plugin, version 3.0.0

Here we have the description for the dependency plugin:

> The dependency plugin provides the capability to manipulate artifacts. It
> can copy and/or unpack artifacts from local or remote repositories to a
> specified location.

[snip]

Cheers,
Jörg



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

Re: How to use error-prone 2.3.4 plugin with Maven

[Jörg Schaible]

Just overwrite that property from command line:

docker run -it --rm -v $HOME/.m2:/root/.m2 -v $PWD:/root/trellis-t3 -w
/root/trellis-t3 maven:latest mvn clean install -Derrorprone.version=2.3.4

BTW: That's one of the reasons to declare all versions with properties in POMs.

Am Mittwoch, 18. November 2020, 16:01:05 CET schrieb Chris Ward:


I see

 2.3.3

in file ~/.m2/repository/org/onosproject/onos-dependencies/2.2.7-b2/onos-
dependencies-2.2.7-b2.pom , but it's apparent that I'm not supposed to edit 
this file; it is
owned by root, and there is what looks like a sha1 of the file in the same 
directory as if
Maven is intending to detect changes.


So where is Maven getting this from into its cache ? That is, where do I find 
the original
2.3.3 so that I can change it to 2.3.4 
?

On 2020/11/18 11:39:05, Maarten Mulders  wrote:
> Hello Chris,>
>
> By issuing mvn help:effective-pom -Dverbose=true, you can inspect the >
> "effective POM". It will show you where the version of the Error Prone >
> is selected:>
>
>  2.3.3>
>  >
>
> (you may need to scroll a bit, it's pretty much near the top of the output)>
>
> The version of Error Prone is selected from the parent module, >

*T J (Chris) Ward, IBM Research.
Scalable Data-Centric Computing - IBM Spectrum MPI
IBM United Kingdom Ltd., Hursley Park, Winchester, Hants, SO21 2JN
011-44-1962-818679
LinkedIn https://www.linkedin.com/in/tjcward/[1]
ResearchGate https://www.researchgate.net/profile/Thomas_Ward16[2]


IBM Research -- Data Centric Systems[3]
IBM Supercomputer Marketing[4]


IBM Branded Products[5] IBM Branded Swag[6] *
[7]


UNIX in the Cloud - Find A Place Where There's Room To Grow, with the original 
Open
Standard. Free Trial Here Today[8]
Protein Folding by Supercomputer - BlueMatter[9] Molecular Dynamics package.
Data Tables - In-memory key-value store[10] package.
Linux on Windows - Virtualisation[11] package. On the Lighthouse !


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU




[1] https://www.linkedin.com/in/tjcward/
[2] https://www.researchgate.net/profile/Thomas_Ward16
[3] http://www.research.ibm.com/artificial-intelligence/hardware/
[4] https://www.ibm.com/it-infrastructure/power/scale-out
[5] https://www.ibm.com/products
[6] https://logostore-globalid.us/
[7] cid:_2_DDABDAF8DDABD54800527E0B80258624
[8] http://sdf.lonestar.org/index.cgi?telnet
[9] https://github.ibm.com/TJCW/BlueMatter
[10] https://github.ibm.com/TJCW/tx-cics-tables
[11] https://w3-03.ibm.com/services/lighthouse/documents/124087

Re: AW: Creating JAR file in WAR module leads to error in EAR creation

[Jörg Schaible]

Am Donnerstag, 12. November 2020, 14:13:42 CET schrieb Hohl, Gerrit:
> Hello everyone,
> 
> 
> maybe some additional information will be helpful.
> The project structure is like (and also build in this order due to the
> dependencies of the modules):
> 
> - XXX-pom
>   - XXX-ejb
>   - XXX-web
>   - XXX-ear

[snip]

You should not mix-up both artifacts for Maven. From Mavens PoV they are the 
same (because they have the same G:A:V). Look at the configuration options for 
the WAR plugin. You can generate automatically a jar file for the classes with 
an own classifier which is automatically attached. Use that one to refer in 
your EAR build.

Cheers,
Jörg



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

Re: Merged configuration between parent & child?

[Jörg Schaible]

If you put your configuration additionally into a profile in the parent, that is
activated e.g. on the existence of the file "profiles/lombok". Then you can
simply create that in those child projects individually that use the
processor. Personally I share typically the profile's name with the one of the
file in the profiles directory...

On Thursday, 15. October 2020, 13:24:41 CEST Andres Almiray wrote:
> Thank you Anders, the `combine.children="append"` attribute applied to the
> child's  element does the trick.
>
> Wonderful!
>
> On Thu, Oct 15, 2020 at 12:54 PM Anders Hammar  wrote:
> > Maybe this blog post helps:
> >
> > https://blog.sonatype.com/2011/01/maven-how-to-merging-plugin-configuratio
> > n-in-complex-projects/
> >
> > /Anders
> >
> > On Thu, Oct 15, 2020 at 12:25 PM Andres Almiray 
> >
> > wrote:
> > > Hello everyone,
> > >
> > > I wonder if it's possible to define a plugin's configuration on both
> >
> > parent
> >
> > > & child in such a way that the resulting configuration is merged, first
> > > the  parent's then the child's. My use case is defining a set of
> >
> > annotation
> >
> > > processors in the maven-compiler-plugin at the parent, also adding
> >
> > another
> >
> > > set in the child's maven-compiler-plugin.
> > >
> > > The following example is NOT explicitly related to Lombok nor AutoValue,
> > > they are used just as reference. Suggestions to skip Lombok and/or
> > > AutoValue are not needed, thanks.
> > >
> > > Given a parent pom such as
> > >
> > > http://maven.apache.org/POM/4.0.0; xmlns:xsi="
> > > http://www.w3.org/2001/XMLSchema-instance;
> > >
> > >  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> > >
> > > http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> > >
> > > 4.0.0
> > > com.acme
> > > parent
> > > 0.0.0
> > > pom
> > >
> > > 
> > >
> > > 1.7.4
> > > 1.18.14
> > >
> > > 
> > >
> > > 
> > >
> > > 
> > >
> > > 
> > >
> > > 
> > >
> > >   org.apache.maven.plugins
> > >   maven-compiler-plugin
> > >   3.8.1
> > >   
> > >
> > >   
> > >
> > >   
> > >
> > >   org.projectlombok
> > >   lombok
> > >   1.18.14
> > >
> > >   
> > >
> > >   
> > >
> > >   
> > >
> > > 
> > >
> > > 
> > >
> > > 
> > >
> > > 
> > >
> > > 
> > >
> > > And a child pom as
> > >
> > > http://maven.apache.org/POM/4.0.0; xmlns:xsi="
> > > http://www.w3.org/2001/XMLSchema-instance;
> > >
> > >  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> > >
> > > http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> > >
> > > 4.0.0
> > >
> > > 
> > >
> > > com.acme
> > > parent
> > > 0.0.0
> > >
> > > 
> > >
> > > child
> > >
> > > 
> > >
> > > 
> > >
> > > 
> > >
> > >   org.apache.maven.plugins
> > >   maven-compiler-plugin
> > >   3.8.1
> > >   true
> > >   
> > >
> > >   
> > >
> > >   
> > >
> > >   com.google.auto.value
> > >   auto-value
> > >   ${auto-value.version}
> > >
> > >   
> > >
> > >   
> > >
> > >   
> > >
> > > 
> > >
> > > 
> > >
> > > 
> > >
> > > 
> > >
> > > The desired result when evaluating the child's pom is to have both
> > > Lombok
> > > and AutoValue (in that order) in the compiler's configuration. As it
> > > currently stands with Maven 3.6.3 only the child configuration is
> > > available, as shown by running `mvn help:effective-pom`
> > >
> > >   
> > >
> > > maven-compiler-plugin
> > > 3.8.1
> > > 
> > >
> > >   
> > >
> > > default-compile
> > > compile
> > > 
> > >
> > >   compile
> > >
> > > 
> > > 
> > >
> > >   
> > >
> > > 
> > >
> > >   com.google.auto.value
> > >   auto-value
> > >   1.7.4
> > >
> > > 
> > >
> > >   
> > >
> > > 
> > >
> > >   
> > >   
> > >
> > > default-testCompile
> > > test-compile
> > > 
> > >
> > >   testCompile
> > >
> > > 
> > > 
> > >
> > >   
> > >
> > > 
> > >
> > >   com.google.auto.value
> > >   auto-value
> > >   1.7.4
> > >
> > > 
> > >
> > >   
> > >
> > > 
> > >
> > >   
> > >
> > > 
> > > true
> > 

Re: How should I represent a library with two configurations in Maven Central?

[Jörg Schaible]

On Tuesday, 22. September 2020, 23:05:12 CEST Alan Snyder wrote:
> I know that. But you also can’t exclude a dependency based on its version.
> 
> So, what comparison are you making?

You don't have to exclude a dependency based on its version, this does not 
make sense.

Maybe you should make yourself familiar with what a dependencyManagement 
section is used for.

If you use classifiers, you have different artifacts for the same G:A:V and you 
have no proper way to chose one if different ones are in your transitive deps. 
With different versions you have different G:A:V and you can manage the correct 
one yourself.

Regards,
Jörg




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

Re: How should I represent a library with two configurations in Maven Central?

[Jörg Schaible]

On Tuesday, 22. September 2020, 01:13:11 CEST Alan Snyder wrote:
> I would still like to understand what you meant when you said that
> classifiers are worse then versions.

You cannot exclude a dependency based on its classifier.

Regards,
Jörg



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

Re: How should I represent a library with two configurations in Maven Central?

[Jörg Schaible]

You won't have to exclude something. A user of your library will just add a 
dependencyManagement section to his/her build and select there the version 
(with A or B) 
he/she wants. That will select the wanted version even if your lib is a 
transitive 
dependency.


Am Dienstag, 22. September 2020, 01:01:58 CEST schrieb Alan Snyder:


By implication, exclusions can work on versions? I have not seen any 
documentation that 
says this. Or are you talking about Gradle?






On Sep 21, 2020, at 2:19 PM, Jörg Schaible  wrote:


Using a classifier is worse, because exclusions do not work on classifiers.







[1] mailto:joerg.schai...@gmx.de

Re: How should I represent a library with two configurations in Maven Central?

[Jörg Schaible]

Hi Alan,

On Sonday, 20. September 2020, 23:50:21 CEST Alan Snyder wrote:
> I’ve posted a question on StackOverflow that has not yet been answered.
> Perhaps someone here has an answer?
> 
> https://stackoverflow.com/q/63906798/1652984?sem=2
> 

If it is A or B exclusively, use the alternatives as part of the version 
string. See
- postgres (https://search.maven.org/artifact/org.postgresql/postgresql[1] )
- xstream 
(https://search.maven.org/artifact/com.thoughtworks.xstream/xstream[2] )

Bouncycaste uses the alternative as part of the artifactId:
- https://search.maven.org/search?q=g:org.bouncycastle[3] 

However, I have often to "manage" 3rd party libraries manually that reference 
one of the 
BC artifacts that should not be used together by using exclusions.

Using a classifier is worse, because exclusions do not work on classifiers.

Regards,
Jörg


[1] https://search.maven.org/artifact/org.postgresql/postgresql
[2] https://search.maven.org/artifact/com.thoughtworks.xstream/xstream
[3] https://search.maven.org/search?q=g:org.bouncycastle

Re: [ANN] Apache Maven Dependency Analyzer Plugin 1.11.2 Released

[Jörg Schaible]

Hmmm. This is neither a plugin nor is the groupId correct ...

Am Mittwoch, 29. Juli 2020, 20:03:02 CEST schrieb Elliotte Rusty Harold:
> The Apache Maven team is pleased to announce the release of the Apache
> Maven Dependency Analyzer Plugin, version 1.11.2
>
> This plugin analyzes the dependencies of a project for undeclared and
> unused artifacts.
>
> https://maven.apache.org/shared/maven-dependency-analyzer/
>
> You should specify the version in your project's plugin configuration:
>
> 
>   org.apache.maven.plugins
>   maven-dependency-analyzer
>   1.11.2
> 
>
> You can download the appropriate sources etc. from the download page:
>
> https://maven.apache.org/shared/maven-dependency-analyzer/download.cgi
>
> Release Notes - Maven Dependency Analyzer Plugin - Version 1.11.2
>
> Bug
>
> [MSHARED-792] - Maven Dependency Analyzer ignores Java 8 type
> annotations on local variables
>
> Improvement
>
> [MSHARED-879] - make build Reproducible
>
> Dependency upgrade
>
> [MSHARED-810] - Support Java 12
> [MSHARED-868] - Upgrade plexus-component-metadata to 2.1.0
> [MSHARED-870] - Upgrade asm to 8.0.1
>
> 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: Maven Dependencies Pop Quiz

[Jörg Schaible]

BTW: I am quite sure, it depends also on the Maven version. The version 
handling of something like 25.1-android has changed over time.

Am Donnerstag, 26. März 2020, 18:00:52 CET schrieb Andres Almiray:
> Hello everyone!
> 
> If I can ask you for 15 minutes of your time, I've put of a 14 question pop
> quiz on dependency resolution. I'm hopeful that this quiz will let us
> realize a few things about the dependency resolution mechanism and its
> rules, perhaps address concerns in the future and make Maven better as a
> result.
> 
> The quiz can be found at https://bit.ly/maven-dependencies-popquiz and is
> totally anonymous (no email address collected). Unless you feel like
> sharing your name ;-)
> 
> Some preliminary numbers to this date:
> 
>  - 3 people have 13 correct answers
>  - 3 people have 12correct answers
>  - 10 people have 11 correct answers
> 
> The current median is 8. Some quick feedback left:
> 
>  - pretty tricky, even for an almost 20 year maven dude. good job!
>  - I've never seen documentation on this
>  - Good food for thought. I guess I generally hope Maven does what I expect
> and when it doesn't, I start specifying more exactly what I want.
> 
> Please feel free to share it with your colleagues and friends. More entries
> mean more data and better results. Thank you!
> 
> Cheers,
> Andres
> 
> ---
> Java Champion; Groovy Enthusiast
> http://andresalmiray.com
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary, and
> those who don't.
> To understand recursion, we must first understand recursion.





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

Re: Profile file activation in a reactor pom, using paren't relative dir - odd behavior

[Jörg Schaible]

Hi,

Am Mittwoch, 27. November 2019, 20:15:11 CET schrieb Danny Shemesh:
> Hey everyone,
> 
> I’m trying to activate a profile in a multi-module project, with several
> reactor poms, based on a file existing (or missing) from the parent
> directory of the root ‘grand’ parent pom.

[snip]

> It seems like the activation file path is expanded correctly in the child
> module, however, it does not activate the profile as I would’ve expected;
> Sadly, using session.executionRootDirectory, or
> maven.multiModuleProjectDirectory wouldn’t meet all Our requirements, as we
> have several parent poms, and we don’t always run maven from the ‘grand’
> pom directory.
> 
> The above was tested using maven 3.6.3 on windows.
> 
> Would love to have any pointers on why this doesn’t work, and how can I
> achieve such a behavior irregardless.

The first thing Maven does, is generating the effective POM. It will first 
select 
all active profiles (from the complete hierarchy) and then interpolate all the 
properties. The assumption is simply wrong that a parent POM is completely 
resolved first (incl. properties). You cannot activate a profile in a child POM 
based on the value set in a parent POM. Especially in the activation part of a 
profile there is no property interpolation (or very limited in the meanwhile).

What you can do though: Declare a profile in a parent based on the existence of 
a file or directory with a relative path. If it is present in the context of a 
child project, the profile gets activated. That's how profiles can be 
predefined 
in a parent and selectively activated. We use typically a directory profiles 
with empty files in each child that should use some special, but generic build.

Cheers,
Jörg



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

Regression: Maven 3.6.2 breaks Tycho pomless builds

[Jörg Schaible]

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

Re: Enforce no local versions

[Jörg Schaible]

Hi Tamás,

On Tue, 29 Jan 2019 11:40:03 +0100 Tamás Cservenák wrote:

> So, if I understand correctly: to enforce there is no reactor project in
> depMgt section of child modules?

No. I don't want that someone uses a version tag in the dependency section of a 
POM, since all versions have 
been defined somewhere in the parent's depMgt section.

Cheers,
Jörg


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

Re: Enforce no local versions

[Jörg Schaible]

On Mon, 28 Jan 2019 22:34:56 +0100 Harald Wellmann wrote:

> Do you mean a rule to enforce no snapshot dependencies? In that case,
> there is a rule called "requireReleaseDeps".

No.

> "No local versions" does not really make sense to me, because any remote
> dependency will first be downloaded to your local repository.

It has nothing to do with repositories. We manage versions in a depMgmt section 
the parent of a multi-
project and no-one should declare own versions for his dependencies in the sub 
projects.

Regards,
Jörg


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

Enforce no local versions

[Jörg Schaible]

Hi,

is there an enforcer rule to ensure that no local versions have been 
defined for dependencies? I always thought, there is one already 
available, but somehow I do not find it...

Cheers,
Jörg



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

Re: Inheritable Profiles or Decision making in POM

[Jörg Schaible]

On Fri, 21 Dec 2018 17:50:42 +0100 Tibor Digana wrote:

> I had a discussion with Robert about inheritable profiles.

Actually, they are inherited, but just the declaration. The activation is based 
on the conditions of the current 
(sub)project.

> As Robert said, this would introduce new issues and bugs. Altering
> dependencies is a bad sing in project my company really need it at least
> in POM with packaging WAR and runtime scope.

Why? A release will always just contain one of these special setups. If you 
want to release both variants, you 
effectively have two projects.

> Profiles are not inheritable.

Wrong. But you seem to talk about dependencies now, that you try to switch 
using profiles and you expect 
that Maven somehow knows later on on its own, which profile it should choose.

> This is user unfriendly because of adding
> the same profile to all children POMs of multi-module project.

You don't have to. You just have to activate it properly.

> Do we
> have a chance to have inheritable profiles in build POM (version 4 or
> 5)?

Why do you need it?

> I want to alter dependencies according to a profile in parent.

I am here with Robert. Once a POM is deployed, you can no longer rely on any 
profile activation (by OS or Java 
runtime is stupid, properties must be known by the client and something like 
the flatten plugin will strip these 
anyway). Therefore managing dependencies in profiles is a bad thing and 
discouraged, but still possible. You 
may just have some surprising side-effects when you suddenly depend on a 
released version.

> The
> dependencies are not inheritable. It would be nice to have another new
> well performed feature in Maven 4.0 or 5.0 in the client's POM. I do not
> want to have a Groovy in XML but the branching would be suitable in some
> circumstances.

Actually you may be faced in future with stripped POMs in the repositories, 
because Maven will separate 
between build time information and runtime information. Only the latter is 
required in the repo. And profiles 
are meant to be build time.

> Last to say is that we have one abstraction but two implementations and
> developer can use JPA implementation of dependency instead of JMS impl.
> Therefore switching dependencies impl.

So provide two BOMs with the proper dependencies and the developer can select 
on its own, on which one 
he wants to rely on.

Cheers,
Jörg


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

Java 11 and java.xml.bin, etc.

[Jörg Schaible]

Hi,

now with Java 11 not containing several jave.ee modules, what's the best
approach for a library that supports still Java 8? I guess profiles based
on the current Java version declaring the missing stuff as dependency are
a bad idea. Should a library developer add the new dependencies
nevertheless with compile/runtime scope or as provided or optional to move
the responsibility to the library users? What do you recommend?

Cheers,
Jörg



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

Re: [Maven Dependency Plugin] Inheriting transitive dependencies whilst defining an artifact output directory

[Jörg Schaible]

Hi,

if you use the copy goal, you don't have to add them to your list of 
dependencies. Personally I would use the 
copy-dependencies goal and copy only the ones with scope provided (i.e. you 
don't have to specify each one 
again).

Cheers,
Jörg


Am Fri, 23 Feb 2018 09:58:09 -0800 schrieb lewis john mcgibbney:

> I should also say, that the workaround is to list each and every
> transitive dependency in the dependency declaration with scope
> 'provided', such that they are NOT on the normal runtime classpath but
> ARE correctly copied into the target directory defined within the
> maven-dependency-plugin configuration as shown above.
> The only issue with this workaround is that it is extremely messy,
> bloats my POM and is difficult to maintain as I have now introduced
> around 50 or so additional dependencies which all have versions, etc.
> Thanks again for any hints.
> Lewis
> 
> On Fri, Feb 23, 2018 at 9:55 AM, lewis john mcgibbney
>  wrote:
> 
>> Hello users@,
>> I am looking to dynamically load JAR's during a program execution based
>> upon a users input and therefore using the maven-dependency-plugin to
>> do this.
>> Specifically, the plugin configuration looks as follows
>>
>>   
>> org.apache.maven.plugins
>> maven-dependency-plugin
>> 
>>   
>> copy prepare-package
>> 
>>   copy
>> 
>> 
>>   
>> 
>>   org.apache.any23.plugins
>>   apache-any23-openie
>>   ${project.version}
>>   ${output.directory}
>> 
>> ...
>> This works fine, however I have an issue with regards to these specific
>> JARs being present on the classpath during the build and runtime
>> depending on the  I assign to them within the dependency
>> definition.
>> If I mark the scope as 'runtime', the dependencies are added to the
>> normal classpath which I do not want, as the purpose here is dynamic
>> classloading via user input.
>> On the other hand, if I define the dependency scope as 'provided' then
>> no transitive dependencies are acquired hence I encounter
>> java.lang.NoClassDefFoundError as although the primary dependency is
>> present, it's own dependencies are not.
>>
>> Does anyone have a way to get around this. Ideally I am looking for a
>> solution to define a specific location I was dependencies (and the
>> transitive dependencies) to reside such that I can load them
>> dynamically at runtime.
>> Thank you kindly in advance,
>> Lewis
>>
>> --
>> http://home.apache.org/~lewismc/
>> http://people.apache.org/keys/committer/lewismc
>>



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

Re: Is there another alternative to using maven plug-in ?

[Jörg Schaible]

Hi Karen,

Am Wed, 31 Jan 2018 08:06:31 + schrieb Karen Goh:

> Hi John,
> 
> I changed my pom according to what you said, by removing the provided
> portion.
> However, I am still getting the below error :
> 
> Failed to execute goal org.apache.maven.plugins:maven-war-plugin:2.2:war
> (default-war) on project Hi5S: Error assembling WAR: webxml attribute is
> required (or pre-existing WEB-INF/web.xml if executing in update mode)
> 
> I have provided web.xml in the WEB-INF :

[snip]

So, where is your web.xml located in relation to the project root?

Cheers,
 Jörg


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

Re: org.openjdk.source.tree.Tree location

[Jörg Schaible]

Hi Martin,

Am Sat, 30 Sep 2017 01:49:39 + schrieb Martin Gainty:

> guava contains import org.openjdk.source.tree.Tree
> 
> 
> any ideas where i can locate jar which contains Tree from openjdk?

http://search.maven.org/#search%7Cga%7C1%7Cfc%3A%
22org.openjdk.source.tree.Tree%22

Use class-based search on central to locate such artifacts.

Cheers,
Jörg


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

MavenArchiver: Add file to archive

[Jörg Schaible]

Hi,

is it possible to use the MavenArchiver for adding a single file to an 
existing archive without extracting and packing the complete content again?

Cheers,
Jörg


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

Re: project.basedir in file-based profile activation

[Jörg Schaible]

Justin Georgeson wrote:

> With 3.3.9 and 3.5.0 When I use this
> 
>   
> 
>   my-profile-id
>   
> 
>   ${project.basedir}${file.separator}somefile.txt
> 
>   
>   
> 
>   
> 
> I see this warning
> 
> [WARNING] Some problems were encountered while building the effective
> [model for com.example:basedir:jar:1.0-SNAPSHOT WARNING]
> ['profiles.profile[my-profile-id].activation.file.exists' Failed to
> [interpolate file location ${project.basedir}${file.separator}somefile.txt
> [for profile jacoco-read-manifest: ${project.basedir} expression not
> [supported during profile activation, use ${basedir} instead
> 
> I was under the impression that ${basedir} is deprecated in favor of
> ${project.basedir}, many years ago at that.

That won't help, because string substitution did not happen yet at the time 
profiles are activated. There's only a special support for ${user.home} and 
${env.HOME}, but that's it. Anything else cannot not work.

> Side note, is it actually worthwhile to use ${file.separator} like this,
> or is that generally only useful when you're outputting stuff to the user
> and want it to look pretty?

Use normal slashes.

Cheers,
Jörg


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

Re: Producing java8 and java7 versions

[Jörg Schaible]

Hi Paul,

Paul Hammant wrote:

> Older releases tried to have a single jar that had adaptive bytecode
> within, right Jörg
> 
> Specifically, class file formats 49, 50, 51 in one Jar.

This is still the case. The -java7 version just omits class files targetting 
Java 8, because in some environments they cause harm if the runtime is not 
yet Java 8 compatible (Android, app servers scanning jars for annotations 
...).

Cheers,
Jörg



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

Re: Producing java8 and java7 versions

[Jörg Schaible]

Hi Chistopher,

Christofer Dutz wrote:

> Perhaps not adding any suffix to the version for the java8 version would
> be ok and to add “java7” to the version for the legacy builds would be a
> good compromise.

That's what XStream has done with the last release.

Cheers,
Jörg


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

Re: Using files to activate Maven profiles

[Jörg Schaible]

Hi Darius,

DariusX wrote:

> On a micro-service leaning project, I have various modules that share
> certain common aspects among them but not everything. For instance, 5
> modules may require Swagger-UI to be downloaded and unzipped into my
> target/webapp. Some other grouping of 5 modules may require something
> else.
> 
> There no neat hierarchy "under" the parent POM, so I'm considering this
> approach:
> 
> 1. Create profiles in the parent POM to define certain aspects within the
> build
> 2. Activate each profile, by the presence of a specific "indicator" file
> 3. In any sub-project that needs a specific feature, create the relevant
> indicator file
> 4. Maybe I'll have a main/maven directory, as a place to keep indicator
> files
> 
> I'm looking for thoughts of the pros and cons of this approach. I'd also
> like to know if there's a more idiomatic approach.

Activating profiles based on file existance is a neat solution for build 
variations and in the meanwhile often used in the way you're describing it 
above. However, you should never use profiles to manage dependencies. That's 
a recipe for desaster for consumers of your artifacts. Note, the file that 
triggers the profile exists only at build time...

Cheers,
Jörg


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

Re: Work-around for antrun AttachArtifact not working in external Ant build file

[Jörg Schaible]

Hi Jürgen,

Jürgen Weber wrote:

> What is the recommended work-around for attaching artifacts created by
> antrun?
> 
> * forward target directory as variable to ant ?

That helps if the created files should be removed in a normal "clean" phase.

> * build-helper-maven-plugin attach-artifact ?

Definitely the proper action.

> http://technotes.khitrenovich.com/attach-maven-artifact-external-build-xml-file/
> https://issues.apache.org/jira/browse/MANTRUN-181
> 
> Thx,
> Juergen

Cheers,
Jörg


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

[OT] Polyglot and release prepare

[Jörg Schaible]

Hi

last week I played with Maven Polyglot 
(https://github.com/takari/polyglot-maven) and transformed some POMs into YAML 
format and was quite impressed by 
the increased readability in combination with three times shorter files.

However, what happens with the release:prepare goal? IIRC, this one parses 
the XML format and adjust the versions for the release. I fear this will no 
longer work for POM files in other formats, right? What kind of release 
process is used by other Polyglot users?

Cheers,
Jörg


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

Re: Strategies for overriding parent plugin configuration in some modules without duplicating config code?

[Jörg Schaible]

Hi Anders,

Anders Hammar wrote:

> Profiles are never a "perfect match". They are evil.

Profiles are a tool, that can be used for good or bad (e.g. defining 
additional/different dependencies). There's no need to demonise it.

Cheers,
Jörg


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

Re: Strategies for overriding parent plugin configuration in some modules without duplicating config code?

[Jörg Schaible]

Hi David,

this is a perfect match for a profile. Define your "fixed" configuration in  
a profile of the parent that is activated based on the existance of a file. 
Add such a "dummy" file in all sub project that should run with the profile 
activated, e.g. "touch profiles/fixed". Then you will not even have to 
modify the POMs of the sub projects.

Cheers,
Jörg

KARR, DAVID wrote:

> Although my issue is about configuring the "jacoco-maven-plugin", I think
> it's really more of a pure Maven configuration issue, as I don't think
> this situation is unique to JaCoCo.
> 
> I have a somewhat large multi-module project.  Each of the child modules
> has a parent pom that configures the "jacoco-maven-plugin" to do offline
> instrumentation (at present, all the modules having unit tests using
> PowerMock, which doesn't work with online instrumentation).
> 
> I've designed a change that I'll have to make in a few classes in each
> module that will allow the unit tests to use Mockito, and for JaCoCo to
> use online instrumentation.  I'll eventually fix all of them to work this
> way, but it will take a little while.  In the meantime, I just want to
> override the configuration in the "fixed" modules with online
> instrumentation and let the other modules use the default of offline
> instrumentation.
> 
> The simple-minded way to do this is just to define the same configuration
> using online instrumentation in each "fixed" module, so it will override
> the parent pom.  Copying that block to every "fixed" module is not a great
> idea.  I'd like a solution that requires less code duplication.
> 
> I suppose I could define ANOTHER parent pom, that specifies the existing
> parent as its parent, and have that second parent use online
> instrumentation, and have the fixed modules use that second parent
> instead.  I will eventually delete this second parent pom once all of the
> modules are "fixed".
> 
> Note that I have a separate aggregator pom that is not a parent pom.
> 
> Are there other reasonable strategies for this "use original parent for
> some, override in same way for others" situation?



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

Re: generated resources not in target jar

[Jörg Schaible]

Give target/generated-resources a try.

Gary Aitken wrote:

> I'm having trouble getting resources generated post-compile into the final
> jar package (packaging type jar).
> 
> During the process-classes phase, I run a task which reads some xml files
> and produces other xml files.  I can't figure out how to get the output
> xml files into the jar.
> 
> Issues:
> 
> 1. The output is written into target/xmldata,
>but the xmldata subtree is not written into the jar.
>I also tried generating into target/resources/xmldata
> 
> 2. I tried the following in the  section of pom.xml:
> 
>   
> ${generated-xml.dir}
> 
>   ${generated-src-xml.dir}
> 
>   
> 
> 
> 3. I also tried adding an
> 
>   **_consolidated.xml
> 
>to the above  section; no luck.
> 
> Hints?
> Thanks,
> Gary



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

Re: Maven-Site-Plugin: Generated content?

[Jörg Schaible]

Hi Gerrit,

Hohl, Gerrit wrote:

> Hello everyone, :-)
> 
>  
> 
> I'm trying to create some content for the Maven site during the Maven
> build process.
> 
>  
> 
> I recognized that the maven-site-plugin has a 
> configuration property which allows defining a directory which holds
> such generated content.
> 
> Normally it's the target/generated-site folder.
> 
> So I placed an APT as well as a HTML file there.
> 
> But nothing happened.
> 
> So I defined it in the configuration of the maven-site-plugin in the
> pluginManagement section:
> 
> ${project.build.directory}/generated-site atedSiteDirectory>
> 
> But also that didn't change anything.
> 
> After the Maven build there is still no file in the target/site folder.
> 
> Neither the rendered APT file nor the HTML file.
> 
>  
> 
> Where is my mistake? :-(

The different formats are nomrally extected in different directories 
(according to 
http://maven.apache.org/plugins/maven-site-plugin/examples/creating-content.html).
 Have you tried to create the same 
structure for the generated-site directory?

Cheers,
Jörg


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

Re: Build behavior differences between 3.2.5 and 3.3.9 with dependency shading

[Jörg Schaible]

Stephen Connolly wrote:

> Hmmm I did some digging...
> 
> 
https://maven.apache.org/ref/3.2.3/apidocs/org/apache/maven/artifact/handler/ArtifactHandler.html#isIncludesDependencies()
> is i think the idea JvZ was hinting at.
> 
> For the case where a shaded JAR shades *everything* then a custom
> packaging will work as we could set this flag and it would stop the
> transitive dependencies being propagated... but most people do not shade
> *all* dependencies, rather they shade a subset.
> 
> I think we may need to re-think how we do this or rethink the model being
> read-only

Set the shaded dependencies as optional. This might at least technically 
produce the proper dependency tree for dependent artifacts.

Cheers,
Jörg


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

Re: Skipping install phase for a particular artifact in a project

[Jörg Schaible]

Hi,

Gupta, Nishant. wrote:

> Hi,
> 
> I was wondering if there is a way by which we can skip the install phase
> for a particular artifact. My use case is that I am using
> maven-assembly-plugin with two assembly descriptors in it. The output of
> first assembly descriptor is being used as input of the second assembly
> descriptor. After package phase, I deleted the first assembly descriptor
> artifact (in the target folder) using maven-clean-plugin but in the
> install phase, it throws and error saying that it couldn't find the first
> assembly descriptor artifact.
> 
> Any help will be appreciated.


Why do you clean something inbetween at all? This is not Ant. In a typical 
Maven project you keep everything that has been built in the target folder - 
even the intermediate results. The final artifacts will be installed (and 
copied to the remote repo) later.

You should rather have a look at the configuration of the assembly plugin. 
There you can define wether a resulting artifact is automatically attached 
to the project (default behavior) or not. Only the attached ones are "final 
results" and therefore installed later.

Cheers,
Jörg


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

Re: How to filter dependency:tree

[Jörg Schaible]

Hi,

Elliot Huntington wrote:

> Hi,
> 
> I work for a company that produces hundreds of artifacts which depend on
> each other. I'm trying to use `dependency:tree` to create a graph (with
> graphviz) to better understand the relationships of these artifacts. The
> problem I'm running into is that the graph is so large it is almost
> useless. I would like to filter the results such that only dependencies
> from my companies base group id are included in the graph.

[snip]

maybe you should have a look first at this:
https://github.com/batmat/overview-maven-plugin

Cheers,
Jörg


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

Re: mvn deploy without rebuilding?

[Jörg Schaible]

thully wrote:

> We can run mvn deploy whenever we make an RC build - however, the problem
> with that ends up being that we are deploying artifacts to our repository
> that may not be the final release. That's what we want to avoid - while we
> can re-deploy if we end up doing a second RC, the lack of version
> differentiation ends up being confusing (and possibly causes problems for
> anyone who has the old versions in their local repository)..

Use a third "staging" repository. If the release is approved, move it over 
to release repo. That's what Nexus does by default.

Cheers,
Jörg


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

Re: Why isn't maven-dependency-plugin copying my artifacts anymore?

[Jörg Schaible]

David M. Karr wrote:

> On 03/10/2016 09:43 PM, Uwe Barthel wrote:
>> I tried:
>> 'mvn clean' removes the lib/ and target/ folder.
>> 'mvn package' puts the libs into lib/ again.
>>
>> I delete all libs in lib/ folder but let the lib/ folder itself and the
>> target folder untouched. ‘mvn package’ works as expected.
>>
> 
> As usual, this still isn't doing anything for me.
> 
> This time I looked closer at the console output.  I'm thinking there's a
> clue here.  I looked closer at the output from
> "maven-dependency-plugin".  This is what I saw:
> -
> [INFO] --- maven-dependency-plugin:2.10:unpack (unpack-license) @
> com.cisco.yangide.core ---
> [INFO] Configured Artifact:
> org.opendaylight.odlparent:odl-license:0.0.1-SNAPSHOT:jar
> [INFO] Unpacking
> .../.m2/repository/org/opendaylight/odlparent/odl-license/0.0.1-
SNAPSHOT/odl-license-0.0.1-SNAPSHOT.jar
> to .../git/yangide/plugins/com.cisco.yangide.core/target/classes with
> includes "" and excludes "META-INF/**"
> ---
> 
> This is the only occurrence of "maven-dependency-plugin" in the build
> output, and notice that it's the "unpack" goal, not the "copy" goal.
> This reference to the "unpack" goal is in the parent of the parent of
> this pom.  Is this causing the maven-dependency-plugin to somehow skip
> the "copy" goal?

Use "mvn help:effective-pom" to see what Maven actually uses after merging 
the POM with the parent.

Cheers,
Jörg


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

Re: Compilation Error -Incompatible Types

[Jörg Schaible]

pradeepkumar wrote:

> I have tried compile form console , even i am facing the same error from
> command prompt.

That simply means your code is not Java compliant. It does not matter that 
the Eclipse compiler has no problem.

Cheers,
Jörg


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

Re: Compilation Error -Incompatible Types

[Jörg Schaible]

pradeepkumar wrote:

> Is there any was to resolve this issue from maven side by adding any flag
> to avoid cast typing issues.

Just because Eclipse can compile it, does not mean that javac of Oracle JDK 
can also. You better try to compile from console using the real compiler to 
see what's wrong.

Cheers,
Jörg


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

Re: Offline builds nearly impossible

[Jörg Schaible]

Hi Jason,

Jason van Zyl wrote:

> If this does not work please let me know. This is what I’ve used in the
> past and if it doesn’t work I agree it needs to be fixed. I honestly
> haven’t tried making a hermetically sealed build in a few years but last
> year worked on a project that did no network traversal aside from using
> file-based repositories and it all worked fine.

Worked like charm. I had to create the metadata for any plugin without a 
fixed version, but that's OK (none of those is actually involved creating 
the artifacts).

Cheers,
Jörg


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

RE: [EXTERNAL] RE: profile activation with multiple conditions

[Jörg Schaible]

Hi Justin,

Justin Georgeson wrote:

> Thanks. I was hoping that it would evaluate the file-based activation per
> project. I was treating it as a separate issue than the multiple
> conditions. But I think what you're saying is that the profile activation
> happens once for the whole reactor, and not per project within the
> reactor. I gather that you're saying if the keystore file doesn't exist
> when I first run maven, then the keystore profile will be activated for
> all projects in the reactor. Is that correct?

Yes. I've verified this with 3.3.9 and 3.2.5. Fails for 3.1.1, i.e. 3.1.1 
implements OR.

> I'm still seeing the
> keystore profile activate from the property alone even if the keystore
> file already exists before I run the mvn command. So that still suggests
> that it's doing an or of the conditions rather than an and. Running 'mvn
> -N -X help:active-profiles -Djarsigner.keystore.scm.url' isn't giving any
> debug info on the profile activation unfortunately.

Keep in mind, that activation is resolved on base of the location of the 
current project's POM, i.e. if your file-based activation uses a relative 
path that is only valid from the parent POM's directory, it does not work 
for the projects inheriting that parent. E.g. a profile declared in a parent 
POM activated on existence of src/main/java will be active for any current 
project compiling Java sources for the main artifact.

> My goal here is to have as much of the build process as possible
> self-contained in the POM files and executed from a single mvn command.

Why don't you simply activate the profile based on the property only and 
declare in this profile the keystore as (provided) dependency, copying it 
with the dependency plugin somewhere to target and configure the jarsigner 
plugin to use it from that location (plugins also defined in this' profile 
settings)?

Cheers,
Jörg


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

Re: Offline builds nearly impossible

[Jörg Schaible]

Paul Benedict wrote:

> I think most people, at least once in their life, try to use their local
> repository cache as an offline remote repository. However, the two aren't
> the same in concept though, IIRC, the last time I tried. You still need to
> keep the two separate.
> 
> Now it would be interesting if a tool existed to copy the contents of a
> local repository and scrub its local metadata. That would then give you a
> true "remote offline repo".

That's what Jason proposed. And what I will do. Actually I already have some 
bash scripts that create the metadata of a remote repo. I just do not have 
the clean-up yet. ;-)

Cheers,
Jörg


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

Offline builds nearly impossible

[Jörg Schaible]

Hi folks,

we have a requirement for a source code escrow 
(https://en.wikipedia.org/wiki/Source_code_escrow). Therefore we intended 
provide our source code with a local Maven repository that can be used for 
offline builds. However, all attempts have been failed so far.

What have we done:
1/ Checked out the tagged versions of our software
2/ Build it with M339 (mvn package) using an empty local Maven repo
As result all released artifacts are recreated in the target directories - 
so far so good.

As next step we took a copy of the local repo and of the cleaned sources to 
a new location and created naively a settings.xml containing two entries 
only:
- the location to the copy of the local repo
- offline set to true

We use JDK 1.7 and tried the different M3 versions (3.0.5, 3.1.1, 3.2.5, 
3.3.9):

First try with Maven 3.0.5:
= %< 
jos@josoo /tmp/kde-jos/offline $ mvn -s settings.xml -f source/pom.xml clean 
package 
[INFO] Scanning for projects...
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]   
[ERROR]   The project ip.users:ip-users-ear:4.4.1 (/tmp/kde-
jos/offline/source/ip.users/ip-users-ear/pom.xml) has 1 error
[ERROR] Unresolveable build extension: Error resolving version for 
plugin 'org.apache.maven.plugins:maven-eclipse-plugin' from the repositories 
[local (/tmp/kde-jos/offline/local.repo), central 
(http://repo.maven.apache.org/maven2)]: Plugin not found in any plugin 
repository -> [Help 2]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2] 
http://cwiki.apache.org/confluence/display/MAVEN/PluginVersionResolutionException
= %< 
$ ls -l local.repo/org/apache/maven/plugins/maven-eclipse-plugin/ 
drwxr-xr-x 2 jos jos 4096 Nov 13 09:47 2.10
= %< 

For whatever reason, it does not accept the maven-eclipse-plugin in the 
local repo (although it is just declared, but not used in the build itself). 
(And yes, it has no sticky version, the newest might always create the best 
project...)

Try with Maven 3.1.1/3.2.5/3.3.9 (all the same):
= %< 
$ mvn -s settings.xml -f source/pom.xml clean package 
[INFO] Scanning for projects...
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]   
[ERROR]   The project builder:source:x-SNAPSHOT (/tmp/kde-
jos/offline/source/pom.xml) has 1 error
[ERROR] Non-resolvable parent POM: Cannot access central 
(http://repo.maven.apache.org/maven2) in offline mode and the artifact 
com.scalaris.buildsystem.maven2:master:pom:274 has not been downloaded from 
it before. and 'parent.relativePath' points at no local POM @ line 6, column 
13 -> [Help 2]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2] 
http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
= %< 
$ ls -l local.repo/com/scalaris/buildsystem/maven2/master
drwxr-xr-x 2 jos jos 4096 Nov 13 09:47 274
= %< 

The "unresolvable" parent is obviously available in the local repo.

As next step we added an active profile to settings.xml with repository 
definitions using the same ids we had originally, but with a URL pointing to 
nowhere (file:///). This makes no difference for M305, but all versions 
3.1.1 and higher start to accept the artifacts available in the local 
repository ... unless the first project in the build uses the maven-
assembly-artifact:

= %< 
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-assembly-
plugin:2.4.1:single (create-assemblies) on project fileupload-app: Failed to 
create assembly: Unable to resolve dependencies for assembly 'app': Failed 
to resolve dependencies for assembly: Missing:
[ERROR] --
[ERROR] 1) commons-codec:commons-codec:jar:1.6
[ERROR] 
[ERROR] Try downloading the file manually from the project website.
[ERROR] 
[ERROR] Then, install it using the command:
[ERROR] mvn install:install-file -DgroupId=commons-codec -
DartifactId=commons-codec -Dversion=1.6 -Dpackaging=jar -Dfile=/path/to/file
[ERROR] 
[ERROR] Alternatively, if you host your own repository you can deploy the 
file there:
[ERROR] mvn deploy:deploy-file -DgroupId=commons-codec -DartifactId=commons-
codec -Dversion=1.6 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -

Re: Offline builds nearly impossible

[Jörg Schaible]

Hi Jason,

Jason van Zyl wrote:

> Use a file based remote repository instead of trying to build in offline
> mode.
> 
> You can either use a repository manager to create the remote repository or
> an empty local repository with a full build. As noted though, you have to
> remove all local repository metadata and files if you create the
> repository locally.
> 
> Now that you have the repository that contains everything you need to
> build create a settings.xml with a mirror pointing to a file-based
> repository. You shouldn’t need to build in offline mode but using a
> file-base repository in your mirror will effectively be the same. This way
> you will not be subject to every Maven plugins potentially flaking
> handling of offline mode.

Good idea, thanks! And with a mirror setup to file:/// (except for that 
file-based remote repo) we can even verify that no offline access is 
required.

Cheers,
Jörg


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

Re: Offline builds nearly impossible

[Jörg Schaible]

Hi Stephen,

Stephen Connolly wrote:

> IOW
> 
> mvn -o -llr goal
> 
> Should do what you want where you have changed the repo url. The
> _remote.repositories stores the URL of the repository not just the id.

My local repo was populated using Maven 3.3.8 or 3.3.9 and those files never 
contained any URL.
=== %< ==
$ find local.repo -name _remote.repositories -exec grep '://' {} +
$ cat local.repo/org/apache/maven/maven-model/3.1.0/_maven.repositories 
#NOTE: This is an internal implementation file, its format can be changed 
without prior notice.
#Fri Nov 13 09:38:55 CET 2015
maven-model-3.1.0.pom>maven-proxy=
=== %< ==

therefore I've changed the URL in the settings to be sure, that no access is 
possible.

As reported  it actually works for 3.1.1, 3.2.5 and 3.3.9 without -llr 
unless the assembly plugin is used. And for 3.3.9 even -llr did not help, 
again due to plugin incompatibilities.
 
> If you are doing offline, better would be to have a repository manager and
> a hostname to host it at... but if you want to use a file:/// URL then you
> need -llr AIUI

In an escrow situation, you certainly have no repo manager. You simply have 
to ensure that the provided source, libraries and tools can be used to 
recreate the product. However, the complete resolver mechanism is extremely 
brittle in offline mode.

Cheers,
Jörg


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

Re: Locking down dependency versions...

[Jörg Schaible]

Kevin Burton wrote:

> Just regular dependency versions.
> 
> So if we're using 1.0.1 of library A I don't want adding adding library B
> to transitively change our dependency on library A...
> 
> This has happened to us before and caused problems.

Use a shared parent where you define all dependencies and their versions in 
the dependencyManagement section. These definitions apply also to transitive 
deps then. Additionally you may never declare versions directly for a 
dependency ... always inherit from the depMgmt section of the shared parent.

Cheers,
Jörg


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

RE: profile activation with multiple conditions

[Jörg Schaible]

Justin Georgeson wrote:

> So here's a minimal parent pom.xml, which lists 2 child modules that I
> created with 'mvn archetype:generate' choosing the
> 'maven-archetype-quickstart' archetype. My goal was that if I
> 
> mvn package
> 
> Then the compile/test/package occurs with no attempt to sign. But then by
> changing the command to
> 
> mvn package -Djarsigner.keystore.scm.url=...
> -Djarsigner.keystore.scm.user=... -Djarsigner.keystore.scm.password=... \
>  -Djarsigner.storepass=...
> 
> Then it checks out a single copy of the keystore during the package phase
> of the parent project, and the jarsigner profile automatically activates
> during each of the modules due to the presence of the keystore file.
> 
> Instead it's deleting the keystore and checking out the keystore file
> during every project (or instead of and of profile activation conditions),
> and the jarsigner profile is not automatically activated.

Profile activation is quite the first thing Maven does. So, the file has to 
be already there when Maven starts.

Form your description I got the impression that you "create" somehow the 
file during the build and expects then that Maven takes it into 
consideration for profile activation. That will never happen. And this has 
nothing to do with multiple profile conditions.

Cheers,
Jörg


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

Re: Reactor versus classifiers ...

[Jörg Schaible]

Hi Benson,

Benson Margulies wrote:

> I've hit a problem with Maven 3.2.5 and the karaf-maven-plugin.
> 
> One module builds a Karaf feature with the karaf maven plugin; this
> produces:
> 
> 
> ${project.groupId}
> rosapi-features
> ${project.version}
> features
> xml
> runtime
> 
> 
> The packaging of this project is 'feature' to use the karaf-maven-plugin.
> 
> 
> The second module consumes it, via the dependency above. It also uses
> the karaf-maven-plugin with a different packaging to make the karaf
> assembly.
> 
> When I try to run release:prepare, I fail, because the features.xml
> file is not, apparently, resolved correctly from the reactor. Does
> anyone here on the Maven side have any suggestions before I try to
> dive into the Karaf side? Of course, it works fine when I am _not_
> running the release plugin.

I assume the modules have a shared parent with the same version. Declare the 
artifact in a dependencyManagement section of the parent (don't use a 
property for the version there - the release plugin will handle it) and drop 
the version when you declare the dependency in the modules.

While your approach should have worked in the first place, we had less 
problems with this solution.

Cheers,
Jörg


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

Re: Copy-dependencies goal error

[Jörg Schaible]

Karl Heinz Marbaise wrote:

> Hi,
> 
> On 10/5/15 7:51 PM, Jörg Schaible wrote:
>> Hi Michael,
>>
>> michael.ctr.taru...@faa.gov wrote:
>>
>>> My apology about part of this reply.  I did not understand part of your
>>> suggestion.
>>>
>>> I thought you were saying 3.0.5 is the latest release.
>>>
>>> That said, I don't see how using the latest release or an older release
>>> makes any difference.
>>>
>>> I have a requirement to use 3.1.1 from a COTS product vendor, so that is
>>> probably not an option.  And "bogus" is just not a good enough
>>> explanation
>>> for me.  What specifically is wrong with what I am doing that does not
>>> work in this release?
>>
>> I just cite my original mail:
>>
>>> IIRC you have problems with 3.1.x when using dependencies with import
>>> scope, because it ignores then your settings then for transitive
>>> deps declaring their own repository in the POM.
>>
>> AFAICS, you are using dependencyManagement with dependencies declared
>> with scope "import"".
> 
> 
> The given pom does not contain any dependencyManagement...so it does
> simply plays not a role here...

If you read the OPs question from last week, you will see that he did not 
provide his POM there and from that description, I assumed he used an import 
scope. That was not the case.

> Apart from that import scope means only
> to use the dependencyManagement part and nothing else as described in
> the documentation...so it does not ignore it nor is it wrong...

And what does that have to do with the stuff defined in settings.xml? 

> See the original documentation
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html.

As long as the dependencies are resolved from the repos declared in 
settings.xml ...

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

We were affected by this more than once, but - honestly - I could not 
reproduce it today (3.3.3, 3.1.1, 3.0.5).

> so this is NOT a problem in contrary it is exactly working as it should
> be...Apart from using repository definition in a pom is a bad
> practice...

Definitely.

> But this is a different story...

Sadly it was not forbidden when it was discussed the last time ...

Cheers,
Jörg



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

RE: Copy-dependencies goal error

[Jörg Schaible]

Hi Michael,

michael.ctr.taru...@faa.gov wrote:

> My apology about part of this reply.  I did not understand part of your
> suggestion.
> 
> I thought you were saying 3.0.5 is the latest release.
> 
> That said, I don't see how using the latest release or an older release
> makes any difference.
> 
> I have a requirement to use 3.1.1 from a COTS product vendor, so that is
> probably not an option.  And "bogus" is just not a good enough explanation
> for me.  What specifically is wrong with what I am doing that does not
> work in this release?

I just cite my original mail:

> IIRC you have problems with 3.1.x when using dependencies with import
> scope, because it ignores then your settings then for transitive 
> deps declaring their own repository in the POM.

AFAICS, you are using dependencyManagement with dependencies declared with 
scope "import"".

Cheers,
Jörg


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

RE: Copy-dependencies goal error

[Jörg Schaible]

Hi Michael,

michael.ctr.taru...@faa.gov wrote:

> What do you mean by a consistent repository and POM model?
> 
> If you mean that the POM must be declaring files to copy that are in the
> repository, that is stating the obvious.
> 
> And in this case, the POM is doing exactly that.  The files I am asking to
> be copied from the repository are actually in the repository.  The problem
> is that I am getting errors for files I did not ask to be copied.

The repository must also contain all POMs for the transitive dependencies 
... otherwise Maven cannot build the project model. Maven core does not know 
that you have bound an instance of the assembly plugin, that is not 
interested in the transitive dependencies.

> Did you look at the POM file I attached and compare it to the error
> messages also attached?

The POMs of the referred artifacts get interesting.

Chrres,
Jörg


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

RE: Copy-dependencies goal error

[Jörg Schaible]

michael.ctr.taru...@faa.gov wrote:

> There are no transitive dependencies!

That depends totally on the declaration of the POMs for your dependencies. 
You don't control this.

> This is not even building source code!!!

That's totally irrelevant.

> It is simply copying ZIP/MD5/SHA1 files from a Nexus repository to a local
> workstation.

And their POMs which may (and obviously do) declare dependencies again.

Cheers,
Jörg


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

RE: Copy-dependencies goal error

[Jörg Schaible]

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

Re: Copy-dependencies goal error

[Jörg Schaible]

You asked the same question before and I gave you the advice to either try 
latest Maven version or 3.0.5, because 3.1.1. is bogus. You never answered.

michael.ctr.taru...@faa.gov wrote:

> I am currently responsible for a "legacy" POM that copies ZIP files
> from the Red Hat JBoss Fuse distro in our Nexus repository manager
> to a location on a local worstation.  Several ZIP files are copied
> from each of the following Fuse components, ActiveMQ, Camel and CXF.
> 
> To perform the copy operation the legacy POM is using the Maven
> copy-dependencies goal or the maven-dependency-plugin.
> 
> When this project is executed by Maven for just the ActiveMQ and
> CXF Fuse components the designated files are copied fine.  When,
> however we execute the project to copy the Camel files, the process
> fails.
> 
> The directory for the failing artifacts is present in our Nexus
> repository manager, and is populated with several artifacts.
> 
> What I do not understand is why Maven is even looking for these
> artifacts for a simple copy operation?  It appears to me that the
> artifacts causing the problem have nothing to do with the copy goal!
> 
> I have posted this problem with Red Hat, who originally helpd our
> previous personnel develop this POM.  They believe, and I tend to
> agree 100%, that this is a Maven problem.
> 
> I have attached our settings.xml, pom.xml and the text of the error
> message.
> 
> Can someone please explain why this is happening and how to fix it?
> 
> Thanks,
> Mike
> 
> Michael Tarullo
> Contractor (Engility Corp)
> Enterprise Architect
> NSRR System Administrator
> FAA WJH Technical Center
> (609)485-5294



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

RE: Trouble With A POM

[Jörg Schaible]

Hi Michael,

michael.ctr.taru...@faa.gov wrote:

> Yes we do that in our settings.xml file.
> 
> Knowing that, is there anything else to add?

AFAICS 3.1.1 is known to be bogus. Can you give the latest 3.3.x version a 
try (or 3.0.5)? IIRC you have problems with 3.1.x when using dependencies 
with import scope, because it ignores then your settings then for transitive 
deps declaring their own repository in the POM.

Cheers,
Jörg


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

Re: Local Repository Question

[Jörg Schaible]

michael.ctr.taru...@faa.gov wrote:

> Can the local repository be a Nexus repository on a server?  If so How?

No. Think of the local repo as cache.

- Jörg


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

Re: Trouble With A POM

[Jörg Schaible]

michael.ctr.taru...@faa.gov wrote:

> I inherited a POM file (copy attached) that copies selected files from our
> Nexus repository to a local workstation location.
> 
> When I run Maven (3.1.1) with said POM I get the following error:
> [ERROR] Failed to execute goal on project all-products:
> Could not resolve dependencies for project
> com.iona.fuse:all-products:pom:1.0.0.0-fuse: Failed to collect
> dependencies
>   at org.apache.camel:apache-camel:zip:src:2.15.1.redhat-620133
>   -> org.apache.camel:camel-cmis:jar:2.15.1.redhat-620133
>   ->
>   org.apache.chemistry.opencmis:chemistry-opencmis-client-
impl:jar:0.8.0
>   ->
>   org.apache.chemistry.opencmis:chemistry-opencmis-commons-
impl:jar:0.8.0
>   -> com.sun.xml.ws:jaxws-rt:jar:2.1.7 ->
>   com.sun.xml.stream.buffer:streambuffer:jar:0.9 ->
>   org.jvnet.staxex:stax-ex:jar:RELEASE:
> Failed to read artifact descriptor for
> org.jvnet.staxex:stax-ex:jar:RELEASE: Failed to resolve version
> for org.jvnet.staxex:stax-ex:jar:RELEASE: Could not find metadata
> org.jvnet.staxex:stax-ex/maven-metadata.xml
>   in local (C:\Users\Michael CTR
>   Tarullo.FAA\.m2\super-pom-test-repository-62)
> 
> I'm starting with an empty local repo for this.  I would think that would
> not be a problem since the only thing this POM is supposed to do is copy
> files from Nexus.

This is only true, if you have defined a mirror for central in your 
settings.xml that redirects to your Nexus.

Cheers,
Jörg


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

Re: Can not build with Junit4.18

[Jörg Schaible]

建文 wrote:

> Junit is added in dependencies,and i can run Junit test in my Eclipse,
> but when run mvn clean install -DskipTests=true fail

Maven is about conventions. If you don't follow its conventions, you'll run 
into trouble. Like this.

Maven separates between the main source and the code for test (unlike 
Eclipse) and uses different class paths. JUnit is *only* on the classpath 
for the test code, which is expected by Maven in the subdirectory 
src/test/java.

As long as you insists on violating Maven's conventions (like keeping test 
code in src/main/java), you'll face such problems. That's what peoples tried 
to tell you already.

Cheers,
Jörg


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

Re: How can I emit the SNAPSHOT version after deploy?

[Jörg Schaible]

Hi Jeff,

Jeff wrote:

 I should clarify that I want to find the specific SNAPSHOT version
 assigned by Nexus (or other maven repository manager applications) after
 the deploy.
 
 So after I deploy 'myapp.jar' to Nexus with GAV:
 
 groupID: mycompany.com
 artifactID: myapp
 version:  1.0-SNAPSHOT
 
 
 Nexus assigns it to something
 like /com/mycompany/myapp/1.0-SNAPSHOT/myapp-1.0-20150821.000538-120.jar
 
 I want to get the 20150821.000538-120 portion and also if possible the
 SHA1 hash Nexus generated.

What happens if you use dependency:get to download the SNAPHSOT? You might 
find it then in your local repository as timestamped version (depending on 
your settings in updatePolicy (always) for the snapshot repo).

Cheers,
Jörg



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

RE: Velocity-based report with project artifacts

[Jörg Schaible]

Hi Martin,

Martin Gainty wrote:

 so if you knew how to accomplish this how come you posted that you did not
 know how to access project artifacts?

as said, your mail triggered my memory and I just wanted to share the 
result, since I've seen various requests for a generated download page.

 I would advise to please be careful with other peoples time..especially
 when they are not charging you.

That's why I asked on the user's list. If you're not interested or have no 
time, then don't answer. However, I am thankful you did. It helped me to do 
the task.

Cheers,
Jörg


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

RE: Velocity-based report with project artifacts

[Jörg Schaible]

Hi Martin,

sometime a simple Velocity template is enough. SNippet from my generic about 
page:

 % ==  
* Generated Artifacts

#set($url=${project.properties.get('site.download')} + 
${project.groupId.replaceAll('\.', '/')} + /)
#set($name=$project.artifact.file.name)
  * {{{${url}${name}}${name}}}

#foreach($artifact in $project.attachedArtifacts)
#set($name=${artifact.file.name})
  * {{{${url}${name}}${name}}}

#end
 % ==

Thanks for the hint though, I forgot that you can access the complete 
project instance.

Cheers,
Jörg

Martin Gainty wrote:

 http://stackoverflow.com/questions/10454181/how-to-determine-what-artifacts-are-built-from-a-maven-reactor-plan-ie-includi
 
 author suggests to code your own mojo:
 /**
  * @goal list-artifacts
  * @phase verify
  */
 public class ListArtifactsMojo extends AbstractMojo {
 
 /**
  * @parameter default-value=${project}
  * @required
  * @readonly
  */
 MavenProject project;
 
 public void execute() throws MojoExecutionException,
 MojoFailureException {
  CollectionArtifact artifacts = new ArrayListArtifact(); //create
  empty array artifacts.addAll(project.getAttachedArtifacts()); //add
  attached Artifacts
 //List them out
  for (Artifact artifact : artifacts)
  {
  System.out.println(Artifact:  + artifact);
  }
 } //end execute
 } //end ListArtifactsMojo
 
 i leave contents of plugin.xml as fun exercise:
 https://maven.apache.org/ref/3.2.1/maven-plugin-api/plugin.html
 
 Martin ...
 
 
 
 To: users@maven.apache.org
 From: joerg.schai...@swisspost.com
 Subject: Velocity-based report with project artifacts
 Date: Fri, 14 Aug 2015 09:05:13 +0200
 
 Hi,
 
 for a report page I'd like to use a velocity template to list all
 artifacts generated by the current project e.g.
 - artifact-1.0.jar
 - artifact-1.0-config.zip
 
 Accessing artifactId and version is clear, but the extension of the main
 artifact is already a problem. Not to speak of all attached artifacts.
 
 Is this information available accessing the $project.* hierarchy?
 Can anyone tell?
 
 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

Re: Extra resource directory for site

[Jörg Schaible]

Dirk Olmes wrote:

 Hi,
 
 Is it possible to specify a resources directory for the site in
 addition to src/site/resources? I did not find anything in the docs of
 the site plugin.

It used also the (documented) directory of parameter generatedSiteDirectory, 
i.e. target/generated-site by default.

 I'm using an Eclipse plugin which generates UML Diagrams from the
 source and keeps them up to date even when refactoring the code. This
 plugin automatically exports the diagram to an image when it changes.
 I'd rather not add src/site/resources as a resource to my main build.

The question is then, how do you get the file for a normal Maven build.

Cheers,
Jörg


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

RE: Specified destination directory cannot be created

[Jörg Schaible]

Hi Michael,

michael.ctr.taru...@faa.gov wrote:

 Thanks Robert.
 
 Using Maven 3.1.1 (required by COTS product vendor); can you define
 ancient :-)?
 
 I suspect it is not permission related, because the build created other
 directories\sub-directories located here (which is the same reason I
 concluded it is neither spaces in a directory name nor directory name
 length as I mentioned in a previous post).
 
 I think it might be time to see what the vendor of the software I'm trying
 to build has to say!!!
 
 But if anyone else has any other ideas, I'm open to hearing them.

Weird idea: Virus Scanner? .scr is normally reserved for screen savers. Do 
you have other .src artifacts in your repo? Have you checked the Windows 
events?

Cheers,
Jörg


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

Velocity-based report with project artifacts

[Jörg Schaible]

Hi,

for a report page I'd like to use a velocity template to list all artifacts 
generated by the current project e.g.
- artifact-1.0.jar
- artifact-1.0-config.zip

Accessing artifactId and version is clear, but the extension of the main 
artifact is already a problem. Not to speak of all attached artifacts.

Is this information available accessing the $project.* hierarchy?
Can anyone tell?

Cheers,
Jörg


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

Re: Use 2 pom.xml files with different names

[Jörg Schaible]

Hi Alex,

Alex Ditu wrote:

 Ok, look what I am trying to achieve: I have a project with 2
 profileDeployments (it produces 2 types of artifacts: a jar and a war)
 but from the same sources. So, I did the following thing: I have
 written 2 pom.xml files with 2 different names (for example: pom.xml
 and pom2.xml). When I want to build the .jar artifact I would use the
 command 'mvn deploy' when I want the .war artifact I would use: 'mvn
 -f pom2.xml' --- after this, I encounter the problem I mentioned
 earlier.

We produce war and jar at once, but give the war a classifier (webapp). 
Might be an alternative for you also.

Cheers,
Jörg


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

Re: Determine maven deploy file name

[Jörg Schaible]

Hi Dan,

Dan Tran wrote:

 Hi
 
 Is there a hook into after maven deploy to retrieve the snapshot deploy
 name?
 
 User case:
 
   * Maven build, smoke test, and deploy huge artifacts (OVA)
   * After deploy, continue with more tests but need to know the deploy
   name
 
 (artifactid-version-timesamp.ova), to reference again the test report
 
 
 I can write a custom plugin to execute after deploy phase

If it is deployed, it is published - even if a later test might fail. 
Therefore you can move those tests simply into a second project depending on 
the original and let the dependency plugin resolve the name.

Cheers,
Jörg


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

Re: Determine maven deploy file name

[Jörg Schaible]

Hi Dan,

Dan Tran wrote:

 Hi Jörg
 
 Base on your idea, I guess I can pull down the maven-metadata.xml to
 figure out the latest name in my next test phase which is already a maven
 module of its own

Simply add it as dependency and let the dependency plugin copy it (you may 
even rename it) into target. There's no reason to meddle with maven-
metadata.xml.

 This may not be correct if a user directly invokes the second test
 project, but it is good enough for now

If it was deployed before, it will use the correct version (unless your user 
has some obscure configuration in his settings.xml).

Cheers,
Jörg

 
 Thanks
 
 -Dan
 
 On Thu, Jul 16, 2015 at 11:30 PM, Jörg Schaible 
 joerg.schai...@swisspost.com wrote:
 
 Hi Dan,

 Dan Tran wrote:

  Hi
 
  Is there a hook into after maven deploy to retrieve the snapshot deploy
  name?
 
  User case:
 
* Maven build, smoke test, and deploy huge artifacts (OVA)
* After deploy, continue with more tests but need to know the deploy
name
 
  (artifactid-version-timesamp.ova), to reference again the test
  report
 
 
  I can write a custom plugin to execute after deploy phase

 If it is deployed, it is published - even if a later test might fail.
 Therefore you can move those tests simply into a second project depending
 on
 the original and let the dependency plugin resolve the name.

 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

Re: Determine maven deploy file name

[Jörg Schaible]

Hi Dan,

Dan Tran wrote:

 Hi Jörg
 
 2 issues for this approach
 
   1. Both modules use the same local repo, so I dont think
   maven-dep-plugin
 would resolve the file to timestamp filename format that i am looking for.
 It is just be artifactId-versoin-SNAPSHOT.
   2. Even if it resolves to the desired file name, I still have to extract
 the file name and use in my test report  ( ie run test result is from the
 artifact that already deploy at maven repo

Set option stripVersion of copy-dependencies to true, then you can rely on 
the name in your test.

Cheers,
Jörg



 
 Thanks
 
 -Dan
 
 On Fri, Jul 17, 2015 at 12:34 AM, Jörg Schaible 
 joerg.schai...@swisspost.com wrote:
 
 Hi Dan,

 Dan Tran wrote:

  Hi Jörg
 
  Base on your idea, I guess I can pull down the maven-metadata.xml to
  figure out the latest name in my next test phase which is already a
  maven module of its own

 Simply add it as dependency and let the dependency plugin copy it (you
 may even rename it) into target. There's no reason to meddle with maven-
 metadata.xml.

  This may not be correct if a user directly invokes the second test
  project, but it is good enough for now

 If it was deployed before, it will use the correct version (unless your
 user
 has some obscure configuration in his settings.xml).

 Cheers,
 Jörg

 
  Thanks
 
  -Dan
 
  On Thu, Jul 16, 2015 at 11:30 PM, Jörg Schaible 
  joerg.schai...@swisspost.com wrote:
 
  Hi Dan,
 
  Dan Tran wrote:
 
   Hi
  
   Is there a hook into after maven deploy to retrieve the snapshot
 deploy
   name?
  
   User case:
  
 * Maven build, smoke test, and deploy huge artifacts (OVA)
 * After deploy, continue with more tests but need to know the
 deploy name
  
   (artifactid-version-timesamp.ova), to reference again the test
   report
  
  
   I can write a custom plugin to execute after deploy phase
 
  If it is deployed, it is published - even if a later test might fail.
  Therefore you can move those tests simply into a second project
 depending
  on
  the original and let the dependency plugin resolve the name.
 
  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





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

Re: maven compiler plugin + toolchains

[Jörg Schaible]

intel radoux wrote:

 Hello,
 
 Yes, I could use maven.compiler.source  properties, but i'm on a parent
 pom, and if somebody add a configuration like
 
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-compiler-plugin/artifactId
 version3.3/version
 configuration
 sourcexxx/source
 targetxxx/target
 /configuration
 /plugin
 
 on his module it will fail.
 
 I was wondering if there was some kind of auto-link between source level
 in maven-compiler-plugin and toolchain plugin (it would be nice)
 
 Anyway, I will go with this solution and hope for the best (anyway I will
 set the default jdk version to 1.5 so that if somebody update the source
 level by itself (not by the maven.compiler.source if will fail hard :D )

Define the plugin configuration in the parent pom in a pluginMgmt section 
and use the proposed property. Someone who inherits the POM may simply 
redefine the property then.

Cheers,
Jörg



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

Re: deployment in runtime for provided scope jars

[Jörg Schaible]

Hi Lin,

Lin Ma wrote:

 Thanks Ron,
 
 I see Maven has phase like install and deploy, but I never used them
 before. Are the two phases suppose to do deployment work, which copy
 application jar and dependency jars to destination host, and setup other
 environment variable like classpath?

No. Both goals refer the Maven repository. install will copy the result of 
your project into your local repository while deploy will copy this stuff 
to a remote repository instead (depends on your settings in the 
distributionManagement) to make the artifacts available for other people. It 
has nothing to do at all with deployment of an application.

 BTW, in the context of a Java jar console application.

That's what IzPack may do for you.

Cheers,
Jörg


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

Re: deployment in runtime for provided scope jars

[Jörg Schaible]

Lin Ma wrote:

 Hi Maven expert,
 
 I think Maven is good for build, and not sure if cover runtime deployment
 well. Wondering what is the best practices for deploy provided scope
 jars?
 
 Currently, I either build a fat jar, or manual copy external dependencies
 jars into class path.
 
 And better solutions is appreciated.

Don't declare them as provided.

See, provided means, such a dependency is already present in the target 
environment of the application. E.g. a web application can assume that the 
application server provides servlet-api if it is compliant with the 
specification.

Otherwise, provided is simply wrong.

- Jörg


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

Re: Maven does not find existing artifacts in local repository because it looks in central where they are not?

[Jörg Schaible]

Hi Christian,

Christian Eugster wrote:

 Hi
 
 as I understand, there is a central repository for maven artifacts:
 central (http://repo.maven.apache.org/maven2
 http://repo.maven.apache.org/maven2) and a local one
 (${user.home}/.m2/repository. What I do not understand is, why after a mvn
 test maven complains about artifacts that are not in local repository. The
 named artifacts are in local repository as I checked. And it says, that it
 cannot download them from central. Because these artifacts are from my own
 project, they are only in the local repository. Why does maven try to
 download them, when they are already in local repository? Is there a wrong
 setting? Does exist a reasonable documentation for beginners that is able
 to explain what is going wrong?
 
 I am thankfully for any hint!

How do you refer those artifacts? Any chance that they are included using an 
import scope?

Cheers,
Jörg


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

Re: What does my application actually require?

[Jörg Schaible]

Hi Dan,

D C wrote:

 I was going to tag this onto my previous post, but I figured the issue is
 unique enough to be a different topic.
 
 
 When I run dependency:tree (with an empty .m2),  I get a nice tree graph
 showing 49 items.   I would expect then my .m2/repository to have 49 items
 in it.  In actuality, my .m2 now has 251 artifacts.

Well, yes. Maven and the plugins in use have also dependencies.

 I want to collect only the artifacts that my application needs to run.
 Would I be safe if I just package up the 49 items listed in the dependency
 tree output?

Use the dependency plugin to copy the dependencies.
http://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-project-dependencies.html

 This would also be useful to reduce because I create my class path like
 so: $ find ~/.m2/repository/ -name *.jar | xargs | sed 's/ /;/g'
 
 The more I can remove from there, the better.

Leave the local repository alone. It is not of use for your task.

Cheers,
Jörg


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

Re: compile with different source option

[Jörg Schaible]

Hi Philipp,

Philipp Kraus wrote:

 Hello,
 
 thanks a lot. I’m using Maven 3 (3.2.0) and I have added
 
 profiles
 profile
 idjdk-default/id
 activation
 activeByDefaulttrue/activeByDefault

Just remove this activeByDefault, it simply does not make sense.

 jdk[1.8,)/jdk
 /activation
 build
 plugins
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-compiler-plugin/artifactId
 !--
 configuration
 includes
 includesrc/main/java/**/*.java/include
 /includes
 excludes
 
excludesrc/main/java/**/CMainBootstrap.java/exclude
 /excludes
 /configuration
 --
 executions
 execution
 configuration
 source1.8/source
 target1.8/target
 /configuration
 goals
 goalcompile/goal
 /goals
 /execution
 /executions
 /plugin
 /plugins
 /build
 /profile
 /profiles
 
 The uncommented block should be changed for the two Java versions also the
 target item. But if I remove the maven.compiler.soource and .target from
 the properties part, the default profile is not used at the moment. IMHO I
 have configured the profile „default“. I have tried to use it with mvn -P
 jdk-default or anything else.
 
 My idea is that I use a „default profile“, which defines the JDK 1.8 and a
 „old“ profile which uses JDK 1.7 and the difference of the both is the
 exclude / include and target items, but both profiles should be used on
 Maven defaults

In this case you have no default profile. You need a second one that is 
activated for any JDK below 1.8. Look at the XStream example, it uses 3 
different profiles for its cases. It does not even define the compiler 
plugin outside a profile - on purpose.

Cheers,
Jörg



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

Re: compile with different source option

[Jörg Schaible]

Hi Philipp,

Philipp Kraus wrote:

 Hello,
 
 I use in my pom.xml the items:
 
 properties
 project.build.sourceEncodingUTF-8/project.build.sourceEncoding
 
project.reporting.outputEncodingUTF-8/project.reporting.outputEncoding
 maven.compiler.source1.8/maven.compiler.source
 maven.compiler.target1.8/maven.compiler.target
 /properties
 
 and I would like to compile only one Java file with Javac 1.7, the whole
 project / all other files should use 1.8. How can I define in my pom.xml,
 that the target compiler value (and the source compiler value) are for
 only one file is set to a different value?

Use two different executions. XStream is doing this in its head, but the 
other way round: Some files with Java 8 the rest with Java 7. Have a look at 
the Java 8 profile.

https://fisheye.codehaus.org/browse/xstream/trunk/xstream/pom.xml?r=2320

Cheers,
Jörg



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

Re: How to escape variable interpolation?

[Jörg Schaible]

David Hoffer wrote:

 I have a case where I have a text file that is generated with a hard coded
 string and I would like to replace that with Maven variables, but I want
 the literal variable string to go in the file not the interpolated values.
 
 I read http://maven.apache.org/shared/maven-filtering/ that i should be
 able to do this with a leading \ but that doesn't work.  It still
 resolves ${service.root.url}.
 
 execution
 idreplace-namespace/id
 phasegenerate-resources/phase
 goals
 goalrun/goal
 /goals
 configuration
 failOnErrortrue/failOnError
 target
 replace
 dir=${project.build.directory}/generated-resources/META-INF/ token=
 http://jmsappsvr/bullpen/service;
 value=\${service.root.url}/bullpen/readwrite 
 include name=**/*.wsdl /
 /replace
 /target
 /configuration
 /execution
 
 How can this be done?
 
 -Dave


Try:

  value=\\\${service.root.url}/bullpen/readwrite

Cheers,
Jörg


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

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

[Jörg Schaible]

A D

Stephen Connolly wrote:

 This is a run-off vote to select the top two options for our new mascot's
 name.
 
 The entries with the highest number of votes will be selected for the
 final round. If there is only one entry with the highest number of votes
 then the entries with the second highest number of votes will also be
 included in the final round.
 
 The vote will be open for 72 hours.
 
 The entries are as follows:
 
 A. Abraham
 B. Boo
 C. Darth Mowl
 D. Jacob
 E. Kaboom
 F. Moses
 G. Rap
 H. Shotgun
 K. The Maven Owl
 L. Ty
 
 It is not clear whether all of the above suggestions were completely
 serious, but I have included them anyway for this first round.
 
 Please respond with at most your top three in order of preference. I may
 not use second or third preferences if we get a sufficient number of
 votes, but in the case of a small poll the additional preferences will
 help.
 
 In the event of repeated votes from an individual, only the last cast vote
 as determined by me will count.
 
 Any other discussion should happen in a separate thread.
 
 Thanks
 
 -Stephen



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

Re: Maven 3.2.3 upgrade

[Jörg Schaible]

Hi Dave,

David Hoffer wrote:

 One other issue came up in this upgrade.  We still have branches that have
 to stay at 3.0.x.  How can I make the trunk build use 3.2.3 w/o changing
 everyone's M2_HOME?  Is there a way to bootstrap the build so the build
 picks the specified version of Maven?  E.g. I want the build to specify
 the version used not the system.

Don't set it at all. The mvn shell scripts will automatically do so for 
their Maven version on-the-fly.

Cheers,
Jörg



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

Re: Maven Plugin Refelction

[Jörg Schaible]

Thomas Scheffler wrote:

 Hi there,
 
 I try to write a simple plugin. I want to have access to the version of
 this plugin. As maven already knows it, I wondered, if I can get access
 to this version string somehow without hardcoding it in properties or
 java code.

Read it from the manifest.

Cheers,
Jörg


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

Re: Change dependency version through property

[Jörg Schaible]

Hi Robert,

Robert Metzger wrote:

 Hi,
 
 I'm a developer at the Apache Flink (incubating) project. I'm trying to
 pass the version of a dependency using a property from the command line to
 the binary build. But it seems that the version I've set is not respected
 everywhere.
 
 
 We have the following setup:
 - flink-parent
- flink-core
- ... more modules ...
- flink-yarn
- flink-dist
 
 The flink-yarn module (and others) have dependencies to Apache Hadoop.
 We have a property (called hadoop.version) to have one place for setting
 the Hadoop version. The default Hadoop version 2.2.0.
 
 The flink-dist module is creating the binary release for Flink. It is
 using the maven-assembly-plugin for that. All jars we depend on are placed
 in the lib directory.
 The flink-dist module has most of our modules (also the flink-yarn)
 module as a dependency so that we can use the modules in the assembly.
 
 
 
 What I'm trying to do is building Flink for a different Hadoop version,
 say 2.2.0-cdh5.0.0-beta-2. Therefore, I'm passing this version as
 -Dhadoop.version=2.2.0-cdh5.0.0-beta-2.
 
 However, some files from Hadoop 2.2.0 end up in the lib directory.
 
 mvn dependency:tree reveals for flink-dist:
 
 [INFO] +- org.apache.flink:flink-yarn:jar:0.8-incubating-SNAPSHOT:compile
 [INFO] |  +- org.apache.hadoop:hadoop-yarn-client:jar:2.2.0:compile
 [INFO] |  |  +- org.apache.hadoop:hadoop-yarn-api:jar:2.2.0:compile
 [INFO] |  |  +- org.apache.hadoop:hadoop-yarn-common:jar:2.2.0:compile
 
 however, for flink-yarn the versions are correct:
 
 [INFO] +-
 org.apache.hadoop:hadoop-yarn-client:jar:2.2.0-cdh5.0.0-beta-2:compile
 [INFO] |  +- commons-logging:commons-logging:jar:1.1.3:compile
 [INFO] |  +- commons-lang:commons-lang:jar:2.6:compile
 
 Here is the full dependency:tree output:
 https://gist.github.com/rmetzger/70c5f35d4cfd06a91169
 
 
 How can I create builds for different Hadoop versions using Maven?

General rule:
- don't use a version tag for direct dependencies
- use a common parent for all modules with
  - a dependency management section for any dependency you want to control
  - use properties for these versions

These properties can be overwritten from command line or setting the 
property again explicitly in a module.

Cheers,
Jörg


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

Re: Why do running modules in parallel take longer to execute than running them in sequence?

[Jörg Schaible]

Hi,

laredotornado-3 wrote:

 Hi,
 
 I’m using Maven 3.2.3, Spring 3.2.11.RELEASE, JUnit 4.11, Java 6, and the
 Surefire/Failsafe 2.17 plugins.  I’m trying to figure out why when running
 a couple of modules in parallel, it takes much longer than when I run them
 individually.  I’m trying to figure out ways to speed up my build.  I have
 this in my parent pom …
 
 modules
 modulecore/module
 …
 modulemodule-x/module
 modulemodule-y/module
 /modules
 
 When I run “mvn clean install -T 4”, modules “module-x” and “module-y” run
 in parallel.  Both have a number of integration tests, all using
 
 @RunWith(SpringJUnit4ClassRunner.class)
 @ContextConfiguration({ classpath:test-context.xml })
 public class MyServiceIT
 {
 
 Below are my surefire/failsafe configurations …
 
 plugin
 
groupIdorg.apache.maven.plugins/groupId

 artifactIdmaven-surefire-plugin/artifactId
 version2.17/version
 configuration
 reuseForkstrue/reuseForks
 argLine-Xmx2048m
 -XX:MaxPermSize=512M /argLine

 skipTests${skipAllTests}/skipTests
 /configuration
 /plugin
 plugin
 
groupIdorg.apache.maven.plugins/groupId

 artifactIdmaven-failsafe-plugin/artifactId
 version2.17/version
 configuration
 reuseForkstrue/reuseForks
 argLine-Xmx4096m
 -XX:MaxPermSize=512M /argLine

 skipTests${skipAllTests}/skipTests
 /configuration
 executions
 execution
 goals

 goalintegration-test/goal
 
goalverify/goal
 /goals
 /execution
 /executions
 /plugin
 
 When I run the tests in parallel, the modules take 11 minutes and 13
 minutes, respectively, to run.  However, running them concurrently
 (without the “-T” option), they execute in 6 minutes and 9 minutes,
 respectively. I’m confused about why they take so much longer to run when
 they both run at the same time and was hoping some folks could suggest
 some ways I can troubleshoot this further.

How much memory do you have? Your test processes take quite a lot and 
executing them in parallel might simply activate disk swapping.

- Jörg


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

Re: move data from pom to class or class to pom

[Jörg Schaible]

Hi Karl-Heinz,

Karl Heinz Marbaise wrote:

 Hi,
 
   Move the Java code that should contain the version into an own
   directory
 tree (e.g. src/main/java-templates). Replace the version string with an
 expression (e.g. ${project.version}) and use the copy-resources goal of
 the resources plugin to filter the file into a target driectory tree
 (e.g. target/generated-sources). Bind the goal to the generate-sources
 phase. Then use additionally the build-helper plugin to add
 target/generated-sources as additional source directory and you're done.
 
 Best solution was already mentoined by Robert Scholte by using the
 templating-maven-plugin which exactly supports that scenario without
 supplemental addition of target/generated-sources folder by
 build-helpr-maven-plugin etc.
 
 Just simply create the template files in src/main/java-templates/ use
 the expressions etc. no need for supplemental configuration of
 maven-resources-plugin etc.
 
 Best and simple solution...which i wrote longer time a go a blog about
 http://blog.soebes.de/blog/2014/01/02/version-information-into-your-appas-with-maven/

nice article ;-)

There's one comment I do not understand though:

 The main disadvantage of this approach is that you can only use the
 Implementation and Specification parts of your MANIFEST.MF file which
 might be enough in some situations but not in all.

You can add all kind of entries to the manifest. You may even overwrite the 
defaults. We use typically:

= % ==
 archive
   manifest
 addDefaultSpecificationEntriestrue/addDefaultSpecificationEntries
 addDefaultImplementationEntriestrue/addDefaultImplementationEntries
   /manifest  
   manifestEntries
 Specification-Version${parsedVersion.majorVersion}.
${parsedVersion.minorVersion}/Specification-Version
 X-Compile-Source${java.version.source}/X-Compile-Source
 X-Compile-Target${java.version.target}/X-Compile-Target
 X-BuilderMaven ${maven.version}/X-Builder
 X-Build-Time${maven.build.timestamp}/X-Build-Time
 X-Build-Os${os.name}/X-Build-Os
   /manifestEntries
 /archive
= % ==

With the $parsedVersion and $maven.version variables provided by the build-
helper plugin.

Cheers,
Jörg


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

Re: move data from pom to class or class to pom

[Jörg Schaible]

Hi Alejandro,

alejandro.e...@miranda.com wrote:

 Hi Curtis,
 
 I *think* i see you point, but wouldn't that happen ONLY if the constant
 is public and referenced in a separate jar?? where it would be inlined in
 the referring class (right?). In my case the constant is package protected
 (it would be private if it wasn't because i need it in unit tests)
 
 The problem with defining it in the manifest is that I use this constant
 in the property of an annotation of the class
 
 @StaticServiceProperty(mandatory = true, type = java.lang.String, name =
 schemaVersion, value = SchemaProviderServiceImpl.SCHEMA_VERSION,
 immutable = true)
 public class SchemaProviderServiceImpl
 
 so I can't grab it from the manifest at runtime. I guess the way I phrased
 it in the original email implied the opposite, sorry about that


typical solution is to generate the source.

Move the Java code that should contain the version into an own directory 
tree (e.g. src/main/java-templates). Replace the version string with an 
expression (e.g. ${project.version}) and use the copy-resources goal of 
the resources plugin to filter the file into a target driectory tree (e.g. 
target/generated-sources). Bind the goal to the generate-sources phase. Then 
use additionally the build-helper plugin to add target/generated-sources as 
additional source directory and you're done.

Cheers,
Jörg


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

Re: AW: AW: Artifact with different sets of dependencies switched by profiles

[Jörg Schaible]

Hi Stephen,

Stephen Connolly wrote:

 And you are going to have the exact same set of issues as with profiles.
 
 Maven 3 does not re-interpolate the poms of dependencies IIRC... or at
 least it is not supposed to... so you only get to control the variables
 from the parent pom and any inherited dependencies/dependencyManagement
 not from the transitive dependencies of your pom

The scope declared in the (inherited) dependencyManagement will overwrite 
any transitive or local one (if not explicitly declared). And if that scope 
is defined by a property, you may overwrite this property in the local pom 
or from command line.

However, if the resulting intermediate artifacts differ, he will run in 
problems.

- Jörg


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

Re: AW: AW: Artifact with different sets of dependencies switched by profiles

[Jörg Schaible]

Hi Christoper,

Christofer Dutz wrote:

 Hi Ron,
 
 I think you got what I'm trying to do a little wrong. It's not two
 different set of dependencies, it's two different ways of linking the same
 set of libraries. If I were to translate this into java, imagine that the
 default way an application was built would be to include all Classes
 needed by the application to be bundled in the application Jar (The
 classes not needed aren't included). Now in modular applications I am able
 to switch to something exactly the same as in Java ... no code is included
 in the Application jar, but the referenced libraries are deployed in
 parallel to the application jar, so the JVM can pull them in as needed (In
 Flex this type is called rsl (runtime shared library).
 
 So in principal I have the same set of dependencies, but in the
 rsl-linking type these dependencies have an additional scope=rsl
 setting. Up until now there was only one pom with the default set of
 dependencies. If the users wanted to utilize rsl linking they would have
 to manually add each dependency and set that's scope to rsl. I would like
 to make it easier for users to switch.
 
 So the profiles is bad, the pom with classifier doesn't work ... I would
 really like to avoid to have something like an flramework artifact and
 one framework-rsl for the rsl linking.

What's the default value for the scope? compile? Then you can do all you 
need with properties. You might use a profile, but it is not necessary:

Declare your dependencies just like before (either in depMgmt or directly):

== % =
 dependency
   groupIdorg.apache.flex.framework/groupId
   artifactIdspark/artifactId
   version4.12.1.20140427/version
   typeswc/type
   scope${flexmojo.scope}/scope
 /dependency
 ...
 properties
   flexmojo.scopecompile/flexmojo.scope
 /properties
== % =

Then you can simply redefine flexmojo.scope from command line. This will 
also affect inherited dependencies, if they are declared in the same way in 
the repository or if you delcare them in a common parent with a 
dependencyManagement section. You might even overwrite the property in a 
profile:

== % =
 profile
   idrsl/id
   properties
 flexmojo.scopersl/flexmojo.scope
   /properties
 profile
== % =

Unfortunately, I don't know nothing about flexmojo. If it works like in the 
world of C where I can use the same libraries (.lib files) to link an 
application either static or dynamically (then requiring runtime libs as 
well), then it is possible to do this. Therefore is is fine for an project 
creating such an application at the end of a build chain.

However, if the libraries differ if build with rsl or not, then you will 
create a very bad user experience, because - just as Stephen already said - 
the build process will use whatever it finds in the local repository, it 
cannot separate between artifacts built with rsl or without. Your users 
might get a wild mix during build time.

Cheers,
Jörg


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

Re: Pack with native tar, unpack with maven-dependency-plugin failure

[Jörg Schaible]

Hi Dan,

Dan Tran wrote:

 I found the root cause of this issue where  I need to force a '-z' option
 during native tar compression.  Without this flag, the output is just a
 normal tar file where native tar is very smart to figure this out. Where
 are plexus-archiver only looks for gz signature and bails out.

You may always use the file utility to get an idea of the real file 
format:

= % =
~/tmp $ tar cf test-tar.tar.gz *.txt
~/tmp $ tar czf test-gz.tar.gz *.txt
~/tmp $ tar cjf test-bz2.tar.gz *.txt
~/tmp $ file *.tar.gz
test-bz2.tar.gz: bzip2 compressed data, block size = 900k
test-gz.tar.gz:  gzip compressed data, last modified: Tue Jun  3 07:50:26 
2014, from Unix
test-tar.tar.gz: POSIX tar archive (GNU)
= % =

Cheers,
Jörg


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

Re: Maven Jar Plugin - Testjar: includes together with skipIfEmpty

[Jörg Schaible]

Hi Nick,

Nick Stolwijk wrote:

 Hi Folks,
 
 I found a little curiosity in the maven jar plugin.
 
 if you specify includes and the skipIfEmpty property a jar is still
 created and attached while it only has a pom file in it. I would have
 expected that the creation of the jar was skipped if no files where
 selected by my includes property.

Well, since the default includes the pom, the jar is not empty.

 My usecase: I only want to generate the tests jar when there are
 builders in the module, so other modules can use those builders in
 their tests. I don't want to package all tests, to prevent developers
 to create dependencies on these tests.
 
 My configuration:
 
 plugin
 artifactIdmaven-jar-plugin/artifactId
 executions
 execution
 goals
 goaltest-jar/goal
 /goals
 configuration
 skipIfEmptytrue/skipIfEmpty
 includes
 include**/*Builder.class/include
 /includes
 /configuration
 /execution
 /executions
 /plugin

Configure the archiver to skip the Maven descriptor:

== % ==
 configuration
   archive
 addMavenDescriptorfalse/addMavenDescriptor
   /archive
 /configuration
== % ==


Cheers,
Jörg


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

Re: Why Is Maven Ignoring My Local Repo?

[Jörg Schaible]

Stephen Connolly wrote:

 It's not a local repository. It is a local repository cache.
 
 There are files there that record where the artifacts were cached *from*.
 
 If the artifact is there but the cache file is not or indicates a
 different source from the allowed sources for your build, then Maven will
 ignore the artifact in your cache and check the remote sources.

Alas, if only the site plugin would be able to determine the proper source - 
then anything would be fine ...

- Jörg

 
 
 On 15 April 2014 02:02, Eric Kolotyluk e...@kolotyluk.net wrote:
 
 I seem to keep running into this problem regularly for things not in
 Maven Central

 [ERROR] Failed to execute goal
 [org.apache.maven.plugins:maven-site-plugin:3.3:site
 (default-site) on project csharp-windows-elevate: Execution default-site
 of goal org.apache.maven.plugins:maven-site-plugin:3.3:site failed:
 Plugin org.apache.maven.plugins:maven-site-plugin:3.3 or one of its
 dependencies could not be resolved: Could not find artifact
 net.trajano.wagon:wagon-git:jar:1.0.1-SNAPSHOT in local-nexus
 (http://localhost:8081/nexus/content/groups/public) -
 [Help 1]

 I can see the artifact in my local repo, but maven somehow feels, because
 it cannot find it in my nexus repository, then it does not exist.

 The side problem is, even though nexus can see the artifact in its index,
 it refuses to download it.

 Why do maven and nexus work so hard at ignoring artifacts?

 Cheers, Eric


 -
 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