Forgot to mention another reason why it might be a good idea
to convert the Model and its depenent classes to interfaces
and use default objects. Store optimization requirements
may necessitate the tracking of whether or not instances of
these objects are dirty. Underlying implementations may
Hi,
Sorry my shxty mail client and jittery cafinated fingers prematurely
sent my last email incomplete so I'm resending it again.
As I recommended I would use the factory method pattern here where
the creator is the factory. The ModelFactory interface is the
interface for all factory implementa
>
> From: Brett Porter <[EMAIL PROTECTED]>
> Date: 2004/01/11 Sun PM 05:13:01 EST
> To: "'Maven Developers List'" <[EMAIL PROTECTED]>
> Subject: RE: maven-model-tools to maven-model-xml
>
> I was about to say the same thing :)
>
> I think this is the right way to go, although I still think we s
>
> From: Jason van Zyl <[EMAIL PROTECTED]>
> Date: 2004/01/11 Sun PM 05:05:26 EST
> To: Maven Developers List <[EMAIL PROTECTED]>
> Subject: RE: maven-model-tools to maven-model-xml
>
> On Sun, 2004-01-11 at 16:50, Brett Porter wrote:
> > Do we really need N libraries each containing two classe
Brett,
> Do we really need N libraries each containing two classes?
>
> I would think there should be one interface to marshal/unmarshal a model
> from a source, and then N providers. maven-model-tools can provide the main
> ones we want to distribute, but others could be plugged in by third part
Jason,
Thanks for all your help!
>
> From: Jason van Zyl <[EMAIL PROTECTED]>
> I was going to move maven-model-tools to maven-model-xml to indicate the
> model being in XML form. I'm doing so as Alex wants to try and make a
> tool that pulls the model from LDAP so 'maven-model-tools' isn't exac
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MPIDEA-2
Here is an overview of the issue:
---
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MPEJB-8
Here is an overview of the issue:
bwalding2004/01/11 16:00:30
Removed: maven-core/src/java/org/apache/maven/jelly/tags/maven
DependencyResolver.java
WerkzDependencyResolver.java
DependencyResolverInterface.java
Log:
Removed.
bwalding2004/01/11 16:00:07
Removed: maven-core/src/test/java/org/apache/maven/jelly/tags/maven
DependencyResolverTest.java
DependencyResolverTestData.java
Log:
Removed.
-
On Sun, 2004-01-11 at 17:20, Brett Porter wrote:
> Is it possible you could also release a timestamped snapshot to ibiblio and
> have maven-core reference that so that it is one less thing that can be
> different when testing it out?
Sure, no problem. I just changed things to work with timestamps
Is it possible you could also release a timestamped snapshot to ibiblio and
have maven-core reference that so that it is one less thing that can be
different when testing it out?
Last attempt I had (CVS from Friday), it bootstraps fine but jar:jar is not
found and there are a bunch of exceptions.
jvanzyl 2004/01/11 14:18:27
Modified:maven-project project.xml
Log:
o use the snaps
Revision ChangesPath
1.9 +6 -32 maven-components/maven-project/project.xml
Index: project.xml
===
RCS fil
jvanzyl 2004/01/11 14:17:48
Modified:maven-model-xpp3 project.xml
Log:
o use snap until we reach stability
Revision ChangesPath
1.9 +3 -3 maven-components/maven-model-xpp3/project.xml
Index: project.xml
===
jvanzyl 2004/01/11 14:17:24
Modified:maven-model project.xml
Log:
o we'll just keep using a SNAPSHOT until we reach stability.
Revision ChangesPath
1.6 +1 -1 maven-components/maven-model/project.xml
Index: project.xml
I was about to say the same thing :)
I think this is the right way to go, although I still think we should give
several common providers in one JAR file as long as additional deps doesn't
increase what maven needs to start with (so xpp3, xstream, and
XML-over-HTTP-from-a-repository are probably ok
On Sun, 2004-01-11 at 12:00, Jason van Zyl wrote:
> Howdy,
>
> I was going to move maven-model-tools to maven-model-xml to indicate the
> model being in XML form. I'm doing so as Alex wants to try and make a
> tool that pulls the model from LDAP so 'maven-model-tools' isn't exactly
> a helpful or
On Sun, 2004-01-11 at 16:50, Brett Porter wrote:
> Do we really need N libraries each containing two classes?
>
> I would think there should be one interface to marshal/unmarshal a model
> from a source, and then N providers. maven-model-tools can provide the main
> ones we want to distribute, but
On Sun, 2004-01-11 at 16:50, Brett Porter wrote:
> Do we really need N libraries each containing two classes?
If component pulling from a different source certainly should be in
separate builds.
> I would think there should be one interface to marshal/unmarshal a model
> from a source, and then N
Submit the patch against HEAD, and just note that it includes those other
patches (the risk here is that if they are not applied, you will probably
have to re-do the patch anyway), or give it against a clean HEAD without
those other patches.
Cheers,
Brett
> -Original Message-
> From: Mike
Do we really need N libraries each containing two classes?
I would think there should be one interface to marshal/unmarshal a model
from a source, and then N providers. maven-model-tools can provide the main
ones we want to distribute, but others could be plugged in by third parties
if they wanted
On Sun, 2004-01-11 at 16:28, [EMAIL PROTECTED] wrote:
> Jason van Zyl <[EMAIL PROTECTED]> wrote on 12/01/2004 04:39:57 AM:
>
> > Howdy,
> >
> > This is primarily for Brett but it's a general outline of today's
> > chores.
> >
> > I found the problem with the Jelly/Ant interaction which was intro
Jason van Zyl <[EMAIL PROTECTED]> wrote on 12/01/2004 04:39:57 AM:
> Howdy,
>
> This is primarily for Brett but it's a general outline of today's
> chores.
>
> I found the problem with the Jelly/Ant interaction which was introduced
> when I rolled the Ant tags into the core. There were bits and
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MCOMPONENTS-8
Here is an overview of the issue:
--
Howdy,
This is primarily for Brett but it's a general outline of today's
chores.
I found the problem with the Jelly/Ant interaction which was introduced
when I rolled the Ant tags into the core. There were bits and pieces
being used from Maven itself and from the Ant tag. There were two
JellyProp
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MCOMPONENTS-7
Here is an overview of the issue:
--
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MCOMPONENTS-6
Here is an overview of the issue:
--
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MCOMPONENTS-5
Here is an overview of the issue:
--
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MCOMPONENTS-4
Here is an overview of the issue:
--
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MCOMPONENTS-3
Here is an overview of the issue:
--
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MCOMPONENTS-2
Here is an overview of the issue:
--
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MCOMPONENTS-1
Here is an overview of the issue:
--
Howdy,
I was going to move maven-model-tools to maven-model-xml to indicate the
model being in XML form. I'm doing so as Alex wants to try and make a
tool that pulls the model from LDAP so 'maven-model-tools' isn't exactly
a helpful or meaningful name. So was thinking it could grow for things
like
On Sun, 2004-01-11 at 10:24, [EMAIL PROTECTED] wrote:
> bwalding2004/01/11 07:24:30
>
> Added: maven-core/src/java/org/apache/maven/jelly/tags/maven
> DependencyResolver.java
> WerkzDependencyResolver.java
> Depend
bwalding2004/01/11 07:26:07
Added: maven-core/src/test/java/org/apache/maven/jelly/tags/maven
DependencyResolverTest.java
DependencyResolverTestData.java
Log:
Ported from the old maven and upgraded to fit in more properly.
Revisi
bwalding2004/01/11 07:25:40
maven-components/maven-core/src/test/java/org/apache/maven/jelly/tags/maven - New
directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
bwalding2004/01/11 07:24:30
Added: maven-core/src/java/org/apache/maven/jelly/tags/maven
DependencyResolver.java
WerkzDependencyResolver.java
DependencyResolverInterface.java
Log:
Ported from the old maven and
dion2004/01/11 05:05:22
Modified:src/java/org/apache/maven Tag: MAVEN-1_0-BRANCH
MavenSession.java
Log:
javadocs
Revision ChangesPath
No revision
No revision
1.18.4.2 +5 -4 maven/src/java/org/apache
dion2004/01/11 04:43:16
Modified:src/java/org/apache/maven/project Tag: MAVEN-1_0-BRANCH
UnitTest.java
Log:
Code cleanup
Revision ChangesPath
No revision
No revision
1.11.10.2 +3 -3 maven/src/java/or
Just getting into the reactor and I've found what looks like an error in
logic to me. Shouldn't it be (in the code pasted below)
if (!blah blah blah)
I've got the reactor tag ordering thingamajig working now. Will start
committing it later tonight.
Cheers,
Ben
/**
* Add a unique depend
Jason van Zyl <[EMAIL PROTECTED]> wrote on 11/01/2004 04:08:00 PM:
> On Sat, 2004-01-10 at 20:07, [EMAIL PROTECTED] wrote:
>
> > Any reason to remove the class javadoc?
>
> Majority of is either generated, only partially correct or just plain
> wrong. In most cases I find nothing is better as it
41 matches
Mail list logo
