date:20081201

[jira] Issue Comment Edited: (MAVENUPLOAD-2286) nez sync rule from sourceforge project

2008-12-01 Thread Christophe Lallement (JIRA)


[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=155811#action_155811
 ] 

Christophe Lallement edited comment on MAVENUPLOAD-2286 at 12/1/08 3:11 AM:


maybe there is an error and the hostname to sync is: 
org.jvyaml,[EMAIL 
PROTECTED]:/home/users/o/ou/ouaibsky/maven/m2repo,rsync_ssh,Ouaibsky,[EMAIL
 PROTECTED],,

  was (Author: christophe):
maybe there is an error and the hostname to sync is: 
org.jvyaml,[EMAIL 
PROTECTED]:/home/users/o/ou/ouaibsky/maven/m2repo,rsync_ssh,Ouaibsky,ouaibsky.free.fr,,
  
 nez sync rule from sourceforge project
 --

 Key: MAVENUPLOAD-2286
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2286
 Project: Maven Upload Requests
  Issue Type: Wish
Reporter: Christophe Lallement

 org.jvyaml,[EMAIL 
 PROTECTED]:/home/users/o/ou/ouaibsky/maven/m2repo,rsync_ssh,Ouaibsky,ouaibsky.free.fr,,

-- 
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-3880) package phase devided into more specific phases

2008-12-01 Thread Anders Kr. Andersen (JIRA)

package phase devided into more specific phases
---

 Key: MNG-3880
 URL: http://jira.codehaus.org/browse/MNG-3880
 Project: Maven 2
  Issue Type: Improvement
  Components: Plugins and Lifecycle
Affects Versions: 2.0.9
Reporter: Anders Kr. Andersen


Currently the command mvn package will produce a zipped result file like xx.war 
or xxx.jar

So I belive it must always be...

I suggest that the phase is devided into multiple pre phases like:

package-copy   -- copies files to target/xxx-war (the prezipped directory 
structure)
package-manifest   -- generates the manifest to be packed into the zipped 
result
package-maven   -- generates the maven META-INF/maven files
package-compress -- zips the  target/xxx-war into the file target/xxx-war.war

The reasoning for these suggestions is that I had a situation where I had to 
add more files into the unpacked result.
This ended up more jobbi than I had thought because I had to manage the 
manifest, maven and compress as well.

Best regards
/Anders

PS: My sample is a Weblogic Integration Problem with task  
weblogic.ant.taskdefs.build.AnnotationManifestTask
The task will go through all classes and jars in the result and make a kind of 
index and place the index into META-INF.

My code got ugly
I had to run the task yes, ofcause..
But I had to do much more than I hoped.
1) MANIFEST.MF  (maven generates it under the final ZIP process) I had to steal 
it from mavens ZIP
2) META-INF/maven/ (Maven also generates it under the final ZIP process). I 
had to steal this as well
3) the package phase will do the compress as well. I had to zip again !!! 
(Maybe I could just update existing zip?, but i did not choose that)

If I had multiple steps in the package phase I could have made this 
customer-plugin easier...


Here is the ugly code


build-manifests moduleDir=${staging.dir}
 searchClasspathRef=annotation.manifest.search.path
 classpathRef=annotation.manifest.class.path
 verbose=false
 version=
 stagingDir=${project.build.directory}/manifest-work/


unzip src=${staging.dir}.${project.packaging}
dest=${staging.dir}
patternset
include name=META-INF/**/*.*/
/patternset
/unzip

delete dir=${staging.dir}/WEB-INF/classes/META-INF/ /
delete file=${staging.dir}.${project.packaging} /
zip destfile=${staging.dir}.${project.packaging} encoding=UTF8 
whenempty=create
fileset dir=${staging.dir}/
/zip






 





-- 
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-3881) Properties in plugin poms are not resolved.

2008-12-01 Thread Derek Clarkson (JIRA)

Properties in plugin poms are not resolved.
---

 Key: MNG-3881
 URL: http://jira.codehaus.org/browse/MNG-3881
 Project: Maven 2
  Issue Type: Bug
  Components: Plugins and Lifecycle
Affects Versions: 2.1.0-M1
 Environment: Mac ox s
Reporter: Derek Clarkson


