Re: Running maven-checkstyle-plugin from the root module

[org . apache . maven . user]

On 21/04/2024 19:03, Jeff Jensen wrote:
> Sorry for the vagueness.  I meant something even simpler - running the
> Checkstyle goal separately, probably in two Maven executions similar to:
>   mvn checkstyle:checkstyle
>   mvn install -Dcheckstyle.skip=true

I have ended up having to do something kind of similar to that in
practice on the larger builds. I'm trying to get to the point where
"mvn clean package" is always the acceptable thing to run, rather than
having to split things up into separate commands during development
(hence this message to the list!).

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


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

Re: Running maven-checkstyle-plugin from the root module

[org . apache . maven . user]

On 21/04/2024 15:59, Jeff Jensen wrote:
> Have you considered only running the checkstyle goal, from the parent so it
> processes all modules, before the full build goal(s)?
> 

There are two ways that I can interpret this:

1. Set the execution in the parent so that all of the child modules
essentially gain an execution. This is what I already have, and has the
limitations I described.
2. Set an execution in the parent that somehow processes all child
modules and is not inherited.

I think 2. is what I want, but I can't see from the documentation how
the plugin can be configured like this. It seems like it wants to work
on one module at a time.

Have I missed something?

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


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

Running maven-checkstyle-plugin from the root module

[org . apache . maven . user]

Hello!

I've been using the maven-checkstyle-plugin for many years now. Almost
all of my projects are heavily multi-module, and I have a fairly
traditional setup where a checkstyle plugin execution is defined in
my organization-wide POM, and inherited by all modules in all projects.
I run checkstyle in the process-sources phase and refuse to build
code if there are style errors:

https://github.com/io7m/primogenitor/blob/develop/pom.xml#L503

This works well enough in the sense that I don't have to repeat any
configuration information, and I can opt-out of checking on a per-module
basis if necessary by setting checkstyle.skip in the module's properties.

Where it _doesn't_ work well enough is that I really want to, for a
given project, get all style errors in all modules before anything else
in the build proceeds. I have projects where style checks succeed in
module A, and then module B takes a minute or so to build, and then a
style check fails in module C. I'd prefer to style check modules A, B,
and C ahead of time so that I don't have to sit through a time-consuming
build of B just to have C fail.

There doesn't seem to be a nice way to configure this. Ideally I would
want checkstyle to check all sources matching a given pattern
("*/src/main/java/**.java", probably). Even if I _could_ get the plugin
to do this, it's not clear how I would preserve the ability to opt-out
of checking on a per-module basis. I'm aware of the source-level
comments like // CHECKSTYLE:OFF and so on, but I prefer to put this kind
of thing in the POM.

Anyone got any ideas?

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

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

Re: Accessing licenses/license as POM properties?

[org . apache . maven . user]

On 2018-05-18T17:01:52 +0200
Andreas Sewe  wrote:

> Hi,
> 
> > Is there a way to access the contents of the  element as POM
> > properties? I'd like to reference the URL of the first license element
> > in a plugin execution, but there doesn't appear to be a
> > ${pom.license.url} or anything similar.  
> 
> here's what I use as an  for the maven-bundle-plugin to
> generate a Bundle-License line in my MANIFEST.MF:
> 
> > ${project.licenses[0].url};description="${project.licenses[0].name}"
> >   
> 
> Works like a charm, as long as you have exactly one license.

Looks good, thanks!

You're also using it for the exact same reason I'd be using it. :)

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



pgp4j6uhckNwT.pgp
Description: OpenPGP digital signature

Disabling javadoc doclint for generated sources?

[org . apache . maven . user]

Hello.

My hand-written code passes Java 8's JavaDoc doclint checks. However, I
also have some code (that has to be in the same package) generated by
an external tool. The JavaDoc that this tool produces doesn't always
pass the doclint checks.

Is there a way to exclude the generated-sources directory from the
doclint checks?

M


pgpxNYDBRXlAR.pgp
Description: OpenPGP digital signature

Re: Enforcer requirePropertyDiverges not propagated to descendants?

[org . apache . maven . user]

On 2017-03-06T10:58:30 -0600
Curtis Rueden  wrote:

