RE: cvs commit: maven-plugins/artifact/xdocs changes.xml

2004-05-11 Thread Vincent Massol 
+1 to create an extension tag which defaults to jar:

dependency
  [...]
  typemyowntype/type
  extensionmyowntypeextension/extension
/dependency

However that's probably for Maven 1.1.

Thanks
-Vincent

 -Original Message-
 From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
 Sent: 11 May 2004 02:03
 To: Maven Developers List
 Subject: Re: cvs commit: maven-plugins/artifact/xdocs changes.xml
 
 [EMAIL PROTECTED] wrote on 11/05/2004 09:36:35 AM:
 
  brett   2004/05/10 16:36:35
 
Modified:artifact/src/main/org/apache/maven/artifact/deployer
  DefaultArtifactDeployer.java
 artifact/xdocs changes.xml
Log:
PR: MPUBERJAR-5
give uberjar type a jar extension
 
Revision  ChangesPath
1.18  +5 -1  maven-
 

plugins/artifact/src/main/org/apache/maven/artifact/deployer/DefaultArti
fa
 ctDeployer.
  java
 
Index: DefaultArtifactDeployer.java
 
===
RCS file: /home/cvs/maven-
 

plugins/artifact/src/main/org/apache/maven/artifact/deployer/DefaultArti
fa
 ctDeployer.
  java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- DefaultArtifactDeployer.java   2 May 2004 15:04:34 -
1.17
+++ DefaultArtifactDeployer.java   10 May 2004 23:36:34 -
1.18
@@ -513,6 +513,10 @@
 {
 return jar;
 }
+else if (type.equals(uberjar))
+{
+return jar;
+}
 return type;
 }
 }
 
 I'd much rather the artifact code externalised the mapping from type
to
 extension. Otherwise it will become a place of continual churn.
 --
 dIon Gillard, Multitask Consulting
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: cvs commit: maven-plugins/artifact/xdocs changes.xml

2004-05-11 Thread Brett Porter 
Probably? Definitely :)

I don't think this is a per dependency attribute. It's a mapping that needs
to be configurable, but global.

- Brett

 -Original Message-
 From: Vincent Massol [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, 11 May 2004 4:20 AM
 To: 'Maven Developers List'
 Subject: RE: cvs commit: maven-plugins/artifact/xdocs changes.xml
 
 
 +1 to create an extension tag which defaults to jar:
 
 dependency
   [...]
   typemyowntype/type
   extensionmyowntypeextension/extension
 /dependency
 
 However that's probably for Maven 1.1.
 
 Thanks
 -Vincent
 
  -Original Message-
  From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]
  Sent: 11 May 2004 02:03
  To: Maven Developers List
  Subject: Re: cvs commit: maven-plugins/artifact/xdocs changes.xml
  
  [EMAIL PROTECTED] wrote on 11/05/2004 09:36:35 AM:
  
   brett   2004/05/10 16:36:35
  
 Modified:
 artifact/src/main/org/apache/maven/artifact/deployer
   DefaultArtifactDeployer.java
  artifact/xdocs changes.xml
 Log:
 PR: MPUBERJAR-5
 give uberjar type a jar extension
  
 Revision  ChangesPath
 1.18  +5 -1  maven-
  
 
 plugins/artifact/src/main/org/apache/maven/artifact/deployer/D
 efaultArti
 fa
  ctDeployer.
   java
  
 Index: DefaultArtifactDeployer.java
  
 ===
 RCS file: /home/cvs/maven-
  
 
 plugins/artifact/src/main/org/apache/maven/artifact/deployer/D
 efaultArti
 fa
  ctDeployer.
   java,v
 retrieving revision 1.17
 retrieving revision 1.18
 diff -u -r1.17 -r1.18
 --- DefaultArtifactDeployer.java   2 May 2004 15:04:34 -
 1.17
 +++ DefaultArtifactDeployer.java   10 May 2004 23:36:34 -
 1.18
 @@ -513,6 +513,10 @@
  {
  return jar;
  }
 +else if (type.equals(uberjar))
 +{
 +return jar;
 +}
  return type;
  }
  }
  
  I'd much rather the artifact code externalised the mapping from type
 to
  extension. Otherwise it will become a place of continual churn.
  --
  dIon Gillard, Multitask Consulting
  
  
  
 -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

