[jira] Created: (SCM-443) login failure
login failure
-
Key: SCM-443
URL: http://jira.codehaus.org/browse/SCM-443
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-perforce
Affects Versions: 1.1.1
Environment: windows service
Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
with continnum in standalone mode
perforce 2008.2 security level 3
Reporter: Raphael PETIT
Priority: Blocker
Index: PerforceLoginCommand.java
===
--- PerforceLoginCommand.java (revision 750811)
+++ PerforceLoginCommand.java (working copy)
@@ -69,7 +69,7 @@
int exitCode = CommandLineUtils.executeCommandLine( cl, new
StringBufferInputStream(password), consumer, err );
isSuccess = consumer.isSuccess();
-if ( isSuccess )
+if (! isSuccess )
{
String cmdLine = CommandLineUtils.toString(
cl.getCommandline() );
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-444) Git provider does 'git push' during 'mvn release:prepare' which causes unwanted problems
Git provider does 'git push' during 'mvn release:prepare' which causes unwanted problems Key: SCM-444 URL: http://jira.codehaus.org/browse/SCM-444 Project: Maven SCM Issue Type: Bug Affects Versions: 1.1 Reporter: Petter Måhlén Priority: Minor When doing 'mvn release:prepare' with a Git provider, a 'git push' command is executed. This is not ideal because the push command can fail or push things from the local repository that are not needed/wanted in the remote repository. Some examples are: 1. The local repository has two branches: master (tracking origin/master) and dummy (tracking origin/dummy). The release is being made on the master branch, and the dummy and origin/dummy branches have diverged. Running 'release:prepare' causes a 'git push', which will succeed for the master branch (assuming that the release preparation has been made correctly) and fail for the dummy branch (the two branches have diverged and need to be merged or rebased). The release preparation aborts and the directory is left in a somewhat inconsistent state where manual cleaning up is needed (removing pom.xml.next files, changing versions to -SNAPSHOT, etc.) 2. The local repository has two branches: master (tracking origin/master) and localtest (not in the origin repository). The localtest branch shouldn't be published because it is just used for some temporary testing and doesn't even work. It will be pushed during 'release:prepare'. Suggested behaviour: use 'git push origin :', or even better, query for which remote repository to push to (found in .git/config) and which branch to push from and to. For me, it would be great to have a 'confirm push' before doing it so as to keep things clean, but maybe that is quite complex. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DOXIA-294) Apt verbatim box not correct
[ http://jira.codehaus.org/browse/DOXIA-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated DOXIA-294: Affects Version/s: (was: 1.0) (was: 1.0-alpha-11) 1.1 Fix Version/s: 1.1.1 Summary: Apt verbatim box not correct (was: Problems with Doxia) > Apt verbatim box not correct > > > Key: DOXIA-294 > URL: http://jira.codehaus.org/browse/DOXIA-294 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Apt, Site Renderer >Affects Versions: 1.1 > Environment: Max OS X (Leopard), Sun Java 1.5.0_16. Maven 2.0.10 >Reporter: Jakob Vad Nielsen > Fix For: 1.1.1 > > Attachments: dump.txt, proof.zip > > > It seems to me that there are a mess on what Doxia packages versions that are > chosen when rendering a site with mvn site:site. See the attached dump.txt. > It seems to me that version 1.0 of doxia is not chosen. And that older > versions are used. > I have added this to my pom.xml > plugin> > org.apache.maven.doxia > doxia-maven-plugin >1.0 > > I discovered this when trying to find out why verbatime text doesn't work > like it did before from an apt file. > - > Verbatime > - > gives thes same markup as > +--+ > Verbatime 2 > +--+ > Both are converted into Verbatime. This > is a new bug that I haven't seen before. > I have attached a small maven project that demonstrates this. demo.html > generated with site:site demonstrates the problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-294) Apt verbatim box not correct
[ http://jira.codehaus.org/browse/DOXIA-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=168147#action_168147 ] Lukas Theussl commented on DOXIA-294: - The different versions are the versions used by various transitive dependencies, they are not all used actually in the final classpath. I confirm the verbatim box issue, we'll fix it after the 1.1 release. > Apt verbatim box not correct > > > Key: DOXIA-294 > URL: http://jira.codehaus.org/browse/DOXIA-294 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Apt, Site Renderer >Affects Versions: 1.1 > Environment: Max OS X (Leopard), Sun Java 1.5.0_16. Maven 2.0.10 >Reporter: Jakob Vad Nielsen > Fix For: 1.1.1 > > Attachments: dump.txt, proof.zip > > > It seems to me that there are a mess on what Doxia packages versions that are > chosen when rendering a site with mvn site:site. See the attached dump.txt. > It seems to me that version 1.0 of doxia is not chosen. And that older > versions are used. > I have added this to my pom.xml > plugin> > org.apache.maven.doxia > doxia-maven-plugin >1.0 > > I discovered this when trying to find out why verbatime text doesn't work > like it did before from an apt file. > - > Verbatime > - > gives thes same markup as > +--+ > Verbatime 2 > +--+ > Both are converted into Verbatime. This > is a new bug that I haven't seen before. > I have attached a small maven project that demonstrates this. demo.html > generated with site:site demonstrates the problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DOXIA-296) HTML is escaped inside
HTML is escaped inside
---
Key: DOXIA-296
URL: http://jira.codehaus.org/browse/DOXIA-296
Project: Maven Doxia
Issue Type: Bug
Components: Module - Xdoc
Affects Versions: 1.1
Reporter: Lukas Theussl
The following two source boxes give the same output:
{code:xml}
what
{code}
ie the html characters are incorrectly escaped in the first version.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DOXIA-296) HTML is escaped inside
[
http://jira.codehaus.org/browse/DOXIA-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl updated DOXIA-296:
Fix Version/s: 1.1.1
> HTML is escaped inside
> ---
>
> Key: DOXIA-296
> URL: http://jira.codehaus.org/browse/DOXIA-296
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Xdoc
>Affects Versions: 1.1
>Reporter: Lukas Theussl
> Fix For: 1.1.1
>
>
> The following two source boxes give the same output:
> {code:xml}
> what
>
> {code}
> ie the html characters are incorrectly escaped in the first version.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEP-201) Add option to tree goal to generate tree based on dependencyManagement
Add option to tree goal to generate tree based on dependencyManagement -- Key: MDEP-201 URL: http://jira.codehaus.org/browse/MDEP-201 Project: Maven 2.x Dependency Plugin Issue Type: New Feature Components: tree Reporter: Paul Gier Assignee: Brian Fox I have a parent pom that controls the dependency versions for a multimodule project. I would like to be able to generate a dependency tree from this pom, so that I can see the tree for the entire project, but currently the tree goal only looks at actual dependencies and not those in dependency management. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4069) Remove support for plugin metaversion LATEST
Remove support for plugin metaversion LATEST Key: MNG-4069 URL: http://jira.codehaus.org/browse/MNG-4069 Project: Maven 2 Issue Type: Task Components: Plugins and Lifecycle Reporter: Benjamin Bentmann Priority: Minor -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-4069) Remove support for plugin metaversion LATEST
[ http://jira.codehaus.org/browse/MNG-4069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4069. -- Assignee: Jason van Zyl Resolution: Fixed Fix Version/s: 3.0 Done in [r750774|http://svn.eu.apache.org/viewvc?view=rev&revision=750774]. > Remove support for plugin metaversion LATEST > > > Key: MNG-4069 > URL: http://jira.codehaus.org/browse/MNG-4069 > Project: Maven 2 > Issue Type: Task > Components: Plugins and Lifecycle >Reporter: Benjamin Bentmann >Assignee: Jason van Zyl >Priority: Minor > Fix For: 3.0 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-358) CheckDependencySnapshotsPhase fails when resolving all dependencies
[ http://jira.codehaus.org/browse/MRELEASE-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=168210#action_168210 ] Rich Seller commented on MRELEASE-358: -- Has anybody had a chance to look at this yet? > CheckDependencySnapshotsPhase fails when resolving all dependencies > --- > > Key: MRELEASE-358 > URL: http://jira.codehaus.org/browse/MRELEASE-358 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.0-beta-7 >Reporter: Rich Seller > Attachments: patch.txt > > > In CheckDependencySnapshotsPhase, if '0' (All) is selected in response to the > prompt "specify the selection number ..." the dependencies are not removed > from the original set, so a ReleaseFailureException is thrown at the end of > checkProject(). > In the attached patch the dependencies are removed from the original set, and > the snapshotSet is returned from resolveSnapshots() to be checked in > checkProject(). > In the tests, I implemented a custom Prompter because I don't know how to set > multiple conditional responses on JMock1 mocks. > One other change made while testing: in processSnapshot, "What is the next > development version?" is set with a singleton list so a different value has > been entered. I removed the list to make the supplied value the default but > allow different responses. I can raise this as a separate issue if required -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEPLOY-93) Deploy plugin does not honor modification of final name by assembly plugin
[
http://jira.codehaus.org/browse/MDEPLOY-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=168216#action_168216
]
Renaud Lepage commented on MDEPLOY-93:
--
I think this is not on Maven's side but more on the Remote Repository's side.
> Deploy plugin does not honor modification of final name by assembly plugin
> --
>
> Key: MDEPLOY-93
> URL: http://jira.codehaus.org/browse/MDEPLOY-93
> Project: Maven 2.x Deploy Plugin
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Thorsten Möller
>
> When using the Maven assembly plugin to create an assembly for a project and
> using "fileName" parameter inside the plugin to change the final name of the
> assembly this new name will not be used by the deploy plugin. The deploy
> plugin always uses the default behavior. The following excerpt from a POM
> illustrates this:
> myGoupID
> myArtifactID
>
>
>
> org.apache.maven.plugins
> maven-assembly-plugin
>
>
>
> src/main/assembly/bin.xml
>
> false
> foo
> gnu
>
>
>
> minimal
> package
>
> single
>
>
>
>
>
>
> With this configuration an assembly named "foo.{tar.gz|zip}" will be created
> in the target folder of the project (note that the artifact is attached
> because the assembly plugin is attached to the package lifecycle phase).
> However, when deploying the project file to the distribution repository it
> will be named "myArtifactId.{tar.gz|zip}", which is the default behavior if
> "finalName" is not specified. Interesting is that in the local repository the
> file name always corresponds to what is specified by "fileName", just for the
> distribution repository the parameter is not honored.
> BTW, the other parameter "appendAssemblyId" is honored correctly, i.e,
> depending on the boolean value the assembly Id will be appended to the name,
> or not.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2432) Apache and Mojo plugins take precendence over plugins in the pom.
[ http://jira.codehaus.org/browse/MNG-2432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-2432: --- Affects Version/s: 3.0-alpha-2 Preferring plugins from the POM over those from the plugin groups in the settings wasn't fixed until 3.x. > Apache and Mojo plugins take precendence over plugins in the pom. > - > > Key: MNG-2432 > URL: http://jira.codehaus.org/browse/MNG-2432 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.4 >Reporter: Jan Bartel >Assignee: Brian Fox > Fix For: 3.0-alpha-2 > > > When resolving plugin prefixes, plugins from apache and mojo take precendence > over plugins explicitly in the pom.xml. For example, an old plugin with > prefix "jetty" at org.codehaus.mojo.jetty-maven-plugin is always used in > preference to the new maven-jetty-plugin with prefix "jetty", even though it > is specified in the pom like so: > > org.mortbay.jetty > maven-jetty-plugin > 6.0-SNAPSHOT > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2432) Apache and Mojo plugins take precendence over plugins in the pom.
[ http://jira.codehaus.org/browse/MNG-2432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-2432: --- Affects Version/s: (was: 3.0-alpha-2) Fix Version/s: (was: 2.0.7) 3.0-alpha-2 > Apache and Mojo plugins take precendence over plugins in the pom. > - > > Key: MNG-2432 > URL: http://jira.codehaus.org/browse/MNG-2432 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.4 >Reporter: Jan Bartel >Assignee: Brian Fox > Fix For: 3.0-alpha-2 > > > When resolving plugin prefixes, plugins from apache and mojo take precendence > over plugins explicitly in the pom.xml. For example, an old plugin with > prefix "jetty" at org.codehaus.mojo.jetty-maven-plugin is always used in > preference to the new maven-jetty-plugin with prefix "jetty", even though it > is specified in the pom like so: > > org.mortbay.jetty > maven-jetty-plugin > 6.0-SNAPSHOT > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2380) Upload Stripes-1.5.1 to Maven Repository
Upload Stripes-1.5.1 to Maven Repository Key: MAVENUPLOAD-2380 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2380 Project: Maven Upload Requests Issue Type: Wish Reporter: Ben Gunter Could you please upload the stripes-1.5.1 bundle to the public maven repository. Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2381) Change the repository URL for the VRaptor
Change the repository URL for the VRaptor - Key: MAVENUPLOAD-2381 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2381 Project: Maven Upload Requests Issue Type: Wish Reporter: Rafael de F. Ferreira We decided to upload our artifacts to SourceForge instead of our own server. The new configuration line is: "org.vraptor","mavens...@web.sourceforge.net:/home/groups/v/vr/vraptor2/htdocs/maven","rsync_ssh","Fabio Kung","fabio.k...@caelum.com.br",, (This issue supersedes MEV-593). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2382) Sync my repository to the central repository
Sync my repository to the central repository Key: MAVENUPLOAD-2382 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2382 Project: Maven Upload Requests Issue Type: Wish Reporter: Alex Eagle "args4j","rs...@jakeherringbone.com:/srv/m2repo","rsync_ssh","Alex Eagle","alexea...@google.com",, Note, I am working on a project in the google-maven-repository that depends on args4j. To upload that project, you require that I have no tags, so I need to upload args4j to the central repository. I have communicated with Kohsuke (the author of args4j and Hudson) about this and gotten his blessing to upload. The files are copied from http://download.java.net/maven/2/args4j/ with the and tags added, as the Maven documentation requires. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-228) role hint: 'scpexe' has a hint, but there are other implementations that don't
[ http://jira.codehaus.org/browse/WAGON-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=168231#action_168231 ] Peter Janes commented on WAGON-228: --- I've just updated to Maven 2.0.10 and still see this error with wagon-ssh-external-1.0-beta-5 (and 1.0-beta-3). > role hint: 'scpexe' has a hint, but there are other implementations that don't > -- > > Key: WAGON-228 > URL: http://jira.codehaus.org/browse/WAGON-228 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ssh-external >Affects Versions: 1.0-beta-3 > Environment: Windows XP, Maven 2.0.9, JDK 1.6.0_04 >Reporter: Dennis Kieselhorst >Assignee: Brett Porter >Priority: Critical > > scpexe doesn't work after updating to 1.0-beta-3: > [ERROR] BUILD ERROR > [INFO] > > [INFO] Unable to initialise extensions > Component descriptor role: 'org.apache.maven.wagon.CommandExecutor', > implementation: > 'org.apache.maven.wagon.providers.ssh.external.ScpExternalCommandExecutor', > role hint: 'scpexe' has a hint, but there are other implementations that don't -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4070) [regression] Parent POMs cannot be resolved when their id values are surrounded by whitespace
[regression] Parent POMs cannot be resolved when their id values are surrounded
by whitespace
-
Key: MNG-4070
URL: http://jira.codehaus.org/browse/MNG-4070
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 3.0-alpha-3
Reporter: Benjamin Bentmann
Priority: Minor
A parent POM with the coordinate snippet:
{code:xml}
org.apache.maven.its.mng0680
parent
1.0
pom
{code}
(note the whitespace!) can't be referenced by children via
{code:xml}
org.apache.maven.its.mng0680
parent
1.0
{code}
because the whitespace in the XML is included in the string comparison of the
ids.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEPLOY-93) Deploy plugin does not honor modification of final name by assembly plugin
[
http://jira.codehaus.org/browse/MDEPLOY-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=168247#action_168247
]
Wendy Smoak commented on MDEPLOY-93:
finalName only affects the filename you see in the target directory, not the
remote repo. The naming format in the remote repo is always
$artifactId-$version-$classifier.
> Deploy plugin does not honor modification of final name by assembly plugin
> --
>
> Key: MDEPLOY-93
> URL: http://jira.codehaus.org/browse/MDEPLOY-93
> Project: Maven 2.x Deploy Plugin
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Thorsten Möller
>
> When using the Maven assembly plugin to create an assembly for a project and
> using "fileName" parameter inside the plugin to change the final name of the
> assembly this new name will not be used by the deploy plugin. The deploy
> plugin always uses the default behavior. The following excerpt from a POM
> illustrates this:
> myGoupID
> myArtifactID
>
>
>
> org.apache.maven.plugins
> maven-assembly-plugin
>
>
>
> src/main/assembly/bin.xml
>
> false
> foo
> gnu
>
>
>
> minimal
> package
>
> single
>
>
>
>
>
>
> With this configuration an assembly named "foo.{tar.gz|zip}" will be created
> in the target folder of the project (note that the artifact is attached
> because the assembly plugin is attached to the package lifecycle phase).
> However, when deploying the project file to the distribution repository it
> will be named "myArtifactId.{tar.gz|zip}", which is the default behavior if
> "finalName" is not specified. Interesting is that in the local repository the
> file name always corresponds to what is specified by "fileName", just for the
> distribution repository the parameter is not honored.
> BTW, the other parameter "appendAssemblyId" is honored correctly, i.e,
> depending on the boolean value the assembly Id will be appended to the name,
> or not.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4071) Support additional read-only local repositories
Support additional read-only local repositories --- Key: MNG-4071 URL: http://jira.codehaus.org/browse/MNG-4071 Project: Maven 2 Issue Type: Wish Components: Artifacts and Repositories Affects Versions: 3.0-alpha-3 Environment: Debian Linux in particular, any other environment Reporter: Ludovic Claude Priority: Minor Work is under way at Debian to support Maven as a tool for building packaged software. Debian uses a local Maven repository (in /usr/share/maven-repo/) which is updated by the Debian tools (dpkg, apt-get). This repository is read-only for the normal user. It would be great if users could use this repository in addition to their local repository in ~/.m2/repo, and it would simplify the Debian tooling. In Debian, when building a package you cannot download anything from the Internet (to allow repeatable builds), so when packaging a Maven project, the --offline option is always used. That means that if you try to trick Maven and use file:///usr/share/maven-repo as a new repository, then it won't work as Maven believes that it is a remote repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4071) Support additional read-only local repositories
[ http://jira.codehaus.org/browse/MNG-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=168266#action_168266 ] Wendy Smoak commented on MNG-4071: -- Why did you choose to make /usr/share/maven-repo a local repo? It seems like if it were in remote repo format, you wouldn't need any changes for it to work. > Support additional read-only local repositories > --- > > Key: MNG-4071 > URL: http://jira.codehaus.org/browse/MNG-4071 > Project: Maven 2 > Issue Type: Wish > Components: Artifacts and Repositories >Affects Versions: 3.0-alpha-3 > Environment: Debian Linux in particular, any other environment >Reporter: Ludovic Claude >Priority: Minor > > Work is under way at Debian to support Maven as a tool for building packaged > software. > Debian uses a local Maven repository (in /usr/share/maven-repo/) which is > updated by the Debian tools (dpkg, apt-get). This repository is read-only for > the normal user. > It would be great if users could use this repository in addition to their > local repository in ~/.m2/repo, and it would simplify the Debian tooling. > In Debian, when building a package you cannot download anything from the > Internet (to allow repeatable builds), so when packaging a Maven project, the > --offline option is always used. That means that if you try to trick Maven > and use file:///usr/share/maven-repo as a new repository, then it won't work > as Maven believes that it is a remote repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4071) Support additional read-only local repositories
[ http://jira.codehaus.org/browse/MNG-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=168267#action_168267 ] Ludovic Claude commented on MNG-4071: - When building a Debian package with Maven, the Debian policies prevent from downloading anything from the Internet. So you need to run Maven with the --offline option, which disables all remote repositories, regardless of their actual location. > Support additional read-only local repositories > --- > > Key: MNG-4071 > URL: http://jira.codehaus.org/browse/MNG-4071 > Project: Maven 2 > Issue Type: Wish > Components: Artifacts and Repositories >Affects Versions: 3.0-alpha-3 > Environment: Debian Linux in particular, any other environment >Reporter: Ludovic Claude >Priority: Minor > > Work is under way at Debian to support Maven as a tool for building packaged > software. > Debian uses a local Maven repository (in /usr/share/maven-repo/) which is > updated by the Debian tools (dpkg, apt-get). This repository is read-only for > the normal user. > It would be great if users could use this repository in addition to their > local repository in ~/.m2/repo, and it would simplify the Debian tooling. > In Debian, when building a package you cannot download anything from the > Internet (to allow repeatable builds), so when packaging a Maven project, the > --offline option is always used. That means that if you try to trick Maven > and use file:///usr/share/maven-repo as a new repository, then it won't work > as Maven believes that it is a remote repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-228) role hint: 'scpexe' has a hint, but there are other implementations that don't
[ http://jira.codehaus.org/browse/WAGON-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=168268#action_168268 ] Brett Porter commented on WAGON-228: 2.0.10 rolled back at the last minute, so you now need to go to 2.1.0-M1 or above > role hint: 'scpexe' has a hint, but there are other implementations that don't > -- > > Key: WAGON-228 > URL: http://jira.codehaus.org/browse/WAGON-228 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ssh-external >Affects Versions: 1.0-beta-3 > Environment: Windows XP, Maven 2.0.9, JDK 1.6.0_04 >Reporter: Dennis Kieselhorst >Assignee: Brett Porter >Priority: Critical > > scpexe doesn't work after updating to 1.0-beta-3: > [ERROR] BUILD ERROR > [INFO] > > [INFO] Unable to initialise extensions > Component descriptor role: 'org.apache.maven.wagon.CommandExecutor', > implementation: > 'org.apache.maven.wagon.providers.ssh.external.ScpExternalCommandExecutor', > role hint: 'scpexe' has a hint, but there are other implementations that don't -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4072) [regression] Repositories from inactive profiles are used for artifact resolution
[regression] Repositories from inactive profiles are used for artifact
resolution
-
Key: MNG-4072
URL: http://jira.codehaus.org/browse/MNG-4072
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.0-alpha-3
Reporter: Benjamin Bentmann
e.g. the following snippet from the {{setttings.xml}
{code:xml}
apache-staging
apache.staging
https://repository.apache.org/content/groups/staging
false
{code}
causes Maven to query r.a.o. for artifacts although the profile hasn't been
activated.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-295) doxia-module-fo fails with a division by 0 error when using FoSink
[
http://jira.codehaus.org/browse/DOXIA-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=168273#action_168273
]
Dean Murphy commented on DOXIA-295:
---
I am using a parser and calling parse() with the sink. I will double check the
content to determine if it is xhtml compliant.
I do agree with you to an extent that hiding this would probably not be
beneficial. Would it be better to throw some type of exception versus death by
a division by zero attempt?
I will post soon regarding the content I'm trying to parse to conclude whether
or not it is compliant.
Thanks!
> doxia-module-fo fails with a division by 0 error when using FoSink
> --
>
> Key: DOXIA-295
> URL: http://jira.codehaus.org/browse/DOXIA-295
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - FO
>Affects Versions: 1.2
> Environment: Linux / Solairs jdk 1.5
> Build from svn check out Revsion: 749805
>Reporter: Dean Murphy
>
> When using the FoSink to convert from documents containing a table, I am
> running into a division by 0 error on line: 703 in
> org.apache.maven.doxia.module.fo.FoSink.java:
> int percent = 100 / cellCount;
> for ( int i = 0; i < cellCount; i++ )
> {
> sb.append( " "%\"/>" );
> sb.append( EOL );
> }
> Simple fix would be to check if cellCount != 0:
> if ( cellCount != 0 ) {
> int percent = 100 / cellCount;
> for ( int i = 0; i < cellCount; i++ )
> {
> sb.append( " "%\"/>" );
> sb.append( EOL );
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