> Hi,
> 
> For what it's worth, I agree that the requirePropertyDiverges rule is
> difficult to use (and maybe buggy?). After playing with it some months ago,
> I concluded that it was not going to work for me. That's why I ended up
> writing my own rule.
> 
> If you want to ensure that the description is set in each child POM, maybe
> the scijava-maven-plugin's requireElements rule _can_ help you here? Or do
> you, again, only want to set the description in some intermediate POM layer?

https://github.com/io7m/primogenitor/commit/021b5a9a6577c02346d85242b77db31f88f8e25c

:D

"A better fix would be to use scijava's requireElements rule and just
assume that anyone capable of creating new elements would be capable of
making them different from the ancestor."

M


pgpyTk0gy5JRU.pgp
Description: OpenPGP digital signature

Re: Enforcer requirePropertyDiverges not propagated to descendants?

[org . apache . maven . user]

Hello.

On 2017-03-05T01:18:34 +0100
Hervé BOUTEMY  wrote:

> first, you'll have to talk about rules, not only the plugin: there are many 
> rules, some implemented by the plugin and some implemented by MojoHaus extra-
> enforcer-rules

Right, yes. It's the requirePropertyDiverges rule in the
extra-enforcer-rules package in this case.

> 
> then: MojoHaus requirePropertyDiverges [1] requires that the property value 
> is 
> different, not that it is not empty
> 
> IIUC what you're trying to do, you'll need both Maven requireProperty [2] and 
> MojoHaus requirePropertyDiverge [1]

That seems wrong, somehow, and it doesn't match the behaviour that I
posted. If I don't define a property, then the property (if any) will
be inherited from an ancestor project, yes? The problem I'm having is
that the requirePropertyDiverges rule seems to stop working after one
level of inheritance. See these three example cases:

0. Project A defines a property P. Project B inherits from
   A and doesn't redefine or declare P. The requirePropertyDiverges rule
   correctly rejects this case and the build fails.

   https://github.com/io7m/requirePropertyDiverges-20170305/tree/master/case-0

   ^^ Building this project should fail, and it does.

1. Project A defines a property P. Project B inherits from A and
   redefines P with a different value. The requirePropertyDiverges rule
   correctly accepts this case and the build succeeds.

   https://github.com/io7m/requirePropertyDiverges-20170305/tree/master/case-1

   ^^ Building this project should succeed, and it does.

2. Project A defines a property P. Project B inherits from A and
   redefines P with a different value. Project C inherits from B
   and doesn't redefine or declare P. This case *should* fail,
   because in C, P is inherited from B and therefore has not diverged.

   https://github.com/io7m/requirePropertyDiverges-20170305/tree/master/case-2

   ^^ Building this project should fail, but it doesn't.

M


pgpM9RdH_mRmy.pgp
Description: OpenPGP digital signature

Enforcer requirePropertyDiverges not propagated to descendants?

[org . apache . maven . user]

Hello.

I'm trying to use the Enforcer plugin to ensure that projects set a
${project.description} that is different to their parent. I'm using
an organization-wide POM, and the rule is specified here:

  https://github.com/io7m/primogenitor/blob/develop/pom.xml#L540

I have an example multi-module project that uses that root POM here:

  https://github.com/io7m/primogenitor-example-20170304

