Re: [ANN] Apache Maven Daemon 1.0.1 released
I can read the project README, yes. Are there plans to publish anything about mvnd on the official Maven website? Acknowledging it exists, linking to the repo, anything like that? On Mon, Jun 24, 2024 at 1:56 PM Slawomir Jaranowski wrote: > pon., 24 cze 2024 o 16:57 Greg Chabala > napisał(a): > > > > > > > If you have any questions, please consult: > > > - the web site: https://maven.apache.org/ > > > > > > Are there any pages on the website about mvnd? I don't see it mentioned > > anywhere. > > > > You can read https://github.com/apache/maven-mvnd > > > > > > On Mon, Jun 24, 2024 at 1:33 AM Slawomir Jaranowski < > > sjaranow...@apache.org> > > wrote: > > > > > The Apache Maven team is pleased to announce the release of the Apache > > > Maven Daemon version 1.0.1 > > > > > > This release provides binaries based on Maven 3.9.8. > > > > > > (From now on, Maven Daemon 1.x line will wrap Maven 3.x binaries, while > > > Maven Daemon 2.x will wrap Maven 4.x binaries. Previous releases used > the > > > same version for both binaries with "m39" and "m40" designators, they > are > > > now gone.) > > > > > > The release source and binary bundles are available for download at: > > > https://downloads.apache.org/maven/mvnd/1.0.1/ > > > > > > The changelog is available at: > > > https://github.com/apache/maven-mvnd/releases/tag/1.0.1 > > > > > > If you have any questions, please consult: > > > - the web site: https://maven.apache.org/ > > > - the maven-user mailing list: > > https://maven.apache.org/mailing-lists.html > > > - the mvnd issue tracker: https://github.com/apache/maven-mvnd/issues > > > > > > Regards, > > > The Apache Maven Team > > > > > > > > -- > Sławomir Jaranowski >
Re: [ANN] Apache Maven Daemon 1.0.1 released
> > If you have any questions, please consult: > - the web site: https://maven.apache.org/ Are there any pages on the website about mvnd? I don't see it mentioned anywhere. On Mon, Jun 24, 2024 at 1:33 AM Slawomir Jaranowski wrote: > The Apache Maven team is pleased to announce the release of the Apache > Maven Daemon version 1.0.1 > > This release provides binaries based on Maven 3.9.8. > > (From now on, Maven Daemon 1.x line will wrap Maven 3.x binaries, while > Maven Daemon 2.x will wrap Maven 4.x binaries. Previous releases used the > same version for both binaries with "m39" and "m40" designators, they are > now gone.) > > The release source and binary bundles are available for download at: > https://downloads.apache.org/maven/mvnd/1.0.1/ > > The changelog is available at: > https://github.com/apache/maven-mvnd/releases/tag/1.0.1 > > If you have any questions, please consult: > - the web site: https://maven.apache.org/ > - the maven-user mailing list: https://maven.apache.org/mailing-lists.html > - the mvnd issue tracker: https://github.com/apache/maven-mvnd/issues > > Regards, > The Apache Maven Team >
Re: Will this potentially break in future releases ?
I like both of these approaches better than the Scala approach to binary compatibility, which is to munge a version into the artifact ID. That feels very broken to me, but unfortunately that is their standard now. I have heard of complaints that using classifiers to specify bytecode level can cause dependency resolution issues, but that sounds like a problem that needs to be exposed and solved, not worked around. The POM reference highlights using classifiers for bytecode versioning explicitly: https://maven.apache.org/pom.html#dependencies (I wish this page had an anchor for the classifier section).
Re: [DISCUSS] Maven Dependency Plugin
Hello Tamás, For context, what are the tensions that you're trying to solve here? Is m-dependency-p too big/getting unmaintainable/becoming a kitchen sink? Do some goals feel like a bad fit? Are you thinking of breaking it up or replacing it? Greg On Tue, Mar 26, 2024 at 8:52 AM Tamás Cservenák wrote: > Howdy, > > just to not let this discussion die off. Let me show a take on a "how > modern Maven plugin should look like" (that targets m-dependency-p goals, > sans analyze and some others) could look like: > https://github.com/maveniverse/toolbox > > The "unpack" related goals are missing, not yet done, but there are already > 33 Mojos in there. Most Mojos that are "gav-" prefixed are totally same as > CLI commands, and they do NOT require Project, are meant to be "ad hoc" > invoked. > The non-"gav-"-prefixed mojos use MavenProject instead to "contextualize" > themselves (so they work with the Project, and the "plugin-" prefixed ones > with Project defined plugins). > > Note1: not yet released (is not on Central), if you want to test drive it, > build it locally). > Note2: the "toolbox" is Maven Plugin and a CLI at the same time (the CLI > uber is toolbox-1.0.0-SNAPSHOT-cli.jar) > Note3: some of the missing goals mentioned on this thread are implemented > > Thanks > T >
Re: [DISCUSS] Maven Dependency Plugin
I do have an example at hand, though I am not sure I would advocate for it: https://blog.frankel.ch/faster-maven-builds/2/ There are undoubtedly better ways to achieve the author's goals, but I'm not sure that's the fault of dependency:go-offline. On Thu, Mar 21, 2024 at 3:19 PM Tamás Cservenák wrote: > Greg, > > would like to see such a project, do you have any examples at hand? > Am sure there are much simpler/better/more correct ways to do the same > thing. > > T > > On Thu, Mar 21, 2024 at 9:15 PM Greg Chabala > wrote: > > > My understanding is dependency:go-offline is an effective way to > > pre-download plugins and dependencies, for instance if one is making some > > layer in a docker build container for later reuse. > > > > On Thu, Mar 21, 2024 at 2:54 PM Tamás Cservenák > > wrote: > > > > > Howdy, > > > > > > What is the use case of "go offline"? > > > That is yet another goal coming from "Maven2 era" and messes up your > > local > > > repository (wrt back tracing dependencies, > > > https://issues.apache.org/jira/browse/MNG-7619) > > > I mean, if you do a build (w/o tests, or skipping most time stealing > > > steps), like "dry build", why is that not an option? > > > > > > T > > > > > > > > > On Thu, Mar 21, 2024 at 8:45 PM Scott Kurz > wrote: > > > > > > > +1 to this list from Slawomir: > > > > > > > > - dependency:analyze / dependency:analyze-only > > > > - dependency:copy > > > > - dependency:copy-dependencies > > > > - dependency:go-offline > > > > - dependency:list > > > > - dependency:tree > > > > - dependency:unpack > > > > - dependency:unpack-dependencies > > > > > > > > On Thu, Mar 21, 2024 at 2:56 PM Slawomir Jaranowski < > > > > s.jaranow...@gmail.com> > > > > wrote: > > > > > > > > > Hi > > > > > I use: > > > > > > > > > > - dependency:analyze / dependency:analyze-only > > > > > - dependency:copy > > > > > - dependency:copy-dependencies > > > > > - dependency:go-offline > > > > > - dependency:list > > > > > - dependency:tree > > > > > - dependency:unpack > > > > > - dependency:unpack-dependencies > > > > > > > > > > > > > > > > > > > > czw., 21 mar 2024 o 17:06 Tamás Cservenák > > > > > napisał(a): > > > > > > > > > > > Howdy, > > > > > > > > > > > > I'd would be interested in how users and devs are using > > > > > > maven-dependency-plugin: > > > > > > https://maven.apache.org/plugins/maven-dependency-plugin/ > > > > > > > > > > > > I collected some basic questions I'd like to have answered (but > > feel > > > > free > > > > > > to add more info!): > > > > > > - which goals are "must have" for you > > > > > > - which goals are "I never touched" for you (or, "I really don't > > > need" > > > > or > > > > > > "never used" or "shrug") > > > > > > - what is missing? > > > > > > > > > > > > Thanks > > > > > > T > > > > > > > > > > > > > > > > > > > > > -- > > > > > Sławomir Jaranowski > > > > > > > > > > > > > > >
Re: [DISCUSS] Maven Dependency Plugin
My understanding is dependency:go-offline is an effective way to pre-download plugins and dependencies, for instance if one is making some layer in a docker build container for later reuse. On Thu, Mar 21, 2024 at 2:54 PM Tamás Cservenák wrote: > Howdy, > > What is the use case of "go offline"? > That is yet another goal coming from "Maven2 era" and messes up your local > repository (wrt back tracing dependencies, > https://issues.apache.org/jira/browse/MNG-7619) > I mean, if you do a build (w/o tests, or skipping most time stealing > steps), like "dry build", why is that not an option? > > T > > > On Thu, Mar 21, 2024 at 8:45 PM Scott Kurz wrote: > > > +1 to this list from Slawomir: > > > > - dependency:analyze / dependency:analyze-only > > - dependency:copy > > - dependency:copy-dependencies > > - dependency:go-offline > > - dependency:list > > - dependency:tree > > - dependency:unpack > > - dependency:unpack-dependencies > > > > On Thu, Mar 21, 2024 at 2:56 PM Slawomir Jaranowski < > > s.jaranow...@gmail.com> > > wrote: > > > > > Hi > > > I use: > > > > > > - dependency:analyze / dependency:analyze-only > > > - dependency:copy > > > - dependency:copy-dependencies > > > - dependency:go-offline > > > - dependency:list > > > - dependency:tree > > > - dependency:unpack > > > - dependency:unpack-dependencies > > > > > > > > > > > > czw., 21 mar 2024 o 17:06 Tamás Cservenák > > > napisał(a): > > > > > > > Howdy, > > > > > > > > I'd would be interested in how users and devs are using > > > > maven-dependency-plugin: > > > > https://maven.apache.org/plugins/maven-dependency-plugin/ > > > > > > > > I collected some basic questions I'd like to have answered (but feel > > free > > > > to add more info!): > > > > - which goals are "must have" for you > > > > - which goals are "I never touched" for you (or, "I really don't > need" > > or > > > > "never used" or "shrug") > > > > - what is missing? > > > > > > > > Thanks > > > > T > > > > > > > > > > > > > -- > > > Sławomir Jaranowski > > > > > >
Re: problem resolving LATEST dependency in the local repo
> I recommend using a bot like Dependabot or Renovate to keep dependencies up-to-date. This seems a strange recommendation for an Ant user.
Re: How to suppress meta tags 'generator', 'date' in Doxia Site Renderer?
I would also like a solution to this, but am no closer to solving it. The noise from these date and version comments in the diffs make finding real changes too difficult.
Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures
My two cents: a very large monobuild with 100s of modules These are the kinds of problems you find when you're abusing the multi-module system. Multi-module builds are a last resort for me, when there are couplings between artifacts that need to be released simultaneously, e.g. API and implementation artifacts. Do you have 100 artifacts that all depend on each other and need simultaneous release? That sounds like a tightly coupled mess. Keep your builds in independent projects instead of modules and avoid these issues.
Re: Configuring canonical URL link elements for maven-site-plugin generated pages
Only for the Fluido skin, eh? In the meantime I've hacked together a beanshell monstrosity to add the tag to any pages that are missing it, which may end up becoming the basis for a custom plugin.
Re: Browsing Maven central buggy?
Repository readme says runtime is Java 8+, but: $ jbang mima@maveniverse Error: A JNI error has occurred, please check your installation and try again Exception in thread "main" java.lang.UnsupportedClassVersionError: eu/maveniverse/maven/mima/cli/Main has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0 On Wed, Jan 24, 2024 at 12:10 PM Tamás Cservenák wrote: > Basically, all you need is JBang installed, and then > > $ jbang mima@maveniverse > > will figure out what it is, download and launch the CLI for you. In CLI use > `help` to get around. > > Without Jbang you need to download latest CLI uberJAR that is here: > > https://repo.maven.apache.org/maven2/eu/maveniverse/maven/mima/cli/2.4.6/cli-2.4.6-uber.jar > > And then just > $ java -jar cli-2.4.6-uber.jar > > And same thing as above with JBang... > > Thanks > T > > On Wed, Jan 24, 2024 at 6:36 PM Manfred Moser > wrote: > > > Well.. you cant really just show this video without pointing to more > > help. So to get started ... > > > > https://github.com/maveniverse/mima > > > > used with > > > > https://www.jbang.dev/ > > > > Any other tips Tamas? > > > > Manfred > > > > > > On 2024-01-24 09:22, Tamás Cservenák wrote: > > > Or something like this: > > > https://asciinema.org/a/0dLOAfWxyxTg6zgcYSDX6FQwm > > > > > > ;) > > > > > > T > > > > > > On Wed, Jan 24, 2024 at 6:13 PM Manfred Moser > > > > wrote: > > > > > >> I suggest to use the maintained search and browse frontend from > Sonatype > > >> instead. > > >> > > >> https://search.maven.org/ .. same as https://central.sonatype.com/ > > >> > > >> And browse at https://central.sonatype.com/search > > >> > > >> It sits on top of the same data and is very nice indeed .. props to > > >> Brian Fox and team btw! > > >> > > >> Manfred > > >> > > >> On 2024-01-24 08:57, Tamás Cservenák wrote: > > >>> Howdy, > > >>> > > >>> Yes, this is a known problem, but it does not affect Maven, as it > does > > >> not > > >>> "browse". > > >>> Basically you have to go directly to the directory you are looking > for, > > >> and > > >>> not rely on HTML "index page" as that seems not maintained since a > > while. > > >>> > > >>> T > > >>> > > >>> On Wed, Jan 24, 2024 at 5:50 PM Thorsten Heit > > >> wrote: > > Hi, > > > > browsing Maven Central using a webbrowser seems, well, a bit buggy: > > > > In > https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-bom/ > > for example I only see versions 2.x up to 2.22.0 and 3.0.0-alpha1 > > whereas 2.22.1 and 3.0.0-beta1 both exist; they are simply not > > visible. > > > > The same happens for a few other GAV coordinates such as > > https://repo1.maven.org/maven2/org/apache/tika/tika-bom/3.0.0-BETA/ > > or > > > > > > >> > > > https://repo1.maven.org/maven2/me/qoomon/maven-git-versioning-extension/9.7.0 > > : > > The directories exist, but one level above these versions are not > > shown. > > > > Is this a known problem? > > > > > > Thorsten > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > >> - > > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > >> For additional commands, e-mail: users-h...@maven.apache.org > > >> > > >> > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > >
Configuring canonical URL link elements for maven-site-plugin generated pages
I'm trying to improve the search engine optimization of my project's maven-site-plugin generated website by following some best practices. I'm already using sitemapxml-maven-plugin to produce a sitemap for search engines. I'd like to configure a canonical URL link element for each page as well, but I don't see any hint of such a thing existing in the documentation. I know it's relatively easy to insert arbitrary elements in the header of ALL pages, like analytics code, but it seems like adding a unique element to the header of every page is more challenging, and might need to be supported directly by the generator. Is anyone doing this sort of thing? Short of making code changes to maven-site-plugin and possibly every plugin that generates reports, I think I might need to insert the canonical URL link elements by parsing the generated HTML after the fact. Greg Chabala
Re: Fatal error compiling: basedir .../target/generated-sources/annotations does not exist
Hello Sławomir, Do you know if MCOMPILER-379 is the same issue as MCOMPILER-567 ? If so, shouldn't the IT test in MCOMPILER-379 have caught it? Greg
Re: Who is maintaining the ASF GitHub bot for Jira?
This is an Apache Infra project, not really Maven: https://infra.apache.org/asfbot.html On Sun, Dec 17, 2023 at 7:27 PM Alexander Kriegisch < alexan...@kriegisch.name> wrote: > Whenever somebody comments on a GitHub PR linked to a Jira issue, the > initial version of the comment is copied over to Jira. But if the comments > are later edited or deleted, the initially created comment in Jira is not > being updated accordingly. This can lead to significant divergence, > bordering on falsification, in Jira issues. E.g. look at my (kriegaex) > comments in https://issues.apache.org/jira/browse/SUREFIRE-1934 and > compare with the heavily edited and restructured comments in > https://github.com/apache/maven-surefire/pull/670. > > Who maintains the bot, and how can I raise this issue there? I searched > for projects in the Apache GitHub organisations, but the bot does not seem > to be a public Apache project. Is it a generic component, despite the name > "ASF bot" implying otherwise? Anyway, Jira comments are editable, so this > is a useful feature that could be implemented. > -- > Alexander Kriegisch > https://scrum-master.de > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Generate soft-links as part of site build
As it happens, I have also been working on making site redirects for pages that have moved. I found placing a plain html file in src/site/resources/ works fine as one would expect. They are not soft links though, just basic HTML with meta refresh redirects and javascript redirects as a fallback. I should try soft links, but I'm not sure my host (GitHub Pages) would honor them. My next thought was that making a redirect file for every page that needs redirecting is a lot of noise and duplication in the repo, and perhaps there's a better way to generate them, e.g. a single template that could be reused for multiple redirect pages. It may be getting close to needing a custom plugin. On Tue, Nov 28, 2023 at 11:36 AM sebb wrote: > Is it possible to generate soft-links as part of a site build? > > I tried adding them to the resources/ folder, but they were ignored. > > Sebb > P.S. No, I cannot use redirects; there needs to be a physical file at > that site location > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Can the jar plugin respect .gitignore?
I hesitate to bring it up, but this seems as good a time as any. You've mentioned several times your intent to massage the Xalan Maven build to produce artifacts at parity with the existing Ant build, and not just the contents of artifacts but also where they end up in the directory structure, for the convenience of those who are used to the Ant build. I foresee that if you are truly successful in this goal, you will have thoroughly reimplemented a procedural Ant build, and created a very weird Maven build, to the point where you may exclaim 'why did I even start this? It took so much work to get Maven to do what I was doing easily in Ant!', and Maven users will be confused about why there's nothing they expected in the target directory after running compile. There's something to be said for embracing the Maven Way [1], and if you want to keep both builds in sync for a time, perhaps the effort would be better spent in updating the Ant build to put things in the places Maven puts them by default. [1]: https://maven.apache.org/background/philosophy-of-maven.html
Re: Can the jar plugin respect .gitignore?
I have no first hand experience using it, and only know of its existence as it's mentioned at the bottom the Reproducible Builds docs: https://reproducible-builds.org/docs/jvm/ Notably the maven-assembly-plugin documentation mentions a predefined 'project' descriptor which may also do just what you want(for buildable sources): https://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html#project You should be able to configure outputDirectory for either to place the assembly where you like: https://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#outputDirectory Didn't see a binary equivalent, but perhaps that would just be your normal build artifact?
Re: Can the jar plugin respect .gitignore?
> > I was thinking specifically about source assembly, where a good initial > approximation is to include the same files checked into git. > Use the sourceReleaseAssemblyDescriptor of maven-assembly-plugin: https://maven.apache.org/apache-resource-bundles/source-release/
Re: Keeping java's version in sync with project's version
I'll just mention that I've used the file referenced in the StackOverflow
question, META-INF/maven/${groupId}/${artifactId}/pom.properties, before to
do something much like you describe, print my application version to the
log at startup.
It did not need any special configuration to appear, and only took a
handful of lines to getResourceAsStream(), load into a Properties object,
and ask pomProperties.getProperty("version","development"). 'development'
is a safety default here for when the project is running in a context
before being packaged, like testing.
Now, how does pom.properties get populated? Will it always be populated?
Will this still work in a Java 9+/JPMS/Maven 4+ world? Unspecified,
exercise for the reader.
Re: Re: Version Management in 'mvn dependency:tree'
On Tue, Oct 31, 2023 at 10:27 PM yukai zhao wrote: > has the project actually introduced the org.apache.commons:commons-lang3 > with version 3.12.0 during the actual compilation process? > Well, no. It says 3.12.0 was omitted, due to being a duplicate, hence why it was not even mentioned without turning on verbose output. This is basically the core purpose of Maven, choosing what version of an artifact to include in the classpath.
Re: Version Management in 'mvn dependency:tree'
On Tue, Oct 31, 2023 at 11:27 AM wrote: > Can't quite make sense of all this; given that you got no replies, maybe > no one else understood either. I second this sentiment. All I could tell is it seems like there's some confusion about interpreting the dependency:tree output, and perhaps confusion on how dependency convergence works, or how a project should specify dependency versions. See https://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html for an overview.
Re: Feedback sought
On Sat, Oct 14, 2023 at 9:15 PM Joseph Kesselman wrote: > Taking out the META-INF: I'll look at that. ... quibbles like editor > configurations and unnecessary files can be cleaned up in subsequent edits; > they shouldn't be considered blockers now. > Sure. Just an opportunity to remove files and thereby reduce the size of the changeset. They may mostly be relocations, but GitHub's UI still struggles under the weight of 1400 changes in a single PR.
Re: Feedback sought
That's certainly an ambitious changeset, but it takes courage to do great work. I'd generally suggest trying to make smaller steps so it's easier on reviewers. For instance: - Could you make a basic Maven build that delegated most of the work to Ant with maven-antrun-plugin? - If so, then you could have separate follow up steps for moving code into the standard Maven layout, and converting from libraries in source to Maven retrieved versions. - Could you convert a smaller artifact first, like the samples directory? As far as specific advice on your current PR: - I'd recommend taking this opportunity to remove IDE droppings from source control entirely. .classpath, .project, .settings/* are all Eclipse specific and will be regenerated when the project is imported, if needed. They are needless noise in source control and IntelliJ IDEA users don't care about them at all. - Everything in META-INF will be generated by Maven, so none of that should be in source control either.
Re: maven-polyglot
That is a good example of the tradeoffs as well. In several places the pom.rb is forced to generate a pom.xml to satisfy other tooling, as mentioned here: https://github.com/jruby/jruby/blob/047188902e8d1d307d1f9e51d1bdc60ec1d09bc9/BUILDING.md#hacking-the-build-system On Mon, Oct 9, 2023 at 4:49 PM Tamás Cservenák wrote: > Howdy, > > I am aware for example the JRuby uses polyglot: > https://github.com/jruby/jruby > > AFAIK, not all languages are "same done" or maybe I may risk "same > quality", for example JRuby/pom.rb is nicely maintained, unsure for other > ones... > > Thanks > T > > > > On Mon, Oct 9, 2023 at 11:35 PM Greg Chabala > wrote: > > > I have looked into maven-polyglot before, and come to the conclusion that > > it is a proof of concept, and something that few if any people actually > > use, because: > > > >1. Professional programmers are not actually offended by using XML in > >the POM, only novices would complain about such a thing. > >2. All tooling will expect a pom.xml, e.g. IDEs, CI tools, linters, > etc. > >If any of those things are able to handle a polyglot POM in non-XML, > > that's > >a tiny miracle. > >3. maven-polyglot gets mentioned when people complain about Maven > using > >XML, as 'look, you don't have to, you can use whatever you want' but > no > > one > >actually does. > >4. The first suspect when something doesn't work right in your build > >will always be maven-polyglot, because no one uses it, so it's > >potentially not compatible with every plugin. Then you get to convert > > back > >to pom.xml and try again. So better to skip the effort and stay with > > XML in > >the first place. > > >
Re: maven-polyglot
I have looked into maven-polyglot before, and come to the conclusion that it is a proof of concept, and something that few if any people actually use, because: 1. Professional programmers are not actually offended by using XML in the POM, only novices would complain about such a thing. 2. All tooling will expect a pom.xml, e.g. IDEs, CI tools, linters, etc. If any of those things are able to handle a polyglot POM in non-XML, that's a tiny miracle. 3. maven-polyglot gets mentioned when people complain about Maven using XML, as 'look, you don't have to, you can use whatever you want' but no one actually does. 4. The first suspect when something doesn't work right in your build will always be maven-polyglot, because no one uses it, so it's potentially not compatible with every plugin. Then you get to convert back to pom.xml and try again. So better to skip the effort and stay with XML in the first place.
Re: question on maven dependency scope
> there will be a common core but i will provide premium > features as addons. ... what is the best way to achieve my goal? I would suggest using compile or runtime as the scope, depending on how you implement the addons, but mark them as optional dependencies.
Re: Multi-module Maven projects and Scala-aware artifact IDs
Sure, individual projects have done things as they saw fit. Guava has -jre and -android flavors on their artifact ID instead of using classifiers. Bouncycastle is using ant for their build process. I wouldn't want to emulate either as best practice. Scala, as an ecosystem, has decided on "_binaryVersion" appended to artifact ID, which feels gross. The Maven POM reference ( https://maven.apache.org/pom.html ) is pretty clear: "The classifier distinguishes artifacts that were built from the same POM but differ in content. It is some optional and arbitrary string that - if present - is appended to the artifact name just after the version number. As a motivation for this element, consider for example a project that offers an artifact targeting Java 11 but at the same time also an artifact that still supports Java 1.8." Binary compatibility versions are noise that should be in the classifier, if you're building from the same source tree, it only needs one artifact ID.
Re: Multi-module Maven projects and Scala-aware artifact IDs
> > Has anyone faced this before? > Yes. The fact that Scala's binary incompatibility leaked into artifact IDs rather than being a classifier irritates me still. I have no good solution for you. The mess that would have come from using Maven for cross version Scala builds led me to follow the status quo of using sbt for Scala projects. The question you linked is a good summary of the compromises. My belief is that if sbt didn't exist the Scala community would have been more motivated to improve this, with different artifact naming conventions and/or improvements to Maven. Greg
Re: MavenCLI failing in Jenkins
Javier, you should take this up with the docker image maintainer: Where to file issues: > https://github.com/carlossg/docker-maven/issues >
Re: [External] : Re: NPE Exception with Surefire3.0.0
While this may have been a rookie mistake and this pom is nonsensical, they did manage to cause an NPE in a standard plugin. That's a bug worth tracking down, right? Better validation, better error messages?
Re: What could cause a missing JAR in WEB-INF?
> > Are you saying that Maven dependency resolving is not deterministic? > I expect the resolution to be deterministic. But from all that has been shared here so far, it looks like something non-deterministic is happening, or perhaps more accurately, it is deterministic per machine, but varies due some unknown property outside the pom. It might even be a bug. I would encourage Thad to see if he can make a project that reproduces the issue that he could share.
Re: What could cause a missing JAR in WEB-INF?
It's no surprise that Xerces is involved here. Some colorful background: https://stackoverflow.com/questions/11677572/dealing-with-xerces-hell-in-java-maven The crux is clearly that xml-apis is a transitive dependency in two places, and depending on which is elected vs evicted, it will be compile or provided scope, and therefore in the WAR or not. This case might be of interest to the reproducible builds folks, since I would have thought it was deterministic, but it seems like your pom as written currently is letting it waffle. In any case, you should be able to force the behavior to be stable by declaring a direct dependency on xml-apis. Whether it should be compile or provided scope, or if you prefer to exclude it entirely instead, will take some more work. Looking at GWT, it seems like gwt-dev is provided because it's intended for compile only, and runtime requirements are in the gwt-servlet artifact, which I presume is also declared in your pom. I suspect Xerces and xml-api, as well as htmlunit, are never needed by GWT at runtime, or are provided by other artifacts or the application server. Looking at com.megginson.sax:xml-writer, it appears to really depend on xml-api, although it is an older version. If your application still works without xml-api present, exclusion might be the best option.
Re: What could cause a missing JAR in WEB-INF?
> I have *war that I've built on 3 different Macs (maven-war-plugin 3.3.2). > Is there a reason you're rebuilding your WAR three times on different Macs? > The code is pulled from my local git repo, and the supporting jars are from > a local Nexus repository. Are they all building from the same git branch/ref? Everything is pulled current? > The missing JAR is in each local repository. I do not see this JAR when I > run `mvn dependency:tree`, though I see a different (newer) version as > "provided." Provided means you are in charge of supplying the JAR, not Maven. Typically this means you expect the JAR will already be available at runtime, e.g. in your application server's provided JARs, so there's no point in bundling it into your WAR. Are you certain this is not just a case of having different application server versions installed, or someone manually updated the provided JARs on one of them? > The missing JAR doesn't seem to matter when the webapp runs (no > problems found so far). Any idea as to why, and > what I can (or should?) do for a consistent build? Make sure you're not using version ranges, and that all versions are specified. For more tips, see: https://maven.apache.org/guides/mini/guide-reproducible-builds.html This is all hypothetical, you didn't show/reference a concrete example pom we could look at.
Re: [m-deploy-plugin] Deploy javadoc archive only
Am I correct in my reading, that they found a similar use case for why installing/deploying without a main artifact was allowed, and thus why a test was guarding that behavior, but then decided it wasn't 'the Maven Way' enough and ripped it out? That makes it seem like a dummy jar is the only solution to Bernhard's problem (or hanging back on an older version of the deploy plugin). On Wed, Feb 22, 2023 at 12:43 PM Tamás Cservenák wrote: > Found this thread discussing this very change, may be helpful: > https://markmail.org/message/cmu5rh6i4cbmkh6e > > HTH > Tamas > > On Wed, Feb 22, 2023 at 7:27 PM Tamás Cservenák > wrote: > > > Howdy, > > > > Not directly helpful, but this change was introduced in early 3.0.0-M1: > > https://issues.apache.org/jira/browse/MDEPLOY-205 > > > > By reading the issue, I am really unsure about the exact intent. > > But, there is already a comment on issue (someone else having similar > > problem) > > > > Let's see if anyone else chimes in. > > > > HTH > > Tamas > > > > On Wed, Feb 22, 2023 at 7:20 PM Bernhard Schuhmann < > > bernhard.schuhm...@jedox.com> wrote: > > > >> Hello! > >> > >> > >> > >> I'm building a JavaDoc archive for a jar file with > >> > >> > >> > >> mvn javadoc:javadoc assembly:single deploy > >> > >> > >> > >> and maven-jar-plugin disabled so that only the JavaDoc archive gets > >> deployed. This has been working until updating to 3.9.0 > >> (maven-deploy-plugin 3.x) -because I only attach the JavaDoc archive I > now > >> get > >> > >> > >> > >> The packaging plugin for this project did not assign a main file to > the > >> project but it has attachments. Change packaging to 'pom'. > >> > >> > >> > >> However, when I change packaging to pom as suggested, > >> maven-javadoc-plugin no longer generates the Javadoc files that I want > to > >> assemble into the zip archive. > >> > >> > >> > >> Any help how to still do that in a single command? How can I deploy an > >> attachment without a main file assigned? > >> > >> > >> > >> Bernhard > >> > >> > >> > >> > >> < > https://www.jedox.com/en/resources/analyst-gartner-critical-capabilities/?utm_source=signature&utm_medium=email&utm_campaign=gartner_cc > > > >> > >> *Bernhard Schuhmann*** > >> > >> Senior Software Engineer > >> > >> *Jedox* > >> > >> Bismarckallee 7a > >> > >> 79098 > >> > >> Freiburg im Breisgau > >> > >> Germany > >> > >> Jedox GmbH > >> Chief Executive Officer (Geschäftsführer): Florian Winterstein > >> > >> Place of Business: Freiburg i. Br. | Registry Court: Amtsgericht > Freiburg | HRB 723467 > >> > >> > >> [TM.V06112018] > >> > >> > >> > > >
Re: MalformedInputException: Input length = 1
> > maven-resources-pluginable is not included in the > https://github.com/OpenAPITools/openapi-generator/blob/master/pom.xml or > our pom.xml and I have not been able to work out what calls it. If you have > any ideas please shout! > maven-resources-plugin is a standard plugin, it's part of the default lifecycle without being specified explicitly: https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html Calling process-resources or any phase after it will trigger the resources plugin, e.g. compile, test, package, verify. It's the first phase in the lifecycle, almost anything will trigger it.
Re: MalformedInputException: Input length = 1
> > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-resources-plugin:3.3.0:resources > (default-resources) on project ABC: filtering > ...\src\main\resources\v1\gradle\wrapper\gradle-wrapper.jar to > ...\target\classes\v1\gradle\wrapper\gradle-wrapper.jar failed with > MalformedInputException: Input length = 1 > > Any ideas are much appreciated!! > Maybe don't check JARs into your source code. On Fri, Jan 20, 2023 at 5:39 AM Delany wrote: > Hi Tom, > You can turn off filtering if you don't need it. The docs suggest having > separate folders for plaintext/binary resources > > https://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html >
Re: How to add a library to the classpath
Try searching for an example: https://github.com/search?l=Maven+POM&q=additionalClasspathElements&type=Code On Thu, Jan 5, 2023 at 7:11 PM Siddharth Jain wrote: > thanks. how do i separate multiple classpaths? tried : and , and none of > them work. > > On Thu, Jan 5, 2023 at 3:58 PM Laird Nelson wrote: > > > On Thu, Jan 5, 2023 at 3:20 PM Siddharth Jain > wrote: > > > > > I am using mvn exec:java to run a program. […] I want to add some more > > > libraries that I have > > > installed in M2 repository to the classpath at runtime and I do NOT > want > > to > > > list them in the project's pom.xml. How can I do this? I tried > searching > > > online but could not find an answer. > > > > > > > The documentation for the exec-maven-plugin's java goal contains this: > > > > > https://www.mojohaus.org/exec-maven-plugin/java-mojo.html#additionalClasspathElements > > >
Re: Maven build hanging -- how to collect diagnostics?
There's also https://issues.apache.org/jira/browse/MNG-2802 regarding concurrent access to the local repository. It looks resolved now, but I don't recall if one needs to set up a special locking mechanism to avoid issues. Concurrently installing artifacts in the local repo has historically been risky, the Windows file locking scheme might even exacerbate such issues.
Re: Re: Maven Deploy fails
On Thu, Nov 10, 2022 at 11:51 AM Raivo Rebane wrote: > What is the right command ? > Official guide: https://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html Some concrete examples: https://gist.github.com/chabala/9127256 As far as what you're doing though, installing javax.xml.bind.jar into your local repo is not a great way to get JAXB to work. You should have a dependency on the publicly available jaxb-api or jakarta.xml.bind-api artifact, and the matching impl. See https://stackoverflow.com/a/52502208/62462
Maven generated site validation tools
I'm a fan of the project websites generated by maven-site-plugin, but I've noticed over the years that there's a lot of moving pieces in the site generation phase. Sometimes upgrading a reporting plugin will produce unexpected site changes, or it may be the interaction of several plugins, etc. Noticing after you've published is annoying. What are folks using to validate their sites programmatically? Are there plugins that bind to post-site and perform tests? Perhaps they spin up the site in Jetty? The only plugin I'm aware of is linkcheck, which is useful but not a comprehensive site validation tool. Greg Chabala
Re: Parallel builds
If you always want to run the build and tests in parallel, you may find value in using maven.config / jvm.config in the project's .mvn directory to set those settings. https://maven.apache.org/configure.html On Fri, Sep 2, 2022 at 11:35 AM Slawomir Jaranowski wrote: > Hi Niels > > There are two different topics. > > First, how Maven builds a multi module project, sequentially or in > parallel. > This is configured by -T options for Maven command. > Even Maven builds modules in parallel, each task like compile, tests are > executed secentiali in each module - simply we can not run tests if we > first not compile code. > > Second topic is how tests are executed sequentially or in parallel, so even > if you build a project module by module you can execute tests in parallel > in each module. > > So there are separate configurations for both cases. > > > pt., 2 wrz 2022 o 14:29 Niels Basjes napisał(a): > > > Hi, > > > > When I want to build my project in parallel ( > > > > > https://cwiki.apache.org/confluence/display/MAVEN/Parallel+builds+in+Maven+3 > > ) I can simply do > > > > mvn -T 1C > > > > > > I found that the integration tests I have running within the > > maven-invoker-plugin > > are still being run sequentially. > > Turns out that this plugin has a similar feature to run in parallel: > > > > > > > > > https://maven.apache.org/plugins/maven-invoker-plugin/examples/parallel-projects-execution.html > > > > So right now I have put that flag into a property and when I want to > really > > run the build in parallel I now do: > > > > mvn -T1C -DparallelThreads=1C > > > > Is this the best way to do this? Or can these two settings be linked > > somehow? > > I.e. Can I provide the maven-invoker-plugin automatically the same value > as > > set on the -T setting? > > > > Or can I set this -T value within my pom.xml file? > > So that I can simply create a profile that contains these. > > > > -- > > Best regards / Met vriendelijke groeten, > > > > Niels Basjes > > > > > -- > Sławomir Jaranowski >
Re: Regarding error 980467
Looks like a Debian packaging issue. The Debian maintainer may or may not be in the Maven user list, but your issue would be better directed to them. I'm not an expert in tricky installations ... I'm scared to touch that by > hand. > You should not be afraid to install Maven directly from https://maven.apache.org/download.html , just untar it wherever you want and add it to the path https://maven.apache.org/install.html Relying on a linux distribution's packages for your development tools is a precarious situation. They will lag behind the current version. Installing them from the tool provider directly is safer. On Mon, Aug 15, 2022 at 4:22 PM F B wrote: > Dear maintainer(s), > > I've got exactly the same error as reported by Emmanuel Bourg: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980467 > > I'm running Linux Mint "5.4.0-122-generic #138-Ubuntu SMP" with Cinnamon > and Eclipse 2022-06, OpenJDK 17.0.4 and Maven 3.6.3 > > According to the comments, I wanted to update Maven by > sudo apt-get --only-upgrade install maven > but received: > >> Paketlisten werden gelesen... Fertig > Abhängigkeitsbaum wird aufgebaut. > Statusinformationen werden eingelesen Fertig > maven ist schon die neueste Version (3.6.3-1). > 0 aktualisiert, 0 neu installiert, 0 zu entfernen und 7 nicht > aktualisiert. << > > The import part is the second-last line: > maven is already newest version (3.6.3-1). > > I'm not an expert in tricky installations and I see links from > /usr/share/maven to /etc/maven and from /usr/bin to /etc/alternatives. I'm > scared to touch that by hand. > > That all said: Why does Mint not upgrade Maven to 3.8.6 ? Is there an easy > way to force that update? > > Kind regards and sorry for this newbie-questions > F. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Create Maven Archetype with special directory structure
Hello Hauke,
I have received your message three times now. I have not responded, hoping
someone else would have something constructive for you, but failing that,
you can have my take on it.
I think the structure you are trying to enforce is weird, and while I
applaud Maven for letting you do it, I would not want to work in a place
that wanted to make archetypes to template this on all projects. If this is
the 'Eclipse structure', gross.
Asking to omit the pom.xml is even weirder. I was unfamiliar with this
Eclipse Tycho pomless concept, and if it's working for them, fine. Omitting
the pom.xml to support it doesn't sound like useful work for Maven
developers.
Maybe your archetype can contain an ant task to delete the pom.xml and
empty directories you want to remove.
Greg Chabala
On Fri, Jul 15, 2022 at 12:53 AM Fuhrmann, Hauke <
fuhrmann.ha...@scheidt-bachmann-st.de> wrote:
> Hi there,
>
> my company is building Java projects with a customised folder structure
> not directly following the Maven standard directory structure
> ("src/main/java" and "src/test/java") but the Eclipse Java structure ("src"
> and "src-test").
>
> I try to create an archetype for our own projects following the archetype
> packaging: https://maven.apache.org/archetype/archetype-packaging/
>
> It works all fine except that maven always adds some main/java and
> test/java folders into my source folders.
>
> My archetype ressources are
>
> archetype-resources/
> ├─ META-INF/
> │ ├─ MANIFEST.MF
> ├─ OSGI-INF/
> ├─ src/
> │ ├─ Demo.java
> ├─ src-test/
> │ ├─ DemoTest.java
> ├─ .classpath
> ├─ .project
> ├─ build.properties
> ├─ pom.xml
>
> The archetype.metadata has this filesSets
>
>
>
> src
>
>
> src-test
>
>
>
> *
>
>
>
>
>
> The resulting directory structure is:
>
> archetype-resources/
> ├─ META-INF/
> │ ├─ MANIFEST.MF
> ├─ OSGI-INF/
> ├─ src/
> │ ├─ mypackage/
> │ │ ├─ Demo.java
> │ ├─ main/
> │ │ ├─ java/
> │ ├─ test/
> │ │ ├─ java/
> ├─ src-test/
> │ ├─ mypackage/
> │ │ ├─ DemoTest.java
> ├─ .classpath
> ├─ .project
> ├─ build.properties
> ├─ pom.xml
> So it's all fine except these empty main/java and test/java folders in the
> src folder. Any way how to change this?
> In plain maven I could add the sourceDirectory and unittestSourceDirectory
> to the build-section. But this cannot be set in the archetype.metadata file.
>
> Is there any way how to omit the pom.xml in the target project? Eclipse
> typcho maven plugin allows a pomless-build that does not require poms in
> the single projects.
>
> Cheers,
> Hauke
>
>
>
> Please see our data privacy policy:
> https://www.scheidt-bachmann.de/en/data-privacy/
> Important Notice: This E-Mail and any files attached are confidential and
> may contain privileged information.
> If you are not the intended recipient, do not forward or disclose this
> E-Mail, open any attachments, make any copies or save this E-Mail anywhere.
> Please delete this E-Mail from your system and notify the sender (as
> applicable also by phone +49 2166 266-0). Thank you very much.
>
> To send this email we must process the following personal data: Your email
> address, first name and surname.
> Your data is processed solely for the purpose of sending this email and
> passed on to third parties only for this purpose.
> You have been included in the circle of recipients for our emails due to
> your professional, social or political position. If this position changes,
> or you inform us that you do not want to receive emails from us, or you
> object to the further processing of your data, we will delete your data and
> no longer use it.
Re: How does Maven really treat "bundle" packaging type?
> > I'm considering uploading any dependencies I do need from JitPack > directly into my own Artifactory as a workaround, but that's crazy and > not long term maintainable. > I would counter that is actually the only appropriate action. Who is JitPack? Will it go away tomorrow? As near as I can tell, it's a one person operation based in the UK, not something a professional would base their build process around. Configuring your Artifactory as a caching proxy as Thomas suggests is the easy way to insulate yourself, but I'd recommend trying to avoid JitPack entirely. On Mon, Jun 20, 2022 at 3:27 PM Thomas Broyer wrote: > Le lun. 20 juin 2022 à 20:38, Pawel Veselov a > écrit : > > > TL;DR: > > > > Is there a way, and what is the correct one if there is, to prevent a > > package being downloaded from a particular repository (or lock it to > > being downloaded from a particular one, though I thought the answer to > > that one is "no")? > > > > Use a repository manager? > Have everything go through your repo manager (by declaring it as proxying > `*` in your settings.xml), and manage "filters" there to make sure you only > get from Jitpack what you expect to get from it (using Nexus, this is done > through "routing rules", I don't know with Artifactory). > That's the route we've taken to avoid a few supply chain attacks, including > dependency confusion like you're seeing here (even though it's probably not > an "attack") > > LR: > > > > Maven 3.8.6, JDK 1.8. > > > > I've run into this strange problem with > > com.github.jsonld-java:jsonld-java:0.13.4 > > The package includes fine as a dependency if it is downloaded from > > Maven Central: > > pom.xml: https://pastebin.com/qev5Udp2 > > Build output: https://pastebin.com/MzUVqWLt (pending moderation, LMK > > if you want me to attach that) > > > > The package fails to download as a dependency if it is downloaded from > > JitPack: > > pom.xml: https://pastebin.com/7L2rEWPz > > Build output: https://pastebin.com/U3StAtMZ > > > > AFAIU, there are two things that are "wrong" in this entire thing: > > a) Developer declared packaging as "bundle" (I'm not entirely sure > > that's wrong, but I don't see a reason for them to have done so, and > > it seems to be a contributing factor) > > b) JitPack/somebody republished the dependency as a virtual package > > that depends on itself, and broke this entirely. > > > > But what I don't understand is why the Maven's behavior is different > > in these two cases. > > > > NOT WORKING CASE: The package is found on JitPack, Maven is asked to > > get com.github.jsonld-java:jsonld-java:0.13.4 of type "bundle" by an > > explicit dependency statement. There is no such downloadable binary, > > so the entire process fails. > > > > WORKING CASE: The package is found on Central, Maven is asked to get > > com.github.jsonld-java:jsonld-java:0.13.4, without packaging > > specification. The packaging specification in the POM is "bundle". But > > Maven is satisfied with just downloading the JAR > > > > Few questions: > > - How come Maven is OK creating/uploading a package with "bundle" > > packaging, but without a "bundle" file? > > - How does Maven decide to download the .jar when the packaging says > > "bundle" in the POM, and is satisfied with that? > > > > This is done through "artifact handlers" (the 'type' from a 'dependency' is > technically unrelated to the 'packaging' from the POM). If your dependency > doesn't declare a 'type', then it defaults to 'jar' (the 'packaging' > selects a lifecycle that determines how to *build* that project, > irrespective of how to consume it) > > - Is there a way to find out who published a package on JitPack, to > > get them to fix it? The developer didn't do that, that was done > > without their consent and/or them being made aware of it > > > > Thank you. > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > >
RE: Determine Maven Dependencies after a build
Great link, thanks you so much From: Shipp, Scott Sent: Tuesday, April 19, 2022 8:55 AM To: Maven Users List Subject: Re: Determine Maven Dependencies after a build I also wanted to add that there is a reproducible builds guide at https://maven.apache.org/guides/mini/guide-reproducible-builds.html<https://maven.apache.org/guides/mini/guide-reproducible-builds.html> which also links to a wiki about the topic. There is a lot you can do to insure reproducible builds with Maven. From: Creager, Greg mailto:greg.crea...@hp.com.INVALID>> Date: Friday, April 15, 2022 at 8:10 AM To: Maven Users List mailto:users@maven.apache.org>> Subject: RE: Determine Maven Dependencies after a build External Email Is there a drawback to simply running resolve-ranges before official builds to ensure the pom has static versions? That seems like it would resolve having published poms with version ranges in production. mvn versions:resolve-ranges -DprocessParent=true From: Mark Derricutt mailto:m...@talios.com>> Sent: Wednesday, April 13, 2022 4:49 PM To: Maven Users List mailto:users@maven.apache.org>> Subject: Re: Determine Maven Dependencies after a build I don't believe there currently is a way for this is native maven. We ended up writing a custom tool/mojo for resolution management using a DSL like: repository https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.org%2Fmaven2%2F&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3XJIvZ9N5riGnqc0FZnFDU15c7gGODNp2AunJMNjx8g%3D&reserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.org%2Fmaven2%2F&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3XJIvZ9N5riGnqc0FZnFDU15c7gGODNp2AunJMNjx8g%3D&reserved=0><https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.org%2Fmaven2&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=ovkq%2BPgEPdZAULpXGSrFylbHql%2BmgCMydB8xidPMNn0%3D&reserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.org%2Fmaven2&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=ovkq%2BPgEPdZAULpXGSrFylbHql%2BmgCMydB8xidPMNn0%3D&reserved=0>><https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.org%2Fmaven2%2F&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3XJIvZ9N5riGnqc0FZnFDU15c7gGODNp2AunJMNjx8g%3D&reserved=0%3chttps://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.org%2Fmaven2&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=ovkq%2BPgEPdZAULpXGSrFylbHql%2BmgCMydB8xidPMNn0%3D&reserved=0%3e<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.org%2Fmaven2%2F&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3XJIvZ9N5riGnqc0FZnFDU15c7gGODNp2AunJMNjx8g%3D&reserved=0%3chttps://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.org%2Fmaven2&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=ovkq%2BPgEPdZAULpXGSrFylbHql%2BmgCMydB8xidPMNn0%3D&reserved=0%3e>> as central; resolve highest org.antlr:antlr4-maven-plugin:[4.10,5.0.0) via central; locked org.antlr:antlr4-maven-plugin:4.10; Which tracks the repositories to check, a range to resolve, and what was resolved/locked ( also tracking deprecated/blacklisted dependencies ). These pom.deps files get attached as artifacts and can be subsequently imported in downstream repos: repo
RE: Determine Maven Dependencies after a build
Is there a drawback to simply running resolve-ranges before official builds to ensure the pom has static versions? That seems like it would resolve having published poms with version ranges in production. mvn versions:resolve-ranges -DprocessParent=true From: Mark Derricutt Sent: Wednesday, April 13, 2022 4:49 PM To: Maven Users List Subject: Re: Determine Maven Dependencies after a build I don’t believe there currently is a way for this is native maven. We ended up writing a custom tool/mojo for resolution management using a DSL like: repository https://repo1.maven.org/maven2/<https://repo1.maven.org/maven2> as central; resolve highest org.antlr:antlr4-maven-plugin:[4.10,5.0.0) via central; locked org.antlr:antlr4-maven-plugin:4.10; Which tracks the repositories to check, a range to resolve, and what was resolved/locked ( also tracking deprecated/blacklisted dependencies ). These pom.deps files get attached as artifacts and can be subsequently imported in downstream repos: repository https://nexus.az1.smxk8s.net/repository/maven-public-group;<https://nexus.az1.smxk8s.net/repository/maven-public-group;> import groupId:artifact.bill-of-materials:3.3.150; locked org.antlr:antlr4-maven-plugin:4.10; From here, the actual pom.xml files are rewritten with [4.10] references - locking the build to a specific, locked range version ( for extra banality we also automatically add on * to prevent transitive dependencies. This definitely has problems, but also have benefits and certainly made hot fixes much easier to handle when we had different deployments staggered into production between customer sites. -- "Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree On 14/04/2022 at 6:25:47 AM, "Creager, Greg" mailto:greg.crea...@hp.com.invalid>> wrote: > I am trying to reproduce a build that was done a week ago. Our maven pom > files use range in many places ([1.0,1.1), when I go look at the pom of the > published project, it just shows the range, not the actual version chosen: > > Published pom: > > com.hp.cp.dfe.shared > common-types > [1.0,1.1) > > > > How do I determine exact versions of dependencies used in a prior build? > In Apache ivy the published ivy.xml shows the exact version chosen, I was > expecting maven to have the same and I am assuming I just am not using the > right util. >
RE: Determine Maven Dependencies after a build
Another question, if the published pom has a range: Published pom: com.hp.cp.dfe.shared common-types [1.0,1.1) Does that mean when another maven build that depends on this will select the latest available common-types in that range, not the one that was used for that build? (my hunch is yes, constant moving target) -Original Message- From: Nils Breunese Sent: Thursday, April 14, 2022 2:01 AM To: Maven Users List Subject: Re: Determine Maven Dependencies after a build Alexander Kriegisch wrote: > A personal note: I am trying to keep my hands off version ranges. I am > not sure the assumed flexibility is worth the trouble of using it and > running into the same issues as you. It also potentially creates a > huge matrix of possible dependency version combinations which might or > might not play nice with each other. How can you ensure to run your > tests on all of them? Sometimes, there is a bug which affects you in > 2.5.3, but not in 2.5.2, and quickly fixed in 2.5.4. Maybe you did or > did not notice that it even exists. Then suddenly, someone uses the > buggy version, and the software does not work despite green tests. I would indeed also recommend to not use version ranges, and using a tool like Dependabot or Renovate to keep your dependencies up-to-date. Nils. - 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 Dependencies after a build
Thanks for all the quick responses, greatly appreciate it. I’ll have to work with our architects and see if I can steer them away from this, build reproducibility is highest priority. Thanks again From: Mark Derricutt Sent: Wednesday, April 13, 2022 4:49 PM To: Maven Users List Subject: Re: Determine Maven Dependencies after a build I don’t believe there currently is a way for this is native maven. We ended up writing a custom tool/mojo for resolution management using a DSL like: repository https://repo1.maven.org/maven2/<https://repo1.maven.org/maven2> as central; resolve highest org.antlr:antlr4-maven-plugin:[4.10,5.0.0) via central; locked org.antlr:antlr4-maven-plugin:4.10; Which tracks the repositories to check, a range to resolve, and what was resolved/locked ( also tracking deprecated/blacklisted dependencies ). These pom.deps files get attached as artifacts and can be subsequently imported in downstream repos: repository https://nexus.az1.smxk8s.net/repository/maven-public-group;<https://nexus.az1.smxk8s.net/repository/maven-public-group;> import groupId:artifact.bill-of-materials:3.3.150; locked org.antlr:antlr4-maven-plugin:4.10; From here, the actual pom.xml files are rewritten with [4.10] references - locking the build to a specific, locked range version ( for extra banality we also automatically add on * to prevent transitive dependencies. This definitely has problems, but also have benefits and certainly made hot fixes much easier to handle when we had different deployments staggered into production between customer sites. -- "Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree On 14/04/2022 at 6:25:47 AM, "Creager, Greg" mailto:greg.crea...@hp.com.invalid>> wrote: > I am trying to reproduce a build that was done a week ago. Our maven pom > files use range in many places ([1.0,1.1), when I go look at the pom of the > published project, it just shows the range, not the actual version chosen: > > Published pom: > > com.hp.cp.dfe.shared > common-types > [1.0,1.1) > > > > How do I determine exact versions of dependencies used in a prior build? > In Apache ivy the published ivy.xml shows the exact version chosen, I was > expecting maven to have the same and I am assuming I just am not using the > right util. >
Determine Maven Dependencies after a build
I am trying to reproduce a build that was done a week ago. Our maven pom files use range in many places ([1.0,1.1), when I go look at the pom of the published project, it just shows the range, not the actual version chosen: Published pom: com.hp.cp.dfe.shared common-types [1.0,1.1) How do I determine exact versions of dependencies used in a prior build? In Apache ivy the published ivy.xml shows the exact version chosen, I was expecting maven to have the same and I am assuming I just am not using the right util.
Re: Plugin resolution error
> > The company does not use proxy for Maven or IntelliJ > You mean like this one? https://artifacts.horizon.bankofamerica.com/artifactory/plugins-release On Fri, Apr 8, 2022 at 12:48 AM Azin, Arian wrote: > > Hello, > > Getting this error when running mvn clean install: > > [ERROR] Failed to execute goal > com.github.spotbugs:spotbugs-maven-plugin:3.1.12:spotbugs (spotbugs) on > project gret-fo-algo-root: Execution spotbugs of goal > com.github.spotbugs:spotbugs-maven-plugin:3.1.12:spotbugs failed: Plugin > com.github.spotbugs:spotbugs-maven-plugin:3.1.12 or one of its dependencies > could not be resolved: Could not find artifact com.baml > .gretcore.gret_core:gret-core-build-tools:jar:2.105.0 in central ( > https://artifacts.horizon.bankofamerica.com/artifactory/plugins-release) > -> [Help 1] > [ERROR] > > > The company does not use proxy for Maven or IntelliJ. Other users do not > have this problem either. The versions used: > > java version "1.8.0_321" > Java(TM) SE Runtime Environment (build 1.8.0_321-b25) > Java HotSpot(TM) 64-Bit Server VM (build 25.321-b25, mixed mode) > > > Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; > 2018-10-24T14:41:47-04:00) > Maven home: C:\Program Files (x86)\Apache\Maven360\bin\.. > Java version: 1.8.0_321, vendor: Oracle Corporation, runtime: C:\Program > Files\Java\jdk8\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > > > IntelliJ IDEA 2021.3.3 (Community Edition) > Build #IC-213.7172.25, built on March 15, 2022 > Runtime version: 11.0.14.1+1-b1751.46 amd64 > VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o. > Windows 10 10.0 > GC: G1 Young Generation, G1 Old Generation > Memory: 2048M > Cores: 16 > > Kotlin: 213-1.5.10-release-949-IJ7172.25 > > -- > This message, and any attachments, is for the intended recipient(s) only, > may contain information that is privileged, confidential and/or proprietary > and subject to important terms and conditions available at > http://www.bankofamerica.com/emaildisclaimer. If you are not the > intended recipient, please delete this message. >
Re: [Pdf plugin] default fop configuration link broken
I don't know where it is now, but here it is as it was in 1.11.1: https://github.com/apache/maven-doxia/blob/doxia-1.11.1/doxia-modules/doxia-module-fo/src/main/resources/fo-styles.xslt On Wed, Feb 23, 2022 at 9:34 PM Woonsan Ko wrote: > Hi, > > While reading [1], I found the link broken: > - > https://github.com/apache/maven-doxia/blob/master/doxia-modules/doxia-module-fo/src/main/resources/fo-styles.xslt > > Does anyone know where to find it? > > Thanks, > > Woonsan > > [1] https://maven.apache.org/plugins/maven-pdf-plugin/usage.html > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Possible file separator bug in 3.10.0 using bnd-maven-plugin
Just my opinion, https://github.com/apache/maven-compiler-plugin/pull/88
feels like a hack solution.
Generating classes for package-info.java files, just to appease some issue
with the incremental compiler? That seems like it should have been filtered
in the compile plugin, not litter the build with classes that have no
function.
On Mon, Feb 14, 2022 at 10:56 AM Daniel B. Widdis wrote:
> I just bumped the maven-compiler-plugin version on my project from 3.9.0 to
> 3.10.0 and it caused Windows-based builds to fail maven-bnd-plugin tests
> for package-info files in the "wrong" directory. The symptom looks to be
> associated with the windows file separator.
>
> Sample failure looks like:
> [INFO] Compiling 386 source files to
> D:\a\oshi\oshi\oshi-core\target\classes
> [INFO]
> [INFO] --- bnd-maven-plugin:6.1.0:bnd-process (default) @ oshi-core ---
> Error: D:\a\oshi\oshi\oshi-core\pom.xml [0:0]: Classes found in the wrong
> directory:
>
> {oshi/jna/platform/unix/package-info.class=oshi\jna\platform\unix\package-info,
>
> oshi/driver/unix/solaris/disk/package-info.class=oshi\driver\unix\solaris\disk\package-info,
>
> oshi/hardware/platform/mac/package-info.class=oshi\hardware\platform\mac\package-info,
> oshi/software/os/package-info.class=oshi\software\os\package-info,
>
> oshi/software/os/linux/package-info.class=oshi\software\os\linux\package-info,
> ... (many more)
>
> While the failure is in another plugin, is it possible something in this PR
> didn't handle the change?
> [MCOMPILER-205] Add a boolean to generate missing package-info classes by
> default by gnodet · Pull Request #88 · apache/maven-compiler-plugin
> (github.com) <
> https://github.com/apache/maven-compiler-plugin/pull/88/files>
>
>
> I've looked over the code and don't see anything obvious there.
>
> I do have package-info files in all my packages so new ones should not have
> been generated, but it seems new ones may have.
>
> Full test run here: Bump maven-compiler-plugin from 3.9.0 to 3.10.0 ·
> oshi/oshi@471641b (github.com)
>
>
> --
> Dan Widdis
>
Re: request for documentation update about mirrors
I can't speak to your question about disabling the https requirement, though my guess is that will be impossible and/or unpopular, likely by design. If you could just turn it off, some people would just turn it off, which defeats the purpose. The root of my questions is that if your Nexus is configured properly, https shouldn't be an issue to begin with. You should get in touch with your Nexus admin, get familiar with the historical and/or bureaucratic reasons for what exists, and get one of them configured to meet your needs, e.g. serving over https, a group that contains the aggregate of all the repos your settings.xml is referencing. They are likely already familiar with the need for https access. On Wed, Dec 8, 2021 at 6:26 PM wrote: > Sorry for broken threading; I wasn't subscribed to the mailing list so I > never got your reply; not sure how to fix it now. Now I'm subscribed. > > Yes, we are using nexus. One of our nexus servers is even using HTTPS. > The rest are not. > As for why we have "many" ... I'm not entirely sure. It was like that > when I got here. > I could ask around, but I'm not sure how much it matters. Could be > > * Historical reasons > > * Bureaucratic reasons > > * Or maybe even very good reasons that I happen to not know. > As it happens, many of these "separate" nexus repositories are on the same > server, but maven treats them all as if they are distinct, because they > have different paths. E.g. one might be > http://nexus.example.com:8080/nexus/content/groups/main/ > while another might be > > http://nexus.example.com:8080/nexus/content/repositories/UPLOAD-EXTERNAL-RELEASES/ > > Not sure if any of this answers your question. > > > _ > “This message is for information purposes only, it is not a > recommendation, advice, offer or solicitation to buy or sell a product or > service nor an official confirmation of any transaction. It is directed at > persons who are professionals and is not intended for retail customer use. > Intended for recipient only. This message is subject to the terms at: > www.barclays.com/emaildisclaimer. > > For important disclosures, please see: > www.barclays.com/salesandtradingdisclaimer regarding market commentary > from Barclays Sales and/or Trading, who are active market participants; > https://www.investmentbank.barclays.com/disclosures/barclays-global-markets-disclosures.html > regarding our standard terms for the Investment Bank of Barclays where we > trade with you in principal-to-principal wholesale markets transactions; > and in respect of Barclays Research, including disclosures relating to > specific issuers, please see http://publicresearch.barclays.com.” > > _ > If you are incorporated or operating in Australia, please see > https://www.home.barclays/disclosures/importantapacdisclosures.html for > important disclosure. > > _ > How we use personal information see our privacy notice > https://www.investmentbank.barclays.com/disclosures/personalinformationuse.html > > _ >
Re: request for documentation update about mirrors
> > since we are using a settings.xml which lists many http-only repositories, > including one with an id of "central". > Since these are all on our internal network > We don't let maven access the public internet As your repositories are all internal, and you don't let maven connect to the public internet, what are you using to host internal repos? Nexus, Artifactory? Either should provide https out of the box. Also, why 'many' repositories? Your internal repository manager ought to cache, mirror and aggregate, and be the single repo you need to reference. Greg Chabala On Wed, Dec 8, 2021 at 11:39 AM wrote: > I hope this is the right mailing list; if I not, would appreciate a > redirect. > In the release notes for maven 3.8.1, here: > https://maven.apache.org/docs/3.8.1/release-notes.html > There is a helpfully titled section "How to fix when I get a HTTP > repository blocked?" > > https://maven.apache.org/docs/3.8.1/release-notes.html#how-to-fix-when-i-get-a-http-repository-blocked > It mentions 2 options: > > * Update to a newer version of the artifact you're fetching, which > is presumably available over https > > * Define a mirror in your settings, which links to this page: > https://maven.apache.org/guides/mini/guide-mirror-settings.html > > The first option is not helpful, since we are using a settings.xml which > lists many http-only repositories, including one with an id of "central". > Since these are all on our internal network, the usual concerns about > security don't apply, or at least not in full force like they would on the > public internet. > > (We don't let maven access the public internet. If a fellow coworker is > trying to hijack my maven downloads, I suppose they might succeed. We'll > keep taking that risk for now :)) > > That brings us to the second option: create a mirror. Unfortunately, the > linked page doesn't even mention anything about blocking and unblocking. > In fact, I can't find the tag documented anywhere, though > perhaps I'm looking in the wrong places. > > What I'd ideally like to see is a way to "undo" the mirror defined in the > global settings in one fell swoop. > That is, I do NOT want to go through the repos listed in our repositories, > and then tediously create a mirror for each of them, one by one, and then > remember to keep the two lists in sync if anything changes. > > So: can the documentation be updated to mention anything about unblocking, > and is there any way to do what I want? > > Thanks, > Mark. > > > _ > “This message is for information purposes only, it is not a > recommendation, advice, offer or solicitation to buy or sell a product or > service nor an official confirmation of any transaction. It is directed at > persons who are professionals and is not intended for retail customer use. > Intended for recipient only. This message is subject to the terms at: > www.barclays.com/emaildisclaimer. > > For important disclosures, please see: > www.barclays.com/salesandtradingdisclaimer regarding market commentary > from Barclays Sales and/or Trading, who are active market participants; > https://www.investmentbank.barclays.com/disclosures/barclays-global-markets-disclosures.html > regarding our standard terms for the Investment Bank of Barclays where we > trade with you in principal-to-principal wholesale markets transactions; > and in respect of Barclays Research, including disclosures relating to > specific issuers, please see http://publicresearch.barclays.com.” > > _ > If you are incorporated or operating in Australia, please see > https://www.home.barclays/disclosures/importantapacdisclosures.html for > important disclosure. > > _ > How we use personal information see our privacy notice > https://www.investmentbank.barclays.com/disclosures/personalinformationuse.html > > _ >
Re: Alter configuration of another mojo
This might be a better question for the dev list. Thank you for your effort regardless. I would hate to see this become an example of 'Maven is harder than Gradle'. On Thu, Sep 23, 2021 at 3:55 AM Cédric Champeau wrote: > Hi folks, > > I'm the maintainer of the GraalVM native build tools plugins for Maven and > Gradle. In the next release, we're moving to JUnit Platform 5.8, which now > integrates a "unique test id tracker", which before used to be implemented > in this plugin suite. > > The goal of this ID tracker is to collect _unique_ test IDs for every test, > so that we can build a native image which would execute the same tests in > native mode. In other words, we first execute the tests in "JVM" mode, > using the surefire plugin, then there's a native image being built which > includes the tests and uses the information from the JVM execution to tell > which tests to execute in the native mode (that's because traditional test > discovery mechanisms don't work in a native executable). > > Before JUnit 5.8, the listener which collects test ids used to live in the > "junit-platform-native" dependency, and because it did so, the sole fact of > adding this dependency was enough to trigger the listener. That was a > temporary solution until JUnit actually *bundles* this listener, and that's > where things get more complicated. > > Starting with the 5.8 release, the listener is embedded into JUnit. This > means we can remove it from the "junit-platform-native" dependency [1]. > However, it also means that there must be a way to opt-in, because most > users don't need this listener active. Therefore, JUnit requires the > "junit.platform.listeners.uid.tracking.enabled" system property to be set. > > This means, in practice, that IF the native maven plugin is applied, THEN > the surefire mojo needs to be configured to set this property. It's an > implementation detail that users shouldn't have to worry about. For Gradle > this was trivial to implement because we can just react to the presence of > the native plugin and reconfigure the test task to add this system > property. For Maven, this proves quite challenging. > > Currently, the only way I found is to have the user explicitly add this > system property to the surefire mojo: > > > org.apache.maven.plugins > maven-surefire-plugin > 3.0.0-M5 > > > > true > > > > > > This is certainly not nice, because as I said, the user shouldn't care: > because we apply the native plugin, we *know* that we need that listener. > Therefore I'm looking for ways to automatically alter the configuration of > the surefire plugin if the native plugin is applied. More importantly, this > is a breaking change since upgrading the plugin now requires a redundant > system property to be set. > > I found that I could do this in the following situations: > > - if my mojo runs _before_ the tests: this is not possible, since I need > the results of the test execution to get the list of tests > - using a lifecycle extension: it seems doable, but then I'm replacing one > problem with another: the user has to register the extension, either by > updating the POM file or adding it to their extensions. This, again, is a > no-go since we want this to be transparent. > > Last but not least, I'm not mentioning that there's a 2d property which > would ideally need to be set too, which is the directory where those test > ids are dumped. By default it uses the target directory today, but this is > causing reliability issues, unless users do clean on every run. So it would > be great to be able to configure a *unique* directory per session. One > problem at a time, though. > > All in all, is there any other way to do what I need that I'm missing? > > Thanks for your help, > > [1] https://github.com/graalvm/native-build-tools/issues/131 >
Re: Question on installing Maven from Red Hat (RHEL8), missing .m2 directory for users
The .m2 directory will be created automatically on first use, as I recall. A non-trivial command that pulls some artifacts should be enough. You would only be concerned with creating it yourself if you need to set up specific values in settings.xml, which is your responsibility to create if needed. The bigger concern is that your Red Hat package is so old. https://maven.apache.org/docs/history.html The first time you have an issue that requires technical help, people will ask you to try the current version. If you're going through the effort of making an Ansible Playbook, you might as well install the current version from a tarball. Also, as Maven falls under the umbrella of 'developer tools', one would usually encourage developers to install their own tooling as needed. I would be displeased if my workplace wanted to standardize on a three year old version of Maven and script its installation for me. On Wed, Aug 18, 2021 at 10:44 AM christopher.mil...@gd-ms.com < christopher.mil...@gd-ms.com> wrote: > > > Hi, this is on RHEL8, trying to standardized on how we install Maven where > I work, so it's the same for each user. Make it easy for setup and > troubleshoot. > > From a RHEL8 workstation, I'm running the following command, as we have a > repository to pull from: > > > dnf install maven -y > > > DNF pulls in all dependencies and installs successfully (we are sticking > with Red Hat packages as to keep things as simple as possible), as I can > confirm this with the following: > > > [user_a@rhel8-maven3 bin]$ mvn --version > Apache Maven 3.5.4 (Red Hat 3.5.4-5) > Maven home: /usr/share/maven > Java version: 1.8.0_282, vendor: Red Hat, Inc., runtime: > /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.282.b08-4.el8.x86_64/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "4.18.0-305.el8.x86_64", arch: "amd64", family: > "unix" > [user_a@rhel8-maven3 bin]$ > > > However it didn't create a .m2 directory for any of the users. Will this > have to be created manually? Along with creating the settings.xml file? I > didn't see anything in the documentation on how to create .m2. > > Our end goal is to create an Ansible Playbook to automate this install as > well and want to have the correct steps. > > Thanks > > >
Re: Unable to resolve artifact error when trying to transfer ISO using pom.xml
Ah, I missed your inline question about plugin versions. In general they are independent of the maven version, and you should feel free to upgrade to the latest version for any plugin. https://maven.apache.org/plugins/maven-dependency-plugin/ is at 3.2.0. https://www.mojohaus.org/versions-maven-plugin/ has a display-plugin-updates goal, along with other similar goals that can help you check if your project plugins are up to date. On Tue, Aug 3, 2021 at 2:09 PM Greg Chabala wrote: > For reference: https://maven.apache.org/pom.html > > You want your Nexus configured in the top level repositories tag, not > in distributionManagement. > > On Tue, Aug 3, 2021 at 2:00 PM christopher.mil...@gd-ms.com < > christopher.mil...@gd-ms.com> wrote: > >> >> Sorry, I forgot to include the Nexus repo in the pom.xml >> >> >> >> false >> ID_GOES_HERE >> ID_GOES_HERE >> Nexus_repo_url_copied_here> >> default >> >> >> >> >> I'm copying the URL directly from the Nexus repo directly into the >> tags. >> >> thanks >> >> >> -Original Message- >> From: Greg Chabala >> Sent: Tuesday, August 3, 2021 2:41 PM >> To: Maven Users List >> Subject: Re: Unable to resolve artifact error when trying to transfer ISO >> using pom.xml >> >> >> External E-mail --- CAUTION: This email originated from outside GDMS. Do >> not click links or open attachments unless you recognize the sender and >> know the content is safe. >> >> Your ISO will not be in Central. If it is, you can tell us the >> coordinates. >> >> You need your Nexus repository configured in the pom.xml so that Maven >> can find the artifacts. >> >> On Tue, Aug 3, 2021 at 1:25 PM christopher.mil...@gd-ms.com < >> christopher.mil...@gd-ms.com> wrote: >> >> > >> > I was able to get a working pom.xml in our development environment, >> > however when I transferred this pom to an production, air-gapped >> > environment, it continues to output the following error: unable to >> > resolve artifact >> > >> > I am not a software developer, I'm a system engineer and a lot of the >> > pom.xml files that I've inherited aren't uniform between each other, >> > so please bear with me as I've been trying to figure this out for >> months. >> > >> > Environment: >> > RHEL 8.2 OS >> > Apache Maven 3.5.4 (currently installed) Java Version: 1.8.0_222 >> > (currently installed and added java path to my .bashrc file under my >> > home directory and output of $JAVA_HOME shows >> > /etc/alternatives/jre_1.8.0_openjdk. Not sure if this is the Java >> > that I'm supposed to use, however I don't get any type of Java errors >> > when trying to run this.) >> > >> > >> > When I execute the pom with the following command: mvn >> > dependency:copy -f pom.xml -s ~/.m2/settings.xml >> > >> > This is some of the output that I'm getting, the download part is odd, >> > as it has the group ID, artifact ID and version ID along with the name >> > of the ISO I'm trying to download from a Nexus repo. >> > >> > "Downloading from central: https://repo.maven.apache.org/maven2/ >> > ///> > https://repo.maven.apache.org/maven2/%3cgroupID%3e/%3cartifactID%3e/%3 >> > cversionID%3e%3crelease_number%3e/%3cname> >> > of ISO here> >> > >> > Error failed to execute goal >> > org.apache.maven.plugins:maven-dependency-plugin:2.8copy (default-cli) >> > on Project : Unable to resolve artifact Could not >> > transfer artifact ::iso: >> > from/to central >> > (https://repo.maven.apache.org/maven2): >> > repo.maven.apache.org: Name or service not known" >> > >> > >> > Here is my pom.xml. I've modeled this after the best practice put out >> > by apache/maven for using dependency:copy >> > >> > >> > https://maven.apache.org/plugins/maven-dependency-plugin/examples/copy >> > ing-artifacts.html >> > >> > 4.0.0 >> > >> > group_ID_here >> > artifact_ID_here >> > version_of_iso >> > >> > >> > /dropbox/ >> > >> > >> > >> > >> > >> > org.apache.maven.plugins >> > maven-dependency-plugin >> > 2.8 >> > <--
Re: Unable to resolve artifact error when trying to transfer ISO using pom.xml
For reference: https://maven.apache.org/pom.html
You want your Nexus configured in the top level repositories tag, not
in distributionManagement.
On Tue, Aug 3, 2021 at 2:00 PM christopher.mil...@gd-ms.com <
christopher.mil...@gd-ms.com> wrote:
>
> Sorry, I forgot to include the Nexus repo in the pom.xml
>
>
>
> false
> ID_GOES_HERE
> ID_GOES_HERE
> Nexus_repo_url_copied_here>
> default
>
>
>
>
> I'm copying the URL directly from the Nexus repo directly into the
> tags.
>
> thanks
>
>
> -Original Message-
> From: Greg Chabala
> Sent: Tuesday, August 3, 2021 2:41 PM
> To: Maven Users List
> Subject: Re: Unable to resolve artifact error when trying to transfer ISO
> using pom.xml
>
>
> External E-mail --- CAUTION: This email originated from outside GDMS. Do
> not click links or open attachments unless you recognize the sender and
> know the content is safe.
>
> Your ISO will not be in Central. If it is, you can tell us the coordinates.
>
> You need your Nexus repository configured in the pom.xml so that Maven can
> find the artifacts.
>
> On Tue, Aug 3, 2021 at 1:25 PM christopher.mil...@gd-ms.com <
> christopher.mil...@gd-ms.com> wrote:
>
> >
> > I was able to get a working pom.xml in our development environment,
> > however when I transferred this pom to an production, air-gapped
> > environment, it continues to output the following error: unable to
> > resolve artifact
> >
> > I am not a software developer, I'm a system engineer and a lot of the
> > pom.xml files that I've inherited aren't uniform between each other,
> > so please bear with me as I've been trying to figure this out for months.
> >
> > Environment:
> > RHEL 8.2 OS
> > Apache Maven 3.5.4 (currently installed) Java Version: 1.8.0_222
> > (currently installed and added java path to my .bashrc file under my
> > home directory and output of $JAVA_HOME shows
> > /etc/alternatives/jre_1.8.0_openjdk. Not sure if this is the Java
> > that I'm supposed to use, however I don't get any type of Java errors
> > when trying to run this.)
> >
> >
> > When I execute the pom with the following command: mvn
> > dependency:copy -f pom.xml -s ~/.m2/settings.xml
> >
> > This is some of the output that I'm getting, the download part is odd,
> > as it has the group ID, artifact ID and version ID along with the name
> > of the ISO I'm trying to download from a Nexus repo.
> >
> > "Downloading from central: https://repo.maven.apache.org/maven2/
> > /// > https://repo.maven.apache.org/maven2/%3cgroupID%3e/%3cartifactID%3e/%3
> > cversionID%3e%3crelease_number%3e/%3cname>
> > of ISO here>
> >
> > Error failed to execute goal
> > org.apache.maven.plugins:maven-dependency-plugin:2.8copy (default-cli)
> > on Project : Unable to resolve artifact Could not
> > transfer artifact ::iso:
> > from/to central
> > (https://repo.maven.apache.org/maven2):
> > repo.maven.apache.org: Name or service not known"
> >
> >
> > Here is my pom.xml. I've modeled this after the best practice put out
> > by apache/maven for using dependency:copy
> >
> >
> > https://maven.apache.org/plugins/maven-dependency-plugin/examples/copy
> > ing-artifacts.html
> >
> > 4.0.0
> >
> > group_ID_here
> > artifact_ID_here
> > version_of_iso
> >
> >
> > /dropbox/
> >
> >
> >
> >
> >
> > org.apache.maven.plugins
> > maven-dependency-plugin
> > 2.8
> > <How do I know what
> > version number this is suppose to be and will work correctly with the
> > version of Maven that I have?
> >
> >
> >
> > ${project.groupId}
> > artifact_ID_goes_here
> > ${project.version
> > iso
> > false
> > ${depStagingArea}
> > ${downloadFilename}
> >
> >
> >
> >
> >
> >
> >
> >
> > This is my settings.xml file
> >
> >
> >
> >
> > ID_goes_here
> > username_goes_here
> > password_goes_here
> > 664
> > 775
> >
> >
> >
> >
> >
> > nexus
> >
> >
> >ID_goes_here
> >URL_goes_here
> >true
> >
> >
> >
> >
> >
> >
> >
> > Thanks
> >
> > Chris
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
Re: Unable to resolve artifact error when trying to transfer ISO using pom.xml
Your ISO will not be in Central. If it is, you can tell us the coordinates. You need your Nexus repository configured in the pom.xml so that Maven can find the artifacts. On Tue, Aug 3, 2021 at 1:25 PM christopher.mil...@gd-ms.com < christopher.mil...@gd-ms.com> wrote: > > I was able to get a working pom.xml in our development environment, > however when I transferred this pom to an production, air-gapped > environment, it continues to output the following error: unable to resolve > artifact > > I am not a software developer, I'm a system engineer and a lot of the > pom.xml files that I've inherited aren't uniform between each other, so > please bear with me as I've been trying to figure this out for months. > > Environment: > RHEL 8.2 OS > Apache Maven 3.5.4 (currently installed) > Java Version: 1.8.0_222 (currently installed and added java path to my > .bashrc file under my home directory and output of $JAVA_HOME shows > /etc/alternatives/jre_1.8.0_openjdk. Not sure if this is the Java that I'm > supposed to use, however I don't get any type of Java errors when trying to > run this.) > > > When I execute the pom with the following command: mvn dependency:copy -f > pom.xml -s ~/.m2/settings.xml > > This is some of the output that I'm getting, the download part is odd, as > it has the group ID, artifact ID and version ID along with the name of the > ISO I'm trying to download from a Nexus repo. > > "Downloading from central: https://repo.maven.apache.org/maven2/ > /// https://repo.maven.apache.org/maven2/%3cgroupID%3e/%3cartifactID%3e/%3cversionID%3e%3crelease_number%3e/%3cname> > of ISO here> > > Error failed to execute goal > org.apache.maven.plugins:maven-dependency-plugin:2.8copy (default-cli) on > Project : Unable to resolve artifact > Could not transfer artifact ::iso: > from/to central > (https://repo.maven.apache.org/maven2): > repo.maven.apache.org: Name or service not known" > > > Here is my pom.xml. I've modeled this after the best practice put out by > apache/maven for using dependency:copy > > > https://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html > > 4.0.0 > > group_ID_here > artifact_ID_here > version_of_iso > > > /dropbox/ > > > > > > org.apache.maven.plugins > maven-dependency-plugin > 2.8 >version number this is suppose to be and will work correctly with the > version of Maven that I have? > > > > ${project.groupId} > artifact_ID_goes_here > ${project.version > iso > false > ${depStagingArea} > ${downloadFilename} > > > > > > > > > This is my settings.xml file > > > > > ID_goes_here > username_goes_here > password_goes_here > 664 > 775 > > > > > > nexus > > >ID_goes_here >URL_goes_here >true > > > > > > > > Thanks > > Chris >
Re: Questions on what xml tags to use for pom.xml file for downloading isos
I had the advantage of learning Maven in the company of other developers
where it was already in heavy use, but I recommend reading the beginners
guides:
https://maven.apache.org/guides/getting-started/maven-in-five-minutes.html
https://maven.apache.org/guides/getting-started/
Also, the Sonatype Maven book may be a bit dated, but sometimes it has
additional context: https://books.sonatype.com/mvnref-book/reference/
Greg Chabala
On Wed, Jul 28, 2021 at 7:03 AM christopher.mil...@gd-ms.com <
christopher.mil...@gd-ms.com> wrote:
>
> Okay, so I'll stay with what I have.
>
> Do you have any recommendations on where to get more up to speed on
> Maven? Like I said earlier, I've been watching some videos on youtube,
> still not getting some of the concepts being put forth.
>
> Thanks
>
>
>
> -Original Message-
> From: Greg Chabala
> Sent: Tuesday, July 27, 2021 4:10 PM
> To: Maven Users List
> Subject: Re: Questions on what xml tags to use for pom.xml file for
> downloading isos
>
>
> External E-mail --- CAUTION: This email originated from outside GDMS. Do
> not click links or open attachments unless you recognize the sender and
> know the content is safe.
>
> If it works, it works. It sounds like you're not really using Maven to
> build software in this case, you're only using (or abusing) it to download
> binaries.
>
> If the binaries you were downloading were actually libraries that Maven
> was using to compile software against, it would be more conventional for
> them to be in the dependency section.
>
> On Tue, Jul 27, 2021 at 2:53 PM christopher.mil...@gd-ms.com <
> christopher.mil...@gd-ms.com> wrote:
>
> >
> > Thanks for the write up.
> >
> > I'm watching a few videos on youtube, trying to understand the pros of
> > using Dependencies and I'm still not understanding, Vs what I have
> > currently mark up tags that pertain to the ISOs that I want to
> > download under and tags.
> >
> >
> >
> > -Original Message-
> > From: Greg Chabala
> > Sent: Tuesday, July 27, 2021 1:31 PM
> > To: Maven Users List
> > Subject: Re: Questions on what xml tags to use for pom.xml file for
> > downloading isos
> >
> >
> > External E-mail --- CAUTION: This email originated from outside GDMS.
> > Do not click links or open attachments unless you recognize the sender
> > and know the content is safe.
> >
> > Sounds like you're all set, but as you asked for an example with the
> > dependencies tag:
> >
> > > xmlns="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
> >
> > Software_Release_Here
> > Software_Program_Here
> > Version_Number_Here
> >
> >
> > /dropbox/foo
> > ${depStagingArea}
> >
> >
> >
> >
> >
> > org.apache.maven.plugins
> > maven-dependency-plugin
> > 3.1.1
> >
> >
> >
> >
> >
> >
> > ${project.groupId}
> > 1st_ISO_here.iso
> > ${project.version}
> > iso
> >
> >
> > ${project.groupId}
> > 2nd_ISO_here.iso
> > ${project.version}
> > iso
> >
> >
> >
> >
> > You would call this with mvn dependency:copy-dependencies instead of
> > mvn dependency:copy
> >
> > Greg Chabala
> >
> > On Tue, Jul 27, 2021 at 10:32 AM christopher.mil...@gd-ms.com <
> > christopher.mil...@gd-ms.com> wrote:
> >
> > >
> > >
> > > Thanks for the help on this as it was very helpful.
> > >
> > > All I needed was the following tag:
> > > ${depStagingArea}
> > >
> > > This places the multiple ISOs under the correct directory in RHEL OS
> > > where it was defined under the following tag:
> > > /dropbox/foo
> > >
> > >
> > >
> > >
> > > -Original Message-
> > > From: Nick Stolwijk
> > > Sent: Monday, July 26, 2021 4:18 PM
> > > To: Maven Users List
> > > Subject: Re: Questions on what xml tags to use for pom.xml file for
> > > downl
Re: Questions on what xml tags to use for pom.xml file for downloading isos
If it works, it works. It sounds like you're not really using Maven to
build software in this case, you're only using (or abusing) it to download
binaries.
If the binaries you were downloading were actually libraries that Maven was
using to compile software against, it would be more conventional for them
to be in the dependency section.
On Tue, Jul 27, 2021 at 2:53 PM christopher.mil...@gd-ms.com <
christopher.mil...@gd-ms.com> wrote:
>
> Thanks for the write up.
>
> I'm watching a few videos on youtube, trying to understand the pros of
> using Dependencies and I'm still not understanding, Vs what I have
> currently mark up tags that pertain to the ISOs that I want to download
> under and tags.
>
>
>
> -Original Message-
> From: Greg Chabala
> Sent: Tuesday, July 27, 2021 1:31 PM
> To: Maven Users List
> Subject: Re: Questions on what xml tags to use for pom.xml file for
> downloading isos
>
>
> External E-mail --- CAUTION: This email originated from outside GDMS. Do
> not click links or open attachments unless you recognize the sender and
> know the content is safe.
>
> Sounds like you're all set, but as you asked for an example with the
> dependencies tag:
>
>
> 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
>
> Software_Release_Here
> Software_Program_Here
> Version_Number_Here
>
>
> /dropbox/foo
> ${depStagingArea}
>
>
>
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
> 3.1.1
>
>
>
>
>
>
> ${project.groupId}
> 1st_ISO_here.iso
> ${project.version}
> iso
>
>
> ${project.groupId}
> 2nd_ISO_here.iso
> ${project.version}
> iso
>
>
>
>
> You would call this with mvn dependency:copy-dependencies instead of mvn
> dependency:copy
>
> Greg Chabala
>
> On Tue, Jul 27, 2021 at 10:32 AM christopher.mil...@gd-ms.com <
> christopher.mil...@gd-ms.com> wrote:
>
> >
> >
> > Thanks for the help on this as it was very helpful.
> >
> > All I needed was the following tag:
> > ${depStagingArea}
> >
> > This places the multiple ISOs under the correct directory in RHEL OS
> > where it was defined under the following tag:
> > /dropbox/foo
> >
> >
> >
> >
> > -Original Message-
> > From: Nick Stolwijk
> > Sent: Monday, July 26, 2021 4:18 PM
> > To: Maven Users List
> > Subject: Re: Questions on what xml tags to use for pom.xml file for
> > downloading isos
> >
> >
> > External E-mail --- CAUTION: This email originated from outside GDMS.
> > Do not click links or open attachments unless you recognize the sender
> > and know the content is safe.
> >
> > Hi,
> >
> > I think you need to fix the parameter resolution:
> > ${depStagingArea/pcs} should be ${depStagingArea}/pcs
> >
> > Hth,
> >
> > Nick Stolwijk
> >
> > ~~~ Try to leave this world a little better than you found it and,
> > when your turn comes to die, you can die happy in feeling that at any
> > rate you have not wasted your time but have done your best ~~~
> >
> > Lord Baden-Powell
> >
> >
> > On Mon, Jul 26, 2021 at 9:28 PM christopher.mil...@gd-ms.com <
> > christopher.mil...@gd-ms.com> wrote:
> >
> > >
> > >
> > > Hi, first post here. I'm new to Maven and its been quite some time
> > > since I've used XML.
> > >
> > > We are trying to using Maven to either upload and download artifacts
> > > from a Nexus repository Vs doing it manually.
> > >
> > > I've been trying various things, until I got the following to
> > > finally work for a multi iso download from a Nexus repo that we have
> inhouse:
> > >
> > >
> > >
> > > > > xmlns=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<
> > >
Re: Questions on what xml tags to use for pom.xml file for downloading isos
Sounds like you're all set, but as you asked for an example with the
dependencies tag:
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
Software_Release_Here
Software_Program_Here
Version_Number_Here
/dropbox/foo
${depStagingArea}
org.apache.maven.plugins
maven-dependency-plugin
3.1.1
${project.groupId}
1st_ISO_here.iso
${project.version}
iso
${project.groupId}
2nd_ISO_here.iso
${project.version}
iso
You would call this with mvn dependency:copy-dependencies instead of mvn
dependency:copy
Greg Chabala
On Tue, Jul 27, 2021 at 10:32 AM christopher.mil...@gd-ms.com <
christopher.mil...@gd-ms.com> wrote:
>
>
> Thanks for the help on this as it was very helpful.
>
> All I needed was the following tag:
> ${depStagingArea}
>
> This places the multiple ISOs under the correct directory in RHEL OS where
> it was defined under the following tag:
> /dropbox/foo
>
>
>
>
> -Original Message-
> From: Nick Stolwijk
> Sent: Monday, July 26, 2021 4:18 PM
> To: Maven Users List
> Subject: Re: Questions on what xml tags to use for pom.xml file for
> downloading isos
>
>
> External E-mail --- CAUTION: This email originated from outside GDMS. Do
> not click links or open attachments unless you recognize the sender and
> know the content is safe.
>
> Hi,
>
> I think you need to fix the parameter resolution: ${depStagingArea/pcs}
> should be ${depStagingArea}/pcs
>
> Hth,
>
> Nick Stolwijk
>
> ~~~ Try to leave this world a little better than you found it and, when
> your turn comes to die, you can die happy in feeling that at any rate you
> have not wasted your time but have done your best ~~~
>
> Lord Baden-Powell
>
>
> On Mon, Jul 26, 2021 at 9:28 PM christopher.mil...@gd-ms.com <
> christopher.mil...@gd-ms.com> wrote:
>
> >
> >
> > Hi, first post here. I'm new to Maven and its been quite some time
> > since I've used XML.
> >
> > We are trying to using Maven to either upload and download artifacts
> > from a Nexus repository Vs doing it manually.
> >
> > I've been trying various things, until I got the following to finally
> > work for a multi iso download from a Nexus repo that we have inhouse:
> >
> >
> >
> > > xmlns=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<
> > http://maven.apache.org/POM/4.0.0%20http:/maven.apache.org/xsd/maven-4
> > .0.0.xsd
> > >>
> >
> > 4.0.0
> >
> > Software_Release_Here
> > Software_Program_Here
> > Version_Number_Here
> >
> >
> >
> > /dropbox/
> > 1st_ISO_here.iso
> > 2nd_ISO_here.iso
> >
> >
> >
> >
> >
> >
> > org.apache.maven.plugins
> > maven-dependency-plugin
> > 2.8
> >
> >
> >
> > ${project.groupId}
> > 1st_ISO_here.iso
> > ${project.version}
> > iso
> > iso
> > ${depStagingArea/pcs}
> > ${downloadFilename1}
> >
> >
> > ${project.groupId}
> > 2nd_ISO_here.iso
> > ${project.version}
> > iso
> > iso
> > ${depStagingArea/pcs}
> > ${downloadFilename2}
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Also, when I run this, the isos are downloaded to ~/software/xml/poms,
> > when I've specified markup tags for
> > /dropbox/. Not sure why its working
> > like this.
> >
> > Thanks
> >
> >
> >
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
Re: Questions on what xml tags to use for pom.xml file for downloading isos
I agree with NIck's suggestion on fixing the property names.
Also, when I run this, the isos are ...
>
When you run what? Your exact command invocation would help. A pom.xml does
not run like a script, it is shared configuration for any number of plugin
invocations.
Your configuration of artifacts within the dependency plugin is unusual.
Typically, your artifacts would be defined in a top level
tag.
Greg Chabala
On Mon, Jul 26, 2021 at 3:18 PM Nick Stolwijk
wrote:
> Hi,
>
> I think you need to fix the parameter resolution: ${depStagingArea/pcs}
> should be ${depStagingArea}/pcs
>
> Hth,
>
> Nick Stolwijk
>
> ~~~ Try to leave this world a little better than you found it and, when
> your turn comes to die, you can die happy in feeling that at any rate you
> have not wasted your time but have done your best ~~~
>
> Lord Baden-Powell
>
>
> On Mon, Jul 26, 2021 at 9:28 PM christopher.mil...@gd-ms.com <
> christopher.mil...@gd-ms.com> wrote:
>
> >
> >
> > Hi, first post here. I'm new to Maven and its been quite some time since
> > I've used XML.
> >
> > We are trying to using Maven to either upload and download artifacts from
> > a Nexus repository Vs doing it manually.
> >
> > I've been trying various things, until I got the following to finally
> work
> > for a multi iso download from a Nexus repo that we have inhouse:
> >
> >
> >
> >
> > 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<
> >
> http://maven.apache.org/POM/4.0.0%20http:/maven.apache.org/xsd/maven-4.0.0.xsd
> > >>
> >
> > 4.0.0
> >
> > Software_Release_Here
> > Software_Program_Here
> > Version_Number_Here
> >
> >
> >
> > /dropbox/
> > 1st_ISO_here.iso
> > 2nd_ISO_here.iso
> >
> >
> >
> >
> >
> >
> > org.apache.maven.plugins
> > maven-dependency-plugin
> > 2.8
> >
> >
> >
> > ${project.groupId}
> > 1st_ISO_here.iso
> > ${project.version}
> > iso
> > iso
> > ${depStagingArea/pcs}
> > ${downloadFilename1}
> >
> >
> > ${project.groupId}
> > 2nd_ISO_here.iso
> > ${project.version}
> > iso
> > iso
> > ${depStagingArea/pcs}
> > ${downloadFilename2}
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Also, when I run this, the isos are downloaded to ~/software/xml/poms,
> > when I've specified markup tags for
> > /dropbox/. Not sure why its working
> like
> > this.
> >
> > Thanks
> >
> >
> >
> >
>
Re: Hi,
https://stackoverflow.com/a/27805058/62462 web.xml is usually provided in source, it is not something that maven or > any build tool has to generate > Never heard of web.xml being generated. Please show us your project if you think it is. On Sat, Jul 24, 2021 at 3:32 PM Benjamin hansen wrote: > I have read through this post: > > https://crunchify.com/how-to-run-java-program-automatically-on-tomcat-startup/ > > which describes how to automatically start my project under tomcat during > startup. > > Basically I have to add this to my web.xml > > > > CrunchifyTutorials > crunchify.com > .tutorials.CrunchifyServletExample class> > 1 > > > however the web.xml is generated by maven, so somehow i think i have to put > this into pom.xml which then will instruct maven to add this to the web.xml > file. > > So my question is how i should put this into the pom.xml file? >
RE: Parent pom plugin inheritance
Ok, so if I understand correctly, declaring plugins in the parent pom will cascade to the child pom that declares that parent, no need to reference the plugin from the child. From: Mantas Gridinas Sent: Thursday, May 6, 2021 9:18 AM To: greg.crea...@hp.com.invalid Cc: users@maven.apache.org Subject: Re: Parent pom plugin inheritance The plugins you've listed are default plugins included in maven configuration. Whether you declare them or not, they will get included regardless, though not always with the version you'll want. It's not necessary to reference the elements in management blocks in child poms either. You can reference them in the same pom that declares management blocks just fine, and the references will cascade into any pom that declare your pom as parent. I hope this clears it up a bit. On Thu, May 6, 2021 at 2:20 PM Creager, Greg mailto:greg.crea...@hp.com.invalid>> wrote: > > I am new to Maven and doing a lot of learning about Parent pom inheritance. > When I first set things up, I put the common plugins in the parent pom under > the plugingManagement tags and things are working fine (with no plugins in > the child poms) > > But in my research of all things maven I came across a few learnings that say > the way I have things setup should not work. From what I can tell and from > the Maven learning page, even if you use pluginManagment to put your plugins > at the parent POM, you still need to reference those plugins from the child > pom. > Plugin Management > ? pluginManagement: is an element that is seen along side plugins. Plugin > Management contains plugin elements in much the same way, except that rather > than configuring plugin information for this particular project build, it is > intended to configure project builds that inherit from this one. However, > this only configures plugins that are actually referenced within the plugins > element in the children or in the current POM. The children have every right > to override pluginManagement definitions. > https://maven.apache.org/pom.html#Plugin_Management<https://maven.apache.org/pom.html#Plugin_Management> > > > But with my experience, the plugins defined in the parent pom are getting > used without any declaration in the child, I even changed versions in the > parent to confirm I was not just getting default plugin versions. What am I > missing? Have things changed? I did think it odd that you could not inherit > plugins like everything else you can. > > Note: I am not using any configurations, just simple plugin reference in > parent pom: > build> > > > maven-clean-plugin > 3.1.0 > > > maven-resources-plugin > 3.1.0 > > > maven-compiler-plugin > 3.8.1 > > > maven-surefire-plugin > 3.0.0-M4 > > > maven-jar-plugin > 3.2.0 > > > maven-install-plugin > 3.0.0-M1 > > > maven-deploy-plugin > 3.0.0-M1 > > > maven-site-plugin > 3.7.1 > > > maven-project-info-reports-plugin > 3.0.0 > > > > > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org<mailto:users-unsubscr...@maven.apache.org> For additional commands, e-mail: users-h...@maven.apache.org<mailto:users-h...@maven.apache.org>
Parent pom plugin inheritance
I am new to Maven and doing a lot of learning about Parent pom inheritance. When I first set things up, I put the common plugins in the parent pom under the plugingManagement tags and things are working fine (with no plugins in the child poms) But in my research of all things maven I came across a few learnings that say the way I have things setup should not work. From what I can tell and from the Maven learning page, even if you use pluginManagment to put your plugins at the parent POM, you still need to reference those plugins from the child pom. Plugin Management ? pluginManagement: is an element that is seen along side plugins. Plugin Management contains plugin elements in much the same way, except that rather than configuring plugin information for this particular project build, it is intended to configure project builds that inherit from this one. However, this only configures plugins that are actually referenced within the plugins element in the children or in the current POM. The children have every right to override pluginManagement definitions. https://maven.apache.org/pom.html#Plugin_Management But with my experience, the plugins defined in the parent pom are getting used without any declaration in the child, I even changed versions in the parent to confirm I was not just getting default plugin versions. What am I missing? Have things changed? I did think it odd that you could not inherit plugins like everything else you can. Note: I am not using any configurations, just simple plugin reference in parent pom: build> maven-clean-plugin 3.1.0 maven-resources-plugin 3.1.0 maven-compiler-plugin 3.8.1 maven-surefire-plugin 3.0.0-M4 maven-jar-plugin 3.2.0 maven-install-plugin 3.0.0-M1 maven-deploy-plugin 3.0.0-M1 maven-site-plugin 3.7.1 maven-project-info-reports-plugin 3.0.0
Re: Maven superpom, JUnit 5 and Spring
You're taking the discussion to a place about building something flexible, but the initial question from a user was 'Why is the Super POM pulling in an old version of maven-surefire-plugin by default?'. That's an issue that deserves to be solved. Maven 3.6.3's Super POM pulls in maven-surefire-plugin version 2.12.4, which was published 2012-09-24. Can we update the Super POM to something less ancient so that new users don't get burned by default? On Sun, Mar 7, 2021 at 2:07 PM Hervé BOUTEMY wrote: > if you're talking about the little subset that we use for our default > packaging bindings [1], as you can see from the page, there is already a > version fixed by the bindings > > but: > 1. that ties you to a precise Maven version, which is something we want to > avoid > 2. it does not work for the many other plugins > > that's why any discussion is about making something flexible, and not > focusing > only on the few plugins used by default packagings > > regards, > > Hervé > > [1] https://maven.apache.org/ref/3.6.3/maven-core/default-bindings.html > > Le dimanche 7 mars 2021, 15:43:45 CET Mantas Gridinas a écrit : > > Maven does not provide all of those 5 thousand plugins by default, does > it? > > > > On Sun, Mar 7, 2021 at 11:39 AM Hervé BOUTEMY > wrote: > > > > But my question is why not add a feature where maven would > > > > produce a pom that contains the default plugins, repositories, and > etc. > > > > regardless of how verbose it would be? > > > > > > because there is a wide diversity of plugins (more than 5,000 in > Central > > > Repository), then nobody can define everything > > > > > > We need something extensible > > > > > > Regards, > > > > > > Hervé > > > > > > Le dimanche 7 mars 2021, 12:08:39 CET Mantas Gridinas a écrit : > > > > As far as I understand, depending on maven version, the list of > default > > > > plugin versions is different. One way I go around this is by using > maven > > > > wrapper, which also downloads the required maven version by the > project. > > > > > > > > The other way to go around this is to define all the plugin versions > > > > yourself. But my question is why not add a feature where maven would > > > > produce a pom that contains the default plugins, repositories, and > etc. > > > > regardless of how verbose it would be? > > > > > > > > On Sun, Mar 7, 2021, 12:46 Hervé BOUTEMY > wrote: > > > > > sorry, I don't understand: can you explain a little more what you > mean > > > > > by > > > > > "produce the implied pom" and "some issues of irreproducability"? > > > > > > > > > > Le dimanche 7 mars 2021, 10:44:08 CET Mantas Gridinas a écrit : > > > > > > Why not provide an ability to produce the implied pom explicitly > in > > > > > > current project as well? This way you would get around some > issues > > > > > > of > > > > > > irreproducability. > > > > > > > > > > > > On Sun, Mar 7, 2021 at 9:29 AM Hervé BOUTEMY < > herve.bout...@free.fr> > > > > > > > > > > wrote: > > > > > > > every existing plugin version can't be defined by Maven itself, > > > > > > > given > > > > > > > diversity of plugins > > > > > > > then we need something extensible > > > > > > > > > > > > > > there is https://issues.apache.org/jira/browse/MNG-5588 , > > > > > > > proposing to > > > > > > > mimic dependencyManagement import to get an equivalent > > > > > > > pluginManagement > > > > > > > import > > > > > > > > > > > > > > I love this idea, which is currently blocked by one stupid > > > > > > > concrete > > > > > > > > > > issue: > > > > > > > there is no "scope" field in plugin definition > > > > > > > > > > > > > > looking at model: > > > > > > > > https://maven.apache.org/ref/3.6.3/maven-model/maven.html#class_pl > > > > > > > ugin > > > > > > > > > > > > > > perhaps we could abuse plugin's "inherited" field, the same > way we > > > > >
Re: Maven superpom, JUnit 5 and Spring
I agree with the recommendations made by Anthony, and that best practice is to specify all versions explicitly. However, I am also empathetic to the concerns raised by Tilman. When people compare Maven to other build tools and complain about the verbosity of POM files, a lot of that verbosity comes from having to specify versions for plugins, including plugins that are part of the default lifecycle. If we agree that Maven follows a convention over configuration design, perhaps the Super POM should be updated to some more sensible defaults. While it may not be as reproducible to leave them unspecified, it would reduce the surprise to beginners when now very outdated plugin versions are used by default. Greg On Mon, Feb 22, 2021 at 3:44 PM Anthony Whitford wrote: > I recommend reading the “Important Note” found here: > https://maven.apache.org/guides/mini/guide-configuring-plugins.html#introduction > < > https://maven.apache.org/guides/mini/guide-configuring-plugins.html#introduction > > > > > Important Note: Always define each version of the plugins used by the > build to guarantee the build reproducibility. A good practice is to specify > them in the elements for each build > plugins. (Generally, you will define a element in a > parent POM.) For reporting plugins, specify each version in the > elements (and surely in the > elements too). > > > In other words, do not rely on the implied Super Parent Pom for defining > plugin versions because it will not guarantee build reproducibility. > Instead, your pom hierarchy should explicitly declare the plugin versions > to use. (Maintaining a corporate pom that may be used across projects > might be a wise approach.) > > > > On Feb 22, 2021, at 11:11 AM, Tilman Hausherr > wrote: > > > > Hello, > > > > I'm using maven 3.6.3 and the maven-surefire-plugin version used in a > build is 2.12.4 when the version is not specified, the "effective" version > is 2.10. For junit 5 one needs 2.22.2, see > > > https://junit.org/junit5/docs/current/user-guide/#running-tests-build-maven > > this is a pitfall for JUnit 5 users: > > https://stackoverflow.com/a/66313961/535646 > > who don't read the manual. Should I create a JIRA issue that the super > pom should be updated? Or is another plugin to "blame" for the default > version? > > > > Tilman > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > >
Re: where to get the code example ?
Looks like the correct link is http://books.sonatype.com/mvnex-book/mvnex-examples.zip Found in an old issue: https://github.com/sonatype/maven-example-en/issues/43 On Sun, Feb 14, 2021 at 8:29 PM Karen Goh wrote: > hi, > I come to know about the free ebooks where they detailed all about using > maven. > There is a zip on chapter 6 - multi module project which I need to study > as my current project is using multi modules. > But, when I go to the link : > > http://www.sonatype.com/books/mvnex-book/mvnex-examples.zip > > it just directed me to: > > https://books.sonatype.com/mvnex-book/reference/index.html > > Please let me know where can I download the zip file. > > Tks & regards, > Karen > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: How do you get "import in3.*;" to work in a Java program when using Maven?
Looks like it's not on Maven Central. There was an issue opened about it: https://github.com/blockchainsllc/in3/issues/16 As well as two opened yesterday, by a3845: https://github.com/blockchainsllc/in3/issues/28 & https://github.com/blockchainsllc/in3/issues/29 You can follow the project's directions and install their jar into your local repo, or a local repo manager like Nexus. I'd be hesitant use any library that hadn't figured out how to get their artifact to central though. It'll just as likely disappear. Greg Chabala On Sun, Jan 17, 2021 at 3:46 PM Alub Quinata wrote: > I have a working pom.xml file, and I want to use Incubed in3. I added > these lines to my Maven pom.xml file: > > > it.slock > in3 > v2.5.4 > > > > I was trying to follow the directions here: > https://github.com/blockchainsllc/in3/packages/72045?version=v2.5.4 > > I tried different versions of in3 too. Whenever I ran "mvn install", I > got an error like this: > > Could not resolve dependencies for project org.foobar:jar:0.1.0: Could not > find artifact it.slock:in3:jar:2.5.4 in central ( > https://repo.maven.apache.org/maven2) > > I looked on different Maven repositories for "in3" or "it.slock", but I > could not find anything. How do you use pom.xml to build in3 for Java? >
Re: maven-resources-plugin:3.2.0 fails with weird error
Given the stacktrace, I'm guessing you've found a regression from this commit: https://github.com/apache/maven-filtering/commit/80c045058a364c5c7d46be9c2b2ae65b81f84d7f Nothing else in that file has changed in years. Would be good to narrow it down to a test case though. On Thu, Nov 12, 2020 at 7:14 PM Maxim Solodovnik wrote: > Here is the output with `-e`: > > *mvn -version* > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) > Maven home: /opt/maven > Java version: 11.0.9, vendor: Ubuntu, runtime: > /usr/lib/jvm/java-11-openjdk-amd64 > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "5.4.0-53-generic", arch: "amd64", family: > "unix" > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-resources-plugin:3.2.0:copy-resources > (prepare-test-resources) on project openmeetings-web: Input length = 1 -> > [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-resources-plugin:3.2.0:copy-resources > (prepare-test-resources) on project openmeetings-web: Input length = 1 > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:215) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:156) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:148) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:117) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:81) > at > > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build > (SingleThreadedBuilder.java:56) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute > (LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) > at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) > at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957) > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289) > at org.apache.maven.cli.MavenCli.main (MavenCli.java:193) > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native > Method) > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl.java:62) > at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke (Method.java:566) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced > (Launcher.java:282) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch > (Launcher.java:225) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode > (Launcher.java:406) > at org.codehaus.plexus.classworlds.launcher.Launcher.main > (Launcher.java:347) > Caused by: org.apache.maven.plugin.MojoExecutionException: Input length = 1 > at org.apache.maven.plugins.resources.ResourcesMojo.execute > (ResourcesMojo.java:362) > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo > (DefaultBuildPluginManager.java:137) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:210) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:156) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:148) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:117) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:81) > at > > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build > (SingleThreadedBuilder.java:56) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute > (LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) > at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) > at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957) > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289) > at org.apache.maven.cli.MavenCli.main (MavenCli.java:193) > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native > Method) > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl.java:62) > at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke (Method.java:566) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced > (Launcher.java:282) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch > (Launcher.java:225) > at org.codehaus.plexus.classworlds.laun
Re: jfx library location with javafx.scene.layout.Region
JavaFX has been removed from the JDK for some time now: https://blogs.oracle.com/java-platform-group/the-future-of-javafx-and-other-java-client-roadmap-updates This is the artifact you want: https://search.maven.org/artifact/org.openjfx/javafx-graphics org.openjfx javafx-graphics 15.0.1 On Sun, Nov 1, 2020 at 7:08 AM Martin Gainty wrote: > attempting to locate jar for javafx.scene.layout.Region > > from what i see jfx.scene.layout is part of jfx library > > but from some reason jfx was not included in OpenJDK > > any clues where to find binaries for jfx? > > Thanks! > martin >
Re: Using Apache Maven, what is the simplest way to include /lib/ directory in the classpath in the pom.xml
I appreciate that you're trying to use Maven to build software, but you've framed your question unfairly. What is the simplest way to specify a directory (and all jars underneath > this directory) to be in the maven classpath when it compiles .java classes > and builds a .jar? > Maven builds from versioned JARs identified by coordinates. You cannot jam a directory of JARs into the classpath. Maybe you can do that in Ant, but not Maven. I need something with no more than 5..10 lines of XML that would include > this directory so that it would pick up all jars and add to the class path. > Doesn't exist, no matter how much you want it. There are hundreds of jar files in the > $TOMCAT_HOME//WEB-INF/lib directory. > Over time I can create an entry for each one, but I just don't have time > for that right now, also I would need to determine the version of each and that would be a nightmare. The time is now. Don't leave the nightmare for someone else later. I suspect your real issue is closer to this: https://blog.sonatype.com/2009/04/how-to-convert-from-ant-to-maven-in-5-minutes/ Greg Chabala On Fri, Oct 16, 2020 at 9:48 AM /dev /local/ca wrote: > Thank you for the suggestion Bernd, > > Do you have an example you can share? There are hundreds of jar files in > the $TOMCAT_HOME//WEB-INF/lib directory. > > I need something with no more than 5..10 lines of XML that would include > this directory so that it would pick up all jars and add to the class path. > Over time I can create an entry for each one, but I just don't have time > for that right now, also I would need to determine the version of each and > that would be a nightmare. > > If you can please help with what the question asks. > > On Fri, Oct 16, 2020 at 2:38 AM Bernd Eckenfels > wrote: > > > Hello, > > > > It is really not a good idea to fight maven. If you need something in the > > classpath for compile, specify it as dependency in the Pom. Otherwise > your > > build cannot be repeated and the project is hard to set up. > > > > All tomcat libraries needed to compile should be in the maven repository. > > If you have custom artifacts, the normal method is to upload them to a > > (own) repository Server and reference them there. > > > > There is a way to specify a local („system“) location for dependencies, > > but I would not recommend that way. (And in all cases not possible to > use a > > wildcard/directory search) > > > > Gruss > > Bernd > > > > > > -- > > http://bernd.eckenfels.net > > > > Von: /dev /local/ca > > Gesendet: Friday, October 16, 2020 10:24:50 AM > > An: users@maven.apache.org > > Betreff: Using Apache Maven, what is the simplest way to include > > /lib/ directory in the classpath in the > > pom.xml > > > > What is the simplest way to specify a directory (and all jars underneath > > this directory) to be in the maven classpath when it compiles .java > classes > > and builds a .jar? > > > > The directory is not in my git repo or any directory under my IDE project > > files. > > > > I have a requirement to create a pom.xml that will reference the current > > project, and external jars in a /lib/ directory. > > -- > > > > The requirement is to put together a pom.xml for a maven build that > depends > > on jars in: > > > > $TOMCAT_HOME/webapps//WEB-INF/lib/ > > > > I want to reference that location directly in the maven pom.xml file and > > not copy the /lib/*.jar files to another directory under my git repo. > > > > The .../WEB-INF/lib/ contains .jar files that contains classes that my > > project imports. > > > > The jar that is then built will be put into: > > $TOMCAT_HOME/webapps//WEB-INF/lib/ to extend the product as > > per the vendor instructions. > > -- > > > > If anyone has had this exact issue, and has a reference pom.xml that can > be > > pasted here, it would be extremely helpful and get me going quickly. > > -- > > > > Irrespective of the deployment part where I copy the jar to > > /webapps//WEB-INF/lib/, I would be happy to just get files > > under /src/com/.../.java/ compiled and put into a jar in the /target/ > > directory > > >
Re: Maven Plugins & Confusing Versioning
I agree with other users' sentiments here. I was ignoring the milestone releases for a long time as though they were unfinished and unsuitable for stable use. Additionally, I have my version checking plugin configured to ignore milestones based on how they are used by other projects, and there's little point to making an exception for Maven plugin versions. Greg Chabala On Tue, Oct 6, 2020 at 9:13 AM Gary Gregory wrote: > On Tue, Oct 6, 2020 at 7:46 AM Thomas Broyer wrote: > > > (sorry for the delay) > > > > On Sat, Oct 3, 2020 at 5:27 PM Karl Heinz Marbaise > > wrote: > > > > > Hi, > > > > > > On 03.10.20 11:47, Thomas Broyer wrote: > > > > Wait, you mean that you don't even follow your own rules for versions > > ⁉️ > > > > where milestones sit between beta and RC versions. > > > > > > Can you explain which rules you are referencing? > > > > > > > I meant those: > > https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning > > > > > https://github.com/apache/maven/blob/maven-3.6.3/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java#L356 > > > > > https://github.com/apache/maven/blob/maven-3.6.3/maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java#L48 > > and as shown by that command: > > $ java -jar /opt/maven/lib/maven-artifact-3.6.3.jar 3.0.0-beta1 3.0.0-M1 > > 3.0.0-RC1 3.0.0 > > Display parameters as parsed by Maven (in canonical form) and comparison > > result: > > 1. 3.0.0-beta1 == 3-beta-1 > >3.0.0-beta1 < 3.0.0-M1 > > 2. 3.0.0-M1 == 3-milestone-1 > >3.0.0-M1 < 3.0.0-RC1 > > 3. 3.0.0-RC1 == 3-rc-1 > >3.0.0-RC1 < 3.0.0 > > 4. 3.0.0 == 3 > > > > The part M... is from our perspective a milestone in direction to a > > > particular set of features that has nothing to do with not stable... > for > > > > example see https://maven.apache.org/surefire/maven-failsafe-plugin/ > > > > > > > > I'm for example using maven-release-plugin:3.0.0-M1 in production... > > > You can take a look into the CI results > > > ( > > > > > > https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-release/job/master/ > > > ) > > > or the tests which are running on them: > > > > > > > > > https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-release/job/master/lastCompletedBuild/testReport/ > > > > > > > > > The question based on that is comming up: > > > > > > What do you define as "unstable" ? All of those plugins are already > > > running very long (I mean very long) in production environments ... so > > > of course sometimes people find bugs ... > > > > > > > > > As Enrico alrady mentioned ...we don't release unstable plugins... (but > > > it drills down to the question: What is a unstable plugin?) > > > > > > The question to me is: should anyone use a milestone version? What are > the > > "guarantees" compared to a "final" version? > > If you're saying that there's no reason not to use a milestone in > > production, that it's guaranteed to work just as well as a "final" > version, > > then why isn't it labelled "final"? > > When I see a milestone version (or any "prerelease" version), I'm > thinking > > "OK, they're still working on it (hey, it's not even a release > candidate), > > let's use the latest "final" release" (in this case 2.5.3; > > > > > https://search.maven.org/artifact/org.apache.maven.plugins/maven-release-plugin > > ). > > I also expect that if there are bugs in that latest "final" release that > > possibly there could be a "point release" fixing them (2.5.4) before the > > next major version is "stable" (3.0.0) > > So of course such a "prerelease" could be "stable enough" to be used in > > production, but who knows in which ways it could possibly break? or > change > > in backwards-incompatible ways in a future 3.0.0-M2 or the final 3.0.0? > > Only people following the plugin's development closely can know. > > > > So, if the message you want to send is "use that 3.0.something version, > > it's absolutely OK for production use (and btw we'll fix 2.5.3 bugs in a > > 3.0.0-M2, not a 2.5.4)", then tag it as 3.0.0 (or 2.5.4 or 2.6.0), not > > 3.0.0-M1. > > If you want to make it clear that some feature is not "stable" yet (in > its > > API/configuration, or possibly buggy), then you could add warnings in the > > docs and even issue a warning at runtime if it's being used (I know > people > > don't pay attention to warnings, and I think mostly because Maven output > is > > quite/too verbose, but still). > > > > From a user's POV, I agree that the messaging on "M" releases is unclear. > To me a milestone release is not stable, it's just a different way of > saying "alpha" or "beta". > > Gary > > > > > -- > > Thomas Broyer > > /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/> < > http://xn--nna.ma.xn--bwa-xxb.je/> < > > http://xn--nna.ma.xn--bwa-xxb.je/> > > >
Re: CPD goal in maven plugin does not support txt format.
>> 'text' doesn't work. >> In my opinion, txt and text should both be viable options. >> >> The PMD goal rejects 'text' and only accepts 'txt'. Sorry about that. Just a guess on my part from looking at the source of TextRenderer <https://github.com/pmd/pmd/blob/master/pmd-core/src/main/java/net/sourceforge/pmd/renderers/TextRenderer.java#L22>, since it registers itself using "text". But that's in PMD itself, looks like the plugin is doing its own thing with configuration codes. >> Any particular reason why Maven developers don't seem to like outputting >> text output? I see something similar with the Spotbugs plugin. There's no >> text output either and the XML output is too verbose for my liking. I've used maven-pmd-plugin myself, and I think it works great. I reference the plugin in the reporting section of my build, and the reports get generated with the site goal. I expect reading the HTML reports as part of the generated site does the job for most folks. And if one wanted to do something with the report programmatically, there's the xml report for that. It seems your wish for text output is a bit far from the happy path, since no one noticed it was broken. Just poking around in the blame, this looks like the commit that removed the "txt" support, 14 years ago: https://github.com/apache/maven-pmd-plugin/commit/e64025962e6babb82435099673a635ab497f2a6b#diff-b57f29ee2de2392a1af539fb7c05ec76L224 >> Specifying sourceforge.pmd.cpd.SimpleRenderer >> works but it outputs a file as the full class name and ignores the >> skipEmptyReport configuration value set to true. That sounds pretty good to me. Could still try the TextRenderer to see if it performs more to your liking. >> It also generates a cpd.xml file. Always. It says that right in the code: https://github.com/apache/maven-pmd-plugin/blob/master/src/main/java/org/apache/maven/plugins/pmd/CpdReport.java#L311 // always create XML format. we need to output it even if the file list is > empty or we have no duplications > // so the "check" goals can check for violations > writeXmlReport( cpd ); Greg On Fri, Jul 3, 2020 at 6:14 PM LINUS FERNANDES wrote: > >>>>>You want the text renderer? > > https://github.com/pmd/pmd/blob/master/pmd-core/src/main/java/net/sourceforge/pmd/renderers/TextRenderer.java > > What do you mean? Obviously, I want text output, not XML. I prefer less > verbose output since I'm looking at it through a text editor. > > On Fri, Jul 3, 2020 at 5:40 PM LINUS FERNANDES wrote: > Thanks, Greg. > > On Sat, 4 Jul 2020, 04:05 LINUS FERNANDES, > wrote: > > > The goals need an output file name as well, I think. > > > > On Sat, 4 Jul 2020, 03:52 LINUS FERNANDES, > > wrote: > > > >> Any particular reason why Maven developers don't seem to like outputting > >> text output? I see something similar with the Spotbugs plugin. There's > no > >> text output either and the XML output is too verbose for my liking. > >> I've already filed an issue concerning that. > >> > >> 'text' doesn't work. > >> In my opinion, txt and text should both be viable options. > >> > >> The PMD goal rejects 'text' and only accepts 'txt'. > >> > >> Since they're from the same Maven family, the CPD goal must accept txt > as > >> an option as well. And the documentation is misleading when it says it > >> supports specifying 'txt' as an input. > >> > >> Specifying sourceforge.pmd.cpd.SimpleRenderer > >> works but it outputs a file as the full class name and ignores the > >> skipEmptyReport configuration value set to true. > >> > >> It also generates a cpd.xml file. > >> > >> Where does a bug report go? > >> Jira or the pmd Github repo? > >> > >> Is there a specific tag for the pmd maven plugin? > >> > >> > >> > >> > >> On Sat, 4 Jul 2020, 01:56 Greg Chabala, wrote: > >> > >>> Better still, use the full classname of the renderer, looks like the > >>> plugin > >>> only know how to handle xml and csv: > >>> > >>> > https://github.com/apache/maven-pmd-plugin/blob/master/src/main/java/org/apache/maven/plugins/pmd/CpdReport.java#L456 > >>> > >>> On Fri, Jul 3, 2020 at 3:22 PM Greg Chabala > >>> wrote: > >>> > >>> > Looks like a typo in the documentation. From your link "See the > >>> > net.sourceforge.pmd.renderer
Re: CPD goal in maven plugin does not support txt format.
Better still, use the full classname of the renderer, looks like the plugin only know how to handle xml and csv: https://github.com/apache/maven-pmd-plugin/blob/master/src/main/java/org/apache/maven/plugins/pmd/CpdReport.java#L456 On Fri, Jul 3, 2020 at 3:22 PM Greg Chabala wrote: > Looks like a typo in the documentation. From your link "See the > net.sourceforge.pmd.renderers package javadoc for available renderers". > > You want the text renderer? > https://github.com/pmd/pmd/blob/master/pmd-core/src/main/java/net/sourceforge/pmd/renderers/TextRenderer.java > > Try "text" instead of "txt". > > On Fri, Jul 3, 2020 at 2:18 AM LINUS FERNANDES > wrote: > >> If this is a bug, where do I file it? >> >> On Fri, 3 Jul 2020, 11:46 LINUS FERNANDES, >> wrote: >> >> > >> > I receive the following message while using the cpd goal in the PMD >> maven >> > plugin. >> > >> > maven.plugins:maven-pmd-plugin:3.13.0:cpd (cpd) on project DSAlgos: >> > Execution cpd of goal >> org.apache.maven.plugins:maven-pmd-plugin:3.13.0:cpd >> > failed: org.apache.maven.reporting.MavenReportException: Can't find CPD >> > custom format txt: java.lang.ClassNotFoundException >> > >> > The documentation states that the txt format is supported. >> > >> > https://maven.apache.org/plugins/maven-pmd-plugin/cpd-mojo.html#format >> > >> > The pmd goal supports the txt format. >> > >> > >> > Regards, >> > Linus. >> > >> > >> > >> > >> >
Re: CPD goal in maven plugin does not support txt format.
Looks like a typo in the documentation. From your link "See the net.sourceforge.pmd.renderers package javadoc for available renderers". You want the text renderer? https://github.com/pmd/pmd/blob/master/pmd-core/src/main/java/net/sourceforge/pmd/renderers/TextRenderer.java Try "text" instead of "txt". On Fri, Jul 3, 2020 at 2:18 AM LINUS FERNANDES wrote: > If this is a bug, where do I file it? > > On Fri, 3 Jul 2020, 11:46 LINUS FERNANDES, > wrote: > > > > > I receive the following message while using the cpd goal in the PMD maven > > plugin. > > > > maven.plugins:maven-pmd-plugin:3.13.0:cpd (cpd) on project DSAlgos: > > Execution cpd of goal > org.apache.maven.plugins:maven-pmd-plugin:3.13.0:cpd > > failed: org.apache.maven.reporting.MavenReportException: Can't find CPD > > custom format txt: java.lang.ClassNotFoundException > > > > The documentation states that the txt format is supported. > > > > https://maven.apache.org/plugins/maven-pmd-plugin/cpd-mojo.html#format > > > > The pmd goal supports the txt format. > > > > > > Regards, > > Linus. > > > > > > > > >
Re: org.codehaus.mojo > mojohaus.org
Never used it myself, but these might help: https://search.maven.org/search?q=g:org.codehaus.mojo%20a:animal-sniffer* https://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/ https://github.com/mojohaus/animal-sniffer Cheers, Greg Chabala On Mon, Jun 29, 2020 at 4:54 PM Charles Herrick < charles.herr...@perficient.com> wrote: > Links still have the old org.codehaus.mojo form URL and thus are not > reachable. I’m looking for the latest Animal Sniffer to plug into my > Maven+Eclipse. > > > > Am I missing something? > > > > Thanks, > > e: charles.herr...@perficient.com > > t: Texas Time > > -- > > *Charles Herrick*, Technical Architect > > m: 512-289-0926 | NASDAQ: PRFT | *Perficient.com > <http://www.perficient.com/>* > > > > [image: Logo Icon] <http://www.perficient.com/> > > > > [image: LinkedIn Icon] <https://www.linkedin.com/company/165444> [image: > Twitter Icon] <https://twitter.com/perficient> [image: Blog Icon] > <http://blogs.perficient.com/> [image: Facebook Icon] > <https://www.facebook.com/perficient> [image: YouTube Icon] > <https://www.youtube.com/channel/UCRUC3AbkGIH4Wud_PgKovug/> > > >
Re: bad links
Looks like most of these were fixed in April with this commit: https://github.com/apache/maven-deploy-plugin/commit/5378b4936866a927260b893dfd81abb2f4ceb1ef and there's an open PR from 2018 for the dead example link: https://github.com/apache/maven-deploy-plugin/pull/2 On Fri, May 22, 2020 at 3:32 PM Anders Hammar wrote: > Works for me. > > /Anders (mobile) > > Den fre 22 maj 2020 21:54Greg Chabala skrev: > > > It looks to me that some of the inline links in the Usage paragraph are > > broken: > > user mailing list - links to > > https://maven.apache.org/plugins/maven-deploy-plugin/mail-lists.html > which > > 404s > > mail archive - also links to > > https://maven.apache.org/plugins/maven-deploy-plugin/mail-lists.html > > issue tracker - links to > > https://maven.apache.org/plugins/maven-deploy-plugin/issue-tracking.html > > which 404s > > source repository - links to > > > https://maven.apache.org/plugins/maven-deploy-plugin/source-repository.html > > which > > 404s > > > > also, in examples: > > Disable timestamps suffix in an artifact - links to > > > > > https://maven.apache.org/plugins/maven-deploy-plugin/examples/disabling-timestamps-suffix.html > > which 404s > > > > On Fri, May 22, 2020 at 1:41 PM Karl Heinz Marbaise > > wrote: > > > > > Hi Robert, > > > > > > On 22.05.20 19:21, Roger Pack wrote: > > > > As a note all the url's under "usages" here: > > > > https://maven.apache.org/plugins/maven-deploy-plugin/index.html > > > > are 404's... > > > > Cheers! > > > > > > > > > Unfortunately I can not acknowledge this? > > > > > > working fine from my site. > > > > > > Yes they are shown as "not secure" cause there are some http links in > > > there. > > > > > > Kind regards > > > Karl Heinz Marbaise > > > > > > - > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > > >
Re: bad links
It looks to me that some of the inline links in the Usage paragraph are broken: user mailing list - links to https://maven.apache.org/plugins/maven-deploy-plugin/mail-lists.html which 404s mail archive - also links to https://maven.apache.org/plugins/maven-deploy-plugin/mail-lists.html issue tracker - links to https://maven.apache.org/plugins/maven-deploy-plugin/issue-tracking.html which 404s source repository - links to https://maven.apache.org/plugins/maven-deploy-plugin/source-repository.html which 404s also, in examples: Disable timestamps suffix in an artifact - links to https://maven.apache.org/plugins/maven-deploy-plugin/examples/disabling-timestamps-suffix.html which 404s On Fri, May 22, 2020 at 1:41 PM Karl Heinz Marbaise wrote: > Hi Robert, > > On 22.05.20 19:21, Roger Pack wrote: > > As a note all the url's under "usages" here: > > https://maven.apache.org/plugins/maven-deploy-plugin/index.html > > are 404's... > > Cheers! > > > Unfortunately I can not acknowledge this? > > working fine from my site. > > Yes they are shown as "not secure" cause there are some http links in > there. > > Kind regards > Karl Heinz Marbaise > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: maven-license-plugin: what does 'license-list' actually produce?
Ah, like what you get from the standard dependency report? E.g. https://maven.apache.org/plugins/maven-dependency-plugin/dependencies.html#Licenses On Wed, May 6, 2020 at 5:55 PM Alain Désilets wrote: > On Wed, May 6, 2020 at 6:48 PM Greg Chabala > wrote: > > > Ah, I see. I believe it's closer to (A), but I would describe it as 'the > > list of licenses that the plugin knows to exist in the universe'. > > > > Really? Not terribly useful. I can probably accurate version of that info > from wikipedia. > > > > > > I believe (B) would be the license:third-party-report goal: > > > https://www.mojohaus.org/license-maven-plugin/third-party-report-mojo.html > > > Yeah, I ran that. But it basically gives me a long list of third-party > modules with their licenses. What I would like to see is a consolidated > "bag" of all the licenses that my project depends on. Of course, I can > manually generate that bag by consolidating the third-party-report output, > but it would be nice to have an automated way to get that. > > Alain >
Re: maven-license-plugin: what does 'license-list' actually produce?
Ah, I see. I believe it's closer to (A), but I would describe it as 'the list of licenses that the plugin knows to exist in the universe'. I believe (B) would be the license:third-party-report goal: https://www.mojohaus.org/license-maven-plugin/third-party-report-mojo.html On Wed, May 6, 2020 at 5:34 PM Alain Désilets wrote: > On Wed, May 6, 2020, 4:16 PM Greg Chabala wrote: > > > The documentation has an example of the output: > > > > > https://www.mojohaus.org/license-maven-plugin/examples/example-license-list.html > > > Yes I saw that. I just don't know how to interpret that list. Is it > > (A) the list of all licenses under which I coul distribute the projet >Or > (B) the union of all the licenses of a dependancy that the project depends > on > > > > > > > On Wed, May 6, 2020 at 3:03 PM Alain Désilets > > wrote: > > > > > The output of the license-list goal and the plugin documentation say > that > > > this is a list of 'availalble licenses'. > > > > > > I am not sure what 'available' means in this context. I *believe* it > > means > > > those are the various licenses under which I could distribute the > > project. > > > But I am not sure. Can someone confirm that my understanding is > correct? > > > > > > Thx. > > > > > > Alain Désilets > > > > > >
Re: maven-license-plugin: what does 'license-list' actually produce?
The documentation has an example of the output: https://www.mojohaus.org/license-maven-plugin/examples/example-license-list.html On Wed, May 6, 2020 at 3:03 PM Alain Désilets wrote: > The output of the license-list goal and the plugin documentation say that > this is a list of 'availalble licenses'. > > I am not sure what 'available' means in this context. I *believe* it means > those are the various licenses under which I could distribute the project. > But I am not sure. Can someone confirm that my understanding is correct? > > Thx. > > Alain Désilets >
Re: Global setting for --no-transfer-progress
You could add the option to the ${maven.projectBasedir}/.mvn/maven.config file,
but that's still a per project change, unfortunately.
On Tue, Apr 7, 2020 at 9:16 AM Tomo Suzuki
wrote:
> I tried MAVEN_OPTS, which did not work (it's not for Java virtual machine):
>
> suztomo-macbookpro44% export MAVEN_OPTS='--no-transfer-progress'
> suztomo-macbookpro44% mvn compile
> Unrecognized option: --no-transfer-progress
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
>
>
> Ugly suggestion: adding that option at the end of "mvn" shell script.
>
>
>
>
> On Tue, Apr 7, 2020 at 7:29 AM Tarakesh Vishwanath
> wrote:
>
> > Hi,
> >
> > We have started using Maven 3.6.1's new option --no-transfer-progress to
> > reduce the log output. However, it is cumbersome to add this flag to
> every
> > maven invocation in codebase.
> > Just wanted to know if there's any way this setting can be made Global ??
> >
> > Regards,
> > Tarakesh
> >
>
>
> --
> Regards,
> Tomo
>
Re: Debugging spring-boot-maven-plugin in IntelliJ
This may not be the best solution, but when I need to debug into a maven plugin, I temporarily add the plugin to my project in compile scope. Then I can easily browse the source and IntelliJ will start hitting the debug breakpoints. Cheers, Greg Chabala On Thu, Feb 13, 2020 at 2:31 PM Jeeva Manivel wrote: > Hi all, > > I want to debug spring-boot-maven-plugin in IntelliJ. I have the source > code, But I do not see this spring-boot-maven-plugin.jar in dependencies in > Project Structure(because its not added as a dependency in pom.xml, its > added as a plugin). Please let me know how to attach the source and debug > this plugin. > > > > Thanks, > Jeeva >
Re: [ANN] Apache Maven JAR Plugin 3.2.0 Released
I would take that up with gcs-maven-mir...@googlegroups.com as noted here: https://storage-download.googleapis.com/maven-central/index.html On Sun, Nov 3, 2019 at 1:59 PM Anthony Whitford wrote: > > How can we get Google’s Central mirror fixed? > >
Re: Jenkins builds
Thanks for the reply , I understand the concept of the .m2 folder and generally how maven works. We run an Archiva server where we cache dependencies and publish our released artifacts etc etc. Although having a separate .m2 folder is quite possible and would address my issue, it’s something I’m trying to avoid for performance reasons. Pulling down all the external dependencies from Archiva, or central repository, for each project takes too long and takes up too much space. Our builds have a customer implementation component which means we have many builds for many customers. What I would like to have is a common .m2 folder for external dependencies, and a build specific .m2 folder with just the build output. Something like: ~/.m2/repository /log4j /commons-io /… $WORKSPACE1/.m2/repository /customer1-lib /build-lib /... $WORKSPACE2/.m2/repository /customer2-lib /build-lib /... That way I don’t have to pull down all the common stuff into a fresh .m2 for each build. > On May 19, 2017, at 5:36 PM, Karl Heinz Marbaise wrote: > > Hi Greg, > > On 19/05/17 19:12, Greg Parker wrote: >> I’m looking for a way to isolate builds from one another on our Jenkins >> server. > > What I would like to do is have a common .m2 folder > > for external dependencies. > > > For my own artifacts I’d like to install/retrieve > > them to/from a separate local repository. > > > I suspect that this capability does not exist, but I thought I would check. > > The first thing what you need to understand is that the $HOME/.m2/repository > is a cache location where the artifacts which are downloaded only cached to > prevent repeated downloads from remote repositories.. > > The first step is to separate build jobs in Jenkins means that each job has > it's own local cache directory which means having the local cache in the > workspace ($WORKSPACE/.repository)... > > The second step is having a repository manager (like Nexus, Artifactory or > Archiva) which handles the separation between the artifacts which are created > by your own and the ones you are consuming from outside (for example from > Maven Central).. > > There I would suggest to make this difference for your own artifacts and the > artifacts which you call "external"... > > > Kind regards > Karl Heinz Marbaise > > - > 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
Jenkins builds
I’m looking for a way to isolate builds from one another on our Jenkins server. What I would like to do is have a common .m2 folder for external dependencies. For my own artifacts I’d like to install/retrieve them to/from a separate local repository. I suspect that this capability does not exist, but I thought I would check. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Velocity - Archetypes Question
Hi Maria: It isn’t obvious from the documentation, but if you try creating an archetype following the instructions in http://maven.apache.org/archetype/maven-archetype-plugin/examples/create-multi-module-project.html, and look at the generated project, yes, it is velocity templates that are generated. Cheers, Greg Trasuk Web Age Solutions. http://www.webagesolutions.com > On Dec 3, 2015, at 8:44 PM, Maria Beckham > wrote: > > > > Hi there, > Are archetypes in maven by default based on velocity engine/templates > processing? > Thanks,Maria > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Installing on Solaris
I think Curtis has the right answer. And when you set JAVA_HOME, it should be pointing to the JDK, not the JRE installation - looks like that will be /export/home/e0857723/aaa_bonita/jdk17/jdk1.7.0_79 for you. Is it possible to have the admins upgrade the box to JDK7? Solaris has some strange indirection going on to make ‘java’ a basic command line task, (/usr/bin/java is a link to /usr//java/bin/java, which is a link to /usr/jdk/latest, etc) so you’ll be fighting the OS if you try to run a different version (although I think it should be do-able). Cheers, Greg Trasuk > On Nov 6, 2015, at 1:34 PM, Curtis Rueden wrote: > > Hi James, > > Probably you meant to set JAVA_HOME, not CLASSPATH. > > The JAVA_HOME variable points to your Java installation, whereas CLASSPATH > points to .jar files (and/or directories of .class files) you want to be > available to Java after it starts up. > > Regards, > Curtis > > On Fri, Nov 6, 2015 at 12:24 PM, james pruett wrote: > >> Greg, thanks for that. >> Yes, I downloaded SE Solaris Sparc 64bit version from where you >> mentioned... >> Note I am not admin but I read that it should still be possible for me to >> run java from userspace. >> >> Q: I set my CLASSPATH, but perhaps incorrectly >> >> % env | grep CLASSPATH >> >> CLASSPATH=/export/home/e0857723/aaa_bonita/jdk17/jdk1.7.0_79/jre/lib/sparcv9 >> >> % ls $CLASSPATH >> jspawnhelper libdcpr.so libj2gss.so libjava.so >>libjdgaSUNWffb.solibjsdt.so libmlib_image.so >> libsaproc.so libt2k.soserver >> >> >> mktpricing:/export/home/e0857723/aaa_bonita % javac -version >> Error: could not find libjava.so >> Error: Could not find Java SE Runtime Environment. >> >> >> >> mktpricing:/export/home/e0857723/aaa_bonita % which javac >> /export/home/e0857723/aaa_bonita/jdk17/jdk1.7.0_79/bin/javac >> >> >> I realize this is not a maven problem I am having but I am begging help >> help. >> I can go to Solaris help if you think necessary. >> >> Thanks for helping! >> jim >> >> >> >> >> On Fri, Nov 6, 2015 at 11:50 AM, Greg Trasuk >> wrote: >> >>> >>> Hi James: >>> >>> Based on your class path, it looks like you installed the “Java Runtime >>> Environment”. That’s just the Java virtual machine without the Java >>> Compiler. Maven is going to need the Java Compiler, so you’ll need to >> get >>> the Java SE version (Standard Edition, appears to be at >>> >> http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html >>> ). >>> >>> Having said that, it looks odd that it’s having trouble finding >>> ‘libjava.so’. There might be something funny about your JDK >> installation. >>> Maybe that gives you a place to start looking… >>> >>> Basically, before Maven has any chance at working, you need to make sure >>> that you can run ‘javac -version’ and it comes back with 1.7 or higher. >>> >>> Cheers, >>> >>> Greg Trasuk >>> http://www.webagesolutions.com >>> >>> >>>> On Nov 6, 2015, at 12:36 PM, james pruett wrote: >>>> >>>> Hi, >>>> >>>> I get this error. Any help appreciated. >>>> >>>> >>>> % mvn >>>> Error: could not find libjava.so >>>> Error: Could not find Java SE Runtime Environment. >>>> >>>> % env | grep -i CLASSPATH >>>> >>> >> CLASSPATH=/export/home/e0857723/aaa_bonita/jdk17/jdk1.7.0_79/jre/lib/sparcv9 >>>> >>>> >>>> % ls -las $CLASSPATH/libjava.so >>>> 524 -rwxrwxrwx 1267912 Apr 10 2015 >>>> >>> >> /export/home/e0857723/aaa_bonita/jdk17/jdk1.7.0_79/jre/lib/sparcv9/libjava.so >>> >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >>> >> - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Installing on Solaris
Hi James: Based on your class path, it looks like you installed the “Java Runtime Environment”. That’s just the Java virtual machine without the Java Compiler. Maven is going to need the Java Compiler, so you’ll need to get the Java SE version (Standard Edition, appears to be at http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html). Having said that, it looks odd that it’s having trouble finding ‘libjava.so’. There might be something funny about your JDK installation. Maybe that gives you a place to start looking… Basically, before Maven has any chance at working, you need to make sure that you can run ‘javac -version’ and it comes back with 1.7 or higher. Cheers, Greg Trasuk http://www.webagesolutions.com > On Nov 6, 2015, at 12:36 PM, james pruett wrote: > > Hi, > > I get this error. Any help appreciated. > > > % mvn > Error: could not find libjava.so > Error: Could not find Java SE Runtime Environment. > > % env | grep -i CLASSPATH > CLASSPATH=/export/home/e0857723/aaa_bonita/jdk17/jdk1.7.0_79/jre/lib/sparcv9 > > > % ls -las $CLASSPATH/libjava.so > 524 -rwxrwxrwx 1267912 Apr 10 2015 > /export/home/e0857723/aaa_bonita/jdk17/jdk1.7.0_79/jre/lib/sparcv9/libjava.so - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: War file name and sftp to server
403 error means “Forbidden”. The good news is - Maven deployer is obviously connecting to the Tomcat Manager app before it gets turned away for being unauthorized. So you’re 95% of the way there! The remote does a “HTTP PUT” request that contains the application that you’re trying to deploy. It just means Tomcat is saying “no”. The 403 means the Maven deployer client failed to authenticate to the Tomcat deployer application. I’m not sure the exact incantation to get it to work, but it probably has something to do with ‘conf/tomcat-users.xml’ in the tomcat folder. You need to create a user id that has the ‘manager-script’ role (more info in http://tomcat.apache.org/tomcat-7.0-doc/manager-howto.html#Deploy_A_New_Application_Archive_%28WAR%29_Remotely). You’ll also have to make the user id and password available to the Tomcat Maven plugin. Information on this appears to be at http://tomcat.apache.org/maven-plugin-2.0/tomcat7-maven-plugin/usage.html Sorry I can’t give you a more detailed answer, but hopefully that points you in the right direction. Cheers, Greg Trasuk > On Oct 9, 2015, at 3:29 PM, K R wrote: > > I do see this: > [09/Oct/2015:19:14:49 +] "PUT > /manager/deploy?path=%2FYT-100_ATU_Controller HTTP/1.1" 403 3196 > > > > > On Fri, Oct 9, 2015 at 9:39 AM, Wayne Fay wrote: > >> Also check for error messages on the Tomcat server side, in the Tomcat >> logs. >> >> Wayne >> On Oct 8, 2015 6:49 PM, "ke...@na7kr.us" wrote: >> >>> I tried tomcat plugin and it starts to upload and stops no error. >>> >>> >>> On October 8, 2015 2:13:18 PM tras...@stratuscom.com wrote: >>> >>> Check the Tomcat site for the Tomcat Maven plug-in. Not sure if it will >>>> use sftp, though. I believe it can use https. >>>> >>>> Cheers, >>>> >>>> Greg Trasuk. >>>> >>>> >>>> Sent from my BlackBerry 10 smartphone. >>>> Original Message >>>> From: ke...@na7kr.us >>>> Sent: Thursday, October 8, 2015 4:58 PM >>>> To: Maven Users List >>>> Reply To: Maven Users List >>>> Subject: Re: War file name and sftp to server >>>> >>>> Tomcat7 running on Raspberry Pi >>>> >>>> >>>> On October 8, 2015 1:36:53 PM Curtis Rueden wrote: >>>> >>>> Hi K R, >>>>> >>>>> How do I sftp it to the server? >>>>>> >>>>> >>>>> What kind of server? Web server? Maven repository? Something else? >>>>> >>>>> == Web server == >>>>> >>>>> If it's just a web server, typically that is done outside of the Maven >>>>> build. You can also rename the file at that point. Alternately, you can >>>>> use >>>>> the exec-maven-plugin to automate whatever steps you want during any >>>>> phase(s) of your Maven build. >>>>> >>>>> == Maven repository == >>>>> >>>>> If you want to transfer the final artifact to a Maven repository, this >> is >>>>> called "deploying" the artifact, and is done by Maven's deploy phase. >> You >>>>> have to configure the "wagon" plugin you want to use. For SFTP you'd >> use >>>>> wagon-ssh [1]. >>>>> >>>>> You have to add a distributionManagement section to your POM, and put >>>>> your >>>>> credentails in your ~/.m2/settings.xml. See: >>>>> https://maven.apache.org/plugins/maven-deploy-plugin/usage.html >>>>> >>>>> However, note that you cannot override the final name of the artifact >> in >>>>> your remote Maven repository, since Maven repos use a standard naming >>>>> scheme which includes the version suffix. >>>>> >>>>> == Something else == >>>>> >>>>> Feel free to elaborate on your question. ;-) >>>>> http://stackoverflow.com/help/how-to-ask >>>>> >>>>> Regards, >>>>> Curtis >>>>> >>>>> [1] https://maven.apache.org/wagon/wagon-providers/wagon-ssh/ >>>>> >>>>> On Thu, Oct 8, 2015 at 3:16 PM, K R wrote: >>>>> >>>>> I have this in pom.xml >>>>>> >>>>>> 0.0.1-SNAPSHOT >>>>>> YT-100_ATU_Controller >>>>>> >>>>>> and I get YT-100_ATU_Controller-0.0.1-SNAPSHOT.war how do I get >>>>>> YT-100_ATU_Controller.war? >>>>>> >>>>>> How do I sftp it to the server? >>>>>> >>>>>> >>>> >>>> >>>> - >>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: users-h...@maven.apache.org >>>> >>>> >>>> - >>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: users-h...@maven.apache.org >>>> >>>> >>> >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >>> >> - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: War file name and sftp to server
Hmm… that’s funny. You’d at least expect an error message. Could you try it with the -d for debug option on Maven? That might give you a better insight into why it doesn’t work. I realize you didn’t ask about the Tomcat Maven plugin, but that seems like the most direct approach to getting an app onto Tomcat. If that doesn’t work out, you could try the Maven AntRun plugin and use Ant’s scp task. Cheers, Greg Trasuk > On Oct 8, 2015, at 9:49 PM, ke...@na7kr.us wrote: > > I tried tomcat plugin and it starts to upload and stops no error. > > > On October 8, 2015 2:13:18 PM tras...@stratuscom.com wrote: > >> Check the Tomcat site for the Tomcat Maven plug-in. Not sure if it will use >> sftp, though. I believe it can use https. >> >> Cheers, >> >> Greg Trasuk. >> >> >> Sent from my BlackBerry 10 smartphone. >> Original Message >> From: ke...@na7kr.us >> Sent: Thursday, October 8, 2015 4:58 PM >> To: Maven Users List >> Reply To: Maven Users List >> Subject: Re: War file name and sftp to server >> >> Tomcat7 running on Raspberry Pi >> >> >> On October 8, 2015 1:36:53 PM Curtis Rueden wrote: >> >>> Hi K R, >>> >>>> How do I sftp it to the server? >>> >>> What kind of server? Web server? Maven repository? Something else? >>> >>> == Web server == >>> >>> If it's just a web server, typically that is done outside of the Maven >>> build. You can also rename the file at that point. Alternately, you can use >>> the exec-maven-plugin to automate whatever steps you want during any >>> phase(s) of your Maven build. >>> >>> == Maven repository == >>> >>> If you want to transfer the final artifact to a Maven repository, this is >>> called "deploying" the artifact, and is done by Maven's deploy phase. You >>> have to configure the "wagon" plugin you want to use. For SFTP you'd use >>> wagon-ssh [1]. >>> >>> You have to add a distributionManagement section to your POM, and put your >>> credentails in your ~/.m2/settings.xml. See: >>> https://maven.apache.org/plugins/maven-deploy-plugin/usage.html >>> >>> However, note that you cannot override the final name of the artifact in >>> your remote Maven repository, since Maven repos use a standard naming >>> scheme which includes the version suffix. >>> >>> == Something else == >>> >>> Feel free to elaborate on your question. ;-) >>> http://stackoverflow.com/help/how-to-ask >>> >>> Regards, >>> Curtis >>> >>> [1] https://maven.apache.org/wagon/wagon-providers/wagon-ssh/ >>> >>> On Thu, Oct 8, 2015 at 3:16 PM, K R wrote: >>> >>>> I have this in pom.xml >>>> >>>> 0.0.1-SNAPSHOT >>>> YT-100_ATU_Controller >>>> >>>> and I get YT-100_ATU_Controller-0.0.1-SNAPSHOT.war how do I get >>>> YT-100_ATU_Controller.war? >>>> >>>> How do I sftp it to the server? >>>> >> >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Copy-dependencies goal error
d then looks up the metadata for those dependencies, and so on, and so on. This is what people mean by “resolving dependencies”. In your case, your POM file is a little funny - rather than defining an artifact to build, it really exists only to define a set of dependencies and then call out the build plugin called "maven-dependency-plugin”, which is configured to copy the dependencies to the local file system. Here’s your key point - Maven resolves the dependencies even if your particular plugin configuration is not going to use them - the core maven package doesn’t care about the plugin configuration; it just does its thing, which is resolve dependencies. So even though your plugin configuration specifies “true”, Maven still goes to your Nexus repo and tries to track down those transitive dependencies. Your error message, [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) means that when Maven tried to resolve the dependencies for "org.apache.camel:apache-camel:zip:src:2.15.1”, the metadata for that artifact (which is in your repository) included a dependency on "org.jvnet.staxex:stax-ex”, but that artifact is not present in your repository. The short answer is that you need to get "org.jvnet.staxex:stax-ex” into your repository. It appears to be in Maven Central, so I’m guessing that your Nexus is configured not to act as a proxy to Maven Central. So you’ll need to either load it manually (or use “procurement”) or configure your Nexus to proxy Maven Central (unless of course you can’t do that for security or other reasons, which is why you’d go through procurement). Since you don’t actually care about the “stax-ex” dependency, you could theoretically load a “dummy” jar and pom that would satisfy the dependency, but that’s really bad practice - some other build might need the real dependency at a later time, so you’re best to get the right files into your repository. Hope this helps. Also, there’s a webinar I did for my employer that you might enjoy, Maven for Late Adopters (http://www.webagesolutions.com/webinars/registration.html?ApacheMavenLateAdopters). We also offer training and consulting. Cheers, Greg Trasuk > On Oct 5, 2015, at 5:02 PM, > wrote: > > There are no transitive dependencies! > > This is not even building source code!!! > > > Michael Tarullo > Contractor (Engility Corp) > Enterprise Architect > NSRR System Administrator > FAA WJH Technical Center > (609)485-5294 > > > -Original Message- > From: Jörg Schaible [mailto:joerg.schai...@gmx.de] > Sent: Monday, October 05, 2015 4:37 PM > To: users@maven.apache.org > Subject: RE: Copy-dependencies goal error > > 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
Re: maven jar versus ant jar
Hi Hector: Could you describe in very precise terms how you “installed it locally”? That might help us understand the problem. And perhaps you’ve already mentioned it, but what kind of jar file are you actually building? What does it get installed into? Cheers, Greg Trasuk > On Sep 2, 2015, at 10:37 AM, Magnanao, Hector wrote: > > I've done "mvn clean" several times and built again. It still keeps getting > packaged in my jar. The only difference with this dependency is that I > installed it locally. My pom just declares it as a dependency. Do I need to > clean up my .m2 directory to start fresh ? > > -Original Message- > From: Wayne Fay [mailto:wayne...@gmail.com] > Sent: Tuesday, September 01, 2015 5:31 PM > To: Maven Users List > Subject: Re: maven jar versus ant jar > > Try "mvn clean" first to be sure you didn't accidentally put the > contents of that jar file in target/ and forget about it. Then build > again. > > If it is still large and includes those files, there must be something > in your pom file that is causing it to occur. Very hard to debug your > build without seeing these details. > > Wayne > > On Tue, Sep 1, 2015 at 4:41 PM, Magnanao, Hector > wrote: >> I found out why my maven jar is much bigger. It looks like it's including a >> dependency jar inside the SNAPSHOT jar. I installed this jar locally so I >> can compile but now it's being included in the build itself. So how do I >> exclude it when I do a mvn package ? >> >> -Original Message- >> From: Tobias Hochgürtel [mailto:tobias.hochguer...@googlemail.com] >> Sent: Tuesday, September 01, 2015 3:35 PM >> To: Maven Users List >> Subject: Re: maven jar versus ant jar >> >> You can unpack the jar files to see what they include. This should help >> you to find out what they makes fat or slimmer as the other one. >> >> HTH >> Tobias >> >> Am 01.09.2015 um 22:29 schrieb Magnanao, Hector: >>> I was finally able to build my snapshot jar using maven after going thru >>> all the missing dependencies. But what I noticed is that the maven jar is >>> much larger than my ant jar. Can anybody tell me why this is so ? Should >>> they be different in sizes after converting the build to maven ? what >>> should I be looking for causes of differences ? >>> >>> Hector Magnanao Jr. >>> SCM Analyst >>> >>> Fieldglass, Inc. >>> O: (331) 702-6142 >>> M: (773) 474-3051 >>> hector.magna...@sap.com >>> www.fieldglass.com >>> >>> Fieldglass is now part of SAP >>> >>> This email contains confidential information. If you are not the intended >>> recipient, do not read, distribute or reproduce this transmission >>> (including any attachments). If you have received this email in error, >>> please notify the sender by email reply. >>> >>> >> >> -- >> Tobias Hochgürtel >> >> >> >> Tobias Hochgürtel >> Alt-Stralau 15 >> 10245 Berlin >> >> Tel. 03029 0493-39 >> Fax 03026 9488-22 >> E-Mail: tobias.hochguer...@googlemail.com >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> > > - > 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: snapshot build size difference
jar tvf abc.jar Cheers, Greg Trasuk > On Aug 26, 2015, at 2:09 PM, Magnanao, Hector wrote: > > So I was finally able to get a good snapshot jar build from maven. But I > noticed that the size of the maven build is bigger than the ant build. Does > anyone have any suggestions on how to compare or find out why this is so ? > > Hector Magnanao Jr. > SCM Analyst > > Fieldglass, Inc. > O: (331) 702-6142 > M: (773) 474-3051 > hector.magna...@sap.com > www.fieldglass.com > > Fieldglass is now part of SAP > > This email contains confidential information. If you are not the intended > recipient, do not read, distribute or reproduce this transmission (including > any attachments). If you have received this email in error, please notify the > sender by email reply. > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Properties Files
Converting projects to Maven is not always a direct process. You might want to check out the document below. It talks about a systematic approach to converting projects to Maven, based on the artifacts that are created. http://www.webagesolutions.com/knowledgebase/kb001-Converting-To-Maven.html <http://www.webagesolutions.com/knowledgebase/kb001-Converting-To-Maven.html> Cheers, Greg Trasuk > On Aug 18, 2015, at 10:02 AM, aalok singhvi wrote: > > It's a migration of an ant project. It's java project. Presently ant gets > build properties file on compile time. > On Aug 18, 2015 9:56 AM, "Ron Wheeler" > wrote: > >> What are you building? >> What language and technology stack? >> >> What are the properties files used for - run-time? If so, where do you >> want them to end up when you install your app? >> How are you installing it? >> >> Ron >> >> On 18/08/2015 7:02 AM, aalok singhvi wrote: >> >>> Hello, >>> >>> I have a properties files. I have a multi modules project >>> with 1 parent pom and approx 19 child modules. Where should >>> i be putting the properties files which can be consumed by all >>> the child modules. >>> >>> Thanks >>> >>> >> >> -- >> Ron Wheeler >> President >> Artifact Software Inc >> email: rwhee...@artifact-software.com >> skype: ronaldmwheeler >> phone: 866-970-2435, ext 102 >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >>
Re: Use 2 pom.xml files with different names
> On Aug 10, 2015, at 7:12 AM, Alex Ditu wrote: > > Hello, > > I want to use pom.xml files for my project with 2 different names: > pom.xml and pom2.xml. > In order to select wich one to execute/use I use -f like this: > (…snip…) > > P.S. Don't ask me why I want to use 2 pom files, if anyone encountered > this situation and knows how to deal with it, help will be much > appreciated :) > The problem is, it’s kind of like asking “When I try to drive on the railroad tracks with my car, I keep falling off the rails - has anyone else encountered this problem?” The fundamental concept of Maven is that an artifact is uniquely identified, and the pom file describes the artifact. As such, when Maven puts the artifact into the local repository, it follows the naming conventions. You might be better off to describe what you’re actually trying to achieve, and then we can suggest how to do that. Cheers, Greg Trasuk - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to fix this error?
Hi Simone: The error indicates that the build cannot find the artifact org.openiot:utils.commons:jar:0.0.1 in your local repository. That artifact appears to be built in a different module in the main project. I did 'git clone https://github.com/OpenIotOrg/openiot.git' <https://github.com/OpenIotOrg/openiot.git'> - I assume that’s where you started as well. You need to go to the top-level project folder (‘openiot’) and execute ‘mvn clean install’. That command will cause Maven to build the entire project and install the utility libraries in you local (~/.m2/repository) repository. Cheers, Greg Trasuk Open Source Stream Lead - Web Age Solutions (http://webagesolutions.com <http://webagesolutions.com/>) > On Jul 21, 2015, at 2:49 PM, Simone wrote: > > This is the error: > Failed to execute goal on project scheduler.core: Could not resolve > dependencies for project org.openiot:scheduler.core:war:0.0.1: The following > artifacts could not be resolved: org.openiot:utils.commons:jar:0.0.1, > org.openiot:lsm-light.client:jar:0.0.1: Failure to find > org.openiot:utils.commons:jar:0.0.1 in > http://maven.repository.redhat.com/techpreview/all was cached in the local > repository, resolution will not be reattempted until the update interval of > jboss-ga-repository has elapsed or updates are forced -> [Help1] > > Il 21/07/2015 20:28, Greg Trasuk ha scritto: >> Hi Simone: >> >> The mailing list appears to block screenshots. Could you copy/paste the >> text of the error message? >> >> Thanks, >> >> Greg Trasuk >>> On Jul 21, 2015, at 2:17 PM, Simone wrote: >>> >>> Hello >>> >>> My name is Simone Sciarretta, I am student at the University of Pisa in >>> the Communications Engineering Department >>> I am experimenting a problem with the OpenIoT platform, and particularly >>> when I am following the example of executing the command "mvn clean >>> package jboss-as:deploy" in the library scheduler.core >>> described in the deliverable D4.3.1. I get an error that restrict me to >>> create the file .war and I have not find the way to resolve this problem. >>> I am including a screen shot of the error and I will appreciate if you >>> can help me to understand and tell me what is the problem? >>> >>> If I have to enforce some changes in the repository or modify something >>> in th pom.xml file please let me know? >>> >>> In advance thank you very much for your help. >>> >>> Regards >>> >>> Simone Sciarretta >>> >>> >>> --- >>> Questa e-mail è stata controllata per individuare virus con Avast antivirus. >>> https://www.avast.com/antivirus >>> >>> >>> - >>> 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 >> > > > --- > Questa e-mail è stata controllata per individuare virus con Avast antivirus. > https://www.avast.com/antivirus > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org >
Re: How to fix this error?
Hi Simone: The mailing list appears to block screenshots. Could you copy/paste the text of the error message? Thanks, Greg Trasuk > On Jul 21, 2015, at 2:17 PM, Simone wrote: > > Hello > > My name is Simone Sciarretta, I am student at the University of Pisa in > the Communications Engineering Department > I am experimenting a problem with the OpenIoT platform, and particularly > when I am following the example of executing the command "mvn clean > package jboss-as:deploy" in the library scheduler.core > described in the deliverable D4.3.1. I get an error that restrict me to > create the file .war and I have not find the way to resolve this problem. > I am including a screen shot of the error and I will appreciate if you > can help me to understand and tell me what is the problem? > > If I have to enforce some changes in the repository or modify something > in th pom.xml file please let me know? > > In advance thank you very much for your help. > > Regards > > Simone Sciarretta > > > --- > Questa e-mail è stata controllata per individuare virus con Avast antivirus. > https://www.avast.com/antivirus > > > - > 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
