Re: publishing sub-modules without requiring the parent module to be published?

[Baptiste Mathus]

I'm pretty sure you can't. At least on Central who IIRC checks that kind of
things.
It's indeed needed for the dependency resolution mechanism to work.
Cheers
Le 11 oct. 2015 11:50 PM, "Kevin Burton"  a écrit :

> I'm trying to open source a bunch of code in our stack.
>
> Is it possible to have a parent module private, and the child module
> public?
>
> The problem I have now is that if our customers or the open source
> community imports our modules, it needs to fetch the parent, which is
> private.
>
> I assume this is required due to maven inheritance because it needs to
> determine dependencies.
>
> I can just not specify a  but that causes other problems like the
> maven versions problem skipping it for some reason (though maybe this is a
> bug).
>
>
>
> --
>
> We’re hiring if you know of any awesome Java Devops or Linux Operations
> Engineers!
>
> Founder/CEO Spinn3r.com
> Location: *San Francisco, CA*
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> 
>

publishing sub-modules without requiring the parent module to be published?

[Kevin Burton]

I'm trying to open source a bunch of code in our stack.

Is it possible to have a parent module private, and the child module public?

The problem I have now is that if our customers or the open source
community imports our modules, it needs to fetch the parent, which is
private.

I assume this is required due to maven inheritance because it needs to
determine dependencies.

I can just not specify a  but that causes other problems like the
maven versions problem skipping it for some reason (though maybe this is a
bug).



-- 

We’re hiring if you know of any awesome Java Devops or Linux Operations
Engineers!

Founder/CEO Spinn3r.com
Location: *San Francisco, CA*
blog: http://burtonator.wordpress.com
… or check out my Google+ profile

Submodule without parent can't be version:set in version plugin 2.2

[Kevin Burton]

I have a multi-module project where some of my modules don't have parents
referenced.

if I change to the directory of that module and then run:

mvn versions:set -DnewVersion=5.1.508

I get an exception (see below).

It seems to construct the path wrong.  It uses the name of the submodule
twice (you can see in the path below).

I think this is a bug... I think the issue is that I don't have it setup as
a normal submodule with a referenced 

This has worked in the past and I think it's a supported configuration.

For now I'm just using search/replace to bump my module versions but it's
somewhat annoying.

Is there a workaround or is this just a bug?

java.io.FileNotFoundException:
/home/burton/projects/parent_module/submodule/submodule (No such file or
directory)
at java.io.FileInputStream.open0(Native Method)
at java.io.FileInputStream.open(FileInputStream.java:195)
at java.io.FileInputStream.(FileInputStream.java:138)
at org.codehaus.plexus.util.xml.XmlReader.(XmlReader.java:124)
at
org.codehaus.plexus.util.xml.XmlStreamReader.(XmlStreamReader.java:67)
at
org.codehaus.plexus.util.ReaderFactory.newXmlReader(ReaderFactory.java:118)
at org.codehaus.mojo.versions.api.PomHelper.readXmlFile(PomHelper.java:1613)
at
org.codehaus.mojo.versions.AbstractVersionsUpdaterMojo.process(AbstractVersionsUpdaterMojo.java:319)
at org.codehaus.mojo.versions.SetMojo.execute(SetMojo.java:251)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)


-- 

We’re hiring if you know of any awesome Java Devops or Linux Operations
Engineers!

Founder/CEO Spinn3r.com
Location: *San Francisco, CA*
blog: http://burtonator.wordpress.com
… or check out my Google+ profile

RE: License Auditing

