Re: svn commit: r1763929 - /maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java
Hi,
From what I checked, I don't think those plugins should be impacted
since they use the ArtifactInstaller directly, and not the ProjectInstaller.
But I can add an overload taking an ArtifactRepository which would get
the path to the artifact with "artifactRepository.pathOf(artifact)". And
then go with the one using the RepositoryManager or not, depending on
whether the ArtifactRepository is null or not.
Guillaume
Le 08/10/2016 à 22:11, Robert Scholte a écrit :
Hi Guillaume,
although this is often true, there are some plugins which create their
own local repository, for instance maven-invoker-plugin and
maven-dependency-plugin. In those cases you should pass the
ArtifactRepository.
So we will need those versions too, either as overloaded method or
restored where artifactRepository can be null.
thanks,
Robert
On Sat, 08 Oct 2016 20:43:58 +0200, wrote:
Author: gboue
Date: Sat Oct 8 18:43:58 2016
New Revision: 1763929
URL: http://svn.apache.org/viewvc?rev=1763929&view=rev
Log:
[MSHARED-595] In DefaultProjectInstaller, the path to the local
repository should be retrieved from the RepositoryManager
We need to rely on the RepositoryManager to get a hold of the local
repository base directory.
Modified:
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java
Modified:
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java
URL:
http://svn.apache.org/viewvc/maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java?rev=1763929&r1=1763928&r2=1763929&view=diff
==
---
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java
(original)
+++
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java
Sat Oct 8 18:43:58 2016
@@ -101,7 +101,7 @@ public class DefaultProjectInstaller
{
installer.install( buildingRequest,
Collections.singletonList( new ProjectArtifact( project ) ) );
-installChecksums( buildingRequest,
artifactRepository, artifact, createChecksum );
+installChecksums( buildingRequest, artifact,
createChecksum );
addMetaDataFilesForArtifact( artifactRepository,
artifact, metadataFiles, createChecksum );
}
}
@@ -120,7 +120,7 @@ public class DefaultProjectInstaller
if ( file != null && file.isFile() )
{
installer.install( buildingRequest,
Collections.singletonList( artifact ) );
-installChecksums( buildingRequest,
artifactRepository, artifact, createChecksum );
+installChecksums( buildingRequest, artifact,
createChecksum );
addMetaDataFilesForArtifact( artifactRepository,
artifact, metadataFiles, createChecksum );
}
else if ( !attachedArtifacts.isEmpty() )
@@ -139,7 +139,7 @@ public class DefaultProjectInstaller
for ( Artifact attached : attachedArtifacts )
{
installer.install( buildingRequest,
Collections.singletonList( attached ) );
-installChecksums( buildingRequest, artifactRepository,
attached, createChecksum );
+installChecksums( buildingRequest, attached,
createChecksum );
addMetaDataFilesForArtifact( artifactRepository,
attached, metadataFiles, createChecksum );
}
@@ -153,12 +153,12 @@ public class DefaultProjectInstaller
* the original POM file (cf. MNG-2820). While the plugin
currently requires Maven 2.0.6, we continue to hash the
* installed POM for robustness with regard to future changes
like re-introducing some kind of POM filtering.
*
+ * @param buildingRequest The project building request, must not
be null.
* @param artifact The artifact for which to create checksums,
must not be null.
* @param createChecksum {@code true} if checksum should be
created, otherwise {@code false}.
* @throws IOException If the checksums could not be installed.
*/
-private void installChecksums( ProjectBuildingRequest
buildingRequest, ArtifactRepository artifactRepository,
- Artifact artifact, boolean
createChecksum )
+private void installChecksums( ProjectBuildingRequest
buildingRequest, Artifact artifact, boolean createChecksum )
throws IOException
{
if ( !createChecksum )
@@ -166,7 +166,7 @@ public class DefaultProjectInstaller
return;
}
-File artifactFile = getLocalRepoFile( buildingRequest,
artifactRepository, artifact );
+File artifactFile = getLocalR
Re: svn commit: r1763929 - /maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java
Hi Guillaume,
although this is often true, there are some plugins which create their own
local repository, for instance maven-invoker-plugin and
maven-dependency-plugin. In those cases you should pass the
ArtifactRepository.
So we will need those versions too, either as overloaded method or
restored where artifactRepository can be null.
thanks,
Robert
On Sat, 08 Oct 2016 20:43:58 +0200, wrote:
Author: gboue
Date: Sat Oct 8 18:43:58 2016
New Revision: 1763929
URL: http://svn.apache.org/viewvc?rev=1763929&view=rev
Log:
[MSHARED-595] In DefaultProjectInstaller, the path to the local
repository should be retrieved from the RepositoryManager
We need to rely on the RepositoryManager to get a hold of the local
repository base directory.
Modified:
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java
Modified:
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java
URL:
http://svn.apache.org/viewvc/maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java?rev=1763929&r1=1763928&r2=1763929&view=diff
==
---
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java
(original)
+++
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java
Sat Oct 8 18:43:58 2016
@@ -101,7 +101,7 @@ public class DefaultProjectInstaller
{
installer.install( buildingRequest,
Collections.singletonList(
new ProjectArtifact( project ) ) );
-installChecksums( buildingRequest, artifactRepository,
artifact, createChecksum );
+installChecksums( buildingRequest, artifact,
createChecksum );
addMetaDataFilesForArtifact( artifactRepository,
artifact, metadataFiles, createChecksum );
}
}
@@ -120,7 +120,7 @@ public class DefaultProjectInstaller
if ( file != null && file.isFile() )
{
installer.install( buildingRequest,
Collections.singletonList( artifact ) );
-installChecksums( buildingRequest, artifactRepository,
artifact, createChecksum );
+installChecksums( buildingRequest, artifact,
createChecksum );
addMetaDataFilesForArtifact( artifactRepository,
artifact, metadataFiles, createChecksum );
}
else if ( !attachedArtifacts.isEmpty() )
@@ -139,7 +139,7 @@ public class DefaultProjectInstaller
for ( Artifact attached : attachedArtifacts )
{
installer.install( buildingRequest,
Collections.singletonList( attached ) );
-installChecksums( buildingRequest, artifactRepository,
attached, createChecksum );
+installChecksums( buildingRequest, attached, createChecksum
);
addMetaDataFilesForArtifact( artifactRepository, attached,
metadataFiles, createChecksum );
}
@@ -153,12 +153,12 @@ public class DefaultProjectInstaller
* the original POM file (cf. MNG-2820). While the plugin currently
requires Maven 2.0.6, we continue to hash the
* installed POM for robustness with regard to future changes like
re-introducing some kind of POM filtering.
*
+ * @param buildingRequest The project building request, must not be
null.
* @param artifact The artifact for which to create checksums, must
not be null.
* @param createChecksum {@code true} if checksum should be
created, otherwise {@code false}.
* @throws IOException If the checksums could not be installed.
*/
-private void installChecksums( ProjectBuildingRequest
buildingRequest, ArtifactRepository artifactRepository,
- Artifact artifact, boolean
createChecksum )
+private void installChecksums( ProjectBuildingRequest
buildingRequest, Artifact artifact, boolean createChecksum )
throws IOException
{
if ( !createChecksum )
@@ -166,7 +166,7 @@ public class DefaultProjectInstaller
return;
}
-File artifactFile = getLocalRepoFile( buildingRequest,
artifactRepository, artifact );
+File artifactFile = getLocalRepoFile( buildingRequest, artifact
);
installChecksums( artifactFile );
}
@@ -257,14 +257,14 @@ public class DefaultProjectInstaller
* Gets the path of the specified artifact within the local
repository. Note that the returned path need not exist
* (yet).
*
+ * @param buildingRequest The project building request, must not be
null.
* @param artifact The a
Re: [jira] [Commented] (MSHARED-594) NullPointerException is thrown when trying to install a project without POM file
Hi,
It is allowed by install:install-file when you set generatePom=false. It
would install for example a JAR without any POM. It is true that you
won't be able to depend on the artifact as-is... perhaps we should force
generatePom=true then?
This was a corner-case that I hit for
https://issues.apache.org/jira/browse/MINSTALL-128, and I wanted to keep
the current behaviour.
Guillaume
Le 08/10/2016 à 20:38, Karl Heinz Marbaise a écrit :
Hi Guillaume,
On 08/10/16 20:30, Guillaume Boué (JIRA) wrote:
When creating in-memory Maven projects with the {{ProjectBuilder}},
> it could not have a POM file: the intent is that
> it only has attached artifacts and only those should get installed.
Maybe I misunderstand a thing here...
But if the project has only attached artifacts and those artifacts
will be installed without a POM how should I ever use them ?
Kind regards
Karl Heinz Marbaise
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel
antivirus Avast.
https://www.avast.com/antivirus
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [jira] [Commented] (MSHARED-594) NullPointerException is thrown when trying to install a project without POM file
Hi Guillaume,
On 08/10/16 20:30, Guillaume Boué (JIRA) wrote:
When creating in-memory Maven projects with the {{ProjectBuilder}},
> it could not have a POM file: the intent is that
> it only has attached artifacts and only those should get installed.
Maybe I misunderstand a thing here...
But if the project has only attached artifacts and those artifacts will
be installed without a POM how should I ever use them ?
Kind regards
Karl Heinz Marbaise
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Warning when artifacts are downloaded over an insecure channel
I tried to write a patch for this, and I don't think this is really possible to do without introducing some sort of state in order to avoid duplicate messages, I also ran into the issue that a repository definition might not be used as it might be overridden by another definition, so issuing warnings when repository objects gets created isn't really possible. After looking around a bit and trying different things I came to the conclusion that the listeners might be a resonable place to hold this state and issue warnings, that might of course be totally wrong as I'm not very familiar with the code. I attached a patch that added a hash of domains that there has been a issued a warning about, so that maven doesn't warn twice about the same domain. The hash is not threadsafe, because as far as I understood the code the listeners doesn't run in multiple threads. It issues one warning per unique hostname that it downloads from. //Alex 2016-10-08 12:03 GMT+02:00 Alexander Kjäll : > I liked the idea to only issue warnings about repository urls and not > for every download, that would greatly reduce the amount of duplicated > information. > > I think it might be user friendly to inform when someone has > configured their project so that it disables the security model of > maven, but maybe a warning is to strong and it should rather be an > info level message? > > It might not be obvious to everyone that it's actually the security of > the transport layer that is a key feature, and if that is compromised > it's game over. For example at my place of work some thought that it > didn't matter with https since there was checksums of all the > artifacts. > > I agree that not all repositories have https, but now that lets > encrypt exists it's only a simple configuration tweak to add it, so I > think the improved security of adding https outweights the > inconvenience of it. > > //Alex > > 2016-10-08 11:34 GMT+02:00 Robert Scholte : >> It should be possible to run any build without a warning. We cannot assume >> that every http connection also has a https connection. Maven is only aware >> of one URL and that's the one to Central. This has already been changed to >> https. Other URL's are specified in the settings.xml, (direct) pom.xml and >> dependency-poms. The first two are managed by the end-user, he has set these >> values so he already should be aware of these values. >> The dependency poms (and plugin poms) are harder to discover and to control. >> For all cases having a repository manager is much easier to control >> connections. >> If there should be a warning, might be better to write an enforcer-rule for >> it and apply it on your own projects. >> >> Robert >> >> >> On Sat, 08 Oct 2016 00:49:36 +0200, Manfred Moser >> wrote: >> >>> The aether code is currently absorbed into Maven so you just need to hang >>> tight until thats done if you want to propose a code change. But its right >>> here to the same team. >>> >>> And regarding the warning ... such a warning would have to be disabled by >>> default otherwise it would litter the log for many existing builds causing >>> all sorts of issues. And then I am not sure it makes much sense. >>> >>> But say you go with a warning you would not want to warn for each >>> download but only for the first one to avoid excessive logging. So maybe >>> just warn for each specific repository URL once. >>> >>> Manfred >>> >>> Alexander Kjäll wrote on 2016-10-07 15:42: >>> Thats good feedback, I'll investigate the aether code and propose the same thing to them. I agree that some people might want to have their download unsecure, that's why I think that a warning is an appropriate level of notification regarding this. //Alex 2016-10-08 0:16 GMT+02:00 Michael Osipov : > > Am 2016-10-07 um 23:31 schrieb Alexander Kjäll: >> >> >> Hi >> >> I would like to propose that maven issues a warning when an artifacts >> gets downloaded over http instead of https. >> >> The current security model kind of relies on that noone MITM's the >> download and replaces the artifact and checksums with something >> malicious. That becomes impossible to guarantee when run over a >> transport layer that lacks security. >> >> I have attached a very crude patch that implements this behaviour, but >> I'm sure it needs to be reworked before it's ready to be merged. > > > > Basically, Aether should handle this, as you might plug other protocols > to > pull from: SFTP, FTPS, DAVS, etc. Additionally, if this happens in a > company, maybe people are quite fine with unsecure only. > > To sum up: we should wait when Aether transforms to Maven Artifact > Resolver. > > Michael > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional com
Re: is maven plugin project alive?
in addition, there is more than 40 plugins in this git mirror http://maven.apache.org/plugins/ (that's one of the reason for hesitating to migrate one svn repo with one CI job to 40 git repos with 40 CI jobs) 18 open PRs (I don't know in which state) for 40 plugins (and 76 closed): very good health from these statistics :) Now, if there is one precise Jira issue and/or PR that you are interested in, don't hesitate to work with us to help us merge (after assessing if this is the right direction to go) For people interested in an overview of the diverse content (core, plugins, libraries) maintained by Apache Maven project's community, you can have a look at our distribution review page, which show the state of our current 87 source release packages in our distribution area: https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/dist-tool-check-source-release.html Regards, Hervé Le samedi 8 octobre 2016 11:39:32 Robert Scholte a écrit : > Hi, > > it is not possible to merge these pullrequests at github, it is a > read-only clone. And in case of the plugins, they are still in a > subversion repository for a reason. > Personally I only look at Jira[1] for issues. If there's an issue > referring to a github pullrequest, that's the time to have a look at those > requests. > > Robert > > [1] https://issues.apache.org/jira/ > > On Sat, 08 Oct 2016 01:07:06 +0200, pabloa98 wrote: > > Hello > > > > https://github.com/apache/maven-plugins/pulls displays 18 pull requests. > > some of them so old like 2011. > > > > Is maven plugin project alive? Or should we move to gradle? :) > > > > Pablo > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Warning when artifacts are downloaded over an insecure channel
I liked the idea to only issue warnings about repository urls and not for every download, that would greatly reduce the amount of duplicated information. I think it might be user friendly to inform when someone has configured their project so that it disables the security model of maven, but maybe a warning is to strong and it should rather be an info level message? It might not be obvious to everyone that it's actually the security of the transport layer that is a key feature, and if that is compromised it's game over. For example at my place of work some thought that it didn't matter with https since there was checksums of all the artifacts. I agree that not all repositories have https, but now that lets encrypt exists it's only a simple configuration tweak to add it, so I think the improved security of adding https outweights the inconvenience of it. //Alex 2016-10-08 11:34 GMT+02:00 Robert Scholte : > It should be possible to run any build without a warning. We cannot assume > that every http connection also has a https connection. Maven is only aware > of one URL and that's the one to Central. This has already been changed to > https. Other URL's are specified in the settings.xml, (direct) pom.xml and > dependency-poms. The first two are managed by the end-user, he has set these > values so he already should be aware of these values. > The dependency poms (and plugin poms) are harder to discover and to control. > For all cases having a repository manager is much easier to control > connections. > If there should be a warning, might be better to write an enforcer-rule for > it and apply it on your own projects. > > Robert > > > On Sat, 08 Oct 2016 00:49:36 +0200, Manfred Moser > wrote: > >> The aether code is currently absorbed into Maven so you just need to hang >> tight until thats done if you want to propose a code change. But its right >> here to the same team. >> >> And regarding the warning ... such a warning would have to be disabled by >> default otherwise it would litter the log for many existing builds causing >> all sorts of issues. And then I am not sure it makes much sense. >> >> But say you go with a warning you would not want to warn for each >> download but only for the first one to avoid excessive logging. So maybe >> just warn for each specific repository URL once. >> >> Manfred >> >> Alexander Kjäll wrote on 2016-10-07 15:42: >> >>> Thats good feedback, I'll investigate the aether code and propose the >>> same thing to them. >>> >>> I agree that some people might want to have their download unsecure, >>> that's why I think that a warning is an appropriate level of >>> notification regarding this. >>> >>> //Alex >>> >>> 2016-10-08 0:16 GMT+02:00 Michael Osipov : Am 2016-10-07 um 23:31 schrieb Alexander Kjäll: > > > Hi > > I would like to propose that maven issues a warning when an artifacts > gets downloaded over http instead of https. > > The current security model kind of relies on that noone MITM's the > download and replaces the artifact and checksums with something > malicious. That becomes impossible to guarantee when run over a > transport layer that lacks security. > > I have attached a very crude patch that implements this behaviour, but > I'm sure it needs to be reworked before it's ready to be merged. Basically, Aether should handle this, as you might plug other protocols to pull from: SFTP, FTPS, DAVS, etc. Additionally, if this happens in a company, maybe people are quite fine with unsecure only. To sum up: we should wait when Aether transforms to Maven Artifact Resolver. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: is maven plugin project alive?
Hi, it is not possible to merge these pullrequests at github, it is a read-only clone. And in case of the plugins, they are still in a subversion repository for a reason. Personally I only look at Jira[1] for issues. If there's an issue referring to a github pullrequest, that's the time to have a look at those requests. Robert [1] https://issues.apache.org/jira/ On Sat, 08 Oct 2016 01:07:06 +0200, pabloa98 wrote: Hello https://github.com/apache/maven-plugins/pulls displays 18 pull requests. some of them so old like 2011. Is maven plugin project alive? Or should we move to gradle? :) Pablo - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Warning when artifacts are downloaded over an insecure channel
It should be possible to run any build without a warning. We cannot assume that every http connection also has a https connection. Maven is only aware of one URL and that's the one to Central. This has already been changed to https. Other URL's are specified in the settings.xml, (direct) pom.xml and dependency-poms. The first two are managed by the end-user, he has set these values so he already should be aware of these values. The dependency poms (and plugin poms) are harder to discover and to control. For all cases having a repository manager is much easier to control connections. If there should be a warning, might be better to write an enforcer-rule for it and apply it on your own projects. Robert On Sat, 08 Oct 2016 00:49:36 +0200, Manfred Moser wrote: The aether code is currently absorbed into Maven so you just need to hang tight until thats done if you want to propose a code change. But its right here to the same team. And regarding the warning ... such a warning would have to be disabled by default otherwise it would litter the log for many existing builds causing all sorts of issues. And then I am not sure it makes much sense. But say you go with a warning you would not want to warn for each download but only for the first one to avoid excessive logging. So maybe just warn for each specific repository URL once. Manfred Alexander Kjäll wrote on 2016-10-07 15:42: Thats good feedback, I'll investigate the aether code and propose the same thing to them. I agree that some people might want to have their download unsecure, that's why I think that a warning is an appropriate level of notification regarding this. //Alex 2016-10-08 0:16 GMT+02:00 Michael Osipov : Am 2016-10-07 um 23:31 schrieb Alexander Kjäll: Hi I would like to propose that maven issues a warning when an artifacts gets downloaded over http instead of https. The current security model kind of relies on that noone MITM's the download and replaces the artifact and checksums with something malicious. That becomes impossible to guarantee when run over a transport layer that lacks security. I have attached a very crude patch that implements this behaviour, but I'm sure it needs to be reworked before it's ready to be merged. Basically, Aether should handle this, as you might plug other protocols to pull from: SFTP, FTPS, DAVS, etc. Additionally, if this happens in a company, maybe people are quite fine with unsecure only. To sum up: we should wait when Aether transforms to Maven Artifact Resolver. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
