Re: Strategies for augmenting jar manifest with source provenance info?

[Bernd Eckenfels]

We are setting the manifest entries of the archiver to the project properties 
and the OSGi header.
https://maven.apache.org/shared/maven-archiver/examples/manifest.html

Gruss
Bernd
-- 
http://bernd.eckenfels.net




On Fri, Nov 11, 2016 at 10:35 PM +0100, "KARR, DAVID"  wrote:










> -Original Message-
> From: Stian Soiland-Reyes [mailto:st...@apache.org]
> Sent: Thursday, November 10, 2016 4:20 PM
> To: Maven Users List 
> Subject: 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.

I reposted a separate question on this, but perhaps I should have just 
continued this thread.  My problem with this approach is that I want to store 
this info in the very top-level POM, and have it be used in all of the 
subprojects.  I don't understand how to make that happen.

> 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
> >
> >

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

RE: Strategies for augmenting jar manifest with source provenance info?

[KARR, DAVID]

> -Original Message-
> From: Stian Soiland-Reyes [mailto:st...@apache.org]
> Sent: Thursday, November 10, 2016 4:20 PM
> To: Maven Users List 
> Subject: 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.

I reposted a separate question on this, but perhaps I should have just 
continued this thread.  My problem with this approach is that I want to store 
this info in the very top-level POM, and have it be used in all of the 
subprojects.  I don't understand how to make that happen.

> 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: Compiler plugin & JDK 9 & classpath/modulepath question

[Robert Scholte]

On Wed, 09 Nov 2016 13:24:02 +0100, Matej Novotny   
wrote:



Hello,

I was recently trying the following scenario with JDK 9 and mvn compiler  
3.6.0:
A new Maven project, with module-info, running with JDK 9, having a  
dependency on one other non-modular project (Weld SE in this case).
Feel free to inspect it on GH ->  
https://github.com/manovotn/JDK9Playground


Now compiling this with debug mode showed me that Maven puts the  
dependency onto module-path of the project.

This means JDK 9 will turn this into automatic module.
So I ended up adding entries (`requires` formulas) into module-info.java  
on the one dependency I have there.


I managed to make it compile in the end, but I was wondering about the  
following:
=> Is there a way to tell Maven, that I want to add this dependency (and  
all it brings in transitively) to CLASSPATH instead of module path?
  - that would effectively mean there would be no automatic module (so I  
wouldn't need to declare it in module-info) and instead if would "fall  
back" to unnamed module (=searching classpath)


Right now there's no simple way to do that. While working on the  
modulepath I assumed that once people add the module-info, that they would  
also use auto modules by default to get a 100% pure module instead a  
hybrid.
I've talked with the jigsaw team and there are still some issues with  
transitive (jigsaw) modules, which might effect the current implementation.


I think it is good to track this, so could you add a jira issue at  
https://issues.apache.org/jira/browse/MCOMPILER ?




 => Is there a way for Maven to automatically populate your module-info  
with entries regarding automatic modules? Or at least some kind of a  
detection for which ones do I need?


This is the ever returning question :) So in Java 9 jdeps is capable to  
generate a module-info template for you based on the code. It exports all  
packages, defines the requires and is often capable to detect which ones  
should be transitive, but is cannot detect the optionals. Be aware: this  
is a template, something to start with and which you MUST adjust. It is  
not an incremental tool.


Maven might create the "requires" part and know the optionals, but it  
cannot know about the transitivity (because it jigsaw transitive has a  
different definition than Maven transitive. They're still looking for a  
better keyword to prevent confusion, so any suggestion is welcome).


However, both Maven and the Jigsaw team need to come with a clear  
explanation, because dependencies and modules have different purposes.
I'll give it a try: dependencies resolve into coordinates of multiple  
files which will be added to the classpath (and with Java9 it could also  
be the module path). Having too much dependencies is not an issue, it is  
simply another jar on the path.
The "requires" of the module-info is there to enforce that certain files  
are available, either at compile time or at runtime.
So you can compare this as 2 partly overlapping circles. For the larger  
part is could be possible, but especially the parts that don't overlap are  
hard (impossible?) to identify.
It is very easy to add dependencies, but you never want any irrelevant  
"requires" inside your module-info.