RE: cvs commit: maven-plugins/artifact/xdocs changes.xml

2004-05-11 Thread Vincent Massol 


 -Original Message-
 From: Brett Porter [mailto:[EMAIL PROTECTED]
 Sent: 11 May 2004 08:48
 To: 'Maven Developers List'
 Subject: RE: cvs commit: maven-plugins/artifact/xdocs changes.xml
 
 Probably? Definitely :)
 
 I don't think this is a per dependency attribute. It's a mapping that
 needs
 to be configurable, but global.

That would be even better... :-)

-Vincent

 
 - Brett
 
  -Original Message-
  From: Vincent Massol [mailto:[EMAIL PROTECTED]
  Sent: Tuesday, 11 May 2004 4:20 AM
  To: 'Maven Developers List'
  Subject: RE: cvs commit: maven-plugins/artifact/xdocs changes.xml
 
 
  +1 to create an extension tag which defaults to jar:
 
  dependency
[...]
typemyowntype/type
extensionmyowntypeextension/extension
  /dependency
 
  However that's probably for Maven 1.1.
 
  Thanks
  -Vincent
 
   -Original Message-
   From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED]
   Sent: 11 May 2004 02:03
   To: Maven Developers List
   Subject: Re: cvs commit: maven-plugins/artifact/xdocs changes.xml
  
   [EMAIL PROTECTED] wrote on 11/05/2004 09:36:35 AM:
  
brett   2004/05/10 16:36:35
   
  Modified:
  artifact/src/main/org/apache/maven/artifact/deployer
DefaultArtifactDeployer.java
   artifact/xdocs changes.xml
  Log:
  PR: MPUBERJAR-5
  give uberjar type a jar extension
   
  Revision  ChangesPath
  1.18  +5 -1  maven-
   
  
  plugins/artifact/src/main/org/apache/maven/artifact/deployer/D
  efaultArti
  fa
   ctDeployer.
java
   
  Index: DefaultArtifactDeployer.java
   
  ===
  RCS file: /home/cvs/maven-
   
  
  plugins/artifact/src/main/org/apache/maven/artifact/deployer/D
  efaultArti
  fa
   ctDeployer.
java,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- DefaultArtifactDeployer.java   2 May 2004 15:04:34 -
  1.17
  +++ DefaultArtifactDeployer.java   10 May 2004 23:36:34 -
  1.18
  @@ -513,6 +513,10 @@
   {
   return jar;
   }
  +else if (type.equals(uberjar))
  +{
  +return jar;
  +}
   return type;
   }
   }
  
   I'd much rather the artifact code externalised the mapping from
type
  to
   extension. Otherwise it will become a place of continual churn.
   --
   dIon Gillard, Multitask Consulting
  
  
  
 
-
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
 
-
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: cvs commit: maven-plugins/artifact/xdocs changes.xml

2004-05-11 Thread Maczka Michal 


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, May 11, 2004 3:31 AM
 To: Maven Developers List
 Subject: RE: cvs commit: maven-plugins/artifact/xdocs changes.xml
 
 
 Brett Porter [EMAIL PROTECTED] wrote on 11/05/2004 
 11:06:38 AM:
 
   Someone who knows the software can do that, but until they 
   do, I'd rather 
   fix the things we have. Didn't Ben write Wagon?
  
  Ben wrote maven-fetch, which I never looked at. I don't 
 know how much of 
 it
  influenced Wagon, which was primarily written by Michal, 
 based on the
  artifact code in the current artifact plugin and the Maven 
 source tree, 
 and
  fixing things like what we are talking about here.
  
  Maven Wagon is a subproject of the Maven top-level project which is 
 nearing
  a release of its own.
  
  Hope that clears up why it doesn't make sense to go 
 tweaking around the
  existing code.
 
 Michal,
 
 when are you going to integrate Wagon?