If I fail to set a description in the "root" POM of that project
(in other words, if I remove
https://github.com/io7m/primogenitor-example-20170304/blob/master/pom.xml#L20),
the Enforcer rule fails the build correctly. However, if I leave
that description intact but then fail to set a different
(or indeed any) description in the mod-a POM
(https://github.com/io7m/primogenitor-example-20170304/blob/master/mod-a/pom.xml),
the Enforcer plugin doesn't catch it. I would expect the linked example
project to fail to build, but it doesn't!

Am I doing something wrong? I thought the purpose of the
requirePropertyDiverges rule was to check the current project against
its immediate parent. If this is correct, then something appears to be
wrong with the plugin...

M


pgp1k4qKQDnm1.pgp
Description: OpenPGP digital signature

Re: Defining a property designed to be overridden?

[org . apache . maven . user]

On 2017-03-02T11:12:58 -0600
Curtis Rueden  wrote:

> Hi,
> 
> > I'd need to think a bit more about it, but I personally dislike
> > relativePath and have never used it (across hundreds of projects),
> > pretty much for the sorts of reasons you've described. Hard-coding
> > paths that represent links to other modules seems like a
> > horrendously bad idea.  
> 
> That is fair. I will point out, though, that if you do not specify the
> relativePath, then it is ".." by default. Best practice is to write
> "" if you explicitly do _not_ want Maven to check for the
> parent in the parent directory. Hence, if we implemented my requireElements
> enhancement, the relativePath would be treated as ".." when one is not
> explicitly specified.

Right.

I get the sense that adding  is something that would
upset IDEs (my experience has been that they cope relatively poorly
with anything uncommon like that).

> I will also point out that each "" of a multi-module build is also
> a hard-coded link to another module, which according to your reasoning,
> makes multi-module projects in general a horrendous idea. (And I am not
> being totally facetious here—I personally prefer never to use multi-module
> projects at all. Though I would not go so far as to call them
> "horrendous"—they definitely have their uses.)

Hehe, I probably overstated it a touch. I tend to think of the 
entries slightly differently though: I consider them to be module names
that match the artifact ID of the submodule and also just happen to
correspond to the directory that contains the module's sources. They
don't inspire the same revulsion because they don't exist in my mental
model as filesystem paths. I'm not actually sure they are in Maven's
model either... Can a module name contain slashes?

> > I've written a few plugins, but I'm not intimately familiar with the
> > Maven API: Shouldn't it be possible to recursively retrieve the parent
> > POMs from the reactor (and failing that, the local and remote
> > repositories) within the plugin? That would remove the need for
> > .  
> 
> Sure. You are absolutely welcome to file a PR against the
> scijava-maven-plugin adding this feature. The complication is just that
> instead of loading POMs from local files, you now also need to resolve them
> from the appropriate remote repositories, for which there is certainly
> Maven API, but I am also not familiar enough with it to tell you what it is
> off the top of my head. Hopefully someone else here can comment in more
> detail, and/or suggest alternative solutions here. In any case, if you
> pursue this, it should work to test locally by installing the plugin into
> your local repo cache using the "install" phase, and then using
> "org.scijava:scijava-maven-plugin:1.0.1-SNAPSHOT" in your test POMs.

I will give it a go. I've had somewhat poor experiences with the Maven
APIs as they tend not to be documented too well. I may end up living
with just not enforcing these things...

M


pgpNNHD4Cw4ln.pgp
Description: OpenPGP digital signature

Re: Defining a property designed to be overridden?

[org . apache . maven . user]

On 2017-03-02T10:29:30 -0600
Curtis Rueden  wrote:

> > it seems that I can only require that the XML elements be overridden
> > in *all* descendant POMs, and this introduces too much redundancy.  
> 
> I see.
> 
> Would it be sufficient if the requireElements rule had a multiModule flag
> which, if set, green-lighted the build when the stated elements are defined
> in the local parent POM? This feature would assume you are using the
> aggregator==parent scheme, and follow the  declared in the
>  of each POM. If it finds a POM there, it would parse it and then
> check for the required elements in _that_ POM instead of the initial one.
> And do this recursively, in case you have a multi-layered multi-module
> build.
> 
> The downside of this approach: modules of a project would only build if the
> parent is available locally. E.g.: if you try to build one module of a
> multi-module build which has been physically disconnected from its parent
> (e.g., a partial SVN checkout), the enforcer would fail because it would
> not find the local parent POM to validate against. One can also imagine
> various "aggegator != parent" organizations where the parent is not
> available locally, which would also all fail to support this scheme.
> 

I'd need to think a bit more about it, but I personally dislike
relativePath and have never used it (across hundreds of projects),
pretty much for the sorts of reasons you've described. Hard-coding
paths that represent links to other modules seems like a horrendously
bad idea.

I've written a few plugins, but I'm not intimately familiar with the
Maven API: Shouldn't it be possible to recursively retrieve the parent
POMs from the reactor (and failing that, the local and remote
repositories) within the plugin? That would remove the need for
.

If that is possible, then I think the pseudocode is:

  let root(p) be the root POM of project p
  let parent(p) be the parent of p
  let definesElements(p) return true if p defines the required elements

  Project q = p
  while (!done) {
if (q == root(p)) {
  throw RequiredElementsMissing()
}

if (definesElements(q)) {
  done = true
}

q = parent(p)
  }

This feels like it would achieve what I need with only minimal
assumptions about the hierarchy of projects.

M


pgp1IyM3UMFWw.pgp
Description: OpenPGP digital signature

Re: Defining a property designed to be overridden?

[org . apache . maven . user]

'Ello.

On 2017-03-02T08:16:43 -0600
Curtis Rueden  wrote:

> Hi,
> 
> > I do actually want to enforce this, the issue is that I only want to
> > enforce it as far as the first ancestor.  
> 
> Sorry if you stated otherwise in your writeup, but my understanding is that
> you want to define some empty properties in your new root POM, and then
> ensure they are _not_ empty in the next level down. Right?

Yes, but additionally some XML elements as well.

I'd like to enforce that:

  1. Some properties that are defined as empty in the root POM are
 non-empty in all descendants.

  2. Some XML elements that are defined in the root POM (such as
 issueManagement) are overridden _at least once_ between the root
 and any leaf project.

The requireProperty rule you provided does seem to properly handle point
1, but I think that the options we've discussed are too heavy-handed
for point 2. Unless I've missed something obvious, it seems that I can
only require that the XML elements be overridden in *all* descendant
POMs, and this introduces too much redundancy.

M


pgpx1cabVCYFf.pgp
Description: OpenPGP digital signature

Re: Defining a property designed to be overridden?

[org . apache . maven . user]

Hello!

On 2017-03-01T15:49:10 -0600
Curtis Rueden  wrote:
>
> If what you want is to ensure the property is simply non-empty, or matching
> a particular regex, then take a look at the requireProperty enforcer rule
> [1].
> 
> Or if your goal is to make sure that a property value _differs_ from the
> value defined in an ancestor, the requirePropertyDiverges rule [2] might be
> for you.

I do actually want to enforce this, the issue is that I only want to
enforce it as far as the first ancestor. My current projects look like
this (where indentation indicates inheritance):

  + io7m-jtensors
+ io7m-jtensors-core
+ io7m-jtensors-tests
+ io7m-jtensors-ieee754b16
+ ...
  + io7m-r2
+ io7m-r2-core
+ io7m-r2-shaders
+ ...

I want to move to:

  + io7m-ancestor
+ io7m-jtensors
  + io7m-jtensors-core
  + io7m-jtensors-tests
  + io7m-jtensors-ieee754b16
  + ...
+ io7m-r2
  + io7m-r2-core
  + io7m-r2-shaders
  + ...

So I want to enforce that io7m-jtensors and io7m-r2 override the
required properties (and elements such as issueManagement), but I don't
want to propagate that requirement to the individual submodules of
io7m-jtensors such as io7m-jtensors-core, because this would introduce
pointless redundancy. I have around 50 top-level projects to manage in
this form, so any redundancy that can be eliminated really needs to be!

I'm not sure the enforcer plugin is able to express this "only redefine
once" aspect of the above. Am I wrong?

M


pgpqJtii9lFmz.pgp
Description: OpenPGP digital signature

Re: Defining a property designed to be overridden?

[org . apache . maven . user]

On 2017-03-01T12:46:45 -0600
Curtis Rueden  wrote:
> 
> In this way, I ensure that all projects which extend our parent add all the
> useful metadata and properties needed for successful builditude.
> 

Hm, slight issue with this.

If you take a look at how my projects are usually designed:

  https://github.com/io7m/jtensors/blob/develop/pom.xml

That's the root pom for the project. It defines all of the project's
information such as plugin versions, dependency versions, metadata such
as the SCM location, site, etc.

Then, each module looks like this:

  https://github.com/io7m/jtensors/blob/develop/io7m-jtensors-core/pom.xml

Note how this is a module of the root project and therefore it'd be
redundant to have to re-specify all of the information such as the
contributors, SCM location [0], etc. I only provide the information
that's specific to that module such as the OSGi manifest, dependencies,
etc.

Using the scijava-maven-plugin RequireElements rule would seem to
require me to specify all of this information again in each module.
Is there a way to avoid this?

M

[0] Although I do actually have to re-specify the SCM location due to
an utterly ancient bug/design flaw in the site plugin.


pgp5ZQu43yUl2.pgp
Description: OpenPGP digital signature

Re: Defining a property designed to be overridden?

[org . apache . maven . user]

On 2017-03-01T12:46:45 -0600
Curtis Rueden  wrote:
>
> In this way, I ensure that all projects which extend our parent add all the
> useful metadata and properties needed for successful builditude.
> 
> We released scijava-maven-plugin 1.0.0 on Maven Central; feel free to use
> it if it helps you.

Hah, well, I'm not sure you could have solved my problem any more
precisely than that! Looks like exactly what I need. Thanks very much!

M


pgpLYGw3U7Uf4.pgp
Description: OpenPGP digital signature

Defining a property designed to be overridden?

[org . apache . maven . user]

Hello.

I'm looking to move to an organization-wide parent POM but am not sure
how to handle the following configuration case.

The japicmp [0] plugin takes a configuration parameter that specifies
the previous version of a module against which the current version of
the module will be checked for API compatibility. I believe it can
sometimes infer the correct version by itself, but for the sake of
explanation here, let's assume that it can't and that I need to specify
it myself. This isn't a japicmp plugin issue, it's just a specific
example of a more general problem regarding the scope and definitions
of properties.

I have a parent pom:

https://github.com/io7m/maven-parent-properties-20170301/blob/develop/pom.xml

... which contains a definition like this:


  ...
  

  

  ...

  

  


  com.github.siom79.japicmp
  japicmp-maven-plugin
  0.9.4
  

  verify
  
cmp
  
  

  
${project.groupId}
${project.artifactId}
${io7m.previousVersion}
jar
  

  

  

  

  


I then have an example project that inherits from the parent:

https://github.com/io7m/maven-parent-properties-20170301/blob/develop/mod-a/pom.xml


  
com.io7m.experimental
maven-parent-properties-20170301
1.0.0
  

  mod-a
  
0.9.0
  

  

  
com.github.siom79.japicmp
japicmp-maven-plugin
  

  


Note that the child project must override the io7m.previousVersion
property from the parent. Is this the correct way to handle this? The
downside to this is that if a project forgets to override the property
value, it won't get a sensible "You didn't define this property" error
because it's already defined with an empty value in the parent. If I
don't define the property in the parent, many IDEs get upset at the
presence of an undefined property in the POM.

Any advice would be appreciated.

M

[0] https://siom79.github.io/japicmp/MavenPlugin.html


pgpMdi3j13ccx.pgp
Description: OpenPGP digital signature

Re: Single-page sites?

[org . apache . maven . user]

'Ello.

On 2017-02-28T02:38:02 +0100
Hervé BOUTEMY  wrote:

> Hi,
> 
> No, this is not a current option of maven-site-plugin.

Right, that's what I suspected.

> 
> Pdf plugin does such equivalent one doc from every report.

Do you mean one large pdf that contains the contents of each report?

> 
> but writing such a plugin for one unique html page is not an easy tasks: in 
> addition to the whole reporting integration work, you'll need to work on 
> inter-document links in this unique html file.
> 

That may not be *too* bad as long as plugins aren't constructing links
manually or assuming that the elements they're linking to are on
different pages (could have issues with id attributes no longer being
unique and so on).

I'll take a look.

M


pgpff1z4YVDrP.pgp
Description: OpenPGP digital signature

Single-page sites?

[org . apache . maven . user]

Hello.

I realize this may be a long shot: Is there any way to get the site
plugin to produce one large HTML file instead of one file per report?

If not, does anyone happen to know how much work would be involved in
perhaps writing an alternative site plugin that can do this?

M


pgp5T3pfM7JvT.pgp
Description: OpenPGP digital signature

Re: Deploying independently versioned modules

[org . apache . maven . user]

On 2017-02-08T19:25:01 -0800
Charles Honton  wrote:

> Take a look at maven exists plugin 
> [https://chonton.github.io/exists-maven-plugin/0.0.2/ 
> ].  This has goals to 
> prevent deployment or installation of artifacts which already exist.
> 

Ah, interesting, thank you!

I'll be testing this one today.

M


pgpo7QEAAY2LL.pgp
Description: OpenPGP digital signature

Deploying independently versioned modules

[org . apache . maven . user]

Hello.

For years, I've been developing libraries as sets of modules sharing a
(semantic) version number. For each project, the project's root Maven
module defines the version number for all modules in the project. As a
result, intra-project dependencies can be efficiently declared like
this:

  
${project.groupId}
a-module
${project.version}
  

My release process for version x.y.z of any project looks like this:

  $ git flow release start x.y.z
  $ mvn versions:set -DnewVersion=x.y.z
  $ git add pom.xml */pom.xml
  $ git commit -m 'Mark x.y.z'
  (try a build, wait for CI results, etc, etc, etc)
  $ git flow release finish
  $ git push --all
  $ git push --tags
  $ mvn clean deploy site site:stage && mvn nexus-staging:rc-list
  $ mvn nexus-staging:rc-close -DstagingRepositoryId=...
  $ mvn nexus-staging:rc-release -DstagingRepositoryId=...

However, I've recently begun migrating to OSGi and in an OSGi context,
as soon as you have API bundles, it makes more sense to have
independently semantically-versioned modules. The version number of the
aggregating root Maven module therefore identifies a set of module
versions as opposed to dictating a fixed version number for all
submodules.

This is all fine, except for step 8 in my release process... If an API
module has not changed, the version number will not have changed.
Artifacts are immutable, and therefore I don't want to attempt to
deploy the same version of a module again. I can try to manually deploy
by specifying a list of projects with -pl, but this means that my
release process has to be different for each project. I have rather a
lot of projects (~70 and counting), so I'd prefer to avoid any
project-specific procedures in order to preserve my own sanity.

Is there some way I can get the deploy plugin (or possibly the nexus
staging plugin) to determine that it doesn't need to deploy a module
twice?

M


pgp8r9qa_kzBF.pgp
Description: OpenPGP digital signature

Re: Slightly more advanced resource filtering (templating)?

[org . apache . maven . user]

On 2017-01-03T19:32:59 +0100
Guillaume Boué  wrote:

> It sounds like you're looking for the parse-version goal of the 
> build-helper-maven-plugin: 

On 2017-01-03T19:36:16 +0100
Karl Heinz Marbaise  wrote:
> Hi,
> 
> have you taken a look at the build-helper-maven-plugin

On 2017-01-03T12:45:19 -0600
Curtis Rueden  wrote:

> Hi,
> 
> In addition to the suggestion of others to use parse-version...

Thanks to all of you!

build-helper-maven-plugin looks to be exactly what I need.

M


pgp2negKEm8Wd.pgp
Description: OpenPGP digital signature

Slightly more advanced resource filtering (templating)?

[org . apache . maven . user]

Hello.

I have a small project that contains a plugin for Blender[0]. Plugins
in Blender are Python files that must contain a hash value at the top
of the file containing version information. The version information has
to be numeric constants as Blender actually parses this data rather
than evaluating it in an interpreter.

https://github.com/io7m/smf/blob/develop/io7m-smfj-blender/src/main/resources/__init__.py

Right now, I'm having to remember to manually insert the right version
number each time I increment the Maven version. I'd much rather filter
the Python source file as a resource instead, but unfortunately I'd
need to transform the Maven version string:

  2.3.1 → (2, 3, 1)

Is there an existing plugin that can do this? I assume that it'd be
some sort of templating engine. Unfortunately, all of the search
results for that seem to be in regards to the site plugin.

M

[0] http://blender.org


pgpB0sorrcv35.pgp
Description: OpenPGP digital signature

Re: Using the Maven API outside of a plugin?

[org . apache . maven . user]

On 2016-12-28T12:20:20 +
org.apache.maven.u...@io7m.com wrote:

> Hello.
> 
> I'm writing a small program to analyze the dependencies of Maven
> projects. There are numerous examples of how to do this from within a
> Maven plugin, but I can't work out how to simply load a POM file and
> derive a ProjectDependencyGraph from it outside of the context of a
> plugin. How do I instantiate all of the required classes? As an
> example, I believe I need to instantiate a MavenSession, but all of the
> constructors of that class are deprecated...
> 
> Does anyone have any example code or documentation I can look at?
> 
> M

Am I perhaps correct in thinking that nobody actually knows how to do
this, and that everyone depends on a DI framework instead?

M


pgpgQXv9pKiIT.pgp
Description: OpenPGP digital signature

Using the Maven API outside of a plugin?

[org . apache . maven . user]

Hello.

I'm writing a small program to analyze the dependencies of Maven
projects. There are numerous examples of how to do this from within a
Maven plugin, but I can't work out how to simply load a POM file and
derive a ProjectDependencyGraph from it outside of the context of a
plugin. How do I instantiate all of the required classes? As an
example, I believe I need to instantiate a MavenSession, but all of the
constructors of that class are deprecated...

Does anyone have any example code or documentation I can look at?

M


pgpf11zxYuaSF.pgp
Description: OpenPGP digital signature

Distinguishing between host and container dependencies

[org . apache . maven . user]

Hello.

I'm working on an application that uses an embedded OSGi container to
provide a plugin system.

The problem I'm running into is that I don't seem to have any way to
distinguish between dependencies that are dependencies of the host, and
dependencies that will only be present in the container. The distinction
is that the former will be copied into a directory to be placed onto the
classpath when the application is started and the latter will not be on
the classpath but will instead be copied into a directory at build time
to be scanned/installed by the container at runtime.

I feel like the most natural way to specify this would be to be able to
add a custom scope:

  
x.y.z
example
0.1.0
container
  

The maven-dependency-plugin could then be instructed to copy host
dependencies to one location, and container dependencies to another.
This would also play nicely with IDEs that build classpaths from Maven
dependencies (container-scoped dependencies wouldn't be on the
classpath).

Ideally, this container scope would be propagated transitively
(although I'm not sure what happens if both the host and container
indirectly depend on the same dependency).

I can't distinguish based on types alone, as all of the dependencies
are a mix of plain jars and OSGi bundles (some host dependencies are
bundles, some are plain jars, all of the container dependencies are
bundles).

Is there some other way I can achieve this? Alternatives that don't
play nicely with IDEs aren't an option.

M


pgprmVe4iEg45.pgp
Description: OpenPGP digital signature

Re: "mvn clean verify deploy" causes jar plugin to execute twice

[org . apache . maven . user]

On 2016-08-05T18:48:25 +0200
Anders Hammar  wrote:
>
> Executing
> mvn verify deploy
> will execute the build lifecycle twice. No need to do that. Just execute
> mvn deploy
> as the deploy phase comes after the verify phase.


On 2016-08-05T18:09:46 +0100
Stephen Connolly  wrote:
>
> TL;DR don't run `mvn clean verify deploy` run `mvn clean deploy` as
> `deploy` is after `verify`
> 

Thanks, both of you!

After some five years of using Maven daily, I had no idea that it
didn't eliminate redundant lifecycle calls in that manner... Always
something new.

M


pgp_jUBmBDnHZ.pgp
Description: OpenPGP digital signature

Re: "mvn clean verify deploy" causes jar plugin to execute twice

[org . apache . maven . user]

On 2016-08-05T15:19:05 +
org.apache.maven.u...@io7m.com wrote:
> 
> Note that there are no sources in src/main as this is a module containing 
> the unit tests for all other modules. However, this has not been a problem
> to date and have used this arrangement without issue in some 40 or so
> projects. Today, it suddenly appears to be a problem.

Adding a single empty/useless class to src/main/java in the offending
module works around the issue. This seems like a bug to me...

M


pgp2NydWfCzId.pgp
Description: OpenPGP digital signature

"mvn clean verify deploy" causes jar plugin to execute twice

[org . apache . maven . user]

Hello.

I've run into a bizarre problem when trying to deploy a project.

If I run "mvn clean verify", the project builds without issue. If I run
"mvn clean verify deploy", the project fails to build (on the very last
module, naturally).

The error is:

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-jar-plugin:3.0.0:jar (default-jar) on project 
io7m-jsx-tests: You have to use a classifier to attach supplemental artifacts 
to the project instead of replacing them. -> [Help 1]

I am not attaching supplemental artifacts in that module, and am also not
replacing any.

The project in question is here:

  https://github.com/io7m/jsx/tree/develop

The failure occurs when deploying the io7m-jsx-tests module:

  http://ataxia.io7m.com/2016/08/05/build.txt

Note that there are no sources in src/main as this is a module containing 
the unit tests for all other modules. However, this has not been a problem
to date and have used this arrangement without issue in some 40 or so
projects. Today, it suddenly appears to be a problem.

Is this a bug? Is there anything I can do to fix it?

M


pgprAWNG6GFEp.pgp
Description: OpenPGP digital signature