I'm testing a plugin I have written to run JUnit 4.x tests. The pom for this 
plug uses properties to specify the versions of dependencies. ie. 

dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version${junit.version}/version
/dependency
dependency
groupIdorg.slf4j/groupId
artifactIdslf4j-api/artifactId
version${slf4j.version}/version
/dependency

After compiling and installing the plugin into my local repository, I then 
attempt to use in in another project. The project compiles correcly, but then 
fails when attempting to resolve the dependecies of my plugin. The faiures 
appear to be the plugins dependencies which are versioned by properties. HEre's 
an example:

6) org.slf4j:slf4j-api:jar:${slf4j.version}

  Try downloading the file manually from the project website.

  Then, install it using the command: 
  mvn install:install-file -DgroupId=org.slf4j -DartifactId=slf4j-api 
-Dversion=${slf4j.version} -Dpackaging=jar -Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there: 
  mvn deploy:deploy-file -DgroupId=org.slf4j -DartifactId=slf4j-api 
-Dversion=${slf4j.version} -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] 
-DrepositoryId=[id]

  Path to dependency: 
1) dhc.maven2:maven-junit4x-plugin:maven-plugin:0.0.3-SNAPSHOT
2) org.slf4j:slf4j-api:jar:${slf4j.version}

I also see stack traces like this:

Caused by: java.io.FileNotFoundException: 
http://repo1.maven.org/maven2/org/apache/maven/reporting/maven-reporting-impl/${maven.reporting.version}/maven-reporting-impl-${maven.reporting.version}.jar
at 
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1239)
at 
org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:83)
... 35 more
[DEBUG] Unable to download the artifact from any repository

And 

7 required artifacts are missing.

for artifact: 
  dhc.maven2:maven-junit4x-plugin:maven-plugin:0.0.3-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2)

at 
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:482)
at 
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:394)
at 
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:337)
at 
org.apache.maven.plugin.DefaultPluginManager.getPluginArtifacts(DefaultPluginManager.java:436)
at 
org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:279)
at 
org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:211)
at 
org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:186)
at 
org.apache.maven.plugin.loader.DefaultPluginLoader.loadPlugin(DefaultPluginLoader.java:79)
... 20 more

Plaing around with this I found that if I go into the repository and edit the 
pom file to specify the dependency version then that dependency resolves. 

From this I'm inclined to think that when resolving dependencies of plugins, 
that the plugin's pom is not being processed to look for properties to be 
inserted.

-- 
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-3882) Prevent local repository from also being the remote repository

2008-12-01 Thread Paul Benedict (JIRA)

Prevent local repository from also being the remote repository
--

 Key: MNG-3882
 URL: http://jira.codehaus.org/browse/MNG-3882
 Project: Maven 2
  Issue Type: Bug
  Components: Settings
Affects Versions: 2.1.0-M1, 2.0.10, 3.0-alpha-1
Reporter: Paul Benedict


User list shows that the local repository can be specified as a remote 
repository. I've confirmed this is true. This is obviously a sore 
misconfiguration. Let's check that the values are never equal.

-- 
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: (MECLIPSE-443) Only include **/*.java in Java source directories

2008-12-01 Thread Michael Johns (JIRA)


[ 
http://jira.codehaus.org/browse/MECLIPSE-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=156002#action_156002
 ] 

Michael Johns commented on MECLIPSE-443:


Yes, that's the default behavior of the compiler plugin: 
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-compiler-plugin/src/main/java/org/apache/maven/plugin/CompilerMojo.java?view=markup

You can override that behavior to include other types of files.  I suppose this 
plugin should follow that same pattern.

 Only include **/*.java in Java source directories
 -

 Key: MECLIPSE-443
 URL: http://jira.codehaus.org/browse/MECLIPSE-443
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Improvement
Affects Versions: 2.5.1
Reporter: Michael Johns
Assignee: Barrie Treloar
Priority: Minor
 Fix For: 2.6

 Attachments: MECLIPSE-443.2.patch, MECLIPSE-443.patch


 Since Maven only recognizes *.java files in Java source directories 
 (src/main/java, or src/test/java, for example), it would be nice if the 
 plugin produced .classpath files configured the same way.  Right now, a 
 developer can inadvertently leave a non-Java resource in one of those 
 directories, and everything will work fine in Eclipse.  But when the time 
 comes to produce a package, that artifact will be missing since Maven won't 
 pick it up.