If you are following the commits logs for maven-components you'll find that
last few days there were quite a lot of them and I am busy working on that.
Things are not yet 100% ready but constantly improving. I have no plan to
attempt to integrate wagon for maven 1.0 
Wagon will be a part of m2 alpha-1 release. Once we have it ready we can try
to backport wagon and higher level componets 
to maven 1.1 or whatever will follow 1.0. This will be deadly simple to do
from point of view of development effort but there are some incompatible
changes.
For example snapshot resolving will work also for ropsitories which do not
let you to check the date of the last modifictation. I have also implemented
a possibility of defing proxy server per each repository. So you can have
two http repositories and accees one with proxy, second without proxy. 
This is helpful for people having coroprate http repositories. There is
quite a lot of such new features which are resolving most of our issuess in 
JIRA releated to artifact handling.



Michal

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: cvs commit: maven-plugins/artifact/xdocs changes.xml

2004-05-11 Thread Jason van Zyl 
On Mon, 2004-05-10 at 15:13, Vincent Massol wrote:
  -Original Message-
  From: Brett Porter [mailto:[EMAIL PROTECTED]
  Sent: 11 May 2004 08:48
  To: 'Maven Developers List'
  Subject: RE: cvs commit: maven-plugins/artifact/xdocs changes.xml
  
  Probably? Definitely :)
  
  I don't think this is a per dependency attribute. It's a mapping that
  needs
  to be configurable, but global.
 
 That would be even better... :-)

Yes, it's called an artifact handler and there is no need for an
extension/ element in a dependency. From the dependencies type the
corresponding artifact handler which encapsulates the artifacts handling
will know, among other things, what the extension is.

Discussion are archived which we had an are probably locatable looking
for type/kind/artifacts. Michal, Rafal and myself were among the
participants that I can recall off hand.

-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://maven.apache.org

happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...

 -- Thoreau 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: cvs commit: maven-plugins/artifact/xdocs changes.xml

2004-05-11 Thread dion_gillard 
Maczka Michal [EMAIL PROTECTED] wrote on 11/05/2004 05:29:56 PM:

 If you are following the commits logs for maven-components you'll find 
that
 last few days there were quite a lot of them and I am busy working on 
that.

I don't follow the commits for maven-components or maven-core.

 Things are not yet 100% ready but constantly improving. I have no plan 
to
 attempt to integrate wagon for maven 1.0 

I don't think Brett would let you :-)

 Wagon will be a part of m2 alpha-1 release. Once we have it ready we can 
try
 to backport wagon and higher level componets 

Is there a reason Wagon is tied to m2?

 to maven 1.1 or whatever will follow 1.0. This will be deadly simple to 
do
 from point of view of development effort but there are some incompatible
 changes.
 For example snapshot resolving will work also for ropsitories which do 
not
 let you to check the date of the last modifictation. I have also 
implemented
 a possibility of defing proxy server per each repository. So you can 
have
 two http repositories and accees one with proxy, second without proxy. 

 This is helpful for people having coroprate http repositories. There is
 quite a lot of such new features which are resolving most of our issuess 
in 
 JIRA releated to artifact handling.

These are all good
--
dIon Gillard, Multitask Consulting


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: cvs commit: maven-plugins/artifact/xdocs changes.xml

2004-05-11 Thread Maczka Michal 
 
  Wagon will be a part of m2 alpha-1 release. Once we have it 
 ready we can 
 try
  to backport wagon and higher level componets 
 
 Is there a reason Wagon is tied to m2?
 

Wagon is not just a better replacement for maven-artifact-plugin. 
First fundamental difference is that it supports round trip transfers or
artifacts.
Artifact fetching is at the moment implemented in maven1 at the core level.
So wagon needs to be integrated at the same level. 
I don't think that our core will live long after we have 1.0 release. 
At the moment really a lot parts of m2 can replace their counterparts in
maven 1 core and imo this is the only way 
to have sufficient architecture and quality of the code which will allow us
to take this project much further.
Wagon is usable as standalone liblary but still needs to be integrated with
maven (it was alredy integarted with m2)
as it will use maven configuration setting for both local and remote
repositories, proxy servers, auth. info and so on.
Those things are often completly absent in maven1 but they already added to
m2 (to the new core).

First release of wagon (version 1.0) with docs etc. is relly close (rather
days then weeks from now). 
It will almost certainly preceed release 1.0 of maven. 

regards!

Michal

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: cvs commit: maven-plugins/artifact/xdocs changes.xml

