[jira] [Created] (MNG-6616) Create public API for Projects Artifacts Cache where one project can be invalidated
Balazs Zsoldos created MNG-6616: --- Summary: Create public API for Projects Artifacts Cache where one project can be invalidated Key: MNG-6616 URL: https://issues.apache.org/jira/browse/MNG-6616 Project: Maven Issue Type: Wish Components: Bootstrap & Build Affects Versions: 3.6.0 Reporter: Balazs Zsoldos By introducing the Projects Artifact Cache, single builds became faster. However, there are tools that embed Maven and do not restart the complete JVM process between builds: M2E, mvnsh, etc. These tools cannot force the refresh of project artifacts currently based on a stable public API of Maven. It would be nice if there was a public stable API, where projects could be invalidated in the cache even one-by-one, so the recompilation of a project would be the fastest possible. In case of designing such an API, it should not be only about project artifacts cache, so if new caches introduced later by maven internally, the API should invalidate the project-specific records in all of them. I mean that the API interface should not be called ProjectArtifactCache, but more like ProjectCache, where the first current implementation would invalidate records in ProjectArtifactCache, but later if new caches are introduced, the same API call would manage those caches, too. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-3655) Allow multiple local repositories
[ https://issues.apache.org/jira/browse/MNG-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14630991#comment-14630991 ] Balazs Zsoldos commented on MNG-3655: - Another use-case: We use Gitlab with Gitlab-CI. Gitlab-CI compiles every commit and merges requests within a docker container. As the docker container is empty, every artifact is downloaded again and again. I could use the following solution: - Configure Maven to have a different local repo for the artifacts downloaded from Maven Central - The separate local repo would be placed on a shared folder coming from the host machine By having this solution, the artifacts that are coming from Maven Central, should not be downloaded multiple times. Not downloading the resources again and again is good for the environment ;-) > Allow multiple local repositories > - > > Key: MNG-3655 > URL: https://issues.apache.org/jira/browse/MNG-3655 > Project: Maven > Issue Type: New Feature > Components: Reactor and workspace >Reporter: Ittay Dror > Fix For: Issues to be reviewed for 4.x > > > In some environments, branches are rarely used. This means that if a > developer wishes to work in parallel on two features, he checks out HEAD into > two different locations. The problem is that using 'mvn install' in one > checkout will overwrite the result of 'mvn install' in another. Of course one > can write poms so that the version contains some classifier and then use 'mvn > -Dartifact-classifier=first-checkout install', or, read from a file. Both are > tedious. > Instead, it would be good to be able to tell maven to first consider some > path under the checkout before trying a global local repository (for external > artifacts). > To make this work when running mvn from a module subdir, maybe allow to write > settings.xml in the root directory of the checkout. Then, maven should climb > the directory structure until locating settings.xml (or reaching the global > root directory) and read there. Using settings.xml in such a way has other > benefits that it can be under version control. settings.xml will then be able > to specify a list of local repositories, some absolute paths, some relative > to it. > Another approach could be to allow this list of local repositories in the > global settings.xml file and have an entry in each module's pom indicating > where it is relative to the local repository (like the parent path attribute) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MINDEXER-97) Add OSGi 5.0 MANIFEST headers to OsgiArtifactIndexCreator
Balazs Zsoldos created MINDEXER-97: -- Summary: Add OSGi 5.0 MANIFEST headers to OsgiArtifactIndexCreator Key: MINDEXER-97 URL: https://issues.apache.org/jira/browse/MINDEXER-97 Project: Maven Indexer Issue Type: Improvement Reporter: Balazs Zsoldos It would be extremely useful if the following MANIFEST headers were added to the index: - Require-Capability - Provide-Capability - DynamicImport-Package Especially the first two would be necessary to be able to build up a database that helps finding dependencies for unsatisfied bundles. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] (MPLUGIN-191) plugin-info.html is not created
Balazs Zsoldos created MPLUGIN-191: -- Summary: plugin-info.html is not created Key: MPLUGIN-191 URL: https://jira.codehaus.org/browse/MPLUGIN-191 Project: Maven 2.x Plugin Tools Issue Type: Bug Components: Plugin Plugin Affects Versions: 2.9 Environment: Maven 3.x Reporter: Balazs Zsoldos Priority: Critical During running maven-plugin-plugin:report the following exception occurs: Caused by: java.lang.NoClassDefFoundError: org/apache/maven/doxia/module/xhtml/decoration/render/RenderingContext at org.apache.maven.reporting.sink.SinkFactory.createSink(SinkFactory.java:59) at org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:85) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) ... 20 more Caused by: java.lang.ClassNotFoundException: org.apache.maven.doxia.module.xhtml.decoration.render.RenderingContext at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50) at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244) at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230) ... 23 more After some debugging it seams to me that the cause is the version of maven-reporting-impl dependency which is now 2.0.5. I made it work with the following snippet in my pom.xml: org.apache.maven.plugins maven-plugin-plugin 2.9 report pre-site report org.apache.maven.reporting maven-reporting-impl 2.2 After this setting the plugin-info.html file is generated at target/generated-site/xdoc directory. However nothing is copied to target/site as the output file should be moved to target/generated-site/xhtml and it should have the extension .xhtml.vm. I made the workaround that I copy and rename the html file to src/site/xhtml/plugin-info.xhtml.vm. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-191) plugin-info.html is not created
[
https://jira.codehaus.org/browse/MPLUGIN-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311200#comment-311200
]
Balazs Zsoldos edited comment on MPLUGIN-191 at 10/10/12 6:48 AM:
--
Half of the issue is solved. The plugin still generates plugin-info.html into
targate/generated-site/xdoc although this file is not an xdoc but an xhtml.vm.
Due to this reason the plugin-info.html is not in the finally generated site.
Tested with the version 3.1.
was (Author: zs_b):
Half of the issue is solved. The plugin still generates plugin-info.html
into targate/generated-site/xdoc although this file is not an xdoc but an
xhtml.vm. Due to this reason the plugin-info.html is not in the finally
generated site.
> plugin-info.html is not created
> ---
>
> Key: MPLUGIN-191
> URL: https://jira.codehaus.org/browse/MPLUGIN-191
> Project: Maven 2.x Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 2.9
> Environment: Maven 3.x
>Reporter: Balazs Zsoldos
>Assignee: Robert Scholte
>Priority: Critical
>
> During running maven-plugin-plugin:report the following exception occurs:
> {noformat}Caused by: java.lang.NoClassDefFoundError:
> org/apache/maven/doxia/module/xhtml/decoration/render/RenderingContext
> at
> org.apache.maven.reporting.sink.SinkFactory.createSink(SinkFactory.java:59)
> at
> org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:85)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more
> Caused by: java.lang.ClassNotFoundException:
> org.apache.maven.doxia.module.xhtml.decoration.render.RenderingContext
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
> ... 23 more{noformat}
> After some debugging it seams to me that the cause is the version of
> maven-reporting-impl dependency which is now 2.0.5. I made it work with the
> following snippet in my pom.xml:
> {code:xml}
> org.apache.maven.plugins
> maven-plugin-plugin
> 2.9
>
>
> report
> pre-site
>
> report
>
>
>
>
>
>
> org.apache.maven.reporting
>
> maven-reporting-impl
> 2.2
>
>
> {code}
> After this setting the plugin-info.html file is generated at
> target/generated-site/xdoc directory. However nothing is copied to
> target/site as the output file should be moved to target/generated-site/xhtml
> and it should have the extension .xhtml.vm.
> I made the workaround that I copy and rename the html file to
> src/site/xhtml/plugin-info.xhtml.vm.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-191) plugin-info.html is not created
[
https://jira.codehaus.org/browse/MPLUGIN-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Balazs Zsoldos reopened MPLUGIN-191:
Half of the issue is solved. The plugin still generates plugin-info.html into
targate/generated-site/xdoc although this file is not an xdoc but an xhtml.vm.
Due to this reason the plugin-info.html is not in the finally generated site.
> plugin-info.html is not created
> ---
>
> Key: MPLUGIN-191
> URL: https://jira.codehaus.org/browse/MPLUGIN-191
> Project: Maven 2.x Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 2.9
> Environment: Maven 3.x
>Reporter: Balazs Zsoldos
>Assignee: Robert Scholte
>Priority: Critical
>
> During running maven-plugin-plugin:report the following exception occurs:
> {noformat}Caused by: java.lang.NoClassDefFoundError:
> org/apache/maven/doxia/module/xhtml/decoration/render/RenderingContext
> at
> org.apache.maven.reporting.sink.SinkFactory.createSink(SinkFactory.java:59)
> at
> org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:85)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more
> Caused by: java.lang.ClassNotFoundException:
> org.apache.maven.doxia.module.xhtml.decoration.render.RenderingContext
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
> ... 23 more{noformat}
> After some debugging it seams to me that the cause is the version of
> maven-reporting-impl dependency which is now 2.0.5. I made it work with the
> following snippet in my pom.xml:
> {code:xml}
> org.apache.maven.plugins
> maven-plugin-plugin
> 2.9
>
>
> report
> pre-site
>
> report
>
>
>
>
>
>
> org.apache.maven.reporting
>
> maven-reporting-impl
> 2.2
>
>
> {code}
> After this setting the plugin-info.html file is generated at
> target/generated-site/xdoc directory. However nothing is copied to
> target/site as the output file should be moved to target/generated-site/xhtml
> and it should have the extension .xhtml.vm.
> I made the workaround that I copy and rename the html file to
> src/site/xhtml/plugin-info.xhtml.vm.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