-- 
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-2293) Please upload jSSLutils 0.5.1

2008-12-01 Thread Bruno Harbulot (JIRA)

Please upload jSSLutils 0.5.1
-

 Key: MAVENUPLOAD-2293
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2293
 Project: Maven Upload Requests
  Issue Type: Wish
Reporter: Bruno Harbulot


Hello, I'm the developer and project owner of jsslutils. Could you please 
upload this version of the project in the repository?

Thank you,

Bruno.

-- 
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-3879) Dependency map and documentation

2008-12-01 Thread Daniel Kulp (JIRA)

[
http://jira.codehaus.org/browse/MNG-3879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=156012#action_156012
]

Daniel Kulp commented on MNG-3879:
--

Changing the POM format is definitely a huge deal and is something that seems
to be constantly discussed on the dev list. :-( Adding stuff to the poms
currently breaks users of any previous version of Maven, which is not ideal as
many corporations and such are adverse to upgrading.There is an opinion of
some people that anything deployed in central needs to be completely readable
and usable by all versions of maven.

I'm wondering if instead of adding another element (and thus changing the pom
schema/format), the parser could just be updated to save any comments in the
dependency element.All old versions would just ignore it.

For the second part, that would be an enhancement of the dependency:tree plugin:
http://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.html

Dependency map and documentation

Key: MNG-3879
URL: http://jira.codehaus.org/browse/MNG-3879
Project: Maven 2
Issue Type: New Feature
Components: Dependencies
Affects Versions: 2.0.9
Reporter: benson margulies

This JIRA proposes a feature. I'm willing to try to contribute it given a
modicum of encouragement and guidance.
Over at CXF, we get many questions from users who are completely confounded
by the complex dependency graph that results from our many dependencies and
their many dependencies. I think that they would be less confused by far if
maven gave them a tiny bit of help.
The first part of the idea requires an addition to the core POM, which is why
I'm starting with a JIRA here. I propose to add an 'explanation' element to
the dependency element. This would contain a human-readable string explaining
why the dependency is here.
The second part is a goal that I would propose to call 'dependency-map'. This
would produce a formatted map of the dependency tree -- enriched, of course,
by the comments in the first part.

--
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: (MECLIPSE-414) Not beeing @aggregator, eclipse plugin does not require executedProject

2008-12-01 Thread Benjamin Bentmann (JIRA)


[ 
http://jira.codehaus.org/browse/MECLIPSE-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=156014#action_156014
 ] 

Benjamin Bentmann commented on MECLIPSE-414:


bq. I'm looking into why it needs a forked lifecycle...
For goals that are primarily run from the CLI, there is not other way to tell 
about generated sources/resources. I.e. without forking a build up to 
generates-resources, the plugin would only see the static source/directories 
specified in the POM and would miss stuff that gets dynamically generated.

 Not beeing @aggregator, eclipse plugin does not require executedProject
 ---

 Key: MECLIPSE-414
 URL: http://jira.codehaus.org/browse/MECLIPSE-414
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Bug
Affects Versions: 2.5
Reporter: nicolas de loof
Assignee: Barrie Treloar
 Fix For: 2.6


 The eclispe plugin uses both ${executedProject} and ${project}. 
 Not beeing an aggregator plugin, ${project} is allways tghe currently 
 executed project, and the projectDirectory is project.getBasedir().
 Having two attributes for same target makes the plugin harder to understand

-- 
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-191) Tidy up logging from unpack

2008-12-01 Thread Tom Palmer (JIRA)

Tidy up logging from unpack
---

 Key: MDEP-191
 URL: http://jira.codehaus.org/browse/MDEP-191
 Project: Maven 2.x Dependency Plugin
  Issue Type: Improvement
  Components: unpack
Affects Versions: 2.0
Reporter: Tom Palmer
Assignee: Brian Fox
Priority: Trivial
 Attachments: tidy-unpack-logging.patch

