RE: cvs commit: maven-plugins/artifact/xdocs changes.xml
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? > We have only dissussed the idea itself not the implementation details. I don't see any reasons why handlers should not be "configurable" by users. regards Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: maven-plugins/artifact/xdocs changes.xml
> -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 > 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
> -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 > 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
> > 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
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
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 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
> -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
> -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 tag which defaults to "jar":
> >
> >
> > [...]
> > myowntype
> > myowntypeextension
> >
> >
> > 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
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 tag which defaults to "jar":
>
>
> [...]
> myowntype
> myowntypeextension
>
>
> 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
+1 to create an tag which defaults to "jar":
[...]
myowntype
myowntypeextension
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
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
> 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
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
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
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
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]
>
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/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]
