Re: Download an artifact and its dependencies without a pom.xml

[Manfred Moser]

I have a similar tool that can be used to provision from and to a repository. 

https://github.com/simpligility/maven-repository-tools/tree/master/maven-repository-provisioner

hth

Manfred

Curtis Rueden wrote on 2017-03-02 14:29:

> Hi everyone,
> 
>> My use case is that I want to run a class from a Maven artifact.
> 
> I turned my "synthesize a dummy POM" approach into a full-blown shell
> script called jrun [1].
> 
> You can use it to conveniently run Java code from any remote Maven
> repository. For example, to spin up the Jython REPL:
> 
>$ jrun org.python:jython-standalone
> 
> If you add the ImageJ Maven repository to your ~/.jrunrc:
> 
>[repositories]
>imagej.public = https://maven.imagej.net/content/groups/public
> 
> Then you can launch ImageJ (https://imagej.net/):
> 
>$ jrun net.imagej:imagej
> 
> Or even the entire Fiji distribution of ImageJ (https://fiji.sc/), which as
> of this writing consists of 346 components!
> 
>$ jrun sc.fiji:fiji:LATEST
> 
> All without explicitly downloading or installing anything apart from Maven
> and this one shell script [2].
> 
> If anyone knows a better / standard / best-practices way of doing this,
> please let me know! But I am pretty pumped about how convenient this is. I
> hope that jrun is useful to other developers too.
> 
> Regards,
> Curtis
> 
> P.S. If the Mojohaus devs are interested, perhaps we could fold in
> something like this as a new goal of the exec-maven-plugin.
> 
> [1] https://github.com/ctrueden/jrun
> 
> [2] Windows users need POSIX-compliant shell, though. I did not test it yet.
> 
> --
> Curtis Rueden
> LOCI software architect - https://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
> 
> 
> On Thu, Mar 2, 2017 at 9:50 AM, Curtis Rueden  wrote:
> 
>> Hi everyone,
>>
>> Is there an easy way to download an artifact and its dependencies to a
>> folder locally?
>>
>> * dependency:get will download a single artifact without needing a pom.xml.
>> * dependency:copy-dependencies will copy the dependencies of the current
>> project to a target location.
>>
>> But can these two functionalities be combined?
>>
>> My use case is that I want to run a class from a Maven artifact.
>>
>> The best I have come up with so far is to synthesize a dummy POM:
>>
>> g=org.scijava; a=scijava-common; v=RELEASE; m=org.scijava.script.ScriptREPL;
>> echo "4.0.0x> pId>x0<
>> dependencies>$g$a<
>> version>$v" > pom.xml;
>> mvn -DoutputDirectory=. dependency:copy-dependencies; rm pom.xml; java -cp
>> '*' "$m"
>>
>> Can this be done more elegantly?
>>
>> Thanks,
>> Curtis
>>
>> --
>> Curtis Rueden
>> LOCI software architect - https://loci.wisc.edu/software
>> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
>>
>>
> 


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

Re: Download an artifact and its dependencies without a pom.xml

[Curtis Rueden]

Hi everyone,

> My use case is that I want to run a class from a Maven artifact.

I turned my "synthesize a dummy POM" approach into a full-blown shell
script called jrun [1].

You can use it to conveniently run Java code from any remote Maven
repository. For example, to spin up the Jython REPL:

$ jrun org.python:jython-standalone

If you add the ImageJ Maven repository to your ~/.jrunrc:

[repositories]
imagej.public = https://maven.imagej.net/content/groups/public

Then you can launch ImageJ (https://imagej.net/):

$ jrun net.imagej:imagej

Or even the entire Fiji distribution of ImageJ (https://fiji.sc/), which as
of this writing consists of 346 components!

$ jrun sc.fiji:fiji:LATEST

All without explicitly downloading or installing anything apart from Maven
and this one shell script [2].

If anyone knows a better / standard / best-practices way of doing this,
please let me know! But I am pretty pumped about how convenient this is. I
hope that jrun is useful to other developers too.

Regards,
Curtis

P.S. If the Mojohaus devs are interested, perhaps we could fold in
something like this as a new goal of the exec-maven-plugin.

[1] https://github.com/ctrueden/jrun

[2] Windows users need POSIX-compliant shell, though. I did not test it yet.

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Thu, Mar 2, 2017 at 9:50 AM, Curtis Rueden  wrote:

> Hi everyone,
>
> Is there an easy way to download an artifact and its dependencies to a
> folder locally?
>
> * dependency:get will download a single artifact without needing a pom.xml.
> * dependency:copy-dependencies will copy the dependencies of the current
> project to a target location.
>
> But can these two functionalities be combined?
>
> My use case is that I want to run a class from a Maven artifact.
>
> The best I have come up with so far is to synthesize a dummy POM:
>
> g=org.scijava; a=scijava-common; v=RELEASE; m=org.scijava.script.ScriptREPL;
> echo "4.0.0x pId>x0<
> dependencies>$g$a<
> version>$v" > pom.xml;
> mvn -DoutputDirectory=. dependency:copy-dependencies; rm pom.xml; java -cp
> '*' "$m"
>
> Can this be done more elegantly?
>
> Thanks,
> Curtis
>
> --
> Curtis Rueden
> LOCI software architect - https://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
>
>

Re: Defining a property designed to be overridden?

[Curtis Rueden]

Hi,

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

My group uses "" a lot in IDEs including Eclipse, NetBeans
and IDEA, and it works for us. I suggest giving it a try and seeing if it
causes you any problems. Of course, in your case, since you have
multi-module builds, you probably actually _want_ the default behavior of
".." for your submodules, so maybe you don't want to change anything.

> Can a module name contain slashes?

Sure can! It's a relative directory path.

> I will give it a go. I've had somewhat poor experiences with the Maven
> APIs as they tend not to be documented too well.

Yeah, me too. I've found it pretty hard to get into Maven plugin
development, especially since the APIs have gone through a few major
iterations from 2.x to 3.0.x to 3.1.x etc. And in some cases, plugins mix
and match APIs from those different iterations. :-O

That said, this list (and the Maven dev list) is here for you. Others on
this list know a lot more about it, and can help you win awards.

> I may end up living with just not enforcing these things...

Well, since this rule is mostly for you yourself, and not some nebulous
cloud of community developers consuming your stuff, you can probably get
away with a nice shell script that calls grep over your POMs, and barfs
when various things are not found. Easy, right?

Regards,
Curtis

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


On Thu, Mar 2, 2017 at 1:34 PM,  wrote:

> On 2017-03-02T11:12:58 -0600
> Curtis Rueden  wrote:
>
> > Hi,
> >
> > > I'd need to think a bit more about it, but I personally dislike
> > > relativePath and have never used it (across hundreds of projects),
> > > pretty much for the sorts of reasons you've described. Hard-coding
> > > paths that represent links to other modules seems like a
> > > horrendously bad idea.
> >
> > That is fair. I will point out, though, that if you do not specify the
> > relativePath, then it is ".." by default. Best practice is to write
> > "" if you explicitly do _not_ want Maven to check for the
> > parent in the parent directory. Hence, if we implemented my
> requireElements
> > enhancement, the relativePath would be treated as ".." when one is not
> > explicitly specified.
>
> Right.
>
> I get the sense that adding  is something that would
> upset IDEs (my experience has been that they cope relatively poorly
> with anything uncommon like that).
>
> > I will also point out that each "" of a multi-module build is
> also
> > a hard-coded link to another module, which according to your reasoning,
> > makes multi-module projects in general a horrendous idea. (And I am not
> > being totally facetious here—I personally prefer never to use
> multi-module
> > projects at all. Though I would not go so far as to call them
> > "horrendous"—they definitely have their uses.)
>
> Hehe, I probably overstated it a touch. I tend to think of the 
> entries slightly differently though: I consider them to be module names
> that match the artifact ID of the submodule and also just happen to
> correspond to the directory that contains the module's sources. They
> don't inspire the same revulsion because they don't exist in my mental
> model as filesystem paths. I'm not actually sure they are in Maven's
> model either... Can a module name contain slashes?
>
> > > I've written a few plugins, but I'm not intimately familiar with the
> > > Maven API: Shouldn't it be possible to recursively retrieve the parent
> > > POMs from the reactor (and failing that, the local and remote
> > > repositories) within the plugin? That would remove the need for
> > > .
> >
> > Sure. You are absolutely welcome to file a PR against the
> > scijava-maven-plugin adding this feature. The complication is just that
> > instead of loading POMs from local files, you now also need to resolve
> them
> > from the appropriate remote repositories, for which there is certainly
> > Maven API, but I am also not familiar enough with it to tell you what it
> is
> > off the top of my head. Hopefully someone else here can comment in more
> > detail, and/or suggest alternative solutions here. In any case, if you
> > pursue this, it should work to test locally by installing the plugin into
> > your local repo cache using the "install" phase, and then using
> > "org.scijava:scijava-maven-plugin:1.0.1-SNAPSHOT" in your test POMs.
>
> I will give it a go. I've had somewhat poor experiences with the Maven
> APIs as they tend not to be documented too well. I may end up living
> with just not enforcing these things...
>
> M
>

Re: Defining a property designed to be overridden?

[org . apache . maven . user]

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

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

Right.

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

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

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

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

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

M


pgpNNHD4Cw4ln.pgp
Description: OpenPGP digital signature

Re: Defining a property designed to be overridden?

[Curtis Rueden]

Hi,

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

That is fair. I will point out, though, that if you do not specify the
relativePath, then it is ".." by default. Best practice is to write
"" if you explicitly do _not_ want Maven to check for the
parent in the parent directory. Hence, if we implemented my requireElements
enhancement, the relativePath would be treated as ".." when one is not
explicitly specified.

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

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

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

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Thu, Mar 2, 2017 at 11:02 AM,  wrote:

> On 2017-03-02T10:29:30 -0600
> Curtis Rueden  wrote:
>
> > > it seems that I can only require that the XML elements be overridden
> > > in *all* descendant POMs, and this introduces too much redundancy.
> >
> > I see.
> >
> > Would it be sufficient if the requireElements rule had a multiModule flag
> > which, if set, green-lighted the build when the stated elements are
> defined
> > in the local parent POM? This feature would assume you are using the
> > aggregator==parent scheme, and follow the  declared in the
> >  of each POM. If it finds a POM there, it would parse it and then
> > check for the required elements in _that_ POM instead of the initial one.
> > And do this recursively, in case you have a multi-layered multi-module
> > build.
> >
> > The downside of this approach: modules of a project would only build if
> the
> > parent is available locally. E.g.: if you try to build one module of a
> > multi-module build which has been physically disconnected from its parent
> > (e.g., a partial SVN checkout), the enforcer would fail because it would
> > not find the local parent POM to validate against. One can also imagine
> > various "aggegator != parent" organizations where the parent is not
> > available locally, which would also all fail to support this scheme.
> >
>
> I'd need to think a bit more about it, but I personally dislike
> relativePath and have never used it (across hundreds of projects),
> pretty much for the sorts of reasons you've described. Hard-coding
> paths that represent links to other modules seems like a horrendously
> bad idea.
>
> I've written a few plugins, but I'm not intimately familiar with the
> Maven API: Shouldn't it be possible to recursively retrieve the parent
> POMs from the reactor (and failing that, the local and remote
> repositories) within the plugin? That would remove the need for
> .
>
> If that is possible, then I think the pseudocode is:
>
>   let root(p) be the root POM of project p
>   let parent(p) be the parent of p
>   let definesElements(p) return true if p defines the required elements
>
>   Project q = p
>   while (!done) {
> if (q == root(p)) {
>   throw RequiredElementsMissing()
> }
>
> if (definesElements(q)) {
>   done = true
> }
>
> q = parent(p)
>   }
>
> This feels like it would achieve what I need with only minimal
> assumptions about the hierarchy of projects.
>
> M
>

Re: Defining a property designed to be overridden?

[org . apache . maven . user]

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

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

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

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

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

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

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

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

q = parent(p)
  }

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

M


pgp1IyM3UMFWw.pgp
Description: OpenPGP digital signature

Re: Defining a property designed to be overridden?

[Curtis Rueden]

> it seems that I can only require that the XML elements be overridden
> in *all* descendant POMs, and this introduces too much redundancy.

I see.

Would it be sufficient if the requireElements rule had a multiModule flag
which, if set, green-lighted the build when the stated elements are defined
in the local parent POM? This feature would assume you are using the
aggregator==parent scheme, and follow the  declared in the
 of each POM. If it finds a POM there, it would parse it and then
check for the required elements in _that_ POM instead of the initial one.
And do this recursively, in case you have a multi-layered multi-module
build.

The downside of this approach: modules of a project would only build if the
parent is available locally. E.g.: if you try to build one module of a
multi-module build which has been physically disconnected from its parent
(e.g., a partial SVN checkout), the enforcer would fail because it would
not find the local parent POM to validate against. One can also imagine
various "aggegator != parent" organizations where the parent is not
available locally, which would also all fail to support this scheme.

Thoughts?

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Thu, Mar 2, 2017 at 9:13 AM,  wrote:

> 'Ello.
>
> On 2017-03-02T08:16:43 -0600
> Curtis Rueden  wrote:
>
> > Hi,
> >
> > > I do actually want to enforce this, the issue is that I only want to
> > > enforce it as far as the first ancestor.
> >
> > Sorry if you stated otherwise in your writeup, but my understanding is
> that
> > you want to define some empty properties in your new root POM, and then
> > ensure they are _not_ empty in the next level down. Right?
>
> Yes, but additionally some XML elements as well.
>
> I'd like to enforce that:
>
>   1. Some properties that are defined as empty in the root POM are
>  non-empty in all descendants.
>
>   2. Some XML elements that are defined in the root POM (such as
>  issueManagement) are overridden _at least once_ between the root
>  and any leaf project.
>
> The requireProperty rule you provided does seem to properly handle point
> 1, but I think that the options we've discussed are too heavy-handed
> for point 2. Unless I've missed something obvious, it seems that I can
> only require that the XML elements be overridden in *all* descendant
> POMs, and this introduces too much redundancy.
>
> M
>

RE: [EXTERNAL] [ANN] Apache Maven Version 3.5.0-alpha-1 Released

[Justin Georgeson]

There's already MNG-5585 [1] for declaring credentials for authentication 
realms insettings.xml, so that Maven could choose the credentials that match 
the challenge by realm instead of hard coding the mapping of each  
to a .

[1] https://issues.apache.org/jira/browse/MNG-5585

-Original Message-
From: Andreas Sewe [mailto:s...@st.informatik.tu-darmstadt.de] 
Sent: Thursday, March 2, 2017 6:05 AM
To: users@maven.apache.org
Cc: Justin Georgeson 
Subject: Re: [EXTERNAL] [ANN] Apache Maven Version 3.5.0-alpha-1 Released

Stephen Connolly wrote:
> Can you create an issue against the MNG project in the issue tracker 
> and we will consider it from there

I'll leave that to Justin, as he has the need for this feature and can probably 
describe his requirements best:

  

I just pointed out that Eclipse Tycho already does something similar "on top 
of" Maven's setting.xml for repository mirrors. Would be great if the two 
mechanisms would be similar syntactically as well.

Best wishes,

Andreas


--
This e-mail, including any attached files, may contain confidential and 
privileged information for the sole use of the intended recipient.  Any review, 
use, distribution, or disclosure by others is strictly prohibited.  If you are 
not the intended recipient (or authorized to receive information for the 
intended recipient), please contact the sender by reply e-mail and delete all 
copies of this message.

Download an artifact and its dependencies without a pom.xml

[Curtis Rueden]

Hi everyone,

Is there an easy way to download an artifact and its dependencies to a
folder locally?

* dependency:get will download a single artifact without needing a pom.xml.
* dependency:copy-dependencies will copy the dependencies of the current
project to a target location.

But can these two functionalities be combined?

My use case is that I want to run a class from a Maven artifact.

The best I have come up with so far is to synthesize a dummy POM:

g=org.scijava; a=scijava-common; v=RELEASE;
m=org.scijava.script.ScriptREPL; echo
"4.0.0xx0$g$a$v"
> pom.xml; mvn -DoutputDirectory=. dependency:copy-dependencies; rm
pom.xml; java -cp '*' "$m"

Can this be done more elegantly?

Thanks,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden

Re: Defining a property designed to be overridden?

[org . apache . maven . user]

'Ello.

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

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

Yes, but additionally some XML elements as well.

I'd like to enforce that:

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

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

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

M


pgpx1cabVCYFf.pgp
Description: OpenPGP digital signature

Re: Defining a property designed to be overridden?

[Curtis Rueden]

Hi,

> I do actually want to enforce this, the issue is that I only want to
> enforce it as far as the first ancestor.

Sorry if you stated otherwise in your writeup, but my understanding is that
you want to define some empty properties in your new root POM, and then
ensure they are _not_ empty in the next level down. Right?

If so, then I think the requireProperty rule should be sufficient. You can
write:

  

  
  

  
org.apache.maven.plugins
maven-enforcer-plugin
1.4.1

  
enforce-property

  enforce


  

  io7m.previous.version
  You must define the io7m.previous.version
property!
  .+
  You must set the io7m.previous.version
property!

  
  true

  

  

  

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Thu, Mar 2, 2017 at 2:50 AM,  wrote:

> Hello!
>
> On 2017-03-01T15:49:10 -0600
> Curtis Rueden  wrote:
> >
> > If what you want is to ensure the property is simply non-empty, or
> matching
> > a particular regex, then take a look at the requireProperty enforcer rule
> > [1].
> >
> > Or if your goal is to make sure that a property value _differs_ from the
> > value defined in an ancestor, the requirePropertyDiverges rule [2] might
> be
> > for you.
>
> I do actually want to enforce this, the issue is that I only want to
> enforce it as far as the first ancestor. My current projects look like
> this (where indentation indicates inheritance):
>
>   + io7m-jtensors
> + io7m-jtensors-core
> + io7m-jtensors-tests
> + io7m-jtensors-ieee754b16
> + ...
>   + io7m-r2
> + io7m-r2-core
> + io7m-r2-shaders
> + ...
>
> I want to move to:
>
>   + io7m-ancestor
> + io7m-jtensors
>   + io7m-jtensors-core
>   + io7m-jtensors-tests
>   + io7m-jtensors-ieee754b16
>   + ...
> + io7m-r2
>   + io7m-r2-core
>   + io7m-r2-shaders
>   + ...
>
> So I want to enforce that io7m-jtensors and io7m-r2 override the
> required properties (and elements such as issueManagement), but I don't
> want to propagate that requirement to the individual submodules of
> io7m-jtensors such as io7m-jtensors-core, because this would introduce
> pointless redundancy. I have around 50 top-level projects to manage in
> this form, so any redundancy that can be eliminated really needs to be!
>
> I'm not sure the enforcer plugin is able to express this "only redefine
> once" aspect of the above. Am I wrong?
>
> M
>

Re: [EXTERNAL] [ANN] Apache Maven Version 3.5.0-alpha-1 Released

[Andreas Sewe]

Stephen Connolly wrote:
> Can you create an issue against the MNG project in the issue tracker and we
> will consider it from there

I'll leave that to Justin, as he has the need for this feature and can
probably describe his requirements best:

  

I just pointed out that Eclipse Tycho already does something similar "on
top of" Maven's setting.xml for repository mirrors. Would be great if
the two mechanisms would be similar syntactically as well.

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Re: [EXTERNAL] [ANN] Apache Maven Version 3.5.0-alpha-1 Released

[Stephen Connolly]

Can you create an issue against the MNG project in the issue tracker and we
will consider it from there

On 2 March 2017 at 08:24, Andreas Sewe 
wrote:

> Hi,
>
> > Any chance the Aether work would somehow enable declaring server
> credentials only once in settings.xml and then reusing them for multiple
> build.repositories.repository nodes in pom.xml (such as when you have
> multiple independent repositories within the same authentication realm of a
> single host)?
>
> FYI, Eclipse Tycho has recently (version 1.0.0) introduced a similar
> feature for sharing mirror settings for multiple repositories [1]. As
> the above feature request is similar (sharing settings for multiple
> repositories), the configuration syntax chosen by the Tycho developers
> (treating a URI repository/id specially) may serve as inspiration.
>
> Hope this helps,
>
> Andreas
>
> [1]
>  Authentication_and_Mirrors#Mirroring_multiple_Repositories>
>
>

Re: Defining a property designed to be overridden?

[org . apache . maven . user]

Hello!

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

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

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

I want to move to:

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

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

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

M


pgpqJtii9lFmz.pgp
Description: OpenPGP digital signature

Re: [EXTERNAL] [ANN] Apache Maven Version 3.5.0-alpha-1 Released

[Andreas Sewe]

Hi,

> Any chance the Aether work would somehow enable declaring server credentials 
> only once in settings.xml and then reusing them for multiple 
> build.repositories.repository nodes in pom.xml (such as when you have 
> multiple independent repositories within the same authentication realm of a 
> single host)? 

FYI, Eclipse Tycho has recently (version 1.0.0) introduced a similar
feature for sharing mirror settings for multiple repositories [1]. As
the above feature request is similar (sharing settings for multiple
repositories), the configuration syntax chosen by the Tycho developers
(treating a URI repository/id specially) may serve as inspiration.

Hope this helps,

Andreas

[1]




signature.asc
Description: OpenPGP digital signature