done
On 2/17/06, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
>
> ... on /www/www.apache.org/dist/maven-repository, due to releases of
> Apache XML-RPC, and the Maven JaxMe plugin.
>
> Regards,
>
> Jochen
>
>
> -
> To unsubscribe, e
[ http://jira.codehaus.org/browse/MRM-74?page=all ]
nick gonzalez updated MRM-74:
-
Attachment: maven-repository-webapp-MRM-74.diff
> Browse web user interface
> -
>
> Key: MRM-74
> URL: http://jira.codehaus.org/brows
[ http://jira.codehaus.org/browse/MRM-74?page=all ]
nick gonzalez updated MRM-74:
-
Attachment: (was: maven-repository-webapp-MRM-74.diff)
> Browse web user interface
> -
>
> Key: MRM-74
> URL: http://jira.codehau
On 2/17/06, Brett Porter <[EMAIL PROTECTED]> wrote:
> This reply grabs bits from everywhere and summarises.
>
> Jesse McConnell wrote:
> > Providing a mechansim of strict execution ordering inside of a lifecycle
> > phase could address this..
>
> We already have an ordering (by inheritence, with pr
POM documentation for repository structure looks out of date
Key: MNG-2085
URL: http://jira.codehaus.org/browse/MNG-2085
Project: Maven 2
Type: Bug
Components: Documentation: Guides
Versions: 2.0.2
I'll look into the issues. I should've remembered that it would sound
familiar, but I only spent a week on Maven 1 before moving to Maven
2... :)
-Stephen
On 2/17/06, Brett Porter <[EMAIL PROTECTED]> wrote:
> Hi Stephen,
>
> Stephen Duncan wrote:
> > Is ordering necessarily the right way to thin
... on /www/www.apache.org/dist/maven-repository, due to releases of
Apache XML-RPC, and the Maven JaxMe plugin.
Regards,
Jochen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi Stephen,
Stephen Duncan wrote:
> Is ordering necessarily the right way to think about the problem? My
> usage of Maven is fairly simple, so maybe I'm not really
> conceptualizing some of the use cases. But I think about more in
> terms of prerequisites. For instance, I have several assembly
Raphaël Piéroni wrote:
> - allow the adding of resource post compilation (to have the wsdl in the
> jar)
You can do that by directly copying to target/classes in
process-classes. What you are doing is really processing classes as much
as generating resources. The only limitation is you can't filte
This reply grabs bits from everywhere and summarises.
John Casey wrote:
> Hi,
>
> I'd like to add pre/post phases for all of the major lifecycle phases
> that don't already have it.
For the record, I'm against this as the solution based on the thread so
far. Some basic reasons before going into
Distribution:
http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060218.003003.tar.gz
Log:
http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060218.003003.txt
-
To unsubscribe, e-mai
Distribution:
http://maven.zones.apache.org/~maven/builds/trunk/m2-20060218.01.tar.gz
Log:
http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060218.01.txt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For addit
Is ordering necessarily the right way to think about the problem? My
usage of Maven is fairly simple, so maybe I'm not really
conceptualizing some of the use cases. But I think about more in
terms of prerequisites. For instance, I have several assembly tasks
that I have attached to the package p
[ http://jira.codehaus.org/browse/MJAR-11?page=comments#action_58953 ]
Binyan commented on MJAR-11:
In our case we need to jar up a directory structure and give it the extension
".war". We would use the war plugin for that except that the directory
structure i
[ http://jira.codehaus.org/browse/MNG-2084?page=comments#action_58952 ]
Binyan commented on MNG-2084:
-
OK, the problem then lies in the fact that the docs at
http://maven.apache.org/maven-model/maven.html state the following for the
element:
finalName - The f
[ http://jira.codehaus.org/browse/MNG-2084?page=all ]
Brett Porter closed MNG-2084:
-
Assign To: Brett Porter
Resolution: Won't Fix
finalName doesn't include the extension. There is a related MJAR issue to allow
a configurable extension you can vot
HtmlUnit 1.8 upload request
---
Key: MAVENUPLOAD-747
URL: http://jira.codehaus.org/browse/MAVENUPLOAD-747
Project: maven-upload-requests
Type: Task
Reporter: Brad Clarke
http://htmlunit.sourceforge.net/htmlunit-1.8-bundle.jar
Team memb
I think this is the right separation. Unit test to get coverage, add and
use setters like Vincent suggested. Integration test to verify things
like the lifecycle intereactions, etc. controlled by the annotations at
the class level. We can already do both.
As Carlos mentioned, getting the objects
Jar plugin does not respect the authority of the element
Key: MNG-2084
URL: http://jira.codehaus.org/browse/MNG-2084
Project: Maven 2
Type: Bug
Versions: 2.0.2
Reporter: Binyan
I hav
Hi Vincent,
Vincent Massol wrote:
Hi Jesse,
[snip]
Now, some of plugins can be completely tested by this mechanism while
others
might not actually fit too tell into this lower level testing. That is
where the integration testing comes into more of a play.
I talked to john about this and we
I'm not sure that's enough, actually. There will be times (there already
are) when people will want to set a flag that suppresses the default
mojo for a particular phase in the lifecycle mapped by a packaging, then
substitute in their own. If that mojo happens to fall ahead of another
mojo that
I agree that we need both of unit and integration tests
- unit tests are currently painful because a lot of core objects don't
have a constructor without arguments or don't have constructor and
require caling a factory method. We need to agree where to put all
that staff (I sent a mail about this
Hi Jesse,
> -Original Message-
> From: Jesse McConnell [mailto:[EMAIL PROTECTED]
> Sent: vendredi 17 février 2006 20:40
> To: Maven Developers List
> Subject: plugin testing
>
> brett asked me to look into the idea of a plugin testing framework and
> having mulled it over a bit and talked
brett asked me to look into the idea of a plugin testing framework and
having mulled it over a bit and talked to some folks about it I wanted to
spill out my thoughts here and a couple of stabs at breaking the nut
cleanly. Also, in the interests of having people read this and not have it
drag on I
[ http://jira.codehaus.org/browse/MNG-2083?page=all ]
Carlos Sanchez updated MNG-2083:
Description:
Seems a regression
it's only shown with -X
[DEBUG] Unable to download the artifact from any repository
Try downloading the file manually from
ht
Path to missing dependency is not shown
---
Key: MNG-2083
URL: http://jira.codehaus.org/browse/MNG-2083
Project: Maven 2
Type: Bug
Components: Dependencies
Versions: 2.0.3
Reporter: Carlos Sanchez
Priority: Blo
[ http://jira.codehaus.org/browse/MNG-2082?page=all ]
Trygve Laugstol closed MNG-2082:
Resolution: Incomplete
> assembly:assembly doesn't recognize pre-defined assembly types
> --
>
>
So if i understand how to fix my trouble with the axistools plugin :
To summarize my problem :
My problem is to add a new resource after compilation.
I had this problem because i want to create and API for web service and
generate the wsdl from that API.
Then use that API in the client side and
I say we force the lifecycle issue, just make it a little easier for someone
to shove in an ordered sequence of plugins in the phase of their
liking...that should address it nicely :)
jesse
On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote:
>
> So, you're suggesting scrapping the lifecycle altoget
So, you're suggesting scrapping the lifecycle altogether and going with
a required ordering scheme in the POM? I think that's a bit drastic for
the average user. Also, it's important that we provide some sort of
shorthand to keep users from needing to know what lifecycle bindings are
introduced
+1 Now that I like
On 2/17/06, Jesse McConnell <[EMAIL PROTECTED]> wrote:
>
> if we need to build out a way to get it done, then I rather like the idea
> of
> being able to define a ordering of things inside of a phase, and then bind
> the plugins to that ordering... just to get it done in as cle
Yes. My last job was working for a government-regulated project. The problem
was, that they got write-off from the FDA of their build system 10 years
ago. There was no way it could change (which is unfortunate, because it
sucked). So I wrote a maven front-end to the packaging system, so at least
th
I agree with your sentiments here, basically. The problem is, the number of
things done to a build cannot always decrease. If you need to generate code,
compile it, and then use that code to generate and compile more, well, you
cannot avoid the fact that 4 steps are involved. At this point it becom
next thing would be to talk about how inheritance/injection works with
this. I think it would have to be inherited treating each
specification as an atom. That way, a phase ordering is never merged
from parent to child, but it can be overridden. Since we'd only be
imposing order on phases that
+1
I think this would be good, but maybe we could apply it selectively?
What I mean is, have a default ordering algorithm (like we do now), but
override that algorithm for the phases specified here. Then, we don't
have to specify everything in order to add some order.
Also, would it be good
Update Maven dependencies to 2.0.3
--
Key: CONTINUUM-594
URL: http://jira.codehaus.org/browse/CONTINUUM-594
Project: Continuum
Type: Sub-task
Components: Core system
Reporter: Emmanuel Venisse
Assigned to: Emmanuel Venisse
[ http://jira.codehaus.org/browse/CONTINUUM-534?page=all ]
Emmanuel Venisse updated CONTINUUM-534:
---
Fix Version: (was: 1.1-alpha-1)
1.0.3
Summary: Release Continunum 1.0.3 (was: Release Continunum 1.1-alpha-1)
> Releas
Distribution:
http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060217.164501.tar.gz
Log:
http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060217.164501.txt
-
To unsubscribe, e-mai
BTW, Jesse and I have already had this discussion off-list, but I wanted
to reflect it in the thread. :-)
I couldn't agree more, WRT new projects. Or where people have the
ability to manage their project structures.
My original example was of two source-generation processes in the same
por
Sure, I'm all for inter-phase-ordering, if altering the lifecycle and syntax
is up for debate. A consolidation goal is definitely a work-around.
I am just really against the pre/post thing. It seems very hacky, and very
hand-holdy (who can say if I only need three goals per phase?)
Eric
On 2/17/
if we need to build out a way to get it done, then I rather like the idea of
being able to define a ordering of things inside of a phase, and then bind
the plugins to that ordering... just to get it done in as clear as way as
possible...
compile
I really wonder about adding in more complexity into the pom with things
like ordering...
one of the attractions of maven imo is that it facilitates making the build
a simple thing, small easily digestable chunks of build process, leveraging
the dependency mechanism to weave it all together. Addi
The more I think of it, the more I dislike this solution, actually. It
simply doesn't address the larger problem, as Raphael inadvertently
pointed out. ;-)
The only trouble with strict ordering comes with the syntax, and dealing
with the various layers of inheritance and injection. Plugin bind
Distribution:
http://maven.zones.apache.org/~continuum/builds/branches/continuum-1.0.x/continuum-20060217.163001.tar.gz
Log:
http://maven.zones.apache.org/~continuum/logs/branches/continuum-1.0.x/continuum-build-log-20060217.163001.txt
IMO a consolidation goal is another workaround. It's definitely possible
now, but if we had phase-ordering, we wouldn't need it, right?
-j
Eric Redmond wrote:
+0 to the pre/post phase. As it has been mentioned a million times before,
what's the difference between the post of one phase, and the
[ http://jira.codehaus.org/browse/WAGONFTP-10?page=comments#action_58939 ]
Jean-Laurent de Morlhon commented on WAGONFTP-10:
-
above NPE is related to a missing credential for the ftp server in settings.xml.
adding
tux3-ftp-reposi
+1 on this, with a caveatit is a huge slippery slope that I think we
ought to be really clear on...especially since Raphaël already took us down
the slope some more :P
I am +1 for adding these in to address the immediate need with the
understanding that that is it and revisit the issue for the
+0 to the pre/post phase. As it has been mentioned a million times before,
what's the difference between the post of one phase, and the pre of the
next.
However, I am seeing a need for more than a single execution per stage. I
like John's suggesting alot. It makes sense. Within a particular phase,
NPE in wagon-ftp
Key: WAGONFTP-10
URL: http://jira.codehaus.org/browse/WAGONFTP-10
Project: wagon-ftp
Type: Bug
Versions: 1.0-alpha-6
Environment: linux 2.6.7, jdk 1.4.2, maven 2.0.2
Reporter: Jean-Laurent de Morlhon
Priority: Mino
I understand that this is sort of a slippery slope WRT when we stop
adding new phases. While there are major categories for the phases of a
build, things like the following could occur:
I generate a model using Modello, and would like to use my own custom
Antlr grammar to create instances of t
[ http://jira.codehaus.org/browse/CONTINUUM-496?page=all ]
Emmanuel Venisse closed CONTINUUM-496:
--
Resolution: Fixed
Fixed.
> End Time contains junk value when I forced a build to run
> -
[ http://jira.codehaus.org/browse/MNG-2082?page=comments#action_58935 ]
Howard M. Lewis Ship commented on MNG-2082:
---
My bad; I had two pom.xml's and got confused. Once I update the correct pom,
I'm back in business.
> assembly:assembly doesn't re
assembly:assembly doesn't recognize pre-defined assembly types
--
Key: MNG-2082
URL: http://jira.codehaus.org/browse/MNG-2082
Project: Maven 2
Type: Bug
Components: Artifacts
Versions: 2.0.2
+1
can you add a post-compile-generate-resources phase ? sometimes a resource
is generated (wsdl file) after the compile phase.
for example, the axistool plugin needs for the classes to be generated in
order to generated the wsdl files from them. and the plugin also try to add
it to the resources.
+1
Emmanuel
John Casey a écrit :
Hi,
I'd like to add pre/post phases for all of the major lifecycle phases
that don't already have it. I'm starting to see cases where a particular
packaging maps multiple mojos to the same lifecycle phase, and this
means we cannot control that phase through
Distribution:
http://maven.zones.apache.org/~continuum/builds/branches/continuum-1.0.x/continuum-20060217.153001.tar.gz
Log:
http://maven.zones.apache.org/~continuum/logs/branches/continuum-1.0.x/continuum-build-log-20060217.153001.txt
Hi,
I'd like to add pre/post phases for all of the major lifecycle phases
that don't already have it. I'm starting to see cases where a particular
packaging maps multiple mojos to the same lifecycle phase, and this
means we cannot control that phase through the old suppress-and-augment
approa
An exception is throwed when the http response code is 201
--
Key: WAGON-36
URL: http://jira.codehaus.org/browse/WAGON-36
Project: wagon
Type: Bug
Versions: 1.0-alpha-6
Reporter: Alexandre Poitras
[ http://jira.codehaus.org/browse/MAVENUPLOAD-745?page=all ]
Michael Böckling updated MAVENUPLOAD-745:
-
Attachment: xpp3_xpath-1.1.3.4.O-bundle.jar
> xpp3 pull parser
>
>
> Key: MAVENUPLOAD-745
> URL: http://jir
[ http://jira.codehaus.org/browse/MAVENUPLOAD-745?page=all ]
Michael Böckling updated MAVENUPLOAD-745:
-
Attachment: xpp3_min-1.1.3.4.O-bundle.jar
> xpp3 pull parser
>
>
> Key: MAVENUPLOAD-745
> URL: http://jira.
Distribution:
http://maven.zones.apache.org/~continuum/builds/trunk/continuum-20060217.150001.war
Log:
http://maven.zones.apache.org/~continuum/logs/trunk/continuum-build-log-20060217.150001.txt
[ http://jira.codehaus.org/browse/MNG-2081?page=all ]
Emmanuel Venisse updated MNG-2081:
--
Fix Version: 2.0.3
> Typing error in apt files
> -
>
> Key: MNG-2081
> URL: http://jira.codehaus.org/browse/MNG-2081
>
Log:
http://maven.zones.apache.org/~continuum/logs/branches/continuum-1.0.x/continuum-build-log-20060217.143001.txt
[ http://jira.codehaus.org/browse/MECLIPSE-8?page=comments#action_58926 ]
Nico Przybylek commented on MECLIPSE-8:
---
Since the new release I am not able to use maven2 any longer as I did.
The problem is that I have a project with compile errors. I change
RtfSink supports only ".ppm" image type in figureGraphics()
---
Key: DOXIA-51
URL: http://jira.codehaus.org/browse/DOXIA-51
Project: doxia
Type: Bug
Components: Core
Versions: 1.0-alpha-8
Report
Improve the AptParser class
---
Key: DOXIA-50
URL: http://jira.codehaus.org/browse/DOXIA-50
Project: doxia
Type: Improvement
Components: Core
Versions: 1.0-alpha-8
Reporter: Vincent Siveton
Attachments: AptParser.diff
This p
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_58925
]
Michael Mattox commented on MNGECLIPSE-59:
--
We're really stuck on this. So far the only solution we have is to have two
pom.xml, a pom.xml for the maven eclipse plugin an
Typing error in apt files
-
Key: MNG-2081
URL: http://jira.codehaus.org/browse/MNG-2081
Project: Maven 2
Type: Bug
Components: Documentation: General
Versions: 2.0.1
Reporter: Vincent Siveton
Attachments: typing_errors_apt.d
[ http://jira.codehaus.org/browse/MPJBOSS-24?page=comments#action_58919 ]
Arnaud Heritier commented on MPJBOSS-24:
This will not be fixed.
We stop the maintenance for this plugin.
If you provide a patch will try apply it and to publish a SNAPSHOT if y
[ http://jira.codehaus.org/browse/MPJBOSS-24?page=all ]
Arnaud Heritier moved MAVEN-1748 to MPJBOSS-24:
---
Workflow: jira (was: Maven)
Key: MPJBOSS-24 (was: MAVEN-1748)
Project: maven-jboss-plugin (was: Maven)
> 'maven jboss
[ http://jira.codehaus.org/browse/MRM-38?page=all ]
John Tolentino updated MRM-38:
--
Attachment: MRM-38-maven-repository-webapp.diff
> add a background task scheduler
> ---
>
> Key: MRM-38
> URL: http://jira.code
[ http://jira.codehaus.org/browse/MPIR-30?page=all ]
Brett Porter updated MPIR-30:
-
Fix Version: 2.0
> The automatically generated documentation should identify the project's group
> id, artifact id, and maybe version
> -
[ http://jira.codehaus.org/browse/WAGON-35?page=all ]
Brett Porter closed WAGON-35:
-
Assign To: Brett Porter
Resolution: Duplicate
WAGONFTP-7
> wagon doesn't support site:deploy via ftp
> -
>
> Key:
[ http://jira.codehaus.org/browse/MPIR-30?page=all ]
Brett Porter moved MNG-2080 to MPIR-30:
---
Version: (was: 2.0.2)
Component: (was: Dependencies)
Complexity: (was: Intermediate)
Workflow: Maven (was: Maven New)
[ http://jira.codehaus.org/browse/MNG-2079?page=comments#action_58916 ]
Dan Allen commented on MNG-2079:
Hey, thanks for the quick response! I would like to see this make it into the
documentation somewhere, to avoid future bugs reports. However, I think j
[ http://jira.codehaus.org/browse/MSITE-92?page=all ]
Brett Porter closed MSITE-92:
-
Assign To: Brett Porter
Resolution: Won't Fix
PrematureDocumentationException
The goal only exists in SVN. I'll roll back the site to the last release.
> site:st
'maven jboss' goal when run with Maven 1.1. beta 2 generates bad run.bat and
shutdown.bat files
Key: MAVEN-1748
URL: http://jira.codehaus.org/browse/MAVEN-1748
Project: Maven
content should not be included in apostrophes on the
commandline
--
Key: MJAVADOC-58
URL: http://jira.codehaus.org/browse/MJAVADOC-58
Project: Maven 2.x Javadoc Plugin
Type: Bug
Ve
Distribution:
http://maven.zones.apache.org/~continuum/builds/branches/continuum-1.0.x/continuum-20060217.103001.tar.gz
Log:
http://maven.zones.apache.org/~continuum/logs/branches/continuum-1.0.x/continuum-build-log-20060217.103001.txt
[
http://jira.codehaus.org/browse/MAVENUPLOAD-742?page=comments#action_58909 ]
Dave Sag commented on MAVENUPLOAD-742:
--
sorry i'm not so up with the latest maven jargon. what does "Try to deploy it
to a repo (can be a file:// repo)"
could you please
[ http://jira.codehaus.org/browse/MNG-2079?page=all ]
Emmanuel Venisse closed MNG-2079:
-
Resolution: Won't Fix
The preferred solution is :
mvn scm:checkout -DconnectionUrl=scm:svn:.
If you want to wget the pom, you must run scm:checkout with -
[
http://jira.codehaus.org/browse/MAVENUPLOAD-745?page=comments#action_58902 ]
Joerg Schaible commented on MAVENUPLOAD-745:
Michael, just wanna say thank you for doing this. I wanted to do the same for
ages and never found time. I always wondere
[ http://jira.codehaus.org/browse/MNG-1703?page=all ]
Edwin Punzalan updated MNG-1703:
Attachment: MNG-1703-maven-project.patch
> is not propagated to child POMs
>
>
> Key: MNG-17
[ http://jira.codehaus.org/browse/MNGECLIPSE-75?page=comments#action_58900
]
Jochen Wiedmann commented on MNGECLIPSE-75:
---
First of all, I apologize for confusing this bugs handling by attaching my test
project. I had the impression it would be rel
84 matches
Mail list logo
