[jira] (MCOMPILER-240) Generated sources directory should not be added to compiler's source roots
[
https://jira.codehaus.org/browse/MCOMPILER-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362373#comment-362373
]
Dave Roberge commented on MCOMPILER-240:
+1 - we are using dagger on one of our projects (which uses annotation
processors) and using version 3.2 causes this issue
> Generated sources directory should not be added to compiler's source roots
> --
>
> Key: MCOMPILER-240
> URL: https://jira.codehaus.org/browse/MCOMPILER-240
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.2
> Environment: Apache Maven 3.2.5
> (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T18:29:23+01:00)
> Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
> Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
>Reporter: Tibor Varga
> Attachments: code-generation-test-case.tar.bz2,
> Generated_sources_directory_added_to_source_roots_after_compilation.patch
>
>
> I am using annotation processors with Maven and I keep getting errors when
> compiling with generated sources already present from a previous run.
> I have modified one of the test cases submitted for
> [MCOMPILER-157|http://jira.codehaus.org/browse/MCOMPILER-157] to induce the
> error by generating a source file _as source file_ rather than as a resource.
> Untar the test case and run {{mvn clean test -q && mvn test -q}} to verify.
> What I found is that {{AbstractCompilerMojo}} in version 3.2 of the compiler
> plugin adds the generated sources directory to the compiler's source root
> list, and that has two undesirable effects:
> # Sources generated in the previous run will be stale the next time around
> and cause recompilation.
> # The compiler will consider the previously generated source files to be
> initial inputs.
> The first one is mostly harmless but the second one is deadly, as it breaks
> the processing environment of the annotation processors.
> From the {{javax.annotation.Filer}} documentation in JDK 8:
> bq. "During each run of an annotation processing tool, a file with a given
> pathname may be created only once. Any subsequent attempt to create the same
> file during a run will throw a FilerException [...] The initial inputs to the
> tool are considered to be created by the zeroth round; therefore, attempting
> to create a source or class file corresponding to one of those inputs will
> result in a FilerException."
> Thus by adding the generated sources directory to the compiler's source
> roots, the compiler plugin causes annotation processors to inadvertently
> break their contract with the compiler.
> I get the expected behavior when lines 511-540 in {{AbstractCompilerMojo}}
> are moved after the compiler invocation, say to line 806. See the attached
> patch.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5723) Maven downloads same artifact from all repositories defined in POM
[ https://jira.codehaus.org/browse/MNG-5723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=356767#comment-356767 ] Dave Roberge commented on MNG-5723: --- Apologies, yes versions 3.1-3.2.3 are using aether version 0.9.0.M2, and master is now on 1.0.0.v20140518. The bug was resolved in aether version 0.9.0.M3 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=413880). Another thing I didn't mention, this only seems to trigger if the updatePolicy is set to 'always' AND it has to be set on the second repository element. > Maven downloads same artifact from all repositories defined in POM > -- > > Key: MNG-5723 > URL: https://jira.codehaus.org/browse/MNG-5723 > Project: Maven > Issue Type: Bug >Affects Versions: 3.2.1, 3.2.2, 3.2.3 >Reporter: Ruchir Sachdeva > > I have defined 2 repositories in pom.xml like below. One is public and other > is thirdparty. > > > public > Nexus - Public Repositories > default > http://mavenrepo.aaa.net/nexus/content/groups/public > > true > > > false > > > > thirdparty > Nexus - Third Party > default > > http://mavenrepo.aaa.net/nexus/content/repositories/thirdparty > > true > always > > > false > > > > Say there is a dependency called grpId:artId:1.1.0 which I have defined in my > pom. This dependency is present in both the repositories defined above- > public and thirdparty > When I run mvn install I see different behaviours in the way maven downloads > the grpId:artId:1.1.0 artifact based on the version of maven i am using. > Behaviours :- > **1. Using Maven 3.1 and previous versions** > > - **a.** Maven looks up the dependency grpId:artId:1.1.0 in 'public' repo > - **b.** Maven finds the dependency and downloads it. > - **c.** Maven does not look up the dependency grpId:artId:1.1.0 in >'thirdparty' repo as it is already downloaded from previous repository. > **2. Using Maven 3.2** > > - **a.** Maven looks up the dependency grpId:artId:1.1.0 in 'public' repo > - **b.** Maven finds the dependency in 'public' repo and downloads it. > - **c.** Maven again looks up the dependency grpId:artId:1.1.0 in >'thirdparty' repo even though it is already downloaded from 'public' > repository. > - **d.** Maven finds the dependency in 'thirdparty' repo and downloads it >and overwrites the dependency downloaded from 'public' repo previously > I wonder why maven is behaving in an absurd manner for maven-3.2. It should > stop looking further for the dependency which is already resolved and > downloaded from one repository . > Is there a way to achieve it using maven 3.2 ? -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5723) Why does maven 3.2 download same artifact multiple times from all repositories defined in pom ?
[
https://jira.codehaus.org/browse/MNG-5723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=356737#comment-356737
]
Dave Roberge commented on MNG-5723:
---
Hey, I believe I was able to reproduce the behavior. I created a simple maven
project, and declared 2 repositories in the pom as follows:
{code}
thirdparty
Third Party
http://localhost:8081/nexus/content/repositories/thirdparty/
always
test
Test Repo
http://localhost:8081/nexus/content/repositories/my-test1/
{code}
I created a dummy artifact and deployed it to each of those repos, then added
it as a dependency to the pom.
Using maven 3.1, I did a clean install and was able to see the artifact get
downloaded from both repositories. If you delete the dummy artifact from the
local repository and then build again, you will see the same result.
I observed the behavior in versions 3.1-3.2.3. Building the project with
3.2.4-SNAPSHOT appears to fix the problem.
>From what I found, it was fixed with this commit:
>http://git.eclipse.org/c/aether/aether-core.git/commit/aether-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java?id=c61f6cc18bd804441c5a41a21ee44f9f78f1c9ad
> Why does maven 3.2 download same artifact multiple times from all
> repositories defined in pom ?
> ---
>
> Key: MNG-5723
> URL: https://jira.codehaus.org/browse/MNG-5723
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.2.1, 3.2.2, 3.2.3
>Reporter: Ruchir Sachdeva
>
> I have defined 2 repositories in pom.xml like below. One is public and other
> is thirdparty.
>
>
> public
> Nexus - Public Repositories
> default
> http://mavenrepo.aaa.net/nexus/content/groups/public
>
> true
>
>
> false
>
>
>
> thirdparty
> Nexus - Third Party
> default
>
> http://mavenrepo.aaa.net/nexus/content/repositories/thirdparty
>
> true
> always
>
>
> false
>
>
>
> Say there is a dependency called grpId:artId:1.1.0 which I have defined in my
> pom. This dependency is present in both the repositories defined above-
> public and thirdparty
> When I run mvn install I see different behaviours in the way maven downloads
> the grpId:artId:1.1.0 artifact based on the version of maven i am using.
> Behaviours :-
> **1. Using Maven 3.1 and previous versions**
>
> - **a.** Maven looks up the dependency grpId:artId:1.1.0 in 'public' repo
> - **b.** Maven finds the dependency and downloads it.
> - **c.** Maven does not look up the dependency grpId:artId:1.1.0 in
>'thirdparty' repo as it is already downloaded from previous repository.
> **2. Using Maven 3.2**
>
> - **a.** Maven looks up the dependency grpId:artId:1.1.0 in 'public' repo
> - **b.** Maven finds the dependency in 'public' repo and downloads it.
> - **c.** Maven again looks up the dependency grpId:artId:1.1.0 in
>'thirdparty' repo even though it is already downloaded from 'public'
> repository.
> - **d.** Maven finds the dependency in 'thirdparty' repo and downloads it
>and overwrites the dependency downloaded from 'public' repo previously
> I wonder why maven is behaving in an absurd manner for maven-3.2. It should
> stop looking further for the dependency which is already resolved and
> downloaded from one repository .
> Is there a way to achieve it using maven 3.2 ?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MDEPLOY-131) use default repository when no url specified
[
https://jira.codehaus.org/browse/MDEPLOY-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=329483#comment-329483
]
Dave Roberge commented on MDEPLOY-131:
--
Hey, I'm attempting to implement this, and am hoping to get some feedback. I
ran into an issue when writing a test in DeployFileMojoTest. I created a
plugin-config.xml file similar to the others for deploy-file goal, it looks
like:
{code}
false
deploy-test
Test Repository
file://${basedir}/target/remote-repo/deploy-file-dist-mgmt
default
maven-deploy-plugin
...
${basedir}/src/test/resources/unit/deploy-file-dist-mgmt/plugin-config.xml
...
{code}
The problem is that basedir variable in distribution management section is not
interpolated when being read in so it installs the artifact at the root of the
filesystem. Does anyone have ideas on how fix that, or should I look for
alternative approaches?
> use default repository when no url specified
>
>
> Key: MDEPLOY-131
> URL: https://jira.codehaus.org/browse/MDEPLOY-131
> Project: Maven 2.x and 3.x Deploy Plugin
> Issue Type: Improvement
> Components: deploy:deploy-file
>Reporter: raymond domingo
> Labels: contributers-welcome
> Attachments: DeployFileMojo.java, patch_deploy_file_mojo.diff
>
>
> When using the deploy goal there is no need to specify the url of the
> repository.
> When using deploy-file you DO need to specify the url. This is a problem,
> because during development I like to deploy to snapshot repository and when
> releasing i deploy to release repository and I can't add this logic to the
> pom.
> Thas is why I like the url paramter to become optional (backwards compatible)
> and add default behaviour when it is null. It should just like the deploy
> plugin use the default repository. Snapshot for snapshots and release for
> none snapshot versions.
> I added a patch file fixing this.
> I also added complete source of patched Mojo
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-106) Remember the Dry Run Status
[ https://jira.codehaus.org/browse/MRELEASE-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Roberge updated MRELEASE-106: -- Attachment: 0002-MRELEASE-106-Provided-reasonable-failure-message-whe.patch I implemented a new perform phase to check whether dry run was set to true when preparing release. This patch is dependent on the previous patch file. I attempted to write an integration test using the invoker plugin, but discovered it may not be possible because the build fails. From what I could tell, the plugin is meant to verify successful builds. If anyone has a suggestion for how I might go about writing an integration test for this, I'm happy to look into it. > Remember the Dry Run Status > --- > > Key: MRELEASE-106 > URL: https://jira.codehaus.org/browse/MRELEASE-106 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare >Affects Versions: 2.0-beta-4 > Environment: Release plugin snapshot 20060509.101136-3, Subversion >Reporter: Bob Allison >Priority: Minor > Labels: contributers-welcome > Fix For: Backlog > > Attachments: 0001-MRELEASE-106-Remember-the-dry-run-status.patch, > 0002-MRELEASE-106-Provided-reasonable-failure-message-whe.patch > > > When doing a dry run of a release, make note of that in the > release.properties file so that a reasonable "failure" can occur if the user > tries to perform the release. Also, this flag might be used to allow a > non-dry-run prepare to occur without needing to do a clean in between (maybe > also not need to prompt but reuse the same answers as in the dry run). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-106) Remember the Dry Run Status
[ https://jira.codehaus.org/browse/MRELEASE-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Roberge updated MRELEASE-106: -- Attachment: 0001-MRELEASE-106-Remember-the-dry-run-status.patch Hi, I took a first pass at this issue. I was also going to attempt to implement a better failure message if user tries to perform release. > Remember the Dry Run Status > --- > > Key: MRELEASE-106 > URL: https://jira.codehaus.org/browse/MRELEASE-106 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare >Affects Versions: 2.0-beta-4 > Environment: Release plugin snapshot 20060509.101136-3, Subversion >Reporter: Bob Allison >Priority: Minor > Labels: contributers-welcome > Fix For: Backlog > > Attachments: 0001-MRELEASE-106-Remember-the-dry-run-status.patch > > > When doing a dry run of a release, make note of that in the > release.properties file so that a reasonable "failure" can occur if the user > tries to perform the release. Also, this flag might be used to allow a > non-dry-run prepare to occur without needing to do a clean in between (maybe > also not need to prompt but reuse the same answers as in the dry run). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