2004-05-11 Thread Vincent Massol 


 -Original Message-
 From: Jason van Zyl [mailto:[EMAIL PROTECTED]
 Sent: 11 May 2004 11:38
 To: Maven Developers List
 Subject: RE: cvs commit: maven-plugins/artifact/xdocs changes.xml
 
 On Mon, 2004-05-10 at 15:13, Vincent Massol wrote:
   -Original Message-
   From: Brett Porter [mailto:[EMAIL PROTECTED]
   Sent: 11 May 2004 08:48
   To: 'Maven Developers List'
   Subject: RE: cvs commit: maven-plugins/artifact/xdocs changes.xml
  
   Probably? Definitely :)
  
   I don't think this is a per dependency attribute. It's a mapping
that
   needs
   to be configurable, but global.
 
  That would be even better... :-)
 
 Yes, it's called an artifact handler and there is no need for an
 extension/ element in a dependency. From the dependencies type the
 corresponding artifact handler which encapsulates the artifacts
handling
 will know, among other things, what the extension is.
 
 Discussion are archived which we had an are probably locatable looking
 for type/kind/artifacts. Michal, Rafal and myself were among the
 participants that I can recall off hand.

Sure but we were discussing making the artifact handler configurable by
end users (there's currently a artifact handler but it's not
configurable). Is that possible with what you have already discussed
with Michal and Rafal?

Thanks
-Vincent


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: cvs commit: maven-plugins/artifact/xdocs changes.xml

2004-05-10 Thread dion_gillard 
Brett Porter [EMAIL PROTECTED] wrote on 11/05/2004 10:01:39 AM:

 Long term this will happen in Wagon. Now isn't the time to be making 
those
 sorts of changes :)

It's been how long since Wagon was first released? Almost a year I'd 
guess

Promises of Wagon, Classworlds etc are empty for me. I'm happier to do 
these changes post 1.0.
--
dIon Gillard, Multitask Consulting


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: cvs commit: maven-plugins/artifact/xdocs changes.xml

2004-05-10 Thread Brett Porter 
What's the point of doing the work twice? Wagon is the Maven refactoring of
the artifact code. We don't need to start another refactoring of the
artifact code.

We can't afford the development time of maintaining two codebases as
separate entities. They need to converge.

- Brett

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, 11 May 2004 10:34 AM
 To: Maven Developers List
 Subject: RE: cvs commit: maven-plugins/artifact/xdocs changes.xml
 
 
 Brett Porter [EMAIL PROTECTED] wrote on 11/05/2004 
 10:01:39 AM:
 
  Long term this will happen in Wagon. Now isn't the time to be making
 those
  sorts of changes :)
 
 It's been how long since Wagon was first released? Almost a year I'd 
 guess
 
 Promises of Wagon, Classworlds etc are empty for me. I'm 
 happier to do 
 these changes post 1.0.
 --
 dIon Gillard, Multitask Consulting
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

RE: cvs commit: maven-plugins/artifact/xdocs changes.xml

2004-05-10 Thread dion_gillard 
Brett Porter [EMAIL PROTECTED] wrote on 11/05/2004 10:38:15 AM:

 What's the point of doing the work twice? Wagon is the Maven refactoring 
of
 the artifact code. We don't need to start another refactoring of the
 artifact code.

I wasn't planning on refactoring it.

 We can't afford the development time of maintaining two codebases as
 separate entities. They need to converge.
I agree, having two codebases is an incredible waste of effort.

However, I'm not planning on merging Wagon in personally. Nor Classworlds, 
or Maven2.

Someone who knows the software can do that, but until they do, I'd rather 
fix the things we have. Didn't Ben write Wagon?
--
dIon Gillard, Multitask Consulting


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: cvs commit: maven-plugins/artifact/xdocs changes.xml

2004-05-10 Thread Brett Porter 
 Someone who knows the software can do that, but until they 
 do, I'd rather 
 fix the things we have. Didn't Ben write Wagon?

Ben wrote maven-fetch, which I never looked at. I don't know how much of it
influenced Wagon, which was primarily written by Michal, based on the
artifact code in the current artifact plugin and the Maven source tree, and
fixing things like what we are talking about here.

Maven Wagon is a subproject of the Maven top-level project which is nearing
a release of its own.

