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) s
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 nonsensical.
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, unacce
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 u
On 7/5/06, Brett Porter <[EMAIL PROTECTED]> wrote:
I don't believe anyone is working on it. Create a JIRA issue and assign
it to yourself so that we know you are, though :)
Thanks Dennis!
- Brett
On 5/07/2006 10:28 AM, Dennis Lundberg wrote:
> Hi
>
> I thought that I'd have a go at restructuri
+1
On 7/5/06, Brett Porter <[EMAIL PROTECTED]> wrote:
+1
On 5/07/2006 10:37 AM, Dennis Lundberg wrote:
> Hi
>
> I'm in the process of relocating Jakarta commons components from groupID
> commons- to org.apache.commons. To be able to do this
> correctly I've had much help from Carlos. As this mi
On Mon, Jul 03, 2006 at 05:07:47PM +0100, Mark Hobson wrote:
> Hi there,
>
> I was wondering whether any thought had been given to an abstract
> issue tracking API with implementations for Bugzilla, JIRA, etc.?
>
> I can see a couple of uses within maven:
>
> * Querying the issues fixed when rele
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 tr
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 f
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
> > thin
+1
On 5/07/2006 10:37 AM, Dennis Lundberg wrote:
Hi
I'm in the process of relocating Jakarta commons components from groupID
commons- to org.apache.commons. To be able to do this
correctly I've had much help from Carlos. As this might be something
that others will face, I thought it would be
Hi
I'm in the process of relocating Jakarta commons components from groupID
commons- to org.apache.commons. To be able to do this
correctly I've had much help from Carlos. As this might be something
that others will face, I thought it would be a good idea to create some
documentation for it.
I don't believe anyone is working on it. Create a JIRA issue and assign
it to yourself so that we know you are, though :)
Thanks Dennis!
- Brett
On 5/07/2006 10:28 AM, Dennis Lundberg wrote:
Hi
I thought that I'd have a go at restructuring/expanding the docs for the
maven-jar-plugin, accord
Hi
I thought that I'd have a go at restructuring/expanding the docs for the
maven-jar-plugin, according to the new guidelines for plugins. Before I
dive in, I thought it would be best to ask if somebody else is working
on this.
This would include fixing MJAR-46 and MJAR-47 in some way.
--
D
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 f
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 th
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
> proc
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 no
Thanks for pulling me in Jason, this is good timing. In terms of Mylar's
'Connectors' we currently have a robust and well tested framework for
querying Bugzilla and JIRA. Trac will be ready for experimentation within a
week or so, and no, there is no Mantis connector yet. The Bugzilla
connector
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
On 7/4/06, Steve Loughran <[EMAIL PROTECTED]> wrote:
That'll be the ant-that-has-to-support-java-1.2 on
everything-and-build-with-no-dependencies, won't it?
Be that as it may, but personally I prefer this over the
maven-which-needs-thousands-of-jars-from-codehaus-for-whatever
approach... :-)
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 project
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 think
Brett Porter wrote:
On 4/07/2006 8:16 PM, Steve Loughran wrote:
very +1 too, though I'd like it decoupled from any partiucular build
tool if possible, primarily because you can do other things outside
the build itself. Imagine apps auto-opening bugreps on system crashes,
for example.
None of
On 4 Jul 06, at 11:16 AM 4 Jul 06, Steve Loughran wrote:
Vincent Massol wrote:
+1. Actually I thought there was already a project for this but I was
probably anticipating...
* SCM for SCMs
* Wagon for transports
* Cargo for containers
... Spoor for bug trackers (or whatever other name!)
-Vince
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, si
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
rea
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 b
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 mul
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 the
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
> differenc
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 o
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:
Ca
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 1.1
A generic activity management API would get a big +1 from me (re naming, we use
JIRA for much more than bug tracking)
While building an integrated ALM environment i had to cobble together some
build system interfaces too - a common API for such systems would be very
useful too?
(LuntBuild/Quic
On 7/4/06, Brett Porter <[EMAIL PROTECTED]> wrote:
On 4/07/2006 8:16 PM, Steve Loughran wrote:
> very +1 too, though I'd like it decoupled from any partiucular build
> tool if possible, primarily because you can do other things outside the
> build itself. Imagine apps auto-opening bugreps on syst
On 4/07/2006 8:16 PM, Steve Loughran wrote:
very +1 too, though I'd like it decoupled from any partiucular build
tool if possible, primarily because you can do other things outside the
build itself. Imagine apps auto-opening bugreps on system crashes, for
example.
None of the shared libraries
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 in
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
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 direc
On 04/07/06, Steve Loughran <[EMAIL PROTECTED]> wrote:
very +1 too, though I'd like it decoupled from any partiucular build
tool if possible, primarily because you can do other things outside the
build itself. Imagine apps auto-opening bugreps on system crashes, for
example.
I agree, and this i
Vincent Massol wrote:
+1. Actually I thought there was already a project for this but I was
probably anticipating...
* SCM for SCMs
* Wagon for transports
* Cargo for containers
... Spoor for bug trackers (or whatever other name!)
-Vincent
very +1 too, though I'd like it decoupled from any p
On 04/07/06, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
An XML-RPC API is in the works. AFAIK, it's on the roadmap for Bugzilla 2.24.
You're right, I wasn't aware of this thanks:
https://bugzilla.mozilla.org/show_bug.cgi?id=224577
Should make the bugzilla implementation *alot* easier.
Mark
On 7/4/06, Mark Hobson <[EMAIL PROTECTED]> wrote:
both projects could share the same abstraction. Communication with
Bugzilla is rather tedious and Mylar's implementation seems quite
comprehensive.
An XML-RPC API is in the works. AFAIK, it's on the roadmap for Bugzilla 2.24.
Jochen
--
Whene
Cool, good to see things are moving in that direction. I did think
Mylar was the closest out there to what was needed - it'd be good if
both projects could share the same abstraction. Communication with
Bugzilla is rather tedious and Mylar's implementation seems quite
comprehensive.
Mark
On 04
46 matches
Mail list logo