I hope you understand that the purpose of dependencies and required  
modules are very different. Any attempt to try to solve this with magic is  
a potential failure. Any generated file must always be validated by the  
developer, there's no 1 to 1 translation.


Robert




Many thanks
Matej

-
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

First build in CI with Maven 3.0.5 gets bundle errors

[KARR, DAVID]

I'm working with a large multi-module project that produces OSGi artifacts.  I 
cloned it to my desktop, and it builds fine with maven 3.3.9.

Today I set up a Jenkins pipeline job to build it.  The first time I ran it, I 
saw errors like the following:
---
Invalid extension descriptor for org.apache.felix:maven-bundle-plugin:2.4.0: 
error in opening zip file
The build could not read 45 projects -> [Help 1]
  The project :: (.../pom.xml) has 1 error
Unknown packaging: bundle @ line 13, column 13
---

Note that this is using Maven 3.0.5.

Before I ask the CI admin to upgrade Maven, I'd like to understand these issues 
better.  Is this happening simply because I'm using an older Maven, or is there 
something else going on here?

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

[ANN] Apache Maven Doxia Sitetools 1.7.4 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Apache 
Maven Doxia Sitetools, version 1.7.4


Doxia Sitetools is an extension of base Doxia component that generates 
either  HTML sites, consisting of decoration and content that was 
generated by Doxia, or documents like RTF or PDF.


http://maven.apache.org/doxia/doxia-sitetools/

You can download the appropriate sources etc. from the download page:

http://maven.apache.org/doxia/doxia-sitetools/download.cgi



Release Notes - Maven Doxia Sitetools - Version 1.7.4

** Bug
* [DOXIASITETOOLS-171] - DefaultSiteRenderer must use 
Package#getImplementationVersion to check for Doxia Sitetools prerequisite



Enjoy,

-The Apache Maven team

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

How to put project information metadata into a top-level POM, and have it be part of generated effective POM in META-INF/maven tree?

[KARR, DAVID]

I work on a large multi-project build.  We produce a framework that other teams 
use.  Although all of the teams that use our framework know who we are, it 
occurred to me that it would be considerate to make sure that there is metadata 
in the generated artifact that would give someone information about the 
framework, or who might be responsible for it, assuming someone knew to look 
inside the artifact.

I'm aware of the various POM properties like "organization", "contributors", et 
cetera.  It would be great if I could fill out these properties in the 
top-level parent POM of the project and have those properties be set in all the 
effective POMs stored in the artifact jar of each subproject.

I tried a simple-minded test of setting the "organization/name" property in the 
top-level POM and building all of the artifacts.  Unsurprisingly, this didn't 
put that value into the generated subproject POM files.  What's the simplest 
way to store this information in a single place and have it appear in all of 
the subprojects?

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

Re: Strategies for augmenting jar manifest with source provenance info?

[Curtis Rueden]

Hi,

> what could be interesting is to include the exact git commit at point
> of packaging

Use the buildnumber-maven-plugin for this, together with maven-jar-plugin
manifestEntries config:

https://github.com/scijava/pom-scijava-base/blob/pom-scijava-base-1.0.0/pom.xml#L233-L238
https://github.com/scijava/pom-scijava-base/blob/pom-scijava-base-1.0.0/pom.xml#L383-L400

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
Did you know ImageJ has a forum? http://forum.imagej.net/


On Thu, Nov 10, 2016 at 6:38 PM, KARR, DAVID  wrote:

> > -Original Message-
> > From: Stian Soiland-Reyes [mailto:st...@apache.org]
> > Sent: Thursday, November 10, 2016 4:20 PM
> > To: Maven Users List 
> > Subject: 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.
>
> Ah, and even better would be the info about the people working on the
> project.  That looks like a good strategy.
>
> > 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).
>
> One step at a time. :)
>
> > 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
> > >
> > >
>