[Gary O'Neall]

Hi Jim,

 

Although it does not directly address your needs for license auditing, there is 
a plugin to produce SPDX documents containing detailed licensing information as 
part of a Maven goal.  Many of the scanning tools such as FOSSOlogy are 
generating (or planning to generate) SPDX documents (the version of FOSSOlogy 
to generate SPDX is currently in beta).  There are also a few commercial tools 
which generate SPDX.

 

By using the plugin, you could use a scanning tool which supports SPDX and the 
plugin to capture and maintain the licensing information.  SPDX currently 
maintains license information down to the source file level and maintains 
information on relationships to dependencies.  We are planning to support 
licensing information down to the code snippet level in release 2.1 of the 
spec.  

 

The plugin is in an "alpha" state and could use a bit more user testing before 
being broadly deployed.  The project is hosted on github at 
https://github.com/goneall/spdx-maven-plugin.

 

Information on SPDX can be found at http://spdx.org/ and a list of tools that 
support SPDX can be found at http://spdx.org/tools

 

Please let me know if you would like more information or have any feedback on 
this approach.

 

Thanks,
Gary O'Neall

 

 

 

From: Jim Klo [mailto:jim@sri.com] 
Sent: Monday, September 28, 2015 9:13 AM
To: Maven Users List
Subject: License Auditing

 

Hi, 

Looking for some guidance on doing some source license auditing.  My needs are 
two fold.  I need to track down all the licenses of all our dependencies, which 
there seems to be an abundance of plugins. But I also need to audit the 
licenses of our committed source, as many come from open and non-open projects, 
I need to track the individual files as well.

I’ve started by using Apache RAT [1], which seems to be okay for auditing the 
source, but given that we have a significant number of modules, configuration 
of RAT is somewhat a pain (I have a bunch of custom license definitions and 
matchers) which seem to have to be added to every POM file (doesn’t like going 
into the parent POM likely because of the way we are  using Tycho).

Can anyone recommend a plugin that might be better for my use case?  I’d like 
to be able to have a single config file (or artifact) that contains the license 
declarations, and then be able to reference that from all my modules.  The 
Codehaus License Maven Plugin [2] seems close to what I want, but I can’t seem 
to figure out how to get it to show me files that are missing license headers 
or even show me a per file license summary.  If anyone can point me to some 
examples or tutorials that explain this that would be much appreciated.

[1] 
http://creadur.apache.org/rat/apache-rat-plugin/examples/custom-license.html 


[2] 
http://www.mojohaus.org/license-maven-plugin/examples/example-thirdparty.html 


Thanks, 

JK 

Jim Klo 
Senior Software Engineer 
Center for Software Engineering 
SRI International 
t.  @nsomnac 

 

Hi,Looking for some guidance on doing some source 
license auditing.  My needs are two fold.  I need to track down all 
the licenses of all our dependencies, which there seems to be an abundance of 
plugins. But I also need to audit the licenses of our committed source, as many 
come from open and non-open projects, I need to track the individual files as 
well.I’ve started by using 
Apache RAT [1], which seems to be okay for auditing the source, but given that 
we have a significant number of modules, configuration of RAT is somewhat a 
pain (I have a bunch of custom license definitions and matchers) which seem to 
have to be added to every POM file (doesn’t like going into the parent POM 
likely because of the way we are  using Tycho).Can anyone recommend a plugin that might be better 
for my use case?  I’d like to be able to have a single config file (or 
artifact) that contains the license declarations, and then be able to reference 
that from all my modules.  The Codehaus License Maven Plugin [2] seems 
close to what I want, but I can’t seem to figure out how to get it to show me 
files that are missing license headers or even show me a per file license 
summary.  If anyone can point me to some examples or tutorials that 
explain this that would be much appreciated.[1] http://creadur.apache.org/rat/apache-rat-plugin/examples/custom-license.html";
 
class="">http://creadur.apache.org/rat/apache-rat-plugin/examples/custom-license.html[2] http://www.mojohaus.org/license-maven-plugin/examples/example-thirdparty.html";
 
class="">http://www.mojohaus.org/license-maven-plugin/examples/example-thirdparty.htmlThanks,JK

Jim KloSenior Software 
EngineerCenter for Software EngineeringSRI 
Internationalt.   
@nsomnac