On 6/07/2006 3:40 AM, Rinku wrote:
Just wondering if rather than having an exclusion list stuffed in each
of dependency elements, if we could have some sort of compatible
tag that can 'advise' Maven the choosing strategy for conflicting
artifacts (pretty much like version ranges).
For sake
Hi Brett,
Brett Porter wrote on Friday, July 07, 2006 8:49 AM:
On 6/07/2006 3:40 AM, Rinku wrote:
[snip]
The other thing is that when an artifact is published to a repo, the
publisher can add some compatibility meta-data as well to indicate
that the current version is incompatible with
On 6/07/2006 1:32 AM, jerome lacoste wrote:
- they typically use a versionning similar to x.y.z-n sometimes
adding. -n can be used to fix packaging issues (POM in the case of
maven). Vendor fixes are also accepted and version names reflect the
vendor name.
Yep, already have that for that very
On 7/07/2006 4:58 PM, Jörg Schaible wrote:
You may also have the need to exclude a version in that range because of a
critical bug. E.g. proxytoys run with CGLIB 2.0, 2.0.2 and 2.1.x ... but not
with 2.0.1, that one had introduced a major bug, that broke proxytoys.
you can already do that
I think we need the necessary auditing in the repository manager for
this first, but it's worth moving on. I'm trying to get that up and
running right now, and writing some internal docs so others can dig in
and do stuff like this.
The ideal is actually to have those segments of the
On 6/07/2006 2:19 AM, Mark Hobson wrote:
Could we not use the syntax 3.7 to represent 'the latest revision of
3.7', whereas 3.7-1 would lock the version down to 3.7 rev 1? So
during development people could use 3.7 to allow updated revisions of
the pom to be pushed to them, and then for
jerome lacoste wrote:
On 7/5/06, Steve Loughran [EMAIL PROTECTED] wrote:
Ralph Goers wrote:
Carlos Sanchez wrote:
Yes you can, it's not the best way to do it but you can, by adding
explicitly the dependency with the versoin you want to your pom. In
the very worst case you have to add all
Or can't Maven offer you to upgrade like it does with plugin (or use to)?
On 7/5/06, Jesse McConnell [EMAIL PROTECTED] wrote:
yep, totally...its just that 3.7 should never be 'fuzzy' from a
dependency standpoint unless it is 3.7-SNAPSHOT or this new idea of
incrementing pom versions for same
Carlos Sanchez wrote:
Yes you can, it's not the best way to do it but you can, by adding
explicitly the dependency with the versoin you want to your pom. In
the very worst case you have to add all transitive deendencies to your
pom, like in Maven 1.
That is so impractical as to be
Brett Porter wrote:
It depends on how you use them as to the best solution here. I assume
that they are customised for cocoon, so they shouldn't be considered
to be the same as the original. In that case, I'd suggest you release
them under your own groupID (maybe org.apache.cocoon.thirdparty)
Thanks Carsten. The first part was certainly already discussed (so you
can see it in the mail archives).
It'd be good if you could file bugs for the last 3 things and we can
schedule them for upcoming releases.
- Brett
On 5/07/2006 4:45 PM, Carsten Ziegeler wrote:
Brett Porter wrote:
The
On Jul 4, 2006, at 6:33 PM, Brett Porter wrote:
On 5/07/2006 10:54 AM, David Jencks wrote:
I think the process is somewhat broken and that the maven team is
being far too strict about changing broken poms that were in fact
installed by the maven team, not supplied by the project.
Hi Ralph,
You've got a general versioning problem here, and you'll find the answer
to how do I do this with Maven? will be more straightforward once
considering the question of how you should generally deal with them. As
you've said, this is already a problem for you as you don't know where
Brett Porter wrote:
The first thing I'd suggest is for those having problems to try another
mirror. I know requiring everyone to do that is a pain and not a long
term solution, but I'd like to see how much that reduces the problem.
I'm not sure if the following problem has already been
Brett Porter wrote:
Hi Ralph,
There are a couple of options for addressing this use case in Maven.
- include the JARs in SVN, and reference it as an additional repository
file://localhost/${basedir}/extra-jar-repo
When you declare such a repository in your parent pom, the child poms
Jason van Zyl wrote:
On 4 Jul 06, at 1:45 PM 4 Jul 06, Steve Loughran wrote:
In a way, many of the stuff in M2 is experimental; a build tool that
effectively encodes beliefs about how a project should be structured
and delivered, focusing on component-based development instead of
On 7/5/06, David Jencks [EMAIL PROTECTED] wrote:
On Jul 4, 2006, at 6:33 PM, Brett Porter wrote:
On 5/07/2006 10:54 AM, David Jencks wrote:
I think the process is somewhat broken and that the maven team is
being far too strict about changing broken poms that were in fact
installed by the
On 7/5/06, Ralph Goers [EMAIL PROTECTED] wrote:
Carlos Sanchez wrote:
Yes you can, it's not the best way to do it but you can, by adding
explicitly the dependency with the versoin you want to your pom. In
the very worst case you have to add all transitive deendencies to your
pom, like in
Brett Porter wrote:
Hi Ralph,
You've got a general versioning problem here, and you'll find the answer
to how do I do this with Maven? will be more straightforward once
considering the question of how you should generally deal with them. As
you've said, this is already a problem for you as
On 7/5/06, Stephen Duncan [EMAIL PROTECTED] wrote:
On 7/4/06, Carlos Sanchez [EMAIL PROTECTED] wrote:
On 7/5/06, Stephen Duncan [EMAIL PROTECTED] wrote:
On 7/4/06, Jason van Zyl [EMAIL PROTECTED] wrote:
On 4 Jul 06, at 2:37 PM 4 Jul 06, Steve Loughran wrote:
The metadata will
Not a bulletproof one (there's ${user.dir}, but that's only right 90% of
the time). In a multiproject scenario, you might be better off putting
the individual jars in as stubbed projects:
parent pom:
modulejar-in-svn/module
...
jar-in-svn/pom.xml: the POM from the repository, but add a copy
Carlos Sanchez wrote:
so... you can do it.
In m1 anybody can override the build.properties as in m2 they can put
a different version.
Pardon me for going on and on about this, but the reality is that, at
least in my organization, anybody cannot override the
build.properties. When our CM team
]
Sent: Tuesday, July 04, 2006 10:13 AM
To: Maven Developers List
Cc: dev@cocoon.apache.org
Subject: Re: [RANT] This Maven thing is killing us
On 4/07/2006 9:34 PM, Torsten Curdt wrote:
I agree that the whole maven2 situation is currently far less than
just acceptable ...but TBH I am not sure
Ralph Goers wrote:
Carlos Sanchez wrote:
Yes you can, it's not the best way to do it but you can, by adding
explicitly the dependency with the versoin you want to your pom. In
the very worst case you have to add all transitive deendencies to your
pom, like in Maven 1.
That is so impractical
On 7/5/06, Steve Loughran [EMAIL PROTECTED] wrote:
Ralph Goers wrote:
Carlos Sanchez wrote:
Yes you can, it's not the best way to do it but you can, by adding
explicitly the dependency with the versoin you want to your pom. In
the very worst case you have to add all transitive deendencies
Mike Perham wrote:
The more I think about it, the more I agree with this. I believe we
will need to start using this -n versioning for POM fixes. It's easy to
develop and test a java module but screw up the POM and make it unusable
to the public. How long and how many revisions did it take
sometimes it makes me wonder how gentoo manages their ebuilds.
portage and maven both supports transitive dependencies, but somehow
the portage ebuilds which can be compared to the maven pom is more
stable and reliable. currently the number of portage ebuilds is
around 24,000+,
a
Hello all,
A while back I suggested that the Maven team delegate some of the
reponsibility of maintaining the ibiblio repo to volunteers (as in the linux
equivalent, as Jerome has noted earlier in the thread). Each such voluteer
can maintain a specific area in the repo; so, someone who uses
On 05/07/06, Steve Loughran [EMAIL PROTECTED] wrote:
OK, but the other part of the problem is pushing the changes out to the
user.
in a linux distro, what you are effectively buying is a set of artifacts
compiled on the same gcc version/options, and a subscription that keeps
your box up to
I remember more or less who makes good upload requests and who doesn't ;)
Anyway that's why the field in jira proving that you're a member of
the project is. If you are member and you request an upload that goes
directly without checking correctness if the group already exist.
We can start a
On 05/07/06, Arik Kfir [EMAIL PROTECTED] wrote:
Hello all,
A while back I suggested that the Maven team delegate some of the
reponsibility of maintaining the ibiblio repo to volunteers (as in the linux
equivalent, as Jerome has noted earlier in the thread). Each such voluteer
can maintain a
+1, really great idea.
On 7/5/06, Mark Hobson [EMAIL PROTECTED] wrote:
On 05/07/06, Arik Kfir [EMAIL PROTECTED] wrote:
Hello all,
A while back I suggested that the Maven team delegate some of the
reponsibility of maintaining the ibiblio repo to volunteers (as in the linux
equivalent, as
might be better off using the version ranges notation for this kind of
thing, I don't think you want to get into the habit of x.y being some
kinda fuzzy defintion, it should refer to a specific version.
[3.7,) or something along those lines...
On 05/07/06, Jesse McConnell [EMAIL PROTECTED] wrote:
might be better off using the version ranges notation for this kind of
thing, I don't think you want to get into the habit of x.y being some
kinda fuzzy defintion, it should refer to a specific version.
[3.7,) or something along those
yep, totally...its just that 3.7 should never be 'fuzzy' from a
dependency standpoint unless it is 3.7-SNAPSHOT or this new idea of
incrementing pom versions for same jar.
in freebsd versioning this would be equivalent to something like
treating this 3.7-1 deal as 3.7-STABLE which could be
Just wondering if rather than having an exclusion list stuffed in each
of dependency elements, if we could have some sort of compatible
tag that can 'advise' Maven the choosing strategy for conflicting
artifacts (pretty much like version ranges).
For sake of an example:
dependencies
Sorry, for the cross-post ...but it seems we need a dialog here
somehow. We now have two threads on two different mailing
lists/communities that really should talk to each other.
I propose to commit again all JARs into, say, cocoon/trunk/m2repo
and then tell Maven at build time to use that
Hi,
just to mention a Maven Proxy alternative Proximity, that collects these
kind of stats. Currently (ver RC2) contains a simple Stat implementation
that is not transient (on restart it forgets the stats) and it offers only
few a top10 views just to demonstrate the feature, the final release
Torsten Curdt wrote:
Sorry, for the cross-post ...but it seems we need a dialog here
somehow. We now have two threads on two different mailing
lists/communities that really should talk to each other.
I propose to commit again all JARs into, say, cocoon/trunk/m2repo
and then tell Maven at build
The repository is as good as the users/projects make it. There's no
difference at all with using ant and including the wrong jars, maybe
the problem is that how to fix it in maven is not as easy as in ant.
If project A says it depends on B 1.0 and C says it depends on B 1.1,
there's a conflict
Please, let's not go overboardAnt is nice like c is nice when you need
to get small things done. If you have to maintain very large projects with
varying releases/users/etc maven is a much better choice. Even with its
current flaws. =p
On 7/4/06, Steve Loughran [EMAIL PROTECTED] wrote:
Carlos Sanchez wrote:
The repository is as good as the users/projects make it. There's no
difference at all with using ant and including the wrong jars, maybe
the problem is that how to fix it in maven is not as easy as in ant.
If project A says it depends on B 1.0 and C says it depends on B
Hi!
If project A says it depends on B 1.0 and C says it depends on B 1.1,
there's a conflict in Maven, Ant and anything you want to use, the
difference is that Maven tries to do it for you, but you still can
override that behaviour.
We also ended up putting our jars in svn again and using only
The replace dependency is alredy logged in jira. Not sure about the
conflict one.
On 7/4/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
If project A says it depends on B 1.0 and C says it depends on B 1.1,
there's a conflict in Maven, Ant and anything you want to use, the
difference is
Jesse Kuhnert wrote:
Please, let's not go overboardAnt is nice like c is nice when you need
to get small things done. If you have to maintain very large projects with
varying releases/users/etc maven is a much better choice. Even with its
current flaws. =p
I'm not arguing with that, its
Say if xmlrpc decide to split into xmlrpc-common, xmlrpc-server,
xmlrpc-client, xmlrcp-all then it can say that it conflict with xmlrpc
- and for xmlrpc-all it can say that it replace xmlrpc.
Still, user intervention is required, but thats better than having the
same library on the path
I think having a transitive dependency repository is good. Of course,
you depend upon the community good willing but it is the same
principle for a wiki. Quality will increase if more and more people
participate. I think the Maven Evangelisation guide should be more
visible on the Maven web site
On 4/07/2006 9:34 PM, Torsten Curdt wrote:
I agree that the whole maven2 situation is currently far less than
just acceptable ...but TBH I am not sure the maven team is (or was?)
really aware of all the problems we have.
Not until you forwarded a message (and thanks for doing so). We don't
On Tuesday 04 July 2006 20:53, Carlos Sanchez wrote:
If project A says it depends on B 1.0 and C says it depends on B 1.1,
there's a conflict in Maven, Ant and anything you want to use, the
difference is that Maven tries to do it for you, but you still can
override that behaviour.
Well, since
On 4 Jul 06, at 1:45 PM 4 Jul 06, Steve Loughran wrote:
In a way, many of the stuff in M2 is experimental; a build tool
that effectively encodes beliefs about how a project should be
structured and delivered, focusing on component-based development
instead of application dev. I also
On 4 Jul 06, at 2:37 PM 4 Jul 06, Steve Loughran wrote:
Carlos Sanchez wrote:
The repository is as good as the users/projects make it. There's no
difference at all with using ant and including the wrong jars, maybe
the problem is that how to fix it in maven is not as easy as in ant.
If
On 7/4/06, Jason van Zyl [EMAIL PROTECTED] wrote:
On 4 Jul 06, at 2:37 PM 4 Jul 06, Steve Loughran wrote:
The metadata will never be perfect but right now I still
think it's far from being ideal because we have no real active
process of improving it on a large scale. Carlos puts in a _lot_ of
Carlos Sanchez wrote:
If project A says it depends on B 1.0 and C says it depends on B 1.1,
there's a conflict in Maven, Ant and anything you want to use, the
difference is that Maven tries to do it for you, but you still can
override that behaviour.
Actually, you can't in Maven 2 - at least
On 7/5/06, Stephen Duncan [EMAIL PROTECTED] wrote:
On 7/4/06, Jason van Zyl [EMAIL PROTECTED] wrote:
On 4 Jul 06, at 2:37 PM 4 Jul 06, Steve Loughran wrote:
The metadata will never be perfect but right now I still
think it's far from being ideal because we have no real active
process of
On 7/4/06, Ralph Goers [EMAIL PROTECTED] wrote:
Carlos Sanchez wrote:
If project A says it depends on B 1.0 and C says it depends on B 1.1,
there's a conflict in Maven, Ant and anything you want to use, the
difference is that Maven tries to do it for you, but you still can
override that
Ralph,
Thanks for this, it's very helpful.
On 5/07/2006 6:59 AM, Ralph Goers wrote:
However, this isn't even the biggest problem that has been hampering the
Cocoon community. It is that there seems to be at best a 50% chance of
getting a Maven 2 based Cocoon build to work due to dependencies
On 7/4/06, Carlos Sanchez [EMAIL PROTECTED] wrote:
On 7/5/06, Stephen Duncan [EMAIL PROTECTED] wrote:
On 7/4/06, Jason van Zyl [EMAIL PROTECTED] wrote:
On 4 Jul 06, at 2:37 PM 4 Jul 06, Steve Loughran wrote:
The metadata will never be perfect but right now I still
think it's far from
On Jul 4, 2006, at 5:16 PM, Carlos Sanchez wrote:
On 7/5/06, Stephen Duncan [EMAIL PROTECTED] wrote:
On 7/4/06, Jason van Zyl [EMAIL PROTECTED] wrote:
On 4 Jul 06, at 2:37 PM 4 Jul 06, Steve Loughran wrote:
The metadata will never be perfect but right now I still
think it's far from
On 5/07/2006 10:54 AM, David Jencks wrote:
I think the process is somewhat broken and that the maven team is being
far too strict about changing broken poms that were in fact installed by
the maven team, not supplied by the project. (xmlbeans is the case in
point for me). I also think that
Brett Porter wrote on Monday, July 03, 2006 2:27 PM:
The original snapshot feature works just fine.
There was a particular variation of the feature added that
doesn't work
as designed. (MNG-1908). The variation works exactly the same way but
reuses the file on the server.
Using
On 5/07/2006 3:51 PM, Jörg Schaible wrote:
C'mon. The opposite behaviour was the default for Maven 1, where this worked perfectly.
And everyone complained about how slow it was. As I said, there is a
working fix in MNG-1908, but it is not in the release because the
performance is, IMO,
List
Betreff: Re: [RANT] This Maven thing is killing us
I don't know what you're saying, you are the first one
complaining about it. SNAPSHOTS work for me
On 7/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Unfortunately the SNAPSHOT-feature is broken (at least in
2.0.4): When you
Nachricht-
Von: Wendy Smoak [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 3. Juli 2006 01:35
An: Maven Developers List
Betreff: Re: [RANT] This Maven thing is killing us
On 7/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Unfortunately the SNAPSHOT-feature is broken (at least
[EMAIL PROTECTED] wrote:
Unfortunately the SNAPSHOT-feature is broken (at least in 2.0.4): When you have a
copy of a snapshot versioned artifact, the jar is not updated when a new jar with
same snapshot version is uploaded to the repository. I already filed this as a bug
and hope it will be
Edwin Punzalan wrote:
May I add, that when maven already downloaded a poor/invalid pom, even
after fixing the pom in the repository, maven won't know that it's
changed (unless the version changed) and it will not download it. So
you end up still using your local repo copy.
To re-download
The original snapshot feature works just fine.
There was a particular variation of the feature added that doesn't work
as designed. (MNG-1908). The variation works exactly the same way but
reuses the file on the server.
Using uniqueVersion = false (the default) and a clean up script on the
On 3/07/2006 10:22 PM, Steve Loughran wrote:
I'm kind of busy right now, so am not offering to do this, not until,
say, September. But otherwise, it would be a really interesting thing to
work on. Anyone interesting in co-authoring?
Yep, I've been thinking about these issues for a while (and
Brett Porter wrote:
On 3/07/2006 10:22 PM, Steve Loughran wrote:
I'm kind of busy right now, so am not offering to do this, not until,
say, September. But otherwise, it would be a really interesting thing
to work on. Anyone interesting in co-authoring?
Yep, I've been thinking about these
14:27
An: Maven Developers List
Betreff: Re: AW: [RANT] This Maven thing is killing us
The original snapshot feature works just fine.
There was a particular variation of the feature added that
doesn't work as designed. (MNG-1908). The variation works
exactly the same way but reuses
On 4/07/2006 12:49 AM, [EMAIL PROTECTED] wrote:
Hi!
Brett, can you give some more information about the cleanup script on the server? I found nothing in JIRA. It would be a great help for us if a simple server solution exists.
There isn't anything prepared, but if you do so I'm sure it would
Mike Perham wrote:
-Original Message-
From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
Sent: Saturday, July 01, 2006 2:59 PM
To: Maven Developers List
Subject: RE: [RANT] This Maven thing is killing us
Perhaps we can have a rule that every dependency MUST
Mike Perham wrote:
-Original Message-
From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
Sent: Saturday, July 01, 2006 2:59 PM
To: Maven Developers List
Subject: RE: [RANT] This Maven thing is killing us
Perhaps we can have a rule that every dependency MUST have
Developers List
Subject: RE: [RANT] This Maven thing is killing us
Perhaps we can have a rule that every dependency MUST have
a declared
scope and optional element so that we know the
developer has thought
about the correct values for them, rather than always using
: Kenney Westerhof [mailto:[EMAIL PROTECTED]
Sent: Saturday, July 01, 2006 2:59 PM
To: Maven Developers List
Subject: RE: [RANT] This Maven thing is killing us
Perhaps we can have a rule that every dependency MUST have
a declared
scope and optional element
solution though:
http://jira.codehaus.org/browse/MNG-1258
Mike Perham wrote:
-Original Message-
From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
Sent: Saturday, July 01, 2006 2:59 PM
To: Maven Developers List
Subject: RE: [RANT] This Maven thing is killing us
local
repository...
Roger
-Ursprüngliche Nachricht-
Von: Andrew Williams [mailto:[EMAIL PROTECTED]
Gesendet: Sonntag, 2. Juli 2006 11:11
An: Maven Developers List
Betreff: Re: [RANT] This Maven thing is killing us
This is only true for release repositories though
-Ursprüngliche Nachricht-
Von: Andrew Williams [mailto:[EMAIL PROTECTED]
Gesendet: Sonntag, 2. Juli 2006 11:11
An: Maven Developers List
Betreff: Re: [RANT] This Maven thing is killing us
This is only true for release repositories though, as a
snapshot repository will have an updated version
repository...
Roger
-Ursprüngliche Nachricht-
Von: Andrew Williams [mailto:[EMAIL PROTECTED]
Gesendet: Sonntag, 2. Juli 2006 11:11
An: Maven Developers List
Betreff: Re: [RANT] This Maven thing is killing us
This is only true for release repositories though
PROTECTED]
Gesendet: Sonntag, 2. Juli 2006 11:11
An: Maven Developers List
Betreff: Re: [RANT] This Maven thing is killing us
This is only true for release repositories though, as a
snapshot repository will have an updated version when you
re-deploy surely?
Andy
Now, they're referring to when uniqueVersion = false (which is not the
default). That feature has always been broken, it was only discovered
recently though, and when I attempted to fix it for 2.0.4 it caused a
performance degradation and I decided to hold off until it could be more
fully
You are right. It was turned off in the late betas because we were'nt
going to have time to verify the entire repository.
With the availability of tools, I think this could be reinstated for
2.1, but I've since rethought it and would rather do this in a way that
is more predictable (ie, even
On 7/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Unfortunately the SNAPSHOT-feature is broken (at least in 2.0.4): When you have a
copy of a snapshot versioned artifact, the jar is not updated when a new jar with
same snapshot version is uploaded to the repository. I already filed this as
yes, that's the one I was referring to, thanks!
On 3/07/2006 9:35 AM, Wendy Smoak wrote:
On 7/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Unfortunately the SNAPSHOT-feature is broken (at least in 2.0.4): When
you have a copy of a snapshot versioned artifact, the jar is not
updated when a
On 6/30/06, Mike Perham [EMAIL PROTECTED] wrote:
I'll spare you the details on that one
This does nothing to solve the problem. We can't fix what we don't know
about...
Sorry about that, if was meaning to write to the Maven list with more
precise information later, my email was meant for the
] This Maven thing is killing us
FYI
-- Forwarded message --
From: Bertrand Delacretaz [EMAIL PROTECTED]
Date: Jun 30, 2006 5:58 PM
Subject: [RANT] This Maven thing is killing us
To: dev@cocoon.apache.org
Hi gang,
It's Friday, I'm tired and a bit
-Original Message-
From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
Sent: Saturday, July 01, 2006 2:59 PM
To: Maven Developers List
Subject: RE: [RANT] This Maven thing is killing us
Perhaps we can have a rule that every dependency MUST have
a declared
scope
to delete your local copy first.
This is a good solution though: http://jira.codehaus.org/browse/MNG-1258
Mike Perham wrote:
-Original Message-
From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
Sent: Saturday, July 01, 2006 2:59 PM
To: Maven Developers List
Subject: RE: [RANT] This Maven thing
FYI
-- Forwarded message --
From: Bertrand Delacretaz [EMAIL PROTECTED]
Date: Jun 30, 2006 5:58 PM
Subject: [RANT] This Maven thing is killing us
To: dev@cocoon.apache.org
Hi gang,
It's Friday, I'm tired and a bit depressed after losing about two more
hours unsuccessfully
, rather than always using the
defaults?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Torsten Curdt
Sent: Friday, June 30, 2006 12:06 PM
To: Maven Developers List
Subject: Fwd: [RANT] This Maven thing is killing us
FYI
-- Forwarded
, rather than always using the
defaults?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Torsten Curdt
Sent: Friday, June 30, 2006 12:06 PM
To: Maven Developers List
Subject: Fwd: [RANT] This Maven thing is killing us
FYI
-- Forwarded
On 6/30/06, Torsten Curdt [EMAIL PROTECTED] wrote:
FYI
-- Forwarded message --
From: Bertrand Delacretaz [EMAIL PROTECTED]
Date: Jun 30, 2006 5:58 PM
Subject: [RANT] This Maven thing is killing us
To: dev@cocoon.apache.org
Is anyone here using Cocoon? They could probably
91 matches
Mail list logo