Hope that clears up why it doesn't make sense to go tweaking around the
existing code.

Cheers,
Brett

RE: cvs commit: maven-plugins/artifact/xdocs changes.xml

2004-05-10 Thread dion_gillard 
Brett Porter [EMAIL PROTECTED] wrote on 11/05/2004 11:06:38 AM:

  Someone who knows the software can do that, but until they 
  do, I'd rather 
  fix the things we have. Didn't Ben write Wagon?
 
 Ben wrote maven-fetch, which I never looked at. I don't know how much of 
it
 influenced Wagon, which was primarily written by Michal, based on the
 artifact code in the current artifact plugin and the Maven source tree, 
and
 fixing things like what we are talking about here.
 
 Maven Wagon is a subproject of the Maven top-level project which is 
nearing
 a release of its own.
 
 Hope that clears up why it doesn't make sense to go tweaking around the
 existing code.

Michal,

when are you going to integrate Wagon?
--
dIon Gillard, Multitask Consulting


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: maven-plugins/artifact/xdocs changes.xml

2004-05-10 Thread dion_gillard 
[EMAIL PROTECTED] wrote on 11/05/2004 09:36:35 AM:

 brett   2004/05/10 16:36:35
 
   Modified:artifact/src/main/org/apache/maven/artifact/deployer
 DefaultArtifactDeployer.java
artifact/xdocs changes.xml
   Log:
   PR: MPUBERJAR-5
   give uberjar type a jar extension
 
   Revision  ChangesPath
   1.18  +5 -1  maven-
 
plugins/artifact/src/main/org/apache/maven/artifact/deployer/DefaultArtifactDeployer.
 java
 
   Index: DefaultArtifactDeployer.java
   ===
   RCS file: /home/cvs/maven-
 
plugins/artifact/src/main/org/apache/maven/artifact/deployer/DefaultArtifactDeployer.
 java,v
   retrieving revision 1.17
   retrieving revision 1.18
   diff -u -r1.17 -r1.18
   --- DefaultArtifactDeployer.java   2 May 2004 15:04:34 -   1.17
   +++ DefaultArtifactDeployer.java   10 May 2004 23:36:34 -   1.18
   @@ -513,6 +513,10 @@
{
return jar;
}
   +else if (type.equals(uberjar))
   +{
   +return jar;
   +}
return type;
}
}

I'd much rather the artifact code externalised the mapping from type to 
extension. Otherwise it will become a place of continual churn.
--
dIon Gillard, Multitask Consulting


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: cvs commit: maven-plugins/artifact/xdocs changes.xml

2004-05-10 Thread Brett Porter 
Long term this will happen in Wagon. Now isn't the time to be making those
sorts of changes :)

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, 11 May 2004 10:03 AM
 To: Maven Developers List
 Subject: Re: cvs commit: maven-plugins/artifact/xdocs changes.xml
 
 
 [EMAIL PROTECTED] wrote on 11/05/2004 09:36:35 AM:
 
  brett   2004/05/10 16:36:35
  
Modified:artifact/src/main/org/apache/maven/artifact/deployer
  DefaultArtifactDeployer.java
 artifact/xdocs changes.xml
Log:
PR: MPUBERJAR-5
give uberjar type a jar extension
  
Revision  ChangesPath
1.18  +5 -1  maven-
  
 plugins/artifact/src/main/org/apache/maven/artifact/deployer/D
 efaultArtifactDeployer.
  java
  
Index: DefaultArtifactDeployer.java

 ===
RCS file: /home/cvs/maven-
  
 plugins/artifact/src/main/org/apache/maven/artifact/deployer/D
 efaultArtifactDeployer.
  java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- DefaultArtifactDeployer.java   2 May 2004 15:04:34 
 -   1.17
+++ DefaultArtifactDeployer.java   10 May 2004 23:36:34 
 -   1.18
@@ -513,6 +513,10 @@
 {
 return jar;
 }
+else if (type.equals(uberjar))
+{
+return jar;
+}
 return type;
 }
 }
 
 I'd much rather the artifact code externalised the mapping 
 from type to 
 extension. Otherwise it will become a place of continual churn.
 --
 dIon Gillard, Multitask Consulting
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]