The attached patch changes the logging output from unpacking artifacts by 
logging on a single line to make it more consistent with other logging messages 
(e.g. installing an artifact). It also logs the includes/excludes only when 
they are not null. For example the output (taken from the test run of the 
plugin) changes from:

{noformat}
[INFO] Unpacking 
/Users/tom/Development/Projects/maven/plugins/maven-dependency-plugin/target/unit-tests/unpack/localTestRepo/test-1.0.jar
 to
  
/Users/tom/Development/Projects/maven/plugins/maven-dependency-plugin/target/unit-tests/unpack/outputDirectory
   with includes **/test2.txt and excludes:null
[INFO] Unpacking 
/Users/tom/Development/Projects/maven/plugins/maven-dependency-plugin/target/unit-tests/unpack/localTestRepo/test-1.0.jar
 to
  
/Users/tom/Development/Projects/maven/plugins/maven-dependency-plugin/target/unit-tests/unpack/outputDirectory
   with includes null and excludes:**/*
{noformat}

to:

{noformat}
[INFO] Unpacking 
/Users/tom/Development/Projects/maven/plugins/maven-dependency-plugin/target/unit-tests/unpack/localTestRepo/test-1.0.jar
 to 
/Users/tom/Development/Projects/maven/plugins/maven-dependency-plugin/target/unit-tests/unpack/outputDirectory
 with includes **/test2.txt
[INFO] Unpacking 
/Users/tom/Development/Projects/maven/plugins/maven-dependency-plugin/target/unit-tests/unpack/localTestRepo/test-1.0.jar
 to 
