Re: Strategies for augmenting jar manifest with source provenance info?
Look in META-INF/maven of the jars made with Maven, which should include a copy of pom.xml. Then just make sure your project has an updated block. Now what could be interesting is to include the exact git commit at point of packaging, which I believe could be possible to add using the release plugin..? (It already rewrites the scm tag of the pom). On 10 Nov 2016 11:35 pm, "KARR, DAVID" wrote: > I'm thinking of augmenting builds to add provenance info to the manifest > of the artifacts we produce, to indicate what git url the current artifact > is associated with (a "ContactInfo" tag might also be useful). Is this > something that anyone has ever tried to do? If so, what strategies have > you used? > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Strange result between "bundle" and "jar" type wrt javadoc and dependency resolution
Bundle is a special type used by the maven bundle plugin, which replaces the normal jar with one augmented with OSGi metadata. It is also possible to augment the replaced JAR further, e.g. shadow classes from other dependencies. When deployed, the result is still a *.jar, so it can be used as a jar dependency. To use the bundle dependency would require the maven bundle Plugin to intervene to still look up the jar, otherwise Maven would look for a *.bundle file, which would not exist in the maven repository. Therefore I think you should never need to specify bundle within a . httpclient-osgi is such a shadowed package, bundling several of the httpclient libraries. One thing to be careful with on this particular bundle is that it is not very useful from other Maven OSGi projects, as the httpclient-osgi pom also has transitive dependencies on the libraries which are also inside the httpclient-osgi jar. That might cause some confusion for Javadoc with duplicate classes, or problems I'd you get version mismatches. In https://github.com/apache/jena/blob/master/apache-jena-osgi/jena-osgi/pom.xml#L153 we therefore had to use lots of exclusions. Ironically the o e dependency of httpclient-osgi that *is* needed, httpcore-osgi, is NOT declared in the pom of httpclient-osgi, so that must also be added with similar exclusions. Now if your project is not itself an OSGi project and don't use bundle in its own pom, then you probably don't need httpclient-osgi and can exclude it and use the regular httpclient dependencies instead. On 28 Oct 2016 5:40 pm, "KARR, DAVID" wrote: > I have a subproject in a large multi-module project with the following > dependency: > -- > > org.apache.httpcomponents > httpclient-osgi > 4.5.2 > bundle > > -- > > The project builds without error. > > I was working on implementing Javadoc generation in this tree. When I ran > the "aggregate-jar" goal from the toplevel, it gave me an error saying it > couldn't find this artifact. This was initially mystifying (and still is > somewhat). > > We use an intranet Maven repo, so it's pulling from that instead of > mavencentral. When I looked in the repo itself, I noticed that it had that > artifact, but not the "bundle" type. It just had the plain jar (I assume I > would see something in the directory saying it was a bundle). > > When I looked in my local repo, it also only had the plain jar (I even > cleared out the local repo and reran the build to regenerate it). > > I then tried commenting out the "type" property and also cleared out that > section of the local repo. As before, the subproject built without error. > In addition, the toplevel Javadoc generation did not fail. > > It seems like the regular Maven dependency mechanism was happy with > getting just the "jar" artifact, even though the dependency specified the > "bundle" type, but the Javadoc generation would only work with the exact > type as specified. > > I don't know if there's a bug here, but there's certainly something odd > going on here. > > Can anyone explain what happened here? > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: embedded platform use maven
Sounds tricky, even if you get Maven and it's dependencies working with James, presumably you would also need javac to compile? Why do you want to compile Java code on the embedded platform? It should be more doable to package your application for jamvm using Maven, but doing that packaging on a regular JVM (Oracle, OpenJDK, IBM Java) On 18 Oct 2016 6:52 am, "Diaz Soho" wrote: > Hi , > > If my embedded platform can run jamvm for java applications. Is it > possible to run maven on the embedded platform for java application ? > > does maven provide .so shared library or classpath for java application? > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Comparing specifying repositories in pom vs. settings.xml?
Yes, some years ago we did exactly this; most academic open source projects then didn't bother with Maven Central and we relied on 8 different open repositories around the world, often with dubious hostnames like rpc268.cs.example.edu:8080 -- this meant that although the build was reproducible for everyone at the time; often just one year down the line those repositories might have gone offline and caused long timeouts - or worse, serve a generic HTML page no matter what you request, giving checksum errors. So now the build of the old tag would fail, but worse, released modules that ultimately had that project pom as parent also started failing as dependency in newer code because those are also consulted for transitive dependencies. (Even if that particular repo was not needed, Maven does not generally know which repo for which deps and consults all) So I would say, only add stable long-term repos to the parent pom, e.g. springsource or bintray repositories, while repo-of-the-day should be handled through a proxy Artifactory or Nexus server configured in .settings (enterprise) or top level pom (business open source), the proxy would then keep caches for a rainy day. Anything released open source should be pushed to Central (or at least a single place), even if it was made by someone who didn't bother themselves. On 18 Oct 2016 2:14 pm, "Curtis Rueden" wrote: > > I'm trying, without success, to imagine why you do not simply > > accumulate elements as required. > > Wouldn't that cause Maven to ping every server sequentially for every > needed artifact? > > Better to set up a Maven repository manager (Nexus, Artifactory, etc.) and > proxy all the needed sources, no? Then your settings.xml is always > constant, pointing at your master Nexus, which groups all your needed > repositories. Your build is reproducible and remains resilient to otherwise > disruptive remote repository changes -- as long as your master Nexus does > not change. > > > On Tue, Oct 18, 2016 at 8:03 AM, Mark H. Wood wrote: > > > On Mon, Oct 17, 2016 at 08:03:03PM +, KARR, DAVID wrote: > > > One thing I run into when jumping between different projects is > > different expectations for what maven repos I need to be using. In the > > past, I had to have multiple copies of "~/.m2/settings.xml" lying around, > > and I would hack the specified repos when I needed to. > > > > I'm trying, without success, to imagine why you do not simply > > accumulate elements as required. Before long you should reach > > a state in which new additions are extremely rare. > > > > -- > > Mark H. Wood > > Lead Technology Analyst > > > > University Library > > Indiana University - Purdue University Indianapolis > > 755 W. Michigan Street > > Indianapolis, IN 46202 > > 317-274-0749 > > www.ulib.iupui.edu > > >
Re: where to get xmldsig-1.0.jar
Are you sure you need xmldsig? http://docs.oracle.com/javase/6/docs/api/javax/xml/crypto/dsig/XMLSignature.html and friends has been part of JDK since 1.6, and the OpenJDK includes the org.jcp.xml.dsig implementation. You can also look at the Apache Santuario implementation which is licensed as Apache 2.0: https://santuario.apache.org/Java/api/org/apache/jcp/xml/dsig/internal/dom/DOMXMLSignature.html https://santuario.apache.org/ On 13 October 2016 at 04:02, Libby_li wrote: > Excuse me, do you know the license of xmldsig-1.0.jar? > Thanks~ > > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/where-to-get-xmldsig-1-0-jar-tp92435p5883040.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > -- Stian Soiland-Reyes http://orcid.org/-0001-9842-9718 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Status on namespace support for POM Elements ?
+1 to ALLOW (but not require) the second use case of , this let you have autocomplete say in Eclipse's XML editor. However I believe a xsi schemalocation would then still be needed per plugin unless a catalogue is accessible out of bands, so it would still be a bit verbose. (I never understood why the default xsi schemalocation can't be the namespace) On 5 Jun 2016 8:38 a.m., "Roland Huss" wrote: > > Do you really think introducing XML namespaces would make the handling > > of the pom better ? In particular if you have a separate namespace for > > every plugin? (At apache maven project we have 49 plugins ? This would > > mean in consequence 49 namespaces? And at mojohaus there are about > > another 50 plugins? So this means having to use the configuration > > parameters for all the plugins and on top you need to do namespace > > configuration in your pom file? I'm the opinion this would make things > > worse than better...(There are some things which are better)... > > I don't request to *require* the use of namespaces, but not to break if > a namespace is used. It would be competely sufficient when Maven would > ignore namespaces. The element is specified having a > content anyway. > > BTW, you don't have to specify the namespace on top, but can do at > directly on the enclosing element itself. > > Here's my use case: I'm writing a Maven plugin which has an XSD for its > configuration. This is useful for rich autocompletion and inline > documentation tooltips in a decent IDE. > > There are two ways how you could use this xsd: > > * You can declare a namespace with prefix in the preamble of your > pom.xml but then have to use the prefix for all your configuration > options (which is quite a lot in my use case). You are not required to > use a namespace, though (because of the type of a configuration) > > * Or, the better, more elegant way is to switch to the default namespace > to your plugin int the element : > > http://www.w3.org/2001/XMLSchema-instance"; > xmlns="http://maven.apache.org/POM/4.0.0"; > xsi:schemaLocation=""> > ... > > > xmlns:m="http://maven.apache.org/POM/4.0.0"; > xmlns="https://myplugin.org/v1";> > > bla > > > > ... > > > Both usage patterns are currently broken in Maven 3.3.9 > > > In general pom changes in any way could only become part of pom model 5 > > (Maven 4/5 in line) cause it would break to many things...You can take > > a deep look into the jira for Maven 4.. > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12330198 > > There is no change in the pom syntax required at all (i.e. the Schema is > exactly the same as defined in http://maven.apache.org/POM/4.0.0), its > only about the proper XML parsing of a pom model 4 with namespaces > (which btw each decent XML parser is capable of). > > But even then, is the document > > https://cwiki.apache.org/confluence/display/MAVEN/Moving+forward+with+the+POM+data+model > obsolete /wrt to XML namespaces ? Or what is the status of namespace > support for the next major Maven version ? (sorry, couldn't find any > information about this). > > cheers ... > ... roland > > > > > > > > > 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 > >
Re: Questions regarding License Maven Plugin
Hi, license-maven-plugin is not maintained by Apache, and have its own mailing list which should be able to help you further: http://www.mojohaus.org/license-maven-plugin/mail-lists.html Some documentation for each goal: http://www.mojohaus.org/license-maven-plugin/plugin-info.html On 26 May 2016 5:19 a.m., "Maxim Solodovnik" wrote: > Hello All, > > I'm trying to integrate license-maven-plugin and have couple of questions: > > 1) it seems like "aggregate-add-third-party" goal with "useMissingFile" > option is not generating "src/license/THIRD-PARTY.properties" files, is > this by design? > > 2) it seems "groupByLicense" option is not available for > "aggregate-add-third-party" > goal, maybe it can be added? > > 3) Is it possible to generate LICENSE file like [1] using this plugin? > > so there will be blocks like: > license name > affected libraries > license text > > > Thanks in advance for the answers :) > > [1] > > https://git-wip-us.apache.org/repos/asf?p=tomee.git;a=blob_plain;f=LICENSE;hb=HEAD > > -- > WBR > Maxim aka solomax >
Re: How to expand parent project properties in archetype?
Let me know if there is an easier way.. :)
As the velocity templates are first copied from src/main/resources to
target/classes - I ended up combining it with Maven Resource filtering
http://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html
And then I could actually do
${taverna.language.version}
${project.parent.version}
And use them as
\${taverna.osgi.version}
As there are then 3-4 systems all using $variables I had to use
\-escaping of the Velocity templates to prevent Maven Resources from
injecting too much, e.g.
\${groupId}
so that the velocity template in target/classes contains ${groupId}
and finally after running the archetype contains the user-provided
groupId.
On 16 May 2016 at 11:37, Stian Soiland-Reyes wrote:
> Hi,
>
> We have a sub-module that is a Maven Archetype.
>
> Within the generated pom.xml I want to set some for versions:
>
> https://github.com/apache/incubator-taverna-engine/blob/master/taverna-activity-archetype/src/main/resources/archetype-resources/pom.xml#L32
>
>
> However I don't want to have to hard-code the versions within the
> template pom.xml, but would rather want it to be inherited from the
> in the parent of the archetype - that is so it running
> the archetype would generate with actual version numbers
> - but in the template pom.xml it would be something like
>
> ${taverna.language.version}
>
>
> This is particularly important for our property taverna.engine.version
> which must stay in -SNAPSHOT during development to make the test work:
> https://github.com/apache/incubator-taverna-engine/tree/master/taverna-activity-archetype/src/test/resources/projects/dummyActivity
>
> ..but should change to a release version once releasing.
>
>
> How can I achieve this?
>
> I tried adding to META-INF/maven/archetype-metadata.xml
>
>
> ${project.parent.version}
>
>
> but then the test fails:
>
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-archetype-plugin:2.4:integration-test
> (default-integration-test) on project taverna-activity-archetype:
> [ERROR] Archetype IT 'dummyActivity' failed: Missing required
> properties in archetype.properties: tavernaEngineVersion
>
>
> obviously I can't just hard-code the version number in
> archetypes.properties - as that would just
> move the problem.
>
>
> Any ideas?
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating), Apache Commons RDF (incubating)
> http://orcid.org/-0001-9842-9718
--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
How to expand parent project properties in archetype?
Hi,
We have a sub-module that is a Maven Archetype.
Within the generated pom.xml I want to set some for versions:
https://github.com/apache/incubator-taverna-engine/blob/master/taverna-activity-archetype/src/main/resources/archetype-resources/pom.xml#L32
However I don't want to have to hard-code the versions within the
template pom.xml, but would rather want it to be inherited from the
in the parent of the archetype - that is so it running
the archetype would generate with actual version numbers
- but in the template pom.xml it would be something like
${taverna.language.version}
This is particularly important for our property taverna.engine.version
which must stay in -SNAPSHOT during development to make the test work:
https://github.com/apache/incubator-taverna-engine/tree/master/taverna-activity-archetype/src/test/resources/projects/dummyActivity
..but should change to a release version once releasing.
How can I achieve this?
I tried adding to META-INF/maven/archetype-metadata.xml
${project.parent.version}
but then the test fails:
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-archetype-plugin:2.4:integration-test
(default-integration-test) on project taverna-activity-archetype:
[ERROR] Archetype IT 'dummyActivity' failed: Missing required
properties in archetype.properties: tavernaEngineVersion
obviously I can't just hard-code the version number in
archetypes.properties - as that would just
move the problem.
Any ideas?
--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