/Users/tom/Development/Projects/maven/plugins/maven-dependency-plugin/target/unit-tests/unpack/outputDirectory
 with excludes **/*
{noformat}


-- 
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-3882) Prevent local repository from also being the remote repository

2008-12-01 Thread Wendy Smoak (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=156061#action_156061
 ] 

Wendy Smoak commented on MNG-3882:
--

What values do you want to compare?  The local repo is a path, the remote repo 
is a url.  How would Maven be able to detect this?

Usually what happens is that a user takes a local repository, copies it to a 
server and serves it as a remote repo either with a file:// url or by using a 
web server in front.

Less common is dropping a copy of the local repo filesystem into a repository 
manager -- and this is less of a problem since Archiva at least can repair the 
metadata.

 Prevent local repository from also being the remote repository
 --

 Key: MNG-3882
 URL: http://jira.codehaus.org/browse/MNG-3882
 Project: Maven 2
  Issue Type: Bug
  Components: Settings
Affects Versions: 2.0.10, 2.1.0-M1, 3.0-alpha-1
Reporter: Paul Benedict

 User list shows that the local repository can be specified as a remote 
 repository. I've confirmed this is true. This is obviously a sore 
 misconfiguration. Let's check that the values are never equal.

-- 
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-3163) Profile activation based on hostname or IP

2008-12-01 Thread Jessie Crowe (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=156072#action_156072
 ] 

Jessie Crowe commented on MNG-3163:
---

The maven guide seems to imply this already works here:

http://maven.apache.org/guides/introduction/introduction-to-profiles.html

I cannot seem to get it to work.  I tried

activationpropertynameenv.COMPUTERNAME/name/property on a windows 
box, but the profile did not activate.


 Profile activation based on hostname or IP
 --

 Key: MNG-3163
 URL: http://jira.codehaus.org/browse/MNG-3163
 Project: Maven 2
  Issue Type: Improvement
  Components: Profiles
Reporter: David J. M. Karlsen
Priority: Minor
 Fix For: 3.x


 It would be very nice to be able to activate profiles based on hostname[s] or 
 IP-address[es].
 Yes, this could be exported from the system as a systemproperty quite easily 
 on *NIX with -Dhostname=`hostname` but is a little more tricky on other 
 platforms - so why not include it in maven itself?
 It would be even better if it can be expressed with regex'es or the likes.
 WDYT?

-- 
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-3861) Publish specification on POM construction

2008-12-01 Thread Shane Isbell (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=156074#action_156074
 ] 

Shane Isbell commented on MNG-3861:
---

I'm also updating this to be in line with current builder code.

 Publish specification on POM construction
 -

 Key: MNG-3861
 URL: http://jira.codehaus.org/browse/MNG-3861
 Project: Maven 2
  Issue Type: Task
Reporter: Jason van Zyl
Assignee: Jason van Zyl
 Fix For: 3.0-alpha-1




-- 
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-3163) Profile activation based on hostname or IP

2008-12-01 Thread Jessie Crowe (JIRA)


 [ 
http://jira.codehaus.org/browse/MNG-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jessie Crowe updated MNG-3163:
--

Attachment: exampleproject.zip

Here is an example project that demonstrates trying to load a build profile.  
According to the maven introduction to build profiles, this should work, but it 
doesn't seem to.

 Profile activation based on hostname or IP
 --

 Key: MNG-3163
 URL: http://jira.codehaus.org/browse/MNG-3163
 Project: Maven 2
  Issue Type: Improvement
  Components: Profiles
Reporter: David J. M. Karlsen
Priority: Minor
 Fix For: 3.x

 Attachments: exampleproject.zip


 It would be very nice to be able to activate profiles based on hostname[s] or 
 IP-address[es].
 Yes, this could be exported from the system as a systemproperty quite easily 
 on *NIX with -Dhostname=`hostname` but is a little more tricky on other 
 platforms - so why not include it in maven itself?
 It would be even better if it can be expressed with regex'es or the likes.
 WDYT?

-- 
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] Issue Comment Edited: (MNG-3163) Profile activation based on hostname or IP

2008-12-01 Thread Jessie Crowe (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=156075#action_156075
 ] 

Jessie Crowe edited comment on MNG-3163 at 12/1/08 2:29 PM:


Here is an example project that demonstrates trying to load a build profile.  
According to the maven introduction to build profiles, this should work, but it 
doesn't seem to.

I am using maven 2.0.8

  was (Author: dragonfly0806):
Here is an example project that demonstrates trying to load a build 
profile.  According to the maven introduction to build profiles, this should 
work, but it doesn't seem to.
  
 Profile activation based on hostname or IP
 --

 Key: MNG-3163
 URL: http://jira.codehaus.org/browse/MNG-3163
 Project: Maven 2
  Issue Type: Improvement
  Components: Profiles
Reporter: David J. M. Karlsen
Priority: Minor
 Fix For: 3.x

 Attachments: exampleproject.zip


 It would be very nice to be able to activate profiles based on hostname[s] or 
 IP-address[es].
 Yes, this could be exported from the system as a systemproperty quite easily 
 on *NIX with -Dhostname=`hostname` but is a little more tricky on other 
 platforms - so why not include it in maven itself?
 It would be even better if it can be expressed with regex'es or the likes.
 WDYT?

-- 
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-3882) Prevent local repository from also being the remote repository

2008-12-01 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=156078#action_156078
 ] 

Paul Benedict commented on MNG-3882:


I want to compare the values of the local repo path and the remote repo path. I 
can set both of them to a file system path. I can't remember if I can do it 
directly, or use the file:// protocol.

 Prevent local repository from also being the remote repository
 --

 Key: MNG-3882
 URL: http://jira.codehaus.org/browse/MNG-3882
 Project: Maven 2
  Issue Type: Bug
  Components: Settings
Affects Versions: 2.0.10, 2.1.0-M1, 3.0-alpha-1
Reporter: Paul Benedict

 User list shows that the local repository can be specified as a remote 
 repository. I've confirmed this is true. This is obviously a sore 
 misconfiguration. Let's check that the values are never equal.

-- 
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-3882) Prevent local repository from also being the remote repository

2008-12-01 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=156079#action_156079
 ] 

Paul Benedict commented on MNG-3882:


Okay. I have verified I can put in the same exact value for both. Neither of 
them are using a protocol -- just a file system path.

 Prevent local repository from also being the remote repository
 --

 Key: MNG-3882
 URL: http://jira.codehaus.org/browse/MNG-3882
 Project: Maven 2
  Issue Type: Bug
  Components: Settings
Affects Versions: 2.0.10, 2.1.0-M1, 3.0-alpha-1
Reporter: Paul Benedict

 User list shows that the local repository can be specified as a remote 
 repository. I've confirmed this is true. This is obviously a sore 
 misconfiguration. Let's check that the values are never equal.

-- 
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

64 matches

Mail list logo